oracle的事务提交成功以redo log写入成功为标识，而tidb则要等待apply完毕才算提交成功。如果提前到rocksdb的raft committed阶段结束会不会好一点？
tidb是多节点啊，需要保证一致性。
这是分布式环境，不一样
原理不一样啊，tidb是以mvcc控制分布式事务的
oracle 是commit了，最新的数据放内存里面就行了，等落盘。分布式数据库要把数据同步给大多数的
tidb分布式事务强一致性，raft log committed阶段数据是已经持久化，也就是多副本已收到raft数据并返回消息给leader，而应用层事务提交要等raft log应用到rocksdb kv才算结束。
分布式和集中式的区别一下子就出来了~
Oracle在提交时，为保证线性一致性，需要修改undo段头事务表(内存中的，不用立即落盘)，让事务对其他会话可见，写入redo(必须写入磁盘)，保证事务持久性，实例宕机也能恢复。
Tidb在提交时，为了保证线性一致性，需要等待apply完成，这样才能让其他会话看到，同时在这之前，要保证raft 层面commit，写入多个节点，保证单个节点宕机数据不丢失
2 个赞
rocksdb 加raft
架构的一样锕
我理解是commit了就要保证数据不丢，即持续性。
所以oracle单节点时默认本地redo log写完就好，而分布式tidb要保证完成多数派写，因为万一本地写成功的节点挂了，其他2个节点还是旧数据，就不能保证commit的持续性。
oracle默认是要等redo log落盘才返回commit成功的，少数非交互式的场景可使用commit write nowait实现你说的异步提交。
分布式的要等同步到别的节点才行啊
这是分布式环境呢
oracle不也是支持事务的吗？支持事务的话不都得遵循mvcc吗？oracle 又是怎么来控制事务的呢？
实际上redo log被LGWR进程写到文件就提供了事务恢复的条件。对应是rockdb raft日志的commit。apply的过程跟oracle块数据回磁盘是对应的。所以感觉应该是可以搞的。
设计理念都不一样，没有必要学习他
tidb对应的应该是写到存储数据的rocksdb的WAL
那么怎样理解enable-async-apply-prewrite这个参数呢？如果设置为true，是否就不用等待apply了？会影响读一致性吗
学习到了