mirror of
https://github.com/zhwei820/learn.lianglianglee.com.git
synced 2025-09-26 13:16:41 +08:00
340 lines
29 KiB
HTML
340 lines
29 KiB
HTML
<!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>01 高并发系统：它的通用设计方法是什么？.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="/专栏/高并发系统设计40问/00 开篇词 为什么你要学习高并发系统设计？.md.html">00 开篇词 为什么你要学习高并发系统设计？</a>
|
||
</li>
|
||
<li>
|
||
<a class="current-tab" href="/专栏/高并发系统设计40问/01 高并发系统：它的通用设计方法是什么？.md.html">01 高并发系统：它的通用设计方法是什么？</a>
|
||
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/02 架构分层：我们为什么一定要这么做？.md.html">02 架构分层：我们为什么一定要这么做？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/03 系统设计目标（一）：如何提升系统性能？.md.html">03 系统设计目标（一）：如何提升系统性能？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/04 系统设计目标（二）：系统怎样做到高可用？.md.html">04 系统设计目标（二）：系统怎样做到高可用？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/05 系统设计目标（三）：如何让系统易于扩展？.md.html">05 系统设计目标（三）：如何让系统易于扩展？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/06 面试现场第一期：当问到组件实现原理时，面试官是在刁难你吗？.md.html">06 面试现场第一期：当问到组件实现原理时，面试官是在刁难你吗？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/07 池化技术：如何减少频繁创建数据库连接的性能损耗？.md.html">07 池化技术：如何减少频繁创建数据库连接的性能损耗？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/08 数据库优化方案（一）：查询请求增加时，如何做主从分离？.md.html">08 数据库优化方案（一）：查询请求增加时，如何做主从分离？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/09 数据库优化方案（二）：写入数据量增加时，如何实现分库分表？.md.html">09 数据库优化方案（二）：写入数据量增加时，如何实现分库分表？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/10 发号器：如何保证分库分表后ID的全局唯一性？.md.html">10 发号器：如何保证分库分表后ID的全局唯一性？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/11 NoSQL：在高并发场景下，数据库和NoSQL如何做到互补？.md.html">11 NoSQL：在高并发场景下，数据库和NoSQL如何做到互补？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/12 缓存：数据库成为瓶颈后，动态数据的查询要如何加速？.md.html">12 缓存：数据库成为瓶颈后，动态数据的查询要如何加速？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/13 缓存的使用姿势（一）：如何选择缓存的读写策略？.md.html">13 缓存的使用姿势（一）：如何选择缓存的读写策略？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/14 缓存的使用姿势（二）：缓存如何做到高可用？.md.html">14 缓存的使用姿势（二）：缓存如何做到高可用？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/15 缓存的使用姿势（三）：缓存穿透了怎么办？.md.html">15 缓存的使用姿势（三）：缓存穿透了怎么办？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/16 CDN：静态资源如何加速？.md.html">16 CDN：静态资源如何加速？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/17 消息队列：秒杀时如何处理每秒上万次的下单请求？.md.html">17 消息队列：秒杀时如何处理每秒上万次的下单请求？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/18 消息投递：如何保证消息仅仅被消费一次？.md.html">18 消息投递：如何保证消息仅仅被消费一次？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/19 消息队列：如何降低消息队列系统中消息的延迟？.md.html">19 消息队列：如何降低消息队列系统中消息的延迟？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/20 面试现场第二期：当问到项目经历时，面试官究竟想要了解什么？.md.html">20 面试现场第二期：当问到项目经历时，面试官究竟想要了解什么？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/21 系统架构：每秒1万次请求的系统要做服务化拆分吗？.md.html">21 系统架构：每秒1万次请求的系统要做服务化拆分吗？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/22 微服务架构：微服务化后，系统架构要如何改造？.md.html">22 微服务架构：微服务化后，系统架构要如何改造？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/23 RPC框架：10万QPS下如何实现毫秒级的服务调用？.md.html">23 RPC框架：10万QPS下如何实现毫秒级的服务调用？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/24 注册中心：分布式系统如何寻址？.md.html">24 注册中心：分布式系统如何寻址？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/25 分布式Trace：横跨几十个分布式组件的慢请求要如何排查？.md.html">25 分布式Trace：横跨几十个分布式组件的慢请求要如何排查？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/26 负载均衡：怎样提升系统的横向扩展能力？.md.html">26 负载均衡：怎样提升系统的横向扩展能力？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/27 API网关：系统的门面要如何做呢？.md.html">27 API网关：系统的门面要如何做呢？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/28 多机房部署：跨地域的分布式系统如何做？.md.html">28 多机房部署：跨地域的分布式系统如何做？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/29 Service Mesh：如何屏蔽服务化系统的服务治理细节？.md.html">29 Service Mesh：如何屏蔽服务化系统的服务治理细节？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/30 给系统加上眼睛：服务端监控要怎么做？.md.html">30 给系统加上眼睛：服务端监控要怎么做？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/31 应用性能管理：用户的使用体验应该如何监控？.md.html">31 应用性能管理：用户的使用体验应该如何监控？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/32 压力测试：怎样设计全链路压力测试平台？.md.html">32 压力测试：怎样设计全链路压力测试平台？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/33 配置管理：成千上万的配置项要如何管理？.md.html">33 配置管理：成千上万的配置项要如何管理？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/34 降级熔断：如何屏蔽非核心系统故障的影响？.md.html">34 降级熔断：如何屏蔽非核心系统故障的影响？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/35 流量控制：高并发系统中我们如何操纵流量？.md.html">35 流量控制：高并发系统中我们如何操纵流量？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/36 面试现场第三期：你要如何准备一场技术面试呢？.md.html">36 面试现场第三期：你要如何准备一场技术面试呢？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/37 计数系统设计（一）：面对海量数据的计数器要如何做？.md.html">37 计数系统设计（一）：面对海量数据的计数器要如何做？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/38 计数系统设计（二）：50万QPS下如何设计未读数系统？.md.html">38 计数系统设计（二）：50万QPS下如何设计未读数系统？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/39 信息流设计（一）：通用信息流系统的推模式要如何做？.md.html">39 信息流设计（一）：通用信息流系统的推模式要如何做？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/40 信息流设计（二）：通用信息流系统的拉模式要如何做？.md.html">40 信息流设计（二）：通用信息流系统的拉模式要如何做？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/加餐 数据的迁移应该如何做？.md.html">加餐 数据的迁移应该如何做？</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/期中测试 10道高并发系统设计题目自测.md.html">期中测试 10道高并发系统设计题目自测</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/用户故事 从“心”出发，我还有无数个可能.md.html">用户故事 从“心”出发，我还有无数个可能</a>
|
||
</li>
|
||
<li>
|
||
<a href="/专栏/高并发系统设计40问/结束语 学不可以已.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>01 高并发系统：它的通用设计方法是什么？</h1>
|
||
<p>我们知道，高并发代表着大流量，高并发系统设计的魅力就在于我们能够凭借自己的聪明才智设计巧妙的方案，从而抵抗巨大流量的冲击，带给用户更好的使用体验。这些方案好似能操纵流量，让流量更加平稳得被系统中的服务和组件处理。</p>
|
||
<p>来做个简单的比喻吧。</p>
|
||
<p>从古至今，长江和黄河流域水患不断，远古时期，大禹曾拓宽河道，清除淤沙让流水更加顺畅；都江堰作为史上最成功的的治水案例之一，用引流将岷江之水分流到多个支流中，以分担水流压力；三门峡和葛洲坝通过建造水库将水引入水库先存储起来，然后再想办法把水库中的水缓缓地排出去，以此提高下游的抗洪能力。</p>
|
||
<p>而我们在应对高并发大流量时也会采用类似“抵御洪水”的方案，归纳起来共有三种方法。</p>
|
||
<ul>
|
||
<li>Scale-out（横向扩展）：分而治之是一种常见的高并发系统设计方法，采用分布式部署的方式把流量分流开，让每个服务器都承担一部分并发和流量。</li>
|
||
<li>缓存：使用缓存来提高系统的性能，就好比用“拓宽河道”的方式抵抗高并发大流量的冲击。</li>
|
||
<li>异步：在某些场景下，未处理完成之前，我们可以让请求先返回，在数据准备好之后再通知请求方，这样可以在单位时间内处理更多的请求。</li>
|
||
</ul>
|
||
<p>简单介绍了这三种方法之后，我再详细地带你了解一下，这样当你在设计高并发系统时就可以有考虑的方向了。当然了，这三种方法会细化出更多的内容，我会在后面的课程中深入讲解。</p>
|
||
<p>首先，我们先来了解第一种方法：<strong>Scale-out。</strong></p>
|
||
<h2>Scale-up vs Scale-out</h2>
|
||
<p>著名的“摩尔定律”是由 Intel 的创始人之一戈登·摩尔于 1965 年提出的。这个定律提到，集成电路上可容纳的晶体管的数量约每隔两年会增加一倍。</p>
|
||
<p>后来，Intel 首席执行官大卫·豪斯提出“18 个月”的说法，即预计 18 个月会将芯片的性能提升一倍，这个说法广为流传。</p>
|
||
<p>摩尔定律虽然描述的是芯片的发展速度，但我们可以延伸为整体的硬件性能，从 20 世纪后半叶开始，计算机硬件的性能是指数级演进的。</p>
|
||
<p>直到现在，摩尔定律依然生效，在半个世纪以来的 CPU 发展过程中，芯片厂商靠着在有限面积上做更小的晶体管的黑科技，大幅度地提升着芯片的性能。从第一代集成电路上只有十几个晶体管，到现在一个芯片上动辄几十亿晶体管的数量，摩尔定律指引着芯片厂商完成了技术上的飞跃。</p>
|
||
<p>但是有专家预测，摩尔定律可能在未来几年之内不再生效，原因是目前的芯片技术已经做到了 10nm 级别，在工艺上已经接近极限，再往上做，即使有新的技术突破，在成本上也难以被市场接受。后来，双核和多核技术的产生拯救了摩尔定律，这些技术的思路是将多个 CPU 核心压在一个芯片上，从而大大提升 CPU 的并行处理能力。</p>
|
||
<p>我们在高并发系统设计上也沿用了同样的思路，将类似追逐摩尔定律不断提升 CPU 性能的方案叫做 Scale-up（纵向扩展），把类似 CPU 多核心的方案叫做 Scale-out，这两种思路在实现方式上是完全不同的。</p>
|
||
<ul>
|
||
<li>Scale-up，通过购买性能更好的硬件来提升系统的并发处理能力，比方说目前系统 4 核 4G 每秒可以处理 200 次请求，那么如果要处理 400 次请求呢？很简单，我们把机器的硬件提升到 8 核 8G（硬件资源的提升可能不是线性的，这里仅为参考）。</li>
|
||
<li>Scale-out，则是另外一个思路，它通过将多个低性能的机器组成一个分布式集群来共同抵御高并发流量的冲击。沿用刚刚的例子，我们可以使用两台 4 核 4G 的机器来处理那 400 次请求。</li>
|
||
</ul>
|
||
<p>**那么什么时候选择 Scale-up，什么时候选择 Scale-out 呢？**一般来讲，在我们系统设计初期会考虑使用 Scale-up 的方式，因为这种方案足够简单，所谓能用堆砌硬件解决的问题就用硬件来解决，但是当系统并发超过了单机的极限时，我们就要使用 Scale-out 的方式。</p>
|
||
<p>Scale-out 虽然能够突破单机的限制，但也会引入一些复杂问题。比如，如果某个节点出现故障如何保证整体可用性？当多个节点有状态需要同步时，如何保证状态信息在不同节点的一致性？如何做到使用方无感知的增加和删除节点？等等。其中每一个问题都涉及很多的知识点，我会在后面的课程中深入地讲解，这里暂时不展开了。</p>
|
||
<p>说完了 Scale-out，我们再来看看高并发系统设计的另一种方法：<strong>缓存。</strong></p>
|
||
<h2>使用缓存提升性能</h2>
|
||
<p>Web 2.0 是缓存的时代，这一点毋庸置疑。缓存遍布在系统设计的每个角落，从操作系统到浏览器，从数据库到消息队列，任何略微复杂的服务和组件中，你都可以看到缓存的影子。我们使用缓存的主要作用是提升系统的访问性能，那么在高并发的场景下，就可以支撑更多用户的同时访问。</p>
|
||
<p>那么为什么缓存可以大幅度提升系统的性能呢？我们知道数据是放在持久化存储中的，一般的持久化存储都是使用磁盘作为存储介质的，而普通磁盘数据由机械手臂、磁头、转轴、盘片组成，盘片又分为磁道、柱面和扇区，盘片构造图我放在下面了。</p>
|
||
<p>盘片是存储介质，每个盘片被划分为多个同心圆，信息都被存储在同心圆之中，这些同心圆就是磁道。在磁盘工作时盘片是在高速旋转的，机械手臂驱动磁头沿着径向移动，在磁道上读取所需要的数据。我们把磁头寻找信息花费的时间叫做寻道时间。</p>
|
||
<p><img src="assets/88a27d1b7a0f55917e59486137ab3002.jpg" alt="img" /></p>
|
||
<p>普通磁盘的寻道时间是 10ms 左右，而相比于磁盘寻道花费的时间，CPU 执行指令和内存寻址的时间都在是 ns（纳秒）级别，从千兆网卡上读取数据的时间是在μs（微秒）级别。所以在整个计算机体系中，磁盘是最慢的一环，甚至比其它的组件要慢几个数量级。因此，我们通常使用以内存作为存储介质的缓存，以此提升性能。</p>
|
||
<p>当然，缓存的语义已经丰富了很多，我们可以将任何降低响应时间的中间存储都称为缓存。缓存的思想遍布很多设计领域，比如在操作系统中 CPU 有多级缓存，文件有 Page Cache 缓存，你应该有所了解。</p>
|
||
<h2>异步处理</h2>
|
||
<p><strong>异步</strong>也是一种常见的高并发设计方法，我们在很多文章和演讲中都能听到这个名词，与之共同出现的还有它的反义词：同步。比如，分布式服务框架 Dubbo 中有同步方法调用和异步方法调用，IO 模型中有同步 IO 和异步 IO。</p>
|
||
<p>**那么什么是同步，什么是异步呢？**以方法调用为例，同步调用代表调用方要阻塞等待被调用方法中的逻辑执行完成。这种方式下，当被调用方法响应时间较长时，会造成调用方长久的阻塞，在高并发下会造成整体系统性能下降甚至发生雪崩。</p>
|
||
<p>异步调用恰恰相反，调用方不需要等待方法逻辑执行完成就可以返回执行其他的逻辑，在被调用方法执行完毕后再通过回调、事件通知等方式将结果反馈给调用方。</p>
|
||
<p>异步调用在大规模高并发系统中被大量使用，**比如我们熟知的 12306 网站。**当我们订票时，页面会显示系统正在排队，这个提示就代表着系统在异步处理我们的订票请求。在 12306 系统中查询余票、下单和更改余票状态都是比较耗时的操作，可能涉及多个内部系统的互相调用，如果是同步调用就会像 12306 刚刚上线时那样，高峰期永远不可能下单成功。</p>
|
||
<p>而采用异步的方式，后端处理时会把请求丢到消息队列中，同时快速响应用户，告诉用户我们正在排队处理，然后释放出资源来处理更多的请求。订票请求处理完之后，再通知用户订票成功或者失败。</p>
|
||
<p>处理逻辑后移到异步处理程序中，Web 服务的压力小了，资源占用的少了，自然就能接收更多的用户订票请求，系统承受高并发的能力也就提升了。</p>
|
||
<p><img src="assets/0756d48f746590894b6e96ae4e4f7609.jpg" alt="img" /></p>
|
||
<p>既然我们了解了这三种方法，那么是不是意味着在高并发系统设计中，开发一个系统时要把这些方法都用上呢？当然不是，系统的设计是不断演进的。</p>
|
||
<p>**罗马不是一天建成的，系统的设计也是如此。**不同量级的系统有不同的痛点，也就有不同的架构设计的侧重点。<strong>如果都按照百万、千万并发来设计系统，电商一律向淘宝看齐，IM 全都学习微信和 QQ，那么这些系统的命运一定是灭亡。</strong></p>
|
||
<p>因为淘宝、微信的系统虽然能够解决同时百万、千万人同时在线的需求，但其内部的复杂程度也远非我们能够想象的。盲目地追从只能让我们的架构复杂不堪，最终难以维护。就拿从单体架构往服务化演进来说，淘宝也是在经历了多年的发展后，发现系统整体的扩展能力出现问题时，开始启动服务化改造项目的。</p>
|
||
<p>**我之前也踩过一些坑，**参与的一个创业项目在初始阶段就采用了服务化的架构，但由于当时人力有限，团队技术积累不足，因此在实际项目开发过程中，发现无法驾驭如此复杂的架构，也出现了问题难以定位、系统整体性能下降等多方面的问题，甚至连系统宕机了都很难追查到根本原因，最后不得不把服务做整合，回归到简单的单体架构中。</p>
|
||
<p>所以我建议一般系统的演进过程应该遵循下面的思路：</p>
|
||
<ul>
|
||
<li>最简单的系统设计满足业务需求和流量现状，选择最熟悉的技术体系。</li>
|
||
<li>随着流量的增加和业务的变化，修正架构中存在问题的点，如单点问题，横向扩展问题，性能无法满足需求的组件。在这个过程中，选择社区成熟的、团队熟悉的组件帮助我们解决问题，在社区没有合适解决方案的前提下才会自己造轮子。</li>
|
||
<li>当对架构的小修小补无法满足需求时，考虑重构、重写等大的调整方式以解决现有的问题。</li>
|
||
</ul>
|
||
<p>**以淘宝为例，**当时在业务从 0 到 1 的阶段是通过购买的方式快速搭建了系统。而后，随着流量的增长，淘宝做了一系列的技术改造来提升高并发处理能力，比如数据库存储引擎从 MyISAM 迁移到 InnoDB，数据库做分库分表，增加缓存，启动中间件研发等。</p>
|
||
<p>当这些都无法满足时就考虑对整体架构做大规模重构，比如说著名的“五彩石”项目让淘宝的架构从单体演进为服务化架构。正是通过逐步的技术演进，淘宝才进化出如今承担过亿 QPS 的技术架构。</p>
|
||
<p>归根结底一句话：<strong>高并发系统的演进应该是循序渐进，以解决系统中存在的问题为目的和驱动力的。</strong></p>
|
||
<h2>课程小结</h2>
|
||
<p>在今天的课程中，我带着你了解了高并发系统设计的三种通用方法：**Scale-out、缓存和异步。**这三种方法可以在做方案设计时灵活地运用，但它不是具体实施的方案，而是三种思想，在实际运用中会千变万化。</p>
|
||
<p>就拿 Scale-out 来说，数据库一主多从、分库分表、存储分片都是它的实际应用方案。而我们需要注意的是，在应对高并发大流量的时候，系统是可以通过增加机器来承担流量冲击的，至于要采用什么样的方案还是要具体问题具体分析。</p>
|
||
</div>
|
||
</div>
|
||
<div>
|
||
<div style="float: left">
|
||
<a href="/专栏/高并发系统设计40问/00 开篇词 为什么你要学习高并发系统设计？.md.html">上一页</a>
|
||
</div>
|
||
<div style="float: right">
|
||
<a href="/专栏/高并发系统设计40问/02 架构分层：我们为什么一定要这么做？.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":"70997f066ab43cfa","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>
|