Redis_实战

部署：

前端：部署在Nginx
后端：部署在tomcat

短信登录

session原理：
每一个session都有一个id，当你访问tomcat服务器时，id就自动写到coockie中了，以后请求就带着id，就可以根据id找到session。（每一个浏览器再发请求时都有一个独立的session）

session在服务器端，coockie在客户端。

token：

登录验证时，短信验证码存在session中。用户也保存在session中（登录凭证）。

登录后，用户信息保存在Threadlocal中，便于其他业务需要调用用户信息。

问题：
集群的session共享问题：多台tomcat不共享session存储空间，当请求切换到不同tomcat服务时导致数据丢失的问题。
替换方案需要满足以下条件：

数据共享
内存存储
key-value结构
所以，可以用redis。

用redis代替session

验证码保存在redis，key变成手机号（加一个业务前缀login:code:）同时设置有效期。（保证了唯一key，保证了用户登录时可以根据手机号取到验证码）
登录时用户保存在redis，key变成token（随机生成）（返回token给客户端，验证登录），value变成hash类型，记录用户不同字段的信息。

redis代替session'需要考虑的问题：

选择合适的数据结构。
选择合适的key。
选择合适的存储粒度。

拦截器改进

新增一个拦截器，将token有效期刷新的功能放在拦截器1，和登录用户相关的功能放在拦截器2，它们之间是串行的。
拦截器1：（拦截一切请求）

获取token
查询redis的用户
保存到ThreadLocal
刷新token有效期
放行

拦截器2：（拦截需要登陆的请求）

查询ThreadLocal的用户
1.1 不存在，则拦截
1.2 存在，则继续

商户查询缓存

什么是缓存：
就是数据交换的缓冲区，是存储数据的临时地方，一般读写性能较高。

缓存的作用：

降低后端负载
提高读写效率，降低响应时间。

缓存的成本：

数据一致性成本。
代码维护的成本。
运维成本

该项目中使用redis作为缓存，减轻数据库压力。

redis缓存更新策略

内存淘汰：不用自己维护，利用redis的内存淘汰机制，当内存不足时自动淘汰部分数据，下次查询时更新缓存。（一致性-差，维护成本-无）
超时剔除：给缓存数据添加TTL时间，到期后自动删除缓存，下次查询时更新缓存。（一致性-一般，维护成本-低）
主动更新：编写业务逻辑，在修改数据库数据库的同时，更新缓存。（一致性-好，维护成本-高）

业务场景：

低一致性需求：使用内存淘汰机制。例如店铺类型的查询缓存。
高一致性需求：主动更新，并以超时剔除作为兜底方案。例如店铺详情查询的缓存。

缓存更新策略-主动更新策略

分类：

Cache Aside Pattern：由缓存的调用者，在更新数据库的同时更新缓存。（✅实际使用的最多）
Read/Write Through Pattern：缓存与数据库整合为一个服务，由服务来维护一致性。调用者调用该服务，无需关心缓存一致性问题。
Write Behind Caching Pattern：调用者只操作缓存，由其它线程异步的将缓存数据持久化到数据库，保证最终一致。

操作缓存喝数据库时有3个问题需要考虑：

删除缓存还是更新缓存：

更新缓存：每次更新数据库都更新缓存，无效写操作较多（❌）
删除缓存：更新数据库时让缓存失效，查询时再更新缓存（✅）

如何保证缓存与数据库的操作的同时成功或失败？

单体系统，将缓存与数据库操作放在一个事务。
分布式系统，利用TCC等分布式事务方案。

（线程安全问题）先操作缓存还是先操作数据库？

先删除缓存，再操作数据库。
先操作数据库，再删除缓存。
这两种方式都可能出现异常，但第2种出现异常的可能性更低。

缓存更新策略的最佳实践方案

低一致性需求：使用redis自带的内存淘汰机制
高一致性需求：主动更新，并以超时剔除作为兜底方案

读操作
- 缓存命中则直接返回。
- 缓存未命中则查询数据库，并写入缓存，设定超时。
写操作
- 先写数据库，然后再删缓存。
- 要确保数据库与缓存操作的原子性。

缓存穿透的解决策略

缓存穿透：
指的是客户端请求的数据再缓存中和数据库中都不存在，这样缓存永远不会失效，这些请求都会打到数据库。

