x-xy-y opened a new issue #1161:
URL: https://github.com/apache/servicecomb-service-center/issues/1161
我在调查 watch 的推送延迟问题， 阅读代码 (版本 abed95307df6cb1ef61b5d123ff8d308c337e7ee) 看到
datasource/etcd/state/etcd/cacher_kv.go: KvCacher.handleDeferEvents 函数
```
func (c *KvCacher) handleDeferEvents(ctx context.Context) {
defer log.Recover()
var (
evts = make([]kvstore.Event, sdcommon.EventBlockSize)
i int
)
interval := 300 * time.Millisecond
timer := time.NewTimer(interval)
defer timer.Stop()
for {
select {
case <-ctx.Done():
return
case evt, ok := <-c.Cfg.DeferHandler.HandleChan():
if !ok {
log.Error("replay channel is closed", nil)
return
}
if i >= sdcommon.EventBlockSize {
c.onEvents(evts[:i])
evts = make([]kvstore.Event,
sdcommon.EventBlockSize)
i = 0
}
evts[i] = evt
i++
timeutil.ResetTimer(timer, interval)
case <-timer.C:
timer.Reset(interval)
if i == 0 {
continue
}
c.onEvents(evts[:i])
evts = make([]kvstore.Event, sdcommon.EventBlockSize)
i = 0
}
}
}
```
不是很理解这里的机制
1. 首先是为什么需要做缓冲，再批量调 onEvents ？问题在于，onEvents 好像没有聚合 evts 的逻辑，就是说，如果 onEvents
里也是对所有事件逐行处理的话，与在 KvCacher 不做缓冲直接调，效果是一样的，而且现在这样产生了额外的延迟。
1.1 这个缓冲的大小 EventBlockSize = 800 及 300ms 的延迟是如何选择的？我的疑惑是，什么业务场景或测试用例下，会用满
800 的缓冲，从而无须走到 300ms 延迟后的分支里？
2. 为什么这里要调 timeutil.ResetTimer 重置计时器，如果每 50 ms 产生一个事件，连续 100
个事件，由于这个计时器一直重置，第一个事件至少要 5 秒才会传到 onEvents ？感觉正是由于这一行代码，导致了极大的延迟。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
