【分布式】基于Zookeeper实现分布式锁、秒杀问题复盘

分布式

内容管理

    • 乐观锁和悲观锁 选择
      • 乐观锁 ---海量写请求大量失败
      • 悲观锁 ---- 海量请求 单线程依次执行 响应慢
      • 令牌桶限流
    • Zookeeper注册中心 intro
    • SpringBoot整合ZooKeeper
    • Zookeeper分布式锁
    • 高并发抢红包使用Zookeeper分布式锁
      • Tomcat并发量有限制
      • 缓存与数据库双写一致性


分布式锁解决方案 — 乐观锁和悲观锁的选择、tomcat并发、缓存一致、基于Zookeeper实现分布式锁、高并发抢红包系统复盘


还要加快一点,时间来不及了… redis、 mq、锁redisson等技术重构cfeng.net 成为一个可以分布式部署的项目

乐观锁和悲观锁 选择

前面的分布式锁分别使用了数据库级别的乐观锁、悲观锁和redis实现,谈了实现,这里cfeng补充一点乐观锁、悲观锁的选择问题,解释他们各自的问题(当然基本的乐观锁适合读多写少,悲观锁适合写多读少基本的都know】

首先最基本的需要明确: 乐观锁是无锁结构,悲观锁是一种思想,加上显式的锁解决冲突问题,比如锁代码块的java提供的synchronized,锁数据的数据库提供的行锁、表锁、X锁、S锁等

乐观锁 —海量写请求大量失败

乐观锁的两种基本实现 CAS (ABA还是要version才能解决)和 version版本号机制,本身是没有加锁的,就像之前Cfeng的提现请求(重复提交问题),当然可以很好解决,也就是只有最先到达的就更新成功,同时操作的系统的线程就可能失败

而如果是并发秒杀, 1000个不同的用户秒杀100件商品,如果不是使用提前到redis缓存中处理减库存,直接在数据库中操作,使用Jmeter测试,如果加上乐观锁,虽然可以防止超卖,但是售出的远远不到100个 【explain: 如果同时有10个线程查询到版本号为1,其中一个线程更新成功,变为2,那么其余9个都失败了,所以1/10的请求有效】 大量的请求都返回抢购失败,影响用户体验,也影响商家(没卖完)

所以乐观锁适合的是并发量较小的、修改少的传统系统,可以防止几个人同时更改数据, 乐观锁因为无锁,不需要额外的锁操作开销,同时也可以提高并发量,吞吐量

需要注意,乐观锁为无锁,使用乐观锁需要注意不要乱用数据库事务@Transactional, 比如mysql默认的READ_REPEATEABALE,本身就调用了相关的数据库锁; 所以要么就使用最低的事务隔离级别read_uncommitted; 或者不使用事务,去掉@Transactional

同时解释事务和 锁的关系: 事务是一种粗粒度的对于数据库表的并发限制,保证数据操作正确,但是不能保证业务操作正确,事务ACID

悲观锁 ---- 海量请求 单线程依次执行 响应慢

悲观锁无论是代码级别的锁,还是数据库排他锁for update,都是只能单线程操作,当前线程操作的时候,其他线程都是不能操作的,处于阻塞状态,这样可能让后面的请求进行长时间的阻塞等待,在用户视角就是一直等待页面响应(explain:如果同时1000个线程同时操作一个悲观锁加持的片段,获取到释放需要20ms,那可能需要等待1000 * 20 = 20s,长时间的阻塞等待、假死】,所以需要使用redis缓存加快访问速度

悲观锁主要就是主键情况下加行锁排他锁锁数据,保证同时只有一个线程更新,为了提高用户体验,可以在请求达到后台时,进行限流,比如让请求全部进入rabbitMQ,逐步被操作; 或者可以使用令牌桶进行限流

令牌桶限流

rabbitMQ限流的方式就是Producer将所有的请求发送给消费者逐步处理, 而令牌桶算法就是防止阻塞,进行流量限制,让流量均匀发送。

大小固定的令牌桶以恒定的速率不断产生令牌,如果令牌没有消耗,或者小于产生的速率,那么令牌就会将桶填满,再产生的令牌就会从桶中溢出,保持最大量有限

【分布式】基于Zookeeper实现分布式锁、秒杀问题复盘_第1张图片

而在项目中,可以直接借助Guava提供的RateLimiter实现令牌桶限流接口

Guava是Google开源工具类,提供了限流工具类RateLimiter进行令牌桶算法方式的限流,可以直接引入依赖,使用

<dependency>
            <groupId>com.google.guavagroupId>
            <artifactId>guavaartifactId>
            <version>${guava.version}version>
        dependency>

之后在后台的请求接口中使用RateLimiter进行限流

@RequestMapping("/account")
public class UserAccountController {

    private final UseAccountService accountService;

    //令牌桶方式限流,这里借助工具类,每s放行10个请求
    RateLimiter rateLimiter = RateLimiter.create(10);

    //方便测试,这里就直接使用参数的方式接收
    @GetMapping("/getMoney")
    public ResponseEntity<String> getMoney(UserAccountDto userAccountDto) {
        //阻塞式获取令牌
//        log.info("等待时间" + rateLimiter.acquire());
        //非阻塞式获取令牌
        if(!rateLimiter.tryAcquire(1000, TimeUnit.MILLISECONDS)) {
            log.warn("被限流了,直接返回失败,说明没库存了");
            return new ResponseEntity<>("获取数据失败,被限流了",HttpStatus.OK);
        }
        if(Objects.isNull(userAccountDto.getAccount()) || Objects.isNull(userAccountDto.getUserId())) {
            return new ResponseEntity<>("参数错误",HttpStatus.BAD_REQUEST);
        }
        try {
//            accountService.takeMoney(userAccountDto);
//            accountService.takeMoneyWithVersion(userAccountDto);
//            accountService.takeMoneyWithLock(userAccountDto);
//            accountService.takeMoneyWithRedisLock(userAccountDto);
            accountService.takeMoneyWithZookeeper(userAccountDto);
            return new ResponseEntity<>("提现成功", HttpStatus.OK);
        } catch (Exception e) {
            return new ResponseEntity<>("出现错误",HttpStatus.NOT_FOUND);
        }
    }
}

RateLimiter rateLimiter = RateLimiter.create(10); 初始化令牌桶类,每s放行10个请求, 而请求获取 令牌也有两种方式:

  • 阻塞式获取令牌: 请求线程进入后,如果令牌桶内没有足够多的令牌,就在此处阻塞,等待令牌的发放
  • 非阻塞式获取令牌: 请求线程进入后,如果令牌桶没有足够的令牌,会尝试等待设置好的时间(这里1000ms),如果还是没有拿到令牌,那么直接返回请求失败(因为前面已经发行了足够多的请求进入服务参与秒杀, 这些请求就算进入都是失败的),如果timeout设置0,那么就式阻塞式

【相关的原理源码后续看情况解释】

测试发现1000个线程/1s,在配合Zookeeper分布式锁 + RateLimiter接口限流 (虽然因为机器原因还是5%的请求挂了),大部分请求直接在controller限流位置非阻塞位置返回,没有进入service执行,最终只有一个请求执行成功

Zookeeper注册中心 intro

分布式架构项目 — 系统拆分、独立部署、服务模块解耦;随之而来的分布式事务、数据一致性、分布式架构下的并发安全问题; 除了可以利用数据库级别的乐观、悲观锁;以及借助redis原子性SETNX实现分布式锁,还可以利用注册中心Zookeeper实现分布式锁

Zookeeper的功能特性:

  • 顺序一致性: 从同一个客户端发起的请求,最终严格按照顺序应用到ZooKeeper
  • 原子性: 所有的事务请求结果在整个集群所有机器上的应用情况一致,整个集群中所有机器的状态一致
  • 单一系统映像:ZooKeeper集群中每一台ZooKeeper机器中数据模型相同(冗余)
  • 可靠性 : 一旦更改被应用,更改结果就会持久化,直到下一次覆盖

Zookeeper是 分布式的服务协调中间件(注意其他的分布式服务minIO、rabbitMQ),采用同一的协作方式管理各个子系统(之前Cfeng的博客简单提过RPC框架Dubbo服务发现), 最终使分布式系统像一个动物园一样

【分布式】基于Zookeeper实现分布式锁、秒杀问题复盘_第2张图片

节点: Zookeeper中节点分为 构成集群的机器的 机器节点 以及 数据模型中的数据单元的数据节点; 不管是机器节点还是数据节点都是ZNode

ZooKeeper将所有的数据存储在内存中,最终的数据模型就构成了一颗树,和linux的文件系统一样,构成一棵文件树,节点 对应的就是路径 ; 每个节点保存着相关的信息

临时节点: 生命周期和客户端会话绑定在一起,客户端会话失效,节点就会删除,创建ZNode可以带上标识(整型数字)

持久节点: ZNode被创建了,除非主动移除ZNode,否则就一直都在Zookeeper,和客户端会话没有关系

Watcher监听器: 事件监听器,ZooKeeper允许用户在指定的ZNode创建监听事件,一旦事件触发,Zookeeper就会通知到相关的Client

Zookeeper是高可用的,Zookeeper集群,一般部署奇数个实例,当其中leader挂掉,就会重新选举产生新的Leader【所以Zookeeper和Redis有很多相似之处,包括分布式锁】

Zookeeper作为 典型的分布式数据一致性的解决方案,可以基于ZooKeeper实现数据发布/订阅、负载均衡、命名服务、分布式协调通知、集群管理、分布式锁、分布式队列

统一配置管理: 每一个子系统都需要的配置文件统一放置到Zookeeper的ZNode节点

统一命名服务: 通过ZNode进行统一命名,各个子系统可以通过名字获取到节点上相应的资源

分布式锁: 通过创建与该 共享资源 相关的 顺序临时节点 与 动态监听机制, 控制多线程对共享资源的并发访问 ( 临时节点是核心)

集群状态: 可以动态感知节点的CRUD,保证集群下 的相关节点的主、副本的一致性

Zookeeper的典型应用场景就是配合Dubbo作为注册中心; 服务生产者将子集提供的服务注册到ZooKeeper中心,服务消费者进行服务调用时先在Zookeeper中查找服务,获取到服务生产者的详细信息后,在去调用服务生产者提供的接口

 |==========--------------> 注册中心Zookeeper <-- 发布暴露服务,接口方法签名--------------------|
消费者  <-----------------异步通知-|         直接通过HTTP调用,或者RPC远程协议(DUBBO)        生产者(注册发布服务系统)
【订阅调用服务系统】																		 |
   |																					|
   =============================> 监控器 <======================================================

虽然目前使用SpringCloud较多,但是Dubbo也还是有可用之处,后期Cfeng可能会分享基于Dubbo重构微服务项目(不使用SpringCloud)

SpringBoot整合ZooKeeper

整合Zookeeper首先需要安装Zookeeper,直接到官网下载即可,如果是Windows版本,那么就直接安装到本地,点击bin下埋你的zkServer.cmd就可以运行ZooKeeper服务端 【和redis-Windows类似,mongoDB需要以命令行方式指定dbpath启动】

首先需要引入相关的依赖


        <dependency>
            <groupId>org.apache.zookeepergroupId>
            <artifactId>zookeeperartifactId>
            <version>3.6.2version>
            <exclusions>
                <exclusion>
                    <groupId>org.slf4jgroupId>
                    <artifactId>slf4j-log4j12artifactId>
                exclusion>
            exclusions>
        dependency>

        <dependency>
            <groupId>org.apache.curatorgroupId>
            <artifactId>curator-frameworkartifactId>
            <version>4.2.0version>
        dependency>

        <dependency>
            <groupId>org.apache.curatorgroupId>
            <artifactId>curator-recipesartifactId>
            <version>4.2.0version>
        dependency>

springboot要使用zookeeper服务,也是通过网络进行连接该服务,引入依赖之后,就在yml中配置相关的依赖项

#### zookeeper的配置 -- 主机和命名空间, 命名空间用于区分不同的机器
zk:
  host: 127.0.0.1:2181
  namespace: cfengHost

这里是自动配置的,高度封装的Curator框架,使用该框架实例可以解决底层的问题: 重连、反复注册、NodeExistsException

在SpringBoot项目中,可以自定义注入CuratorFramework实例 对Zookeeper进行相应的操作,创建一个Zookeeper的配置类管理配置

//这里也是使用Environment对象来获取配置文件中的内容
 * 自定义配置CuratorFramework对象用来实现Zookeeper的快速操作使用
 */

@Configuration
@RequiredArgsConstructor
public class ZooKeeperConfig {

    private final Environment environment;

    /**
     * 自定义注入Bean-Zookeeper高度封装的客户端Curator实例
     * 采用工厂模式进行创建,指定客户端连接到Zookeeper服务端的策略: 采用重试机制 5次,每次间隔1s 100ms
     */
    @Bean
    public CuratorFramework curatorFramework() {
        CuratorFramework curatorFramework = CuratorFrameworkFactory.builder().connectString(Objects.requireNonNull(environment.getProperty("zk.host"))).namespace(Objects.requireNonNull(environment.getProperty("zk.namespace")))
                .retryPolicy(new RetryNTimes(5,1000)).build();
        curatorFramework.start();
        return curatorFramework;
    }
}

配置Zookeeper操作对象CuratorWork就可以借助该对象进行节点的各种操作完成Zookeeper的功能

启动项目,可以看到ZooKeeper的相关的日志信息

rg.apache.zookeeper.ZooKeeper           : Client environment:zookeeper.version=3.6.2--803c7f1a12f85978cb049af5e4ef23bd8b688715, built on 09/04/2020 12:44 GMT
2022-09-21 15:29:55.690  INFO 9176 --- [           main] org.apache.zookeeper.ZooKeeper           : Client environment:host.name=DESKTOP-4A4BD0R
2022-09-21 15:29:55.690  INFO 9176 --- [           main] org.apache.zookeeper.ZooKeeper           : Client environment:java.version=16

Zookeeper分布式锁

Zookeeper作为注册中心进行服务发布、订阅,还可以利用创建 与 共享资源 相关的 顺序临时节点, 采用Zookeeper提供的监听器Watcher机制,控制多线程的共享资源的并发访问

ZooKeeper架构通过冗余实现高可用性,当其中一个Zookeeper无应答,就询问另外一个主机,Zookeeper将数据存储在一个分层的命名空间(类似linux的文件系统),类似前缀树结构,客户端可以在节点进行读取

其实可以按照redis的实现思路来理解,核心过程:

  1. 操作共享资源前加上锁 ----- 创建临时顺序节点,利用Watcher监听器不断监听到最小序号的节点
  2. 获取锁成功就可以进行操作
  3. 操作完成 当前线程释放锁 — 删除对应的最小序号的临时节点,让其他的节点序号变为最小,其对应的线程获取到锁 【可重入、高可用、不死锁、互斥、公平】

在zookeeper指定节点locks下面创建临时节点node_n

获取locks下面的所有的子节点children

对子节点按照自增序号从小到大排序

判断本节点是否为第一个节点(序号最小),是则获取锁,不是就监听Watcher比其小节点的删除时间

若删除事件发生,回到前面重新判断,直到获取到锁

【所以和redis一样存在一个等待队列,所以是可重入的】

【分布式】基于Zookeeper实现分布式锁、秒杀问题复盘_第3张图片

核心就是创建临时顺序节点和采用Watcher机制监听临时节点的增减和删除

而在具体实现中,还可以直接使用ZooKeeper的InterProcessMutex(进程间 互斥)实现分布式锁【 InterProcessMutext为公平的可重入锁】

【分布式】基于Zookeeper实现分布式锁、秒杀问题复盘_第4张图片

InterProcessMutex 不依赖JVM,所以可以用作分布式锁

//基于zookeeper实现分布式锁
    @Override
    public void takeMoneyWithZookeeper(UserAccountDto userAccountDto) throws Exception {
        //主要依赖的是ZooKeeper的InterProcessMutex类进程互斥
        //Znode的节点路径
        final String pathPrefix = "/middleware/zkLock";
        //创建Zookeeper的进程互斥锁实例,尝试获取锁的最长的事件为20s,这里创建和资源相关的锁
        InterProcessMutex mutex = new InterProcessMutex(zookeeperClient,pathPrefix + userAccountDto.getUserId() + "-lock");
        try {
            //当前线程对应的节点尝试获取锁,获取的最大等待时间20s
            if(mutex.acquire(10L,TimeUnit.SECONDS)) {
                //当前线程获取到锁
                UserAccount userAccount = userAccountMapper.selectByUserId(userAccountDto.getUserId());
                if(!Objects.isNull(userAccount) && userAccount.getAmount().doubleValue() > userAccountDto.getAccount()) {
                    //提现
                    int res = userAccountMapper.updateAmount(userAccountDto.getAccount(),userAccountDto.getUserId());
                    if(res > 0) {
                        //提现成功
                        UserAccountRecord record = new UserAccountRecord();
                        record.setCreateTime(LocalDateTime.now());
                        record.setAccountId(userAccount.getId());
                        record.setMoney(BigDecimal.valueOf(userAccountDto.getAccount()));

                        accountRecordMapper.insert(record);
                        log.info("zookeeper分布式锁 -当前待提现金额为:{},账户的余额为: {}, 成功", userAccountDto.getAccount(), userAccount.getAmount());
                        //成功后结束
                    } else {
                        throw new Exception("更新出现异常");
                    }
                } else {
                    throw new Exception("账户余额不足");
                }
            } else {
                throw new Exception("获取分布式锁失败Zookeeper");
            }
        } catch (Exception e) {
            throw e;
        } finally {
            //为了保证不死锁,不管正常还是异常,都需要释放锁
            mutex.release();
        }
    }

这里最关键首先就是创建一个Mutext节点,使用当前节点获取锁,获取到锁之后使用之后一定要正常释放,使用finally即可,和redis类似

ZooKeeper的分布式锁主要就是创建节点ZNode,所以这种方式具有时间开销,需要耗费一定时间进行节点的CRUD, 这种开销可以通过集群部署多个ZooKeeper缓解

高并发抢红包使用Zookeeper分布式锁

之前高并发抢红包为了避免同一个用户抢到多个红包,使用redis的SETNX作为分布式锁,这里可以再次使用ZooKeeper分布式锁来代替

为了能够高效的进行相应,红包生成后是直接放在缓存中,异步方式将相关记录计入数据库

/**
     * 抢红包核心业务,需要首先在缓存中查找红包并且进行记录,抢到红包后需要调用DetailService写入数据库
     * @param userId
     * @param redId
     * @return
     * @throws Exception
     */
    @Override
    public BigDecimal rob(Integer userId, String redId) throws Exception {
        //Redis操作组件
        ValueOperations valueOperations = redisTemplate.opsForValue();
        //抢红包前先判断是否抢过红包,如果已经抢过了,就直接返回红包金额,前台显示即可 redId : userID : rob  这里是抢到的ID
        Object object = valueOperations.get(redId + ":" + userId + ":rob");
        if(object != null) {
            return new BigDecimal(object.toString());
        }
        //点红包 --- 判断缓存系统中是否有红包剩余,> 0
        Boolean res = clik(redId);
        //有红包则进入拆红包业务逻辑
        if(res) {
            //分布式锁,每一个人一次只能抢到一次红包,一对一关系
//            final String lockKey = redId + ":" + userId + "-lock";
            final  String lockKey = "/middleware/zkLock/" + redId + "-" + userId + "-lock";
            InterProcessMutex mutex = new InterProcessMutex(zookeeperClient,lockKey);
            //从小红包列表中拆一个红包

            //调用setIfAbsent方法,实现分布式锁,也就是这里pop是只能一次弹一个
//            Boolean lock = valueOperations.setIfAbsent(lockKey,redId);
            //设置分布式锁过期时间24小时
//            redisTemplate.expire(lockKey,24L,TimeUnit.HOURS);

            try {
                //判断当前线程是否获取到了锁
//                if(lock) {
                //这里采用zookeeper获取锁
                if(mutex.acquire(10L,TimeUnit.SECONDS)) {
                    Object value = redisTemplate.opsForList().rightPop(redId);
                    //如果红包金额不为空,说明有红包,有钱
                    if(value != null) {
                        //抢到一个,总数减少
                        String redTotalKey = redId + ":total";
                        //获取当前总数,如果为空则总数为0, 同时更新; 但这里的操作不是但命令,不具有原子性,会出现安全问题,需要修改
//                        Integer currentTotal = valueOperations.get(redTotalKey) != null ? (Integer)valueOperations.get(redTotalKey) : 0;
//                        valueOperations.set(redTotalKey,currentTotal - 1);
                        valueOperations.increment(redTotalKey,-1);

                        //处理红包金额为元
                        BigDecimal result = new BigDecimal(value.toString()).divide(new BigDecimal(100));
                        //抢到红包的信息记录进入数据库
                        redDetailService.recordRobedPacket(userId,redId,new BigDecimal(value.toString()));
                        //当前用户抢过红包了,使用Key进行标识,设置过期时间为1天
                        valueOperations.set(redId + ":" + userId + ":rob",result,24L, TimeUnit.HOURS);
                        log.info("当前用户抢到红包了:剩余红包数量:{},userId={} key={} 金额={}",valueOperations.get(redTotalKey),userId,redId,result);

                        return result;
                    }
                }
            } catch (Exception e) {
                throw new Exception("加分布式锁失败");
            } finally {
                //分布式锁必须释放
//                if(Objects.equals(redId,valueOperations.get(lockKey))) {
//                    //释放当前线程的redis的锁key
//                    redisTemplate.delete(lockKey);
//                }
                mutex.release();
            }
        }
        //null表示当前用户没有抢到红包
        return null;
    }

    /**
     * 点红包业务逻辑: 判断缓存系统是否有红包
     */
    private Boolean clik(String redId) throws Exception {
        ValueOperations valueOperations = redisTemplate.opsForValue();
        //获取红包总数 key:total
        String redTotalKey = redId + ":total";
        //获取剩余个数
        Object total = valueOperations.get(redTotalKey);
        //判断剩余个数是否大于0
        if(total != null && Integer.valueOf(total.toString()) > 0) {
            //还有红包
            return true;
        }
        return false;
    }

当然实际的项目中,第一次查询的时候会先将库存加载到缓存中

Tomcat并发量有限制

这里发起13000线程/1s, 出现的结果是部分线程报错:

org.apache.http.conn.HttpHostConnectException: Connect to 127.0.0.1:8081 [/127.0.0.1] failed: Connection refused: connect
	at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:156)

在这里插入图片描述

只有一半的请求请求成功,虽然那一半的请求确实也是正确的(10个人抢到了红包),且符合使用缓存的情况,1453个请求每秒 ,比不使用缓存性能提升了好几倍

而至于为什么一半的请求全部挂掉了,就是因为SpringBoot内置的Tomcat 最大并发数有限(Tomcat本身也是一个应用,需要考虑它能够抗住高并发),不然请求挂在Tomcat,进入不了应用也白忙活了【RabbitMQ也有心无力,都没有进入】

可以修改yml配置文件,手动”天真的“ 设置最大并发数和最大连接数,手动调优【因为确实还是扛不住】 — 所以这里就引出 进一步的处理方式 ---- Nginx控制流量

server:
  tomcat:
    threads:
      max: 13000  #tomcat可承受最大并发数,默认200 【再大可能机器扛不住】
    max-connections: 13000  #最大连接数,默认8972

事实证明,这也确实很天真,再次发起请求,还是崩了,Error的达到了59%,吞吐量还是1400左右,还是只有少部分请求请求成功,一个Tomcat扛不住,搭建集群还是不可能抗住上百万的流量,所以Nginx必须限流 — 保证到达Tomcat容器的流量在可承受范围内

再给个解决方案: Cache aside

缓存与数据库双写一致性

缓存虽然确实可以提高访问速度、增大系统吞吐量,降低数据库压力,保证应用平稳运行,但是也可能带来问题, 其中一个问题: 数据库和缓存的一致性

延时双删: 先淘汰缓存、写数据库,休眠1s,再次淘汰Cache; 【可以删除1s内缓存的脏数据】

后面具体遇到强一致性业务场景再详解

你可能感兴趣的:(分布式,【中间件】,分布式,java-zookeeper,zookeeper,spring,boot)