常见的解决方案：

缓存空对象null

优点：实现简单，维护方便。
缺点：
- 额外的内存消耗（设置TTL）
- 可能造成短期的不一致

布隆过滤
在客户端和redis之间

优点：内存占用较少，没有多余的key
缺点：
- 实现复杂
- 存在误判可能

其它：做好数据的基础格式校验、加强用户权限校验。（避免访问到数据库中不存在的数据）

缓存雪崩问题及解决方案

缓存雪崩：
是指在同一时段大量的缓存key同时失效或者redis服务宕机，导致大量请求到达数据库，带来巨大压力。

解决方案：

给不同的key的TTL添加随机值。（避免同时失效）
利用redis集群提高服务的可用性。（避免宕机）
给缓存业务添加降级限流策略。（快速失败、拒绝服务）
给业务添加多级缓存。（类比：多层防弹衣）

缓存击穿问题及解决方案

缓存击穿：
也叫热点key问题，就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了，无数的请求访问会在瞬间给数据库带来巨大的冲击。

解决方案：

互斥锁（性能较差）（一致性好）

优点：
- 没有额外的内存消耗
- 保证一致性
- 实现简单
缺点：
- 线程需要等待，性能受影响
- 可能有死锁风险

逻辑过期（并不是真的过期）（性能好）

优点：线程无需等待
缺点：
- 不保证一致性
- 有额外的内存消耗
- 实现复杂

CAP定理
在一个分布式系统中，C一致性consistency，A可用性avalibility，P分区容错性Partition tolerance，这三个要素最多只能同时实现2点，不可能三者兼顾。

优惠券秒杀

全局唯一id

订单表如果用数据库自增id会有以下问题：

id的规律性太明显。
受单表数据量的限制。

全局id生成器
是一种在分布式系统下用来生成全局唯一ID的工具，一般要满足下列特性：
唯一性、递增性、安全性、高可用、高性能。
可以用redis-String，java中返回long-8字节

为了增加ID的安全性，我们可以不直接使用Redis自增的数值，而是拼接一些其它信息。

ID-64位-8字节
组成：

符号位：1b，永远为0
时间戳：31b，以秒为单位，可以使用69年-java生成
序列号：32b，秒内的计数器，支持每秒产生2^32个不同ID-（redis-String64位生成，有可能超过32位，所以每一天重置一次序列号，保证不超过32位。）（同时也方便统计年、月、日的订单量）

如何拼接： java生成的时间戳左移32位<<32位或运算| redis-String生成的序列号

全局唯一ID生成策略：

UUID：JDK提供的，16进制，字符串类型，不符合要求
Redis自增：64位数字
snowflake雪花算法：64位数字，不依赖redis，对时钟依赖高
数据库自增：单独开一张表，用于自增id。（redis自增的数据库版）

Redis自增ID策略：
时间戳+序列号

每天一个key，方便统计订单量。
ID构造是时间戳 + 计数器

库存超卖问题

超卖问题是典型的多线程安全问题，针对这一问题的常见解决方案就是加锁：

悲观锁：
一般新增数据时使用
认为线程安全问题一定会发生，因此在操作数据之前先获取锁，确保线程串行执行。

例如Synchronized、Lock都属于悲观锁。
优点：简单粗暴
缺点：性能一般

乐观锁：
认为线程安全问题不一定会发生，因此不加锁，只是在更新数据时去判断有没有其它线程对数据做了修改。

如果没有修改则认为是安全的，自己才更新数据。
如果已经被其它线程修改，说明发生了安全问题，此时可以重试或异常。
优点：性能好
缺点：存在成功率低的问题（可以用分段锁思想解决）

乐观锁
一般是更新数据时用
乐观锁的关键是判断之前查询得到的数据是否有被修改过，常见的方式有2种：

版本号法。查询库存and版本号-再次判断版本号没有被修改才扣减库存and更新版本号。
CAS法。用库存代替版本号的功能，修改时再次判断库存没有变化（或者库存>0）（如果用默认的CAS会导致业务失败率过高）才扣减库存。

一人一单

