既然是小伙伴们“插眼关注”的问题，与其等待答案，不如我们自己去寻找答案！
API分析
该 watch 功能的主要特性包括：
- 在有限的时间内（目前为 3 小时,可能会调整，请勿依赖此时间）为用户提供高可用的数据变更 watch 服务。
- 在有限时间内，用户可以根据自己上一次事件的 cursor(游标)进行事件回溯或者追数据，适用于异常数据回溯，或者系统变更进行数据补录。
- 支持根据时间点进行变更数据回溯，支持根据游标进行变更数据回溯，支持从当前时间点进行数据变更 watch。
- 支持根据事件类型进行 watch 的能力，包括增、删、改。事件中包含全量的数据。
- 支持主机与主机关系数据变化的事件 watch 能力。
- 采用短长链的设计，当用户通过游标进行事件 watch 时，如果没有事件，则会保持会话连接，在 20s 内有事件变更则直接直接将事件推回。避免用户不断请求，同时保证用户能及时的拿到变更的数据。
- 支持批量事件 watch 能力，提升系统吞吐能力。
- 支持定制关注的事件数据字段，满足用户轻量级的 watch 需求。
链接：https://bk.tencent.com/docs/document/6.1/190/14399
事先先行
对接CMDB属于事件驱动，因此事件先行，先来分析通过API都能获取哪些事件：
- host 代表主机详情事件
- host_relation 代表主机的关系事件（主要使用）
- biz 代表业务详情事件
- set 代表集群详情事件
- module 代表模块详情事件
- process 代表进程详情事件
- object_instance 代表通用模型实例事件
- mainline_instance 代表主线模型实例事件
- biz_set 代表业务集事件
- biz_set_relation 代表业务集和业务的关系事件
以上事件未必都能用到，我们只要按需获取即可，这也体现了watch服务的灵活性！
动作其次
每类事件都有其相应的动作：
- create 创建
- delete 删除
- update 更新
我们的工作重点就是从事件中将增、删、改的动作分离出来，对下游系统进行事件回放，从而保证数据同步。
时间/事件回溯
虽然时间回溯最长间隔为3小时，我们还是希望对不同粒度的事件进行区分，原则如下：
- host_relation 主机关系事件，实时生效；
- module 模块事件，实时生效；
- set 集群事件、biz 业务事件等，可适当在不同时间间隔生效；
时间回溯保证我们能查到历史数据，而事件回溯的cursor游标能够保证我们避免重复的事件。
因此我们对于时间/事件回溯要有一个清醒的理解！
功能需求
通过API的分析，其实我们的功能需求也就同时梳理了出来：
- 核心目标：CMDB驱动资产同步，按业务/集群/模块/主机的结构与下游系统实现关系对应；
- 事件驱动：
1)biz 业务名同步；
2)set 集群名同步；
3)module 模块名同步；
4)host_relation 主机关系同步；
5)其他名称或关系同步；