- 主题:求好用的im 群聊，前后端代码?
主要麻烦点是可能是因为现在手机用户多，要同时支持 ios, android, windows, macos 好几个平台，一般人没那个能力。至少需要几个人合作。
如果只做一个平台，倒是不麻烦。
像楼主这种公司内部使用的，没几个人。
【 在 shaolin (我的大小宝贝儿...) 的大作中提到: 】
: 从头做到正儿八经能凑合着用的用户量较少的。。成本得个几百万+1年吧。。
: 做做才能知道有多费劲，各种推到重来...
--
修改:hgoldfish FROM 112.47.122.*
FROM 112.47.122.*
其实。。im 这东东。。压根不是 java 社区应该讨论的东东。。
应该从底层就用 c/cpp 等 native 的，能精确控制 CPU 和内存资源的语言构建。go 恐怕都不行。
【 在 laiweiting (我心飞行) 的大作中提到: 】
: 是的
: 延迟，抖动，音频压缩，音频解码，视频压缩，视频解码，系统瓶颈，分布式管理，cdn加速，大数据，数据并发
: 哪一条，就不可能是一两个人能做的好的
: ...................
--
FROM 112.47.122.*
用户可能只能几万，但是设计的时候还是得以千万级别的用户量进行设计啊。
【 在 PaoloMaldini (solo con te) 的大作中提到: 】
: 也不是每个人都能做到微信那个数量级的
: 不知道像融云、环信这些是怎么搞的
--
FROM 110.85.22.*
你这是不是太复杂了。每个消息一个 ID，每次发送都有回执不就行了？
没回执的就定个时间点重发，重发不过就显示失败，反正 ID 一样，不会在客户端显示两次。
时间顺序，如果有服务器就更简单了，按服务器接收的顺序排序就行了。客户端自行保证发送的顺序是正常的。没有没服务器的 P2P 就相当麻烦，，要考虑到每个客户端的时间不一样，还有可能调整时间，目前我还没想到什么好办法。
IM 不是关键业务消息队列，只做尽最大努力地投递。投递失败就跟用户说。用户也不会怪你的啊。
【 在 leadu (leadu) 的大作中提到: 】
: 可以选择重发方式，在重发之前需要考虑以下问题：
: 1.如何知道消息发送失败？
: 2.在多大的一个时间窗口之内要知道失败？
: ...................
--
FROM 110.81.42.*
用纯随机的 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.*