通过加锁，对用户id加悲观锁（user_id在常量池中，保证不会生成2个值相同但地址不同的user_id），锁在下单函数外面，下单函数事务提交后才释放锁。（需要获取spring管理的下单函数对象，因为默认使用this对象，它不通过spring管理，不支持事务）（如果不支持事务，会存在问题：事务没提交，就释放锁了）

下单函数中，如果通过用户id和优惠券id查询到了数据，说明用户对该优惠券下过一次单了，返回失败。

集群下的线程并发安全问题

如何集群部署

启动2份服务，设置不同端口。
修改nginx的config目录下的nginx.conf文件，配置反向代理和负载均衡。（nginx反向代理服务器）（默认通过轮询方式实现负载均衡）

此时有2台JVM，也就有2个常量池，2个锁监视器，所以user_id可以在2个常量池中存在2次，所以会出现线程并发安全问题。

所以，要让多个JVM共用1把锁，这样的锁JDK无法提供，所以需要分布式锁。（跨JVM、跨进程的锁）

分布式锁

是什么：
满足分布式系统或集群模式下多进程可见并且互斥的锁。
还要满足其它特性：高可用、高性能、安全性、（可重入不可重入、阻塞非阻塞、公平非公平）

分布式锁的核心是实现多进程之间互斥，而满足这一点的方式有很多，常见的有3种：

MySQL

互斥：利用MySQL本身的互斥锁机制
高可用：好
高性能：一般
安全性：断开链接，自动释放锁

Redis

互斥：利用setnx这样的互斥命令（数据不存在时才能set成功）（释放时只用删除这个key即可）
高可用：好
高性能：好
安全性：利用锁超时时间，到期释放

Zookeeper

互斥：利用节点的唯一性（不重复）和有序性（递增）实现互斥（一般利用有序性实现互斥，比如最小的节点）（释放锁：删除节点）
高可用：好
高性能：一般
安全性：临时节点，断开连接自动释放

Redis的分布式锁的实现思路

实现分布式锁时需要实现的两个基本方法：

获取锁

互斥：确保只能有一个线程获取锁
'SETNX lock thread1'
调试点1
'EXPIRE lock 10' 避免服务宕机引起的死锁
但可能在调试点1发生宕机，这时也会死锁。
可以这样：
'SET lock thread1 EX 10 NX'
非阻塞：成功返回true，失败返回false（避免资源浪费）

释放锁：

手动释放：'DEL lock'
超时释放：获取锁时添加一个超时时间。

Redis分布式锁误删问题

场景：

线程1业务太长，超过锁的过期时间，锁释放
线程2获取锁，进入业务，此时线程1执行完业务，释放了线程2的锁，但此时线程2的业务还没执行完。
线程3获取锁，进入业务，此时发生了线程2、3并发执行业务存在线程安全问题。
（极端情况）

原因：
线程1把别人的锁删除了。（Redis分布式锁，不同线程共享一把锁）（删除锁时未判断是否是自己的锁）

解决：
（业务正常结束）释放锁的时候，判断锁的标识（可以用UUID表示）（之前用的是线程的ID，在JVM内部维护的，递增，不同JVM可能发生发生碰撞）是否一致。（宕机情况不用判断，直接释放锁即可）
我们加锁时'SET lock thread1 EX 10 NX'
thread1就是锁的标识。

UUID
用UUID区分不同的服务（不同JVM）（Universally Unique Identifier 通用唯一标识码）
用线程ID区分不同线程

分布式锁的原子问题

场景：

线程1获取锁，执行业务到判断锁是否是自己的，判断完成，下一步就是释放锁了，此时发生了阻塞（比如JVM垃圾回收），这把锁因为超时被释放了。
线程2在锁释放后获取锁，执行业务。
线程1执行最后一步释放锁，线程3可以获取锁，并执行业务。此时线程2、3并发执行，会存在并发执行的线程安全问题。

原因：
判断锁 & 释放锁它们不是原子的，中间存在间隔，在这个间隔内锁被超时释放了。

解决：
保证 判断锁 & 释放锁 这个整体的原子性。
可以考虑redis事务，但是：redis事务支持原子性，不支持一致性，需要结合乐观锁CAS技术，比较复杂。
所以，可以用Lua脚本。

Redis的Lua脚本

Redis提供了Lua脚本功能，在一个脚本中编写多条Redis命令，确保多条命令执行时的原子性。Lua是一种编程语言。

