【 TiDB 使用环境】生产环境
【 TiDB 版本】V6.5.8
【遇到的问题：问题现象及影响】 考虑到集群高可用场景，希望在同REGION内部署3个AZ的集群，3个AZ之间网络耗时都是小于1ms延迟的，想知道这种架构对线上读写请求的性能影响是怎么样的？例如：整体读耗时会增加多少这样的数据
AZ是啥啊
就是多机房，例如：在北京地区有三个机房，A,B,C，他们之间的网络延迟小于1ms
跨机房部署，网络耗时是双倍增长的，影响比较明显，看业务的接受程度
这个对网络要求太高了
测试过么？
是的，但是对于高可用场景&&考虑到成本预算，目前三AZ方案还是有需求的
可用区 (Availability Zone, AZ)
https://docs.pingcap.com/zh/tidb/stable/multi-data-centers-in-one-city-deployment#同区域三-az-方案
这个方案我看过，主要是不清楚对业务SQL耗时的影响，看来这块还真得压测下
到时候要考虑好机器的分布，label情况，网络带宽1ms应该是可以的，整体性能损失只能实际测试了
是的，这个估计要实际压测一下才知道
是同城三个机房吗？
你可以实际测一把，找个环境模拟下，用chaos-mesh工具为网络增加延迟
是的，同城三个机房
那你考虑下下面哪种拓扑结构适合你，https://docs.pingcap.com/zh/tidb/v7.1/multi-data-centers-in-one-city-deployment#同区域三-az-方案
同城3中心，可用性肯定是提高了，但是性能确实会有下降，主要还是网络的影响，写入延迟至少需要两倍 AZ 间的延迟，读数据一般是1倍以上延迟。
tidb对网络要求还是比较高的，如果想跨AZ部署的话，网络延迟最好控制在1ms以内。
另外还要看业务的接受程度，有些业务连1ms的延迟都无法接受，那这个跨AZ就没戏，业务能接受1ms的延迟，那还可以搞一把
在不考虑缓存等情况下，可以粗略地估计下：
- 一次写请求2PC过程tidb需要去pd 访问两次TSO，一去一回涉及2次Grpc往返请求。读请求涉及1次。
- tidb和tikv交互，如果是update则先查询回tidb内存再到tikv更新，涉及2次Grpc往返请求。如果是select涉及1次，如果是insert，也会去查询、加锁涉及2次Grpc。
- tikv内部三副本，假定不考虑异步分发的问题。raft log从Leader分发到两个follower，一去一回涉及2次Grpc往返请求。apply log阶段也是2次Grpc往返请求。
楼主可以看看上面的过程，如果AZ之间网络耗时每增加 0.1ms，那么在一次请求上这个延迟就会被放大好几次。当然这是理论预估值，实际上有专线的话，延迟可能会很低，建议如果有实际环境的可以做好充分的验证和测试。
外面也有用户是多中心部署方案的落地实践，说明这个也是可行的方案。
如果增加2倍延迟也能接受，网络层的耗时确实避免不了
按照这个流程，耗时会增加多倍，等我把环境准备好后验证一把，我理解这块的耗时主要是体现在两块：
1、TIDB–>PD这块【获取TSO】，毕竟PD只有主提供服务，其他两个AZ的TIDB请求PD确实耗时会增加
2、TIDB–>TIKV这块，如果能确保就近访问【同AZ内TIDB–>TIKV】还好，否则影响太大了
实际上，tidb 会有缓存tso ，可以大大缓解这个问题。
tikv默认情况下是读写leader那个副本，也可以通过label或者placement rule控制副本的存储位置，可以把leader和tidb放在一起，也能大大优化这个问题