消息系统（转）
1. http如何像tcp一样实时的收消息？
长轮询实际怎么玩
1）消息连接：webim和webserver之间建立一条http连接，专门用作消息通道，这条连接叫http消息连接
2）消息连接的4大特性
a. 没有消息到达的时候，这个http消息连接将被夯住，不返回，由于http是短连接，这个http消息连接最多被夯住90秒，就会被断开（这是浏览器或者webserver的行为）
b. 在1）的情况下，如果http消息连接被断开，立马再发起一个http消息连接【见下图中的步骤1、2】
c. 在1）和2）的配合下，浏览器与webserver之间将永远有一条消息连接在（极限情况下会出现4）），每次收到消息时，这个消息连接就能及时将消息带回浏览器页面，并且在返回后，会立马再发起一个http消息连接
d. 如果消息到达时，上一个http消息连接正在返回，没有http消息连接可用（理论上http消息连接的返回是瞬时的，没有连接可用出现的概率极小），则将消息暂存入消息池中，下一个消息连接到达后（上一个
消息连接返回后，根据2）和3）会立马返回新的消息连接，无等待时间），将消息带回，并又立刻返回生成新的消息连接
结论：
webim通过http长轮询可以保证消息的绝对实时性。这种实时性的保证不是通过增加轮询频率来保证的，而是通过夯住http消息连接来保证的，在大部分时间没有实时消息的情况下，这个http消息连接对于webserver的
请求压力是90秒1次，能够大大节省了web服务器资源。
2. 微信为什么不丢消息？
1）im系统是通过超时、重传、确认、去重的机制来保证消息的可靠投递，不丢不重
2）一个“你好”的发送，包含上半场msg:R/A/N与下半场ack:R/A/N的6个报文
3）im系统难以做到系统层面的不丢不重，只能做到业务层面的不丢不重
3. 微信为啥不丢“离线消息”？
1）问题：接收方不在线时，消息发送的流程是怎么样的？
服务器将消息存储到DB中
2）“离线消息”的可达性可能比大家想象的要复杂，常见的优化有：
（1）对于同一个用户B，一次性拉取所有用户发给ta的离线消息，再在客户端本地进行发送方分析，相比按照发送方一个个进行消息拉取，能大大减少服务器交互次数
（2）分页拉取，先拉取计数再按需拉取，是无线端的常见优化
（3）应用层的ACK，应用层的去重，才能保证离线消息的不丢不重
（4）下一页的拉取，同时作为上一页的ACK，能够极大减少与服务器的交互次数
3. 群消息这么复杂，怎么能做到不丢不重？
群消息还是非常有意思的，可达性、实时性、离线消息、消息风暴扩散等等等等，做个总结：
1）不管是群在线消息，还是群离线消息，应用层的ACK是可达性的保障
2）群消息只存一份，不用为每个用户存储离线群msg_id，只需存储一个最近ack的群消息id/time
3）为了减少消息风暴，可以批量ACK
4）如果收到重复消息，需要msg_id去重，让用户无感知
5）离线消息过多，可以分页拉取（按需拉取）优化
4. 微信多点登录与QQ消息漫游架构随想
“多点登录”是指多个端同时登录一个帐号，同时收发消息，关键点是：
1）需要在服务端存储同一个用户多个端的状态与登陆点
2）发出消息时，要对发送方的多端与接收端的多端，都进行消息投递
“消息漫游”是指一个用户在任何端，都可以拉取到历史消息，关键点是：
1）所有消息存储在云端
2）每个端本地存储last_msg_id，在登录时可以到云端同步历史消息
3）云端存储所有消息成本较高，一般会对历史消息时间(或者条数)进行限制
5. QQ状态同步究竟是推还是拉？
状态的实时性与一致性是一个较难解决的技术问题，不同的业务接受度，不同的数据量并发量在线量，实现方式不同，个人建议的方式是：
1）好友状态，如果对实时性要求较高，可以采用推送的方式同步；如果实时性要求不高，可以采用轮询拉取的方式同步
2）群友的状态，由于消息风暴扩散系数过大，可以采用按需拉取，延时拉取的方式同步
3）系统消息/开屏广告等对实时性要求不高的业务，可以采用拉取的方式获取消息
4）“消息风暴扩散系数”是指一个消息发出时，变成N个消息的扩散系数，这个系数与业务及数据相关，一定程度上它的大小决定了技术采用推送还是拉取
6. 微信为啥这么省流量（技术宅入）
1）APP登录时需要拉取什么数据？
答：APP登陆时，一般要拉取两类数据，一类是“id列表型数据”，一类是“信息详情型数据”
2）能不能在登录的过程中不拉取这些数据，而在登录后拉取？
答：如果登录时不拉取，登陆后刷好友列表，刷群列表，群成员会很慢。
如果登录时拉取，登陆过程可能会很慢（微信的“大月亮背景”要等多长时间？QQ登录要等30s？）。
为了保证登录后的体验，一般是在登录过程中拉取。
3）能不能直接复用客户端本地的数据？
答：不能直接复用客户端本地的数据，因为不能确保本地的数据是最新的。
4）核心问题：每次登录都需要拉取，太费流量了，有没有优化方法？
答：常用优化方法有两种
（1）延迟拉取，按需拉取
（2）时间戳
5）延迟拉取，按需拉取为什么有效？为什么能够减少拉取流量？
答：用户在使用APP的过程中，有些数据是一定会使用到的，有些数据是不一定会使用到的。对于一定会使用到的数据，登录时拉取可以提升后续用户体验。对于不一定会使用到的数据，登录时拉取可能浪费流量，
这些数据如果进行“延迟拉取”，可以节省流量。
6）哪些数据不登录后不一定会使用，可以延迟拉取？
答：这个问题的答案和业务紧密相关，以微信为例
一定会使用到的数据：好友列表（主页面要展示user-name），群组列表（主界面要展示group-name）
不一定会使用到的数据：好友详情，群组详情，群友列表，群友详情
故，对于微信，登录时只需要拉取好友列表（id+name）与群组列表（id+name）即可，而其他数据，等用户真正点击和使用时再拉取即可，这样就可以大大减少拉取流量。
7）时间戳为什么有效？为什么能够减少拉取流量？
答：本地数据不能直接使用的原因是，不确定数据是否最新，拉取服务器时间戳与本地时间戳进行比对，如果本地是最新的数据，就能避免重新拉取。id列表数据的变化频度是比较低的（增加id，减少id），时间戳机制非常的有效。
8）加入时间戳机制后，数据拉取流程有什么变化？
答：假设有100个好友，以好友详情数据的拉取为例，没有时间戳之前，直接向服务器拉取这100个好友的详情数据。
在有了时间戳之后，数据拉取流程变为：
（1）先拉取100个好友的时间戳
（2）客户端将100个好友的时间戳与本地时间戳对比，找出差异，假设有10个好友的信息发生了变化，时间戳改变了
（3）拉取有变化的10个好友的信息
优点是：大大减少了数据传输量（由拉取100个好友，降低到拉取10个好友）
缺点是：增加了一次网络交互（原来直接拉取，现在需要分别拉取时间戳与差异数据）
9）使用时间戳的同时，能否降低网络交互次数呢？
答：可以！
客户端对时间戳的使用，往往采取“客户端拉取时间戳”+“客户端比对时间戳”+“客户端再次拉取差异数据”的方式进行，“时间戳比对”的的CPU计算发生在客户端，其实，这个计算可以转嫁到服务器，步骤为：
（1）客户端上传100个好友的时间戳
（2）“服务端”收到客户端上传的时间戳，与最新时间戳对比，找出差异，假设有10个好友的信息发生了变化，服务端可以直接将有差异的10个好友的数据返回
优点是：客户端减少了一次网络请求
缺点是：比对时间戳差异的CPU计算由“端”转嫁到了“云”
10）问题十：你怎么知道微信是这么做的？
答：我不知道微信是怎么做的，微信比较出名，所以标题党了一把，抱歉。
“客户端上传时间戳”的方法，58帮帮APP是这么做的，希望对业界同仁有启示作用。
7. 消息“时序”与“一致性”为何这么难？
（1）分布式环境下，消息的有序性是很难的，原因多种多样：时钟不一致，多发送方，多接收方，多线程，网络传输不确定性等
（2）要“有序”，先得有衡量“有序”的标尺，可以是客户端标尺，可以是服务端标尺
（3）大部分业务能够接受大范围趋势有序，小范围误差；绝对有序的业务，可以借助服务器绝对时序的能力
（4）单点序列化，是一种常见的保证多机时序统一的方法，典型场景有db主从一致，gfs多文件一致
（5）单对单聊天，只需保证发出的时序与接收的时序一致，可以利用客户端seq
（6）群聊，只需保证所有接收方消息时序一致，需要利用服务端seq，方法有两种，一种单点绝对时序，另一种id串行化
8. 58到家通用实时消息平台架构细节（Qcon2016）
（1）“端到云”消息投递：TCP消息通道，消息总线业务解耦
（2）“云到端”消息投递：提供RPC接口，引入状态存储
（3）“端到端”消息投递步骤如下图：
（4）“端到端”消息投递技巧
a）先存离线消息防丢失
b）ACK机制保证可达
c）发送方消息重发
d）接收方消息去重
（5）可扩展协议设计
a）定长包头，变长包体，随时增加接口
b）可扩展序列化协议，随时变化接口
c）可扩展消息协议，随时增加类型
（6）支持跨帐号体系聊天（多个域）：使用domain（或者appid）+uid作为综合key
（7）分层架构如下图
9.
