qq自动发消息脚本 如何设计一个亿级消息量的 IM 系统
IM核心概念
用户：系统的使用者
消息：是指用户之间的沟通内容。通常在IM系统中，消息会有以下几类：文本消息、表情消息、图片消息、视频消息、文件消息等等
会话：通常指两个用户之间因聊天而建立起的关联
群：通常指多个用户之间因聊天而建立起的关联
终端：指用户使用IM系统的机器。通常有Android端、iOS端、Web端等等
未读数：指用户还没读的消息数量
用户状态：指用户当前是在线、离线还是挂起等状态
关系链：是指用户与用户之间的关系，通常有单向的好友关系、双向的好友关系、关注关系等等。这里需要注意与会话的区别，用户只有在发起聊天时才产生会话卡盟，但关系并不需要聊天才能建立。对于关系链的存储，可以使用图数据库（Neo4j等等），可以很自然地表达现实世界中的关系，易于建模
单聊：一对一聊天
群聊：多人聊天
客服：在电商领域，通常需要对用户提供售前咨询、售后咨询等服务。这时，就需要引入客服来处理用户的咨询
消息分流：在电商领域，一个店铺通常会有多个客服，此时决定用户的咨询由哪个客服来处理就是消息分流。通常消息分流会根据一系列规则来确定消息会分流给哪个客服，例如客服是否在线（客服不在线的话需要重新分流给另一个客服）、该消息是售前咨询还是售后咨询、当前客服的繁忙程度等等
信箱：本文的信箱我们指一个Timeline、一个收发消息的队列
读扩散 vs 写扩散
读扩散
我们先来看看读扩散。如上图所示，A与每个聊天的人跟群都有一个信箱（有些博文会叫Timeline），A在查看聊天信息的时候需要读取所有有新消息的信箱。这里的读扩散需要注意与Feeds系统的区别，在Feeds系统中，每个人都有一个写信箱，写只需要往自己的写信箱里写一次就好了，读需要从所有关注的人的写信箱里读。但IM系统里的读扩散通常是每两个相关联的人就有一个信箱，或者每个群一个信箱。
读扩散的优点：
读扩散的缺点：
写扩散
接下来看看写扩散。
在写扩散中，每个人都只从自己的信箱里读取消息，但写（发消息）的时候，对于单聊跟群聊处理如下：
写扩散优点：
写扩散缺点：
注意，在Feeds系统中：
唯一ID设计
通常情况下qq自动发消息脚本，ID的设计主要有以下几大类：
具体的实现方法跟优缺点可以参考之前的一篇博文：分布式唯一 ID 解析
在IM系统中需要唯一Id的地方主要是：
消息ID
我们来看看在设计消息ID时需要考虑的三个问题。
消息ID不递增可以吗
我们先看看不递增的话会怎样：
因此，消息ID最好是递增的。
全局递增 vs 用户级别递增 vs 会话级别递增
全局递增：指消息ID在整个IM系统随着时间的推移是递增的。全局递增的话一般可以使用Snowflake（当然，Snowflake也只是worker级别的递增）。此时，如果你的系统是读扩散的话为了防止消息丢失，那每一条消息就只能带上上一条消息的ID，前端根据上一条消息判断是否有丢失消息，有消息丢失的话需要重新拉一次。
用户级别递增：指消息ID只保证在单个用户中是递增的，不同用户之间不影响并且可能重复。典型代表：微信。如果是写扩散系统的话信箱时间线ID跟消息ID需要分开设计，信箱时间线ID用户级别递增，消息ID全局递增。如果是读扩散系统的话感觉使用用户级别递增必要性不是很大。
会话级别递增：指消息ID只保证在单个会话中是递增的，不同会话之间不影响并且可能重复。典型代表：QQ。
连续递增 vs 单调递增
连续递增是指ID按 1,2,3...n 的方式生成；而单调递增是指只要保证后面生成的ID比前面生成的ID大就可以了，不需要连续。
据我所知，QQ的消息ID就是在会话级别使用的连续递增，这样的好处是，如果丢失了消息，当下一条消息来的时候发现ID不连续就会去请求服务器qq自动发消息脚本，避免丢失消息。此时，可能有人会想，我不能用定时拉的方式看有没有消息丢失吗？当然不能，因为消息ID只在会话级别连续递增的话那如果一个人有上千个会话，那得拉多少次啊，服务器肯定是抗不住的。
对于读扩散来说，消息ID使用连续递增就是一种不错的方式了。如果使用单调递增的话当前消息需要带上前一条消息的ID（即聊天消息组成一个链表），这样，才能判断消息是否丢失。
总结一下就是：
会话ID
我们来看看设计会话ID需要注意的问题：
其中，会话ID有种比较简单的生成方式（特殊的规则生成唯一ID）：拼接from_user_id跟to_user_id：
如果from_user_id跟to_user_id都是32位整形数据的话可以很方便地用位运算拼接成一个64位的会话ID，即：conversation_id = ${from_user_id}
来源：【九爱网址导航www.fuzhukm.com】 免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
