缓存使用、锁以及分布式锁Redisson
在高并发请求时，我们会频繁提到使用缓存技术，最直接的原因是，磁盘IO及网络开销是直接请求内存IO的千百上千倍。
做个简单计算，如果我们需要某个数据，该数据从数据库磁盘读出来需要0.0045S，经过网络请求传输需要 0.0005S，那么每个请求完成最少需要0.005S，该数据服务器每秒最多只能响应200个请求，而如果该数据存于本机内 存里，读出来只需要100us，那么每秒能够响应10000个请求。通过将数据存储到离CPU更近的未位置，减少数据传输时 间，提高处理效率，这就是缓存的意义。
什么场景下适合使用缓存
读密集型的应用
存在热数据的应用
对响应时效要求高的应用
对一致性要求不严格的场景
需要实现分布式锁的时候
什么场景下不适合使用缓存
对一致性要求严格的场景
更新频繁，更新数据频率过高的场景，频繁同步缓存中的数据所花费的代价可能比不使用缓存的代价还要高
读少的场景，对于读少的系统而言，使用缓存就完全没有意义了，比较使用缓存是为了读取数据更高效
缓存穿透
描述：
缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。
解决方案：
接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击
缓存击穿
描述：
缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力
解决方案：
设置热点数据永远不过期。
加互斥锁
说明：
1、缓存中有数据，直接走上述代码13行后就返回结果了
2、缓存中没有数据，第1个进入的线程，获取锁并从数据库去取数据，没释放锁之前，其他并行进入的线程会等待100ms，再重新去缓存取数据。这样就防止都去数据库重复取数据，重复往缓存中更新数据情况出现。
3、当然这是简化处理，理论上如果能根据key值加锁就更好了，就是线程A从数据库取key1的数据并不妨碍线程B取key2的数据，上面代码明显做不到这点。
缓存雪崩
描述：
缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。
解决方案：
缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。
设置热点数据永远不过期。
缓存查询过慢的几个原因
使用大key
如果一个key写入的数据非常大，Redis在分配内存时也会比较耗时。同样的，当删除这个key的数据时，释放内存也会耗时比较久。一定避免存储过大的bigkey，bigkey在分配内存和释放内存时耗时严重，会阻塞主线程。
集中过期
就如上面提到的缓存雪崩。
在某个时间点突然出现一波延时，而且报慢的时间点很有规律，例如某个整点，或者间隔多久就会发生一次。
实例内存达到上限
当Redis内存达到maxmemory后，每次写入新的数据之前，必须先踢出一部分数据，让内存维持在maxmemory之下。
fork耗时严重
如果你的Redis开启了自动生成RDB和AOF重写功能，那么有可能在后台生成RDB和AOF重写时导致Redis的访问延迟增大，而等这些任务执行完毕后，延迟情况消失。
遇到这种情况，一般就是执行生成RDB和AOF重写任务导致的。
网卡负载过高
在某个时间点之后开始，访问Redis开始变慢了，而且一直持续到现在，这种情况是什么原因导致的？
之前我们就遇到这种问题，特点就是从某个时间点之后就开始变慢，并且一直持续。这时你需要检查一下机器的网卡流量，是否存在网卡流量被跑满的情况。
网卡负载过高，在网络层和TCP层就会出现数据发送延迟、数据丢包等情况。Redis高性能除了内存之外，就在于网络IO，请求量突增会导致网卡负载变高。
通俗的说就是多个线程，也可以说多个方法同时对一个资源进行访问时，如果不加锁会造成线程安全问题。举例：比如有两张票，但是有5个人进来买，买了一张票数就减1，在他们进门的时候会判断是否还有票，但是在他们进门的那一刻，票还一张都没有买走。但是他们都已经进门了，过了是否有票的校验了，所以最后票数为被减成负3，显然是不对的，因为票不能小于0，所以需要加一个锁，在同一时刻只能有一个人进门去买票，也就是同一个资源同一个时刻只能有一个线程进行操作，这样在第三个人进门的时候就能判断出票数已经卖完了，不会产生票数成负数的情况。
乐观锁/悲观锁
独享锁/共享锁
互斥锁/读写锁
可重入锁
公平锁/非公平锁
分段锁
偏向锁/轻量级锁/重量级锁
自旋锁
1、乐观锁/悲观锁
乐观锁与悲观锁并不是特指某两种类型的锁，是人们定义出来的概念或思想，主要是指看待并发同步的角度。
乐观锁：顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS(Compare and Swap 比较并交换)实现的。
悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。比如Java里面的同步原语synchronized关键字的实现就是悲观锁。
悲观锁适合写操作非常多的场景，乐观锁适合读操作非常多的场景，不加锁会带来大量的性能提升。
悲观锁在Java中的使用，就是利用各种锁。
乐观锁在Java中的使用，是无锁编程，常常采用的是CAS算法，典型的例子就是原子类，通过CAS自旋实现原子操作的更新。
1.1 乐观锁
乐观锁总是认为不存在并发问题，每次去取数据的时候，总认为不会有其他线程对数据进行修改，因此不会上锁。但是在更新时会判断其他线程在这之前有没有对数据进行修改，一般会使用“数据版本机制”或“CAS操作”来实现。
（1） 数据版本机制
实现数据版本一般有两种，第一种是使用版本号，第二种是使用时间戳。以版本号方式为例。
版本号方式：一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。
核心SQL代码：
1 update table set xxx=#{xxx}, version=version+1 where id=#{id} and version=#{version};
（2） CAS操作
CAS（Compare and Swap 比较并交换），当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。
CAS操作中包含三个操作数——需要读写的内存位置(V)、进行比较的预期原值(A)和拟写入的新值(B)。如果内存位置V的值与预期原值A相匹配，那么处理器会自动将该位置值更新为新值B，否则处理器不做任何操作。
1.2 悲观锁
悲观锁认为对于同一个数据的并发操作，一定会发生修改的，哪怕没有修改，也会认为修改。因此对于同一份数据的并发操作，悲观锁采取加锁的形式。悲观的认为，不加锁并发操作一定会出问题。
在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。
如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。具体响应方式由开发者根据实际需要决定。
如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
期间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常。
1.3代码示例
// ------------------------- 悲观锁的调用方式 -------------------------// synchronizedpublicsynchronizedvoidtestMethod(){// 操作同步资源}// ReentrantLockprivateReentrantLock lock =newReentrantLock();// 需要保证多个线程使用的是同一个锁publicvoidmodifyPublicResources(){lock.lock();// 操作同步资源lock.unlock();}// ------------------------- 乐观锁的调用方式 -------------------------privateAtomicInteger atomicInteger =newAtomicInteger();// 需要保证多个线程使用的是同一个AtomicIntegeratomicInteger.incrementAndGet();//执行自增1
2 独享锁/共享锁
独享锁是指该锁一次只能被一个线程所持有。
共享锁是指该锁可被多个线程所持有。
对于Java ReentrantLock而言，其是独享锁。但是对于Lock的另一个实现类ReadWriteLock，其读锁是共享锁，其写锁是独享锁。
读锁的共享锁可保证并发读是非常高效的，读写，写读，写写的过程是互斥的。
独享锁与共享锁也是通过AQS来实现的，通过实现不同的方法，来实现独享或者共享。
对于Synchronized而言，当然是独享锁。
3 互斥锁/读写锁
上面讲的独享锁/共享锁就是一种广义的说法，互斥锁/读写锁就是具体的实现。
互斥锁在Java中的具体实现就是ReentrantLock。
读写锁在Java中的具体实现就是ReadWriteLock。
4 可重入锁
可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，在进入内层方法会自动获取锁。说的有点抽象，下面会有一个代码的示例。
对于Java ReetrantLock而言，从名字就可以看出是一个重入锁，其名字是Re entrant Lock 重新进入锁。
对于Synchronized而言，也是一个可重入锁。可重入锁的一个好处是可一定程度避免死锁。
5 公平锁/非公平锁
公平锁是指多个线程按照申请锁的顺序来获取锁。
非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。有可能，会造成优先级反转或者饥饿现象。
对于Java ReetrantLock而言，通过构造函数指定该锁是否是公平锁，默认是非公平锁。非公平锁的优点在于吞吐量比公平锁大。
对于Synchronized而言，也是一种非公平锁。由于其并不像ReentrantLock是通过AQS的来实现线程调度，所以并没有任何办法使其变成公平锁。
6 分段锁
分段锁其实是一种锁的设计，并不是具体的一种锁，对于ConcurrentHashMap而言，其并发的实现就是通过分段锁的形式来实现高效的并发操作。
我们以ConcurrentHashMap来说一下分段锁的含义以及设计思想，ConcurrentHashMap中的分段锁称为Segment，它即类似于HashMap（JDK7和JDK8中HashMap的实现）的结构，即内部拥有一个Entry数组，数组中的每个元素又是一个链表；同时又是一个ReentrantLock（Segment继承了ReentrantLock）。
当需要put元素的时候，并不是对整个hashmap进行加锁，而是先通过hashcode来知道他要放在哪一个分段中，然后对这个分段进行加锁，所以当多线程put的时候，只要不是放在一个分段中，就实现了真正的并行的插入。
但是，在统计size的时候，可就是获取hashmap全局信息的时候，就需要获取所有的分段锁才能统计。
分段锁的设计目的是细化锁的粒度，当操作不需要更新整个数组的时候，就仅仅针对数组中的一项进行加锁操作。
7 偏向锁/轻量级锁/重量级锁
这三种锁是指锁的状态，并且是针对Synchronized。在Java 5通过引入锁升级的机制来实现高效Synchronized。这三种锁的状态是通过对象监视器在对象头中的字段来表明的。
偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁。降低获取锁的代价。
轻量级锁是指当锁是偏向锁的时候，被另一个线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，提高性能。
重量级锁是指当锁为轻量级锁的时候，另一个线程虽然是自旋，但自旋不会一直持续下去，当自旋一定次数的时候，还没有获取到锁，就会进入阻塞，该锁膨胀为重量级锁。重量级锁会让他申请的线程进入阻塞，性能降低。
8 自旋锁
在Java中，自旋锁是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁，这样的好处是减少线程上下文切换的消耗，缺点是循环会消耗CPU。
$redis =new\Redis(); $redis->connect('127.0.0.1'); $lockKey ='lock_key'; $randValue = rand(10000,99999);//lock$lock = $redis->set($lockKey, $randValue, ['NX','EX'=>1]);if($lock) {//do something//unlock$script ='
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
'; $redis->eval($script, [$lockKey, $randValue],1); }
与分布式锁相对应的是「单机锁」，我们在写多线程程序时，避免同时操作一个共享变量产生数据问题，通常会使用一把锁来「互斥」，以保证共享变量的正确性，其使用范围是在「同一个进程」中。
如果换做是多个进程，需要同时操作一个共享资源，如何互斥呢？
例如，现在的业务应用通常都是微服务架构，这也意味着一个应用会部署多个进程，那这多个进程如果需要修改 MySQL 中的同一行记录时，为了避免操作乱序导致数据错误，此时，我们就需要引入「分布式锁」来解决这个问题了。
想要实现分布式锁，必须借助一个外部系统，所有进程都去这个系统上申请「加锁」。
而这个外部系统，必须要实现「互斥」的能力，即两个请求同时进来，只会给一个进程返回成功，另一个返回失败（或等待）。
这个外部系统，可以是 MySQL，也可以是 Redis 或 Zookeeper。但为了追求更好的性能，我们通常会选择使用 Redis 或 Zookeeper 来做。
Jedis是Redis的Java实现的客户端，其API提供了比较全面的Redis命令的支持。Jedis中的方法调用是比较底层的暴露的Redis的API，也即Jedis中的Java方法基本和Redis的API保持着一致，了解Redis的API，也就能熟练的使用Jedis。
而Redisson中的方法则是进行比较高的抽象，每个方法调用可能进行了一个或多个Redis方法调用。Redisson的宗旨是促进使用者对Redis的关注分离，从而让使用者能够将精力更集中地放在处理业务逻辑上。
Jedis仅支持基本的数据类型如：String、Hash、List、Set、Sorted Set。
Redisson实现了分布式和可扩展的java数据结构，支持的数据结构有：List, Set, Map, Queue, SortedSet, ConcureentMap, Lock, AtomicLong, CountDownLatch。并且是线程安全的，底层使用Netty4实现网络通信。和jedis相比，功能比较简单，不支持排序，事务，管道，分区等redis特性，可以认为是jedis的补充，不能替换jedis。
Jedis使用阻塞的I/O，且其方法调用都是同步的，程序流需要等到sockets处理完I/O才能执行，不支持异步。Jedis客户端实例不是线程安全的，所以需要通过连接池来使用Jedis。
Redisson使用非阻塞的I/O和基于Netty框架的事件驱动的通信层，其方法调用是异步的。Redisson的API是线程安全的，所以可以操作单个Redisson连接来完成各种操作。
Lettuce：基于Netty框架的事件驱动的通信层，其方法调用是异步的。Lettuce的API是线程安全的，所以可以操作单个Lettuce连接来完成各种操作
redistemplate是springboot2.X后面，由lettuce具体实现，1.x的是jedis，redisson是redis的分布式客户端
1 Redisson提供了和Spring框架的各项特性类似的，以Spring XML的命名空间的方式配置RedissonClient实例和它所支持的所有对象和服务；
2 Redisson完整的实现了Spring框架里的缓存机制；
3 Redisson在Redis的基础上实现了Java缓存标准规范；
4 Redisson为Apache Tomcat集群提供了基于Redis的非黏性会话管理功能。该功能支持Apache Tomcat的6、7和8版。
5 Redisson还提供了Spring Session会话管理器的实现。
Redisson的分布式可重入锁RLock Java对象实现了java.util.concurrent.locks.Lock接口，同时还支持自动过期解锁。
publicstaticvoidmain(String[] args){ Config config =newConfig(); config.useSingleServer().setAddress("redis://127.0.0.1:6379"); config.useSingleServer().setPassword("redis1234");finalRedissonClient client = Redisson.create(config); RLock lock = client.getLock("anyLock");try{// 1. 最常见的使用方法//lock.lock();// 2. 支持过期解锁功能,10秒钟以后自动解锁, 无需调用unlock方法手动解锁//lock.lock(10, TimeUnit.SECONDS);// 3. 尝试加锁，最多等待3秒，上锁以后10秒自动解锁booleanres = lock.tryLock(3,10, TimeUnit.SECONDS);if(res){//成功// do your business} }catch(InterruptedException e) { e.printStackTrace(); }finally{ lock.unlock(); }}
Redisson分布式可重入公平锁也是实现了java.util.concurrent.locks.Lock接口的一种RLock对象。在提供了自动过期解锁功能的同时，保证了当多个Redisson客户端线程同时请求加锁时，优先分配给先发出请求的线程。
publicvoidtestFairLock(RedissonClient redisson){ RLock fairLock = redisson.getFairLock("anyLock");try{// 最常见的使用方法fairLock.lock();// 支持过期解锁功能, 10秒钟以后自动解锁,无需调用unlock方法手动解锁fairLock.lock(10, TimeUnit.SECONDS);// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁booleanres = fairLock.tryLock(100,10, TimeUnit.SECONDS); }catch(InterruptedException e) { e.printStackTrace(); }finally{ fairLock.unlock(); } }
Redisson的RedissonMultiLock对象可以将多个RLock对象关联为一个联锁，每个RLock对象实例可以来自于不同的Redisson实例。
publicvoidtestMultiLock(RedissonClient redisson1,
RedissonClient redisson2, RedissonClient redisson3){ RLock lock1 = redisson1.getLock("lock1"); RLock lock2 = redisson2.getLock("lock2"); RLock lock3 = redisson3.getLock("lock3"); RedissonMultiLock lock =newRedissonMultiLock(lock1, lock2, lock3);try{// 同时加锁：lock1 lock2 lock3, 所有的锁都上锁成功才算成功。lock.lock();// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁booleanres = lock.tryLock(100,10, TimeUnit.SECONDS); }catch(InterruptedException e) { e.printStackTrace(); }finally{ lock.unlock(); } }
Redisson的RedissonRedLock对象实现了Redlock介绍的加锁算法。该对象也可以用来将多个RLock
对象关联为一个红锁，每个RLock对象实例可以来自于不同的Redisson实例。
publicvoidtestRedLock(RedissonClient redisson1,
RedissonClient redisson2, RedissonClient redisson3){ RLock lock1 = redisson1.getLock("lock1"); RLock lock2 = redisson2.getLock("lock2"); RLock lock3 = redisson3.getLock("lock3"); RedissonRedLock lock =newRedissonRedLock(lock1, lock2, lock3);try{// 同时加锁：lock1 lock2 lock3, 红锁在大部分节点上加锁成功就算成功。lock.lock();// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁booleanres = lock.tryLock(100,10, TimeUnit.SECONDS); }catch(InterruptedException e) { e.printStackTrace(); }finally{ lock.unlock(); } }
Redisson的分布式可重入读写锁RReadWriteLock Java对象实现了java.util.concurrent.locks.ReadWriteLock接口。同时还支持自动过期解锁。该对象允许同时有多个读取锁，但是最多只能有一个写入锁。
publicvoidtestFairLock(RedissonClient redisson){ RReadWriteLock rwlock = redisson.getLock("anyRWLock");// 最常见的使用方法rwlock.readLock().lock();// 或rwlock.writeLock().lock();// 支持过期解锁功能// 10秒钟以后自动解锁// 无需调用unlock方法手动解锁rwlock.readLock().lock(10, TimeUnit.SECONDS);// 或rwlock.writeLock().lock(10, TimeUnit.SECONDS);// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁booleanres = rwlock.readLock().tryLock(100,10, TimeUnit.SECONDS);// 或booleanres = rwlock.writeLock().tryLock(100,10, TimeUnit.SECONDS); lock.unlock(); }
