谈谈数据库的高可用架构

前言

本篇文章讨论一下数据库高可用的相关架构。

1. 数据库的高可用

数据库的高可用从下面几点考虑

• 高可用
• 高性能
• 可拓展
• 一致性

1.1 水平切分

主要解决单数据库中数据量过多的问题。水平划分成多个库负载均衡。

1.1.1 如何划分数据

• 通过范围
  • 时间或者主键id划分，缺点是各个库的压力不均
• 通过哈希 建议
  • 存储查询时取模计算在那个库，缺点是当两个库拓展成三个库时麻烦，（数据需要迁移）
• 通过统一路由服务
  • 业务与路由算法解耦

1.2 一主多从 读写分离

单个主数据库搭配多个从数据库来进行使用。主库负责写入，从库负责读取。同步主库和从库的数据。当水平切分遇到主从复制时，划分成的1库和2库分别进行读写分离。

1.2.1 遇到的问题

数据同步不一致 有一定时间差 (还未同步数据就去读取)

通常使用中间件或者强制读主的方式来解决中从数据不一致性问题

• 中间件
  • 当某个key有写操作时，在不一致的时间窗口范围中关于这个key的读也路由到主库中去读。不再通过从库去读。
• 强制读主
  • 也就是双主高可用的架构

单个主库也会成为单点，MHA可以在主库产生故障时进行切换，选举一个读库作为主库。一主在写多的场景下也会产生瓶颈，因而拓展主库也是某些场景需要的。

1.3 多主多从

单个写库还是不能保证写高可用，需要冗余写库。

1.3.1 多个写库写到那个库中？

1. 通过多个写库不同的初始值，相同步长进行递增。
   • 1写库的id为 0 2 4 8 ... 2写库的id为 1 3 5 7
2. 通过业务层来生成唯一的id 保证数据不冲突

同时带来的问题也是数据需要同步的地方增多，数据延迟严重。

1.4 主备进行高可用

主备架构，只有主库提供读写服务，备库冗余作故障转移用

通过虚ip漂移，对业务层透明，不需要人工介入

优点是读写没有延时(写完就可以读)，没有数据一致性问题。
不足的是不能通过加从库拓展读性能。资源利用率为50%，一台冗余主没有提供服务。但如果进行双主同时提供服务(负载均衡)可以解决这一点，但加了会有数据一致性问题如1.5中所说。

1.4.1 通过 Keepalived + MySQL 实现双主热备高可用方案

Keepalived 也就是通过虚拟ip，实现双主对外的统一接口，自动检查，失败切换机制，自动切换防止单点故障。

Keepalived基础是通过VRRP协议

1. VRRP (Virtual Router Redundancy Protocol) 虚拟路由冗余协议。在VRRP中有两组重要的概念：VRRP路由器和虚拟路由器，主控路由器和备份路由器。
2. VRRP路由器是指运行VRRP的路由器，是物理实体，虚拟路由器是指VRRP协议创建的，是逻辑概念。一组VRRP路由器协同工作，共同构成一台虚拟路由器。Vrrp中存在着一种选举机制，用以选出提供服务的路由即主控路由，其他的则成了备份路由。当主控路由失效后，备份路由中会重新选举出一个主控路由，来继续工作，来保障不间断服务。

1.5 双主架构 负载均衡

两个主库同时提供服务，负载均衡。

读写性能相对主备架构得到提升，资源利用率更高。

存在数据一致性问题，也可以水平拓展。但水平拓展会多一层数据同步，同步时间变长。

带来的问题是数据一致性问题以及主键冲突问题(可以通过分布式id解决)

1.6 从库中如何优化

• 为从库加入索引 索引可以不同。主库可以不使用索引，从库使用不同的索引（从库使用场景各不相同）。
• 增加从库
  • 从库越多 同步也慢，同步慢 数据不一致窗口越大。
• 增加缓存
  • 也会带来数据不一致性问题

参考资料博客

• 公众号 架构师之路
• https://www.cnblogs.com/kevingrace/p/6710136.html
• https://www.cnblogs.com/littlecharacter/p/9084291.html

谈谈数据库的高可用架构

原文：https://www.cnblogs.com/wei57960/p/12267962.html