Redis

分布式、集群的概念https://youzhixueyuan.com/the-difference-between-distributed-cluster-and-load-balancing.html

Nosql概述

为什么要用Nosql

1. 单机MySQL的年代

90年代，一个基本网站访问量不会太大，单个数据库完全足够。静态网页html，服务器没有太大压力！

思考一下，这种情况下：整个网站的瓶颈是什么？

1. 数据量如果太大，一个机器放不下

2. 数据索引(B+树)，数据超过300万条一定就要建立索引，一个机器内存也放不下

3. 访问量（读写混合），一个服务器承受不了

出现三种情况之一，就必须要晋级！

做网站不要一上来就分布式，一定要从单机开始，除非确定用户量很大。

2. Memcached(缓存)+MySQL+垂直拆分（读写分离）

网站80%的情况都是在读，每次都要去查询数据库的话十分麻烦，所以可以用缓存来减轻重复查询数据的压力，保证效率！

发展过程：优化数据结构和索引（首先要优化技术本身）-->文件缓存（IO）-->Memcached(当时最热门的技术)

 

 3. 分库分表+水平拆分+MySQL集群

 数据库本质就是读和写，在发展历程中，都是在针对读和写做优化，解决问题。

早些年MyISAM：表锁，十分影响效率，高并发下就会出现严重的问题。

转战InnoDB：行锁

慢慢的就开始使用分库分表来解决写的压力。MySQL在那个年代推出了表分区，没有多少公司使用。

后来的MySQL集群满足了那个年代的需求！

 

 4. 如今的年代

MySQL关系型数据库不够用了，数据量很多，变化很快！

MySQL如果用来存一些比较大的文件，如博客，图片，数据表很大，效率低。如果有一种专门的数据库处理这种数据，MySQL的压力就小了

 

 

mongoDB使用BOSN来存储数据，JSON二进制格式，文本数据库。

为什么要用NoSQL?

用户的个人信息，社交网络，地理信息。用户自己产生的数据，用户日志等等爆发式增长！

这时候我们就需要使用NoSQL数据库，NoSQL可以很好的处理以上的情况！

什么是NoSQL

NoSQL = Not Only SQL(不仅仅是SQL)

泛指非关系型数据库

很多的数据库类型用户的个人信息，社交网络，地理位置。这些数据类型的存储不需要一个固定的格式！不需要多余的操作就可以横向扩展！Map<String, Object>使用键值对来控制。

NoSQL四大分类

KV键值对：

• 新浪：Redis
• 美团：Redis + Tair
• 阿里、百度：Redis + memecache

文档型数据库（bson格式 和json一样）

• MongoDB(一般必须要掌握)
  • MongoDB是一个基于分布式文件存储的数据库，C++编写，主要用来处理大量文档！
  • MongoDB是一个介于关系型数据库和非关系型数据中中间的产品！MongoDB是非关系型数据库中功能最丰富，最像关系型数据库的。
• CouchDB

列存储数据库

• HBase
• 分布式文件系统

图关系数据库

• 不是存图片的，是存关系的，比如：朋友圈社交网络，广告推荐
• Neo4j, InfoGrid

Redis入门

概述

Redis是什么？

Redis(Remote Dictionary Server)，即远程字典服务！

C语言编写，支持网络，可基于内存亦可持久化的日志型、Key-Value数据库，提供多种语言的API(可以使用Java也可以使用PHP等，几乎所有语言都支持)。

Redis会周期性地把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了主从同步。

Redis能干嘛？用作数据库、缓存、消息中间件MQ

1. 内存存储、持久化（内存是断点即失的，所以持久化很重要）

2. 效率高，可用于高速缓存

。。。。。

Redis是单线程的！

Redis是基于内存操作，CPU不是Redis性能瓶颈，内存和网络带宽才是。

Redis为什么单线程还这么快？

核心：Redis是讲所有数据全部放在内存中的，所以说使用单线程操作效率是最高的。多线程的CPU上下文会切换（耗时操作），对于内存系统来说，如果没有上下文切换就是效率最高的。多次读写都是在一个CPU上的，在内存情况下，这个就是最佳方案。

事务

