这是一个创建于 205 天前的主题，其中的信息可能已经有所发展或是发生改变。
单机百万吞吐量的 IM 他的性能瓶颈在哪里？
瓶颈位置
IM 最大的数据的读写就是消息，消息的存储是决定此 IM 系统是否有较高的消息吞吐量的主要原因之一
常见数据库 QPS
MySQL：QPS 一般 3000-7000 左右 （参考： https://blog.csdn.net/tianya_lu/article/details/105096667 ）
MongoDB：QPS 一般在 2 万-4 万左右 （参考： https://blog.csdn.net/sunny_day_day/article/details/108578995 ）
Redis：QPS 一般是 10 万-20 万左右
问题分析
传统的 MySQL QPS 太低，显然不太适合消息这种读写太频繁的场景。
MongoDB 虽然比 MySQL QPS 高不少，但是还远远没有达到我们的预期。
Redis 已经接近了我们的预期，但是 Redis 是内存数据库，不适合存大量的消息，并且有丢消息的概率。
理想中的数据库
是否有一款数据库比 Redis 的 QPS 还要高并且不会丢消息又像 MySQL 一样适合多维度查询的数据库？
我们的开源 IM
悟空 IM （通讯层）： https://github.com/WuKongIM/WuKongIM
唐僧叨叨（业务层）： https://github.com/TangSengDaoDao/TangSengDaoDaoServer
下一篇：6. 用 Go 打造现代 IM 之自研消息数据库一
 |
1
stardew 205 天前
牛的
|
 |
2
cheng6563 205 天前
意义不明的帖子，求助？技术分享？软件推广？
写入性能不是看 TPS 吗 MySQL 测试贴 "硬盘写入速度在 17M/s ， 感觉还没到瓶颈，7200 转机械硬盘的是 90M" 不知道从哪吐槽 |
 |
3
root71370 205 天前
软件推广罢了
|
 |
4
pkoukk 205 天前
额..IM 为什么要高 QPS ？聊天记录不是一般都存在客户端么
|
 |
5
jimrok 205 天前
做 IM 真是卷上天了，一块骨头被一群开源啃了好几遍，每个都说这里有肉。
|
 |
6
zhouhuab 205 天前
盲猜 foundationdb
|
Select Language