【 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放在一起,也能大大优化这个问题