0 引言

地震预警系统(Earthquake Early Warning System，EEWS)可以在破坏性地震波到达前几秒到几十秒发出预警信息(Allen et al，2003)，是能够有效减轻地震灾害的重要技术手段之一。地震预警系统需要在破坏性地震波到达前，以最短的时间延迟，及时将预警信息推送到地震周边一定范围内的公众和相关企业政府用户(Hoshiba et al，2008)，达到紧急避险和决策应对的目的。相关研究表明，预警时间为3s可使人员伤亡减少14%，预警时间10s可使人员伤亡减少39%，预警时间20s可以减少高达63%的人员伤亡(夏玉胜等，2000)。目前地震预警系统已经在全球多个国家进入试运行或实际运行，如日本铁路的UREDAS(Urgent Earthquake Detection Alarm System)(Kodera et al，2021)、墨西哥的SAS(Seismic Alert System)(Suárez et al，2021)和美国的Elarms(Earthquake Alarm System)(McBride et al，2020)。预警信息的快速发布是整个地震预警系统在社会服务中的重要体现(蔡寅等，2019；申源等，2024)。国外应急信息的发布主要采用小区广播技术(Axelsson et al，2007)，如美国的商用移动警报系统CMAS(Commercial Mobile Alert System)、无线紧急警报系统WEA(Wireless Emergency Alerts)(Ngo et al，2011)以及日本的地震海啸预警系统ETWS(Earthquake and Tsunami Warning System)(Musa et al，2013)等。目前地震预警发布主要通过预警专用终端、应急广播和短信等方式来实现(Wang et al，2021)，其时效性和覆盖范围有限，尤其是短信的时效性短板非常明显。如美国Elarms系统受限于并发能力，仅推送延时就在3.5s以上(McBride et al，2023)，而基于目前的手机APP信息推送技术，推送能力在数万每秒至十万每秒(张盼盼，2020)，用户基本在数秒甚至分钟级才能收到预警信息，对于发生在人口密集区域的破坏性地震，采用这种方式使得预警信息无法及时推送到震中附近人员。

信息推送技术主要分为PULL和PUSH技术(Kiziltas et al，2010)，相关研究表明在推送时效和资源使用效率方面，PUSH技术更适用于预警信息发布场景(Minnebo et al，2014)。随着移动终端的不断发展，面向移动终端信息推送技术的相关研究和应用也得到了较大发展(Kweon et al，2014)，如谷歌的C2DM(Cloud to Device Messaging)(Doriya et al，2015)和苹果推送通知服务APNS(Apple Push Notification Service)(景洪水等，2014)，但其实时性和适用范围有限；很多第三方推送技术也得到了大范围应用，如极光推送、个推推送等。传统推送方式会将所有用户信息维护在服务端的用户平台，根据用户在线/离线状态、黑/白名单、地理位置等一系列信息进行信息推送，集中式的用户管理使得用户筛选和路由寻址成为系统瓶颈(翟成彤，2019)。千万级用户量推送可能需要几十秒甚至几分钟，目前今日头条用户数量4.5亿、腾讯新闻用户数量6亿，每个推送平台的推送速率约为20万用户/秒(何凯等，2016)。在日本“3 · 11”9.0级地震中，已经暴露了存在预警信息发布延时较大的问题(Fujinawa et al，2015)，如果用户量进一步提升，耗时还将线性增长，因此需要设计一种全新的推送模式和去中心化的分层网络技术架构(汪科等，2022)，来解决海量信息高并发定向推送的问题。

本文主要在以下两个方面开展研究：

(1) 研究并实现面向预警场景的信息推送分层级联广播技术架构。按中心节点、区域分中心节点、消息分发节点、设备连接节点等多层结构实现系统分层级联，各层级采用广播分发方式进行地震预警信息并行发布；

(2) 提升单服务器推送性能和级联推送线性增加服务器的稳定性。通过高速缓存Redis、消息中间件等技术框架以及CPU核心绑定等技术进行性能调优，实现系统高可用性和动态扩容能力。

