携程数据库高可用架构实践

作者:携程技术团队,来自:DataFunTalk

导读:

我们推荐使用数据库三副本,一主一从一异地容灾。如果想要节省成本,也可以只保留两副本,但是一旦其中一台服务器发生故障,服务器维修时间会比较长,那么在维修期间,数据库服务会处于单点状态,使得风险急剧上升。

本文主要介绍以下内容:

  • SQL Server 高可用

  • MySQL 高可用

  • Redis 高可用

01

SQL Server 高可用

携程的 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 群集服务,尽快恢复业务。

携程数据库高可用架构实践_第1张图片

图1 三副本的 SQL Server 数据库服务架构

使用 AlwaysOn 架构可以极大减轻主节点的负载。数据库的全量备份或日志备份可以调整到异步节点上进行,无须担心数据库备份会对业务造成性能影响。我们会比较关注 AlwaysOn 的主从延迟,并采用插值法进行监控,对每一个业务数据库设计了一张监控表,定期插入时间戳。在经过 AlwaysOn 传递到辅助副本后,我们把时间戳取出来,和当前时间进行比较,就能精确地获得延迟时间。延迟通常是只读副本上的查询语句 IO 开销大导致的。根据延迟时间,以及前文提到的全量语句性能数据采集,我们可以定位导致延迟的异常语句。

02

MySQL 高可用

相对于成熟的商业数据库软件,开源版本的 MySQL 高可用方案更多地需要使用者自己进行设计和研发,好在 MySQL 本身已经为我们提供了一些必要的功能:MySQL 复制技术。MySQL 复制技术包含传统的基于日志传输的复制技术,以及在 MySQL 5.7 之后的版本引入的组复制技术。在携程,大部分 MySQL 集群采用传统的基于日志传输的复制技术。携程的 MySQL 高可用架构经历了3个阶段的演进。

第一阶段:采用传统的 MHA 管理方式,架构如图2所示。

携程数据库高可用架构实践_第2张图片

图2 传统的 MHA 架构

从本质上来说,MHA 是一个管理 MySQL 主从复制架构的工具集。我们可以通过其官方网站下载最新的版本。应用可以通过虚拟 IP 地址10.10.10.59进行访问,虚拟 IP 地址挂载在主节点上。MHA 管理节点会每隔10秒探测并连接主机,如果连续3次连接不上,则判定主机故障,触发切换。在发生切换时,MHA 会结合半同步复制,补全未同步的日志,这种切换可以保证数据完整。另外,切换会尝试连接旧主机,把挂载在主节点上的虚拟 IP 地址删除,然后在 Slave 节点重新挂载虚拟 IP 地址,完成切换。

传统的 MHA 架构比较成熟,使用广泛,但存在风险。如果由于交换机故障,MHA 管理节点连接不上主机,但主机本身运行正常,MHA 管理工具无法判断是网络故障还是服务器故障,就会进行切换,并且把虚拟 IP 地址挂载到 Slave 节点,但 MHA 管理节点连接不上旧主机,无法删除虚拟 IP 地址。此时两个节点都有虚拟 IP 地址存在,数据会发生"双写",也就是发生"脑裂"。这种情况很少发生,但一旦发生,就难以处理,起因就在于虚拟 IP 地址。解决的方法是把虚拟 IP 地址删除,使用物理 IP 地址进行直连。这就需要使用数据库访问 DAL 模块和统一配置中心。在切换时,需要通知应用程序 IP 地址发生变化,并对所有的连接进行重置。

第二阶段:使用 IP 直连,如图3所示。

携程数据库高可用架构实践_第3张图片

图3 IP 直连

初始的时候,应用程序使用物理 IP 地址10.10.10.141访问数据库。MHA 管理节点探测到主节点发生了故障,预备切换到10.10.10.142,并将 IP 地址变化通知统一配置中心 QConfig。统一配置中心在收到这个变化后,会把这个变化推送到应用服务器的数据库访问中间件 DAL。DAL 会重置对数据库的连接,使用新的 IP 地址10.10.10.142。此处的统一配置中心要确保高可用,即使机房发生故障,也不能影响统一配置中心的正常运转。

经过改造,我们去除了数据"双写"的隐患。但在极端场景下,还是会存在风险。如果机房整体发生故障,MHA 管理节点和主机/从机同时无法运行了,MHA 就无法自动切换到 DR 节点。这是由于 MHA 单管理节点本身成了系统瓶颈,解决的方法是引入多 MHA 管理节点进行协同管理。

第三阶段:引入多 MHA 管理节点,如图4所示。

携程数据库高可用架构实践_第4张图片

图4 IP 直连 + 多 MHA 管理节点

应用使用物理 IP 地址10.10.10.141访问数据库。每一个数据库实例都由5个 MHA 管理节点进行同时监听。这5个 MHA 管理节点分布在3个机房。一旦某个 MHA 管理节点探测到主机发生了异常,则标记为 SDOWN。但一个 MHA 管理节点无法决定主机是否真的发生了故障,该 MHA 管理节点需要发起协商流程,和其他4个 MHA 管理节点一同判断,如果多数 MHA 管理节点认为发生了故障,则标记为 ODOWN,也就是确定主机真的发生了故障。MHA 会检测并决定可以成为备选主节点的节点,并由5个 MHA 管理节点再次协商,推选一个管理节点,用来向统一配置中心 QConfig 汇报 IP 地址变化。如果机房发生故障,并且另一个节点10.10.10.142不可用,则可选择主节点为20.20.20.161。统一配置中心会把这个变化推送到 DAL 组件,并重置连接,使用新的 IP 地址。

五节点模式的 MHA 管理是稳定的。其中一个管理节点处于第三机房,能抵御单机房故障。MHA 管理节点之间的协商比较复杂,我们可以借助成熟的 Redis 哨兵管理机制,在 Redis 哨兵管理机制上进行改造,适配对 MySQL 的监控。

03

Redis 高可用架构

Redis 的高可用架构有两种通用的做法:一种是基于复制的主从模型,另一种是群集模型。携程使用的是第一种模型,即主从复制,其运行机制如图5所示。

携程数据库高可用架构实践_第5张图片

图5 Redis 运行机制

Redis 的元数据被存放在 ConfigDB 中。元数据包括 Redis 实例的状态信息,以及对应的 IP 地址和端口信息等。前端可以通过页面对元数据进行调整,如设置某个实例不可用或不可读等。服务是通过 Config Service 实现的。服务会从 ConfigDB 中拉取配置,应用会定期调用 Config Service 服务,获得实例元数据信息,实现对 Redis 群集的实际访问。

我们通过一致性哈希算法对 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 异地机房容灾及切换,这里就不介绍了,谢谢大家。

以上内容选自携程技术团队新作《携程架构实践》

特别推荐一个分享架构+算法的优质内容,还没关注的小伙伴,可以长按关注一下:

长按订阅更多精彩▼

如有收获,点个在看,诚挚感谢

你可能感兴趣的:(携程数据库高可用架构实践)