2、实时数据采集层设计：数据源接入（行情、交易、风控）、消息队列选型（Kafka/RabbitMQ）、数据格式标准化
各位同学，咱们今天聊聊实时数据采集层。这一层是整个监控告警系统的地基，地基不稳，上面盖的楼再漂亮也得塌。我这些年做金融系统，见过太多因为数据采集层设计不合理，导致告警延迟甚至丢失的惨案。嗯，咱们今天就把这块掰开揉碎了讲清楚。
2.1 数据源接入：行情、交易、风控
金融Agent要监控的数据源，说白了就三大类：行情数据、交易数据、风控数据。这三类数据的特点完全不同，接入方式也各有讲究。
2.1.1 行情数据接入
行情数据是实时性要求最高的。股票、期货、外汇的Tick级数据，每秒可能产生成千上万条。我个人习惯用WebSocket或者UDP组播来接入。为什么？因为HTTP轮询的延迟太高了，你想想看，行情变化是以毫秒计的，等HTTP请求来回一圈，黄花菜都凉了。
我在项目中遇到过一个问题：某券商用HTTP轮询接入深交所行情，结果在开盘高峰时段，数据延迟达到3秒以上。后来改成WebSocket长连接，延迟降到了50毫秒以内。这个教训让我深刻认识到，行情接入必须用推模式，不能用拉模式。
- 使用WebSocket或UDP组播，避免HTTP轮询
- 支持断线重连机制，防止网络抖动导致数据丢失
- 数据压缩传输，减少带宽占用
2.1.2 交易数据接入
交易数据包括委托、成交、撤单等。这类数据的特点是：必须保证不丢、不重、有序。为什么？因为交易数据直接关系到资金和持仓，错一条可能就是几百万的损失。
我建议用Kafka作为交易数据的接入通道。Kafka的持久化机制可以保证数据不丢失，而且支持分区顺序消费。我曾经帮一家期货公司排查过问题，他们用RabbitMQ接入交易数据，结果在高并发时出现了消息乱序，导致风控系统误判。后来换成Kafka，问题就解决了。
2.1.3 风控数据接入
风控数据比较特殊，它既有实时性要求，又有历史回溯需求。比如：保证金率、持仓限额、风险指标等。这类数据通常来自风控系统内部，接入方式相对灵活。
我个人习惯用REST API + WebSocket双通道接入。REST API用于获取初始状态和定期同步，WebSocket用于实时推送变化。这样既保证了数据的完整性，又满足了实时性要求。
2.2 消息队列选型：Kafka vs RabbitMQ
消息队列是数据采集层的核心组件。选型选不好，后面全是坑。我直接说结论：金融实时监控场景，首选Kafka。为什么？咱们看个对比表：
| 特性 | Kafka | RabbitMQ |
|---|---|---|
| 吞吐量 | 百万级/秒 | 万级/秒 |
| 消息持久化 | 磁盘持久化，支持回溯 | 内存为主，磁盘为辅 |
| 消息顺序 | 分区内严格有序 | 单队列有序，多队列无序 |
| 消费模式 | 拉模式（Pull） | 推模式（Push） |
| 运维复杂度 | 较高 | 较低 |
你看，Kafka在吞吐量和消息持久化方面完胜。金融监控场景下，行情数据每秒几十万条是常事，RabbitMQ根本扛不住。而且Kafka的拉模式有个好处：消费者可以自己控制消费速度，不会因为生产者太快而被压垮。
不过话说回来，RabbitMQ也不是一无是处。在低吞吐、高可靠性的场景下，比如风控指令下发、交易确认通知，RabbitMQ的灵活路由机制反而更有优势。所以，不要非此即彼，混合使用也是常见方案。
2.3 数据格式标准化
数据格式标准化，说白了就是给所有数据定个统一的"说话方式"。我见过最乱的系统，行情用JSON，交易用Protobuf，风控用XML，解析代码写了一堆if-else，维护起来想死的心都有。
我建议统一使用Protobuf作为数据格式。为什么？三个原因：
- 性能好：Protobuf是二进制格式，序列化/反序列化速度比JSON快10倍以上，体积也小很多
- 强类型：定义好.proto文件后，生成代码可以直接用，不会出现字段名拼写错误这种低级问题
- 向后兼容：新增字段不影响旧版本，这在金融系统升级时特别重要
下面是一个简单的行情数据格式定义示例：
syntax = "proto3";
message MarketData {
string symbol = 1; // 合约代码
double last_price = 2; // 最新价
double bid_price = 3; // 买一价
double ask_price = 4; // 卖一价
int64 volume = 5; // 成交量
int64 timestamp = 6; // 时间戳（毫秒）
string exchange = 7; // 交易所
}嗯，这里要注意：时间戳一定要用毫秒级整数。我见过有人用字符串存时间，结果解析时各种时区问题，排查起来特别痛苦。用整数时间戳，统一用UTC，省心。
- 所有数据统一使用Protobuf
- 时间戳使用毫秒级整数（Unix Timestamp）
- 字段命名统一使用snake_case
- 每个消息必须包含message_id和timestamp
2.4 整体架构图
说了这么多，咱们用一张图把整个数据采集层的架构串起来：
这张图把整个数据采集层的流程画清楚了。数据从行情、交易、风控三个源头进来，经过Protobuf标准化，统一写入Kafka，最后由Agent消费者处理。每一层各司其职，互不干扰。
好了，数据采集层就讲到这里。记住一句话：数据采集层设计得好不好，直接决定了你的监控告警系统能跑多稳。行情接入用WebSocket，交易接入用Kafka，风控接入双通道，数据格式统一用Protobuf，消息队列选Kafka。这套组合拳打下来，基本不会出大问题。