1 海量信息高并发分层级联广播技术 1.1 传统推送技术对比

推送技术的应用对于服务器端的性能是一个极大的挑战，系统不仅要处理大量用户的并发连接，还需要处理海量的信息，负载过高会导致信息下发延时明显增大(阮伟标，2017)。传统信息推送架构(图 1(a))是将所有用户信息维护在服务端的用户平台，查询所有用户以及判断用户信息较为耗时，千万级用户量可能需要几十秒甚至几分钟。本文研究的分层级联广播并发技术(图 1(b))通过分散连接移动终端设备，采用边缘计算技术，利用“去中心化”的思路，将原先整个用户平台的存储压力和查询压力分摊到每个客户端连接管理器实例(CM)上，可以大大减少查询导致的时间损耗，实现更快的网络服务响应，实现预警消息快速分发，并采用Zookeeper进行分布式集群管理，通过单服务器多CM部署进行CPU核心绑定，实现并发性能优化，提高消息分发的吞吐率。本研究主要使用的符号和描述见 表 1。

1.2 高并发分层级联广播设计

本文设计的分层级联广播架构主要模块包括：推送管理平台(Push Manager System，PMS)、级联广播中心(Cascade Broadcast Center，CBC)、客户端连接管理器(Connection Manager，CM)，整个级联广播架构的主要核心为CBC层级模式(图 2)。CBC模块依赖高速服务框架(High-speed Service Framework，HSF)，建立与次级CBC之间的远程过程调用框架连接。上级CBC在启动时将服务注册到集群后，通过内部HSF框架监听暴露端口，等待次级CBC连接握手请求，次级CBC同样通过HSF服务启动注册到集群后，主动向上级CBC发送连接握手请求。上级CBC在监听过程中接收到消息，之后开始建立与次级CBC之间的HSF(TCP)连接。在次级CBC成功连接到上级后，上级CBC将会在静态缓存会话表中以次级CBC的集群名作为节点标志。

PMS为用户提供创建地震消息并发布推送的界面入口和API入口，如 图 3所示。CBC采用级联广播技术理念，分为四层级联广播结构，第一层为cbc-start，负责接收PMS的地震预警消息并广播到所有IDC(Internet Data Center)机房；第二层为cbc-idc-start，作为当前IDC机房机内CBC广播中心的入口，接收到cbc-start的消息后开始在本机房内开始级联广播；第三层为cbc-region，作为级联广播的中转节点；第四层为cbc-region-secondary，收到广播消息后向下发送到CM。这样就将信息推送由单线程推送扩展到多线程并联推送，极大地满足亚秒级下发的技术要求。由CM缓存用户信息，每个CM都维护了各自连接用户的信息。具体推送步骤为：

(1) 获取目标消息(Task)对应的目标识别码(TaskID)。

建立目标分发系统，目标分发系统包括：L个分发层级的广播中心模块和第L分发层级中广播中心模块对应连接的配置管理模块，其中，L指目标分发系统分发层级数，第i分发层级的广播中心模块的数量为X_i(i=1，2，…，L)，X指任一分发层级与下一分发层级之间的目标模块的连接数量，所述目标模块是指可连接到的下一分发层级中广播中心模块或者配置管理模块，并可以表示每个子集CBC实例所包含的数量。因此，对于第i层CBC实例，所包含的CBC实例数量m_CBC为m_i=X^i-1，则整个级联系统中所包含的CBC实例总数M_CBC为

$ M_{\mathrm{CBC}}=\sum\limits_{i=1}^L m_i=X^0+X^1+X^2+\cdots+X^{L-1} $

(1)

例如在本文的测试集群中，令L=3，X=2，则M_CBC=7。

(2) 获取目标时间列表T=(T₁，T₂，T₃，…，T_i…，T_Lo)，其中，T_i=X₀ⁱ×t，X₀ⁱ指用于构建所述目标分发系统对应的X，t指所述目标分发系统中任一分发层级向下一分发层级发送消息所需的时间，Lo指X₀对应的目标分发系统的层级数。

