Redis分布式锁 Spring Schedule实现任务调度

一看到标题就知道，这一篇博客又是总结分布式工作环境中集群产生的问题，个人觉得分布式没有那么难以理解，可能也是自己见识比较浅，对我来说，分布式只是一种后端业务演进时的一种工作方式，而真正实现这种工作方式的是集群

关于集群是什么以及如何搭建集群环境，可以参考之前我的博文，这一片博客将着重介绍Redis分布式锁，这是一个基于SpringBoot构建的高并发电商后端服务项目，并且其中框架包括的Spring Schedule框架搭建的定时任务模块去实现定时关闭未付款的订单

项目地址： https://github.com/challengerzsz/Mall

在项目演进的过程中集群化就意味着复杂，复杂就意味着出问题，那么这个时候今天分享的这个问题是多进程可能在统一进程都去进行关单任务，这是不必要的，后面进行详细分析，希望看到这篇博客的初学者们能够了解到这听起来高大上的概念其实不是那么困难的，有经验的同行们欢迎指正修改

如何去实现一个关单服务

试想一下，自己是否有在购物客户端(web/app)中发起订单之后，本该选择支付的或者是因为什么原因，没钱了也好或者不想买了也好，订单挂在那里，但是却没有取消掉，这个例子在一个场景商城后端的项目中如何去解决呢？

关单的逻辑在我看来可以有下面实现方式

开放关单接口给商家管理端，供商家进入管理端进行手动关单

如果这样实现的话，那么如果商家比较忙忘记了，或者因为订单太多根本来不及处理，怎么办？眼看着商品一件一件减少却不见付款，并且其余想买这件商品的买家因为订单数量为0，不能进行购买，那么你这个购物平台还有什么商家甘愿入驻
开放关闭订单接口给客户端，用户主动取消发起的订单

如果选择这样的实现，可能用户会忘记或者故意卡单不让你售卖出去，占用库存却又不付款，卖家心急，真正想买的人也着急，挂起订单的买家还有种皇上不急太监急的感觉
服务端定时关单

定时关单的逻辑就需要用到Spring Schedule的定时任务框架，通过制定合理地策略帮助卖家删除那些被遗忘的却又被发起订单了的数据，顺便提一句，之前我也写过类似的定时任务，但是是在MySQL中进行编码的，也就是说定时任务的执行我交给了数据库去进行，我们知道I/O操作是比较耗时的操作，比如上一篇分析服务器宕机的问题，如果MySQL状态正忙，这个时候再来一大堆定时任务需要删除的订单，不用说想必已经知道结果

现在的购物平台给我的感觉这三种逻辑是都存在的，肯定也存在别的实现方式，我在这里也就是举例一下，下面来说今天的主题

Spring Schedule实现定时关单

今天的主题其实是上述三种分析的第三种实现，使用Spring提供的框架实现定时任务，制定自己的逻辑，下面介绍Schedule这个框架的时候，大家可以大概了解一下cron表达式，并且可以百度搜索一些cron自动生成的网站去方便开发

Spring Schedule给我的感觉优点有下面3点

基于注解来设置调度器。
非常方便实现简单的调度
对代码不具有入侵性，非常轻量级

什么是cron表达式

cron表达式是一个字符串，字符串以5或6个空格隔开，分为6或7个域，每一个域代表一个含义 ,cron表达式在这里不具体介绍，具体可参考下列几图

举一个例子

@Component
public class Task {
    private Logger logger = LoggerFactory.getLogger(getClass());
    
