一、行情系统概述：分布式行情系统的定义、核心挑战与架构演进
大家好，我是你们这堂课的主讲人。今天咱们聊聊行情系统。
很多人觉得行情系统不就是把价格数据推送给用户吗？其实没那么简单。我做了十几年分布式系统，行情系统是我见过对延迟最敏感、对吞吐要求最变态的系统之一。说白了，它就是个在毫秒甚至微秒级别内，把海量市场数据准确无误地分发到全球各地的“数据管道”。
1.1 什么是分布式行情系统？
先给个定义。分布式行情系统，就是由多台服务器协同工作，完成行情数据的采集、清洗、存储、计算和分发的一套软件系统。
它跟传统单体行情系统最大的区别在于：
- 数据不存一台机器上——单机扛不住全球交易所的实时数据流
- 处理能力可以水平扩展——加机器就能扛更多用户
- 任何单点故障不影响整体——一台挂了，其他节点继续干活
我记得刚入行时，某家券商的行情系统还是单机部署。每天开盘前，运维小哥都要重启一遍服务，生怕盘中崩了。现在想想，那真是刀尖上跳舞。
1.2 核心挑战：三个绕不开的坎
做行情系统，你一定会遇到这三个问题。我一个个说。
挑战一：低延迟
行情数据是有时效性的。延迟100毫秒，对于高频交易来说，可能就是几百万的损失。
为什么会这么敏感？你想想看，如果A交易所的行情比B交易所慢了50毫秒，套利者就能利用这个时间差，在两个市场间来回倒手。所以，行情系统的延迟必须压到极致。
我个人习惯把延迟拆成三部分来看：
- 网络延迟：数据从交易所到你的服务器，物理距离决定了下限
- 处理延迟：数据解析、校验、转换，这部分靠优化代码来压
- 分发延迟：把数据推送给用户，这里最容易出问题
关键指标：行情系统通常要求端到端延迟在1毫秒以内。注意，是端到端，不是单机处理时间。
挑战二：高吞吐
低延迟难，高吞吐更难。两者往往还是矛盾的。
举个例子。沪深交易所一天的行情数据量有多大？我告诉你，光是逐笔成交数据，一天就能产生几十亿条。如果你用传统的消息队列一条条处理，CPU很快就跑满了。
我在项目中遇到过最夸张的情况：某次行情峰值，每秒涌入200万笔订单数据。当时我们的系统直接被打挂了。后来复盘发现，问题出在序列化上——我们用了JSON，解析太慢。换成二进制协议后，吞吐直接翻了5倍。
避坑指南：我曾经以为只要加机器就能解决吞吐问题。后来发现，如果数据分片策略不对，加再多机器也是白搭。关键是要让每台机器处理的数据量均衡，别让一台累死，其他闲着。
挑战三：数据一致性
这个最容易被忽视，但后果也最严重。
行情数据必须保证顺序。比如某只股票先涨到10元，再跌到9元。如果用户先看到9元，再看到10元，那交易策略就全乱了。
分布式环境下，保证顺序很难。因为数据可能从不同节点到达，时间戳也可能有偏差。我见过一个案例：某系统因为时钟不同步，导致行情数据乱序，用户基于错误数据下了单，最后赔了钱，官司打了半年。
注意：行情系统的数据一致性，不是强一致性，而是“因果一致性”或“最终一致性”。你不需要所有节点同时看到相同数据，但必须保证每个用户看到的数据是逻辑正确的。
1.3 典型架构演进：从单体到分布式
行情系统的架构不是一天建成的。我把它分成三个阶段，你看看你们公司现在在哪个阶段。
第一阶段：单体架构
最原始的方案。一台服务器，一个进程，搞定所有事情。
- 优点：简单，开发快，部署容易
- 缺点：扛不住高并发，单点故障，扩展性差
我记得2010年左右，很多中小券商的行情系统还是这个架构。每天开盘前，运维都要祈祷服务器别挂。
第二阶段：分层架构
把系统拆成接入层、处理层、分发层。每层可以独立部署和扩展。
- 接入层：负责接收交易所的原始数据
- 处理层：负责数据清洗、计算、存储
- 分发层：负责推送给用户
这个架构的好处是，哪层瓶颈就扩哪层。比如用户多了，就多加几台分发服务器。
第三阶段：分布式架构
这是目前主流方案。核心思想是：数据分片 + 多副本 + 无状态设计。
- 数据分片：按股票代码或交易所，把数据分散到不同节点
- 多副本：每个分片有多个副本，保证高可用
- 无状态设计：服务器不保存用户状态，挂了直接换一台
我参与过的一个项目，就是用这种架构支撑了全球20多个交易所的行情数据。单日处理量超过100亿条，延迟控制在500微秒以内。
下面这张图，是我画的分布式行情系统核心架构图。你可以看到数据从交易所到用户的完整路径。
1.4 架构演进背后的驱动力
你可能会问，为什么要从单体演进到分布式？说白了，就是业务逼的。
我总结了几点：
- 数据量爆炸：十年前一天几亿条，现在一天几百亿条
- 用户规模增长：从几千用户到几百万用户
- 延迟要求变高：从秒级到毫秒级，再到微秒级
- 业务复杂度增加：从简单行情展示到量化交易、风控计算
嗯，这里要注意。架构演进不是一蹴而就的。我见过很多团队，一上来就想搞分布式，结果搞了半年，系统还没跑起来。我的建议是：先跑通单体，再逐步拆分。别为了分布式而分布式。
核心观点：分布式行情系统的本质，是用多台机器的协同工作，来换取更低的延迟、更高的吞吐和更强的可用性。但代价是系统复杂度大幅上升。
1.5 本章小结
这一章我们聊了三个核心问题：
- 什么是分布式行情系统——多台机器协同处理行情数据
- 三大核心挑战——低延迟、高吞吐、数据一致性
- 架构演进路径——从单体到分层，再到分布式
我个人觉得，理解这些基础概念，比学会某个具体技术更重要。因为技术会变，但底层逻辑不会变。你只要掌握了这些核心挑战，后面学任何具体方案，都能很快上手。
好，这一章就到这儿。下一章我们聊聊具体的通信协议，看看怎么把延迟压到微秒级。
公众号:蓝海资料掘金营，微信deep3321