案例源码：飞机直达

Spring Integration提供的全局锁，目前为这几种存储提供了实现：Gemfire、JDBC、Redis、Zookeeper

它们使用相同的API抽象–这正是Spring最擅长的。这意味着，不论使用哪种存储，你的编码体验都是一样的，有一天想更换实现，只需要修改依赖和配置就可以了，无需修改代码，就像jdbc规范那样，换个驱动（不同厂商的实现方式）就行啦。。。

下面以Redis为例，讲解Spring Integration如何使用分布式锁。

增加依赖：

   <dependency>
            <!-- spring integration -->
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-integration</artifactId>
        </dependency>
        <dependency>
            <!-- spring integration与redis结合，实现redis分布式锁 -->
            <groupId>org.springframework.integration</groupId>
            <artifactId>spring-integration-redis</artifactId>
        </dependency>
        <dependency>
            <!-- redis -->
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>

配置文件增加redis配置：

spring:
  redis:
    port: 6379
    host: redis地址ip

增加RedisLock的配置类：

测试并发请求，先下载个JMeter 回来。。。
http://jmeter.apache.org/download_jmeter.cgi

解压后：

右键test plan 新建一个线程组：


新建请求：

设置好路径之后点绿色按钮测试：

测试没锁的情况：

发现多个线程并发获取了临界资源，那句输出语句可以理解为你业务的处理过程。。。

测试分布式锁：

先用postman测试接口，然后断点看redis情况：

redis上面多了一个key的组（文件夹），组的名称在声明配置的时候设置的，和对应分布式锁的key，对应这行代码：Lock lock = redisLockRegistry.obtain("lock");
还有一个key的过期时间，就是你获取了锁资源，但是你业务里面异常了，线程就会停止执行，但是redis上面的记录还在，如果没有过期时间，后面的线程就无法获取这个分布式锁了。。。。过期时间在配置那里设置、、

@Configuration
public class RedisLockConfiguration {

    private static final String integrationGroupKey = "redis_integration";//分布式锁的组名称（文件夹）
    private static final long expireAfter = 10L*1000L;//分布式锁持有时间（避免获取后处理业务异常，锁不释放）

    @Bean
    public RedisLockRegistry redisLockRegistry(RedisConnectionFactory redisConnectionFactory) {
        return new RedisLockRegistry(redisConnectionFactory, integrationGroupKey,expireAfter);
    }

}

现在用压测工具测试：配置和前面的一样，25线程并发

运行结果看得出：虽然有些抢不到资源的，但是起码资源是不会出现错乱，那些拿不到还以再次并发测试去拿。保证了数据的一致性，原子性操作。

完美 ！散花，又学会一个复制粘贴的小工具，或许人人都是架构师，分布式锁还不是调API完事？