魅族实时消息推送架构总结

架构总结"/>

魅族实时消息推送架构总结

今日读了  架构师于小波：魅族实时消息推送架构总结 

总结了几个技术点，供大家参考

一、手机功耗问题-----协议选择

        协议列表：XMPP，SIP

         优点：开源组建多

         缺点：协议比较复杂，冗余，有余标签也较多，导致更加消耗数据流量

         解决方案：采用自定义二进制协议

         优点：轻量，编解码速度快，节约流量达50%-70%

         附：XMPP协议简介

                 可扩展通讯和表示协议 (XMPP) 可用于服务类实时通讯、表示和需求响应服务中的XML数据元流式传输。XMPP以Jabber协议为基础，而Jabber是即时通讯中常用的开放式协议。

             SIP协议简介

             SIP(Session Initiation Protocol)是一个应用层的信令控制协议。用于创建、修改和释放一个或多个参与者的会话。这些会话可以是Internet多媒体会议[3]  、IP电话或多媒体分发。会话的参与者可以通过组播（multicast）、网状单播（unicast）或两者的混合体进行通信。

二、手机功耗问题-----长连接保持

        固定心跳，受国内网络情况的制约，同时还有用户对各类信息的实时性要求不同，所以进化为智能心跳

        智能心跳：根据不同的网络环境，使用不同的心跳间隔；对于实时性要求不高的消息，采用手机唤醒状态才推送的规则

三、移动网络的问题

       国内网络的复杂性和不稳定性，导致消息重复的新问题

       解决方案：消息基于序列号的交互方式，首先推送消息的时候，不是把消息直接推送下去，是发一个通知到客户端，告诉你有消息，客户端拿到这个通知，发送一个指令上来，说获取这个消息，会带上一个收到最近消息的最大的序列号。这里有一个大坑，也就是DNS也容易出现问题，相信很多人都碰到过这样的情况。怎么解决这个问题？用全IP的方式，要接入服务器的话，我们这边有一个WEBService，里面有很多的IP列表，IP列表都拉下来，客户端直接选取一个IP地址直接去连接，看下面第一个图的第一步，通过HTTP访问客户端的，但是也存在一个域名的问题，我们做了预埋，直接用DNS访问，如果这个DNS访问不通，就可以用预埋的IP来访问，就可以拿到一个IP地址。

四、海量连接的问题

       并发问题

       单机可以达到400万的长连接，我们实现C++来实现的，是性能的原因才用C++的。还有多进程+epoll，内存池防止内存碎片。这里比较推荐Tcmalloc这个是谷歌开元的组件，非常好用。最后我们还做了内核参数调优的优化，内核参数调优，系统在一台服务器上跑的时候，达到百万级连接的时候，我们发现有一个问题，其中有一个CPU的负载会非常高，其他的CPU负载相对来说是比较低的，是比较空闲的，最后我们发现说，因为我们的网卡是多个，网卡的中断都由这个CPU响应，既要响应网卡的中断，又要响应业务的需求，这个非常的繁忙，怎么解决？把这个网卡中断绑定，转到其他CPU上，达到负载均衡。第二个是TCP RTO修改，我们用2.0的系统内核，默认的只是200毫秒的，如果200毫秒出现超时重传，但是网络延迟比较大的，200毫秒的话，会经常会出现重传，会很频繁的重传，会导致协议站的性能会降低，所以我们就在内核系统打了补丁，改为3秒左右，性能会得到一部分的提升。

         负载均衡

         LVS做负载均衡，存在单点问题

         客户端做负载均衡

         LVS对IP列表进行排序，负载小的在前，客户端拉取IP列表；断线重连的解决方案是对IP分区发送探测包，使用第一个返回的IP

         服务器端做负载均衡

         针对客户端的选取策略，服务器端根据本身的复杂做探测包响应的发送延迟