架构师于小波：魅族实时消息推送架构.docxVIP

架构师于小波：魅族实时消息推送架构 2021-02-20 系统引见 这个系统数据情况是这样的，实时在线的用户是2500万左右，下面有一个趋势图，从今年1到10月份的都列出来了，这个系统一天PV量是50亿左右，这个系统推送速度可以达到600万条/分钟。 数据结构? 系统架构设计 系统架构规律上划分，划分为四层，最下面的一个是供应魅族手机的接入。其次层是消息分发服务，次要的作用就是供应上行消息的路由和用户下行消息的路，这边有一个用户路由表。第三层是订阅信息，第四层是存储，包括离岸消息存储，包括订阅消息的存储。 推送系统架构? 左上角有一个服务管理和业务监控，其实是两个独立的东西。有一个推送平台，是供应应业务使用的推送业务的接口。我们都有独立的服务，是有单独的DEMO的集群，可以独立的部署和独立的扩容。 踩过的坑＆心得 手机的功耗问题 ? 手机功耗问题? 手机功耗问题次要涉及两个点，第一个是流量，其次个是电量。先看流量的问题，怎样样处理流量的问题，通过协议选择，现在传统的互联网上，有比较典型的使用通讯协议的话，是这两个协议，XMPP、SIP，这两个协议有很多的优点，第一个是开元组件格外多，假如想快速的搭建一脱系统出来，这两个协议是比较好的选择。不足的地方是协议很简单，单独的标准文档就有几十页，假如完全把它看完，弄懂，估量要花长的时间，由于这两个协议是基于互联网的，并不是针对移动互联网进行优化的，所以协议是比较重的，像XMPP，有很多无用的标签，我们根本用不到这些标签，包括SIP协议，也有很多头，和XMPP协议差不多的。最重要的一点是格外的耗流量，所以我们就本人定义了IDG的协议，轻量、编解码属于快，是上面两个协议的10倍左右的编解码速度，最重要的一点是节省流量，使用中发觉节省流量到50%到70%。 ? 还有一个电量的问题我们怎样样处理？洲际电量就要涉及到长连接的保持，要想保持，就是要发送心跳包到用户手机上，固定的心跳，固定3分钟、5分钟或者是10分钟来发送心跳，网络情况是比较简单的，有时候网络情况是好的，有时候网络情况是差的，选择最短的时间。前面有一个协议，IDG的协议来降低用户的流量问题，通过智能心跳的问题，来降低手机的电量的消耗。? ? 下面讲一下有个延迟推送，系统使用过程中，我们发觉有些用户对实时性的要求并不是特殊的敏感，比如说系统的升级、应用的升级，早几分钟，或者是晚几分钟，并不会影响用户的使用体验。我们对于这种实时性要求不高的消息，可以使得手机在唤醒的形态下才把信息推送下去，我们怎样晓得手机处于唤醒形态呢？这个服务端是可以感知得到的，前面讲过手机要维持长连接，就要发心跳，发心跳就要唤醒手机，服务端收到心跳包的时候，再把消息推送下去，这样就可以相对来说降低一点手机的功耗问题。通过这三个点的优化，基本上相对来说是比较完善的处理了手机的功耗问题，不过这个只是其中一步其中一个坑，我们革命还未成功。 移动网络的问题? 国内的移动网络有一个特点，不稳定，由于我们不晓得什么时候会掉线，还有延迟是格外大的，移动网络的不稳定和高延迟，会让我们遇到一些什么问题？首先是遇到的反复消息的问题，反复消息是怎样产生的，可以看这个图的流程。 ? 服务端向客户端推送一条消息的时候，正常情况下，消息推送下去，客户端到这个消息，给它回一个应答，假如回应答的过程中，服务端就收不到这个应答，服务端就有两种处理方式，一种是离线，一种是超时重试，重试几次，直到收到为止，这样服务端要保持每一条推送消息的形态，这样子假如服务端后端由于不单是一个服务组成的，是有很多服务组成的，后端的调动页就会拉得很长，每一个节点上面都需要保持形态，任何一个节点消灭问题，整个都会认为这个消息是推送失败了。反复消息的话，客户端发送应答，服务端没有接到这个应答，而网络好的时候，再推送一次，那就消灭反复了。 那怎样处理这个问题？设置了消息基于序列号的交互方式，首先推送消息的时候，不是把消息直接推送下去，是发一个通知到客户端，告知你有消息，客户端拿到这个通知，发送一个指令上来，说猎取这个消息，会带上一个收到最近消息的最大的序列号。这里有一个大坑，也就是DNS也简约消灭问题，信任很多人都遇到过这样的情况。怎样处理这个问题？用全IP的方式，要接入服务器的话，我们这边有一个WEBService，里面有很多的IP列表，IP列表都拉下来，客户端直接选取一个IP地址直接去连接，看下面第一个图的第一步，通过HTTP访问客户端的，但是也存在一个域名的问题，我们做了预埋，直接用DNS访问，假如这个DNS访问不通，就可以用预埋的IP来访问，就可以拿到一个IP地址。 海量连接消灭问题 处理了IP的DNS的问题，革命成功还有半天，还有最终一个问题了，就是海量连接的问题。大并发话，我们的目标，单机可以达到40