Redis事务本质：一组命令的集合。一个事务中的所有命令都会被串行化执行！

一次性、顺序性、排他性。

Redis事务没有隔离级别的概念。

Redis单条命令是保证原子性的，但是事务不保证原子性。

redis的事务：

• 开启事务（multi）
• 命令入队（一系列命令。。。）
• 执行事务（exec）

正常执行事务：

 

 

放弃事务：

 

 

编译型异常（代码有问题，命令有错），事务中所有的命令都不会执行！

 

 

运行时异常（例如除0错误），如果事务队列中存在语法性错误，那么执行事务的时候，其他命令是可以正常执行的（所以没有原子性），错误命令抛出异常。

 

 

Redis实现乐观锁

监控 watch一个变量（面试常问）

悲观锁：很悲观，认为什么时候都会出问题，无论做什么都会加锁

乐观锁：

• 很乐观，认为什么时候都不会出问题，所以不会上锁！
• 获取version
• 更新的时候比较version

Redis监控测试

正常执行成功！

 

 

测试另一个线程修改值，使用watch可以当做redis的乐观锁操作

 

如果修改失败，先解锁unwatch，再重新加锁watch，重新获取最新的值

 

Redis持久化

重点！

Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以Redis提供了持久化功能。

RDB(Redis DataBase)

什么是RDB

在指定时间间隔内将内存中的数据集快照写入磁盘，也就是讲的Snapshot快照，它恢复时是将快照直接读入内存里。

父进程正常处理客户端请求，Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。默认用RDB，一般情况下不需要修改这个配置。

RDB保存的文件是dump.rdb

有时候在生产环境下我们会将这个文件进行备份！

redis.conf配置文件中, save 60 10000的意思是60秒内修改了5次key，就会触发rdb操作。默认配置中，900秒内修改1次，300秒内修改10次，60秒内修改10000次，都会触发rdb操作，可以自己更改配置。

 

触发机制：

1.  save 的规则满足的情况下，会自动触发rdb规则，产生rdb文件

2. 执行flushall命令，也会触发rdb规则

3. 退出redis，也会产生rdb文件

如何恢复rdb文件：

1. 只需要将rdb文件放在redis启动目录即可，redis启动的时候会自动检查dump.rdb恢复其中的数据。

2. 查看需要存在的位置，即redis的启动目录

 

 优点：

1. 适合大规模的数据恢复

2. 对数据的完整性要求不高

缺点：

1. 需要一定的时间间隔进程操作，如果redis意外宕机了，最后一次修改数据就没有了。例如save 60 10000，在第59秒的时候宕机了，那么这10000条数据就没了！

2. fork进程的时候，会占用一定的内存空间。

3. 由于快照的特性无法保存创建RDB之后的增量数据。

AOF(Append Only File)

AOF是什么

将我们的所有命令都记录下来，history，恢复的时候就把这个文件全部都执行一遍

 

 

 

 以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF保存的是appendonly.aof文件

Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。

配置文件中appendonly no的意思是AOF默认是不开启的，需要手动配置改成yes才会开启。

持久化策略配置：

• appendfsync always 每写一次就append一次
• appendfsync everysec 每一秒钟append一次，最多只会丢失1秒的数据
• appendfsync no 不append

如果aof文件有问题，是启动不了redis的，可以用redis-check-aof监测文件来修复aof文件

• redis-check-aof --fix appendonly.aof

如果文件正常，重启即恢复。

优点：

1. 默认最多丢失1秒数据，文件的完整性会更好

2. AOF在对日志文件进行操作的时候是以append-only的方式去写的，他只是追加的方式写数据，自然就少了很多磁盘寻址的开销了，写入性能惊人，文件也不容易破损。

3. AOF的日志是通过一个叫非常可读（人能看得懂）的方式记录的，这样的特性就适合做灾难性数据误删除的紧急恢复了，比如公司的实习生通过flushall清空了所有的数据，只要这个时候后台重写还没发生，你马上拷贝一份AOF日志文件，把最后一条flushall命令删了就完事了。

缺点：

1. 相对于数据文件来说，aof远远大于rdb，修复的速度也比rdb要慢。

2. AOF运行效率也要比rdb慢

两者怎么选择？

