携程数据库高可用架构实践
Posted DataFunTalk
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了携程数据库高可用架构实践相关的知识，希望对你有一定的参考价值。
编辑整理：Hoh
内容来源：《携程架构实践》
出品平台：DataFunTalk
注：转载请在后台留言“转载”。
导读：飞机有两个发动机，用于实现高可用。如果一个发动机出现故障，另一个发动机还能够持续工作，数据库运维也是如此。我们需要多个副本，一旦某个节点发生故障，另外一个节点可以继续提供服务。我们还需要考虑到机房发生故障的场景，需要有快速切换到异地容灾机房的能力。
我们推荐使用数据库三副本，一主一从一异地容灾。如果想要节省成本，也可以只保留两副本，但是一旦其中一台服务器发生故障，服务器维修时间会比较长，那么在维修期间，数据库服务会处于单点状态，使得风险急剧上升。
本文主要介绍以下内容：
SQL Server 高可用
mysql 高可用
Redis 高可用
携程的 SQL Server 高可用架构经过了多次演进。最初使用的是镜像技术，如果服务器出现故障，在切换时，需要人工进行干预以切换到镜像节点。同时镜像节点不提供读服务，可扩展性比较差。后来引入了 SAN 存储，将计算和存储进行分离，可以实现自动切换，但 SAN 存储技术过于复杂，并且价格昂贵。2013年，我们开始将其逐步改造为 AlwaysOn 架构，这是 SQL Server 2012 以后的版本所具有的功能。
图1显示了三副本的 SQL Server 数据库服务架构。主副本提供读写访问；一个辅助副本是同步模式，即和主副本数据保持一致；另一个辅助副本是异步模式，存放在异地机房。同步模式可以保证主从数据一致，在切换时不会丢失数据。但同步节点的性能可能会对主副本造成影响，每一个事务都需要在同步节点确认后，才算完成。所以，将同步节点和主节点放在同一网段内，可以减少网络开销，提升整体的响应速度。
SQL Server 可以在主副本服务器发生故障时，自动切换到同步节点。在切换期间，数据库不可用，所以通常在1分钟之内完成。而切换到异步节点是手动触发的，因为是异步模式，可能会丢失数据，所以尽量不切换到异步节点。
SQL Server 高可用在很大程度上依赖于底层操作系统。因为 AlwaysOn 架构依赖底层的 Windows 群集服务。一个 Windows 群集可以有多套 AlwaysOn 组。Windows 群集服务可以这样设计：
尽量增加群集节点数量，一般保持在9个以上的奇数节点，避免一台或两台服务器故障导致整个群集不可用；
因为群集节点多，所以增加 regroup 的超时时间，避免重组超时导致整个群集异常；
增加文件共享仲裁，文件共享可以存放在第三机房，避免机房故障导致群集失去多数仲裁，同时在失去多数仲裁时，可以使用 ForceQuorum 模式强制启动 Windows 群集服务，尽快恢复业务。
使用 AlwaysOn 架构可以极大减轻主节点的负载。数据库的全量备份或日志备份可以调整到异步节点上进行，无须担心数据库备份会对业务造成性能影响。我们会比较关注 AlwaysOn 的主从延迟，并采用插值法进行监控，对每一个业务数据库设计了一张监控表，定期插入时间戳。在经过 AlwaysOn 传递到辅助副本后，我们把时间戳取出来，和当前时间进行比较，就能精确地获得延迟时间。延迟通常是只读副本上的查询语句 IO 开销大导致的。根据延迟时间，以及前文提到的全量语句性能数据采集，我们可以定位导致延迟的异常语句。
相对于成熟的商业数据库软件，开源版本的 MySQL 高可用方案更多地需要使用者自己进行设计和研发，好在 MySQL 本身已经为我们提供了一些必要的功能：MySQL 复制技术。MySQL 复制技术包含传统的基于日志传输的复制技术，以及在 MySQL 5.7 之后的版本引入的组复制技术。在携程，大部分 MySQL 集群采用传统的基于日志传输的复制技术。携程的 MySQL 高可用架构经历了3个阶段的演进。
第一阶段：采用传统的 MHA 管理方式，架构如图2所示。
第二阶段：使用 IP 直连，如图3所示。
经过改造，我们去除了数据"双写"的隐患。但在极端场景下，还是会存在风险。如果机房整体发生故障，MHA 管理节点和主机/从机同时无法运行了，MHA 就无法自动切换到 DR 节点。这是由于 MHA 单管理节点本身成了系统瓶颈，解决的方法是引入多 MHA 管理节点进行协同管理。
第三阶段：引入多 MHA 管理节点，如图4所示。
五节点模式的 MHA 管理是稳定的。其中一个管理节点处于第三机房，能抵御单机房故障。MHA 管理节点之间的协商比较复杂，我们可以借助成熟的 Redis 哨兵管理机制，在 Redis 哨兵管理机制上进行改造，适配对 MySQL 的监控。
Redis 的高可用架构有两种通用的做法：一种是基于复制的主从模型，另一种是群集模型。携程使用的是第一种模型，即主从复制，其运行机制如图5所示。
我们通过一致性哈希算法对 Redis 进行分片。每一个分片都被称为组。在每一个组中，有读写实例和只读实例，它们会通过复制关系来传递数据。在部署时，我们尽量把实例分散到不同的服务器上。一旦服务器发生故障，则只会影响部分分片，不会严重影响后端数据库。我们应当尽量控制 Redis 缓存的每一个实例为 10GB 左右。如果超过 10GB，则可能需要确定是否可以进行拆分。若需要重新进行分组，则多拆分出几个组。
Redis 由哨兵来监控 Redis 实例的运行状态。我们启用了5个哨兵来同时监听。哨兵的主要功能为：
监控所有实例是否在正常运行；
当 Slave 出现故障时，通过消息通知机制把该 Slave 拉出，并将其设置为不可用，同时把 Master 设置为可读、可写；
当 Master 出现故障时，通过自动投票机制从 Slave 节点中选举新的 Master，实现 Redis 的自动切换。
哨兵实际上是一个运行在特殊模式下的 Redis 服务，我们可以通过在启动命令参数中指定 sentinel 选项，来标识该 Redis 服务是哨兵。每一个哨兵会向其他哨兵，即 Master 和 Slave 定时发送消息，以确认对方是否正常运行，如果发现对方在指定时间内未回应，则暂时认为对方主观挂机 ( Subjective Down，简称 SDOWN )。如果哨兵群中的多数哨兵都报告某个 Master 没响应，系统就会认为该 Master 客观挂机 ( Objective Down，简称 ODOWN )。
通过 Redis 的运行机制可以看出，Config Service 的状态信息需要和 Redis 实例的实际状态信息保持一致，否则在访问应用时会发生异常，比如，当只读实例发生故障，在重新向 Master 节点全量同步数据期间，如果该实例还是配置可读，在访问应用时就会报错。当有故障发生时，Redis 需要具备快速自动恢复的能力，减少人工干预。我们应当尽量从哨兵处获得信息，如果超过半数的哨兵发生故障，则直连 Redis 实例来获得物理状态。
对于 Redis 异地机房容灾而言，我们需要考虑跨机房全量同步为网络带来的开销，以及可能存在的网络不稳定因素。因此，我们采用了一个中间层，即 Keeper 来对数据进行缓冲。在本质上，Keeper 是伪 Slave，即实现 Redis 协议，伪装成 Slave，让 Master 推送数据到 Keeper 中。受限于篇幅，对于 Redis 异地机房容灾及切换，这里就不介绍了，谢谢大家。
—— 新书推荐 ——
扫描下方二维码，进入购书页面
目前可享50元优惠~
社群推荐：
关于我们：
一个在看，一段时光！ 以上是关于携程数据库高可用架构实践的主要内容，如果未能解决你的问题，请参考以下文章