分布式核心知识点

1. 分布式介绍：

分布式分为分布式缓存（Redis）、分布式锁（Redis 或 Zookeeper）、分布式服务（Dubbo 或 SpringCloud）、分布式服务协调（Zookeeper）、分布式消息队列（Kafka 、RabbitMq）、分布式 Session 、分布式事务、分布式搜索（Elasticsearch）等。不可能所有分布式内容都熟悉，一定要在某个领域有所专长。

2.分布式理论

分布式理论分为CAP，base理论。

一.CAP理论

任何分布式系统都无法同时满足一致性(consistency),可用性(availibity),分区容错性(partition tolerance)这三项,最多只可同时满足其中的两项.zookeeper和Eureka做注册中心对比：
2.1.zookeeper做注册中心是满足CP，
2.2.Eurka是满足AP，
2.3.nacos同时满足AP和CP

二.base理论

Basically Available(基本可用)
       假设系统，出现了不可预知的故障，但还是能用, 可能会有性能或者功能上的影响，比如RT是	     10ms，变成50ms
       
Soft state（软状态）
      允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时
    
Eventually consistent（最终一致性）
      系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值

关于数据一致性

强一致：操作后的能立马一致且可以访问
弱一致：容忍部分或者全部访问不到
最终一致：弱一致性经过多一段时间后，都一致且正常

3.理解分布式事务？分布式事务的协议有哪些？

分布式事务是指会涉及到操作多个数据库的事务。目的是为了保证分布式系统中的数据一致性。分布式事务类型：二阶段提交 2PC ，三阶段提交 3PC。

 2PC ：第一阶段：准备阶段（投票阶段）和第二阶段：提交阶段（执行阶段）。
 3PC ：三个阶段：CanCommit 、PreCommit 、DoCommit。

4.分布式事务的解决方案有哪些？

分布式事务解决方案： TCC 、2PC和3PC 、事务消息。

5.TCC柔性事务的解决方案

什么是TCC柔性事务

刚性事务：遵循ACID柔性事务：遵循base理论TCC:

将事务提交分为

Try：完成所有业务检查( 一致性 ) ，预留必须业务资源( 准隔离性 )Confirm ：对业务系统做确认提交，默认 /confirm/i阶段不会出错的 即只要Try成功，/confirm/i一定成功Cancel : 业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放, 进行补偿性 TCC 事务和 2PC 的类似，Try为第一阶段，Confirm - Cancel为第二阶段，它对事务的提交/回滚是通过执行一段 /confirm/i/cancel 业务逻辑来实现，并且也并没有全局事务来把控整个事务逻辑TCC交互图 优点：

它把事务运行过程分成 Try、/confirm/i/Cancel 两个阶段每个阶段由业务代码控制，这样事务的锁力度可以完全自由控制不存在资源阻塞的问题，每个方法都直接进行事务的提交 缺点

在业务层编写代码实现的两阶段提交，原本一个方法，现在却需要三个方法来支持对业务的侵入性很强，不能很好的复用 注意：使用TCC时要注意Try - Confirm - Cancel 3个操作的幂等控制，由于网络原因或者重试操作都有可能导致这几个操作的重复执行 6.事务管理器宕掉了，怎么办

做冗余，设置多个事务管理器，一个宕掉了，其他的还可以用。

7.怎么保证分布式系统的幂等性

状态机制。版本号机制。

1.对于每个请求必须有一个唯一的标志，比如订单支付请求，必须要包含订单的id，一个id只能支付一次。

2.每次处理完请求之后，必须要有一个记录标识这个请求已经处理过了，比如最常见的是在mysql中记录一个状态，比如支付前先插入一条这个订单的支付流水，而且支付流水采用唯一约束，只有插入成功才进行支付。

3.每次接受到请求之后需要先判断之前是否已经处理过，比如一条订单已经支付了，那么就一定会有支付流水，如果存在就表示已经支付过了。

8.消息中间件如何解决消息丢失问题

事务消息

消息队列提供类似Open XA的分布式事务功能，通过消息队列事务消息能达到分布式事务的最终一致

半事务消息

