System_Design

1. 什么是分布式系统 由多个子系统组成的系统。子系统之间通过网络通讯，每个子系统由多个机器组成 2. 为什么需要分布式系统 单台机器的读写能力有限，且不安全 3. 如何设计分布式系统 3.1. 复制 分布式系统复制.md 3.2. 分区 分布式系统分区.md 4. 分布式系统理论基础 CAP.md

1. 需求是什么 - 需求单 - 原型图 2. 为什么要做这个需求 - 用于解决什么问题 - 需求是不是可以不做 - 能不能简化下需求 3. 需求分析 理解概念需要结合系统举例子 3.1. 原有流程是怎样的 找运营或者产品演示流程 读写流程、B端C端流程 3.2. 新流程是怎样的 1. 系统中的角色

1. 什么是分布式锁 分布式环境（跨进程或者机器）的锁 满足以下条件 - 原子性 加锁和解锁的操作必须是原子的 - 互斥 在任意时刻，只有一个客户端能持有锁 - 无死锁 即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁 - 加锁和解锁必须是同一客户端 加锁和解锁必须是同

1. 什么是海量数据 就是数据量太大，没法一次性加载到内存进行处理 2. 如何处理海量数据 分而治之+合适的数据结构处理【关键点】+合并结果 既然没法一次性加载，那么拆分之后多次加载，选用合适的数据结构处理，最后把结果进行合并 2.1. 怎么分 一行行读取大文件，利用 hash+取模 分成小文件。

1. 分布式ID是什么 分布式环境（多台机器）下唯一的ID 分布式ID的特性 - 全局唯一 - ID嘛，当然得保证唯一性 - 趋势递增 - 递增是为了适应MySQL InnoDB存储引擎聚簇索引的特点 - 趋势而不是顺序是为了防止认为猜测到ID生成策略从而进行攻击 可以加个时间戳 - 高并发 - 淘

1. 什么是高可用系统 - 即可用性高的系统 - 可用性指的是系统的一部分出现了故障，我们能预料并应对这个故障。本质上就是容错 - 可用性高 - 可用性=平均故障间隔/(平均故障间隔 + 故障恢复平均时间) - 一般都是以几个9来表示系统的可用性，99.99的可用性较多，9越多就代表可用性越强 2.

1. 什么是分布式Session session是服务端的内存 分布式环境（多态机器）共享的session 2. 为什么需要分布式Session 在分布式环境之下，如果仍然使用传统的Tomcat的session机制，那么会发生以下现象：用户在A系统登录后，需要跳转到B系统进行某些操作，问题在于此时用

1. 什么是可伸缩 - 描述系统应对负载增长的能力 - 负载指的是并发数性能测试.md 2. 如何设计可伸缩系统 - 纵向扩容 - 横向扩容 3. 什么是高并发 - 读或写或者读写QPS高的系统 4. 如何设计高并发 4.1. 服务层可伸缩 - 做到加机器线性增长性能：每个服务是无状态的。就是没有那

1. 什么是分布式存储 分布式环境（跨多台机器）的文件存储 2. 为什么需要分布式存储 单机性能和容量有限 单机可用性不高 3. 如何实现分布式存储 - 分布式系统复制.md - 分布式系统分区.md - 分布式一致性.md - 分布式系统集群元数据管理.md 4. 分布式存储实例 4.1. Ela

1. 什么是数据模型 - 计算机和现实世界之间的抽象层，描述了数据的特征 2. 为什么需要数据模型 - 计算机不能直接处理现实的事物，所以，人们只有将现实事物转成数字化的数据，才能让计算机识别处理 3. 数据模型有哪些 - 概念模型：描述现实世界的信息 - 逻辑模型：内存中或磁盘中的数据结构 - 物

1. BASE是什么 - AP理论的一个延申 - 他保障的是最终一致性而不是强一致性，就是说由于故障是不可避免的，我允许这段时间内数据是不一样的，但是过了这段时间需要保证数据是一致的。 - 通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用。 1.1. Basic Avail

1. 重构是什么 在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。本质上来说，重构就是在代码写好之后改进它的设计。 2. 什么时候需要重构 维护的系统有很多想吐槽的地方或者痛点，这时就需要重构 3. 如何重构旧系统 3.1. 梳理业务流程 体验业务/历史需求单/原型图 一个tag

