java课程设计日历记事本代码已开源

1、java课程设计历记事本代码，已开源1.为什么要使分布式锁使分布式锁的的，外乎就是保证同时间只有个客户端可以对共享资源进操作。举个很长的例系统 A 是个电商系统，前是台机器部署，系统中有个户下订单的接，但是户下订单之前定要去检查下库存，确保库存够了才会给户下单。由于系统有定的并发，所以会预先将商品的库存保存在 Redis 中，户下单的时候会更新 Redis 的库存。此时系统架构如下：但是这样来会产个问题：假如某个时刻，Redis 的某个商品库存为 1。此时两个请求同时到来，其中个请求执到上图的第 3 步，更新数据库的库存为 0，但是第 4 步还没有执。另外个请求执到了第 2 步，发现库存还是

2、1，就继续执第 3 步。这样的结果，是导致卖出了 2 个商品，然其实库存只有 1 个。很明显不对啊！这就是典型的库存超卖问题。此时，我们很容易想到解决案：锁把 2、3、4 步锁住，让他们执完之后，另个线程才能进来执第 2 步。按照上的图，在执第 2 步时，使 Java 提供的 Synchronized 或者 ReentrantLock 来锁住，然后在第 4 步执完之后才释放锁。这样来，2、3、4 这 3 个步骤就被“锁”住了，多个线程之间只能串化执。当整个系统的并发飙升，台机器扛不住了。现在要增加台机器，如下图：增加机器之后，系统变成上图所，假设此时两个户的请求同时到来，但是落在了不同的机器上

3、，那么这两个请求是可以同时执了，还是会出现库存超卖的问题。因为上图中的两个 A 系统，运在两个不同的 JVM ，他们加的锁只对属于 JVM 的线程有效，对于其他 JVM 的线程是效的。因此，这的问题是：Java 提供的原锁机制在多机部署场景下失效了，这是因为两台机器加的锁不是同个锁（两个锁在不同的 JVM）。那么，我们只要保证两台机器加的锁是同个锁，问题不就解决了吗？此时，就该分布式锁隆重登场了。分布式锁的思路是：在整个系统提供个全局、唯的获取锁的“东西”，然后每个系统在需要加锁时，都去问这个“东西”拿到把锁，这样不同的系统拿到的就可以认为是同把锁。于这个“东西”，可以是 Redis、Zook

4、eeper，也可以是数据库。此时的架构如图：通过上的分析，我们知道了库存超卖场景在分布式部署系统的情况下使 Java 原的锁机制法保证线程安全，所以我们需要到分布式锁的案。2.效的分布式锁在设计分布式锁的时候，应该考虑分布式锁少要满的些条件，同时考虑如何效的设计分布式锁，以下点是必须要考虑的：(1) 互斥在分布式并发的条件下，最需要保证在同时刻只能有个线程获得锁，这是最基本的点。(2) 防死锁在分布式并发的条件下，如有个线程获得锁的同时，还没有来得及去释放锁，就因为系统故障或者其它原因使它法执释放锁的命令,导致其它线程都法获得锁，造成死锁。所以分布式常有必要设置锁的有效时间，确保系统出现故障后

5、，在定时间内能够主动去释放锁，避免造成死锁的情况。(3) 性能对于访问量的共享资源，需要考虑减少锁等待的时间，避免导致量线程阻塞。所以在锁的设计时，需要考虑两点。1、 锁的颗粒度要尽量。如你要通过锁来减库存，那这个锁的名称你可以设置成是商品的ID,不是任取名称。这样这个锁只对当前商品有效,锁的颗粒度。2、 锁的范围尽量要。如只要锁2代码就可以解决问题的，那就不要去锁10代码了。(4) 重我们知道ReentrantLock是可重锁，那它的特点就是：同个线程可以重复拿到同个资源的锁。重锁常有利于资源的效利。关于这点之后会做演。3.基于Redis实现分布式锁3.1 使Redis命令实现分布式锁加锁加

6、锁实际上就是在redis中，给Key键设置个值，为避免死锁，并给定个过期时间。使的命令*：SET lock_key random_value NX PX 5000*值得注意的是：random_value 是客户端成的唯的字符串。NX 代表只在键不存在时，才对键进设置操作。PX 5000 设置键的过期时间为5000毫秒。也可以使另外条命令:SETNX key value只不过过期时间法设置。这样，如果上的命令执成功，则证明客户端获取到了锁。解锁解锁的过程就是将Key键删除，但要保证安全性，举个例：客户端1的请求不能将客户端2的锁给删除掉。释放锁涉及到两条指令，这两条指令不是原性的,需要到redi

