博文:零基础IM开发入门(一):什么是IM系统?
博文系列:IM消息ID技术专题
-
划重点:预分配中间层、分好段存储
-
微信的海量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