redis4.0之RDB-AOF混合持久化：小孩子才做选择，我全都要，你单独用RDB你会丢失很多数据，你单独用AOF，你数据恢复没RDB来的快，真出什么事第一时间用RDB恢复，然后AOF做数据补全，真香！冷备热备一起上，才是互联网时代一个高健壮性系统的王道。

Redis主从复制

概念：主从复制，是指将一台redus服务器的数据，复制到其他的redis服务器。前者称为主节点(master/leader)，后者称为从结点(slave/follower)；数据的复制时单向的，只能由主节点到从节点。Master以写为主，Slave以读为主。

默认情况下，每台redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

一个集群至少有三台服务器，一主二从！

主从复制的作用主要包括：

1. 数据冗余：主从复制实现了数据热备份，是持久化之外的一种数据冗余方式。

2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写redis数据时应用连接主节点，读redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高redis服务器的并发量。

4. 高可用（集群）基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制时redis高可用的基础。

 

一般来说，要将redis运用于工程项目中，只使用一台redis是万万不能的（宕机），原因如下：

1. 从结构上，单个redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大；

2. 从容量上，单个redis服务器内存容量有限，就算一台redis服务器内存容量为256G，也不能将所有内存用作redis存储内存，一般来说，单台redis使用内存超过20G，就要切换成集群。

 

 可以在一台机器上模拟，单机多集群。当然多机多服务效果更好。

复制原理：

Slave启动成功连接到master后会发送一个sync同步命令

Master接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送这个数据文件到slave，并完成一次完全同步。

全量复制：slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。

增量复制：master继续将新的所有收集到的修改命令依次传给slave，完成同步。

但只要是重新连接master，一次完全同步（全量复制）将被自动执行！我们的数据一定可以在从机中看到。

哨兵模式

概述

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费时费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。redis从2.8开始正式提供了Sentinel(哨兵)架构来解决这个问题。

能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

哨兵模式是一种特殊的模式，首先redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待redis服务器响应，从而监控运行的多个redis实例（一旦服务器不给哨兵响应了，就认为服务器可能宕机了）。

如下图为单机哨兵

 

 

哨兵有两个作用：

1. 通过发送命令，让redis服务器返回监控其运行状态，包括主服务器和从服务器。

2. 当哨兵检测到master宕机，会自动将slave切换到master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对redis服务器进行监控，可能会出现问题，为此，可以使用多个哨兵进行监控。各个哨兵之间还会进行监控吗，这样就形成了多哨兵模式。

 

 

 假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观认为主服务器不可用，这个现象称为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起（可是能哨兵1,2或3），进行failover[故障转移]操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

有个投票算法，可以看源码。

配置哨兵模式：目前状态时一主(6379)二从(6380,6381)

1. 配置哨兵配置文件sentinel.conf

进入配置文件目录，建一个哨兵配置文件，例sentinel.conf

内容：

#sentinel(配置的是什么) moniter(监视的是谁) myredis(被监控的名称) 127.0.0.1 6379(监控主机) 1(代表有一个哨兵认为主机挂掉，就客观上认为主节点失联了)

sentinel moniter myredis 127.0.0.1 6379 1

2. 启动哨兵

 

 

 如果master节点断开了，这个时候就会从从机中随机选择一个服务器（这里有一个投票算法）。此时6381从机转换为主机。

 

 

 如果主机此时回来了，只能归并到新的主机下，当做从机，这就是哨兵模式的规则。

优点：

1. 哨兵集群，基于主从复制模式，所有的主从复制优点，它都有

2. 主从可以切换，故障可以转移，系统的可用性会更好

3. 哨兵模式就是主从模式的升级，手动到自动，更加健壮

缺点：

1. Redis不好在线扩容，集群容量一旦到达上限，在线扩容十分麻烦

2. 实现哨兵模式的配置其实是很麻烦的，里面有很多选择

哨兵模式的全部配置：

如果有哨兵集群，就要为每一个哨兵配置端口号，开启三个（如果集群中有三个哨兵）哨兵配置文件

 

 

 Redis缓存穿透与雪崩（面试高频）

服务的高可用问题

 

 

缓存穿透（查不到）

概念

