变更通知:Nacos 的推拉结合与配置中心的长轮询

  监听者数 | 发布次数 | 收到回调数/应收 | 延迟 最小 / 中位 / 最大(ms)  | 同一次发布各监听者收到时间的跨度,中位(ms)
  -----+------+----------+----------------------+------------------------
  1    | 30   | 30/30    | 14.7 / 71.3 / 127.4  | 0.0                    
  30   | 10   | 300/300  | 54.3 / 121.9 / 156.9 | 1.9                    
  add_listener 返回(子进程打印 ready)之后,到每个监听者都收到过第一次推送的时间:1 个监听者 6.2 s;30 个监听者 6.1 s(这段时间里的发布没有回调,所以上表只统计生效之后的发布)
  发布调用(POST)自己也要花时间;这里的延迟从调用发出之前算起,所以包含服务端处理发布的时间

  方式               | 收到变更数 | 延迟 最小 / 中位 / 最大(ms)      | 50 s 里发出的 HTTP 请求数
  -----------------+-------+--------------------------+-------------------
  Nacos 推送(SDK 监听) | 10/10 | 39.1 / 63.0 / 130.6      | (gRPC 长连接,没有统计)   
  短轮询 1 s          | 9/10  | 164.7 / 603.2 / 1010.6   | 52                
  短轮询 5 s          | 6/10  | 1272.3 / 2131.0 / 4445.9 | 11                
  长轮询(最多挂起 10 s)   | 10/10 | 0.4 / 0.8 / 1.6          | 13                
  short1(间隔 1 s)没有看到的变更:m3(与下一次变更相隔 0.15 s)
  short5(间隔 5 s)没有看到的变更:m1(与下一次变更相隔 0.56 s), m3(与下一次变更相隔 0.15 s), m4(与下一次变更相隔 2.07 s), m5(与下一次变更相隔 1.18 s)
  轮询看到的是“轮询那一刻的最新值”,所以没看到的变更对应上面与下一次变更的间隔;短轮询的请求数只取决于间隔,与变更多少无关;长轮询在没有变化时每个超时周期发一次请求,有变化时立即返回

  情形          | 恢复后收到的回调数 | 最后一个回调的内容     | 最后一个回调距恢复 | 恢复后的全部回调(内容@距恢复秒数)
  ------------+-----------+---------------+-----------+-------------------
  (a)冻住 5 s   | 1         | f2            | 0.00 s    | f2@0.00           
  (b)冻住 45 s  | 1         | f2            | 0.22 s    | f2@0.22           
  (c)Nacos 重启 | 1         | after-restart | 0.07 s    | after-restart@0.07
ERRORS {}