图片来源：pexels.com

作者：梁鑫（资深架构师，多年云原生，微服务架构经验，开源SIA系列产品owner）

前言

今年开始，由于工作内容调整。开始负责美股港股产品的研发。之前的两篇文章，重构 - 在美股行情系统的实践和美股交易架构实践分享了行情系统的重构和交易系统的建设。按照计划，接下来要改造的是 APP 的信息推送了。

APP 信息推送

目前行情产品采用的是定时请求机制，通过 HTTP 请求每隔若干时间从后端服务拉取一次行情数据，在这个时间间隔内数据是不会发生任何变化的。但当我们打开竞品比较时，发现他们的行情数据是以肉眼不可捕捉的速度变化的。明显这不是定时请求能够达到的效果，一定是通过建立 TCP 长连接，把数据源源不断的从后端服务推送到了用户的手机上。

1

消息推送的方式选择

熟悉信息传输的朋友肯定发现这种需求不需要实时返回数据，是典型的异步传输。一般可以采用两种方式来处理。一种是后端服务直接采用 TCP 方式传输到客户的手机上。另一种就是选择合适的消息服务器，让后端服务和客户手机进行解耦。明显我们会选择后者。

MQTT 协议基本是手机端进行消息通信的标准做法，让我们先了解一下消息队列遥测传输协议，它是一种基于发布订阅的轻量级通讯协议，该协议构建于 TCP/IP 协议上，最大优点在于以极少的代码和有限的带宽，为连接远程设备提供实时可靠的消息服务。

2

选择何种 MQTT 产品

实现 MQTT 协议的消息产品不少，选择哪一款产品比较合适？我们的选择是 EMQ，为什么选择 EMQ 呢，我直接把 EMQ 官网描述照搬下来大家可以作为参考。

EMQ 设计目标是实现高可靠，并支持承载海量物联网终端的 MQTT 连接，支持在海量物联网设备间低延时消息路由:

• 稳定承载大规模的 MQTT 客户端连接，单服务器节点支持 50 万到 100 万连接。

• 分布式节点集群，快速低延时的消息路由，单集群支持 1000 万规模的路由。

• 消息服务器内扩展，支持定制多种认证方式、高效存储消息到后端数据库。

• 完整物联网协议支持，MQTT、MQTT-SN、CoAP、LwM2M、WebSocket 或私有协议支持。

2.1

EMQ 的高可用方式

MQTT 服务器肯定需要支持高可用，我们是不能容忍单点故障的，但 EMQ 的高可用方式需要注意一个问题，EMQ 的集群需要一个 master 节点和若干个 slaver 节点，将 slaver 节点 join 到 master 节点组成集群，当 mater 节点宕机后需要 client 端进行重新连接才能正常 running。

EMQ 的高可用架构图如下：

3

使用 EMQ 服务需要考虑的三个问题

当我们把 EMQ 引入到我们的系统后，我们需要考虑三个潜在的问题。

一，客户端 APP 连接数。EMQ 官网数据号称单个 EMQ 节点可以支持 50 万到 100 万个链接，我们目前搭建了两个节点，按 50 万计算，可以支持 100 万个客户端链接。可以预计的将来我们很难短时间内达到百万用户同时在线，所以判断这个数据完全可以满足我们的需求。

二，EMQ 服务器创建的 topic 数量。官网没有给出 topic 的数量限制，可能觉得一般的使用情况应该不会创建超级大量的 topic，但我们的需求比较特殊，如果按股票创建 topic，很可能会让 topic 数量暴增，从而导致 EMQ 服务出现问题。因此我们要最大限度的降低这个值。

三，Topic 的信息吞吐量，如果把所有的行情信息都传送到 EMQ，相信 EMQ 无法承受这个量级，因此我们也要最大限度的降低这个值。而且降低这个值会减少用户 APP 的流量。

4

五，如何降低 EMQ 服务的三个峰值

首先，我们不能把所有的股票行情消息都推送到 EMQ 服务器上。美股有数万只股票。每只股票又都包含实时信息，交易明细新，交易买卖档信息。如果把所有的信息都推送到 EMQ 上，需要创建十多万个 topic，很明显这样处理是不合适的。那么最好的方式就是客户在 APP 上查看那只股票的信息就把哪个股票的信息往 EMQ 中推送。

其次，我们不能把每只股票的所有行情信息都推送到 EMQ 服务器上。针对某些非常热门的股票，开盘收盘时每秒钟的交易信息可以到 4000+，如果把这些都推送到客户 APP 上，手机可能打不开了。因此我们需要利用时间间隔每秒推送两到三条信息，就可以让客户感受到价格信息的实时变化，优化客户的体验。

再次，采取续约的方式保证股票信息只在需要的时候进行推送。客户一般关注某只股票一段时间就会关注其他股票或者做其它的事情了，因此我们采用续约的方式处理。客户首先订阅某只股票信息，然后间隔若干时间进行续约。如果服务端没有收到续约信息，就不再推送该股票的信息了。

最后，保留拉取信息模式，非开盘时间不进行数据推送。非开盘时间股票信息基本不会发生变化，因此推送只在盘中时刻采用。

5

有效的避免安全隐患

首先要设置 EMQ 的防火墙，EMQ 的防火墙设置在官网有明确的介绍，我这里就不做赘述。其次我们将 EMQ 服务设置为只处理下行数据，不处理上行数据的模式。客户 APP 进行的订阅请求，采用 http 的方式。

6

APP 推送的完整架构设计

Redis 的作用是实现分布式锁，保证只有一个行情 API 节点往 EMQ 中推送数据。

总结

美股行情竟然是公司第一个采用信息推送的 APP 产品，有一点出乎我的意料。（全文完）

精彩文章推荐

微服务架构设计总结实践

2021-05-10

万字长文精华之数据中台构建五步法

2021-05-07

从零开始搭建创业公司后台技术栈

2021-04-29

图解 Kafka，看本篇就足够啦

2021-04-28

代码重构技巧宝典，学透本篇就足够了！

2021-04-27

梁鑫：美股交易架构实践

2021-04-26

王启军：云原生架构下如何拆分微服务？

2021-04-20

原创精华：剖析亿级请求下的多级缓存

2021-04-19

梁鑫：重构 - 在美股行情系统的实践

2021-04-09

浅谈架构：架构的缘起与目标

2021-04-07