本文由百度搜索技术平台研发部分享，本文有修订和改动。

1、引言

分布式数据传输系统是一种用于在多个计算节点之间高效传输大量数据的系统，诣在高效的解决大规模数据迁移、备份、跨地域复制等问题。其广泛应用在实时数据流传输、跨数据中心数据迁移、多媒体传输等场景，在大多数企业中的日志管理、业务数据建库等场景中也都会使用到。

众所周知，数据的高效传输往往直接影响着企业对市场先机的把握，对企业发展有重要意义，特别是在金融领域，如证券行业，它对分布式数据传输系统的设计提出了更高的要求，证券领域数据变化飞快，一个高时效、稳定的数据流传输系统不仅能有效的提升用户体验，更能提供用户一手的投资信息，有助于用户的投资决策，进而拉进企业与用户的距离。

本文将通过一个百度搜索旗下的金融场景案例来分享构建高实时、高可用的分布式数据传输系统的技术实践。

技术交流：

• 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

• 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4602-1-1.html）

2、业务背景

作为百度搜索场景下时效性要求较高的业务，金融承载着每天数千万次的用户搜索请求。

而在2021年以前，金融业务的数据一直都是采用传统的互联网引入方式，该方式的特点是接入成本较低，但受公网等不可控因素影响，数据时效性较差，且数据断流、错误等问题频出，随即而来的就是业务维护成本较高，十分不利于产品迭代。

我们基于此发起了一个证券数据直连项目，诣在通过接驳全球各大证券交易所数据中心来构建一个高时效、高可用的分布式传输系统，从而有效的解决传统数据引入方式（公网抓取、推送）所带来的时效性、稳定性、正确性等问题，进而满足全国乃至全球用户的金融需求。

3、设计目标

3.1业务目标

接驳全球各大证券交易所Level-1行情数据，来覆盖全量上市公司股票、外汇、期货、ETF、涡轮牛熊等证券业务来满足用户需求，时效性追平金融行业竞品，为打造强大的金融生态做数据基建储备。

Level-1行情简称LV1行情：是交易所根据交易规则发布的即时行情信息，数据格式包括基于FIX/FAST协议的接口和TXT文件、二进制数据流等，行情通过交易所信息技术公司的高速地面网和宽带广播卫星系统发布或上证所信息网络有限公司的互联网和专线传输。

3.2技术目标

