大家好，我们最近准备上云，之前一直走的自建服务路线。核心挑战在于长连接/心跳服务的高并发, 虽然单个心跳流量很小，但要求用户一直保持在线，这带来很大的架构压力（我们团队这方面没啥经验）。
希望能跟有大规模长连接/IM/实时音视频/IoT/远程桌面云平台架构经验的朋友交流，有偿咨询或长期合作。
我的微信是 bGxtaGcxMjM0IA==
 |
1
LiaoMatt 10 天前
千万连接如果只是心跳, 通过算每个连接占用到系统内存和带宽可以大概算出需要几个实例, 相对比较容易应对, 但是涉及到数据上传下发情况就会复杂很多, 就要提前限制实例连接设备数的上线, 做消息队列,重试等; 之前我的做法是检测到带宽瓶颈就扩容, 转移部份连接到扩容到实例
|
 |
2
cloudzhou 10 天前
肯定需要 proxy 的，这是“一直保持在线”最好的方式
很早时候我就解析过 msn 聊天协议，方式就是多个接入点 从 domain 就开始分流 |
 |
4
queue 10 天前
插个眼，希望能等到大佬们成熟的架构方案，见识见识
|
 |
5
YiXinCoding 10 天前
做一个节点负载监控服务，客户端初始化的时候从这个服务获取一个负载最低或距离最近的后端节点，在客户端负载均衡，只要客户端连接稳定，后面数据在内网通过队列排队处理就行了。
思路就跟网游登录选服务器，哪个空闲选哪个一样的~ |
 |
7
blueswhisper 10 天前
@opentrade 数据库分库分表业界有很多成熟方案了。 除非你用的是非常小众的数据库，得自己搓轮子
|
 |
8
jedihy 10 天前
这感觉是高频系统设计面试题？感觉和问 chatgpt 就能得到最优解，无非就是你怎么 shard 你的数据库，再加一次层 cache 。千万级长链接心跳并发并不高。100s 一次心跳就是 10W 的 QPS ，1 个 LB 带 10 个 VM 差不多了吧。
|
 |
10
opentrade OP @blueswhisper 有是有，比如 Citus ，但是也各种限制，比如不喜欢 Azure ，aws 的 Aurora 相对又差点意思
|
 |
12
qinghuazs 9 天前
@opentrade #3 我理解数据库通过分库分表基本能解决大部分问题了，比如你用户量很大，那就搞比较多的数据库实例，目前我们公有云平台数据库实例应该是 70 个左右，分库后，再针对业务进行分表，同样的，用户量大的话，表分的就多一点，我知道的某个互联网头部企业的某个核心业务但是分表就分了一万多个！
|
 |
13
v2hh 9 天前
像这种长连接突然系统宕机恢复过程不是并发很高吗，做限流吗
|
 |
14
zzjcool 9 天前 via iPhone
mqtt 很适合这个场景，我们有过千万级别实践经验，需要的可以联系我 dG9pLXRvaS10b2k=
|
|
18
blueswhisper 9 天前
@opentrade PostgreSQL 你首先遇到的问题是 PostgreSQL 连接数限制。长连是一个专有领域，分库分表是另一个领域，两者都精的不多。讨论跟你标题有点偏离了，如果你需要分库分表方面的咨询的话，倒是可以聊聊。
|
|
19
opentrade OP @blueswhisper 聊聊呗，加我微信？
|
|
20
opentrade OP @blueswhisper 连接数不会是太大问题
|
 |
21
dododada 8 天前
在线只是个状态，只有 ping/pong ，和数据库没关系的呀，一般来讲，消息本身和数据库都没有关系，只有需要落地的时候才会最终流到数据库啊；
传统的负载要么是 F5 ，要么是 HA 之类，再不济 nginx ，不过 nginx 的均衡要自己优化，云上的不太懂，感觉应该类似 |
Select Language