陌陌通讯协议的学习

15 sec read

陌陌发展刚开始由于规模小,30-40W的连接数(包括Android后台长连接用户),也使用XMPP;由于XMPP的缺点:流量大(基于XML),不可靠(为传统固定网络设计,没有考虑WIFI/2G/3G/地铁/电梯等复杂网络场景),交互复杂(登陆需5-6次,尤其是TLS握手);XMPP丢消息的根本原因:服务端和客户端处于“半关闭”状态,客户端假连接状态,服务端有收不到回执;Server端连接层和逻辑层代码没有解耦分离,常常重启导致不可用。

momo-1

消息中转:

momo-2

连接层(Connector链接集群)

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

逻辑层(Logic逻辑集群)

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

通讯协议设计:

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

通讯协议:

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

momo-3

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

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

Redis协议:

momo-4

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

Read Redis Command

momo-5

基于队列的消息协议

momo-6

基于队列的交互

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

momo-7

基于版本号的消息协议

momo-8

基于版本号的交互

momo-9

针对弱网络的优化协议

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

监控

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

momo-10

momo-11

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

多端口、双协议支持,应对移动网关代理的端口限制

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

参考资料:

打赏作者
微信支付标点符 wechat qrcode
支付宝标点符 alipay qrcode

C语言学习:size_t

在学习C语言的时候,遇到了一个新的数据类型size_t,截止目前也没有完全理清这个类似的具体场景及出现的原因。
44 sec read

C语言学习:main()函数的正确写法

C语言虽然是一门古老的语言,但是其标准一直在完善,所以很多以前支持的语法在到当前已经不能在使用了。 C语言的版
41 sec read

Scipy数学函数的Scala实现

最近在推进项目的时候,遇到需要将线下的Python代码转化成线上的集群代码,由于机器代码环境是Scala,所以
4 min read

4 Replies to “陌陌通讯协议的学习”

  1. 并发问题怎么处理?例如c1向c2发送3条聊天消息,而这时候svr还没处理完第一条的时候就,push给c2通知同步sync,然后c2同步到3条消息,接着svr处理后面两天的时候有push通知,这时候,c2会发起3次sync,并且3次的sync结果都是一样的

发表评论

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