则对于一个有L层的集群，总共需要下发的链路为L-1层，则集群的整体消耗时间为

$ T_{\mathrm{CBC}}=t(L-1) $

(2)

(3) 为了更好地平衡分发层级数量和整体广播耗时，将目标分发系统分为每层连接的目标模块数量可变的第一单元和每层连接的目标模块数量固定的第二单元。遍历T且当T_i大于等于预设的时间阈值T₀时，将所述目标分发系统划分成第一单元和第二单元；所述第一单元包括第一分发层级至第i-1分发层级的广播中心模块，其中，任一分发层级中单个广播中心模块与下一分发层级中X^m个广播中心模块连接(m=1，2，…，i-1)；所述第二单元包括第i发层级至第L分发层级的广播中心模块，其中，任一分发层级中单个广播中心模块与下一分发层级中X个广播中心模块或者配置管理模块连接。例如，在一个5层的分发系统中，前3层中每个广播中心模块均与下一分发层级中10个广播中心模块连接，后2层的分发层级中每个广播中心模块均与下一分发层级中2个广播中心模块连接，这样一方面减少了整体的层级数量，另一方面又控制了每一层的分发时间。

(4) 基于所述第一单元和第二单元，将所述目标识别码逐级由分发层级发送至客户端CM。在本系统的级联框架中，CM与底层CBC之间可以为一一对应关系，也可以为多对一对应关系。当采用一一对应方式时，则底层CM的数量m_CM为

$ m_{\mathrm{CM}}=m_L=X^{L-1} $

(3)

(5) 已知在消息下发前，已有SDK与CM建立TCP长连接，且由于负载均衡模块作用，每个CM模块维护的长连接数量大致相同，因此可以统一设每台的SDK连接数量为m_SDK，则SDK总数M_SDK为

$ M_{\mathrm{SDK}}=m_{\mathrm{SDK}} \times m_{\mathrm{CM}} $

(4)

在TCP连接场景下，CM作为服务端需要将SDK的长连接通道信息缓存在内存中，并从内存中轮询长连接通道，将连接信息放到线程池中进行批量下发，这里需要结合定向推送技术，按照震中区域距离进行优先推送。假设线程总数为n，耗时为t_SDK，耗时主要为网络延迟，网络延迟整体服从泊松分布，即

$ P(X=k)=\frac{\lambda^k}{k!} \mathrm{e}^{-\lambda}, k=0, 1, \cdots, n $

(5)

其中，已知其期望为λ，即认为网络延迟均值为λ，CM实例之间为并发关系，因此宏观上认为整体耗时分摊到所有CM实例，因此，整体网络耗时为

$ T_{\mathrm{SDK}}=\frac{m_{\mathrm{SDK}} \times m_{\mathrm{CM}} \times \lambda}{q m_{\mathrm{CM}}}=\frac{\lambda m_{\mathrm{SDK}}}{q} $

(6)

根据以上系统架构，整体的系统耗时可以表示为

$ T_{\mathrm{ALL}}=T_{\mathrm{CBC}}+T_{\mathrm{CM}}+T_{\mathrm{SDK}}=t(L-1)+t+\frac{\lambda m_{\mathrm{SDK}}}{q}=t L+\frac{\lambda m_{\mathrm{SDK}}}{q} $

(7)

而对于传统架构，不存在级联系统，因此可以认为上述公式中L＝1，SDK仅依赖负载均衡分散分布在不同的CM集群上，而在区域广播架构中，SDK会依据Geohash序列分布在就近的CM集群上，并负载均衡。相对于前者，可以认为传统推送架构的SDK网络消耗会比区域广播高。

因此，可以将传统架构的耗时表示为

$ T_{\mathrm{ALL}}=t+\frac{\lambda^{\prime} m_{\mathrm{SDK}}}{q}\left(t^{\prime} \approx t L, \lambda^{\prime}>\lambda\right) $