    @Scheduled(cron = "0 */1 * * * ?")
    public void testSchedule() {
        logger.info("定时任务启动");
        try {
            Thread.sleep(2000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        logger.info("定时任务执行完成");
    }
}

很简单将定时任务类使用@Component声明为Spring容器的一个组件Bean，使用@Schedule并且指定cron参数，并且在执行这个方法的时候让处理定时任务的这条线程睡2s，来模拟处理逻辑的时间，这个定时方法将会在每分钟整的时候被调用，看看效果

执行定时任务的日志

可以看到线程1从8:20:00被调用，线程睡眠2s模拟真实处理逻辑后,8:20:02执行完成

实现关单定时器 V 1.0

V1.0的逻辑实现很简单，写一个定时方法，直接去处理关单

@Scheduled(cron = "0 */1 * * * ?")
public void closeOrderTaskV1() {

    logger.info("关闭订单定时任务启动");
    //这里是你自己的关单逻辑
    logger.info("关闭订单定时任务结束");
}

我的关单逻辑是这样的，定时任务触发之后，关闭掉发起订单2个小时，却未付款的订单，关单逻辑可以是可配置的，使用Spring配置类的注解，读取.yml或.xml中关单的需要关闭订单的超时时间，之后的对数据库操作在这里也不提

大家可以想想这个V1.0版本会有什么问题，尤其是在集群环境下

多进程同时启动定时关单

集群环境下，Tomcat集群其实是多个进程，并且部署的项目逻辑代码完全一致，这个时候问题来了，大家也应该都想到了，多个进程都会在分钟的整数倍的时候执行这个定时任务，会有什么问题呢

损耗性能

这个逻辑其实交个其中一台应用服务器去做就好了，没有必要多进程同时委派一条线程去做同一件事，假如这个时候满足条件需要关闭的订单较多，I/O速度较慢，并且现在电商前端面临浏览高峰期，但是却有的线程被调度去做了浪费时间的事情，那这个定时任务设计的是失败的，设计定时任务的目的给我的感觉是，使用简单的注解去执行一些不需要程序员考虑和实现的定时任务，是为了让开发和逻辑变得简单，并且开发过程中根本不会希望会因为引入一个框架而浪费性能
重复还原库存

关单的逻辑是这样，关闭掉应该关闭的订单之后，需要还原库存，那么在这个时候如果多进程执行了关单，那将意味着，多个定时任务中都会存在还原库存这一操作，忽略数据有效性，如果多条进程同事执行这个任务，那将导致还原很多条无效的库存，明明只是还原10个库存，5条进程同时执行的时候，将会至少还原10个库存
数据的有效性

试想一下，多条进程同时执行这个并发任务的话，如果是定时任务执行关单逻辑，并发的结果是一样的，都是关闭掉符合条件的订单，看似这个并发情况不会出错，但是如果SQL语句设计的不好，或者没有使用一些对数据有效性的加锁策略，都会产生影响
脏读/写数据进行操作

上面分析了，如果只是关闭订单这一步操作，可能多条进程都会因为脏读造成对同一个订单进行关单，这虽然是一个并发导致的问题，但是不至于结果出错，该被关闭的订单迟早要被关闭，只是可能重复执行关闭它的操作

那么还原库存这一步操作呢，如果不进行必要的加锁策略，那将产生真正的并发问题

上面已经提到，多条进程同时执行关单的时候，需要进行还原库存这一操作，那么如果不加锁，可能会出现其中一条进程正在还原库存，库存已被还原，但是在此同时，一条请求来了，想要获取商品的库存信息，那会产生什么结果，假如此时商品库存为0，定时关单执行完成后将还原10件库存，但是请求的读线程读取数据库执行SQL操作，那么将出现脏读，逻辑上应该是这个时候用户在客户端能够看见的是10件库存

若是这个时候多进程同时执行还原库存的操作呢，可能多条进程读取到的都是未还原的库存，这样最好，还原之后结果是正确的，但是这样的假设必定造成错误，并发量大的情况下，肯定有一台应用服务器有点吃不消，进程的调度也不是那么迅速，那么这个时候很可能出现4个进程还原成功之后，剩余1条进程才开始执行并且这个时候，增加的库存数就是脏数据，那么如何去解决
订单关闭后还原商品库存

我的关单逻辑中包含一步操作，先去检查订单中的商品库存，若获取到的库存为null，则说明该商品已被删除无记录，若有数据再将订单中选购的商品数量还原到库存中
```
for (Order order : orderList) {
  List<OrderItem> orderItemList = orderItemMapper.getByOrderNo(order.getOrderNo());
  for (OrderItem orderItem : orderItemList) {
  //InnoDB
  Integer stock = productMapper.selectStockByProductId(orderItem.getProductId());
  //考虑到已生成订单里的商品，被删除的情况
  if (stock == null) {
      continue;
  }
  Product product = new Product();
  product.setId(orderItem.getProductId());
  //还原库存
  product.setStock(stock + orderItem.getQuantity());
  productMapper.updateByPrimaryKeySelective(product);
    }

    orderMapper.closeOrderByOrderId(order.getId());
    logger.info("关闭订单orderNo {}", order.getId());
}
```
遍历需要关闭的订单列表中的商品信息，查询库存，库存为空不进行还原操作，库存若不为空，则将订单中选购的数量还原至库存
- 行锁/表锁
```
    -- 悲观锁使用主键查找是行锁，若查找不是主键则是表锁
    SELECT
    stock
    FROM product
    WHERE id = #{id}
    FOR UPDATE
```
  这里也说明了，这条SQL语句采用悲观锁的策略，这样写的目的大家应该也能够体会的到，如果多条进程实现关单操作，并且还原库存，若不对数据进行加锁，可能展示的是无效数据，若select的字段为主键，则使用的是行锁的策略，如果不是主键，则对整张表进行加锁保证数据正确性，乐观锁悲观锁不是要研究的主题，继续向下看
多进程采用这样的策略能保证安全吗

如果说写一个增加访问量的场景，答案是不能的，仅仅对select语句进行for update启动事务进行行锁或者表锁这种形式的加锁方式，多进程情况下同样会造成脏读，我们的目的是获取库存并且在库存基础上进行还原操作，但是这两步是不具有原子性的，其实就和多线程情况下i++一样，同样会出现严重的并发问题，除非使用事务，将查询和更新两步操作实现原子性，实现方式不再赘述
定时任务交由单进程进行处理

这句话的意思，其实就是某一时刻集群中的应用服务器只有一台是在跑这个定时任务的，这样的话避免了多进程情况下的数据一致性问题，并且性能方面也不会浪费，如何实现这一点？