这是一个创建于 753 天前的主题，其中的信息可能已经有所发展或是发生改变。
本人职业生涯十多年基本都在开发 IM ，踩过许多坑，重构了无数个版本 (好代码不是设计出来的，是重构出来的)。
我们开源的 IM ，目前我认为最具现代化的 IM：
- 万人或千万人群支持
- 同一账号多设备登录
- 消息不丢，换设备实时同步
- 消息可编辑可回复
- 消息可以点赞
- 已读未读
- 在线状态
- 端对端加密（仅国外）
（其实现代 IM ，不仅仅是 IM 了，更像一个实时的论坛）
开源地址：
唐僧叨叨 IM ，高颜值，仿 TG https://github.com/TangSengDaoDao/TangSengDaoDaoServer
悟空 IM ，唐僧叨叨的通讯底层（自研消息 DB ） https://github.com/WuKongIM/WuKongIM
 | 1 TESTFLIGHT2021 2023-09-18 11:36:34 +08:00 缅北需要这个 |
 | 2 0littleboy 2023-09-18 11:39:17 +08:00 遥遥领先于微信 |
 | 3 wkong OP @0littleboy 不敢不敢 |
 | 4 cmos 2023-09-18 11:51:32 +08:00 看了一下架构，这个对服务器的负载应该不低吧？尤其是用户量多于 10K ，同时活跃数大于 1K 的时候。 |
 | 6 laoyutang 2023-09-18 12:11:40 +08:00 via Android 千万人的群聊，牛逼啊 |
 | 7 sakuramanstein 2023-09-18 12:15:31 +08:00 via Android 牛 |
 | 8 hellomynameis 2023-09-18 12:18:05 +08:00 不如 Telegram |
 | 9 veike 2023-09-18 12:19:12 +08:00 万人的群聊应该没有办法正常聊天吧 |
| 10 hellomynameis 2023-09-18 12:20:06 +08:00 @veike 不至于，除非全都同时在线，常常人数越多的群在线人数比例就越低，不经常上线的死人越多 |
 | 11 skiy 2023-09-18 12:21:20 +08:00 牛。先 star 。 |
 | 12 hepin1989 2023-09-18 12:21:23 +08:00 小心点，国家不准有 500 人的群，别去踩缝纫机 |
 | 14 lasuar 2023-09-18 12:27:10 +08:00 有没有 一键清除多久未上线的成员（时间可填） |
 | 17 bctdg 2023-09-18 13:39:12 +08:00 大佬，能分享一下 IM 业务访问数据库的 workload 的具体分布吗？（比如写入的频率和读（或者扫表）的频率） 看代码是用的 BoltDB 做存储引擎？这个有啥讲究吗 |
 | 19 fgwmlhdkkkw 2023-09-18 13:42:23 +08:00 @bctdg boltdb 说 go 写的，应该只是为了方便吧，毕竟 sqlite3 需要 cgo |
| 20 wkong OP @bctdg 通讯层会将消息推送一份到业务层，业务层目前是分表存储了消息（业务层存与不存，通讯层都会存储消息） BoltDB 主要是用来存储一些 key value 的元数据，比如用户的 uid 和 token ，消息存储是自研的 LSM 存储 |
| 21 bctdg 2023-09-18 13:49:12 +08:00 @fgwmlhdkkkw 毕竟 go 的数据库选择也有很多嘛，Pebble 、BadgerDB 也是 go 写的 kv 数据库，所以有点好奇怎么选的 |
 | 22 hao7Chen 2023-09-18 13:50:16 +08:00 Go 语言这么厉害吗？看来我得学一学了 |
 | 24 i979491586 2023-09-18 13:53:54 +08:00 牛。先 star 。 |
| 25 wkong OP @bctdg Pebble 这些不适合 IM 消息的这种特点，自研的类似 kafka 一样的 一个 topic 一个日志文件+索引文件，我们是一个频道一个日志文件+索引文件，一个频道的消息就可以按顺序写入到频道的日志文件里，性能非常高 |
 | 29 MENGKE 2023-09-18 14:16:09 +08:00 被缅北之类的拿去用小心被定帮信啊 |
 | 31 ArianX 2023-09-18 14:50:28 +08:00 和主流 IM 的对比如何，飞书也是用 go 打造的 |
 | 32 matolv 2023-09-18 14:54:04 +08:00 这个 UI 和操作逻辑和微信接近，微信属于完全上位替代，从用户角度就没太大意义了，除非当作企业 OA 一部分使用。如果是其他场景，TG 和 element/matrix 属于差异性替代，有存在意义。 |
 | 33 queuey 2023-09-18 15:41:48 +08:00 随便看了一下 iOS 的代码，这个 DB SQL 连防注入都没有？而且没有看到用户和用户关系表？当然有可能是我遗漏了 |
| 34 wkong OP @queuey 都是通过？填充的参数应该不存在注入问题，用户和群我们都统一抽象为频道了，频道与频道之间可以 follow 的关系 |
 | 35 winglight2016 2023-09-18 15:57:45 +08:00 好，这下老板再让我做个微信就有办法了。。。Uェ*U |
 | 36 aiqinxuancai 2023-09-18 15:59:57 +08:00 @wkong #13 这个主要看执法的灵活性 |
 | 37 yaodao 2023-09-18 16:06:41 +08:00 大佬，佩服，点赞收藏了 |
 | 38 tigerZhang 2023-09-18 16:56:28 +08:00 iOS 列表采用的是 tableView ？ collectionView ？自定义 ？ |
 | 39 hentaisan 2023-09-18 17:01:45 +08:00 现在没有专供局域网的 im 吗？ |
| 40 wkong OP |
 | 41 Jirajine 2023-09-18 17:37:09 +08:00 via Android @matolv #32 matrix 使用下来感觉非常卡顿缓慢，无论哪个客户端，性能比微信还差。不知道是它默认的 homeserver 问题，还是协议设计有问题。 telegram 或许不是最开放隐私安全的 IM ，但应该是性能最好的 IM 。 |
 | 42 jlak 2023-09-18 18:06:40 +08:00 via iPhone 一千万人群需要开一千万个 ws 吗 |
 | 43 wyx119911 2023-09-18 19:43:46 +08:00 @hellomynameis #10 确实，不过微信群在线率还是很高的 |
| 44 matolv 2023-09-19 08:36:15 +08:00 via iPhone @Jirajine vector-im 时代 UI 非常简陋，卡顿，崩溃和 bug 都很多，改名到 element 以后 UI 换掉，功能性 bug 基本修完就好很多了。如果你的卡顿指消息载入慢什么的那是服务器端的问题，不是客户端问题 |
| 45 MENGKE 2023-09-19 09:38:42 +08:00 @wkong #30 https://www.jylawyer.com/special/zongshu/20220325/15818.html 感觉第 7 条什么都能装进去。再加上私有化部署端对端加密，我个人觉得有风险，但法律方面我也不太懂 |
Select Language