(8)

若令T_ALL＜T_ALL′，即

$ t L+\frac{\lambda m_{\mathrm{SDK}}}{q}<t^{\prime}+\frac{\lambda^{\prime} m_{\mathrm{SDK}}}{q} $

(9)

$ t L-t^{\prime}<\frac{\lambda^{\prime} m_{\mathrm{SDK}}}{q}-\frac{\lambda m_{\mathrm{SDK}}}{q} $

(10)

$ \frac{q\left(t L-t^{\prime}\right)}{m_{\mathrm{SDK}}}<\lambda^{\prime}-\lambda $

(11)

由于本文目标以千万用户进行广播，因此显然可得$ \frac{q}{m_{\mathrm{SDK}}}$要远小于1，而上述前提满足t′≈tL，λ′ >λ，因此不等式成立。即认为，当区域广播的网络不成为整体系统负担时，在千万用户的场景下级联广播比传统广播模式更具优势。

2 区域定向优先广播技术

区域内用户消息推送技术称为基于移动位置服务(Location Based Services，LBS)(Biswas et al，2022)，可通过手机型号定位、物联网物理围栏等技术实现。该技术的运用场景与地震预警区域定向推送的区别在于：①LBS技术一般用于固定的地理围栏(Geo-fencing)，继而等待用户进入围栏触发场景用例，而地震预警区域定向不会在推送前得知围栏范围，因此两者在用户地理信息的维护和区域搜索算法上有较大区别；②在地理围栏技术中，一般围栏均是多边形，由于区域复杂，为了加快算法，更多作用于小范围的商圈判定，而地震预警区域一般很大，使用类似搜索方法会增加大量耗时。

这里借鉴了LBS技术中运用到的GeoHash技术(图 4)，GeoHash编码具有如下三个特点：①GeoHash用一个字符串来表示经度和纬度两个坐标，在数据库中可以实现在一列上应用索引，降低开发维护的成本与难度；②GeoHash表示一个矩形区域，可以合理利用用户的地址编码，既能明确用户的位置，又不至于暴露其精确坐标，有助于用户的隐私保护；③编码的前缀可以表示更大的区域，字符串前部相似的部分表示距离相近，从而可以设计相应的位置匹配算法。

GeoHash将地球表面按经纬度划分为相等大小的多个区域，将各区域进行编号。由 图 4可知，区域划分越细，编号越长。具体计算方式为：根据划分位数n得到横排长度x和纵排长度y，以此计算经纬度位于哪一格，并推导出该格的序号，即

$ \operatorname{GeoHash}={Hex}\left(x_i\right)+{Hex}\left(y_i\right) $

(12)

$ x_i=\text { latitude } \times \frac{x}{180^{\circ}} $

(13)

$ y_i=\text { longtitude } \times \frac{y}{360^{\circ}} $

(14)

具体推送步骤为：

(1) 获取目标地理区域对应的网格列表B=(B₁，B₂，B₃，…，B_q…，B_p)，其中，B_q指第q个网格，q=1，2，…，p；p为网格数量；

(2) 获取客户端位置列表A=(A₁，A₂，A₃，…，A_r…，A_m)，其中，A_r指第r个客户端ID对应的坐标值，m为客户端ID的总数量；

(3) 遍历A且当A_r处于B_q内，将A_r对应的客户端ID插入至B_q对应的多个目标客户端列表内，其中，任一目标客户端列表C=(C₁，C₂，C₃，…，C_k…，C_Y0)，C_k指第k个目标客户端ID，Y0指单个配置管理模块连接的客户端ID数量；

(4) 获取目标消息的目标坐标值，将所述目标消息对应的目标识别码发送至目标区域对应的客户端，具体包括如下步骤：当所述目标坐标值处于B_q内时，基于B_q和B_q相邻的网格构建目标区域，从所述目标区域中每个网格对应的数据库中提取若干个C，将所述目标识别码以逐个目标分发系统的分发层级发送至每个C中的目标客户端ID。

