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

[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 差不多了吧。

[opentrade]

@jedihy 你说的这些早就在 chatgpt 上问了好多遍了，主要是交流些实战经验，也好上线有点底气

[opentrade]

@blueswhisper 有是有，比如 Citus ，但是也各种限制，比如不喜欢 Azure ，aws 的 Aurora 相对又差点意思

[opentrade]

@opentrade 蟑螂 db ，pingcap 那些我又不敢用

[qinghuazs]

@opentrade #3 我理解数据库通过分库分表基本能解决大部分问题了，比如你用户量很大，那就搞比较多的数据库实例，目前我们公有云平台数据库实例应该是 70 个左右，分库后，再针对业务进行分表，同样的，用户量大的话，表分的就多一点，我知道的某个互联网头部企业的某个核心业务但是分表就分了一万多个！

[v2hh]

像这种长连接突然系统宕机恢复过程不是并发很高吗，做限流吗

[zzjcool]

mqtt 很适合这个场景，我们有过千万级别实践经验，需要的可以联系我 dG9pLXRvaS10b2k=

[opentrade]

@v2hh 对， 你说到重点了

[opentrade]

@qinghuazs 我们没法跟大厂比啊，分表分那么多。分库又让系统搞得复杂了。你们用的啥公有云平台数据库?

[opentrade]

@qinghuazs 目前我们保守，选 auora ，citus 和蟑螂 db 那些还不敢用，我们是 psql ，也用不了 OceanBase 这些。