3. 哨兵系统架构设计:哨兵模式介绍、系统分层架构与数据流图
在《Level2行情坏账率哨兵实战教程》中,哨兵系统并非一个简单的监控脚本,而是一套具备实时采集、流式计算、分级告警能力的分布式架构。本章将深入剖析哨兵模式的核心思想,并给出清晰的分层架构与数据流设计,为后续编码实现奠定基础。
3.1 哨兵模式介绍
哨兵模式借鉴了分布式系统中“哨兵节点”的概念:每个哨兵独立运行,持续探测目标状态,并通过共识机制判断是否触发告警。在本课程中,哨兵系统针对Level2行情中的坏账率指标进行实时监控,其核心特征包括:
- 无状态探测:每个哨兵节点只关注当前时间窗口内的行情数据,不依赖历史持久化状态。
- 多维度阈值:支持按股票代码、行业板块、时间粒度设置不同的坏账率阈值。
- 自动降噪:通过滑动窗口均值过滤瞬时毛刺,避免误告警。
- 分级响应:根据坏账率严重程度,触发不同级别的告警动作(日志、邮件、Webhook)。
实战提示:哨兵模式与传统的定时任务轮询不同。哨兵采用事件驱动+流式窗口计算,能够在毫秒级感知坏账率突变,适合高频行情场景。
3.2 系统分层架构
哨兵系统采用经典的三层架构:采集层、计算层、告警层。各层职责明确,通过消息队列解耦,便于水平扩展。
| 层级 | 核心组件 | 主要职责 | 技术选型参考 |
|---|---|---|---|
| 采集层 | 行情网关、数据解析器 | 接收Level2行情流,解析逐笔成交、委托队列,提取坏账相关字段 | WebSocket / TCP Socket |
| 计算层 | 滑动窗口引擎、坏账率计算器 | 按时间窗口聚合计算坏账率,与阈值比较,生成告警事件 | Flink / 自研流引擎 |
| 告警层 | 告警路由器、通知分发器 | 根据告警级别路由到不同渠道,支持去重与抑制 | Redis + 消息队列 |
架构要点:采集层与计算层之间使用消息队列(如Kafka)作为缓冲,防止行情峰值压垮计算节点。告警层独立部署,避免计算层故障导致告警丢失。
3.3 数据流图
下图展示了哨兵系统的完整数据流转路径,从行情数据源到最终告警输出,共经过6个关键处理阶段。
3.4 核心处理流程
数据流图中的每个阶段都对应一组明确的处理步骤。下表列出了从行情到达至告警发出的完整流程清单:
| 步骤 | 阶段 | 具体操作 | 输出数据 |
|---|---|---|---|
| 1 | 采集 | 接收Level2行情快照,解析坏账相关字段(坏账笔数、总成交笔数) | 结构化行情事件 |
| 2 | 缓冲 | 将行情事件写入消息队列,按股票代码分区 | 分区有序事件流 |
| 3 | 窗口聚合 | 按1分钟滑动窗口聚合,计算坏账笔数 / 总成交笔数 | 窗口坏账率指标 |
| 4 | 阈值比较 | 将窗口坏账率与预设阈值(如0.5%)比较 | 告警事件 / 正常事件 |
| 5 | 告警路由 | 根据告警级别(警告/严重/紧急)选择通知渠道 | 路由指令 |
| 6 | 通知分发 | 调用邮件API、短信网关或Webhook发送告警 | 告警通知 |
3.5 计算层内部架构
计算层是哨兵系统的核心,其内部采用滑动窗口 + 状态机设计。下图展示了计算层内部的组件协作关系:
注意:滑动窗口引擎需要处理乱序到达的行情事件。建议在反序列化阶段添加时间戳校验,丢弃延迟超过窗口长度的事件,避免计算偏差。
3.6 架构设计要点总结
- 解耦:采集层与计算层通过消息队列解耦,任一层的故障不会直接导致另一层不可用。
- 可扩展:计算层支持水平扩展,通过增加计算节点分摊股票分区的坏账率计算压力。
- 低延迟:滑动窗口计算在内存中完成,不依赖磁盘IO,单节点处理延迟可控制在10ms以内。
- 可观测:每层都暴露监控指标(采集速率、计算延迟、告警数量),便于运维排查。