【 TiDB 使用环境】生产环境
【 TiDB 版本】v6.1.7
【遇到的问题：问题现象及影响】 传统的MySQL主从复制是依赖binlog的，所以主实例写入变高后从解析binlog会成为瓶颈，这样会带来业务写完&&成功了【写：主】立刻去读会读不到数据【读：从】，但是对于tidb的架构，上层tidbsever是无状态的，写入成功意思是写到了tikv rocksdb的wal日志&&落盘&&符合raft机制，那真的不会存在在TIDB集群内写成功后立刻读会存在读不到数据的情况么？
不会，放心用。线性一致性就保证了写入之后，肯定能读到，而且是一致性读
不会的，写的时候是行锁，写完就没了
只要你commit了肯定能查到。。。
妥妥放心吧
他写完数据之后，写到了tikv rocksdb，然后写日志，落盘，这些操作都是操作的leader，只有写成功了。才会返回客户端成功的结果，当你写成功之后立马查询，他查的肯定是leader的mvcc最新版本的一个数据。而且tidb架构内部服务器要求的网络是2ms以内吧，也就是说，你完成之后，在2ms的时间数据会传到你说的从库。正常来说我公司没有用tidb主从结构。tidb架构本身坏掉任意一台服务器都没问题，没必要在搞一套从库服务器。
看来TIDB是支持强一致性读的
tidb设计上就是强一致的，不会读不到
我这边线下模拟一下，谢谢了
tidb是基于raft协议的，正常情况下，通过PD组件的调度和数据复制机制，可以保证数据的安全性和一致性。但是数据的写入和读取都是由 Leader 节点负责的，如果在 Leader 节点完成写入后发生故障或转移，新选举出的 Leader 节点可能会没有刚刚写入的数据，从而可能导致读不到数据的情况，不过这种概率特别小，不用担心
TiDB的读写是一致的，按照你写的例子，就是【写：主】，【读：主】。
也支持【读：从】，但是需要手工设置。
最后，请注意：TiDB里的主从是指副本，不是指节点。这里是和MySQL完全不一样的。
强一致性
tidb是 强一致性的
【读：从】也不会出现不一致好吧。。。读从也要从和主确认一致性的，而不是直接给结果
一致性的保证可以参考官方文档看看
Region 与 Raft 协议
Region 与副本之间通过 Raft 协议来维持数据一致性，任何写请求都只能在 Leader 上写入，并且需要写入多数副本后（默认配置为 3 副本，即所有请求必须至少写入两个副本成功）才会返回客户端写入成功。
https://docs.pingcap.com/zh/tidb/stable/tikv-overview#tikv-简介
1 个赞
一致性读 基本操作 毋庸置疑
如果基于raft共识算法 不能保证一致性 可以让google把当年的论文撤稿了 所有基于此的基础设施全部崩塌
2 个赞
唯一需要注意的就是tidb的默认事务隔离级别是RR不是RC。
https://docs.pingcap.com/zh/tidb/stable/system-variables#transaction_isolation
https://docs.pingcap.com/zh/tidb/stable/transaction-isolation-levels#可重复读隔离级别-repeatable-read
当事务隔离级别为可重复读时，只能读到该事务启动时已经提交的其他事务修改的数据，未提交的数据或在事务启动后其他事务提交的数据是不可见的。对于本事务而言，事务语句可以看到之前的语句做出的修改。
begin t1;
update t;
begin t2
commit t1;
select from t --RR事务隔离级别这个时候看不到update t ，因为begin t2的时候t1没有提交。
commit t2
select from t --这个时候才可以看到update t
1 个赞
不存在的，写入成功的其中一个标志是大部分副本都有数据
理论知识太扎实了~