1）基础设施建设：协同交易所、运营商完成物理专线的链路部署，通过物理专线接入的方式在百度云机房接入上海、深圳、香港、纳斯达克证券交易所数据中心，适配交易所单、组播协议将二进制流/文本数据引入到百度内部，再分别完成华南、华北、华东、香港（支持海外访问）地域的数据存储与转发，同时支持负载和流量调度来支撑各地域的用户请求。(注：这里的物理专线特指光缆）

2）时效性和稳定性提升：行情数据检索99分位耗时不超过200ms，数据稳定性从99%提升至99.99%以上，数据灾备能力从1主0备升级至1主2备。

3）数据安全：基于百度安全能力，构建类似的防火墙策略来严格控制每一个机房、每一个集群的出入权限，并且配置好相应的安全组策略。

4、关键思路

从功能和网络拓扑上来看，一个高时效、高可用的金融数据传输系统至少需要包含以下几个部分，我们逐个来进行解读。

4.1接入层

适配全球各大交易所单、组播传输协议，确保数据能在专线物理网络正常传输。

接入主要有2种方式：

1）一种是走互联网；
2）一种是走物理专线。
前者相对比较灵活：各类数据协议基本都可以支持，有直接走HTTP（GET/POST），或者是走消息队列的发布订阅等等，接入成本较低，属立即接入那种，但受公网的不可控因素影响，在传输效率和安全性上相对后者会有比较大的差距，我们一般会把互联网的方式当做一个灾备能力存在。

专线方式的特点：是仅点对点传输，由于用的是独立的光缆，在有限带宽内理论可以做到无争用状态，不受公网影响，属可靠传输，传输协议私有化，增加了更多的认证机制。因此也更安全，区分不同应用场景，像证券类数据传输，一般交易所采用的是单播、组播方式，当下用的多的是组播。另外专线中也有主备的概念，一般会预留1-2条线路做灾备，整体下来，专线的费用要更昂贵一些，接入的周期也更长，往往长达几个月。

4.2网络层

完成华南、华北、华东百度云机房虚拟网络架构建设，包括子网、路由、网关等。

虚拟网络的核心组成部分主要是子网、路由、网关、虚拟机，其中每个子网关联着一个虚拟机集群，我们把整个组成部分（域）统称为一个VPC（Virtual private Cloud），路由又区分为TGW路由和对等连接。

这里主要关注对等连接，它是为用户提供了VPC级别的网络互联服务，使用户实现在不同虚拟网络之间的流量互通，实现同区域/跨区域，同用户/不同用户之间稳定高速的虚拟网络互联，其核心是基于对路由表的操作，对等连接也支持配置地域级的DNS同步。

网关又分为NAT网关和专线网关：

1）一个对外：比如设置SNAT和DNAT规则用于统一网段的外网出口；

2）一个对内：对内其实就是确保能够走专线和内部网络打通。

4.3传输层

完成各机房内的数据解析、存储、同步、转发等。

对于接入层获取到的数据我们分为三个级别：

1）像交易所主要是二进制流、文本为一级数据，我们需要保留近一段时间的原始数据落在本地（一级数据管理集群），以便用作应急回放。

2）而解码后的数据为二级数据，落在二级数据管理集群上，主要用于跨地域同步。

3）最后，对解码后的数据进行计算&加工，作为三级数据，落在三级数据管理集群用于承接应用服务。同时，按协议解码后的数据按照使用场景区分为实时流（如分时）、延时流（如K线），延时流经过实时流计算得来，实时流同步进内存用于提升IO效率，延迟流通过实时流的计算后异步进DB，DB维护在三级数据管理集群上。

4.4应用层

负载/流量调度、监控能力等建设。

应用层的设计，主要有两个方面的考虑：

1）一方面是对于接入层的负载和流量调度，如通过部署websocket/http服务来支撑百度用户流量，使用BLB（Baidu Load Balance）将同一区域的多台百度智能云服务器虚拟成一个组，设置一个内网或外网的服务地址，将前端并发访问转发给后台多台云服务器（BCC），实现应用程序的流量均衡，性能上实现业务水平扩展。

负载均衡还通过故障自动切换及时地消除服务的单点故障，提升服务的可用性，支持服务器调度权重策略配置，并支持TCP、HTTP等协议。

2）一方面是对监控的应用，如请求/数据传输日志落盘、统计、分析以及流量和sla监控等。

4.5小结

将以上四层能力建设后，此时单机房内的网络拓扑应该如下图所示。

注：DCC/BBC/BCC都是百度云范畴的机器类型，更多细节可以参考百度智能云私有网络：https://cloud.baidu.com/doc/VPC/s/Vjwvytu2v。

5、核心难点1

公网和私有网络方式下如何在云上完成多协议适配，尤其是在私有网络中适配单播、组播协议以及如何做组播转单播。

5.1公网&私有网络接入介绍

对于一个数据传输系统来说，最重要的一点其实就是能支持多协议的数据适配来提升系统的灵活性，证券交易所一般提供的接入方式有公网接入和私有网络接入，公网接入的成本较低，一般周粒度就可完成，没有复杂协议约束。

而私有网络往往会有更高的要求，协议上大部分都要求具备单播介入能力，少部分像纳斯达克和深圳交易所会要求下游支持组播接入。绝大多数的云厂商是无法直接在虚拟机上适配的，传统券商基本都是完全使用昂贵的物理机资源来承载，虽然物理机插拔更方便也更稳定，但运维管理成本也更高。

两种方式在效果和成本上也有本质的区别：

1）公网接入：公网比较常见的数据接入方式主要是HTTP/HTTPS方式，当然也会有RPC/FTP，只是用的相对少一些。

为了提升数据传输安全，双方可以在调用前协商好数据加密算法和密钥。优点是接入成本较低，能快速应用，尤其在跨洋传输上会有体现。缺点是走的公共线路，网络不可靠，且数据易被截获，当攻击者捕获两端的数据包后，哪怕不能完全解析，也可以实施一些流量攻击手段以影响服务稳定性。总的来说，一般不会对于安全性、时效性要求较高的数据采用该方式接入，更多是只是一种备用方式（特殊场景除外，如跨洋传输）。

2）私有网络接入：公司内网其实就属于一个私有网络，但是对于跨公司传输数据的场景，要想构建私有网络，一般会走物理专线接入的方式。

这种点对点传输方式的显著优点是专网专用且安全性较高，基本不受公共网络影响（自然灾害等不可抗力除外），在带宽范围内基本可以做到无网络争用状态（数据即发即达），由于是私有网络（双端内网传输），基本不用担心数据安全问题，而且往往还会增加额外的数据校验手段，尤其在金融场景，会有严格的token（硬/软）认证，该方式的缺点是成本相比公网传输接入成本更高，一般要持续数月，费用更昂贵，一般在上百万元，依赖选取的传输介质（一般选择光纤）和带宽。

5.2私有网络中单播、组播协议接入方案

私有网络有单播、广播、组播之分。

1）单播：相对比较好适配一些，走静态路由的方式在同一个VLANID下分别配置云端和IDC端的IP段作为IPV4专线互联地址即可。

2）广播：一般是对于服务端而言，比如证券交易所下游对接着全球范围的所有券商，数据源是相同的，一般会采用广播的机制把数据推送给所有下游。

3）组播：一般是要求下游需要适配，现如今大部分业务都已经上公有云，在云上常用虚拟化技术来完成服务器集群的部署。

对于虚拟机来说，更多的支持单播传输，不支持组播传输，往往需要在专门的物理设备（组播路由器、或特定的组播软件）上配置转发组播报文的路由，路由表关联着具体的路由协议（如PIM），再用IGMPV3协议来完成组播成员和报文的管理，通过动态BGP维护邻居关系（现在的云厂商上对BGP的可能是固定分配AS号，如果有AS的要求还是需要在物理机上单独做），我们可以圈出一部分物理资源专门承载组播数据传输，通过配置IGMP Snooping（可以将组播报文转发到二层数据链路层，实现组转单，注意版本需要是3，否则无法转发IGMPV3报文）+ AP完成组播转单播配置，再通过双网卡（WAN口+LAN口）形式实现专线网络数据接入&同步到百度内网，物理机通过三层交换机来关联，构造出类似下面的网络拓扑（如下图所示）。

6、核心难点2

6.1概述

数据管理&跨地域同步，数据灾备能力、时效性提升。

数据的分层管理主要是应对单机房内的场景，而对于跨机房或者说跨地域的主要难点是数据同步，后者需要更多的考虑跨机房数据传输效率和灾备管理，核心是网络设计。

6.2数据管理

按使用场景的不同，将数据分交易所二进制流数据（原始数据流）、文本数据、业务数据/日志等。

1）原始数据流：主要应对单机房、跨机房传输场景，当出现下游业务服务异常导致的数据展现错误时，存储的原始数据流可以很好的对数据进行回放，以便快速恢复业务，尤其是应对金融证券数据传输场景，证券交易所一般不会推送重复数据，如果下游业务服务异常导致存储的业务数据全部失效或为脏数据，那可能只能通过refresh主动请求上游来重新获取。

但这样做可能会出现核心数据丢失，由于这种方式的效率较低，还会扩大业务受损的影响面，因此一般会先存储交易所下发的原始数据流，业务可以自定义存储方式和周期，当出现问题时，可以通过『重播』原始数据流来止损。

另外原始数据流还能用于在对等网络中的跨机房恢复业务数据。

2）业务数据流：主要应对单机房传输的场景，根据模块分工的不同，分证券的实时行情、历史行情等等，对于单机房数据集群的管理我们有很多方式，对于自研的DB，在调度上可以用一些标准的分布式管理手段（如zk），数据同步的手段一般需要自定义，对于传统的DB如Mysql、Redis、Mongo等，一般有标准化的数据同步方式和调度模式。

6.3跨地域同步

跨机房地域同步的前提是多个机房之间需要有直接或间接关联关系的专用物理网络，即确保网络是可达的，然后再结合虚拟网络完成子网及路由配置。

对于具有直接网络关联关系的2个机房来说，我们的对等网络（Peer Connection）设计稍微简单一些。

现在各个云厂商也基本都支持直接配置了，其原理是首先在同一个VPC下划分好子网并规划好集群规模，其次通过配置路由表的方式完成本端和对端的下一跳关联，这样就完成了2个直接对端的对等网络建设。

接着再配置和内网专线的路由，就能做到云机房->内网机房的网络互通。

但如果2个机房没有直接关联关系，而又需要完成本端和对端数据同步怎么办呢，比如有A B C三个机房，只有A-B B-C有直接关联关系，而我们想要让A-C关联，这时候不可能说再建立一条物理链路，我们可以采用类似桥接的方式（或者叫隧道），同时关联A-B-C三个机房，其中B作为一个”网桥”，再通过NAT技术完成IP地址转换，确保C可以识别从A过来的路由，而A-B B-C 正常采用对等网络的方式完成基础网络配置，这样就可以胯多个机房进行通信，由于是物理网络传输，机房间的耗时不会有很大差别（30ms内）。

由于网络细节的篇幅较多，我们不做详细的赘述，这里我们看看跨地域同步的网络架构（如下图所示）。

注：图中网段可以根据不同场景做划分，这里只做简单介绍。

6.4数据灾备能力、时效性提升

数据灾备：我们一般选择离各个证券交易所就近的一个接入点，比如上证选择在上海机房接入，深证选择在广州接入，纳斯达克在香港接入，每个接入点配置2条专线用做物理链路的主备，同时扩展一条互联网通路（注意这里的互联网也是直接和交易所对接，已经不是传统数据引入渠道）做次备，链路默认都是活跃状态，有专们的物理设备会根据专线的健康状况（自定义逻辑）自动切换。

最后，再根据上面提到的跨地域同步的原理，在云机房关联各条物理链路，在每条物理链路上抽象出独立的VPC，通过构建网络拓扑实现跨机房数据复制及灾备。

时效性：物理专线（光缆）接入方式天然的优势就是数据”即发即达”，因为在固定带宽内基本不存在网络争用，而且现在大部分线路都会配置中继，其损耗带来的影响相对可控，因此接入方式就决定了数据传输的时效性。

相比传统互联网接入方式，单从数据上来看，专线接入SLA超过5个9（互联网接入2个9），当然也会配置上重传机制来进一步提升数据到达的可靠性。

交易所下发数据的数据频率按市场划分，A股一般3s/笔，港美股没有特殊限制，即有成交即下发，除去光损耗带来的影响，最快可以到3ms/笔，由于频率越高，对机器要求也越高，为此我们特殊做了一些限频操作，整体的数据时效性基本会在60ms（99.99+分位）内。

7、核心难点3

7.1概述

集群管理&单地域、跨地域流量调度。

流量调度生效在应用层，主要是找到一种高效的调度/负载方式来对内/外的业务提供数据支撑，从协议上/应用场景划分主要有TCP/HTTP，策略上因业务而异，主要还是基于对流量分配中权重的定义。

比如有基于RS健康检查的分配，每隔一段时间探测一下下游集群的健康状况来动态调整流量配比，也可以根据下游机器的连接数来分配，还可以基于对资源访问的热度来分配，区分单地域和跨地域场景如下面所述。

7.2单地域场景

现在各个云厂商都有相应的流量调度产品支撑，比如百度云上有BLB（Baidu Load Balance），可以很轻松构建一个调度规则出来，在BLB下可以设置调度集群的协议（TCP/HTTP），然后关联对应的服务器集群，最后给不同的服务器集群配置权重策略。

当流量进来时，BLB会帮我们完成自动分配，在某一个集群出现问题时，可以手动调整集群权重来干预流量配比，即所谓的切流。

7.3多地域场景

多个机房间的流量调度策略是在云上一般是隔离开的，当然我们可以在多个机房的最上层再抽象出一个专门的调度集群，对外暴露一个VIP。

在这个VIP上配置多个地域之间的调度关系，互联网公司基本上也都是这么做的，更多的是针对超大集群规模的场景，而且VIP的选取也是有条件/成本的。

但如果想低成本快速在云上创建一个能支持多地域同时访问且具备自动化流量调度的应用，且云上又不支持多地域共享VIP的功能时，我们可以尽可能多的基于云上已有的功能自己完成，在每个机房内部单独抽出一个类似nginx的集群，每个集群上维护着不同于本地域的调度关系，它们的下游就是不同于本机房的BLB，同时互相检查对方的健康状况并上报监控系统，这样当出现异常时，除了能针对性的在本机房内完成BLB级的流量调度，还能做到多机房间的流量切换，以提升机房间的灾备能力。当然，也需要有足够的容量。

8、总体设计

上图各个模块的作用如下（各模块均采用多路复用）：

1）源数据接入集群：适配2种方式（互联网/物理专线）+各类协议（互联网、单播、组播）的数据源接入；

2）源数据转发集群：确保各机房源数据的一致性，降低由于业务服务本身带来的数据不一致问题；

3）数据解析集群：公共模块，主要是针对源数据进行统一的处理，以便转发给下游各业务；

4）业务数据集群（实时/延时流）：负责将数据解析集群下发的内容转换成业务详细数据，也就是B端或C端用户看到的数据；

5）网关集群：负责承载用户访问流量；

6）监控集群：负责收集各个集群上报的日志情况，并作为稳定性管理手段之一。

可以看到：机房B相比其他机房，少了接入层配置，这主是基于成本和性能上考虑，把机房B当做数据传输枢纽，不仅能保证本机房数据传输，也能支持跨机房的数据同步&复制。该分布式传输系统从数据接入到监控集群，整体机器规模不大（100左右），但可支撑超过10亿的流量。

9、本文小结

一个良好的产品体验及产品矩阵，其背后一定离不开一个高可用、高时效的数据支撑，尤其是在金融领域，用户只可能会为一手的信息、完善的产品功能买单。

自21年完成数据通路建设以来，金融的稳定性和业务规模都有了质的飞跃，证券数据时效性问题从季度数十个降低到年度1个以内，99分位耗时更是从过去的分钟级降低到60ms以内，数据SLA从2个9左右提升至5个9以上，产品覆盖股票、外汇、基金、期货等诸多领域，也是第一个在搜索领域支持行情长连接的业务，基于搜索生态也孵化出来了像百度股市通PC站、app等多个独立端产品，目前正在结合AI能力进行持续优化，期望从完善用户体验->帮助用户决策进阶，也让金融投资变得更智能，更简单。

本文主要结合一个金融数据接入案例对分布式数据传输系统做了一个简单的介绍，包括传输系统中的一些核心节点的设计，如数据接入层的多协议适配、数据的分层管理以及跨地域的数据同步对应的网络拓扑等，通过实验得出结论，该方案能很好的应用在各种规模的分布式数据传输系统设计中。当然，由于篇幅问题，也省略了很多实现上的细节，读者有任何问题可以留言，可以一起探讨，也会尽量答复。

10、相关文章

[1] 技术扫盲：新一代基于UDP的低延时网络传输层协议——QUIC详解

[2] 以网游服务端的网络接入层设计为例，理解实时通信的技术挑战

[3] 知乎千万级并发的高性能长连接网关技术实践

[4] 手淘亿级移动端接入层网关的技术演进之路

[5] 喜马拉雅自研亿级API网关技术实践

[6] 石墨文档单机50万WebSocket长连接架构实践

[7] 小米小爱单机120万长连接接入层的架构演进

[8] B站基于微服务的API网关从0到1的演进之路

[9] 百度统一socket长连接组件从0到1的技术实践

[10] 淘宝移动端统一网络库的架构演进和弱网优化技术实践

11、其它百度技术分享

《百度APP移动端网络深度优化实践分享(一)：DNS优化篇》

《百度APP移动端网络深度优化实践分享(二)：网络连接优化篇》

《百度APP移动端网络深度优化实践分享(三)：移动端弱网优化篇》

《全面了解移动端DNS域名劫持等杂症：原理、根源、HttpDNS解决方案等》

《深入了解百度开源的分布式RPC框架brpc的方方面面》

《直播系统聊天技术(四)：百度直播的海量用户实时消息系统架构演进实践》

《IM消息ID技术专题(五)：开源分布式ID生成器UidGenerator的技术实现》

《百度统一socket长连接组件从0到1的技术实践》

《百度网盘千万节点的P2P架构设计(PPT) [附件下载]》

《即时通讯音视频开发（二十）：一文读懂视频的颜色模型转换和色域转换》

《揭秘百度IM消息中台的全量用户消息推送技术改造实践》

《百度基于金融场景构建高实时、高可用的分布式数据传输系统的技术实践》

（本文已同步发布于：http://www.52im.net/thread-4602-1-1.html）