Lua脚本提供了Redis的调用命令：
基本语法：'redis.call(‘mingling名称’，‘key’，‘其它参数’，...)'

redis调用Lua脚本：
基本语法：' EVAL "return redis.call('set', KEYS[1], ARGV[1]) " 1 name ROSE '

Java中RedisTemplate调用Lua脚本：
'excute(RedisScript script, List keys,Object args);'即可

总结：基于Redis的分布式锁实现思路

思路：

利用set nx ex获取锁，并设置过期时间，保存线程标识。（nx保证互斥，ex保证超时删除、兜底方案）
释放锁时先判断线程标识是否与自己一致，一致则删除锁

特性：

利用set nx满足互斥性。
利用set ex保证故障时锁依然能释放，避免死锁，提高安全性。
（lua脚本保证原子性，防止误删）
利用redis集群保证高可用和高并发特性。

Redisson

基于setnx实现的分布式锁存在下面的问题：

不可重入。同一个线程无法多次获取同一把锁。
不可重试。获取锁只尝试1次就返回false，没有重试机制。
超时释放。锁超时虽然可以避免死锁，但如果是业务执行耗时较长，也会导致锁释放，存在安全隐患。
主从一致性。（读写分离模式）如果redis提供了主从集群，主从同步存在延迟，当主宕机时，如果从未同步主中的锁数据，则会出现锁失效。（从升级为主，但是从没有原主的锁数据）

所以，引入redisson

Redisson：
是一个在redis的基础上实现的java驻内存数据网络（In-Memory Data Grid）。它不仅提供了一系列的分布式的java常用对象，还提供了许多分布式服务，其中就包含了各种分布式锁的实现。
分布式锁实现：可重入锁、公平锁、联锁、红锁、读写锁、信号量、可过期信号量、闭锁。

使用：

引入依赖
配置bean（配置redisson地址）
使用redisson的分布式锁：1创建锁对象-> 2获取锁 'lock.tryLock(获取锁的最大等待时间（期间会重试），锁的自动释放时间，时间单位);' -> 3释放锁

redisson的可重入锁原理

通过重入次数，记录重入锁。

利用redis-map数据结构实现。
key：lock
value：hahsmap（field：thread1，value：次数）
通过Lua脚本操作redis的hash数据，保证原子性。
2.1 同一个线程重入时，次数+1。
2.2 释放时，次数-1，如果次数<=0，释放锁（del lock）
2.3 如果不同线程想要获取锁，返回失败（判断线程id不相等）。

Redisson可重试 & leaseTime=-1时超时不释放原理

可重试：订阅并等待锁释放的信号
超时不释放：watchDog

获取锁流程
1.1 判断ttl是否null（null：获取锁成功）（剩余有效时间：获取锁失败）
1.2 获取成功：判断leaseTime是否-1（-1永不过期）（！=-1会过期）
1.3 leaseTime-1:开启watchDog（每隔releaseTime1/3的时间间隔，刷新剩余时间）并放回获取锁成功
1.4 leaseTime！=-1，直接返回获取锁成功。
1.5 ttl！=null 判断剩余等待时间是否>0（大于0：订阅并等待释放锁的信号->判断等待时间是否超时->超时返回获取锁失败、不超时循环尝试获取锁进入1.1）
释放锁流程
2.1 判断是否成功（成功->发送释放锁消息 to 订阅释放锁信号的线程 & 取消watchDog->结束）（失败->记录异常->结束）

总结Redisson分布式锁原理：

可重入：利用hash结构记录线程id和重入次数。
可重试：利用信号量和PubSub（发布订阅）功能实现等待、唤醒、获取锁失败的重试机制。（等待、唤醒不会过多占用CPU）
超时续约：利用watchDog，每隔一段时间（releaseTime/3），重置超时时间。

主从一致问题-mutiLock联锁

lock = redissonClient.getMultiLock(lock1, lock2, lock3);
在这三个锁中都获取到锁才是获取锁成功。
（有一个不成功就不成功，三个主节点-可以配从节点，如果出现某个主宕机，也不会影响获取锁的结果）（可以配置failedLocksLimit获取锁失败上限）（失败的锁>上限，回退，从头开始获取每一把锁）