7、s的lua脚本持特性，redis执lua脚本是原性的。脚本如下：这种式较简单，但是也有个最重要的问题：锁不具有可重性。使Redisson实现分布式锁3.2.1Redisson介绍Redisson是架设在Redis基础上的个Java驻内存数据格（In-Memory Data Grid）。充分的利了Redis键值数据库提供的系列优势，基于Java实具包中常接，为使者提供了系列具有分布式特性的常具类。使得原本作为协调单机多线程并发程序的具包获得了协调分布式多机多线程并发系统的能，降低了设计和研发规模分布式系统的难度。同时结合各富特的分布式服务，更进步简化了分布式环境中程序相互之间的协作。3.2.2R

8、edisson简单使Config config = new Config();config.useClusterServers()lock.unlock();只需要通过它的 API中的 Lock 和 Unlock 即可完成分布式锁，且考虑了很多细节：l Redisson 所有指令都通过 Lua 脚本执，Redis 持 Lua 脚本原性执。l Redisson 设置个 Key 的默认过期时间为 30s，但是如果获取锁之后，会有个WatchDog每隔10s将key的超时时间设置为30s。另外，Redisson 还提供了对 Redlock 算法的持，它的法也很简单：multiLock.unlock(

9、);3.2.3Redisson原理分析(1) 线程去获取锁，获取成功:执lua脚本，保存数据到redis数据库。线程去获取锁，获取失败:直通过while循环尝试获取锁，获取成功后，执lua脚本，保存数据到redis数据库。(2) 在个分布式环境下，假如个线程获得锁后，突然服务器宕机了，那么这个时候在定时间后这个锁会动释放，也可以设置锁的有效时间(不设置默认30秒），这样的的主要是防死锁的发。但是在实际情况中会有种情况，业务处理的时间可能会于锁过期的时间，这样就可能*导致解锁和加锁不是同个线程。*所以WatchDog作就是Redisson实例关闭前，不断延长锁的有效期。如果程序调加锁法显式地给了

10、有效期，是不会开启后台线程(也就是watch dog)进延期的，如果没有给有效期或者给的是-1，redisson会默认设置30s有效期并且会开启后台线程(watch dog)进延期多久进次延期：（默认有效期/3），默认有效期可以设置修改的，即默认情况下每隔10s设置有效期为30s(3) Redisson可以实现可重加锁机制的原因：l Redis存储锁的数据类型是Hash类型l Hash数据类型的key值包含了当前线程的信息下是redis存储的数据这表数据类型是Hash类型,Hash类型相当于我们java的 key, 类型,这key是指 redisson它的有效期还有9秒，我们再来看们的key1

11、值为078e44a3-5f95-4e24-b6aa-80684655a15a:45它的组成是:guid + 当前线程的ID。后的value是就和可重加锁有关。value代表同客户端调lock法的次数，即可重计数统计。举图说明上这图的意思就是可重锁的机制，它最的优点就是相同线程不需要在等待锁，是可以直接进相应操作。3.2.4获取锁的流程其中的指定字段也就是hash结构中的field值（构成是uuid+线程id），即判断锁是否是当前线程3.2.5加锁的流程4. 使Redis做分布式锁的缺点Redis有三种部署式l 单机模式l Master-Slave+Sentienl选举模式l Redis Clu

12、ster模式如果采单机部署模式，会存在单点问题，只要 Redis 故障了。加锁就不了采 Master-Slave 模式，加锁的时候只对个节点加锁，即便通过 Sentinel 做了可，但是如果 Master 节点故障了，发主从切换，此时就会有可能出现锁丢失的问题。基于以上的考虑，Redis 的作者也考虑到这个问题，他提出了个 RedLock 的算法。这个算法的意思概是这样的：假设 Redis 的部署模式是 Redis Cluster，总共有 5 个 Master 节点。通过以下步骤获取把锁：获取当前时间戳，单位是毫秒。轮流尝试在每个 Master 节点上创建锁，过期时间设置较短，般就毫秒。尝试在

13、多数节点上建个锁，如 5 个节点就要求是 3 个节点（n / 2 +1）。客户端计算建好锁的时间，如果建锁的时间于超时时间，就算建成功了。要是锁建失败了，那么就依次删除这个锁。只要别建了把分布式锁，你就得不断轮询去尝试获取锁。但是这样的这种算法，可能会出现节点崩溃重启，多个客户端持有锁等其他问题，法保证加锁的过程定正确。例如：假设共有5个Redis节点：A,B,C,D,E。设想发了如下的事件序列：(1)客户端1成功锁住了A,B,C，获取锁成功（但D和E没有锁住）。(2)节点C崩溃重启了，但客户端1在C上加的锁没有持久化下来，丢失了。(3)节点C重启后，客户端2锁住了C,D,E，获取锁成功。这样，客户端1和客户端2同时获得了锁（针对同资源）。最后由于细节内容实在太多了，为了不影响章的观赏性，只截出了部分知识点致的介绍下，每个节点都有更细化的内容！需要这份档的朋友可以帮忙点个赞