原来是这样啊

引用：weixiaoyao 发表于 2021-04-04 16:43
我想应该需要route来做路由，根据uid，gid之类，保证同一个user，group等的请求落到同一个server

路由层同一个biz_type转发到同一台节点就可以，但是依旧绕不开单点问题，所以感觉。。想要单调递增的id，只能堆单机性能了。

引用：JackJiang 发表于 2020-10-23 20:38
im中也不一定要严格递增，微信的id就是趋势递增，不是严格递增：《IM消息ID技术专题(一)：微信的海量IM聊 ...

消息序列号是严格递增的吧

如果是万人群的情况，属于这个群聊会话ID在一段时间之后即将溢出，还可以复用以前的号段吗?

引用：怎么能够 发表于 2021-01-26 11:33
a-server缓存1000，2000，b-server缓存2000，3000，第一次请求到b返回20001，后面请求可能到a返回1001，怎 ...

我想应该需要route来做路由，根据uid，gid之类，保证同一个user，group等的请求落到同一个server

引用：怎么能够 发表于 2021-01-26 11:33
a-server缓存1000，2000，b-server缓存2000，3000，第一次请求到b返回20001，后面请求可能到a返回1001，怎 ...

是有，有这种可能性，文章里没有提到这一点的处理办法

a-server缓存1000，2000，b-server缓存2000，3000，第一次请求到b返回20001，后面请求可能到a返回1001，怎么保证趋势递增的？

引用：eagle042 发表于 2020-10-25 11:10
不是的，比如sessionID 这类的，只需要唯一，甚至都不需要递增。微信文章里提到的 序列号，同步的时间戳 ...

你没理解我说的话，严格递增的意思是：1、2、3、4、5、6、7、8，不能有问隔的这种。
微信的趋势递增指的是：1、、3、5、7、8、10，中间有间隔无所谓，只要是递增就可以。

引用：JackJiang 发表于 2020-10-23 20:38
im中也不一定要严格递增，微信的id就是趋势递增，不是严格递增：《IM消息ID技术专题(一)：微信的海量IM聊 ...

不是的，比如sessionID 这类的，只需要唯一，甚至都不需要递增。微信文章里提到的 序列号，同步的时间戳对于个体（单个人）来说是需要严格增的，微信的分段不同于滴滴讲的分段，微信的是根据人分段，滴滴是单纯分段，应用范围有很大的差别。 就以微信中的小明为列子，新产生的ID是绝不会低于他之前产生的ID的，这里的滴滴算法是不能保证的，除非同一个人永远落到一个段内。

IM中的ID生成器没有滴滴想的这么简单，也许满足了他的场景，但是在微信、钉钉这种纯IM体系中，还要复杂一点。

引用：eagle042 发表于 2020-10-23 16:05
本文简单总结一下：
1.  ID 分类（分片）。
2.  同一种类ID分段。

im中也不一定要严格递增，微信的id就是趋势递增，不是严格递增：《IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）》

本文简单总结一下：
1.  ID 分类（分片）。
2.  同一种类ID分段。
3. 同一种类ID分步长。
整体上是一种分片的逻辑。 此类ID 是趋势递增的，在IM通信中应用有限，IM中很多ID是需要严格增的，比如时间戳，比如消息游标。

不错啊