术→技巧, 研发

即时通讯系统之陌陌

钱魏Way · · 920 次浏览

放弃使用XMPP

陌陌发展刚开始由于规模小,30-40W的连接数(包括Android后台长连接用户),也使用XMPP;由于XMPP的缺点:

  • 流量大(基于XML)
  • 不可靠(为传统固定网络设计,没有考虑WIFI/2G/3G/地铁/电梯等复杂网络场景),交互复杂(登陆需5-6次,尤其是TLS握手)
  • XMPP丢消息:服务端和客户端处于“半关闭”状态,客户端假连接状态,服务端有收不到回执;
  • Server端连接层和逻辑层代码没有解耦分离,常常重启导致不可用。

陌陌的系统架构

消息中转:

连接层(Connector链接集群)

  • 连接层的作用:只做消息转发
  • 设计原则简单/异步
  • 允许随时重启更新/只允许晚上重启/不允许重启断线
  • 单台压测试连接数70W;现状:5亿用户,月活5000W+,连接数1200W+;

逻辑层(Logic逻辑集群)

  • 用户会话验证
  • 消息存取
  • 异步队列
  • 随时重启

通讯协议设计:

  • 安全性要求
  • 流量要求
  • 传输要求可靠(不会丢消息)
  • 高效(弱网络快速的收发)
  • 易于扩展

陌陌的通讯协议

常见协议XMPP/SIP,主要缺点:流量大,不可靠,交互复杂

陌陌采用私有通讯协议,目标:

  • 高效,弱网络快速收发
  • 可靠,不会丢消息
  • 易于扩展
  • 参考协议格式:REDIS协议

Redis协议

下面都是用Redis协议来描述逻辑

基于队列的消息协议

基于队列的交互

  • 传统的IM协议
  • 前提是基于网线、WiFI,网络延迟极小
  • 移动网络下,交互及其费时,服务器要维护每个状态容易出错

基于版本号的消息协议

基于版本号的交互

针对弱网络的优化协议

  • 消息通过版本号维护顺序
  • 新消息到达,Server只负责push通知
  • Client收到轻量的msg-psh后发生同步请求
  • Server按照版本号连续发送msg
  • Client告诉Server收到的最后的版本

监控

  • 核心的长连接只用于传输轻量的实时数据,图片、语音等都开新的TCP或HTTP连接
  • 一切就绪后,最重要的就是监控,写一个APP查看所有的运营状态,每天观察

如何选择最优路线智能路由、连接策略:

  • 多端口、双协议支持,应对移动网关代理的端口限制
  • 支持TCP、HTTP两种协议
  • 根据备选IP列表进行并发测速(IP+端口+协议)
  • 后端根据终端连接情况,定时更新终端的备选IP列表
  • 终端在连接空闲时上报测速数据,便于后端决策
  • TCP协议不通,自动切换到http
  • 优先使用最近可用IP
  • 并发测速,根据终端所处的位置下发多组IP、PORT,只用IP,不用域名,手机上的DNS50%不准

参考资料:

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注