3 实验验证 3.1 单点性能测试

通过单台服务器部署单CM实例的性能测试评估性能瓶颈。由于测试环境从CBC到CM端，没有外部网络延时的影响，为评估其影响，收集了推送的预警信息网络延时，发现绝大部分都在500ms以内，但由于其数量较少，本研究还对每日互动公司从CM端推送到实际用户的170万条数据的延时进行了统计分析(图 5)，由图可见90%的消息耗时在200ms内，96.76%的消息耗时在500ms内，该时延范围与相关网络时延统计基本一致(杨振辉等，2018)。因此，为了实现秒级预警信息下发，测试环境下从PMS到CM的耗时需要控制在500ms以内，这样便可为信息向外推送留出足够的时间。具体测试步骤为：

(1) 在单机器环境下，部署一个CM实例，从10000连接数开始，按每次5000连接逐渐提高连接数，测试CM在500ms下的峰值性能。

(2) 基于测试步骤(1)中得到峰值连接数，在单机环境下，以同样的连接数扩展多台CM，测试单机环境下且不影响整体性能的情况下，最多能同时部署多少CM实例。

(3) 基于测试步骤(2)中得到的CM实例部署情况，以同样的CM实例数和连接数，扩展多台机器，测试多机器部署是否会对整体性能产生影响。

3.2 级联性能测试

随着下发信息量的增加，单台服务器单CM实例的延时整体呈上升趋势(图 6(a))。测试数据取10次实验的平均值，在500ms以内能够支撑的最大连接数约为6万，但部分实验的耗时超过500ms，因此综合考虑多次实验结果，选择5万作为单个CM实例可接受时延下的最大连接数。当单个CM实例下发5万条消息时，需要占用4~6个CPU核心，故在32核机器上最多可部署5个CM实例(图 6(b))。据此，以5万连接作为单个CM实例的峰值性能，在单台机器上逐渐将CM实例数量扩展至5个(每个实例绑定6个CPU核心)。可以看到，当每台机器部署不超过5个CM实例时，耗时几乎没有变化；同时将CM实例部署的机器横向扩展后，整体耗时依然无明显变化(图 6(c))。

基于上述测试结果可以得到以下结论：

(1) 单CM实例的峰值认为是50000连接数。

(2) 在32核CPU上，每台机器上可部署的CM实例数为5个(即每个CM实例约占6个CPU核，其中CPU性能会对部署情况产生一定影响)，因此基于本文部署服务器的单机峰值性能为500ms发送250000个客户端。

(3) 通过CPU核绑定和本文的级联广播推送架构，横向扩展机器不会对整体耗时产生影响。因此，单机器500ms内下发250000个客户端可以扩展到40台同样配置的机器，达到预警信息同时下发千万量级用户的性能，且耗时控制在500ms以内。

3.3 千万量级推送性能测试

基于上述性能测试结果，设计并搭建了千万量级预警信息发布平台，在阿里云新建95台虚拟机，部署硬件清单如 表 2所示。其中一台机器用作消息下发，部署PMS和CBC(Start)模块，三台机器作为注册中心，部署Zookeeper，利用其树状节点管理中心功能，以节点的各个状态对应服务的健康度。除了服务端微服务以外，将Redis、Hbase、分布式锁、主从关系等注册到Zookeeper上，统一管理，使微服务架构可以方便地发现和调用此类服务，并实现负载均衡。一台机器作为数据库，部署MySQL和Redis，CM端部署45台服务器，每台服务器部署5个CM，并在8台服务器上混合布设CBC(Region)模块。

为实现千万量级模拟客户端，每台服务器采用主网卡和4个虚拟子网，每个IP建立4.5万个连接，即每台客户端机器发起22.5万个长连接，通过共计45台机器来发起1000万个长连接，每个CM实例和模拟连接实例之间进行直连。

