江苏龙网

  1. 首页 > 人文 > >

网易网易分布式数据库多活架构的演进与实践( 二 )


这个方案适用发展初期的业务 ， 提供了宿主机级别的容灾能力与读写分离的能力 。
网易网易分布式数据库多活架构的演进与实践
本文插图
除了异步复制、半同步复制外 ， MySQL从5.7之后便提供了MySQL Group Replication这种新型的复制模式 ， 相较于传统的主从方案 ， MGR提供了自动选主、数据强一致和主从皆可写入等能力 。 MGR在网易内部大量产品上都有不错的推广 。

网易网易分布式数据库多活架构的演进与实践
本文插图
无论是主从复制还是MGR都逃不开一个复制延迟的问题 ， MySQL复制的是Binlog ， Binlog发送到从节点到Binlog在从节点上回放执行有一段时间差 ， 这就是复制延迟 。
在主从切换时 ， 从节点必须回放完堆积的Binlog才能对外提供服务 ， 所以过大的复制延迟会导致不可控的主从切换时间 。 另外只读节点上复制延迟过大 ， 也会导致业务读到过时的数据 ， 可能影响到业务的正确性 。
MySQL后续版本提升了其并行复制的能力 ， 但仍然没能完全解决复制延迟过高的问题 ， 我们的做法是监控各个实例的TPS情况 ， 当达到可能触发复制延迟时就对集群做水平拆分（通过DDB的扩容完成） 。
业务上的话DDB提供了LOADBALANCE这样的hint语法 ， 允许业务指定SQL能容忍的复制延迟 ， 如果延迟超过设定的阈值 ， 则会调度到主节点执行 。
网易网易分布式数据库多活架构的演进与实践
本文插图
五、跨机房多活
如果业务有跨机房容灾的需求 ， 或单一机房内资源已经无法满足业务的发展需求时就有跨机房多活的需求了 。 最完善的方案是使用单元化来做 ， 但是单元化对业务的改造代价过大 ， 所以出现了一种折中的跨机房多活方案 。
网易网易分布式数据库多活架构的演进与实践
本文插图
此方案中业务层代码还是在每个机房部署一套 ， 但是在数据库的写操作和对一致性要求较高的读请求会路由到主机房 ， 而每个机房都有自己的只读实例提供一致性要求不太高的读请求 。
此方案提供了简单的跨机房容灾能力 ， 但是跨机房的读写会造成较大的延迟 ， 且对机房间的稳定性要求也较高 。
分享前我简单搭了一个实验环境 ， 测试了在相同的并发下不同的延迟对数据库性能的影响 。
网易网易分布式数据库多活架构的演进与实践
本文插图
当延迟上升到3ms时 ， 数据库性能下降在30%+ ， 当延迟上升到20ms时 ， 数据库性能下降在75%+ 。 而3ms和20ms刚好是同城多机房和跨城多机房的一个延迟标准 。
从数据上看 ， 同城情况下 ， 强一致的同步方案仍然是可行的 ， 而跨城的情况下 ， 基本只能用异步的同步方案了 。
六、跨机房单元化
应用仍然在每个机房对立部署 ， 但是机房内的应用只读写本机房的数据库 ， 为了避免多写带来的数据冲突 ， 每个机房只写自己负责的数据 ， 这就是跨机房单元化多活 。 这个方案中最重要的就是对流量的路由 ， 每个机房负责了一部分业务流量 ， 常见的划分方式为按照ID Hash划分 ， 或者按照地域划分 。
此方案解决了上面方案跨机房读写的延迟问题 ， 并且具有更好的水平扩展性 ， 唯一的弊端是业务改造代价较大 。 数据库层要提供较好的数据同步能力 ， 缓存、消息队列、RPC等组件都要做对应的改造 。
网易网易分布式数据库多活架构的演进与实践
本文插图
不同单元的数据库双向同步工作我们使用自研的网易数据运河（NDC）来完成 。 NDC对外主要提供了数据迁移/数据同步和数据订阅的能力 ， 数据同步将关系型数据库的数据实时同步到异构的对端数据库或数仓中 ， 数据订阅则将数据库的增量变更推送进消息队列 ， 供业务方或流计算任务消费 。


推荐阅读


上一篇：中新经纬|冰山冷热：上半年净利最高预亏3000万

下一篇：股东|中文在线：控股股东、实控人童之磊提前终止减持计划