第一个，第二个选项大家判断一下对错吧？自己分析原因如下：
1）第一个选项：tikv scheduler pool 是负责写请求，而不是读请求。应该是写写冲突吧？
2）第二个选项 fysnc 表示同步方式，raftsore 发往flower 的 log 是同步写还是异步写？
1 个赞
- 乐观事务模式也会有读写冲突，读等锁 2. 这里fsync到rocksdb指的是leader先写raft日志到raftdb（一个rocksdb实例）然后在apply该日志，发往follower后follower也是同样先写日志后在apply
1 个赞
第一个，不会回滚（根据三个CF的先后顺序，先右到左的检测，然后左到右的put）
参考：
https://asktug.com/t/topic/33550
第二个，单论raft log，是同步发送，然后append
参考：
1 个赞
第一个选项是错误的，问题在于会等待，但不会回滚事务，第二个选项是正确的，都会先在不是都会只在，也就是说必然会包含这一步，但还有后续的步骤
1 个赞
(1)请问在tikv scheduler pool是不是会进行检查write cf和lock cf的冲突检查?
(2)另外是不是还有好像还有一个快照snapshot的对比动作。检查写写冲突，如果写写冲突就回滚
1 个赞
有个锁对于同一个key的写有隔离作用，只能依次排队写入，snapshot的对比动作不是检查写写冲突，是检查版本，版本过期是失败
1 个赞
那tikv scheduler pool应该是会进行检查write cf和lock cf的冲突检查的吧？
1 个赞
根据我的理解，锁的检查是在kvdb里面执行的，是apply的线程池中的线程该干的事，scheduler pool说是检查锁其实并不准确
1 个赞
那A这个选项scheduler pool 进行读写冲突检测是检测啥内容？
1 个赞
我是觉得这个地方并不严谨，写写冲突检测，可能更靠谱，再说这个答案不是错的么，
写写冲突那个我指的latch，不是snapshot
确实不够严谨，悲观模式应该是无锁读，乐观模式会有读写冲突
write和lock在kvdb，apply这个动作是异步的，所以本质上scheduler的pool中的那个物理线程干了这两个冲突检查是不准确的，我是这个理解
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。