个推消息中心如何实现多渠道消息智能下发？

目前，各行业的数智化进程如火如荼，企业对数智化用户运营的需求日益旺盛；同时，在万物互联的5G时代，用户触达的渠道也变得更加丰富。企业需要更高效、智能的方式进行用户触达管理。基于此，个推将多年来积累的数字化运营经验和用户触达能力相结合，打造了“消息中心”系统产品，能够帮助企业客户将APP通知栏消息、短信、微信、钉钉的系统消息、智能人工外呼、5G消息等行业八大主流用户触达渠道进行有效整合和管理。

个推消息中心技术架构

本文从技术角度解读“个推消息中心”如何实现多渠道消息下发的智能管理。

一、用户触达的三大范式

个推在消息推送领域有十余年的实践经验，一直深度服务于企业消息管理的一线，深刻理解各行业客户在消息管理和用户触达方面的差异化需求。通过总结大量的消息下发模版，对数十个行业场景的特征进行整合，个推最终抽象出消息在多渠道的流转过程和模式，形成了个推消息中心开展用户触达的三大基础范式：并发消息、补发消息、分发消息。

1、并发消息

并发消息是指实现特定消息在多渠道的并行下发，适用于重要消息的大规模群发。比如，银行在开展某次运营活动时，采用APP消息推送+微信+短信等多渠道为用户推送活动优惠通知。

个推消息中心-并发消息处理流程

2、补发消息

为了提升消息的到达率，企业会对未触达的用户进行消息补发。比如，很多银行会选择将手机银行消息推送作为发送动帐通知的主渠道，在手机银行推送消息未到达时，再采用短信下发的方式通知客户。

个推消息中心-补发消息处理流程

3、分发消息

根据消息内容和想要触达的用户群不同，企业会通过不同渠道下发不同的消息。比如，很多银行在发送动帐通知时，会通过微信来发送200元以下的小额交易动账消息，而针对200元以上的大额交易动账则会选择短信的方式来通知用户。

个推消息中心-分发消息处理流程

个推消息中心依托用户触达的三大范式，打通了消息从产生、过滤、规则匹配、高效下发、海量消息保存以及最终展示的全链路，是一个集消息下发、精准匹配、效果追踪、数据统计等功能于一体的平台性产品。

个推消息中心能够根据下发规则对消息、渠道和用户群进行自动匹配，实现智能推送。相比传统的单渠道推送，个推消息中心不仅能够通过并发、分发、补发等方式实现更高的消息到达率；还能够帮助企业更加科学地管理渠道资源，大幅减少短信费用和外呼成本，提升用户运营效率。

二、个推消息中心的技术实现

同时，个推消息中心实现了对复杂的目标客群进行有效管理，能够满足金融、融媒体等行业客户对大规模消息实时下发、海量数据存储等方面的能力要求。

1、复杂目标客群管理

个推消息中心提供了一套统一的客户通道关系存储体系，能够将各个通道的用户体系和客户方自身的用户体系对应起来，实现了复杂目标客群的有效管理。由于客户方系统的用户体系和业务形态非常复杂，可能是1对1、1对N、N对1、N对M等对应关系，因此个推消息中心采用“N对M”为基础存储结构，并提供灵活配置的客群管理模块以支持企业进行不同类型的客户通道关系管理，满足了绝大多数企业用户的需求。

2、高并发消息下发

在类似“618”“11.11”等特殊的营销节点或运营活动期间，企业往往需要在几分钟之内完成数百万甚至千万量级消息的批量下发。这就要求消息中心系统必须具备数万QPS的消息下发能力。我们做了如下处理，以满足企业客户对系统性能的要求。

减少Redis操作

个推消息中心中，对客户通道关系的正向和逆向转化关系的读写需要严重依赖于系统的Redis。所以，额外新增的Redis操作逻辑过多会给Redis集群带来较大压力，从而对原先单渠道推送的性能产生影响。这就要求我们将业务流程中非必要的Redis操作消除。我们首先整合了Redis存储value的内容以减少Redis的读写次数；同时，用其他设计方案以代替Redis操作，例如：我们去除了依赖于Redis的分布式token存储方式，而采用其他的安全方式进行安全校验，以减少Redis集群的压力。

隔离

✦1）业务隔离

不同类型的推送任务对系统的资源占用和要求不同。比如，全推、标签推、分组推等推送任务要求系统在短时间内下发数百万甚至数千万条消息，会占用较多的资源，给系统带来较大冲击，从而对单推、列表推等实时性较高的消息下发任务产生较大影响。所以我们对不同类型的推送任务进行了业务上的隔离，以保证系统及时响应和处理优先级更高的推送任务。

✦2）存储资源隔离

同时，我们将关系型数据库里的数据根据业务特点及数据规模进行分库，保证核心功能不受边缘功能的影响；并将Redis集群隔离，划分多个Redis集群，防止单个Redis故障对整个系统产生重大影响，保障系统的稳定运行。

分布式任务调度

其次，我们将全推、标签推、分组推等规模较大的推送任务拆分成一个个小任务，并由分布式任务调度系统统一调度，由整个推送集群共同处理任务请求，以保证大批量消息的及时下发。

异步处理

消息中心推送流量往往具备流量大、波峰波谷差异巨大等特点，因此我们采用MQ、日志异步落库、异步RPC等形式，尽量避免了系统的阻塞，从而达到较高的QPS。

3、海量数据的存储能力

系统在运行的过程中必然会产生数据，并需要对相关数据进行计算和存储。个推消息中心系统需要存储的数据主要有三大部分

✦ 客户通道关系、消息下发计数等数据。在高QPS和高实时性的推送需求下，我们必须将此类数据（数量级在百万乃至亿级）存储在缓存中以提升系统性能。

✦ 消息下发任务数据。个推消息中心需要对每个任务的详情以及每个任务下消息的到达、点击、展示等各类明细数据进行存储。此类数据目前日增量在百万及千万级不等。

✦ 部分业务方要求长时间存储的消息详情。这部分数据往往日增量在千万级到亿级不等，存储时间从半年到永久不等，且要支持较快的查询及较高的QPS。

我们采用以下方式解决海量数据存储的问题：

1）Codis集群
针对缓存数据，我们构建了分布式Codis集群，采用代理+分片的形式对Redis进行扩容。以支持TB级系统缓存数据的存储。

2）关系型数据库分库分表（MySQL和Oracle）
由于客户的统计需求变化多样，目前消息中心支持从用户、模版、通道、任务等多维度对推送任务进行统计。我们以日维度+分库分表的形式存储了所有推送任务信息的详情，支持了从用户、模版、通道、任务等维度较为实时的统计。

3）HBase
HBase是一个分布式的、面向列的开源数据库。具备高可靠、高性能、存储空间几乎可以无限扩展的特点。我们采用HBase来存储历史消息，使系统可以支持PB级数据的存储及数万QPS的用户维度消息查询并发能力。

总结

本文对个推消息中心的技术实现进行了介绍。个推消息中心能对下发的消息进行统一调度、精细化管理，尤其是对于未触达的用户可以进行多渠道的补发、并发，协助客户形成高转化的投放策略。同时个推消息中心具备高并发、高可靠等性能，能够很好地满足行业客户的运营需求。

个推“消息中心”采用私有化部署，可根据客户具体需求进行个性化定制，已经服务于银行、融媒体等多家行业客户。