这个是不是BUG？ #233
Comments
|
我好像明白了，即便是批量操作也是会有多个返回结果的，不可能就只有一个，但是 |
|
这里used命名是有问题的，应该是available，表示channel里面可用的大小。 |
vinllen
added a commit
that referenced
this issue
Feb 3, 2020
|
已在1.7版本修改为available，后面会正式发布在v2.0里面。1.7之前的版本不做修改。 |
vinllen
added a commit
that referenced
this issue
May 2, 2020
* add CI * in debug CI * in debug CI * in debug CI * in debugging CI * in debug CI * in debugging CI * in debug CI 2 * split sync code from sync.go to dbSync directory to make code clean * finish adjust sync mode code * update a lit * add cluster node list judge, only accpet role master. see #149 * update ChangeLog * update ChangeLOG 2 * add CI * in debug CI * in debug CI * in debug CI * in debugging CI * in debug CI * in debugging CI * in debug CI 2 * split sync code from sync.go to dbSync directory to make code clean * finish adjust sync mode code * update a lit * add cluster node list judge, only accpet role master. see #149 * update ChangeLog * update ChangeLOG 2 * merge commit in feature-1.6 manually. see pull/201 * resuming from break-point, in coding * add resume_from_break_point in configuration * resuming from break-point, in coding 2 * resuming from break-point, finish offset adjust * merge v1.6.24 manully * update some metrics * update, add run-id * almost finish resume from break-point * polish resume from breakpoint * release 1.7-unstable v1 * modify ChangeLog * restore add parameters judge when version >= 5.0 * cherry pick 3ea30b0 * update redis-go-cluster to add more log details * cherry pick 0e10b0d * bugfix of sendId, see #222 * improve: rename used -> available in delayChan. see #233 * block password, see #229 * set auth_type to 'auth' as default, see #237 * release v1.6.26 * modify ChangeLog * polish conf comment * merge 16.27 manually * 1. polish conf 2. add filter key for redis-shake-checkpoint * 1. polish conf 2. add filter key for redis-shake-checkpoint2 * unify offset by only one, step 1: modify checkpoint and add ut * unify offset by only one, step 2: modify syncIncrease.go. haven't test yet * unify offset by only one, step 3: finish test * finish cluster resuming from break point and pass simple test * update driver * add picture of resuming from break point * add picture of resuming from break point * add checkpoint and conf version * cherry pick 1d6c8ed from v1.6.28 * modify the checkpoint fcv * release v2.0 * merge v1.6.28 * update redis-go-cluster to remove SELECT judge, see #273 * disable target.db when enable resume_from_break_point * release v2.0.1
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
你好，我深入看一下逻辑代码，发现有一个点没想通：A为源redis，B为target redis，type=sync
阶段：增量更新
当每次A监听指令发送，都会执行一次 ds.addDelayChan(sendId.Get())，但是如果没有触发Flush的话，命令还是在Send层面。
监听B的响应处，有一个去拉去这个Channel，但是如果上述命令执行5000次，也就是有5000个delay chan，但是监听B的响应只拉一个，delay是不是会迟早塞满。
特别是qps特别高的时候1S内有100个操作，这个情况就会出现。
不应该是执行Flush的时候再去写这个ds.addDelayChan(sendId.Get())，并且
used := cap(ds.delayChannel) - len(ds.delayChannel)这种命名很容易产生混淆，我都不知道used对应的是余量还是使用了多少
The text was updated successfully, but these errors were encountered: