从“两地三中心”到“三地五中心”的升级
从“两地三中心”升级到“三地五中心”,是基础设施的重大升级,不只是简单的数据副本的增加。其带来的架构改善有以下几点。
(1)数据库具备了城市级容灾能力。
(2)应用具备了城市级容灾能力,应用的部署可以实现城市1与城市2双中心的模式,应用的容灾能力增强。
(3)数据库的容量提升,只读副本数量增加,服务能力增强。这种升级同时也对原数据中心架构引入了新的挑战。
(1)跨城带来的耗时增加,对业务的批处理、链路整体耗时、热点行等产生影响。
(2)数据同步副本数增加,原有机房间的网络需扩容。
(3)数据同步副本数增加,原有租户的硬件资源扩容。在架构升级的过程中,需始终保持容灾能力不降低:任何单个机房出现故障后,集群依然可用,且除了主库所在城市1之外的其他城市机房出现故障,集群依然可用,依然能够提供服务。其过程如下。
(1)初始状态,如图3-1-7所示。
(2)城市2新增一个副本,该副本用于数据异步式同步,不参与一致性投票,该副本对原集群结构稳定性无影响。参与投票的依然是机房1、机房2、机房3,容灾策略与“两地三中心”一致,数据同步耗时无增加。“两地四副本”模式如图3-1-8所示。
(3)城市3新增一个副本,该副本数据实时同步,参与一致性投票,但需限定在选主时不能作为主库,以避免耗时的增加,因应用部署还在城市1。在这种模式下,城市2、城市3的单个城市故障不影响集群的稳定性。“三地五中心”模式如前面的图3-1-1所示。
(4)城市2的不参与投票副本切换为实时同步,并开始参与投票,完成“三地五中心”的部署。在任意一个城市的机房出现故障时,都能够实现容灾切换。以上过程中,如果机房5不选择部署全量副本,只是参与投票的日志副本,那么建设周期会较短,可以直接在城市2建设全量副本,完成后立即进行机房5的配置。
应用耗时分析与优化
“三地五中心”带来的事务耗时增加了跨城耗时部分,会对业务全链路耗时、热点行、批处理产生影响,需要在架构升级前进行耗时分析,在升级后进行耗时的监控与验证。
基于分布式的trace中间件,使用实时计算对链路上的应用日志、数据库日志进行解析,分析出业务链路的不同场景中的库依赖、SQL模板、SQL执行顺序与次数。然后按照“三地五中心”建设的库关联、应用部署城市,分析会增加耗时的SQL,从而计算出整体链路的耗时增加。根据评估结果进行耗时的优化,可考虑的方向有:缓存、应用部署、SQL的优化,以及异步化改造等。
热点行也会因为单次事务的耗时增加导致锁冲突加剧,热点行问题更加明显。可以在建设完成后进行压测,识别热点行,并有针对性地解决热点问题。
单次耗时的增加,也会导致批处理整体完成的时间延长,需要评估是否会超出业务可接受的完成时间。可考虑的优化方案有调整批处理分组数、调整锁粒度等。