用纯随机的 uuid 啊。。哪有那么容易重复。

【 在 leadu (leadu) 的大作中提到: 】
: 这个肯定不行，消息一多，必定出现冲突。当然你可以使用多个guid拼接降低冲突概率，但消息id会需要索引的，太长了处理不便
--
FROM 110.81.42.*

消息 ID 和时间戳分开两个字段。

现在的 IM 一般不差这点开销。

【 在 PaoloMaldini (solo con te) 的大作中提到: 】
: 一般消息id是要求递增的，否则很多逻辑你没法做
--
FROM 110.81.42.*

顺序应该由服务器管理吧。

跟数据库的 ID 一样，有好几种做法，各有优劣。同时每种方案也都有各自的业务逻辑算法。

【 在 PaoloMaldini (solo con te) 的大作中提到: 】
: 不是，两码事
: 会有很多复杂的场景需要客户端按顺序拉消息，
: 如果消息ID不是递增的，这块代码基本没法写
: ...................
--
FROM 110.81.42.*

你说的是在服务器里面的 ID，这个事情参考数据库 ID 的各种方案。

客户端到服务器要求一个回执，这个 ID 你可以认为是请求 ID，跟数据库的 ID 是不一样的。

【 在 PaoloMaldini (solo con te) 的大作中提到: 】
: 不是，有很多实际场景，从前往后拉，从后往前拉
: 另外还得考虑服务端负载啥的，总之这里面细节很多
: 按我理解主流IM设计消息id都是递增的，是不是严格+1递增可能各有各的做法
: ...................
--
FROM 110.81.42.*

请教一下，如果只做消息转发坑深吗？
具体需求就是自建一个消息转发服务器，在现有的IM应用中插入模块，截获特定消息转发到自建服务器上。




【 在 shaolin 的大作中提到: 】
: 这个建议你放弃吧，IM坑很深的。我是做过这个，如果0基础做这个，没有很长一段时间的积累，是做不好的。 ...
--
FROM 114.254.1.*