整个推送系统模块之间的网络拓扑使用了级联广播的模式，上下层模块维护稳定TCP长连接，地震预警消息以消息编号的形式在系统中快速向下广播，直到最底层通信模块，随后将消息下发至模拟链接器。消息从PMS下发命令和消息，发送到入口CBC中，入口CBC采用同步调用的形式，从会话表中提取次级CBC的通道信息，通过HSF调用到区域CBC的Callback方法，进行远程回调，从而将消息下发到区域CBC。区域CBC采用异步调用的形式，以同样的HSF方法回调到次级CBC并下发消息。以此顺序逐层下发，最后由最终层CBC进行异步回调CM，将消息传递到CM，进而推送到SDK(图 7)。

如 图 7所示，在消息下发功能接收到下发命令和消息后，通过ProtoBuf(Google Protocol Buffers)技术解析消息内容，获取到消息中的APPID和TaskID，根据两条ID信息从个推服务器中获取消息公共体内容。同样，将消息内容通过ProtoBuf技术反序列化成真实消息内容，再采用信息压缩技术转化成二进制流，开始进入发送流程。下发流程开始时，会先遍历该台CM模块中维护的Grizzly连接会话表，对会话表中缓存的连接判断APPID是否为需要下发的APP以及客户端是否在线校验和客户端的地域过滤。为了对系统千万量级性能进行实际评估，设计测试为：预警消息由PMS下发，发给CBC(Start)，广播给8个CBC(Region)，再广播给各自连接的CM，CM再发给模拟连接。通过PMS模块发送预警信息，以每30s间隔循环发送20次，下发总量10080006个长连接，具体测试信息推送情况见 图 8。

由 图 8可以看到，系统在推送千万量级预警信息时，整体延时在460~575ms之间分布，平均延时在475ms，延时波动较小，表明本文研究的方法具备千万量级预警信推送能力，可以达到亚秒级。相对于传统推送方法，千万量级信息推送往往在数十秒到分钟级，本文设计的级联推送架构体现出海量信息场景下的高时效性能和高并发处理能力。

3.4 区域定向推送

为了在真实环境中对系统的区域定向推送能力和延时情况进行分析，在天津、四川、山东、福建等地选择了约100部手机进行测试。推送方案按照天津、四川、山东、福建4个地区模拟4个震例信息，每个震例信息分别做3次全量广播和3次区域定向广播(共计24条消息)，推送内容和方案如 表 3所示。

测试数据采用每次客户端收到消息并回执的时间减去服务端消息发出的时间，24组测试平均延时结果如 图 9所示，可以看到24轮测试整体延时均控制在1s内，平均延时控制在500ms以内。

4 结语

本文采用区域定向优先广播技术和海量用户高并发广播技术，设计了一个海量用户亚秒级地震预警信息发布系统。通过对CM的性能优化，最终提供了一套由PMS 1台、CM 45台、中间件4台(共50台服务器)组成的具备秒级推送千万用户的地震预警信息发布平台。测试表明，该系统在500ms内(不计服务器到终端的网络传输延迟)即可向一千万个并发长连接用户推送地震预警消息，在实际区域定向推送中延时也控制在1s内。该系统的部署和实际应用可以实现震中区域海量用户预警信息的亚秒级推送，提升预警信息服务“最后一千米”的覆盖效能。

相较于传统的推送技术，本文解决的千万量级预警信息推送技术瓶颈主要体现在两个方面：①降低级联系统端到端的网络延时，减少级联系统的业务逻辑，将大量用户管理和计算下沉到CM端，利用广播拓扑结构优化整体的下发耗时链路，以降低系统整体耗时，并在CM系统进行性能优化，使CM具备承载短时间高并发的能力；②结合预警信息发布场景的区域定向推送技术，使海量预警信息可以在亚秒级实现高并发的区域推送。本文研究成果将为我国地震预警系统建设和地震预警信息的广泛应用提供有力的技术支持，可有效减轻未来破坏性地震的人员伤亡和经济损失。此外，该系统也可以用于其他紧急系统的信息发布，具有广阔的应用前景。