Wu Yun

> 前的设计是没问题的，因为同 db（那肯定也包含同 key）的 binlog 会被分到相同的 worker 中，因为这个 worker 是 binlog worker，它只有一个 bg_thread 对任务进行取出和应用，所以不存在一致性的问题。调用顺序 这里是写binlog的一致性的原因，key一致性的保证在PikaReplClient::ScheduleWriteDBTask的实现里面，取出redis_command的第一个操作对象作hash散列到write_db_workers_中，这样保证了写单key一定被同一个线程write_db_workers_执行，保证了一致性。 但是有个疑问，这里感觉只保证了Set, Del这种操作的一致性，但如果是SUnionStore这种呢？考虑以下场景： 1. SAdd set1 "1" 2. SAdd set2 "2" 3. SRem set1 "1" 4....

> > > 前的设计是没问题的，因为同 db（那肯定也包含同 key）的 binlog 会被分到相同的 worker 中，因为这个 worker 是 binlog worker，它只有一个 bg_thread 对任务进行取出和应用，所以不存在一致性的问题。调用顺序 > > > > > > 这里是写binlog的一致性的原因，key一致性的保证在PikaReplClient::ScheduleWriteDBTask的实现里面，取出redis_command的第一个操作对象作hash散列到write_db_workers_中，这样保证了写单key一定被同一个线程write_db_workers_执行，保证了一致性。 但是有个疑问，这里感觉只保证了Set, Del这种操作的一致性，但如果是SUnionStore这种呢？考虑以下场景： > > > > 1....

这个改动不一定合理，我看了前面的相关pr，有提到rtc最好是拦截单key。同时如果是但是哪怕纯内存也比较慢的操作不能走rtc。

> 可以把当前 RedisCache 开启的命令都加回来，我们这边目前已经解决了缓存和数据库数据一致性的问题 done

> 刚发现，你的改动好像是在pika/src或者是pika/include下，是不应该修改 pika/tools/migrate_tool下呢？ 3.5当时直接在src下面改了，我不知道重新commit会不会导致你以前的review记录没了，所以想着review结束了再和4.0一样放到tools下面。当时unstable分支下面有这个工具，3.5没有，我就直接在src下面改了。

> 这里我尝试使用该工具进行迁移，发现其仅将sst文件下载到migrate-tool本地，但是没有将命令转发给下游 @guozhihao-224 可以贴一下pika_migrate用的conf吗？还有使用场景是啥样的呢？

> > > 这里我尝试使用该工具进行迁移，发现其仅将 sst 文件下载到 migrate-tool 本地，但是没有将命令转发给下游 > > > > > > @guozhihao-224可以贴一下pika_migrate用的conf吗？还有使用场景是啥样的呢？ > > 是pika3.5.5 迁移到 3.5.5版本，100GB量级的数据 > > 这里测试后，发现有将命令往下转发给下游，但是我发现，设置redis-sender-num大于8的话，就会在转发一部分数据后卡住不动了，设置成其他值会的比如5 — 8 之间，也会突然出现卡住不执行的状态。有试过设置为2能够跑完迁移任务，但是设置为2后，迁移时间太长了，100GB的数据的迁移1个多小时 > > 是否有死锁的情况出现 对应的conf：...

> 感觉tools下代码太多了，net,pstd这些可以感觉可以直接用pika下的。然后cache这些其实作为migrate工具来说也不需要。 done，简化了一下，把net、storage、pstd和cache全删了，直接使用主目录下的 @wangshao1