暂不能投递的消息，发送方已经成功地将消息发送到了消息队列服务端，但是服务端未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，处于该种状态下的消息即半事务消息。

消息回查

由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，消息队列服务端通过扫描发现某条消息长期处于“半事务消息”时，需要主动向消息生产者询问该消息的最终状态（Commit或是Rollback），该询问过程即消息回查

交互图（来源rocketmq官方文档）

目前较为主流的MQ，比如ActiveMQ、RabbitMQ、Kafka、RocketMQ等，只有RocketMQ支持事务消息

如果其他队列需要事务消息，可以开发个消息服务，自行实现半消息和回查功能

好处

事务消息不仅可以实现应用之间的解耦，又能保证数据的最终一致性同时将传统的大事务可以被拆分为小事务，能提升效率不会因为某一个关联应用的不可用导致整体回滚，从而最大限度保证核心系统的可用性

缺点

不能实时保证数据一致性极端情况下需要人工补偿，比如 假如生产者成功处理本地业务，消费者始终消费不成功 9.常见分布式事务解决方案概览

常见分布式事务解决方案
2PC 和 3PC
两阶段提交, 基于XA协议

TCC
Try、/confirm/i、Cancel事务消息

最大努力通知型

分布式事务分类

刚性事务：遵循ACID柔性事务：遵循base理论

分布式事务框架

TX-LCN：支持2PC、TCC等多种模式

https://github.com/codingapi/tx-lcn更新慢（个人感觉处于停滞状态） Seata：支持 AT、TCC、SAGA 和 XA 多种模式

https://github.com/seata/seata背靠阿里，专门团队推广阿里云商业化产品GTS

https://www.aliyun.com/aliware/txc RocketMq：自带事务消息解决分布式事务

https://github.com/apache/rocketmq 10.分布式事务常见核心概念

前置知识

X/OpenDTP 事务模型

是X/Open 这个组织定义的一套分布式事务的标准，也就是定义了规范和 API 接口，由各个厂商进行具体的实现

DTP 是分布式事物处理(Distributed Transaction Processing)的简称

XA协议

XA是由X/Open组织提出的分布式事务规范。

XA规范主要定义了(全局)事务管理器(TM)和(局 部)资源管理器(RM)之间的接口

主流的数据库产品都实现了XA接口，是一个双向的系统接口，在事务管理器以及多个资源管理器之间作为通信桥梁

JTA

Java Transaction API,java根据XA规范提供的事务处理标准

AP

application, 应用程序也就是业务层，微服务等

RM

Resource Manager，资源管理器。一般是数据库，也可以是其他资源管理器，比如消息队列，文件系统

TM

Transaction Manager ，事务管理器、事务协调者，负责接收来自用户程序（AP）发起的 XA 事务指令，并调度和协调参与事务的所有 RM（数据库），确保事务正确完成

事务模型

在分布式系统中，每一个机器节点能够明确知道自己在进行事务操作过程中的 结果是成功还是失败，但无法直接获取到其他分布式节点的操作结果

当一个事务操作跨越多个分布式节点的时候，为了保持事务处理的 ACID 特性，

需要引入一个“协调者”（TM）来统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点被称为 AP。

TM 负责调度 AP 的行为，并最终决定这些 AP 是否要把事务真正进行提交到（RM）

11.如何保证消息队列的高可用

可用采用集群来保证高可用,以RabbitMQ为例,推荐采用镜像集群,普通集群如果磁盘节点挂了就GG了,还是无法保证高可用,镜像集群的配置要用到HAProxy,需要在后台管理页面中设置策略,将ha-mode设置为all,表明每个节点上都存放镜像…限于篇幅,具体的集群配置我后面会专门写一篇博客总结.

12.项目中为什么引入消息队列

解耦，异步，削峰

解耦：
异步
削峰

13.如何保证消息的消费顺序?

以rabbitmq为例,消息1和消息2需要按顺序消费,必须先消费消息1,后消费消息2,我们可以将消息放顺序到不同的queue里,然后由worker来消费.

14.如何解决消息队列的延时及过期失效问题?

