xinyin025/learn.lianglianglee.com
1
0
Fork 0
mirror of https://github.com/zhwei820/learn.lianglianglee.com.git synced 2025-09-25 04:36:41 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity
85b6063789
learn.lianglianglee.com/专栏/MySQL实战宝典/17 高可用设计：你怎么活用三大架构方案？.md.html
周伟 0f006e4e9b add
2022-05-11 18:57:05 +08:00

857 lines
24 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<!-- saved from url=(0046)https://kaiiiz.github.io/hexo-theme-book-demo/ -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1.0, user-scalable=no">
<link rel="icon" href="/static/favicon.png">
<title>17 高可用设计：你怎么活用三大架构方案？.md.html</title>
<!-- Spectre.css framework -->
<link rel="stylesheet" href="/static/index.css">
<!-- theme css & js -->
<meta name="generator" content="Hexo 4.2.0">
</head>
<body>
<div class="book-container">
<div class="book-sidebar">
<div class="book-brand">
<a href="/">
<img src="/static/favicon.png">
<span>技术文章摘抄</span>
</a>
</div>
<div class="book-menu uncollapsible">
<ul class="uncollapsible">
<li><a href="/" class="current-tab">首页</a></li>
</ul>
<ul class="uncollapsible">
<li><a href="../">上一级</a></li>
</ul>
<ul class="uncollapsible">
<li>
<a href="/专栏/MySQL实战宝典/00 开篇词 从业务出发，开启海量 MySQL 架构设计.md.html">00 开篇词 从业务出发，开启海量 MySQL 架构设计.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/01 数字类型：避免自增踩坑.md.html">01 数字类型：避免自增踩坑.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/02 字符串类型：不能忽略的 COLLATION.md.html">02 字符串类型：不能忽略的 COLLATION.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/03 日期类型：TIMESTAMP 可能是巨坑.md.html">03 日期类型：TIMESTAMP 可能是巨坑.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/04 非结构存储：用好 JSON 这张牌.md.html">04 非结构存储：用好 JSON 这张牌.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/05 表结构设计：忘记范式准则.md.html">05 表结构设计：忘记范式准则.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/06 表压缩：不仅仅是空间压缩.md.html">06 表压缩：不仅仅是空间压缩.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/07 表的访问设计：你该选择 SQL 还是 NoSQL？.md.html">07 表的访问设计：你该选择 SQL 还是 NoSQL？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/08 索引：排序的艺术.md.html">08 索引：排序的艺术.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/09 索引组织表：万物皆索引.md.html">09 索引组织表：万物皆索引.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/10 组合索引：用好，性能提升 10 倍！.md.html">10 组合索引：用好，性能提升 10 倍！.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/11 索引出错：请理解 CBO 的工作原理.md.html">11 索引出错：请理解 CBO 的工作原理.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/12 JOIN 连接：到底能不能写 JOIN？.md.html">12 JOIN 连接：到底能不能写 JOIN？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/13 子查询：放心地使用子查询功能吧！.md.html">13 子查询：放心地使用子查询功能吧！.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/14 分区表：哪些场景我不建议用分区表？.md.html">14 分区表：哪些场景我不建议用分区表？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/15 MySQL 复制：最简单也最容易配置出错.md.html">15 MySQL 复制：最简单也最容易配置出错.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/16 读写分离设计：复制延迟？其实是你用错了.md.html">16 读写分离设计：复制延迟？其实是你用错了.md.html</a>
</li>
<li>
<a class="current-tab" href="/专栏/MySQL实战宝典/17 高可用设计：你怎么活用三大架构方案？.md.html">17 高可用设计：你怎么活用三大架构方案？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/18 金融级高可用架构：必不可少的数据核对.md.html">18 金融级高可用架构：必不可少的数据核对.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/19 高可用套件：选择这么多，你该如何选？.md.html">19 高可用套件：选择这么多，你该如何选？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/20 InnoDB Cluster：改变历史的新产品.md.html">20 InnoDB Cluster：改变历史的新产品.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/21 数据库备份：备份文件也要检查！.md.html">21 数据库备份：备份文件也要检查！.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/22 分布式数据库架构：彻底理解什么叫分布式数据库.md.html">22 分布式数据库架构：彻底理解什么叫分布式数据库.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/23 分布式数据库表结构设计：如何正确地将数据分片？.md.html">23 分布式数据库表结构设计：如何正确地将数据分片？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/24 分布式数据库索引设计：二级索引、全局索引的最佳设计实践.md.html">24 分布式数据库索引设计：二级索引、全局索引的最佳设计实践.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/25 分布式数据库架构选型：分库分表 or 中间件 ？.md.html">25 分布式数据库架构选型：分库分表 or 中间件 ？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/26 分布式设计之禅：全链路的条带化设计.md.html">26 分布式设计之禅：全链路的条带化设计.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战宝典/27 分布式事务：我们到底要不要使用 2PC？.md.html">27 分布式事务：我们到底要不要使用 2PC？.md.html</a>
</li>
</ul>
</div>
</div>
<div class="sidebar-toggle" onclick="sidebar_toggle()" onmouseover="add_inner()" onmouseleave="remove_inner()">
<div class="sidebar-toggle-inner"></div>
</div>
<script>
function add_inner() {
let inner = document.querySelector('.sidebar-toggle-inner')
inner.classList.add('show')
}
function remove_inner() {
let inner = document.querySelector('.sidebar-toggle-inner')
inner.classList.remove('show')
}
function sidebar_toggle() {
let sidebar_toggle = document.querySelector('.sidebar-toggle')
let sidebar = document.querySelector('.book-sidebar')
let content = document.querySelector('.off-canvas-content')
if (sidebar_toggle.classList.contains('extend')) { // show
sidebar_toggle.classList.remove('extend')
sidebar.classList.remove('hide')
content.classList.remove('extend')
} else { // hide
sidebar_toggle.classList.add('extend')
sidebar.classList.add('hide')
content.classList.add('extend')
}
}
function open_sidebar() {
let sidebar = document.querySelector('.book-sidebar')
let overlay = document.querySelector('.off-canvas-overlay')
sidebar.classList.add('show')
overlay.classList.add('show')
}
function hide_canvas() {
let sidebar = document.querySelector('.book-sidebar')
let overlay = document.querySelector('.off-canvas-overlay')
sidebar.classList.remove('show')
overlay.classList.remove('show')
}
</script>
<div class="off-canvas-content">
<div class="columns">
<div class="column col-12 col-lg-12">
<div class="book-navbar">
<!-- For Responsive Layout -->
<header class="navbar">
<section class="navbar-section">
<a onclick="open_sidebar()">
<i class="icon icon-menu"></i>
</a>
</section>
</header>
</div>
<div class="book-content" style="max-width: 960px; margin: 0 auto;
overflow-x: auto;
overflow-y: hidden;">
<div class="book-post">
<p id="tip" align="center"></p>
<div><h1>17 高可用设计：你怎么活用三大架构方案？</h1>
<p>我们前面学习了 MySQL 数据库复制的原理、优化，以及基于复制技术实现业务层的读写分离方案，这些内容都是为了铺垫 MySQL 数据库的高可用架构设计。因为复制是高可用的基础，但只用复制同步数据又远远不够，你还要结合自己的业务进行高可用设计。</p>
<p>同时，高可用也不仅仅是数据库的事情，你要从业务的全流程出发，思考怎么设计一个真正健壮的高可用架构。</p>
<p>现在，我们先来看看什么是高可用？为什么它如此重要。</p>
<h3>高可用概念</h3>
<p>首先，我们来看一下 wiki 上对高可用（High Availability）的定义：</p>
<blockquote>
<p><em>High availability (HA) is a characteristic of a system which aims to ensure an agreed level of operational performance, usually uptime, for a higher than normal period.</em></p>
</blockquote>
<p>从上面的描述来看，高可用（High Availability）是<strong>系统所能提供无故障服务的一种能力</strong>。 简单地说就是避免因服务器宕机而造成的服务不可用。</p>
<p>我们都知道，高可用是每个业务系统设计时，开发人员必须考虑的关键点。比如你的系统在发生不可用时，业务表现如何？用户能否容忍你的不可用时长？</p>
<p>而业界度量高可用能力也有统一标准：判断宕机时间，并以此计算出每年系统可用时间达到几个 9，来判断高可用架构是否健壮。具体如下表所示：</p>
<p><img src="assets/Cgp9HWDQD-SAUpH5AAJjBtN-SRQ153.png" alt="图片1.png" /></p>
<p>通常来说，系统至少要达到 4 个 9（99.99%），也就是每年宕机时间不超过 52.56 分钟，否则用户体验会非常差，感觉系统不稳定。</p>
<p><em><strong>99.99% = 1 - 52.56 / (365*24*60)</strong></em></p>
<p>不过 4 个 9 宕机 52 分钟对于生产环境的影响还是比较大，但是 5 个 9 对大部分系统来说要求又太高。所以一些云服务商会提出一个 99.995% 的可用性概念，那么系统一年的不可用时长为：</p>
<p><em><strong>不可用时长 = (1 - 99.995%)*365*24*60 = 26.28 (分钟)</strong></em></p>
<p>即一年最多的影响服务的时间为 26.28 分钟。</p>
<p>简单了解“高可用”有多么重要之后，接下来我们就来看一下，怎么设计高可用架构。</p>
<h3>高可用架构设计</h3>
<p>系统要达到高可用，一定要做好软硬件的冗余，消除单点故障（SPOF single point of failure）。</p>
<p>冗余是高可用的基础，通常认为，系统投入硬件资源越多，冗余也就越多，系统可用性也就越高。</p>
<p>除了做好冗余，系统还要做好故障转移（Failover）的处理。也就是在最短的时间内发现故障，然后把业务切换到冗余的资源上。</p>
<p>在明确上述高可用设计的基本概念后之后，我们来看一下高可用架构设计的类型：<strong>无状态服务高可用设计、数据库高可用架构设计。</strong></p>
<h3>无状态服务高可用设计</h3>
<p>无状态的服务（如 Nginx ）高可用设计非常简单，发现问题直接转移就行，甚至可以通过负载均衡服务，当发现有问题，直接剔除：</p>
<p><img src="assets/Cgp9HWDQD-yAZa9GAAFC3XH5bN0451.png" alt="图片2.png" /></p>
<p>上图中，当第一台 Ningx 服务器出现问题，导致服务不可用，Load Balance 负载均衡服务发现后，就可以直接把它剔除。</p>
<p>对于上层用户来说，他只会在几秒内的访问出现问题，之后服务就立刻恢复了。无状态的服务，高可用设计就是这么简单。</p>
<h3>数据库高可用架构设计</h3>
<p>所以，系统高可用设计，真正的难点、痛点不在于无状态服务的设计，而在于数据库的高可用设计，这是因为：</p>
<ul>
<li>数据持久化在数据库中，是有状态的服务；</li>
<li>数据库的容量比较大，Failover 的时间相对无状态服务会更多；</li>
<li>一些系统，如金融场景的数据库，会要求数据完全不能丢失，这又增加了高可用实现的难度。</li>
</ul>
<p>其实从架构角度看，数据库高可用本身也是业务高可用，所以我们要从业务全流程的角度出发，思考数据库的高可用设计。</p>
<p>我在这里提供了三种数据库的高可用架构设计方法，它们不但适用于 MySQL 数据库，也适用于其他数据库。</p>
<h4>基于数据层的数据库高可用架构</h4>
<p>基于数据层的数据库高可用架构，就是基于数据同步技术。当主服务器 Master 发生宕机，则故障转移到从服务器 Slave。</p>
<p>对于 MySQL 数据库来说，就是基于前面介绍的复制技术。对于 16 讲的读写分离架构，如果主服务器发生宕机，做如下操作就行了：</p>
<p><img src="assets/Cgp9HWDQD_SAE1FOAAGGwtRmgxQ798.png" alt="图片3.png" /></p>
<p>可以发现，我们原先的 Slave3 从服务器提升为了新主机，然后建立了新的复制拓扑架构，Slave2、Slave3 都连到新 Master 进行数据同步。</p>
<p>为了在故障转移后对 Service 服务无感知，所以需要引入 VIP（Virtual IP）虚拟 IP 技术，当发生宕机时，VIP 也需要漂移到新的主服务器。</p>
<p>那么这个架构的真正难点在于：</p>
<ol>
<li>如何保障数据一致性；</li>
<li>如何发现主服务器宕机；</li>
<li>故障转移逻辑的处理；</li>
</ol>
<p>我们可以通过 MySQL 提供的无损复制技术，来保障“数据一致性”。而“发现主服务器宕机”“处理故障转移逻辑”要由数据库高可用套件完成，我们 20 讲再来学习。</p>
<h4>基于业务层的数据库高可用架构</h4>
<p>第二种“基于业务层的数据库高可用架构设计”则完全基于业务实现，数据库只是用于存储数据。</p>
<p>当一台数据库主服务器不可用，业务直接写另一台数据库主服务器就可以了。我们来看一下这个架构：</p>
<p><img src="assets/CioPOWDQEC2AZb6zAAGEbb1d9mA777.png" alt="图片4.png" /></p>
<p>从上图可以看到，Service 服务写入 Master1 主服务器失败后，不用等待故障转移程序启用主从切换，而是直接把数据写入 Master2 主服务器。</p>
<p>这看似是一种非常简单、粗暴的高可用架构实现方式，但能符合这样设计的业务却并不多，因为该设计前提是<strong>状态可修改</strong>。</p>
<p>比如电商中的订单服务，其基本逻辑就是存储电商业务中每笔订单信息，核心逻辑就是往表Orders 中插入数据，即：</p>
<pre><code>INSERT INTO Orders(o_orderkey, ... ) VALUES (...)
</code></pre>
<p>这里 o_orderkey 是主键。为了实现基于业务层的数据库高可用，可以在主键生成过程中加入额外信息，比如服务器编号，这样订单的主键设计变为了：</p>
<p><strong>PK = 有序UUID-服务器编号</strong></p>
<p>这样的话，当写入服务器编号 1 时失败了，业务层会把订单的主键修改为服务器编号 2，这样就实现了业务层的高可用，电商中的这种订单号生成方式也称为“跳单”。</p>
<p>而当查询订单信息时，由于主键中包含了服务器编号，那么业务知道该笔订单存储在哪台服务器，就可以非常快速地路由到指定的服务器。</p>
<p>但这样设计的前提是整个服务的写入主键是可以进行跳单设计，且查询全部依赖主键进行搜索。</p>
<p>看到这里，你是不是觉得非常符合 NoSQL 的 KV 访问设计呢？别忘了前面介绍的 Memcached Plugin 哦。</p>
<h4>融合的高可用架构设计</h4>
<p>刚刚“基于业务层的数据库高可用架构”中，虽然通过跳单设计，可以实现写入业务的高可用实现。但这时订单服务的查询功能会受到极大影响。在上面的例子中，当发生宕机时，服务器编号为 1 的订单无法查询。</p>
<p>所以，我给出一种业务和数据层相结合的高可用设计。这个架构可以解决宕机后，查询服务受限的问题。其架构图如下所示：</p>
<p><img src="assets/Cgp9HWDQEDWAZ2elAAGdIYpgnI4256.png" alt="图片5.png" /></p>
<p>上图中，将不同编号的订单根据不同的数据库进行存放，比如服务器编号为 1 的订单存放在数据库 DB1 中，服务器编号为 2 的订单存放在数据库 DB2 中。</p>
<p>此外，这里也用到了 MySQL 复制中的部分复制技术，即左上角的主服务器仅将 DB1 中的数据同步到右上角的服务器。同理，右上角的主服务器仅将 DB2 中的数据同步到左上角的服务器。下面的两台从服务器不变，依然从原来的 MySQL 实例中同步数据。</p>
<p><strong>这样做得好处是：</strong></p>
<ul>
<li>在常态情况下，上面两台 MySQL 数据库是双活的，都可以有数据的写入，业务的性能得到极大提升。</li>
<li>订单数据是完整的，服务器编号为 1 和 2 的数据都在一个 MySQL 实例上。</li>
<li>更重要的是，这样当发生宕机时，Service 服务的写入不受到影响，写入服务器编号为 1 的订单通过跳单设计写入 DB2。</li>
<li>同时，对于订单读取也不会受到影响，因为数据都是一个实例上，如：</li>
</ul>
<p><img src="assets/Cgp9HWDQEFOAeB45AAF92xVslwY929.png" alt="图片6.png" /></p>
<p>多活</p>
<h3>总结</h3>
<p>这一讲我们学习了系统设计中最为重要的高可用设计，这是业务系统设计中必须考虑的一点。生产环境没有高可用，是根本无法完成上线工作的。</p>
<p>这一讲我建议你反复阅读，加深自己对于高可用系统设计的理解。因为这些思想不限于 MySQL数据库，而是适用所有数据库以及业务系统。</p>
<p>最后，我来总结下今天的内容：</p>
<ol>
<li>高可用是系统所能提供无故障服务的一种能力，度量单位是几个 9；</li>
<li>线上系统高可用目标应不低于 99.995%，否则系统频繁宕机，用户体验不好；</li>
<li>高可用实现基础是：冗余 + 故障转移；</li>
<li>无状态服务的高可用设计较为简单，直接故障转移或剔除就行；</li>
<li>数据库作为有状态的服务，设计比较复杂（冗余通过复制技术实现，故障转移需要对应的高可用套件）；</li>
<li>数据库高可用有三大架构设计，请务必牢记这几种设计。</li>
</ol>
</div>
</div>
<div>
<div style="float: left">
<a href="/专栏/MySQL实战宝典/16 读写分离设计：复制延迟？其实是你用错了.md.html">上一页</a>
</div>
<div style="float: right">
<a href="/专栏/MySQL实战宝典/18 金融级高可用架构：必不可少的数据核对.md.html">下一页</a>
</div>
</div>
</div>
</div>
</div>
</div>
<a class="off-canvas-overlay" onclick="hide_canvas()"></a>
</div>
<script defer src="https://static.cloudflareinsights.com/beacon.min.js/v652eace1692a40cfa3763df669d7439c1639079717194" integrity="sha512-Gi7xpJR8tSkrpF7aordPZQlW2DLtzUlZcumS8dMQjwDHEnw9I7ZLyiOj/6tZStRBGtGgN6ceN6cMH8z7etPGlw==" data-cf-beacon='{"rayId":"7099732059673d60","version":"2021.12.0","r":1,"token":"1f5d475227ce4f0089a7cff1ab17c0f5","si":100}' crossorigin="anonymous"></script>
</body>
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-NPSEEVD756"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag() {
dataLayer.push(arguments);
}
gtag('js', new Date());
gtag('config', 'G-NPSEEVD756');
var path = window.location.pathname
var cookie = getCookie("lastPath");
console.log(path)
if (path.replace("/", "") === "") {
if (cookie.replace("/", "") !== "") {
console.log(cookie)
document.getElementById("tip").innerHTML = "<a href='" + cookie + "'>跳转到上次进度</a>"
}
} else {
setCookie("lastPath", path)
}
function setCookie(cname, cvalue) {
var d = new Date();
d.setTime(d.getTime() + (180 * 24 * 60 * 60 * 1000));
var expires = "expires=" + d.toGMTString();
document.cookie = cname + "=" + cvalue + "; " + expires + ";path = /";
}
function getCookie(cname) {
var name = cname + "=";
var ca = document.cookie.split(';');
for (var i = 0; i < ca.length; i++) {
var c = ca[i].trim();
if (c.indexOf(name) === 0) return c.substring(name.length, c.length);
}
return "";
}
</script>
</html>
Reference in New Issue View Git Blame Copy Permalink