【笔记】IM消息通信学习

博文：零基础IM开发入门(一)：什么是IM系统？

博文系列：IM消息ID技术专题

• 微信的海量IM聊天消息序列号生成实践（算法原理篇）

• 划重点：预分配中间层、分好段存储
  
  

• 微信的海量IM聊天消息序列号生成实践（容灾方案篇）

  • 划重点：嵌入式路由表容灾

• 解密融云IM产品的聊天消息ID生成策略

  消息ID的使用贯穿了IM技术逻辑的方方面面，比如：
  1）聊天消息的顺序保证；
  2）聊天消息QoS送达保证机制时的去重；
  3）特定聊天消息的精确查找和匹配；
  4）聊天消息的已读未读处理；
  5）聊天消息的送达回执；
  6）群聊消息的扩散读拉取标记
  
  常见的消息ID生成策略有：
  1）UUID：这种方法简单直观，可以很好的保证唯一性，但对于技术洁癖的人来说ID长度会有点长，而且是无序的；
  2）使用时间戳长整数：这个最偷懒，用在吞吐量不大的场景下，凑活也能用，但存在重复的风险，也无法保证分布式下的唯一性；
  3）使用twitter开源的snowflake算法：在分布式高并发的情况下，这也是个不错的选择；
  4）按用户使用独立的ID生成空间生成顺序的ID：比如微信的消息序列号生成策略就很不错
  

• 深度解密美团的分布式ID生成算法

  • UUID ：不易于存储：UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用；信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。
  • Snowflake算法：强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。
  • 数据库的自增ID：强依赖DB，当DB异常时整个系统不可用，属于致命问题。配置主从复制可以尽可能的增加可用性，但是数据一致性在特殊情况下难以保证。主从切换时的不一致可能会导致重复发号；ID发号性能瓶颈限制在单台MySQL的读写性能。
  • Leaf-segment方案：可生成全局唯一、全局有序的ID；ID号码不够随机，能够泄露发号数量的信息，不太安全；TP999数据波动大，当号段使用完之后还是会hang在更新数据库的I/O上，tg999数据会出现偶尔的尖刺；DB宕机会造成整个系统不可用。
  • Leaf-snowflake方案：可生成全局唯一、局部有序的ID