分布式 笔记

1、分布式锁的实现方式：
1、数据库
基于数据库表：
创建一张锁表：id、方法名称（唯一索引）、备注信息、参数信息（对应重载方法）、更新时间
锁住一个方法等价于往锁表里插入一行数据，通过方法名称字段的唯一性把其他想获得方法的线程给校验住
缺点：数据库挂了就很麻烦，需要主从、锁没有过期时间，需要整一个定时任务来删数据、线程请求一次锁失败了不会自旋转，需要在while循环里面不断请求，不是可重入锁，需要在锁表里面新开一个主机信息与线程信息的字段。

基于数据库排他锁
创建一张锁表：id、方法名称（唯一索引）、备注信息、参数信息（对应重载方法）、更新时间
锁住一个方法等价于开启一个事务通过for update的方法来查询method name，查到之后数据库就会给他上排他锁，执行完方法之后再主动地提交事务，拿不到锁的就while里面try catch反复执行
缺点：for update 查询条件必须加索引否则锁住整张表、如果查询范围大，走全表扫描可能会锁整张表、多个重载方法需要添加具体参数与返回值做区分，导致查询语句复杂、查询语句需要占用数据库连接，阻塞的线程越多占用的连接就越多，可能会把数据库连接池撑爆。

2、redis
基于Redis命令
加锁：setNX 、释放锁：DELETE
命令：setNX key value EX seconds（seconds秒） PX milliseconds（milliseconds毫秒）
缺点：delete命令可能误删key（无需识别则可删除key）、不支持阻塞等待与可重入。
基于Redis Lua脚本（保证加锁、解锁的原子性）
加锁：SET lock_name random_value EX seconds NX、
释放锁：if redis.call("get",KEY[1])==ARGV[1]
then return redis.call("del",KEYS[1])
else return 0
end
缺点：不支持阻塞等待与可重入、Redis挂了就寄了
基于Redission
加锁模式：单点、主从、哨兵、集群模式
加锁：根据锁名查看是否有锁，如果无，则通过LUA脚本加锁，加锁参数：锁名（key）、当前线程的唯一标识(value)、持有锁的时间。如果有，则看是不是当前线程的锁，如果是，则可重入次数加一，如果不是，直接返回。
解锁：查找锁是否存在，如果不存在则广播解锁消息，如果存在则根据锁名与唯一标识查看是否存在，如果不存在则表明锁被其他线程占用，如果存在则将可重入计数减1，当可重入计数为0才释放锁。
redlock 红锁
线程向多个独立的redis节点获取锁（避免主从中的异步复制导致锁丢失），获取锁的超时时间要小于锁的失效时间。
当且仅当大多数（N/2 +1）的redis节点都取到锁，且获取锁的时间小于锁失效的时间才算加锁成功。
3、zookeeper
zookeeper为每一个客户端按照先后顺序创建一个临时顺序节点，每一个客户端会在它前面的节点上注册一个监听器，zookeeper按照先后顺序去加锁，具体来说，如果当前客户段创建的节点是最小的，则当前客户端拿到锁。
临时顺序节点的好处：临时节点可以防止死锁，这一点做的比redis友好，当客户端崩溃的时候，链接会自动断开，删除客户端创建的锁节点。而redis得等到锁过期了才能再加锁。顺序节点可以防止锁竞争
4、redis与zookeeper
redis基于内存存储，zookpeer基于磁盘存储，redis并发性能更好
客户端崩溃时，zookeeper释放锁更加及时，redis要等锁过期时间
zookeeper是CP，牺牲可用性保证一致性，因为集群中少于一般的节点或者集群正在进行master选举时都会拒绝新的写请求，无法加锁，保证一致性。redis是AP，保证可用性，因为即使节点出问题，或者集群做数据同步的时候，如果出现网络延迟导致各个节点数据不一致，客户端也可以正常读写，保证可用性。
2、什么是一致哈希
场景：分布式场景下，数据存到哪个数据库一般是用唯一标识对数据库数量取模，但是如果集群需要扩张或者收缩则需要重新计算hash值，这样非常复杂。
3、分布式缓存
1、Guava：Google提供的本地缓存
初始化CacheLoader需要重写load方法，这样在缓存没有命中时会调用该方法。
初始化loadingCache需要传入缓存容量、元素的过期时间、元素失效的监听器、cacheloader
常见方法：get、put、invalidate方法等
@Test
public void testCache() throws ExecutionException, InterruptedException {
CacheLoader cacheLoader = new CacheLoader<String, Animal>() {
// 如果找不到元素，会调用这里
@Override
public Animal load(String s) {
return null;
}
};
LoadingCache<String, Animal> loadingCache = CacheBuilder.newBuilder()
.maximumSize(1000) // 容量
.expireAfterWrite(3, TimeUnit.SECONDS) // 过期时间
.removalListener(new MyRemovalListener()) // 失效监听器
.build(cacheLoader); //
loadingCache.put("狗", new Animal("旺财", 1));
loadingCache.put("猫", new Animal("汤姆", 3));
loadingCache.put("狼", new Animal("灰太狼", 4));

loadingCache.invalidate("猫"); // 手动失效

Animal animal = loadingCache.get("狼");
System.out.println(animal);
Thread.sleep(4 * 1000);
// 狼已经自动过去，获取为 null 值报错
System.out.println(loadingCache.get("狼"));
}
/**
● 缓存移除监听器
*/
class MyRemovalListener implements RemovalListener<String, Animal> { @Override
public void onRemoval(RemovalNotification<String, Animal> notification) {
String reason = String.format("key=%s,value=%s,reason=%s", notification.getKey(), notification.getValue(), notification.getCause());
System.out.println(reason);
}
}
class Animal {
private String name;
private Integer age;
public Animal(String name, Integer age) {
this.name = name;
this.age = age;
}

2、Caffeine Cache：由Guava改进而来的本地缓存
与ConcurrentMap的区别：ConcurrentMap不会显式移除数据，Guava会自动移除不常用的元素。
缓存淘汰策略：LRU、LFU、FIFO，缓存淘汰设置：大小、权重（大小和权重二选一）、时间
3、redis
4、多级缓存策略：
使用本地缓存Guava和redis做一个多级缓存架构。
5、存在的问题：
（1）数据一致性如何处理：
更新数据库-->canal监听binlog，对增量日志解析-->针对本地缓存，借助MQ的广播机制同步。针对redis缓存可以在更新前删除缓存，然后MQ同步缓存。
4、redis到底该如何使用？
1、key的设计：与业务相关，可读性高；长度不能太长；命中率（请求redis次数/总请求树）要高。尽量将读请求多的数据放到缓存。
2、value的设计：尽量小，避免出现big key（单线程容易阻塞，查询、持久化耗时长）
5、分布式协议
1、事务协议
2、一致性协议
3、保活性协议
4、复制协议
6、CAP理论
C：一致性（多个服务之间的数据要保持一致） A：可靠性（不论什么时候都能响应外部请求，但是不管响应是否正确） P：分区容错性（哪怕部分区域出现网络瘫痪，也能对外提供服务）
CAP在分布式场景下只能保证两个，而且无法同时保证CA，所以只有CP和AP
CP：Zookeeper、Nacos
AP：redis，Eureka、Nacos
7、BASE理论：
Basically Available：基本可用。出现故障之后还是能用，只不过需要折损响应时间和功能。
Soft State：软状态。允许多个节点数据存在延时或者短暂不一致
Eventually Consistent：最终一致性。在一定时间后可以达到一个最终的状态。
8、柔性事务&刚性事务：
柔性事务追求最终一致性：TCC（补偿事务）、Sega（业务入侵）；MQ事务消息（依赖MQ）、本地消息表（不支持回滚）
刚性事务追求强一致性：2PC、3PC（因为会提交阶段之前同步阻塞）
8、分布式事务
强一致性：2PC、3PC、Seata中的AT和XA模式
弱一致性：事务消息、最大努力通知、本地消息表、Seata的TCC和Saga模式
1、2PC：两阶段提交 precommit+commit -强一致性
XA协议中的三个角色：AP（应用系统）、TM（事务管理器）、RM（资源管理器、事务的参与者）。主要用于资源管理器和事务管理器之间的通信。
两阶段的提交过程：
准备阶段：TM向RM发送消息，RM收到消息执行事务，如果执行成功就会返回就绪，但是不提交事务，进入同步阻塞状态。
提交阶段：如果所有RM都是就绪，TM向所有RM发送Commit，所有RM提交完事务返回ACK；如果存在RM未就绪，则向所有RM发送rollback，执行事务回滚。
缺点：
对TM强依赖，事务管理器出问题了整个2PC得不到保障，而且会出现单点故障问题；
2PC本身在一阶段结束之后就会出现同步阻塞的问题；
如果RM没收到commit信息就会存在数据不一致。
2、3PC：三阶段提交 -强一致性
将准备阶段细化成两个阶段。
准备阶段：TM向RM发送准备请求，RM不需要执行事务，只需要回复能否操作；如果RM都回复yes，则发送precommit，否则发送abort，中断事务请求。
预提交阶段：执行事务操作，例如写redolog和binlog；RM成功执行事务则返回yes，否则返回no；如果RM全部返回yes则发送docommit，否则回滚。
提交阶段：发送docommit进行事务提交；如果有RM没有收到TM信息，则RM会认为TM出现故障，也会自动提交事务
2PC上的改进：解决2PC中存在的协调者和参与者同时挂掉导致的数据一致性问题。
3、TCC：补偿事务、柔性事务-最终一致性
TCC属于侵入式事务，不依赖于数据库的事务，而是基于业务逻辑的补偿机制把分布式事务分解为多个子事务，每个子事务都有try、confirm、cancel三个操作，通过这些操作实现事务的执行与回滚。
Try（尝试执行）：资源预留与事务前置条件的检查。
Comfirm（确认执行）：所有try阶段的参与方执行成功，则执行事务并提交。
Cancel（取消执行）：如果有节点事务try失败，则回滚事务。
流程：主业务服务调用事务协调者（TM）开启事务，然后调用try接口校验从节点执行事务所需的资源，然后从节点会执行comfirm，如果try或者comfirm执行失败会，TM会调用cancel接口终止事务。
通过日志记录事务失败时的执行状态。当事务提交成功之后就会删除日志。

4、本地消息表-最终一致性
业务操作和消息写入库：在本地事务中执行业务逻辑，然后将需要发送给其他服务的消息插入到消息表，然后提交本地事务
消息发送和状态更新：定时任务扫描消息表中待发送的消息，发送到消息队列。
消息消费与补偿：消费者消费消息后变更消息状态；消费失败可以查询消息表重新消费。
相比于最大努力通知，引入了一张本地的消息表，会更可靠
5、事务消息-最终一致性
例如，使用RocketMQ的事务消息
生产者向MQ发送半事务消息，此消息对消费者不可见；生产者执行事务之后会发送消息给MQ，此时根据事务结果决定是否删除半事务消息。
6、最大努力通知-最终一致性
借助消息队列进行消息异步通知。主要依靠消息队列重试特性确保消息被消费。
7、Sega：长事务解决方案，将长事务拆分成多个本地短事务。
把长事务按顺序拆分成多个本地短事务，并且每个本地短事务都有对应的补偿操作；本地短事务依次执行，执行的过程中有反向恢复和正向重试。
因为正向补偿和反向补偿都需要自己实现，所以对代码有入侵。
反向恢复：当前事务执行失败，把此前执行成功的事务都通过补偿操作回滚。
正向重试：当前事务失败就一直重试。
因为补偿理论上不会出错，但是也需要记录日志。
7、Seata - 一整套分布式的解决方案
一个分布式事务由多个本地事务组成，可以分为：
Transaction Manager（事务管理者）：负责开启、提交、回滚事务。
Transaction Coordinator（事务协调器）：维护分布式事务的全局状态。
Resource Manager（资源管理器）：单个的微服务，执行本地事务。
Seata执行流程：
TM收到请求后，调用TC开启全局事务，并且从TC中获得XID。
TM再通过RPC调用各个微服务RM，并且传递全局事务的XID
RM会根据XID向TC注册一个事务分支
当所有调用链路全部预执行结束后，TM检查是否由RM事务执行失败，如果都成功则发送commit给TC，否则发送rollback。
TC收到TM的消息再协调RM进行二阶段提交，commit或rollback。
四种事务模式：
AT模式：强一致性
它是一种自动提交的无侵入性的事务模式，引入@GlobalTransaction注解即可也是类似于2PC的两段式提交。
一阶段：各个分支事务直接提交，并记录日志用于回滚
二阶段：如果需要回滚直接使用日志回滚，如果不需要则直接结束。
局限性：只能支持具有ACID属性的关系型数据库，但对于redis就不支持，所以redis和数据库无法一起做分布式事务。
TCC模式：最终一致性
需要自己实现try、comfirm、cancel分支，对代码有侵入性。
可以支持redis、es多个非关系型数据库与关系型数据库一起做事务。
Saga模式：最终一致性
适合长事务，将长事务拆分成多个本地事务，依次执行本地事务，需要对每个事务编写正向和反向补偿代码，对代码有侵入性
XA模式：强一致性
将事务分为两个阶段。
一阶段：各个分支事务预提交，并且占用与锁定资源。
二阶段：根据TC决定是否提交事务还是回滚事务。
由于这种模式需要占用资源一直到第二阶段结束，所以性能低。

如何选择分布式事务：
实现成本：对于TCC和2PC都对代码有侵入性，有成本。本地消息表、事务消息，最大努力通知都依赖中间件。
一致性要求：根据CAP理论，不能通知保证一致性和可用性，所以对于核心链路可以保证强一致性（2PC、3PC、AT、XA）、非核心链路保证最终一致性（本地消息表、事务消息、最大努力通知、TCC、Saga）
数据规模：对于数据规模不大的可以使用中间件实现的分布式事务，但在数据量大的情况下不建议只用这种，因为可能存在数据堆积情况。
9、CDN
定义：内容分发网络，它是由分布在不同区域的边缘节点服务器组成的分布式网络。它的作用就是把站点的内容发布到各个边缘节点服务器，用户可以就近获取内容。
如果没有CDN，就需要访问源站，其中会经过多次转发导致延时，还可能丢包，但是有CDN就可以就近访问边缘节点服务器。响应更快。
CND网络就是在用户层和服务器之间增加缓存层，缓存层的目的是用于解析域名得到缓存服务器IP，然后用户和缓存服务器交互，如果缓存服务器没有数据就访问源服务器拿数据。
应用场景：
网站加速：CDN可以缓存静态资源
10、如何将一个项目改造成分布式微服务？
1、分析业务的需求，包括拆分成分布式微服务之后的业务指标、安全指标等要求
2、根据业务需求设计微服务框架，其中包括服务拆分、服务通信、数据存储
3、选择合适的微服务框架
4、编码
5、性能测试
6、运维与监控
11、限流算法
1、固定窗口：固定时间内记录访问请求数并做限制，时间一过计数器清空。缺点是临界问题，可以卡计数器刷新的时间点频繁访问。
2、滑动窗口：为了解决固定窗口存在的临界问题，将窗口进一步细分成小窗口，每个小窗口内有独立的计数器，大窗口每次往前滑一个小窗口的长度，根据所有小窗口内的计数器总和进行限流。缺点是对多余请求会直接拒绝，在部分场景下用户体验不好（占便宜场景除外）。
3、漏桶限流：把所有请求放到固定大小的容器里，以一定的速率处理请求，超出容量后会拒绝请求。
优点是可以平滑流量，缺点是不能应对突发流量。
4、令牌桶限流：往令牌桶里以固定的速率添加令牌，请求需要拿到令牌才能被处理，否则就拒绝请求。
例如Guava的RateLimiter组件，优点在于可以平滑流量，并且可以处理突发流量。
12、为什么不在事务中一起做外部调用
1、增加事务的执行时间，可能增加死锁的概率。
2、增加事务失败的风险、、导致数据不一致：对于用户下单服务，下单部分进行事务操作，最后发MQ通知用户，如果仅仅是MQ发送失败就回滚事务，会出现非核心链路的业务导致核心链路业务执行失败，这本身不合理。并且MQ如果发送消息成功，只是ACK失败，就回滚整个核心链路业务，这就导致数据不一致。
13、Dubbo协议