【分布式】分布式基本理论

一、CAP

• 一致性 Consistency： 所有节点在同一时间具有相同的数据
• 可用性 Availability ： 保证每个请求不管成功或者失败都有响应，即服务在正常响应时间内一直可用
• 分区容错性 Partition tolerance ： 分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务

分布式系统最多同时满足一致性、可用性、分区容错性中的两个。
假设两个分布式服务网络断开了连接，保证可用性只能返回旧数据，保证一致性只能阻塞等待网络恢复。

一致性

从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。
从服务端来看，则是更新如何分布到整个系统，以保证数据最终一致。
强一致性：对于关系型数据库，要求更新过的数据能被后续的访问都看到。
弱一致性：能容忍后续部分或全部访问不到更新的数据
最终一致性：经过一段时间后要求能访问到更新后的数据。

二、BASE

BASE理论是对CAP的一致性和可用性进行一个权衡的结果，核心思想是即使无法做到强一致性，但应用可以采用适合的方式达到最终一致性
基本可用（Basically Available）： 分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用，如部分用户被引导到降级页面，只提供降级服务。
软状态（Soft State）：指允许系统存在中间状态，而该中间状态不影响系统整体可用性。分布式存储一般一份数据会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。
最终一致性： 最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致性的状态。

ACID 和 BASE 的区别和联系

ACID 是传统数据库设计理念，追求强一支模型，BASE支持的是大型分布式系统，通过牺牲强一致性获得高可用性。
ACID和BASE 代表两种相反的设计哲学，具体分布式系统设计场景中，系统主键对一致性要求不同，因此ACID和BASE会相互结合使用。

三、负载均衡算法

1. 轮询法 ： 将请求按顺序轮流地分配到后端服务器上，均衡的对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载
2. 随机法： 通过系统的随机算法，根据后端服务器的列表大小值 来随机选取其中一台服务器进行访问，访问次数很多的情况实际效果接近轮询法
3. 源地址哈希法：根据获取客户端的IP地址，通过哈希函数计算得到一个数值，用该数值对服务器列表大小取模运算。 源地址哈希法同一IP地址的客户端，在服务列表不变时，每次都会映射到同一台后端服务器进行访问。
4. 加权轮询法：不同后端服务器可能机器配置和当前系统的负载并不相同，因此抗压能力也不同，给配置高，负载低的机器配置更高的权重，处理更多的请求。加权轮询法能将请求按顺序和权重分配到后端
5. 加权随机法：和加权轮询法一样，只不过不是顺序的，而是随机的
6. 最小连接数法： 最小连接数算法比较灵活智能。 根据后端服务当前的连接情况，动态的选取其中积压连接数最少的一台服务器来处理当前请求。尽可能提高后端利用效率，将负载合理的分流到每一台服务器。

四、限流算法

常见的限流算法有三类： 计数器算法、 漏桶算法、令牌桶算法。

1. 计数器（固定窗口）

在一段时间间隔内，处理请求的最大数量固定，超过部分不处理。如指定线程池大小、数据库连接池大小、nginx连接数等都属于计数器算法
算法实现：设置一个计数器counter，每当请求过来的时候+1，如果大于设定值就拒绝访问。如果请求与之前间隔大于一分钟，就重置counter。

临界问题：假如用户在 0 : 59 时候瞬间发了100个请求，然后在 1 : 00 又瞬间发送了100个请求。 那么实际上这个用户在1秒内瞬间发了200个请求。可能会压垮服务。

2. 滑动窗口

滑动窗口是将时间周期分为N个小周期，分别记录每个小周期内访问次数，并根据时间滑动删除过期的小周期。
周期越小，滑动窗口越平滑，限流统计越准确。

3. 漏桶

水从进水口进入漏桶，漏桶以一定速度出水，当水流入速度过大，桶内总水量大于桶容量会直接溢出，请求被拒绝。

算法通常用于限制外部接口流量，保护其他人的系统，如银行接口。
算法缺点：瞬时流量大，大部分会被丢掉。出口速度固定，不能灵活的应对后端能力提升，比如动态扩容，后端流量从1000QPS提升到1w QPS。 漏桶没办法

4. 令牌桶

以一个设定的速率产生令牌并放入桶中，用户每次请求都得申请令牌，如果令牌不足，则拒绝请求。
令牌的数量和发放速度强相关，如果令牌发放的速度比申请的速度快，令牌桶会放满令牌，直到令牌占满整个令牌桶：

面对瞬间大流量可以拿到很多令牌，算法通常是用于限制被访问的流量，保护自身系统
好处是：可以方便的应对后端扩容，通过改变令牌发放速度，使得出口突发流量能被处理。

五、分布式事务解决方案

两阶段提交（2PC）： MySQL的事务是通过日志系统来完成两阶段提交的。两阶段协议，由事务管理器协调多个资源管理器。

三阶段提交（3PC）：多一个预准备，先问问行不，在执行操作，再提交。

六、分布式Session解决方案

1. Session 复制： 每个服务器都存一份，浪费服务器资源
2. 存储在客户端中： 用户将Session信息保存在cookie中，每次请求http请求附带cookie， cookie有最大限制且有安全隐患。
3. hash一致性：让同一个ip负载到同一服务器中，缺点是水平扩展重新hash，服务器闪断session会被清空，需要重新登录
4. 统一存储：统一存储在Redis 和 DB中， 增加一次网络调用。

七、Session 和 Token的区别

当用户第一次通过浏览器使用用户名和密码访问服务器时，服务器会验证用户数据，验证成功后，在服务器端写入session 数据，向客户端返回sessionId， 浏览器将sessionId保存在cookie中，当用户再次访问浏览器时，会携带sessionId， 服务器拿着sessionId获取到session数据，进行用户信息查询，从而实现登录状态保持。
弊端：

1. 服务器压力增大： 通常session是存储在内存中的，当用户量增大时，服务器的压力增大。
2. CSRF跨站伪造请求攻击 ：session是基于cookie进行用户识别的，如果cookie被恶意网站截获，就会受到跨站请求伪造的攻击。
3. 扩展性不强：如果将来需要搭建多个服务器进行分流，每个服务器虽然执行逻辑一样，但是session数据却不共享，不同服务器无法得到用户登录信息。

token与session的不同主要在：

1. 认证成功后，会对当前用户数据进行加密，生成一个加密字符串token，返回给客户端（服务端并不保存）
2. 浏览器接收到的token值存储在 Local Storage中， 不会像cookie那样自动携带。
3. 再次访问服务器时，服务器对传来的token值进行解密，解密完成后进行用户数据查询，如果查询成功则通过认证，实现状态保持。

八、高并发系统设计

服务单一独立部署
库存预热，采用信号量去查数据库，将数据提前放如redis
动静分离
网关拦截
限流、熔断、降级
队列削峰，不去抢数据库，只去redis 中抢信号量。