搞定系统设计 01：从 0 到百万用户的系统
Posted qcrao
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了搞定系统设计 01：从 0 到百万用户的系统相关的知识，希望对你有一定的参考价值。
如何从零开始设计一套可以服务百万用户的系统。
这是本书第一章的内容，浅显易懂，把常见的套路组合了一下，没有具体的技术细节，过一遍也没什么负担。
从单服务开始
俗话说：千里之行，始于足下。构建一个复杂系统也不例外，我们从单服务开始。
画出整体的大框图，流程很简单。客户端先请求 DNS 拿到服务端的 IP 地址；客户端拿着 IP 地址请求服务端的接口；服务端返回 html；客户端渲染出页面。
这种是最简单的系统。但有个问题是：数据无法持久化。只能把状态存在内存中，一旦进程重启，数据就都丢失了。
数据库
因此，一般的服务都会加一个数据库：
具体是选择关系型数据库还是非关系型数据库，这里有一些需要考虑的点：
关系型数据库最出名的当属 mysql，Oracle，PgSQL，互联网公司用得最多的还是 MySQL。它将数据存储在一张表的一行，可以在不同的表之间执行 join 操作。
非关系型数据库也叫 NoSQL，它有四种类型：k-v，图数据库，列存，文档型。
更多的时候当然还是选择老牌的关系型数据库，但有些场景还是更适合 NoSQL，尤其是在互联网蓬勃发展的今天。
下面这几个场景更适合使用 NoSQL：
服务需要超低延迟。
服务的数据是非结构化的。
只需要序列化反序列化数据（Json/XML/YAML）
需要存储大量数据。
负载均衡
现在很少有网站直接用 IP 地址+端口的地址访问，前面至少得挂个 nginx。
后端服务也不能是单个 server，至少得挂个 2 台。当单个服务意外挂了，另一个服务得马上顶上，防止单点故障。
服务之间则是通过私有 IP 通信。
客户端通过 DNS 拿到的 IP 不再是服务器的 IP，而是前面的负载均衡器的 IP。请求到来之后，由负载均衡器将请求打到不同的 server 上。这一切对用户是透明的。
加上了负载均衡器后，服务层的可用性解决了。但是数据库层呢，我们还只有一个数据库服务器，一旦它挂了，服务同样是不可用的。
解决办法就是让数据库有更多的副本。
数据库副本
互联网绝大多数的场景是多读写少，可以采用经典的主从式架构模式，一般都会设置成一主多从。
所有的写操作，包括插入、删除、更新操作由主执行；而所有的读操作都由从执行。
采用主从架构的好处很多：
性能更强。读操作被分散到多个从，每个从的压力会更小，性能也更高。
可靠性更高。数据被分散保存，一个从挂了，数据不会丢，可以通过其他从恢复。
可用性更强。一个从挂了，有其他从顶上。
缓存
增加一个缓存层也是常规的做法。
缓存在内存中存储计算好的结果，等下次请求到来时，直接使用内存中的数据，系统响应时间会更短。
关于缓存，有这么几点需要考虑：
何时使用缓存。读多写少的场景更适合用缓存，例如城市 id 和名称的对应关系，基本是不会变的，放在缓存中再合适不过。
过期策略。过期后，数据将被移出缓存。过期时间既不能太长也不能太短：太长数据会不“新鲜”，太短则需要频繁更新数据。
一致性。数据发生变更时，数据库里的更改和缓存的更改并不在一个事务中，存在不一致的风险。
处理单点失效。由多个 server 组成集群，在多个数据中心部署缓存都是可选的方法。
逐出策略。一旦 cache 满了，再添加新的缓存项时就需要逐出缓存中已有的缓存项。逐出策略如 LRU、LFU、FIFO 分别在不同的场景下使用。
CDN
CDN 全称是 Content Delivery Network，内容分发网络。它是基于地理位置的服务，用来缓存静态内容，如图片、视频、CSS、javascript 文件等等。
下面这张图展示了 CDN 的工作流程，非常清晰：
使用 CDN 需要考虑的点有：
费用。CDN 一般由第三方提供，根据数据流入、流出量收取费用。因此对于不常访问的数据应及时从 CDN 中移出。
设置过期时间。太长导致数据不“新鲜”，太短又需要频繁回源读取数据。
CDN 失效时如何处理。当 CDN 出问题时，客户端应该有能力直接从源服务器读取数据。
踢出文件。通过 CDN 厂商提供的 API 手动踢出或者通过在 URL 中增加版本号的方式实现。
当我们增加了 CDN 之后，系统架构图如下：
无状态层
Web 层的水平扩展依赖无状态的设计：将状态（例如用户的 session）保存在外存，一般用 NoSQL。
当 Web 层无状态化后，流量上升就加机器，流量下降就减机器，扩展更容易。
数据中心
业务做起来后，用户会越来越多。为了更好的用户体验，需要建立多个数据中心。根据用户的地理位置决定由哪个数据中心提供服务。
当某个数据中心宕机了，流量自动或手动切到其他数据中心。
消息队列
消息队列让生产者和消费者解耦，对于构建可伸缩的服务架构是非常有用的。
生产者向消息队列发送消息，它不需要关心消费者是否在可用。消费者消费消息，它也不需要关心生产者是否可用。
日志、打点、自动化
对错误日志量的监控常常能快速发现和定位问题。
对业务信息、机器状态、进程状态进行打点和监控也是必不可少的。
当整个系统越来越大，我们还需要通过自动化工具来提升开发效率，CICD 就得搬到台前。
数据库伸缩
服务在线上正常运转，数据会越来越多。单机总有一天不能装下所有的数据，对数据库的扩展需求提上日程。
同样有两种扩展方式。
最简单的就是垂直扩展。换更大容量、更多核心，更大内存的机器，只要足够有钱，这都不是事。开始阶段，加机器的效率甚至更高。
更难的是水平扩展。说白了就是分 shard，将全量数据拆分到不同的机器上去。
分 shard 最关键的就是 key 的选取，它要能保证数据的平均分布。
数据分片并不容易，需要考虑下面这几点：
resharding。当某个 shard 也不能完全存放数据时，就需要重新再分 shard。reshard 最常用的方法是一致性哈希。
名人问题。也称为热点 key 问题，需要特殊解决。
join。一旦分片，数据库被分散到不同的机器上，不再能执行 join 操作，通常的解法是将字段冗余到同一个表上。
最后是一张考虑了以上所有的点之后的架构图：
点评
第一章感觉说了很多，又感觉什么都没说。整体看内容还是比较浅显的，不少都是点到即止。
不管怎么说，我们都已经上路了。
以上是关于搞定系统设计 01：从 0 到百万用户的系统的主要内容，如果未能解决你的问题，请参考以下文章