本篇文章主要介绍了"基于Redis实现分布式锁-Redisson使用及源码分析"，主要涉及到redis方面的内容，对于其他编程jrs看球网直播吧_低调看直播体育app软件下载_低调看体育直播感兴趣的同学可以参考一下：
【转】在分布式场景下，有很多种情况都需要实现最终一致性。在设计远程上下文的领域事件的时候，为了保证最终一致性，在通过领域事件进行通讯的方式中，可 以共享存储（领...
【转】
在分布式场景下，有很多种情况都需要实现最终一致性。在设计远程上下文的领域事件的时候，为了保证最终一致性，在通过领域事件进行通讯的方式中，可 以共享存储（领域模型和消息的持久化数据源），或者做全局XA事务（两阶段提交，数据源可分开），也可以借助消息中间件（消费者处理需要能幂等）。通过 Observer模式来发布领域事件可以提供很好的高并发性能，并且事件存储也能追溯更小粒度的事件数据，使各个应用系统拥有更好的自治性。
本文 主要探讨另外一种实现分布式最终一致性的解决方案——采用分布式锁。基于分布式锁的解决方案，比如zookeeper,redis都是相较于持久化（如利 用InnoDB行锁，或事务，或version乐观锁）方案提供了高可用性，并且支持丰富化的使用场景。 本文通过Java版本的redis分布式锁开源框架——Redisson来解析一下实现分布式锁的思路。
分布式锁的使用场景
如果是不跨限界上下文的情况，跟本地领域服务相关的数据一致性，尽量还是用事务来保证。但也有些无法用事务或者乐观锁来处理的情况，这些情况大多是对于一个共享型的数据源，有并发写操作的场景，但又不是对于单一领域的操作。
举 个例子，还是用租书来比喻,A和B两个人都来租书，在查看图书的时候，发现自己想要看的书《大设计》库存仅剩一本。书店系统中，书作为一种商品，是在商品 系统中，以Item表示出租商品的领域模型，同时每一笔交易都会产生一个订单，Order是在订单系统（交易限界上下文）中的领域模型。这里假设先不考虑 跨系统通信的问题（感兴趣的可以参考下领域服务、领域事件）， 也暂时不考虑支付环节，但是我们需要保证A,B两个人不会都对于《大设计》产生订单就可以，也就是其中一个人是可以成功下单，另外一个人只要提示库存已没 即可。此时，书的库存就是一种共享的分布式资源，下订单，减库存就是一个需要保证一致性的写操作。但又因为两个操作不能在同一个本地事务，或者说，不共享 持久化的数据源的情况，这时候就可以考虑用分布式锁来实现。本例子中，就需要对于共享资源——书的库存进行加锁，至于锁的key可以结合领域模型的唯一标 识，如itemId,以及操作类型（如操作类型是RENT的）设计一个待加锁的资源标识。当然，这里还有一个并发性能的问题，如果是个库存很多的秒杀类型 的业务，那么就不能单纯在itemId 加类型加锁，还需要设计排队队列以及合理的调度算法，防止超卖等等，那些就是题外话了。本文只是将这个场景作为一个切入点，具体怎么设计锁，什么场景用还 要结合业务。
需要解决的问题
分布式的思路和线程同步锁ReentrantLock的思路是一样的。我们也要考虑如以下几个问题：
- 死锁的情况。复杂的网络环境下，当加锁成功，后续操作正在处理时，获得锁的节点忽然宕机，无法释放锁的情况。如A在Node1 节点申请到了锁资源，但是Node1宕机，锁一直无法释放，订单没有生成，但是其他用户将无法申请到锁资源。
- 锁的性能效率。分布式锁不能成为性能瓶颈或者单点故障不能导致业务异常。
- 如果关键业务，可能需要重入场景，是否设计成可重入锁。这个可以参考下在多线程的情况下，比如ReentrantLock就是一种可重入锁，其内部又提供了公平锁和非公平锁两种实现和应用，本文不继续探讨。带着以上问题，和场景，沿着下文，来一一找到解决方案。
基于Redis实现
Redis 命令
在Redisson介绍前，回顾下Redis的命令，以及不通过任何开源框架，可以基于redis怎么设计一个分布式锁。基于不同应用系统实现的语言，也可以通过其他一些如Jedis,或者Spring的RedisOperations 等，来执行Reids命令Redis command list。
分布式锁主要需要以下redis命令，这里列举一下。在实现部分可以继续参照命令的操作含义。
