- 主题:求好用的im 群聊，前后端代码?
两个月之前你就在问了
【 在 feng321 (sfdf) 的大作中提到: 】
: 我入职才一个多月，好吧！
: 【 在 nikezhang 的大作中提到: 】
: : 他隔三差五的就来问类似需求
: --
--
FROM 223.104.3.*
内部使用，那用飞鸽传书不好吗
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 主要麻烦点是可能是因为现在手机用户多，要同时支持 ios, android, windows, macos 好几个平台，一般人没那个能力。至少需要几个人合作。
:
: 如果只做一个平台，倒是不麻烦。
:
--
FROM 223.104.3.*
消息发不出去没问题，支持重新发就行，除非是告诉你发出去了那边没收到那种
【 在 leadu (leadu) 的大作中提到: 】
: 我们全部用c#写过一个，客户端使用的Xamarin，服务器用的Orleans（类似于java的akka）。
: 机器扔在北京阿里云了，性能比微信好，发消息rtt均值在200ms以下，基本上用户看不见发消息那个转圈。吞吐方面，阿里云4个节点一共2k多一个月，这样的机器配置环境中，一秒几k的消息发送。
: 吞吐受限于机器的iops，我们使用的阿里云600多的ssd的ecs，ecs的iops不怎么样，好像是消息吞吐的2倍多的样子。
: 时间长了数据就看个大概吧。
--
FROM 223.104.3.*
可以选择重发方式，在重发之前需要考虑以下问题：
1.如何知道消息发送失败？
2.在多大的一个时间窗口之内要知道失败？
3.重发策略是什么样？
4.如何去重
5.新消息和重发消息如何保证消息有序性
6.流量和延时要求是什么样
im系统说到底是一个分布式多结点不可靠环境中如何保证only once的消息传递，倒不难，主要是要处理的异常情况比较多
【 在 nikezhang 的大作中提到: 】
: 消息发不出去没问题，支持重新发就行，除非是告诉你发出去了那边没收到那种
--
FROM 61.49.152.*
你这是不是太复杂了。每个消息一个 ID，每次发送都有回执不就行了？
没回执的就定个时间点重发，重发不过就显示失败，反正 ID 一样，不会在客户端显示两次。
时间顺序，如果有服务器就更简单了，按服务器接收的顺序排序就行了。客户端自行保证发送的顺序是正常的。没有没服务器的 P2P 就相当麻烦，，要考虑到每个客户端的时间不一样，还有可能调整时间，目前我还没想到什么好办法。
IM 不是关键业务消息队列，只做尽最大努力地投递。投递失败就跟用户说。用户也不会怪你的啊。
【 在 leadu (leadu) 的大作中提到: 】
: 可以选择重发方式，在重发之前需要考虑以下问题：
: 1.如何知道消息发送失败？
: 2.在多大的一个时间窗口之内要知道失败？
: ...................
--
FROM 110.81.42.*
你这个方案进一步细化了一些，刚才我提的问题可以细化一些，当然还是那些问题：
1.什么时候给ack？服务器收到即给么？服务器给了ack之后崩溃了怎么办？投递成功给ack，那群聊怎么办？ack拖得时间太长怎么办？
2.ack丢了怎么办？都报用户消息发送失败了但最后一次重试实际成功了
3.id怎么生成，多客户端怎么处理？
4.ack的时候用户撤回了消息怎么办？
之前说了，东西不难，但少考虑了一定会丢消息，对于im来说，丢一条消息就是严重事故
【 在 hgoldfish 的大作中提到: 】
: 你这是不是太复杂了。每个消息一个 ID，每次发送都有回执不就行了？
: 没回执的就定个时间点重发，重发不过就显示失败，反正 ID 一样，不会在客户端显示两次。
: 时间顺序，如果有服务器就更简单了，按服务器接收的顺序排序就行了。客户端自行保证发送的顺序是正常的。没有没服务器的 P2P 就相当麻烦，，要考虑到每个客户端的时间不一样，还有可能调整时间，目前我还没想到什么好办法。
: ...................
--
FROM 61.49.152.*
分布式系统中的id和时间都是坑，都需要细致处理
【 在 hgoldfish 的大作中提到: 】
: 你这是不是太复杂了。每个消息一个 ID，每次发送都有回执不就行了？
: 没回执的就定个时间点重发，重发不过就显示失败，反正 ID 一样，不会在客户端显示两次。
: 时间顺序，如果有服务器就更简单了，按服务器接收的顺序排序就行了。客户端自行保证发送的顺序是正常的。没有没服务器的 P2P 就相当麻烦，，要考虑到每个客户端的时间不一样，还有可能调整时间，目前我还没想到什么好办法。
: ...................
--
FROM 61.49.152.*
用UUID不行吗？
【 在 leadu (leadu) 的大作中提到: 】
: 分布式系统中的id和时间都是坑，都需要细致处理
--
FROM 180.167.95.*
这个肯定不行，消息一多，必定出现冲突。当然你可以使用多个guid拼接降低冲突概率，但消息id会需要索引的，太长了处理不便
【 在 guestking 的大作中提到: 】
: 用UUID不行吗？
:
--
FROM 61.49.152.*
时间戳+UUID
这样还能有重复？
【 在 leadu (leadu) 的大作中提到: 】
: 这个肯定不行，消息一多，必定出现冲突。当然你可以使用多个guid拼接降低冲突概率，但消息id会需要索引的，太长了处理不便
--
FROM 180.167.95.*