|
|
# 分布式
|
|
|
|
|
|
## 分布式ID生成方案有哪些？
|
|
|
|
|
|
- Redis
|
|
|
Incr命令
|
|
|
- Mongodb
|
|
|
ObjectID
|
|
|
- 雪花算法
|
|
|
|
|
|
Snowflake算法(雪花算法)是由Twitter提出的一个分布式全局唯一ID生成算法，该算法生成一个64bit大小的长整数。64bit位ID结构如下：
|
|
|
|
|
|
|
|
|
|
|
|
## 一致性Hash算法
|
|
|
|
|
|
一致性Hash算法是为了解决传统Hash算法（比如取余运算）时候，由于添加或删删除节点时候，导致过多数据进行迁移问题而引入的新算法。
|
|
|
|
|
|
假定有几台Redis服务器，假定是N，要存储key-value数据，传统模式是根据hash(key)%N服务器数量来定位出来存放在第几台服务器上面。
|
|
|
|
|
|
一致性Hash算法，会使用2\^32个虚拟hash槽位，可以想象成在一个圆环（也叫hash环）上面有0到2\^32-1编号的槽位。首先我们确定每台Redis服务器在这个环上槽位，可以用服务器IP或ID或者name进行hash：
|
|
|
> 槽位 = hash(Redis服务器IP)%2^32
|
|
|
|
|
|
当一个key-value数据过来时候，根据key计算出其在环上槽位，然后沿着环顺时针行走，遇到的第一个服务器就是要存放的服务器。
|
|
|
|
|
|
|
|
|
|
|
|
如上图所示：根据一致性Hash算法，数据A会被定为到Node A上，B被定为到Node B上，C被定为到Node C上，D被定为到Node D上。
|
|
|
|
|
|
一致性Hash算法在服务节点太少时，容易因为节点分部不均匀而造成**数据倾斜**（被缓存的对象大部分集中缓存在某一台服务器上）问题，例如系统中只有两台服务器，其环分布如下：
|
|
|
|
|
|
|
|
|
|
|
|
此时必然造成大量数据集中到Node A上，而只有极少量会定位到Node B上。为了解决这种数据倾斜问题，一致性Hash算法引入了虚拟节点机制，即对每一个服务节点计算多个哈希，每个计算结果位置都放置一个此服务节点，称为虚拟节点。具体做法可以在服务器IP或主机名的后面增加编号来实现。
|
|
|
|
|
|
例如上面的情况，可以为每台服务器计算三个虚拟节点，于是可以分别计算 “Node A#1”、“Node A#2”、“Node A#3”、“Node B#1”、“Node B#2”、“Node B#3”的哈希值，于是形成六个虚拟节点：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 什么是分布式一致性？
|
|
|
|
|
|
分布式一致性（Distributed Consensus）简单来说就是在多个节点组成系统中各个节点的数据保持一致，并且可以承受某些节点数据不一致或操作失败造成的影响。分布式一致性是分布式系统的基石。
|
|
|
|
|
|
## Cap理论是什么？
|
|
|
|
|
|
Cap理论中C代表一致性，A代表可用性，P代表分区容忍性。CAP理论下分布式系统在满足P情况下，需要在C和A之间找到平衡。
|
|
|
|
|
|
|
|
|
|
|
|
根据C的情况，数据一致性模型分为：
|
|
|
|
|
|
- 强一致性
|
|
|
|
|
|
新的数据一旦写入，在任意副本任意时刻都能读到新值。强一致性使用的是同步复制，即某节点受到请求之后，必须保证其他所有节点也全部完成同样操作，才算这次请求成功完成。
|
|
|
|
|
|
- 弱一致性
|
|
|
|
|
|
不同副本上的值有新有旧，这需要应用方做更多的工作获取最新值
|
|
|
|
|
|
- 最终一致性
|
|
|
|
|
|
各副本的数据最终将达到一致。一般使用异步复制，这意味有更好的性能，但需要更复杂的状态控制
|
|
|
|
|
|
## 什么是Raft算法？
|
|
|
|
|
|
Raft算法属于最终一致性致性算法实现。在Raft中，每个节点在同一时刻只能处于以下三种状态之一：
|
|
|
|
|
|
- 领导者(Leader)
|
|
|
- 候选者(Candidate)
|
|
|
- 跟随者(Follower)
|
|
|
|
|
|
在Raft中Leader负责所有数据的读写，Follower只能用来接受Leader的Replication log。当一个节点刚开始启动时候默认都是Follwer状态，若在一段时间内，没有收到Leader的心跳，就会开始Leader Election过程：该节点会变成Canidate，将当前term技术加+1，同时投个自己一票，然后向其他节点发起投票请求，若获得集群中半数以上投票，则该节点会成Leader，然后开始向集群中发布心跳。
|
|
|
|
|
|
## 什么是BASE理论？
|
|
|
|
|
|
BASE理论是Basically Available(基本可用)，Soft State（软状态）和Eventually Consistent（最终一致性）三个短语的缩写。
|
|
|
|
|
|
其核心思想是：
|
|
|
|
|
|
> 既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
|
|
|
|
|
|
什么是基本可用呢？假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：
|
|
|
|
|
|
- 响应时间上的损失：正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果。
|
|
|
- 功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
|
|
|
|
|
|
什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。
|
|
|
|
|
|
软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
|
|
|
|
|
|
上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。
|
|
|
|
|
|
## 如何实现分布式事务?
|
|
|
|
|
|
分布式事务分类:
|
|
|
|
|
|
1.刚性事务
|
|
|
|
|
|
- 强一致性：各个业务操作必须在事务结束时全部成功，或者全部失败
|
|
|
- XA模型
|
|
|
- 满足CAP理论的CP
|
|
|
|
|
|
2.柔性事务
|
|
|
|
|
|
- 保证最终一致性，事务结束后在可接受的时间范围内，可能出现短暂的不一致，最终会达成一致性
|
|
|
- 满足CAP理论的AP，满足BASE理论
|
|
|
|
|
|
### 2PC
|
|
|
|
|
|
XA是由X/Open组织提出的分布式事务的架构（或者叫协议）。XA架构主要定义了（全局）事务管理器（Transaction Manager）和（局部）资源管理器（Resource Manager）之间的接口。
|
|
|
|
|
|
|
|
|
2PC(两阶段提交)是XA规范标准实现。
|
|
|
|
|
|
|
|
|
2pc实现过程：
|
|
|
|
|
|
1. 请求阶段，（commit-request phase，或称表决阶段，voting phase）
|
|
|
|
|
|
在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。
|
|
|
|
|
|
在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。
|
|
|
|
|
|
2. 提交阶段（commit phase）
|
|
|
|
|
|
在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。
|
|
|
|
|
|
当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。
|
|
|
|
|
|
参与者在接收到协调者发来的消息后将执行响应的操作。
|
|
|
|
|
|
缺点：
|
|
|
|
|
|
- 同步阻塞，并发能力不高。在没有收到真正提交还是取消事务指令的时候，所有资源管理器锁定当前的资源
|
|
|
- 单点故障：事务的发起、提交还是取消，均是由事务管器管理的，只要事务管理器宕机，那就凉凉了。
|
|
|
|
|
|
### TCC
|
|
|
|
|
|
分布式事务可以采用TCC来处理分布式事务。TCC核心思想就是针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。分为三个阶段：
|
|
|
|
|
|
- Try 阶段:主要是对业务系统做检测（一致性）及资源预留（准隔离性）
|
|
|
- Confirm 阶段:主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。(Confirm 操作满足幂等性。要求具备幂等设计，Confirm 失败后需要进行重试。)
|
|
|
- Cancel 阶段：主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。(Cancel 操作满足幂等性)
|
|
|
|
|
|
|
|
|
Try阶段进行资源预留示意图：
|
|
|
|
|
|
|
|
|
|
|
|
国内有一些关于TCC方案介绍的文章中，把TCC分成三种类型：
|
|
|
|
|
|
- 通用型TCC
|
|
|
- 服务需要提供try、confirm、cancel
|
|
|
|
|
|
- 补偿性TCC
|
|
|
业务服务只需要提供 Do 和 Compensate 两个接口
|
|
|
|
|
|
- 异步确保型TCC
|
|
|
|
|
|
主业务服务的直接从业务服务是可靠消息服务，而真正的从业务服务则通过消息服务解耦，作为消息服务的消费端，异步地执行。异步确保型 TCC中业务服务不需要提供try、confirm、cancel三个接口
|
|
|
|
|
|
### 基于消息队列柔性事务
|
|
|
|
|
|
|
|
|
|
|
|
1. 操作支付表，然后在事件表里面插入一条数据，状态为new状态，放到数据库，这个（1、2、3）操作都是在一个事务中，因为他们都是一个库
|
|
|
|
|
|
2. 定时任务读取事件表，发送队列，发送成功以后，将事件表new的状态改为（published），监听事件表，插入一条数据到事件表
|
|
|
|
|
|
3. 定时任务读库是不是published事件表，如果是published事件表，更新订单表，更新事件表为processed，这样就将一个大事务，拆分成几个几个的小事务
|
|
|
|
|
|
### Saga
|
|
|
|
|
|
confirm 直接执行资源操作，（如：库存服务的减库存，支付服务的扣减账户余额）
|
|
|
cancel 回滚资源操作，这个地方的cancel与TCC中的cancel不一样，准确点说应该是回滚，（如：回滚库存服务的减库存操作，回滚支付服务的扣减账户余额的操作）。当然是业务层面实现的回滚，而非数据库事务层面的回滚
|
|
|
|
|
|
Saga正常流程：
|
|
|
|
|
|
|
|
|
|
|
|
Saga异常流程：
|
|
|
|
|
|
|
|
|
|
|
|
Saga对比TCC少了一步try的操作，TCC无论最终事务成功失败都需要与事务参与方交互两次。而Saga在事务成功的情况下只需要与事务参与方交互一次, 如果事务失败，需要交互两次。
|
|
|
|
|
|
saga保证满足以下业务规则：
|
|
|
|
|
|
- 向后恢复
|
|
|
|
|
|
补偿所有已完成的事务，如果任一子事务失败
|
|
|
|
|
|
- 向前恢复
|
|
|
|
|
|
重试失败的事务，假设每个子事务最终都会成功
|
|
|
|
|
|
显然，向前恢复没有必要提供补偿事务，如果你的业务中，子事务（最终）总会成功，或补偿事务难以定义或不可能，向前恢复更符合你的需求
|
|
|
|
|
|
## 限流算法怎么实现？
|
|
|
|
|
|
## 熔断器工作原理是？
|
|
|
|
|
|
## 什么是Sidecar模式？
|
|
|
|
|
|
想象一下假如你有6个微服务相互通信以确定一个包裹的成本。
|
|
|
|
|
|
每个微服务都需要具有可观察性、监控、日志记录、配置、断路器等功能。所有这些功能都是根据一些行业标准的第三方库在每个微服务中实现的。
|
|
|
|
|
|
但再想一想，这不是多余吗？它不会增加应用程序的整体复杂性吗？
|
|
|
|
|
|
这时候可以使用Sidecar模式，将单个服务的所有传入和传出网络流量都流经 Sidecar 代理。 因此，Sidecar 能够管理微服务之间的流量，收集遥测数据并实施相关策略。从某种意义上说，该服务不了解整个网络，只知道附加的 Sidecar 代理。这实际上就是 Sidecar 模式如何工作的本质——将网络依赖性抽象为 Sidecar。
|
|
|
|
|
|
在sidecar上，可以把日志、微服务注册、调用链、限流熔断降级等功能都实现，基于sidecar，抽象出servicemesh。
|
|
|
|
|
|
## 什么是Service mesh
|
|
|
|
|
|
服务网格（Service Mesh）是一种在分布式软件系统中管理服务对服务（service-to-service）通信的技术。服务网格管理东西向类型的网络通信（East-west traffic）。服务网格中有数据平面和控制平面的概念：
|
|
|
|
|
|
- 数据平面的职责是处理网格内部服务之间的通信，并负责服务发现、负载均衡、流量管理、健康检查等功能。
|
|
|
- 控制平面的职责是管理和配置 Sidecar 代理以实施策略并收集遥测
|
|
|
|
|
|
|
|
|
|
|
|
## Consul架构是怎么样的？
|
|
|
|
|
|
|
|
|
|
|
|
- Agent是Consul集群中的守护进程。它的生命周期从启动Consul agent开始。Agent可以以client或是server模式运行
|
|
|
|
|
|
- Client：Client是转发所有RPC请求到Server的Agent。Client相对来说是无状态的，它的唯一后台活动是参与LAN gossip pool。它的资源开销很小，只消耗少量的网络带宽
|
|
|
|
|
|
- Server：Server是负责参与Raft quorum，维护集群状态，响应RPC查询，和其他datacenter交换WAN gossip信息并转发查询到leader或是远程datacenter的Agent
|
|
|
|
|
|
- Gossip：Consul是建立在处于多种目的提供了完整gossip 协议的Serf之上的。Serf提供了成员管理、错误检测、时间传播等特性。我们只需要知道gossip会触发随机的点到点通信，主要基于UDP协议
|
|
|
|
|
|
- LAN Gossip：位于相同本地网络区域或是datacenter的节点之间的LAN gossip pool
|
|
|
|
|
|
- WAN Gossip：只包含server的WAN gossip pool。这些server主要存在于不同的datacenter中，并且通常通过internet或广域网进行通信
|
|
|
|
|
|
## 架构设计中，你会考虑的点？
|
|
|
|
|
|
- 可靠性
|
|
|
- 非核心业务降级处理
|
|
|
- 高并发业务支持限流操作
|
|
|
- 应用鉴权授权机制，防止未经授权的访问和滥用
|
|
|
- 多机部署，实现故障转移
|
|
|
- 可伸缩性
|
|
|
- 无状态应用，可多机分布式部署
|
|
|
- 可维护性
|
|
|
- 尽量不引入新的技术栈
|
|
|
- 可观察性
|
|
|
- prometheus exporter 上传metric指标
|
|
|
- 告警功能
|
|
|
- 应用提供健康检查接口，拨测系统健康拨测
|