缓存和数据库中都没有的数据，用户不断发起请求。用户想要查询一个数据，发现redis内存数据库没有，也就是缓存没有命中，于是向持久层数据库查询。发现也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中（比如秒杀活动，并发量很大），于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透。

我们数据库的id都是1开始自增上去的，如果发起id为-1的数据或id为特别大不存在的数据。这时用户很可能是攻击者，攻击会导致数据库压力过大，严重会击垮数据库。

解决方案：布隆过滤器

原理：https://juejin.im/post/6844903982209449991

布隆过滤器是一种数据机构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力。

 

 缓存空对象

 当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源；

 

 

 这个方法有两个问题：

1. 如果空值能够被缓存起来，就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键；

2. 即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致（可能缓存层没有，但是存储层有），对于需要保持一致性的业务会有影响。

缓存击穿（量太大，缓存过期，在这个空档期，都对mysql进行了访问）

概述

跟缓存雪崩有点像，但又不一样。缓存雪崩是因为缓存大面积失效，打崩了DB；而缓存击穿是指一个key非常热点，例如微博热搜，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库。

当某个key在过期的瞬间，持续的大并发就穿破缓存，直接请求数据库，会导致数据库瞬间压力过大，就像在一个完好无损的桶上凿开了一个洞。

解决方案

• 设置热点数据永不过期
• 加互斥锁，分布式锁：使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。

缓存雪崩

概念

缓存雪崩，是指在某一个时间段，缓存集中过期失效。redis宕机

产生雪崩的原因之一，比如在写文本的时候，马上就要到双十二零点，很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨1点的时候，这批商品的缓存就都过期了。而对于这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求都会到达存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。

其实集中过期，倒不是非常致命，比如致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，这个时候，数据库也是可以顶住压力的，无非就是对数据库产生周期性的压力而已。而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。

解决方案

• redis高可用：多设几台redis，其实就是搭建的集群
• 限流降级：缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。如果对于某个key只允许一个线程查询数据和写缓存，其他线程等待。
• 数据预热：再正式部署之前，先把可能的数据预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间（加随机值），让缓存失效时间点尽量均匀。

 

常问面试题

• redis基础https://juejin.im/post/6844903982066827277
• 持久化https://juejin.im/post/6844903989184577550
• 缓存雪崩、击穿、穿透https://juejin.im/post/6844903989184577550
• 布隆过滤器https://juejin.im/post/6844903982209449991

1. 为什么要用redis？

mysql不适用现在的大数据量和高并发的需求，需要用缓存做中间件。

其中memcached与redis的区别和使用的场景见https://www.cnblogs.com/aspirant/p/8883871.html

memcached实现分布式的方法是一致性hash，详情见https://juejin.im/post/6844903598694858766

redis存储类型更多，可以再说redis把数据放在内存中，避免磁盘IO带来的性能问题，在当今内存越来越便宜的情况下，redis越来越受欢迎。

2. redis有哪些数据结构？

各种数据结构的底层实现https://www.jianshu.com/p/fb7547369655

String :key-value缓存应用，最常规的set/get操作，也可以做加1减1操作，用于计数

底层实现：int编码字符串对象，raw编码字符串对象

功能：value中string类型是二进制安全的，即Redis的string可以包含任何数据，比如图片或者序列化的对象。

应用场景：缓存、计时器、分布式锁

List：

底层实现：3.2之前, ziplist/linkedlist  3.2+, quicklist(快速列表，是ziplist和linkedlist二者结合，quicklist是一个ziplist组成的双向链表，每一个结点保存这一个一个小的ziplist。)

功能：value作字符串列表，支持两端插入和弹出，并可以获得指定位置的元素。

应用场景：关注列表，粉丝列表，消息队列

hash：

底层实现：ziplist和hashtable

当hash对象可以同时满足以下两个条件时，哈希对象使用ziplist编码。

• 哈希对象保存的所有键值对的键和值的字符串长度都小于64字节。
• 哈希对象保存的兼职对数量小于512个。

冲突：当有两个或以上的键被分配到哈希数组的同一个索引上时，会产生哈希冲突。Redis也使用链地址法来解决键冲突。

应用场景：存储用户信息、用户主页访问量、组合查询

