FetchDataLogic-国标视频平台信令服务器统一定时数据获源码实现

本文对应源码core/app/sev/vss/internal/logic/proc/fetch_data_proc.go，将说明它在进程里做了哪些事、为什么要集中在一个逻辑里按时间表拉取，以及典型场景（ONVIF 发现、设备在线状态快照等）如何体现「少请求DB/少外部依赖、多读内存」的思路。

项目源码地址https://github.com/openskeye/go-vss

1. 本质

FetchDataLogic实现types.SipProcLogic，在 VSS 启动时与其它 SIP 协程任务一起DO常驻运行。可以概括为：

1. 启动阶段：两条并行分支并行拉第一批数据，并通过InitFetchDataState通知全进程「可调业务」。
2. 运行阶段：每秒被Ticker唤醒一次，按不同周期异步触发各类「刷新ServiceContext里缓存字段」的函数。

也就是说：它是ServiceContext——字典、平台设置、媒体节点列表、ONVIF 局域网发现结果、设备/通道在线状态快照等，
都尽量在这里统一更新，供 HTTP / SIP / SSE / WS 等逻辑直接读内存，而不是每个请求各自去 RPC 或扫库。

2. 启动

WaitGroup: 两个 goroutine ├── goroutine A: dictionaries() → InitFetchDataState.Done()（sync.Once） └── goroutine B: setting() → mediaServers() → onvifDiscover() → deviceOnlineState() → InitFetchDataState.Done()（sync.Once） wg.Wait() 后进入下方定时循环

• dictionaries()

  • RPC：Config.DictionaryTrees
  • 写入：svcCtx.DictionaryMap（按字典uniqueId构建的map）

• setting()

  • RPC：Config.SettingRow
  • 经rule.NewConfig(...).Conv().Setting()与本地Config合并后写入svcCtx.Setting
  • 后序任务依赖「设置已就绪」，因此放在同一分支里先于mediaServers。

• mediaServers()

  • RPC：Config.MsList（媒体服务器node列表）
  • 写入：svcCtx.MediaServerRecords

• onvifDiscover()

  • 设备探测 ONVIF 设备，解析 SOAP，写入svcCtx.OnvifDiscoverDevices
  • 下一节将详细介绍。

• deviceOnlineState()

  • RPC：Device.OnlineState（DB 聚合设备/通道online列表）
  • 写入：svcCtx.DeviceOnlineState（*DeviceOnlineStateResp，设备 map + 通道 map）

InitFetchDataState作为全局数据基础，在入口程序中需要先行完成，其它模块才能放行（例如 SIPListen、SendLogic等），避免启动程序错乱。

3. 定时循环

for v := range time.NewTicker(time.Second).C，用Unix 秒做取模区分不同场景等数据获取：

每次触发都是异步执行，不阻塞下一秒的Ticker，避免某次 RPC 或 UDP 发现拖死调度。

这里需要注意的是，每一个携程中没有做状态处理机制，如果说当前周期执行时间较长，下一个（n）周期完成后的数据可能将会被覆盖，这里可以自行优化以下。

4. 典型案例：ONVIF设备发现

1. 按配置Onvif.MulticastIP、WsDiscoveryPort发送固定 XMLwsDiscoveryMessage（NetworkVideoTransmitter）。
2. 遍历网卡JoinGroup/SetMulticastInterface，提高多网卡环境下收到应答的概率。
3. 在DiscoveryTimeout内收 UDP 包，解析types.OnvifWSDiscoveryResponse，从Scopes/XAddrs等抽出名称、厂商、型号、IP、服务 URL 等。
4. 使用包级onvifKeyMaps：对EndpointReference.Address稳定映射到本服务生成的UUID，便于列表里去重与展示主键一致。
5. 最终svcCtx.OnvifDiscoverDevices = records（切片替换）。

为什么放在 FetchData 里、而不是每个 HTTP「搜索设备」再 discover 一次？

• 发现涉及组播、多网卡、超时等待、XML 解析，成本高、耗时长、结果短时内相对稳定。
• 集中每 2 分钟刷一次（可再调配置），前端或其它接口只读OnvifDiscoverDevices，体验上是「列表可能最多延迟一个周期」，但换来极快的数据响应。
• 这与「减少对DB的频繁/重复查询」是同一思路：把重 I/O / 重计算挪到后台周期任务，请求路径直接读取内存数据。

5. 与 DB RPC 的关系

FetchDataLogic自身仍会调 RPC（因此 DB 侧仍会被访问），但频次被限制为周期任务，且单份缓存服务多消费者：

• 设备/通道在线状态：deviceOnlineState每 10 秒拉全量 map 到DeviceOnlineState。例如 SSEdevice_online_state、诊断页等若都改为只读该字段，就不会每个 SSE 连接或每个 HTTP 请求都打一遍OnlineState。
• 字典 / 设置 / 媒体服务：每 4 秒刷新，业务代码在热路径上读DictionaryMap、Setting、MediaServerRecords，避免散落各处的「每次来一下SettingRow」。

权衡：

• 优点：请求延迟低、后端负载平稳、代码边界清晰（获取数据优先看FetchDataLogic填充的字段）。
• 代价：数据延迟TTL（4s / 10s / 120*s 不等），强一致场景仍需直连DB RPC读取；ONVIF 列表也可能短暂滞后于真实网络。

6. 小结

7. 源码与索引

• fetch_data_proc本文件：core/app/sev/vss/internal/logic/proc/fetch_data_proc.go
• 初始化：core/app/sev/vss/main.go（InitFetchDataState.Add(2)）
• 消费DeviceOnlineState的典型逻辑：core/app/sev/vss/internal/logic/sse/device_online_state.go
• 设备/通道在线：写入路径与详细解释见：设备与通道在线状态.md

FetchDataLogic是VSS的统一定时数据入口——把字典、配置、媒体节点、ONVIF 发现、在线状态等按不同周期刷新进ServiceContext，让业务在请求路径上多读内存、少重复访问 DB/RPC/网络，ONVIF 则是其中最典型例子。