这是一个创建于 433 天前的主题，其中的信息可能已经有所发展或是发生改变。
本人职业生涯十多年基本都在开发 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
imes 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