做实时行情系统这几年我最大的感受是很多人把它的设计难点想错了。大家以为最难的是“连上一个行情源把数据解析出来”一旦数据流停了第一反应就是“上游源挂了”其实真正难的是当协议、数据源、架构里任何一个环节抖动时整个系统还能不能稳定输出。实时行情系统不是一根简单的数据管道它是一整套围绕协议选择、高可用架构、数据源选型展开的延迟与可靠性博弈。这篇文章是我从零搭行情系统到后来因为延迟尖刺和丢包问题被迫做高可用改造整个过程里沉淀下来的方案和踩坑经验。适合正在做行情系统的人也适合那些准备接行情但还没想清楚数据源选型和协议取舍的开发者。下面不写教科书只写我怎么拆这个问题。1. 先把问题定义清楚你要做的是哪一类行情系统很多团队拉个会议说要“做行情系统”但聊了半小时你会发现大家说的根本不是一回事。有人说的是接入解码有人说的是行情转发网关有人说的是行情历史数据库还有人说的是前端K线图的数据服务。这三四类系统的协议要求、架构复杂度、延迟预算完全不同。如果不先把这个问题掰开后面每一步设计都是空中楼阁。1.1 行情数据的完整链路你的系统站在哪一段行情数据从交易所撮合引擎产生到最终被你的策略或用户看到中间大致有这几个环节交易所快照/逐笔生成行情源服务商接入转发你的系统接收解码内部总线分发快照计算和指标加工落盘存储推送或查询最后到客户端渲染或策略订阅。不同团队喊的“实时行情系统”站位差异非常大。只做接入层把交易所或者行情商的数据包收下来、解析成统一消息然后丢给下游。这类系统核心指标是解包吞吐和延迟架构相对简单。做分发转发层要支撑多个订阅方按证券或按频道广播行情。这时候要考虑广播效率、订阅治理、权限控制。做快照计算层维护当前最新的盘口和逐笔实时计算涨速、均价、盘口异动等指标。这类系统需要同时处理多条数据流的合流、乱序、重复复杂度明显高。做历史存储与回放给回测、分析和复盘提供数据。这类系统更看重写入吞吐、时间窗口查询和回放性能对毫秒级接收延迟没太多要求。我自己的项目属于第二、第三类的混合体既要支撑多个客户端订阅又要维护实时快照和部分衍生指标。这种定位决定了我在协议选型、数据源接入和架构设计上要同时照顾“低延迟”和“多订阅”两个目标。你现在动手之前建议也先画一条数据流把每个环节写清楚再判断你做的到底是哪段。1.2 延迟、容量、可靠性其实是三角取舍行情系统设计难难在这三个指标天然互相拉扯。延迟敏感的应用比如高频套利或者盘口追踪它希望从行情产生到自己代码收到数据的时间越短越好。但容量上来之后比如全市场逐笔、几千只股票的盘口每秒几万甚至几十万笔消息任何复杂处理都会把延迟拉高。可靠性和前两项更是矛盾要实现高可用就要加冗余、加复制、加补偿任何一个额外动作都会增加延迟。你必须在动手之前明确自己当前的优先级到底是什么。我做这套系统的时候用户场景主要是盘中盯盘和量化策略的分钟级重采样对延迟的要求是“稳定比极低更重要”宁可平均延迟多两三毫秒也不希望出现偶尔100毫秒的尖刺。这个定位让我后面的很多设计做出了明显偏保守的选择。这里有一个比较实用的量化思路先定业务容忍度再倒推技术预算。比如你的业务要求是“行情从源端产生到策略可见不超过50毫秒且p999不超过200毫秒”那网络传输只有几毫秒、解码最多给5毫秒、总线加计算给10毫秒、推送给几毫秒剩下的都是缓冲余量。有了这个预算表你在每一步做技术选型时就有了取舍依据。1.3 你真的需要毫秒级行情吗这个问题听起来像废话但经常会被人忽略。很多团队买了一大堆低延迟设备最后业务跑的是2秒刷新一次的人工看盘页面这完全是在给架构上不必要的强度。我的建议是先把消费方盘一遍人工盯盘和移动端百毫秒级延迟其实可以接受WebSocket足够。分钟级或秒级策略普通TCP订阅接口就够了不用自己搭UDP多播接收。二级市场的盘口博弈和套利才需要认真考虑微秒到毫秒级链路这时候协议选型才会直接决定成败。实时行情系统的很多设计成本比如UDP多播接收、共享内存分发、硬件时间戳对齐都是为最后这一类场景准备的。如果你不属于这一类完全可以把钱花在更好的数据源和更稳定的服务上而不是在OS内核参数里折腾。2. 协议选择TCP、UDP多播和私有协议怎么取舍协议选型是行情系统的第一个分水岭。选错了后面再想从TCP改成UDP多播几乎是推倒重来。我见过不少项目一开始用WebSocket收行情跑得挺好后来业务要求提高切换到低延迟行情源结果接入层、解码层、序列号处理逻辑全部要重写痛苦得不行。所以协议问题最好在第一天就想清楚。2.1 TCP在行情场景下为什么“会卡”TCP本身是一个可靠、有序、面向连接的协议这在普通业务里是优点但在实时行情场景里有一个致命问题队头阻塞。只要前面的一个数据包丢了或者延迟了后面的所有数据包都要排队等待重传。短时间看起来没事但在网络抖动时TCP的延迟尖刺会非常难看。行情系统最怕的不是平均延迟而是尾延迟。真实场景里策略逻辑往往会对“最新价格”做时序判断某一次的突然卡顿可能直接导致错误信号。我做过一个测试在轻微丢包的局域网环境里TCP订阅通道的p99延迟能到几百毫秒而同样条件下UDP通道的p99几乎没变化。道理很简单TCP把“可靠性”放在协议栈里强制执行它在丢包时一定会停下来等这种等待对行情数据来说就是不可接受的。因此在专业行情分发链路里TCP更多被用在控制连接、请求响应、补数据这些场景而不是作为主行情的实时传输通道。2.2 UDP多播机构级行情分发的主流选择如果要做低延迟、多订阅方的行情广播UDP多播几乎是绕不开的方案。原因很实际行情天然是一对多的。同一个股票的快照可能有几十个客户端同时在订阅。如果用TCP每个客户端都要建立一条独立连接源端就必须把数据复制几十份发出去带宽和CPU都吃不消。多播则能让网络层自动把一份数据复制给同一个组里的所有接收者效率和延迟都比TCP好很多。但UDP多播不等于直接裸发UDP包就完事了。它把可靠性问题从协议栈转移到了应用层。你需要自己设计序列号、心跳、重传机制。接收端要做序列号连续性检测一旦发现空洞就知道中间丢了数据然后向重传服务请求缺失区间。这套机制看起来很重但它换来了一个核心价值主数据流永远不受重传阻塞影响。多播的一个现实约束是它对网络环境有要求。物理局域网或者支持组播的专网环境部署没问题但在云主机和容器环境里多播基本不可用。如果在云端跑工程上一般退化为TCP私有协议或WebSocket通过调整缓冲区、多路复用等方式尽量压低延迟。这个约束要在选型时就问清楚你的部署环境到底是机房裸金属还是云。2.3 行情协议里的序列号、快照与增量、重传机制协议选好传输层还要把应用层协议的关键字段设计好。我见过很多自研行情协议设计得五花八门但有几个要素是必须有的。序列号是最重要的字段。序列号不代表包ID而是代表这条流的时间顺序号。接收端靠它判断是否丢包、是否乱序。没有全局序列号你就无法准确做到断点续传和对账。数据发布方如果有多个子频道或数据源还要在序列号基础上带一个源ID避免接收端把不同流的序号混在一起比较。快照与增量是行情协议的另一个关键设计。每笔逐笔成交是增量数据但新客户端的初始状态需要一个“当前完整快照”。成熟的行情协议会周期性发送快照或者在客户端启动时通过请求获取。增量数据必须携带自增序号接收端判断自己缺了哪一段再去补快照或重传区间。这个过程如果在应用层实现得不好很容易出现“差一条数据就一直卡住”的问题。重传服务需要单独设计。UDP多播主通道丢了包在应用层是不能靠阻塞主通道来补的必须有一个独立的retransmit通道或请求响应服务。接收端发现空洞后发送请求带上自己最后收到的序号和需要补的序号区间由重传服务返回对应数据。这里要注意重传通道走TCP是安全的因为它不承载实时主数据流即使慢一点也不影响最新行情的到达。2.4 WebSocket和REST接口什么时候够用并不是所有行情系统都要上UDP多播。WebSocket在很多场景下反而是更合理的选择。WebSocket运行在TCP之上有连接语义有二进制帧支持可以做到服务端主动推送。对Web前端、移动端、量化研究环境来说这个协议非常顺手因为生态成熟、跨网络容易也能穿过大部分防火墙。如果你的业务对延迟的容忍度在几十毫秒到百毫秒级WebSocket完全够用它能让你把精力放在订阅逻辑和数据解析上而不是自己维护UDP重传。REST轮询则适合更低频的场景比如分钟级K线、日线历史数据。它的问题不只是延迟高还有实时性差你无法知道下一次请求之间发生了什么变化你看到的永远是“请求时点”的切片。行情数据严格来说是一个流不是一组离散的状态所以只要场景要求“一有变化就能感知”REST就不合适。下面是我在选型时用的一张对比表直接抄作业也行维度TCP私有协议UDP多播WebSocketREST轮询典型延迟毫秒级丢包时尖刺明显亚毫秒到毫秒级较稳定几十毫秒级秒级可靠性协议内置应用层实现协议内置请求响应一对多广播效率低需要复制连接极高网络层复制中需要逐个推送无推送实现复杂度中高低最低适合场景中低延迟策略、云端分发机构级低延迟交易Web/移动端订阅低频查询、历史数据3. 数据源选型直连、服务商聚合与公开接口的真实差异协议选型是“怎么接”数据源选型是“接谁的”。这个环节如果只贪便宜或者只看单一指标后面会吃大亏。数据源的质量直接决定你系统的可用性和数据质量而且这部分问题通常不是靠架构能弥补的。3.1 数据源到底有几层行情数据源可以按照离交易所的物理距离和逻辑链路分几层。最上层是交易所本身。交易所直接输出的是原始的撮合快照和逐笔委托/成交数据格式通常是私有二进制传输方式也偏底层比如专用网络、组播或专有行情系统。直接对接交易所一般意味着高昂的接入成本和严格的合规要求普通公司和个人基本走不到这一步。第二层是行情服务商或柜台服务商。国内常见的券商行情服务器、期货柜台、行情API实际上就是这一层。它们从交易所拿到原始行情以后经过整理、转发、加字段再以某个特定API协议提供给下游。这一层是大多数专业行情用户的主战场。它的数据质量、延迟、稳定性都比较好但费用不低不同服务商之间还有字段差异和代码体系差异。第三层是第三方量化数据接口或聚合平台。它们把一两个或多个行情源的数据再次整合提供标准化的HTTP或WebSocket接口有些甚至直接把数据整理成DataFrame。这类平台的易用性最好社群资料也多适合研究和开发初期验证。但它的延迟比服务商源高不少而且字段经常被“清洗”过你可能拿不到最原始的盘口对手价。第四层是公开的网页接口或免费行情来源。它们几乎没有成本接入也快但稳定性、限流策略、数据完整性都不受你控制生产环境基本不建议依赖单一免费源。3.2 不同数据源的真实差异对比我整理过一个比较实际的对比维度延迟、数据丰富度、费用、数据质量、集成成本每一项都直接影响项目决策。维度交易所直连行情服务商/柜台第三方聚合免费公开接口延迟极低低中到高高且不稳定字段完整度最全未过滤较全经过裁剪字段有限数据质量最高高偶尔有源间差异中可能出现漏tick低限流和乱序常见费用极高中高低到中免费集成成本极高需专线/合规中有文档有SDK低接口友好最低适合场景自营极低延迟交易专业策略、生产环境研究、回测、原型学习、演示、非关键链路这个表格不是让你直接选第一行而是让你结合自己的定位做组合。比如我在生产环境用的是一个付费服务商源作为主源另一个服务商源作为备用源同时保留一个免费源做本地开发测试。三层混着用才能既保证生产不裸奔又控制成本。3.3 多源冗余和“时间基准”问题单数据源在真实线上环境里根本不可靠。我遇到过几次主源因为服务端任务重启导致连接中断这时候如果架构里没有备用源整个系统的行情就断供了。备用源不是简单再连一个源就行它必须和主源保持同一套行情序列语义至少能在主源断开时让下游从一个相对一致的时间点继续接收。多源冗余还有一个容易忽视的问题时间戳对齐。不同数据源对同一笔成交打的时间戳可能不同。有的源给的是交易所原始时间有的源给的是本地接收时间有的源还带上了服务商自己的处理时间。如果你直接把源时间戳落库后面做回测和数据分析时就会发现同一个价格点在不同源里对不上。更稳妥的方案是在接入层统一把每条消息打上“系统接收时间戳”同时保留源的原始时间戳分析时以系统时间戳为对齐基准原始时间戳作为参考字段。3.4 数据源选型上我的建议不要凭参数表和网上口碑直接定源最好的办法是花一到两周做一次影子数据验证。具体做法很简单选定两个候选数据源同时接入一套非生产环境让它们并行跑一段时间然后对比几个关键指标每秒消息数、平均延迟、序列号空洞次数、重复消息比例、字段异常比例、断连次数。注意这里的延迟必须从“同一时刻的数据”来对比最可靠的标准是看同一序列号消息从源A和源B到达本机的时差或者用统一定时基准测量。我在选型时还养成了一个习惯每个价格字段必须做精度和单位检查。不同源对价格的表示方式差异很大有的用整数分有的用浮点元有的用字符串。这种问题在联调阶段就会发现但如果只靠文档理解往往要等数据对比时才暴露处理成本会高很多。接入层统一做一层“字段标准化”是必须的不要指望下游自己适应多家源的差异。4. 高可用架构设计的主线思路行情系统的特点是数据量极大、实时性要求高、故障影响直接。高可用不是简单“部署两个副本”而是要把数据流的接入、分发、计算、存储故障域拆干净让任何一个环节出问题都不会造成全局停摆。4.1 接入层多源接入与全局序列号管理接入层是所有数据的入口也是故障最容易爆发的地方。一个源断线、一个协议包解析出错、一处缓冲区溢出都会在这里引爆。我的设计原则是每个数据源一个独立Adapter进程或线程互不共享状态故障隔离。主源和备源之间不互相感知它们只负责把各自的数据变成统一格式的消息发给下游总线。这样即使主源Adapter崩溃备源Adapter还可以继续提供服务。接入层还承担一个关键职责统一生成内部消息的全局序列号和接收时间戳。不同源有自己的业务序列号但下游不应该直接依赖源的序列号否则一旦切换数据源下游的乱序和补数据逻辑就全乱了。内部序列号由接入层分配格式通常包含“源ID自增序号”或“全局自增序号”这样下游无论如何订阅都能按一个统一的顺序逻辑工作。接入层处理重复消息也很重要。行情源在重连之后经常会把断线期间的旧数据重新推一遍。如果不做去重下游会看到同一个成交记录出现两次。去重一般用滑动窗口维护最近N个序列号N的大小根据重传窗口设置。注意去重只能在同一个源同一通道内做跨源的去重还需要结合业务字段和比对规则比较复杂一般不在接入层做。4.2 分发层从消息队列到共享内存的取舍接入层解码后的数据要分发到多个消费者。这一步的选型很关键直接决定系统是“能跑”还是“能扛”。如果你对延迟要求不是极低比如总体预算在10毫秒以上内部用消息队列是完全可行的。Kafka、Redis Stream、RocketMQ都有现成的发布订阅模型还能提供持久化和消息回溯工程实现简单很多。它们的代价是序列化、磁盘写、消费组调度带来的额外延迟和资源开销但在数据量级可控的前提下稳定性和可维护性远高于自己裸写。如果你要做低延迟分发消息队列就不太合适了。这个场景下业界常用的是共享内存加无锁队列或者基于UDP组播做跨机分发。共享内存方案利用mmap把同一块内存映射到多个进程消费者可以用无锁读的方式拿到最新数据延迟能做到微秒级而且不经过内核网络栈避开系统调用开销。缺点是部署在同一台机器上进程外的消费者无法直接获取需要额外组件将数据转发出去。我实际采用的是混合方案核心快照计算进程和后端存储进程之间走共享内存做到低延迟不丢数据跨机器的客户端订阅则通过网关进程转成TCP或WebSocket推送。这样既满足了低延迟的内环需求又保留了跨机部署的灵活性。4.3 计算与存储层快照引擎、落盘与回放计算层要维护“当前最新行情状态”。这个状态可以拆成两个部分最新快照包括最新价、买一卖一、买卖五档、当日开高低逐笔记录包括每一笔成交的时间、价格、数量、主动买卖方向。快照引擎最常见的实现是使用并发哈希表key是证券代码value是最新的快照结构体。每一笔增量到达时更新对应字段并把需要推送变更的标记发出去。这里要注意一个细节状态更新操作必须是原子的。在高并发情况下多个数据流同时修改同一只股票的快照如果加锁不当就会出现“价格和量对不上”的脏读。我一般用无锁哈希表加乐观更新或者按证券代码做分片锁避免全局锁带来的竞争热点。存储层不建议在这个过程中做同步写。行情数据量很大如果每笔都同步落盘延迟影响会非常明显。正确的设计是主链路只做内存计算和推送异步将原始消息批量写入日志或时序数据库。落盘消息要保留原始序列号和时间戳以便后续做故障恢复时的数据回放。回放服务本质上就是按照时间区间读取历史数据并按序列号依次推送给订阅方。这个能力看起来简单但它是高可用架构里断线补偿机制的基础。4.4 故障切换与断线补偿不能只靠“重启”高可用切换不是粗暴地重启一个进程而是要保证下游感知到的数据流尽量连续。这里有两个核心机制主备切换和断线补偿。主备切换的前提是状态同步。备用节点必须从主节点拿到快照状态和日志偏移并且维护一个“我落后主节点多少数据”的度量。切换时备用节点要把自己缺失的数据段从主节点同步过来才能开始对外服务。如果直接切过去下游看到的价格会突然跳变甚至错得离谱。为了防止简单的主备双节点在极端情况下出现“脑裂”问题生产环境一般建议引入协调组件做领导选举节点拿到领导权时会带一个版本号旧节点即使还在运行也会因为版本号较低而自动降级为从节点。断线补偿有三种典型来源重传服务器提供的缺失区间数据、内存快照加增量数据、历史存储回放。具体用哪一种取决于中断的时长。中断在几秒内重传服务器最合适中断在几分钟内内存里维护的最后快照加后续增量可以补上中断时间较长就要靠历史存储回放补数据。我这套系统里把三类补偿做成了同一个接口客户端在重新连接时带上自己最后消费的序列号补偿服务根据这个序列号自动判断该走哪条路径对下游透明。5. 性能量化延迟从哪儿来能压到什么程度很多人以为写好代码就行不上压测不知道行情系统到底有多少隐藏开销。延迟不是单点问题它是从源端到你客户端整条链路上的积累。我在这里把主要环节拆开给你一份可以照着做的量化方法。5.1 端到端延迟的四段拆解为了排查性能问题我把端到端延迟拆成四段源端到接入层、接入层解码、内部总线分发与计算、推送层到客户端。源端到接入层的延迟主要由网络条件和上游服务商的处理方式决定。如果走专网或同机房部署这部分的延迟可以做到很低一般在数百微秒到数毫秒。如果走公网波动会明显加大。接入层解码的延迟相对固定主要是协议解析和对象创建的开销性能优秀的二进制解码器平均解一条消息在几百纳秒到几微秒之间。内部总线负责分发这部分延迟取决于消息传递方式。共享内存无锁队列的延迟能控制在几微秒Kafka之类的消息中间件则要到毫秒级甚至更高。推送层到客户端用WebSocket有网络和TCP开销用TCP私有协议可以做到相对更稳定。每一段都不是瓶颈合在一起就决定了你的延迟预算是否够用。建议在每一段的关键节点打上高精度时间戳至少标记“源端时间戳”“接入层到达时间”“解码完成时间”“总线发出时间”“客户端收到时间”。只有切到每段的耗时你才能定位到延迟是网络、代码还是架构造成的。5.2 压测行情系统到底怎么压真实行情系统不好压。因为行情数据不像普通HTTP请求可以用压测工具随便生成。我的做法是从生产环境录制一段真实行情保存原始二进制数据包然后在测试环境用回放工具按照同样速率和包序推给系统。这样做的最大好处是压测流量和真实流量形态完全一致能准确压出解码和总线在高吞吐下的行为。回放工具需要支持倍速回放。我一般先跑正常1倍速再跑5倍速和10倍速观察系统在峰值速率两到三倍时是否还能保持稳定。如果1倍速下就会出现消息积压那就不用看后面了。压测指标至少包括吞吐量每秒处理消息数、平均延迟、p99和p999延迟、消息积压总量、CPU和内存占用。我还要提醒一点压测时要重点看CPU软中断占比和内存分配速率。行情接收是高IO场景网络软中断处理不好会直接成为瓶颈。内存分配速率过高则说明热路径上产生了大量短期对象GC会成为延迟尖刺的来源。这两项通常比平均延迟更能暴露问题。5.3 常见调优方向内核、网卡、GC系统吞吐和延迟上不去很多时候不是业务代码的问题而是OS和运行环境没有调优。网络层最常见的调整是增大UDP或TCP接收缓冲区。行情数据突发性强如果内核接收缓冲区太小瞬时流量一冲直接丢包。Linux下可以通过sysctl或setsockopt调大net.core.rmem_max和rmem_default具体数值要结合消息大小和吞吐量测算。网卡方面打开网卡多队列并让应用进程绑定到处理对应队列的CPU核心可以显著降低软中断竞争。应用层的热路径优化重点是减少锁和对象拷贝。行情解码后消息会经过多次转发每次反射、格式化、复制都会产生额外开销。我用下来有效的方法包括用固定字节数组代替String字段用对象池复用临时Buffer用无锁队列代替互斥锁避免在热路径上打日志。GC方面尽量让高频对象的生命周期短到进入新生代就能回收避免晋升到老年代产生Major GC。调优不是一次做完就完了。每做一个改动都要重新压测对比。我习惯把压测基线记录在案改动后再跑同一份回放流量找出p99和GC次数的差异如果指标没变好果断回滚。6. 从设计到落地还有几个必须警惕的坑架构设计做完只是开始真实落地过程中踩过的坑往往比设计文档里的内容更有参考价值。这里写几个我印象最深、也最容易让新手翻车的问题。6.1 序列号出现空洞不一定就是丢包接入层做连续性检测时看到序列号跳了一个区间条件反射会认为数据丢了马上触发重传请求。但真实行情系统里序列号空洞可能来自以下几个原因上游行情源本身不是单流单调某个子频道一段时间没有数据消息乱序到达后面的先到前面的还在路上多个通道合并后通道路由间隙导致不同步还有一种可能就是检测窗口设置得太小数据还在传输路径上。正确做法是不要对单个空洞立刻重传。一般要给一个等待窗口比如等待若干毫秒或者N个后续包如果空洞仍然存在再发起重传请求。否则一旦网络出现轻微抖动所有客户端会同时对重传服务发起请求造成“重传风暴”把重传服务打挂这是行情系统里很典型的雪崩场景。6.2 解码器的内存分配陷阱我在第一次压测时发现GC频率高得吓人冲刺CPU profiling才发现问题出在解码器每次解析行情都新建了一堆对象每条消息里几十个字段每个字符串都要new然后马上处理完丢弃。在每秒几万笔消息的流量下这些短命对象直接塞满了新生代Minor GC高频触发。解决办法就是热路径的对象复用。价格、成交量这些字段不要在解码时转成String直接用整数或浮点表示需要传递的消息体尽量用预分配的Buffer池每条消息的元数据对象用Flyweight模式复用。经过这轮优化新生代分配速率降了接近一个数量级GC几乎不再成为延迟尖刺的源头。6.3 小集群的高可用比想象中更难做很多人以为高可用就是“两个节点一个挂了另一个顶上”。但两个节点做高可用会面临脑裂和数据冲突问题。两个节点同时认为自己是主节点各自接收数据、各自计算、各自推送下游就乱了。更稳妥的落地方式至少是三个节点组成一个带领导选举的小集群或者引入一个独立的协调服务维护版本号。我在实际项目中用的是协调组件加版本号机制节点启动时必须先获取一个递增的版本号数据接收和推送时都带上这个版本号下游只认版本号最大的来源。旧主节点即使还活着它的版本已经作废无法再对外提供数据。这套机制牺牲了一点简单性但换来了确定的故障切换行为线上用了很久也没出过冲突。另外高可用一定要定义清楚RPO和RTO。你能接受丢多少数据能接受停机多少秒这直接决定切换策略的激进程度。如果业务能接受最多丢几百条消息切换时可以不等补偿完成就对外服务如果一条都不能丢那必须做同步复制和数据对账代价是切换时间变长。这个权衡没有标准答案但必须提前想清楚否则故障真正发生时你根本来不及现场讨论。