批量重导,自己写程序把失效的数据查出来然后重新导入队里中.

15.消息队列满了怎么处理?当消息过度积压怎么处理?

应当在设计上尽量避免出现这种问题,如果确实已经碰到了,可以采取服务降级策略,同时临时增加一些消费能力更强劲的消费者,以X倍速率消费队列中积压的消息.

16.消息队列怎么避免重复消费

任何消息队列产品不保证消息不重复，如果你的业务需要保证严格的不重复消息，需要你自己在业务端去重

kafka、rocketmq、rabbitmq等都是一样的

接口幂等性保障 ，消费端处理业务消息要保持幂等性

幂等性，通俗点说，就一个数据或者一个请求，给你重复来多次，你得确保对应的数据是不会改变的

Redis

   //Redis中操作，判断是否已经操作过 TODO

    boolean flag =  jedis.setNX(key);

    if(flag){

         //消费

     }else{

          //忽略，重复消费

     }

Incr 原子操作：key自增，大于0 返回值大于0则说明消费过

  int num =  jedis.incr(key);
                  if(num == 1){
                        //消费
                  }else{
                       //忽略，重复消费
                  }

上述两个方式都可以，但是排重可以不考虑原子问题，数据量多需要设置过期时间，考虑原子问题，

数据库去重表

某个字段使用Message的key做唯一索引

核心还是业务场景，不一定每个消息消费都需要加上述的操作，比如下面的场景

优惠券记录释放的MQ消息，即锁定的消息变成可用的，不管多少次都是一样的结果
update coupon_record set state='NEW' where id =#{id} and state='LOCK'

评论点赞计数，需要保证幂等性，因为一个消息就会导致数值发生变化

17.RabbitMQ是如何保障消息可靠性投递

什么是消息的可靠性投递

保证消息百分百发送到消息队列中去

详细
    保证mq节点成功接受消息
    消息发送端需要接受到mq服务端接受到消息的确认应答
    完善的消息补偿机制，发送失败的消息可以再感知并二次处理

RabbitMQ消息投递路径

生产者-->交换机->队列->消费者

通过两个的点控制消息的可靠性投递

    生产者到交换机
        通过confirmCallback

    交换机到队列
        通过returnCallback

建议

开启消息确认机制以后，保证了消息的准确送达，但由于频繁的确认交互， rabbitmq 整体效率变低，吞吐量下降严重，不是非常重要的消息真心不建议用消息确认机制

18.分布式锁核心知识介绍和注意事项

避免单人超领劵

加锁

本地锁：synchronize、lock等，锁在当前进程内，集群部署下依旧存在问题分布式锁：redis、zookeeper等实现，虽然还是锁，但是多个进程共用的锁标记，可以用Redis、Zookeeper、Mysql等都可以

设计分布式锁应该考虑的东西

排他性

在分布式应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行 容错性

分布式锁一定能得到释放，比如客户端奔溃或者网络中断 满足可重入、高性能、高可用注意分布式锁的开销、锁粒度 19.基于Redis实现分布式锁的几种坑《上》

实现分布式锁 可以用 Redis、Zookeeper、Mysql数据库这几种 , 性能最好的是Redis且是最容易理解

分布式锁离不开 key - value 设置key 是锁的唯一标识，一般按业务来决定命名，比如想要给一种商品的秒杀活动加锁，key 命名为 “seckill_商品ID” 。value就可以使用固定值，比如设置成1

基于redis实现分布式锁，文档：http://www.redis.cn/commands.html#string

加锁 SETNX key value

setnx 的含义就是 SET if Not Exists，有两个参数 setnx(key, value)，该方法是原子性操作

如果 key 不存在，则设置当前 key 成功，返回 1；

如果当前 key 已经存在，则设置当前 key 失败，返回 0

解锁 del (key)

得到锁的线程执行完任务，需要释放锁，以便其他线程可以进入,调用 del(key)

