简单的说，好友系统是维护用户好友关系的系统。我们最熟悉的好友系统案例当属QQ，实际上QQ是一款即时通讯工具，凭着好友系统沉淀了海量的好友关系链，从而铸就了一个坚不可摧的商业帝国。好友系统的重要性可见一斑。
熟悉互联网产品的人都知道，当产品有了一定的用户量，往往会开发一个好友系统。其主要目的是增加用户粘性（有了好友就会常来）或者增加社区活跃度（有了好友就会多交流）。
而我的后台开发生涯就是从这样一个系统开始的。
QQ的架构是什么样子的
那时候，好友系统对于我们团队大部分人来说，都是一个全新的事物，因为我们大部分人都是应届生。整个系统的架构自然不是我们一群黄毛小孩所能创造。
我们先从数据层讲起。
因为我们对QQ太熟悉了，我们可以很容易地列出好友系统的数据主要包括用户资料、好友关系链、消息（聊天消息和系统消息）、在线状态等。
互联网产品往往要面对海量的请求并发，传统的关系型数据库比较难满足读写需求。在存储中，一般是读多写少的数据才会使用MySQL等关系型数据库，而且往往还需要增加缓存来保证性能；NoSQL（NotOnlySQL）应该是目前的主流。
对于好友系统，用户资料和好友关系链都使用了kv存储，而消息使用公司自研的tlist（可以用redis的list替代），在线状态下面再介绍。
接着是逻辑层。
在这个系统中复杂度最高的应该是消息服务（而这个服务我并没有参与开发[捂脸]）。
消息服务中，消息按类型分为聊天消息和系统消息（系统消息包括加好友消息、全局tips推送等），按状态分为在线消息和离线消息。在实现中，维护3种list：聊天消息、系统消息和离线消息。聊天消息是两个用户共享的，系统消息和离线消息每个用户独占。当用户在线时，聊天消息和系统消息是直接发送的；如果用户离线，就把消息往离线消息list存入一份，等用户再次登录时拉取。
这样看来，消息服务并不复杂？其实不然，系统设计中常规的流程设计往往是比较简单的，但是对于互联网产品，异常情况才是常态，当把各种异常情况都考虑进来时，系统就会非常复杂。
这个例子中，消息发送丢包是一种异常情况，怎么保证在丢包情况下，还能正常运行就是一个不小的问题。
常见的解决方法是收包方回复确认包，发送方如果没收到确认包就重发。但是确认包又可能丢包，那又可以给确认包增加一个确认包，这是一个永无止境的确认。
解决方法可以参考TCP的重传机制。那问题来了，我们为什么不用TCP呢？因为TCP还是比较慢的，聊天消息的可靠性没有交易数据要求那么高，丢几条消息并不会造成严重后果，但是如果用户每次发送消息后都要等很久才能被收到，那体验是很差的。
一个比较折中的方案是，收包方回复确认包，如果发送方在一定时间内没有收到确认就重发；如果收包方收到两个相同的包（自定义seq一样），去重即可。
结束语：以上就是QQ的架构是什么样子的全部内容，更多内容请关注学步园。