其实。。im 这东东。。压根不是 java 社区应该讨论的东东。。

应该从底层就用 c/cpp 等 native 的，能精确控制 CPU 和内存资源的语言构建。go 恐怕都不行。

【 在 laiweiting (我心飞行) 的大作中提到: 】
: 是的
: 延迟，抖动，音频压缩，音频解码，视频压缩，视频解码，系统瓶颈，分布式管理，cdn加速，大数据，数据并发
: 哪一条，就不可能是一两个人能做的好的
: ...................
--
FROM 112.47.122.*

也不是每个人都能做到微信那个数量级的
不知道像融云、环信这些是怎么搞的

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

我们全部用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。小程序、各端都有。不贵。
【 在 feng321 的大作中提到: 】
: 这里大佬云集，能帮我这个忙吗？前端最好是uniapp写的，老板要我做群聊，群会议，一头雾水，网上也没找到合适的前后端代码，谢谢。不喜勿喷，版主觉得不合适，麻烦通知我，我来删帖。

- 来自「最水木 for iPhone 11」
--
FROM 222.128.14.*

openfire挺垃圾，一堆bug还动不动卡死，也就是demo级别

【 在 tower6 的大作中提到: 】
: 现在有openfire，xmpp的客户端一大堆
: 至于能用的程度，只有自己试一下才知道
--
FROM 111.206.214.*