配置锁超时 expire (key，30s）

客户端奔溃或者网络中断，资源将会永远被锁住,即死锁，因此需要给key配置过期时间，以保证即使没有被显式释放，这把锁也要在一定时间后自动释放

综合伪代码

methodA(){
  String key = "coupon_66"

  if（setnx（key，1） == 1）{
      expire(key,30,TimeUnit.MILLISECONDS)
      try {
          //做对应的业务逻辑
          //查询用户是否已经领券
          //如果没有则扣减库存
          //新增领劵记录
      } finally {
          del（key）
      }
  }else{

    //睡眠100毫秒，然后自旋调用本方法
		methodA()
  }
}

存在哪些问题，大家自行思考下

20.基于Redis实现分布式锁的几种坑你是否踩过《下》

多个命令之间不是原子性操作，如setnx和expire之间，如果setnx成功，但是expire失败，且宕机了，则这个资源就是死锁

使用原子命令：设置和配置过期时间  setnx / setex
如: set key 1 ex 30 nx
java里面 redisTemplate.opsForValue().setIfAbsent("seckill_1",1,30,TimeUnit.MILLISECONDS)

业务超时，存在其他线程勿删，key 30秒过期，假如线程A执行很慢超过30秒，则key就被释放了，其他线程B就得到了锁，这个时候线程A执行完成，而B还没执行完成，结果就是线程A删除了线程B加的锁

可以在 del 释放锁之前做一个判断，验证当前的锁是不是自己加的锁, 那 value 应该是存当前线程的标识或者uuid

String key = "coupon_66"
String value = Thread.currentThread().getId()

if（setnx（key，value） == 1）{
    expire(key,30,TimeUnit.MILLISECONDS)
    try {
        //做对应的业务逻辑
    } finally {
    	//删除锁，判断是否是当前线程加的
    	if(get(key).equals(value)){
					//还存在时间间隔
					del（key）
        }
    }
}else{
	
	//睡眠100毫秒，然后自旋调用本方法

}

进一步细化误删

当线程A获取到正常值时，返回带代码中判断期间锁过期了，线程B刚好重新设置了新值，线程A那边有判断value是自己的标识，然后调用del方法，结果就是删除了新设置的线程B的值核心还是判断和删除命令 不是原子性操作导致 21.手把手教你彻底掌握分布式锁lua脚本+redis原生代码编写

前面说了redis做分布式锁存在的问题

核心是保证多个指令原子性，加锁使用setnx setex 可以保证原子性，那解锁使用 判断和删除怎么保证原子性文档：http://www.redis.cn/commands/set.html多个命令的原子性：采用 lua脚本+redis, 由于【判断和删除】是lua脚本执行，所以要么全成功，要么全失败

//获取lock的值和传递的值一样，调用删除操作返回1，否则返回0

String script = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";

//Arrays.asList(lockKey)是key列表，uuid是参数
Integer result = redisTemplate.execute(new DefaultRedisscript<>(script, Integer.class), Arrays.asList(lockKey), uuid);

全部代码

/**
* 原生分布式锁 开始
* 1、原子加锁 设置过期时间，防止宕机死锁
* 2、原子解锁：需要判断是不是自己的锁
*/
String uuid = CommonUtil.generateUUID();
String lockKey = "lock:coupon:"+couponId;
Boolean nativeLock=redisTemplate.opsForValue().setIfAbsent(lockKey,uuid,Duration.ofSeconds(30));
    if(nativeLock){
      //加锁成功
      log.info("加锁：{}",nativeLock);
      try {
           //执行业务  TODO
        }finally {
           String script = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";

                Integer result = redisTemplate.execute(new DefaultRedisscript<>(script, Integer.class), Arrays.asList(lockKey), uuid);
                log.info("解锁：{}",result);
            }

        }else {
            //加锁失败，睡眠100毫秒，自旋重试
            try {
                TimeUnit.MILLISECONDS.sleep(100L);
            } catch (InterruptedException e) { }
            return addCoupon( couponId, couponCategory);
        }
        //原生分布式锁 结束

遗留一个问题，锁的过期时间，如何实现锁的自动续期 或者 避免业务执行时间过长，锁过期了？

原生方式的话，一般把锁的过期时间设置久一点，比如10分钟时间 22.基于Redis官方推荐-分布式锁最佳实践介绍

原生代码+redis实现分布式锁使用比较复杂，且有些锁续期问题更难处理

官方推荐方式：https://redis.io/topics/distlock多种实现客户端框架Redisson官方中文文档：https://github.com/redisson/redisson/wiki/%E7%9B%AE%E5%BD%95

聚合工程锁定版本，common项目添加依赖（多个服务都会用到分布式锁）

      org.redisson
      redisson
      3.10.1

创建redisson客户端

 @Value("${spring.redis.host}")
    private String redisHost;

    @Value("${spring.redis.port}")
    private String redisPort;

    @Value("${spring.redis.password}")
    private String redisPwd;
    
		
    @Bean
    public RedissonClient redissonClient() {
        Config config = new Config();

        //单机模式
        //config.useSingleServer().setPassword("123456").setAddress("redis://8.129.113.233:3308");
        config.useSingleServer().setPassword(redisPwd).setAddress("redis://"+redisHost+":"+redisPort);

        //集群模式
        //config.useClusterServers()
        //.setScanInterval(2000)
        //.addNodeAddress("redis://10.0.29.30:6379", "redis://10.0.29.95:6379")
        // .addNodeAddress("redis://127.0.0.1:6379");

        RedissonClient redisson = Redisson.create(config);

        return redisson;
    }

23.Redisson实现优惠券微服务领劵接口的分布式锁

优惠券微服务，分布式锁实现方式

Lock lock = redisson.getLock("lock:coupon:"+couponId);
//阻塞式等待，一个线程获取锁后，其他线程只能等待，和原生的方式循环调用不一样
lock.lock();
        try {
            CouponDO couponDO = couponMapper.selectOne(new QueryWrapper().eq("id", couponId)
                    .eq("category", couponCategory)
                    .eq("publish", CouponPublishEnum.PUBLISH));

            this.couponCheck(couponDO,loginUser.getId());

            CouponRecordDO couponRecordDO = new CouponRecordDO();
            BeanUtils.copyProperties(couponDO,couponRecordDO);
            couponRecordDO.setCreateTime(new Date());
            couponRecordDO.setUseState(CouponStateEnum.NEW.name());
            couponRecordDO.setUserId(loginUser.getId());
            couponRecordDO.setUserName(loginUser.getName());
            couponRecordDO.setCouponId(couponId);
            couponRecordDO.setId(null);
            //高并发下扣减劵库存，采用乐观锁,当前stock做版本号,一次只能领取1张
            int rows = couponMapper.reduceStock(couponId);

            if(rows == 1){
                //库存扣减成功才保存
                couponRecordMapper.insert(couponRecordDO);
            }else {
                log.warn("发放优惠券失败:{},用户:{}",couponDO,loginUser);
                throw new BizException(BizCodeEnum.COUPON_NO_STOCK);
            }

        }finally {
            lock.unlock();
        }

24.Redisson是怎样解决分布式锁的里面的坑

简介：redisson解决分布式锁里面的坑

问题 : Redis锁的过期时间小于业务的执行时间该如何续期？

watch dog看门狗机制

负责储存这个分布式锁的Redisson节点宕机以后，而且这个锁正好处于锁住的状态时，这个锁会出现锁死的状态。或者业务执行时间过长导致锁过期，

为了避免这种情况的发生，Redisson内部提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期。

Redisson中客户端一旦加锁成功，就会启动一个watch dog看门狗。watch dog是一个后台线程，会每隔10秒检查一下，如果客户端还持有锁key，那么就会不断的延长锁key的生存时间


默认情况下，看门狗的检查锁的超时时间是30秒钟，也可以通过修改Config.lockWatchdogTimeout来另行指定

指定加锁时间

// 加锁以后10秒钟自动解锁
// 无需调用unlock方法手动解锁
lock.lock(10, TimeUnit.SECONDS);

// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁
boolean res = lock.tryLock(100, 10, TimeUnit.SECONDS);

if (res) {
   try {
     ...
   } finally {
       lock.unlock();
   }
}

小滴课堂官网：https://xdclass.net/#/index