数据库高可用设计方案

简介：大家好，我是程序员枫哥，🌟一线互联网的IT民工、📝资深面试官、🌹Java跳槽网创始人。拥有多年一线研发经验，曾就职过科大讯飞、美团网、平安等公司。在上海有自己小伙伴组建的副业团队，目前业余时间专注Java技术分享，春招/秋招/社招/跳槽，一对一学习辅助，项目接活开发。
🌈更多学习内容， 欢迎👏关注👀【文末】微信公众号：IT枫斗者
🌟🌟程序员找工作，就上Java跳槽网：www.javatiaocao.com

数据库高可用设计方案

MySQL复制技术实现业务层读写分离方案，本质上就是为了打造数据库的高可用，因为复制是高可用的基础。但只用复制同步数据又远远不够，还要结合自己的业务进行高可用设计。

什么是高可用？

• 高可用（High Availability）是系统所能提供无故障服务的一种能力。 简单地说就是避免因服务器宕机而造成的服务不可用。

• 我们都知道，高可用是每个业务系统设计时，开发人员必须考虑的关键点。比如你的系统在发生不可用时，业务表现如何？用户能否容忍你的不可用时长？

• 而业界度量高可用能力也有统一标准：判断宕机时间，并以此计算出每年系统可用时间达到几个 9，来判断高可用架构是否健壮。

• 

• 通常来说，系统至少要达到 4 个 9（99.99%），也就是每年宕机时间不超过 52.56 分钟，否则用户体验会非常差，感觉系统不稳定。

高可用架构设计

• 系统要达到高可用，一定要做好软硬件的冗余，消除单点故障（SPOF single point of failure）。
• 冗余是高可用的基础，通常认为，系统投入硬件资源越多，冗余也就越多，系统可用性也就越高。
• 除了做好冗余，系统还要做好故障转移（Failover）的处理。也就是在最短的时间内发现故障，然后把业务切换到冗余的资源上。
• 在明确上述高可用设计的基本概念后之后，我们来看一下高可用架构设计的类型：无状态服务高可用设计、数据库高可用架构设计。

无状态服务高可用设计

• 无状态的服务（如 Nginx ）高可用设计非常简单，发现问题直接转移就行，甚至可以通过负载均衡服务，当发现有问题，直接剔除：

• 

• 上图中，当第一台 Ningx 服务器出现问题，导致服务不可用，Load Balance 负载均衡服务发现后，就可以直接把它剔除。

• 对于上层用户来说，他只会在几秒内的访问出现问题，之后服务就立刻恢复了。无状态的服务，高可用设计就是这么简单。

数据库高可用架构设计

• 所以，系统高可用设计，真正的难点、痛点不在于无状态服务的设计，而在于数据库的高可用设计，这是因为：
  • 数据持久化在数据库中，是有状态的服务；
  • 数据库的容量比较大，Failover 的时间相对无状态服务会更多；
  • 一些系统，如金融场景的数据库，会要求数据完全不能丢失，这又增加了高可用实现的难度。
• 其实从架构角度看，数据库高可用本身也是业务高可用，所以我们要从业务全流程的角度出发，思考数据库的高可用设计。

基于数据层的数据库高可用架构

• 基于数据层的数据库高可用架构，就是基于数据同步技术。当主服务器 Master 发生宕机，则故障转移到从服务器 Slave。

• 对于 MySQL 数据库来说，就是基于前面介绍的复制技术，如果主服务器发生宕机，做如下操作就行了：

• 

• 可以发现，我们原先的 Slave3 从服务器提升为了新主机，然后建立了新的复制拓扑架构，Slave2、Slave3 都连到新 Master 进行数据同步。

基于业务层的数据库高可用架构

• “基于业务层的数据库高可用架构设计”则完全基于业务实现，数据库只是用于存储数据。

• 当一台数据库主服务器不可用，业务直接写另一台数据库主服务器就可以了。我们来看一 下这个架构：

• 

• 从上图可以看到，Service 服务写入 Master1 主服务器失败后，不用等待故障转移程序启用主从切换，而是直接把数据写入 Master2 主服务器。

• 这看似是一种非常简单、粗暴的高可用架构实现方式，但能符合这样设计的业务却并不多，因为该设计前提是状态可修改。

• 比如电商中的订单服务，其基本逻辑就是存储电商业务中每笔订单信息，核心逻辑就是往表Orders 中插入数据，即：

• INSERT INTO Orders(o_orderkey, ... ) VALUES (...)
  

• 这里 o_orderkey 是主键。为了实现基于业务层的数据库高可用，可以在主键生成过程中加入额外信息，比如服务器编号，这样订单的主键设计变为了： PK = 有序UUID-服务器编号。这样的话，当写入服务器编号 1 时失败了，业务层会把订单的主键修改为服务器编号 2，这样就实现了业务层的高可用，电商中的这种订单号生成方式也称为“跳单”。

• 而当查询订单信息时，由于主键中包含了服务器编号，那么业务知道该笔订单存储在哪台服务器，就可以非常快速地路由到指定的服务器。

融合的高可用架构设计

• “基于业务层的数据库高可用架构”中，虽然通过跳单设计，可以实现写入业务的高可用实现。但这时订单服务的查询功能会受到极大影响。在上面的例子中，当发生宕机时，服务器编号为 1 的订单无法查询。

• 所以，我们可以在业务和数据层相结合的层面来设计一个融合的高可用设计。这个架构可以解决宕机后，查询服务受限的问题。其架构图如下所示：

• 

• 上图中，将不同编号的订单根据不同的数据库进行存放，比如服务器编号为 1 的订单存放在数据库 DB1 中，服务器编号为 2 的订单存放在数据库 DB2 中。

• 此外，这里也用到了 MySQL 复制中的部分复制技术，即左上角的主服务器仅将 DB1 中的数据同步到右上角的服务器。同理，右上角的主服务器仅将 DB2 中的数据同步到左上角的服务器。下面的两台从服务器不变，依然从原来的 MySQL 实例中同步数据。