作者：甘恒通，2011年加入腾讯TEG数据平台部，主要负责大数据平台、推送平台后台的研发和优化工作，对构造高可用、高性能的分布式大数据处理和推送系统有丰富的实战经验，近期工作内容是构建信鸽精准推送系统，包括智能分群、实时推送、实时推送效果跟踪，解决公司内外部对推送质量和需求。
我分享的主题是腾讯信鸽海量移动推送服务的构建，在加入腾讯TEG数据平台部后，我主要从事大数据相关的一些系统和应用开发。最近一两年主要是构建腾讯云推送，也就是信鸽这个系统。对于消息推送来说，它是触达移动用户的一个很重要的方式，基本上是每个应用必备的能力。然而受限于整体的终端环境、网络环境和后台的服务能力，如果想要做到百亿级别的消息推送以及推送后的效果跟踪，还是有不小的技术挑战。再进一步来说，如果只给用户提供感兴趣的内容，做到精细化的运营，又需要在数据和机器学习平台上有深度的积累，引入BI的能力。
推送系统建设
第一部分是关于推送系统的建设，主要有三个子块，终端、后台、云化治理。第二部分的内容是增值服务，包括精准推送流程、数据、基础支撑平台、可视化操作。对于消息推送来说有三个主要环节，第一个环节是先检索出我们需要推送的目标用户，第二步是选择合适的通道进行消息的分发，最后是终端收到消息后进行展示。对于移动推送服务来讲，最基础的是需要做精做细，在终端、后台、数据服务这三个层次。
不同的业务对推送有不同的诉求，比如新闻类的业务。热点新闻的推送需要追求时效性，对于腾讯这种体量的公司，往往意味着亿级或者数十亿级消息的推送能力。一般推送消息后想要看到实时的推送效果，以便及时调整运营的策略。百亿级别的消息推送，有不少的计算量，需要构建一套实时统计的系统，支撑海量数据的分析。结合不同的用户做精细化的运营，又需要我们在数据和基础的算法平台上有深度的积累。下面我将结合信鸽的推送系统，逐一和大家介绍这些相关的经验。
终端
对终端来说主要的挑战有以下两点，一是service的保活，最关键消息的抵达率。对于消息的抵达率，如果设备已经直接对接厂商通道，对于消息推送，抵达率是一个很关键的指标，如果设备有厂商通道，直接使用厂商通道，信鸽目前已经对接了小米、华为、魅族等厂商通道，对于没有厂商通道的设备，需要进行终端 Service 保活。终端 Service 保活。朴素的做法，是为每个 App 起一个独立Service、建立一个长连接。这种方式实现相对简单，但是对用户来讲，会消耗更多手机的资源。信鸽移动推送为了兼顾服务质量和用户体验，使用的是共享通道的方式，更加省电、省流量。信鸽服务了公司内外很多大体量活跃 App，这些 App 能够有效提升 Service 存活率。这将消耗用户的很多资源，如网络流量等。对于腾讯来说，我们既服务了公司内部，又同时服务了公司外部一些拓扑的应用，有效提升了service的保活。
第二是终端发布后运营的能力。首先是建立云端调度能力，也就是需要终端和后台一起配合，建立一个云控通道，实现用户无感知的配置下发或通道切换的能力。第二点是关于准确的统计数据上报，对于消息推送来说，推送完之后既有正向效果也有反向效果。如果想要采集到这些准确数据的话，还应该注意不少细节。比如终端的设备是否真的打开了推送权限，在目前的环境下，各厂商没有一个统一的接口来访问到这个状态。另一方面，即使用户打开一个权限，消息到达终端后调用系统的展示接口，最后是否真的展示给用户，也受制于不同的机型。针对这些情况，我们都需要深入了解终端的环境，然后做一些更细的优化。
第三是关于终端的服务、质量、监控。我们构建了一套从Crash上报、报警、在线修复的Crash平台，严格保证终端的质量。
后台
接下来主要介绍后台的经验。下图是信鸽整体的技术架构图，包含了终端、接入层、后台逻辑层，存储、数据分析平台、消息网关这几大部分。对于数据分析平台来说，给用户提供了实时的效果跟踪、多维分析的能力。整套系统构建在Docker云化基础之上的。经过这一两年的建设，信鸽现在基本初步形成了一个高性能、架构可伸缩、易于运维的系统。
下面我们来看一下后台的业务流程。比如一个电商APP想要在晚上八点的时候给广东省的男性用户做一个促销，需要借助信鸽做一次推送。图片的上半部分是用户可以看到的一些具体推送类型，包括单推、全推、标签或者用户分群。最下面是接收到消息的这些设备，里面包含了国内一些主流的厂商如华为、小米、魅族，以及国外的苹果等，另外还有未提供厂商通道的设备。中间是后台具体实现推送的逻辑，推送后经过一个数据上报的通道，进行数据的统计。
信鸽是一个典型的分布式系统，涉及的技术栈是比较深的。对于分布式系统我们可以讨论的东西非常多，比如性能、数据的安全性、怎么去容灾、怎么做水平的扩展、怎么做伸缩性。由于时间关系，我今天主要讲两点。一是关于性能，怎么推的更快。二是效率，主要关于怎么改善运维效率。
首先看一下如何让消息推得更快。对推送来说有两个最重要的逻辑，一是检索出我们需要推送的目标人群，二是筛选合适的通道进行推送下发，这是一个典型的工程上的实现。这个工程上的实现其实可以转化为一个标准的析取范式，这样我们就把一个工程问题映射成一个数学问题。这两个过程如果用传统做法，传统做法，数据逐层下漏，容易形成瓶颈。而这个过程，映射成数学问题，很像一个 A 并 B 交 C 的过程。我们把这个公式做个等价转化，变成 A 交 C 并上 B 交 C。最外层是并集，我们就可以把各个子集分布式处理。为此我们构建了分区位图的系统，可以进行实时分布式的人群筛选和通道路由的操作。线上，单机可以在几百毫秒内完成亿级用户的通道筛选和人群检索的操作，从根本上消除了这两大部分的瓶颈。
完成人群检索和通道路由后，接下来是执行批量的消息下发。这里的核心逻辑是找到推送设备和后台接入机建立长连接的ip 和 端口信息， 这个信息最简单的是存储在一个集中式的CKV（Nosql，类似Redis）数据库里。这个信息最简单的是存储在一个集中式的CKV数据库里。这个核心逻辑又可以切分成两个环节，第一个就是对于消息上行这一部分，我们要保证注册的成功率。第二个是消息下行这部分，我们要解决在推送高峰期中心存储面临百万级别以上每秒高并发的访问，这个节点的高负载会制约时效性和推送的成功率。
下面我们分两步看看如何解决这两个问题。首先对于上行这一部分，终端和后台建立长连接，终端就近接入，也规避了运营的风险。前面有一个统一的接入网关和容灾的切换，具体消息上来之后，采用轻重分离的模式，也就是这里的接入层只负责维持长连接，其它逻辑全部后置。前端节点只负责简单的建群逻辑就可以返回，其他的消息可以后置，由其它的节点进行处理，这样可以明显提高我们注册的成功率。
消息下行这部分有一个核心的push节点，优化方案是把原本中央存储的数据进行分区缓存，缓存规则是基于设备ID做边界的一致性hash，消息下行和注册上行采用相同的一致性hash算法，这样设备注册上来的时候，IP和端口的信息就可以实时落地到固定的一台push节点上。真正需要推送的消息下来的时候，从cache就能查找到需要下行的接入机的信息，根本上也消除了对中央存储的依赖。这个push节点还有一个cache manager服务，可以灵活配置对失效缓存的清理。
对于推送效果实时统计，百亿级的消息推送再和用户画像进行关联，计算量还是不小的。对于分布式计算来说，最重要的就是减少数据量，也相应减少了网络存储量和最后的计算量。这里我们采用两个步骤来进行数据极致的压缩，一是构建了一个全局的唯一ID生成系统，也就是做文本数字化的操作，把设备的标识、用户的标识或画像的数据全部转化成一个map的存储。二是自适应压缩存储的数据结构，经过这样的转换之后就支持了海量数据实时的统计分析。
然而，固化的数据统计指标不能满足所有的业务场景，对于一些个性化的统计分析需求，我们又构建了一套多维的实时分析系统。在原有实时统计分析的基础上，构建了一个为图矩阵，实时做到数据上传和下载的操作。最终我们也支持了这种千亿级别的交互式的实时多维数据分析。我们也形成了一个比较完善的数据分析平台，这个平台涉及到用户或者设备画像的一个积累。底层是设备，上面是计算层，最后是一个可视化的报表呈现。这样整体上就减少了运营分析的成本，提高了效率。信鸽在整个系统上也可以构建一些精准营销的能力，比如说用户分群或者归因分析等等。
云化治理
海量推送系统涉及到的子系统是非常多的，相应的运维工作量或者说挑战性也是非常大的。经过一两年的建设，信鸽的运维也跟随业界的发展，从传统的运维流程走向一个Docker镜像的持续集成，然后发行一个DevOps的流程，采用MySQL作为静态或动态的配置中心，整体的开发流程变成面向云的一个研发体系。做了这个转换之后，我们的版本发布效率也从传统的几个小时，缩减到了分钟级别。
面向云的研发体系，除了提高研发版本的发布效率外。另一方面我们可以为整个系统涉及到的相关人员，包括开发、测试、运维，分别给他们构建静态或者动态的配置中心，还能解决下面三大类的问题。一是保证版本的一致性，减少传统地通过手工进行版本打包、解包的过程所带来版本不一致的问题。程序的发布包放在镜像里面，镜像里只包含可执行这个程序，同时对这个程序目录结构进行标准化。具体实粒启动的时候可以通过环境变量指定到具体的配置中心，完成静态配置下发到一个固定的配置目录。二是解决环境隔离的问题，也就是不同的人员可以根据自己的需要，在自己的配置中心里进行灵活版本的配置定制，同时可以很方便地追溯到版本配置的情况。三是解决物理机器资源有限的情况，利用虚拟化的技术，我们的资源不再受限，开发、测试人员可以并行进行编译或者测试的工作。
关于信鸽的推送服务后台这一部分，主要包括两点。一是性能，通过优化数据结构，同时采用分布式的缓存，解决了性能的问题。二是结合Docker镜像做了一个面向云的研发体系，解决了运维的效率问题。
信鸽的增值服务
下面为大家介绍一下信鸽的增值服务。首先，从精准推送服务进行切入，对于精准推送，有下面几个阶段：规则引擎、过滤、预估模型、深度学习、在线学习、迁移学习。往往实际过程中是多个模型进行混合使用，比如深度学习解决复杂场景，在线场景解决时效性的问题。
对于精准推送的一个基本服务流程，简单来说就是给合适的用户在合适的时间和地点给他推合适的内容。关于精准推送，过程和算法都有比较多可以借鉴的地方，但有两个环境是需要长时间的建设和积累。一是数据，我们需要构建多维的用户画像的数据，二是关于完善的机器学习平台的搭建。
首先我们先看一下数据部分，腾讯本身有广泛的业务线，涵盖了游戏、社交、文化、电商等等领域。对于我们来说，通过帐号体系，PGM这个模型来关联数据的孤岛，用户侧的数据是有一定的随机性。通过数据分析提炼价值，提高准确度。比如通过用户关系链修正用户的年龄等，最后输出标准化的数据。经过多年时间的积累，形成了腾讯自己独有的多维海量的数据资产。
经过多年的建设，我们得到了一个完善的分布式计算和机器学习的基础支撑平台。这个平台里面涵盖了存储、资源调度、计算、应用这么几个层次。在这里，我们主要还做了一个可视化的机器学习平台，它能大大地简化我们对机器学习的使用门槛，支撑了精准推荐，OCR、自然语言处理等具体的应用场景。
左图是BRNN算法的原理和示意图，如果要完整理解这个算法，同时搭建一个分布式系统实现这样算法模型的话，还是有很大的挑战。右图是基于特斯拉的一个可视化的机器学习平台，只要通过简单的拖拽就能实现这个过程，大大简化了我们的使用成本。
讲到这里，我们可以看到这是一个信鸽推送的完整技术解决方案。其中包含了分布式系统的搭建，对于数据的一些积累，包括我们构建的数据分析平台、机器学习的平台。信鸽本身已经可以做到一个集消息推送、数据分析、数据运营、商业智能为一体的推送服务，并开放给大家使用。
举个例子，如何来提升游戏的留存？
- 第一步，通过可视化机器学习平台，配置算法模型，圈选出目标用户。
- 第二步，通过数据分析的平台，归因分析出可能流失的原因。
- 第三步，用信鸽推送做用户的精准触达。
- 最后，信鸽可以作为一个桥梁，用来连接用户、平台、流量、资本，它能大大地减少开发者的成本，提升接入的效率。
信鸽作为一个推送服务，现在已经集消息推送、数据分析、数据运营、商业智能于一身。后续我们会更加努力，将这项服务做得更好。
Q/A
Q：推送目标用户的筛选以及做分布式的原理，刚才简单说了一个集合运算的分配定律。这种筛选对筛选字段的限制，因为我现在有一些业务它的筛选规则非常复杂，我想知道信鸽系统在处理这种需求的时候，有没有一些更具体或者更深入的思考？
A：业务场景肯定都是非常复杂的，这里面最基础的，就是要定义好我们最基础的数据存储的力度。这里面数据存储的力度，比如刚才的逻辑，我给广东省男性用户，这是一个最基础的逻辑，但可以后面加更多的逻辑，比如近三天活跃的、登陆过首页的等等这些业务逻辑。这些业务逻辑，其实可以统一映射成一个标签，所以说基于标签来维护这种最底层的数据存储，最后你的业务逻辑无非是这些标签的“与”或“非”的运算。
Q：我想知道对于不同的标签，系统在处理它们时的效率有没有区别？
A：没有区别，是亚毫秒级别的，多个标签之间最多是毫秒级别，同时可能和业务体量有关系。我们做的都是基于亿级用户测试的，亿级用户也是毫秒级别，而且是单机。
Q：您刚才介绍下发通道有厂商通道、自建通道，有的手机没有厂商通道只能用自建通道，但有些情况下自建的服务通道是不能使用的，但微信在这些方面就可以生效，我想了解信鸽方面的通道和微信通道有没有融合的趋势？
A：首先微信，包括手Q，跟推送是两个不同的领域。虽然看起来很像，微信、手Q叫IM即时通讯，信鸽叫消息推送，是两个不同的业务场景。对于底层的通道，微信和手Q几乎是每个手机默认的白名单用户，一个手机可以收不到别的应用推送的消息，但绝对不会收不到微信和手Q的消息。
Q：微信和手Q在厂商通道方面未来会不会有融合的趋势？
A：不会，因为微信和手Q不会因为一个应用而影响它的质量。