1. 为什么有CAP 分布式系统有多个节点，各个节点之间状态需要同步，这就需要CAP理论的支持 2. CAP是什么 三者只能选其二 2.1. C(Consistency) 一致性。 写操作之后读，必须返回该值。当数据分布在多个节点上的时候，从任意一个节点读取的数据都是该值。 2.1.1. 举例 A、

1. 是什么 - PCU指的是同时在线人数，和QPS不同 - 比如10000同时在线人数是用户一点点进来的，所以QPS不可能是10000 - QPS：每秒并发数 2. 步骤 2.1. 计算单核QPS 1. 创建测试计划并执行 2. 使用top命令查看负载是否稳定在60% 3. 计算单核TPS - 假

1. 什么是集群元数据 - 任何文件系统中的数据都可以分为实际数据和元数据 - 数据指的是我们存入文件中的数据 - 元数据指的是文件的特征，比如访问权限、数据块的分布等 2. 为什么需要集群元数据 - 通过集群元数据我们才能知道数据和分区的映射关系 3. 集群元数据维护方式 一般集群中元数据的维护有

1. 我对软件系统技术规划的理解 软件系统技术规划，顾名思义，就是对软件系统做一些技术侧的规划，分三块描述： 1. 软件系统 2. 技术侧 3. 规划 1.1. 软件系统 往大了说桌面端的PC软件，Web端的网页、移动端的APP等等都是软件系统，往小了说，一个服务，一个模块，一个组件，一个小工具也属

1. 分布式一致性是什么 - 数据在多个副本之间保持一致，即数据一致性 2. 为什么需要分布式一致性 - 分布式环境下，为了容错同一份数据需要复制到多个节点，但由于网络问题复制是有延迟的，因此同一时刻一份数据在多个节点上可能是不同的。分布式一致性就是为了解决这个问题 3. 分布式一致性模型 - 分布

1. 什么是缓存中间件 - 通用缓存的基础设施 2. 为什么需要缓存中间件 - 为应用层屏蔽缓存的读写、并发安全、缓存淘汰、分布式支持等细节 3. 如何设计缓存组件 3.1. 基本读写 - 比如HashMap能实现O(1)的读写效率 3.2. 并发安全 多线程同时读写缓存会出问题，如何解决？ 3.2

1. 什么是分布式计算 2. 为什么需要分布式计算 3. 分布式计算分类 4. 批处理 5. 流处理 - 流处理 - 流：随着时间的推移逐步增加的数据 - 事件是流处理的最小单位 - 每个事件包含时间戳，表示创建时间 - 事件有生产者产生，对应多个消费者 5.1. 消息系统 - 消息队列介绍.md

1. 什么是TCP连接池 复用TCP Connection的池子 2. 为什么需要TCP连接池 如何设计池化技术.md - 创建TCP连接需要三次握手，关闭连接需要四次挥手，开销大 - TCP连接数量是有限制的。高并发下主动关闭的一方进入TIME WAIT会耗尽连接数TCP time wait.md

1. 什么是分布式系统通讯 - 单体系统拆分成多个子系统后，子系统之间需要通讯提供完成的服务 2. 分布式系统间通讯方式 2.1. 同步通讯 - A调用B，等待结果返回 2.1.1. REST vs RPC - Restful.md - 如何设计一个RPC框架.md RPC REST -------

1. 什么是RPC - 远程过程调用 - 是一个计算机通信协议 - 这种协议使得client可以像调用本地函数一样去调用server上的函数，即屏蔽了网络通讯的细节 - 采用C/S模式，经典实现是request-response 1.1. 本地函数调用 vs RPC - 本地函数调用：不需要经过网络

1. 什么是状态 - 状态指的是程序的上下文信息或者数据 - 有状态：用户的前一次请求和后一次请求有关联，必须打到某个节点才能正常处理 - 无状态：用户的前一次请求和后一次请求有关联，打到任意一个节点都能正常处理 2. 有状态服务 vs 无状态服务 有状态服务 无状态服务 --- ---------

1. 什么是限流 - 高并发系统的三大利器之一，限制访问速率（区别于Semaphore限制的是访问数量） - 技术层面的限流：服务A调用服务B，服务B为了防止请求量过大，限制访问速率 - 业务层面的限流：限制某人每天只能使用n次 2. 为什么需要限流 - 后端服务的处理能力是有限的，如果突发流量暴增

1. 什么是服务升级回滚 - 分布式系统一个服务有多个实例，新功能发布或者旧系统重构时需要对这些实例都进行升级替换，如果出现问题了那么得及时回滚 2. 部署策略 2.1. 停机部署 - 把现有版本的服务停机，然后部署新的版本 - 优点：在部署过程中不会出现新老版本同时在线的情况，保证一致性 - 缺点

1. 什么是开放接口 一般的API只对内部系统开放 而开放API则是对外部系统开放，其他系统或者软件可以调用这个API获取本系统的数据 2. 如何设计开放接口 2.1. 安全问题 对于开放接口，主要面临3个安全问题： - 请求身份是否可信任--认证 - 请求的参数是否被篡改--签名 - 请求是否唯一

1. 什么是分布式系统故障 某个节点宕机或者网络不通 2. 如何检测分布式系统故障 2.1. 心跳检测 2.2. Gossip协议检测 分布式一致性算法之Gossip.md 3. 如何处理分布式系统故障 3.1. 故障转移（Fail-Over） - A调用B，如果B出现故障，且B有其他副本，那么A转

1. 超时重试是什么 - 超时：服务A调用服务B，为了防止服务A请求服务B但是一直没有响应，导致服务A的线程等资源一直hold着无法释放，因此需要设置超时 - 重试：服务A调用服务B，如果服务A请求服务B发生了网络错误，那么会触发超时，但是这个网络是暂时的，因此重试几次可能就好了 2. 怎么设计超时

1. 什么是节点通信 分布式系统节点之间需要通信，交换元数据 1.1. 元数据是什么 master、slave的关系 数据的分布情况等 1.2. 元数据维护方式 一般集群中元数据的维护有两种方式 1.2.1. 集中式 由一台机器维护，master负责将信息写入这台机器，代表由zookeeper 1.

1. 什么是错误 程序运行过程中发生的异常问题 2. 错误分类 按照严重程度可以分为两类：严重与普通 严重的应该终止程序。比如程序启动时初始化资源失败等情况 普通的是情况而定 3. 错误构建 创建一个错误需要带上详细信息，如下 3.1. 错误码 - 0：成功 - 1：未知异常 - 4xxxxx：客户

1. 什么是分布式事务 - 分布式环境下的事务。 - 传统的事务是单个数据库节点的，而分布式事务则是跨多个数据库节点的，甚至是其他数据源比如Redis、MongoDB 2. 为什么需要分布式事务 传统的数据库事务只能保证单个库内的事务，跨多个库就不行了 参考数据库事务.md 3. 分布式事务使用场景

1. 什么是池化技术 预先创建对象并存放到池子里，使用的时候从池子中获取对象而不是创建，使用结束把对象归还给池子而不是销毁 2. 为什么需要池化技术 - 频繁创建、销毁对象开销大 - 对象占用资源多，需要限制对象的数量否则会把资源耗尽 3. 池化技术的缺点 池化技术属于利用空间换时间，所以会消耗内存

1. 2PC是什么 保证强一致性的一种分布式事务方案 2. 2PC流程 - 把事务分成两个阶段 - 第一阶段：由事务管理器向所有database发送prepare请求 - 第二阶段根据第一阶段的结果决定。 - 如果第一阶段全部响应ok那么执行第二阶段的commit； - 如果第一阶段有一个datab

1. 什么是缓存 CPU和磁盘的速度差异巨大，一般会根据局部性原理把常用的数据加载到内存中，以提高访问速度 2. 为什么需要缓存 - 提高性能 - 降低下游负载 3. 缓存的缺点 3.1. 缓存一致性 - CAP原则下延迟导致的一致性是没办法解决的，只能保证最终一致性 - 如果是read-throu

1. TCC是什么 保证最终一致性的一种分布式事务方案 2. TCC流程 - TCC：Try、 Confirm、 Cancel - 把事务分成两个阶段 - 第一阶段执行Try操作，对业务检查及资源预留 - 第二阶段根据第一阶段的结果决定。 - 如果第一阶段成功则执行Confirm 做业务确认操作； -

1. 可靠消息最终一致性是什么 保证最终一致性的一种分布式事务方案 2. 可靠消息最终一致性流程 3. 可靠消息最终一致性的使用场景 - 适用于一些最终一致性、时间敏感度低、分布式事务只能成功不能失败的业务，比如注册送积分，登录送优惠券等 - 多个服务多个数据源且数据源可以不是DB 4. 可靠消息最

1. 最大努力通知是什么 保证最终一致性的一种分布式事务方案 2. 最大努力通知流程 3. 最大努力通知使用场景 - 适用于一些最终一致性、时间敏感度低、允许少量的分布式事务失败的业务，且被动方处理结果不影响主动方的处理结果，比如银行通知、支付结果通知等。 - 多个服务多个数据源且数据源可以不是DB

1. Saga是什么 保证最终一致性的一种分布式事务方案 2. Saga流程 - 有多个事务参与者，每个参与者都有两块逻辑：正向操作和逆向操作 - 把事务分成两个阶段 - 第一阶段每个参与者执行正向操作 - 第二阶段根据第一阶段结果而定 - 如果所有正向操作均执行成功，那么分布式事务提交 - 如果任

1. 3PC是什么 - 证强一致性的一种分布式事务方案，2PC的改进版 2. 3PC流程 - 把2PC中的第一阶段拆分成两步，因此整个事务过程分成3个阶段：CanCommit、PreCommit、DoCommit - CanCommit阶段：协调者向所有参与者询问 你们是否可以完成本次事务？ ，各个

1. 两阶段是什么 - 将整个事务流程分为两个阶段 - 准备阶段 - 提交阶段或者回滚阶段 2. 两阶段实现 2.1. 数据库层次 - 两阶段实现之2PC.md 2.2. 应用层次 - 两阶段实现之TCC.md 3. 参考 - 请问TCC和2PC的区别在哪里？ \- 知乎

1. 本地消息表是什么 我们以下单后增加积分两个事务为例。 下单服务为服务A，积分服务为服务B 1. 服务A执行下单逻辑 2. 服务A下单成功后，发送消息到MQ中 3. 服务B消费消息处理本地事务 4. 服务B执行成功，则更新本地消息表的状态 5. 服务B消息表的状态【可以使用zookeeper解耦

1. 2PC是什么 - 2PC：Two-Phase Commit - 把事务分成两个阶段 - 第一阶段由事务管理器像所有database发送prepare请求 - 如果全部响应ok那么执行第二阶段的commit；如果有一个响应fail那么执行第二阶段的rollback - 2. 2PC存在的问题 -

1. TCC是什么 - 2PC是数据库层面的两阶段，而TCC是应用层面的两阶段 - TCC： - Try：尝试执行事务 - Confirm：确认执行事务 - Cancel：取消执行事务 - 本质上也是属于两阶段事务。 - 第一阶段执行Try操作，对业务检查及资源预留 - 第二阶段根据第一阶段的结果决

1. 是什么 1. 生产者执行本地事务完毕，发送消息到MQ 2. MQ把消息丢给消费者 3. 消费者消费消息，执行本地事务，成功则ack，失败则nack并重新入队 4. 消费者可以主动调用生产者的接口查询消息状态 2. 特点 跟分布式解决方案之可靠消息最终一致性.md差不多，依赖于MQ，允许少量的分

1. RocketMQ事务消息是什么 - 传统的本地消息表需要依赖数据库的消息表 - 而RocketMQ事务则是对本地消息表的一个封装，将本地消息表移动到了MQ内部，解决 Producer 端的消息发送与本地事务执行的原子性问题 2. RocketMQ事务消息原理 1. 服务A发送half mess

1. 分布式一致性算法是什么 - 准确地说是共识算法：让所有的节点对某件事达成一致。 2. 为什么会有一致性问题 2.1. 客户端并发请求 - 比如Leader-Follower场景：一个Client，A、B、C三个Node，Client请求A写入x为1，如果A认为x的值为1，那么B、C也必须认为该

1. Basic Paxos 1.1. Basic Paxos是什么 - 简称Paxos - Lamport发明的分布式共识算法，是Raft、ZAB的基础 1.2. Basic Paxos算法流程 1.2.1. 角色 - client：请求发起者。打酱油 - proposer：提案提议者。类似于协调

- ZAB协议.md

1. Raft是什么 - Diego Ongaro发明的分布式共识算法 2. 为什么需要Raft - 为了解决Paxos实现复杂的问题 3. Raft算法流程 3.1. 角色 - Leader - Follower - Candidate 3.2. 三个阶段 3.2.1. 阶段1：Leader选举

1. Gossip是什么 - 由施乐公司提出的一种用于分布式数据库在多节点间复制数据的算法 - 节点之间不断交换信息，一段时间之后集群所有节点都会知道完整的信息 2. 为什么需要Gossip 3. Gossip算法流程 - 每个节点定时，随机得选取连接的节点传播消息 - 其他节点收到之前没有的消息后

1. 分布式一致性模型是什么 - 不同的一致性模型解决了不同程度的一致性问题 2. 分布式一致性模型分类 2.1. 强一致性 - CAP.md中的C - 也叫线性一致性 2.2. 弱一致性 - 最终一致性 - 因果一致性 - 读你所写一致性 - 会话一致性 - 单调读一致性 - 单调写一致性 - 前

1. 复制是什么 - 同一份数据保存在多台机器上 - 存储数据的每个节点叫做副本 2. 为什么需要复制 - 通过数据冗余提高可用性 - 通过读写分离提高读吞吐量 3. 复制架构 分布式系统复制架构.md 4. 复制方式 分布式系统复制方式.md 5. 复制日志格式 分布式系统复制日志.md 6. 参

1. 什么是Leader-Leader - 有多个Leader，每个Leader有多个Follwer 2. Leader-Leader使用场景 - 多个数据中心 - 应用程序在断网之后仍然需要继续工作 3. Leader-Leader原理 3.1. Leader选举 3.2. Leader同步数据给

1. 什么是Leaderness - 没有leader，客户端写的时候将写请求并行发给所有replica，读的时候同样将读请求并行发给所有replica 2. Leaderness使用场景 3. Leaderness原理 3.1. 数据同步 3.1.1. 写入冲突问题 - 允许多个客户端同时写入相同

1. 什么是Leader-Follower - 副本中有且仅有一个Leader，其他的都是Follower 2. Leader-Follower使用场景 - 单个数据中心 3. Leader选举 所有副本中选出一个作为Leader，其他的副本作为Follower 3.1. 选举方法 1. 手动 -

1. 是什么 - 副本之间的数据变更一般通过复制日志追踪，格式有以下几种 2. 分类 2.1. 物理日志 - 对哪个page的修改，原始值是什么，更新值是什么 2.2. 逻辑日志 - 对哪条记录的修改，又分为Statement和Row 2.2.1. Statement - 客户端请求的原始语句 -

1. 同步复制 leader要同步给所有follower才算成功 1. 客户端请求leader 2. leader写入本地数据 3. leader同步给follower 4. leader返回给客户端成功 2. 异步复制 leader写入就算成功 1. 客户端请求leader 2. leader写入

1. 是什么 - 一般副本中有两种角色 - Leader：负责处理客户端的写入请求 - Follower：从Leader同步数据，可以处理客户端的读取请求 2. 分类 2.1. Leader-Follower 分布式系统复制架构之主从复制.md 2.2. Leader-Leader 分布式系统复制架

1. 什么是分区 - 将一份数据分割成多份，保存在不同节点上 - 有两层映射 - 从数据中取出一个字段作为key，然后将key- partition - 接着将partition- machine/node 2. 为什么需要分区 - 数据量太大无法在一个节点存储，需要分散存储 - 数据分散在多个节点

把 key 尽量平均分配到各个 partition/node 上 1. 拆分key的选择 1.1. 主键ID 比如自增主键。优点是数据分布均匀，缺点是根据业务字段查询慢时需要读取所有分区 1.2. 业务ID 比如用户ID、商品ID等。优点是根据业务字段查询快，缺点是数据分布可能不均匀 1.3. 举例

路由组件把客户端的读写请求，路由到相应partition所在的node 1. 路由组件 路由组件 2. 请求处理 2.1. 新增数据 1. 客户端生成包含sharding key的数据 2. 客户端把新增请求发送给路由组件 3. 路由组件根据sharding key转发到相应的节点 4. 节点新增数

1. client - 客户端本地保存了分区和服务器节点的关系，直接请求到正确的节点 2. proxy - 客户端请求路由层，由路由层负责转发请求到正确的节点 3. server - 客户端请求任意服务器节点，由该服务器节点负责转发请求到正确的节点 4. 举例 - MySQL使用proxy或者cli

把 partition/node 尽量平均分配到各个 machine 上 1. 分配方式 1.1. 静态分配 创建远超machine数目的node， 优点：迁移node到其他machine时，集群可以对外响应 缺点：machine最大数目是固定的 1.2. 动态分配 各个node相互协调，各自负责一