set：

底层实现：intset和hashtable

intset可以理解为数组，hashtable就是普通的哈希表(key为set的值，value为null).

set的底层存储intset和hashtable是存在编码转换的，使用intset存储必须满足下面两个条件，否则使用hashtable，条件如下：

• 结合对象保存的所有元素都是整数值
• 集合对象保存的元素数量不超过512个

intse内部是一个数组，且存储数据的时候是有序的，查找时使用二分查找。

应用场景：暂、踩、标签、好友关系

• 存储一些集合性的数据，比如微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合；
• 可以对集合取交、并、差集，应用到好友推荐、共同关注等。
• 还可以利用唯一性，统计访问网站的所有独立IP。

SortedSet(Zset)：

底层实现：ziplist或skiplist

在同时满足以下两个条件时使用ziplist，其他时候使用skiplist

• 有序集合保存的所有元素的长度小于64字节
• 有序集合保存的元素数量小于128个

ziplist：紧挨着的是元素和分值，整体数据有序。

skiplist：核心店主要包括一个dict对象和一个skiplist对象。dict保存key/value，key作为元素，value作为分值，便于通过key(元素)获取score(分值)；skiplist保存的有序的元素列表，每个元素包括元素和分值，便于执行range之类的命令。

应用场景：积分排行榜。

geospatial地理位置：朋友的定位，附近的人，打车距离计算等。

• 通过经纬度定义城市，可计算以一个点为圆心，指定半径范围内的人（附近的人）；
• 根据经纬度计算打车距离（打车距离计算）

hyperloglog：做基数统计的算法，有0.81的错误率，内存固定。网页的UV(访问量)--->一个人访问一个网站多次，但是还是算作一个人。传统的方法用set保存用户id，可以统计set中元素数量，这个方式如果保存大量的用户id，就比较麻烦。但是我们的目的不是保存用户id，而是为了计数！！

基数：不重复的元素。例如A{1,3,5,7,8}的基数是5，可以接受误差。

bitmaps：位运算，只有0和1。筛选用户最快！统计疫情感染人数，统计用户信息，365天打卡。两个状态的，都可以用bitmaps。

还可以再说BloomFilter（布隆过滤器），使用场景多，原理简单，会让面试官眼亮！

3. 为什么Redis那么快？（重要！）

先看关系型数据库和redis本质上的区别：

 

 基于内存、单线程的KV数据库，用C语言编写（更贴近底层），官方提供的数据可以达到100000+QPS（每秒内查询次数）。

• 完全基于内存，内存操作，快速。数据类似于HashMap，查找和操作的时间复杂度都是O(1).
• 数据结构简单，对数据操作也简单
• 单线程，避免了不必要的上下文切换和竞争条件，也不存在多线程或者多进程导致的切换而消耗CPU。
• 多路IO复用模型，非阻塞IO。

4. 实现Redis高可用：集群部署方式Redis Cluster或者哨兵集群（主从架构+Sentinel哨兵模式，至少需要三个哨兵实例来保证自己的健壮性）。主从+哨兵并不能保证数据不丢失，但是可以保证集群的高可用。

5. 主从之间数据怎么同步？

Slave启动成功连接到master后会发送一个sync同步命令

Master接到命令，触发一次全量复制。master会启动一个线程，生成RDB快照，还会把新的收集到的修改命令缓存在内存中。RDB文件生成后，master将这个文件发送给slave，slave拿到之后第一件事就是把写进本地磁盘，然后加载进内存，然后master继续将新的所有收集到的修改命令依次传给slave（增量复制），完成同步。

但只要是重新连接master，一次完全同步（全量复制）将被自动执行！我们的数据一定可以在从机中看到。

6. Redis过期策略和内存淘汰机制？手撕LRU？

https://leetcode-cn.com/problems/lru-cache/solution/lruhuan-cun-ji-zhi-by-leetcode-solution/

7. 分布式锁解决并发一致性

Redis：SETNX

格式：setnx key value

将key的值设为value，当且仅当key不存在。如果key已经存在，则setnx做任何动作。注意要记得释放锁。

 

 

防止代码发生异常，导致释放锁操作没有执行导致死锁，可以用try, finally解决。

