一：前言

我在实际环境中遇到了这样一种问题，分布式生成id的问题！因为业务逻辑的问题，我有个生成id的方法，是根据业务标识+id当做唯一的值！

而uuid是递增生成的，从1开始一直递增，那么在同一台机器上运行代码，加上同步方法（synchronized），这个生成id的方法就是ok！

但是因为业务扩展或者说为了安全，项目运行在两台机器上，此时单个的同步方法（synchronized）就不能防止id的重复了！！！

要解决上面的这个问题，其他有如下解决办法！

（1）：每台机器生产Id的代码，key+id 可以在前加上机器编号区分，key + id --- >机器唯一编号 + key + id

（2）：使用数据库行锁（单个数据库的是时候），在需要插入id的表加上行锁，防止数据重复导致程序异常！

（3）：使用分布式锁

二：分布式锁简介

网上有很多的讲解分布式锁的文章，但是细细分析很多的代码还是有很多的问题的，如下代码片段摘自博文：

和

public void lock(long timeout) {        long nano = System.nanoTime();        timeout *= 1000000;        final Random r = new Random();        try {            while ((System.nanoTime() - nano) < timeout) {                if (redisTemplate.getConnectionFactory().getConnection().setNX(key.getBytes(), LOCKED.getBytes())) {                    redisTemplate.expire(key, EXPIRE, TimeUnit.SECONDS);                    locked = true;                    logger.debug("add RedisLock[" + key + "].");                    break;                }                Thread.sleep(3, r.nextInt(500));            }        } catch (Exception e) {        }    }

博主也说了：如果长时间获取不到，就会获取锁失败，相当于没加锁！

这里还有可能发生其他问题：

（1）并发情况，expire主动释放锁的时候，可能释放的是别人的锁（不懂请查询资料）

（2）Redis服务挂掉，锁失败，相当于没加锁！

注：使用的时候要注意上面问题！！！

还有一种摘自博文：

这个博问分析的：

while (timeout >= 0) {            long expires = System.currentTimeMillis() + expireMsecs + 1;            String expiresStr = String.valueOf(expires); //锁到期时间            if (this.setNX(lockKey, expiresStr)) {                // lock acquired                locked = true;                return true;            }            String currentValueStr = this.get(lockKey); //redis里的时间            if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {                //判断是否为空，不为空的情况下，如果被其他线程设置了值，则第二个条件判断是过不去的                // lock is expired                String oldValueStr = this.getSet(lockKey, expiresStr);                //获取上一个锁到期时间，并设置现在的锁到期时间，                //只有一个线程才能获取上一个线上的设置时间，因为jedis.getSet是同步的                if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {                    //防止误删（覆盖，因为key是相同的）了他人的锁——这里达不到效果，这里值会被覆盖，但是因为什么相差了很少的时间，所以可以接受                    //[分布式的情况下]:如过这个时候，多个线程恰好都到了这里，但是只有一个线程的设置值和当前值相同，他才有权利获取锁                    // lock acquired                    locked = true;                    return true;                }            }            timeout -= DEFAULT_ACQUIRY_RESOLUTION_MILLIS;            /*                延迟100 毫秒,  这里使用随机时间可能会好一点,可以防止饥饿进程的出现,即,当同时到达多个进程,                只会有一个进程获得锁,其他的都用同样的频率进行尝试,后面有来了一些进行,也以同样的频率申请锁,这将可能导致前面来的锁得不到满足.                使用随机的等待时间可以一定程度上保证公平性             */            Thread.sleep(DEFAULT_ACQUIRY_RESOLUTION_MILLIS);        }

这个相比第一个完善了误删除key的问题，但是要合理的设置超时时间，否则的话，也会使锁失效。

三：Redisson分布式锁的介绍和简单的使用

Redisson的介绍可以到： 这里去了解！

我这里说一下使用时候要注意的问题：

1：文档里面说明了支持Redis 2.8以上版本，支持Java1.6+以上版本。根据自己的环境选择合适的版本！

2：2.8.1的redisson 需要使用 netty的jar包， 否则报错：

Hopper: java.lang.NoClassDefFoundError: io/netty/channel/EventLoopGroup。

3：2.8.1的redisson需要jackson 2.5+版本，否则报错bjectMapper.addMixIn method not fond。

我写了一个简单的例子，自己也做了一下测试，使用的Redis主从+哨兵模式！

demo的目录结构，具体的源码我放到github上面,地址：

注：这里一定要先安装Redis服务，如果没有安装Redis服务，请参考这篇：

如果Redis服务安装到服务器上面，请修改代码中的Redis地址和端口！否则运行不起了!

运行这个类UUidGeneratorLockTest就可以看到效果！测试结果我也在readme.txt进行了总结！

如果在测试和学习的过程中有疑问，可以随时和我联系，也可以加左侧的群互相探讨！谢谢！

四：总结

这个时代，信息爆炸，各种技术博文之间互相复制，真正好的文章还是需要鉴别的！

我也要反思，自己之前也写过一些博文，也是遇到问题了，去网上搜一些解决方案，很多方案确实是理论上可以解决当前遇到的问题，当时去深究，就会发现很多的不完整性！

多思考，多测试！让代码能够更加高效和安全！

---

欢迎访问我的csdn博客，我们一同成长！

"不管做什么，只要坚持下去就会看到不一样！在路上，不卑不亢!"

博客首页：