2024-06-18 blue-VH-driver-订阅组态相关分析

摘要:

2024-06-18 blue-VH-driver-订阅组态相关分析

订阅组态相关:

1. 组态
   1. 枚举位号
      1. 过滤条件错误，错误码转换
      2. 枚举位号过程中，与VH断开连接
      3. 枚举位号时，VH查询超时
   2. 组态订阅
      1. 过滤条件的订阅，
         1. 开关，确定是否开启该功能
         2. 缓存的VH的组态，应该是标准数据服务提供的最小的结构体
         3. 和VH断开
            1. TODO: LoginDB组态服务器的IP地址，是怎么填。
               1. 同时填主组态服务器地址，以及从组态服务器地址
            2. 断开的时机
               1. 发起订阅时断开
                  1. 发起前断开
                  2. 订阅过程中断开
               2. 订阅成功后断开
      2. 位号名修改
         1. TODO: 和VH方确认回调的接口，
            1. 情况一: 删除后，新建位号
            2. 情况二: 保持位号id不变，但是位号名被修改
      3. 组态更新的时候，先处理删除，再处理修改， 再处理新增。
2. 实时订阅
   1. 创建订阅
      1. 与VH断开连接
         1. 立即向上层返回失败
   2. 添加位号
      1. 与VH断开连接
         1. 添加前断开
         2. 添加时断开
      2. 位号不存在
         1. 全部不存在
         2. 部分不存在
      3. 添加位号的数量超过VH单个订阅分组的阈值
   3. 删除位号
      1. 与VH断开连接
         1. 删除前断开
         2. 删除时断开
      2. 位号不存在
   4. 删除订阅
      1. 与VH断开连接
         1. 仅清理订阅任务数据
      2. 已清除应用端的订阅关系，但由于异步调用，导致VH的解除订阅关系通知延迟收到
   5. 获取订阅数据
      1. 与VH断开连接:
   6. 断线后重连
      1. 恢复所有已添加的位号
   7. 订阅成功后， 位号重命名、位号删除
3. 实时读
   1. 与VH断开连接
      1. 发起前断开
      2. 异步读请求发起后断开
4. 实时写
   1. 与VH断开连接
      1. 发起前断开
      2. 异步读请求发起后断开
5. 流量控制，限流
   1. TODO: 要不要做
   2. 限制哪些接口的流量
6. 配置文件中，功能开关
   1. 流量控制
   2. 是否开启组态订阅
7. 调试跟踪方式方法
   1. 动态配置
8. 断开重连后
   1. 单机的场景
      1. 重连后，会重新推送一次位点。导致缓存的位点重复。
   2. 主从的场景
      1. 重连后，一定会重新推送一次第一次的位点。导致缓存的位点重复。

1.1 创建订阅分组成功, 但是激活订阅分组失败

1. 调用VH接口删除已经创建的订阅分组
   1. 无论否删除成功，都返回
   2. 不做重试删除已经创建的订阅分组，避免无法结束调用

1.2 向订阅分组添加的位号的数据量超过单个订阅分组的阈值

1. 创建订阅任务时，订阅任务内，准备持有多个订阅分组
2. 添加位号时，找到一个可容纳该位号数量的订阅分组
   1. 如果找到，则在该订阅分组内添加位号
   2. 如果未找到，创建新的订阅分组，创建成功后，立即激活该订阅分组。 然后再向该订阅分组添加位号

1.3 向订阅分组添加位号, 一部分添加成功，一部分添加失败

1. 该接口对外返回失败
2. 但是接口返回的response里，记录哪些是添加成功的，哪些是添加失败的。
3. 添加失败的位号
   1. VH本身并不会再状态改变时继续添加。
      1. 例如: 向订阅分组添加位号时，该位号不存在。随后该位号被创建，并不会被自动添加到订阅分组中。
   2. 驱动不对添加失败的位号做重试。
4. 添加失败的部分位号, 由调用方重新添加订阅。

1.4 向订阅分组删除位号，一部分删除成功，一部分删除失败

1. 该接口对外返回失败
2. 但是接口返回的response里，记录哪些是添加成功的，哪些是添加失败的。
3. 添加失败的位号， 驱动不对删除失败的位号做重试。
4. 删除失败的部分位号, 由调用方重新从订阅分组中删除。

1.5 删除整个订阅任务，订阅任务中含有多个订阅分组，一部分订阅分组退订成功，一部分订阅分组退订失败

1. 对退订失败的订阅分组，一直做重新退订的尝试。
2. TODO: 可能存在一直无法退订成功的情况，导致接口无法返回。

1.6 位号名被修改，导致订阅分组中持有的位号，被删除

1. 位号名被修改，被处理成先删除该位号，然后添加一个全新的位号。
2. 订阅分组中，持有的位号，被删除。
3. 被修改名称后的位号，由标准数据服务调用方负责重新向分组添加订阅。

1.7 驱动与VH断开连接，对给标准数据服务的接口的数据的影响

1. 标准数据服务调用方，调用bool IsReady() 接口，主动获取驱动的状态是否正常。驱动不主动去通知标准数据服务。
2. 标准数据服务，调用需要与VH进行交互的服务，返回状态错误。
3. 标准数据服务，获取订阅分组的通知的数据，获取位号的变化通知，不对数据做下线的特殊标识。正常获取。
   1. 如果标准数据服务不调用IsReady()， 那么就不知道驱动已经与VH断开连接。
   2. 由于驱动与VH断开连接，所以不会收到位号变化通知。标准数据服务将驱动内缓存的数据获取完后，将一直获取空数据。

1.8 驱动与VH断开连接后, 与VH重连, 恢复已订阅的位号

1. 创建订阅任务，订阅任务内保持在断线重连后，需要重新订阅的位号。
2. 恢复已订阅的位号，创建一个新的线程去处理。此线程模拟客户端线程。
3. 当收到位号变化通知时，主要是删除位号时，对保持的在断线重连后需要恢复的位号做删除。
4. 断线重连，重新订阅位号时，遵循订阅任务的订阅分组逻辑。
5. 当有添加订阅位号未成功时，一直重试，直到所有的位号都被添加订阅成功。
6. 断线重连的状态，当还未恢复完已订阅的位号前，不对外提供服务。
   1. TODO:  恢复已订阅的位号时，出错就一直重试，可能存在死循环的逻辑。导致可能一直不对外提供服务。

1.9 通知位号删除的回调函数，给出的是位号的id, 但是向组态订阅添加位号是使用tagName, 从订阅组态删除位号使用的是位号的subId

1.  需要能获取 <位号id →位号tagName>， 需要维护此全局的缓存，并且在位号增加/删除/更新的时候，维护更新此缓存。
2.  当通知位号删除时, 通过位号id，拿到位号tagName, 清理掉持有的位号的，避免在重连恢复位号订阅的时候，订阅不存在的位号。

核心设计类图: