分布式系统

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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相互协调，各自负责一