如果在执行释放锁之前进程被kill了，释放锁操作依然不会被执行，则可以设置一个过期时间，即使无法手动释放锁，也可以在10秒后过期，防止死锁。

 

 

但是可能setnx执行成功，但是expire失败，导致死锁。这种情况可以用set expire的原子操作，一起执行。

 

 

非高并发场景下，上面那样写应该就可以了，但是在高并发场景下使用，问题很大。比如线程A执行一个请求可能执行15秒，但是10秒的时候锁就过期了，线程B获得锁去执行请求，当到达15秒时线程A执行完毕，释放锁，但此时释放的锁是线程B的锁。当再来一个线程C，线程B可能又会把线程C的锁给释放了。只要是高并发的场景还在，这个锁就可能一直失效！问题很大！

解决方法：可生成一个 UUID 标识当前线程，在执行释放锁之前判断一下。

 

 

但还是有锁超时的可能性，无论把超时时间加到多久，都有可能超时，而且时间太长，如果线程挂掉，要等几分钟才能释放，不合适！

解决方法：锁续命，Redisson（redis java客户端，用于分布式场景）已经都封装好了、

 

 

Redisson分布式锁实现原理：

 

 

 Redssion代码实现用了很多lua脚本，会把这个lua脚本当成原子命令去执行。

加锁底层实现：

 

 

问：主从架构做分布式锁有什么问题？

问题：

Redis主从架构锁失效问题：线程1在主节点中加锁成功，但是主节点的数据还没有同步给从节点，主节点就挂掉了，此时哨兵模式将从节点变成主节点，线程2在新的主节点上发现没有锁，则可以加锁成功，所以就会出现同一个商品的加锁逻辑有多个线程在执行。

解决方案：

1. 可以用zookeeper解决。

zookeeper与redis类似，虽然功能有差异，也可以轻松实现分布式锁，用zk实现就没有主从架构锁失效的问题。zookeeper也可以当做一个缓存，也是在内存中的KV，但它的KV是树形结构。也有主从架构，主节点叫Leader，从节点叫Follower。

zk与redis的区别：

zk与redis集群架构的区别，要从CAP理论说起。

CAP理论：一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项。

• 一致性：所有节点在同一时间的数据完全一致。要结合多个数据拷贝下并发读写的场景。
• 可用性：服务在正常相应时间内一直可用。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。可用性通常情况下可用性和分布式数据冗余，负载均衡等有着很大的关联。
• 分区容错性：分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。

redis集群架构满足AP，也就是可用性高一些；zk集群架构满足CP，也就是一致性高一些。redis主节点只要写key成功，即加锁成功，就会马上告诉客户端加锁成功；但是写zk主节点的key，加锁成功不会马上告诉客户端，而是同步给从节点，并且只有收到超过一半的从节点同步成功的结果后，zk才把加锁成功的结果告诉客户端。如果zk主节点挂了，zk会重新选取新的主节点，ZAB选取协议，会帮我们保证同步成功的从节点变成新的主节点。这时再来一个线程在新的主节点上写key加锁，就会不成功。

如何选择？如果并发要求不高，可以选择zk，zk就是分布式协调框架，比redis更适合做分布式锁。但是对并发要求高的话，可以选redis。

2. 非要用redis的话，可以用Redlock也可以解决。不推荐！

多个redis节点，没有主从，是对等的，每次加锁要同时给多个redis节点触发这个命令，超过半数redis节点加锁成功才算成功，否则就把成功的那个节点回滚。比较麻烦，要做很多判断。

问：redis为什么可以作为分布式锁？

因为redis是单线程的，所有的请求在redis上都会形成一个队列，顺序执行，先拿到锁的先执行。

8. 缓存数据库的双写一致性问题https://learnku.com/articles/22363

缓存的更新策略https://zhuanlan.zhihu.com/p/86396877

最经典的缓存+数据库读写的模式，就是 Cache Aside Pattern

• 读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
• 更新的时候，先更新数据库，然后再删除缓存。

*采用延时双删策略* （1）先淘汰缓存 （2）再写数据库（这两步和原来一样） （3）休眠1秒，再次淘汰缓存