跨可用区部署可提高实例的可用性,本文档介绍使用跨可用区部署方式对于实例的影响。
使用跨可用区部署的 Kafka 实例前,应注意:
消息队列 Kafka版支持跨可用区部署 Kafka 实例,即支持多 AZ。跨可用区部署的实例具备更强的容灾能力,全方位保障集群数据的可靠性和服务的可用性。
在购买 Kafka 实例时,部署方式设置为跨可用区部署,并选择 3 个可用区即可实现跨可用区容灾。创建实例后,不可修改实例的部署方式,即单可用区部署的实例无法切换为跨可用区部署。跨可用区部署的实例在使用姿势上对客户端没有区别。但是建议客户端机器也分散到和服务端相同的多个可用区部署,以提升整体服务的可用性,也可以避免可用区孤立场景下的故障问题。
对于已购买的 Kafka 实例,您可以在 Kafka 实例的实例详情页签中基本信息区域找到可用区一行,查看可用区数量。如果可用区数量大于 1,表示该实例为跨可用区部署的实例。
跨可用区部署的实例,网络资源、计算节点、存储节点、ZooKeeper 等底层资源均会分散在多个可用区,故障在多个可用区之间互相隔离,确保单个可用区内的底层资源故障不影响其他可用区的节点。某个可用区内如果出现计算、存储等类型故障,在集群内部均可以切换到其他可用区,保障业务持续可用。但如果两个及以上的可用区发生故障,依然会影响服务可用性。
如果两个可用区之间出现网络故障,即无法相互通信,则可能会出现集群脑裂的现象,即两个可用区的节点都提供服务,但其中一个可用区的数据写入会在集群恢复后视为脏数据。为了避免出现脏数据,客户端的写入处理需要将 Ack 策略配置为 -1 或者 all,并且 minISR 副本数应大于一半最大副本数,例如 3 副本时应配置为 2 以上。
在集群网络恢复后,客户端无需任何操作即可恢复生产消费,但是由于服务端会重新对数据进行归一化,其中一个分裂节点的数据会被直接截断,但对于多副本跨区的数据存储方式来说,这种截断在 ack=-1 时也并不会导致数据丢失。
跨可用区部署的场景下,包括副本在内的数据会分散到多个可用区,数据请求链路也会分散至多个可用区,即默认不亲和,而多个可用区之间的网络延迟会 0.5~1ms 范围内,比可用区内略高,因此跨可用区部署对请求时延会有一定的影响,也会增加副本同步的延迟时长。客户端 Ack 参数大于 1、等于 -1 或 all 时,该时延会直接影响到消息生产的客户端写入耗时。与单可用区部署场景相比,多可用区部署时实例的吞吐量峰值能力通常会有 20% 以内的损耗。