我们全部用c#写过一个，客户端使用的Xamarin，服务器用的Orleans（类似于java的akka）。
机器扔在北京阿里云了，性能比微信好，发消息rtt均值在200ms以下，基本上用户看不见发消息那个转圈。吞吐方面，阿里云4个节点一共2k多一个月，这样的机器配置环境中，一秒几k的消息发送。
吞吐受限于机器的iops，我们使用的阿里云600多的ssd的ecs，ecs的iops不怎么样，好像是消息吞吐的2倍多的样子。
时间长了数据就看个大概吧。


im最麻烦的是任何情况都不能丢消息，其次是延时。
任何情况要画重点：服务器要多结点以便维护，接入点要多结点。
actor保活探测要做好，恢复要做好，否则内网抖一下就全玩完了。
发送端用户点了发送之后用户坐个电梯不能丢消息
发送端在地铁上可能切换接入点。
dns必须控制，否则2s发不出一个消息等投诉吧
接收端不能重复展示消息

im技术方面的世界记录是erlang的whatsapp，cpu内存什么的根本不重要，重要的是robust

【 在 hgoldfish 的大作中提到: 】
: 其实。。im 这东东。。压根不是 java 社区应该讨论的东东。。
: 应该从底层就用 c/cpp 等 native 的，能精确控制 CPU 和内存资源的语言构建。go 恐怕都不行。
:
--
修改:leadu FROM 123.115.136.*
FROM 123.115.136.*

我们是有个和im相关的产品
【 在 guestking 的大作中提到: 】
: 你们是做im产品的吗？
:
--
FROM 123.115.136.*

你这个方案进一步细化了一些，刚才我提的问题可以细化一些，当然还是那些问题：
1.什么时候给ack？服务器收到即给么？服务器给了ack之后崩溃了怎么办？投递成功给ack，那群聊怎么办？ack拖得时间太长怎么办？
2.ack丢了怎么办？都报用户消息发送失败了但最后一次重试实际成功了
3.id怎么生成，多客户端怎么处理？
4.ack的时候用户撤回了消息怎么办？

之前说了，东西不难，但少考虑了一定会丢消息，对于im来说，丢一条消息就是严重事故

【 在 hgoldfish 的大作中提到: 】
: 你这是不是太复杂了。每个消息一个 ID，每次发送都有回执不就行了？
: 没回执的就定个时间点重发，重发不过就显示失败，反正 ID 一样，不会在客户端显示两次。
: 时间顺序，如果有服务器就更简单了，按服务器接收的顺序排序就行了。客户端自行保证发送的顺序是正常的。没有没服务器的 P2P 就相当麻烦，，要考虑到每个客户端的时间不一样，还有可能调整时间，目前我还没想到什么好办法。
: ...................
--
FROM 61.49.152.*

这个肯定不行，消息一多，必定出现冲突。当然你可以使用多个guid拼接降低冲突概率，但消息id会需要索引的，太长了处理不便

【 在 guestking 的大作中提到: 】
: 用UUID不行吗？
:
--
FROM 61.49.152.*