高并发架构求解：千万级在线长连接，有偿咨询（杭州）

[opentrade]

大家好，我们最近准备上云，之前一直走的自建服务路线。核心挑战在于长连接/心跳服务的高并发, 虽然单个心跳流量很小，但要求用户一直保持在线，这带来很大的架构压力（我们团队这方面没啥经验）。

希望能跟有大规模长连接/IM/实时音视频/IoT/远程桌面云平台架构经验的朋友交流，有偿咨询或长期合作。

我的微信是 bGxtaGcxMjM0IA==

[LiaoMatt]

千万连接如果只是心跳, 通过算每个连接占用到系统内存和带宽可以大概算出需要几个实例, 相对比较容易应对, 但是涉及到数据上传下发情况就会复杂很多, 就要提前限制实例连接设备数的上线, 做消息队列,重试等; 之前我的做法是检测到带宽瓶颈就扩容, 转移部份连接到扩容到实例

[cloudzhou]

肯定需要 proxy 的，这是“一直保持在线”最好的方式
很早时候我就解析过 msn 聊天协议，方式就是多个接入点
从 domain 就开始分流

[opentrade]

@LiaoMatt 瓶颈还是数据库

[queue]

插个眼，希望能等到大佬们成熟的架构方案，见识见识

[YiXinCoding]

做一个节点负载监控服务，客户端初始化的时候从这个服务获取一个负载最低或距离最近的后端节点，在客户端负载均衡，只要客户端连接稳定，后面数据在内网通过队列排队处理就行了。

思路就跟网游登录选服务器，哪个空闲选哪个一样的~

[xmh51]

@opentrade 数据库什么瓶颈？

[blueswhisper]

@opentrade 数据库分库分表业界有很多成熟方案了。 除非你用的是非常小众的数据库，得自己搓轮子

[jedihy]

这感觉是高频系统设计面试题？感觉和问 chatgpt 就能得到最优解，无非就是你怎么 shard 你的数据库，再加一次层 cache 。千万级长链接心跳并发并不高。100s 一次心跳就是 10W 的 QPS ，1 个 LB 带 10 个 VM 差不多了吧。