目录
一、解决redis服务器端口问题
redis客户端在windows环境下(IDEA)，redis在linux云服务下，若客户端想访问服务器，首先需要在云服务器外网IP下访问，其次还需要能访问到服务器端口。修改IP后，如何访问到服务器端口？？？redis的服务器端口默认是被云服务器的防火墙保护着的，即使在外网ip下也是不能访问的。那需要将redis服务器的端口号像tomcat一样，设成开放形式吗？？？这种做法是不可行的，tomcat即使设成开放形式，黑客也不容易入侵，但若redis设成开放形式，是很容易被黑客入侵的。那如何在不开放端口的情况下，访问到redis服务器？？？
解决方法：
1、将java代码打包成可执行的jar包，直接在linux服务器上运行。
2、配置ssh端口转发，把云服务器的redis端口，映射到本地主机
ssh支持端口转发，可以将redis服务器端口6379映射到本地端口8888，后续可以直接访问：127.0.0.1:8888就可以访问本机的redis服务器了。
在linux云服务器上进行配置：
检查是否配置成功，输入netstat查看本地是否有8888端口：
ps：当配置了端口转发后，一定要断开连接进行重新连接。
二、java环境下使用redis
1、引入依赖
2、使用(这里就只拿String举例，语法基本和redis命令一样)
（1）get和set
（2）mget和mset
（3）incr和decr
三、javaSpringt环境下使用redis
1、配置文件，连接redis
2、选择redis
3、使用
springboot对redis不同类型进行了封装，可以使用不同类型下的一些方法。
四、redis持久化
1、持久化概念
持久化是指将数据保存在持久存储介质(如硬盘、数据库等)，保证数据的长期存储，以便在需要时能够重新读取和处理数据。
2、redis持久化策略
redis将数据放在内存中，内存的特点是访问速度快，但是不能长期存储数据，当计算机关闭或重启时，内存中的数据就会被清空，如何使得redis能持久化存储数据？？？redis采用RDB和AOF两种策略，将数据同步到硬盘中，当redis重启时，用来恢复数据，使得redis具有持久化。
3、RDB策略
（1）实现原理
触发RDB持久化后，将redis内存中的所有数据生成快照(RDB二进制文件)，保存到硬盘。
（2）触发RDB持久化
①手动触发
在redis客户端，执行特定的命令，触发rdb持久化，生成快照。
save命令：阻塞当前redis服务器，无法处理客户端的其他命令，全力以赴的进行快照生成操作。
bgsave命令：redis进程执行fork操作创建子进程，由子进程负责进行快照生成操作，完成后自动结束，redis服务器阻塞只发生在fork阶段。
bgsave执行流程：
当执行bgsave命令时，redis父进程先判断当前是否存在其他正在执行的子进程，如RDB/AOF子进程，如果存在bgsave直接返回；如果没有父进程执行fork操作创建子进程，子进程根据父进程内存数据生成临时快照文件，完成后对原有RDB文件进行替换，并且该进程发送信号给父进程表示完成，父进程更新统计信息。
举例：
此时就会手动写入rdb文件中。rdb文件保存在配置指定的目录，默认为(/var/lib/redis)下，文件名默认为dump.rdb。
假如没有手动写入硬盘，也没有达到自动触发的条件，若重新启动redis服务器，此时会获取到之前的数据吗？？？
若是通过正常流程启动redis服务器，此时redis在退出的时候会自动触发生成rdb文件；但若是异常重启(kill-9或者服务器掉电)，此时redis来不及生成rdb文件，内存中的尚未保存到快照中的数据就会随着重启而丢失。
正常关闭：
异常关闭：
②自动触发
redis也可以自动触发rdb持久化机制。
使用save配置，如："save m n "表示m秒内数据集发生了n次修改，自动触发rdb持久化机制；
正常关闭redis服务器时，也会自动触发rdb持久化机制；
redis进行主从复制时，主节点也会自动生成rdb快照，然后将rdb快照文件内容传输给从节点。
以上可以改变自动触发条件。
ps：如果修改了rdb文件内容，并且通过kill -9 关闭进程，则很可能重新启动redis时失败。当rdb文件损坏时，可以使用redis提供的redis-check-dump工具检查rdb文件并获取对应的错误报告。
（3）RDB策略的优缺点
优点：rdb是二进制文件，加载rdb恢复数据较快。
缺点：rdb策略不能实时更新数据到rdb文件，若此时redis服务器挂了，且内存中最新的数据还未更新到rdb文件中，此时这部分数据就丢失了；创建子进程，进行全量数据保存，属于重量级操作，频繁执行成本过高。
4、AOF策略
（1）实现原理
AOF是实时进行持久化的，重启redis时执行AOF文件中的命令达到恢复数据的目的。
所有的写入命令会追加到aof缓存区中，根据缓存区的刷新策略将数据更新到硬盘中(AOF文件)，随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩目的。当redis服务器进行重启时，可以加载AOF文件进行数据恢复。
（2）AOF文件
首先需要开启aof，当开启aof时，rdb就不再生效了，redis服务器重启时，就不读取rdb文件了。
进入配置文件开启aof：
写入键值对，查看aof文件(路径和rdb一样)：
（3）刷新策略
前面提到所有的写入命令会先放到aof缓冲区中，根据刷新策略再将数据更新到硬盘中，从而减少了操作硬盘的次数，提高效率。
刷新策略在配置文件中：
always：命令写入缓冲区就向硬盘中写入，写入频率最高，数据可靠性最高，性能最低；
everysec：同步线程每秒刷新一次缓冲区的数据到硬盘中，写入频率较低，数据可靠性较低，性能较高；
no：redis不会主动刷新缓冲区数据到硬盘中，而是直接交给操作系统去判断，写入频率最低，数据可靠性最低，性能最高。
（4）AOF文件重写
前面提到，当aof文件越来越大时，需要定期对aof文件进行重写，达到压缩的目的。
例如：set key1 111; set key2 222; set key1 222;
最后的结果应该只有两条，但如果不重写，aof会保存3条数据，此时就要求要定期对aof文件进行重写，压缩文件。
aof文件重写原理：
ps：fork之后的写入命令还需要写到缓冲区和旧aof文件，是为了防止新aof文件突然挂了，此时aof文件就没有fork之后的数据了，数据不准确。
（5）AOF策略优缺点
优点：aof策略是实时更新数据到aof文件，数据可靠性高；
缺点：aof文件是文本文件，加载aof恢复数据较慢。
5、混合持久化策略
redis结合了aof和rdb的特点，引入了混合持久化策略，每一个写入命令按照aof的方式(文本)写入文件，当触发重写时，将缓冲区所有内容以rdb(二进制)写入新文件中，使用新文件替换旧文件。后续进行写入命令时，还是按照aof方式写入文件。
五、redis事务
1、数据库事务
了解redis事务前，先回顾数据库事务。
数据库事务的概念：一组操作，要么全部成功，要么全部失败。
数据库事务的特点：①原子性；②一致性；③持久性；④隔离性；
2、redis事务特点
redis事务和数据库事务一样，都是对一组操作进行打包完成。
特点(数据库事务对比)：①弱化的原子性；redis没有回滚机制，一组操作中若有一个命令执行失败，这一组操作还是会继续执行，不要求全部失败；②不保证一致性；redis不涉及约束，不保证结果都是合理有效的；③不需要隔离性；redis是单线程处理请求；④不具备持久性；redis数据存储在内存中不具有持久性，aof和rdb持久策略和事务无关。
3、redis事务的作用
当面对不同的redis客户端时，保证服务器对同一个客户端的一组操作全部执行完毕后，再执行下一个客户端的命令。
4、redis事务操作
（1）multi
开启一个事务，执行成功返回ok。后面的每个命令会先放在客户端队列里。
（2）exec
执行一个事务。
（3）discard
放弃当前事务，清空队列。
（4）watch
在执行事务时，假设客户端1先修改了key1的值为100，然后客户端2修改了key1的值为200，按照时间先后顺序，key1的值应为200，但若exec命令是在客户端2之后，此时key1的值就为100了，此时这种情况就会造成歧义。
使用watch命令监督某个key，若在执行事务时，其他客户端修改了该key，真正提交事务时服务器会发现监督的key版本号已经超过了事务开始时的版本号，就会让事务执行失败，所有命令都不执行。
（5）unwatch
取消对key的监控。
六、主从复制
1、主从模式
（1）作用
主从模式是分布式系统中的一种模式。当只有一个服务器来存储redis数据时，此时若该服务器挂了，后续客户端也无法从redis中读取数据了。在分布式系统中，希望有多个服务器来部署redis服务，构成一个redis集群。即使其中一个挂了，客户端还可以去其他服务器上读取数据，对于读操作的并发量下的可用性进行了提高。
（2）原理
主从模式中，有n个节点，其中有一个主节点，n-1个从节点。主节点可以修改数据，可以读数据；从节点只能读数据；当主节点数据发生变化时，从节点数据也需要一起变化；从节点挂了，不影响redis的使用；主节点挂了，此时就不能修改redis数据了。
2、主从复制
参与复制的redis服务器被划分为主节点和从节点，一个redis服务器只能有一个主节点，但可以拥有多个从节点，复制只能由主节点到从节点。
分布式系统中，每个服务器应该处于不同的云服务器上，但此时博主手里就一个云服务器上，所以就只能启动几个端口不同的redis服务器进行演示。
（1）启动三个不同端口的redis
启动3个不同的redis服务器，端口号分别为：6380、6381、6382。
端口号的设置我们在配置文件中修改，先建立一个目录，里面装3个不同端口redis的配置文件：
修改三个文件的端口号以及开启后台模式：
启动三个不同的redis：
（2）建立主从关系
以6380为主节点，6381和6382为从节点，修改从节点配置文件，建立主从关系；
同时需要修改每个节点aof所处的路径，不然会导致每个redis的aof文件是一样的：
以上三个用来放置每个redis服务器对应的aof文件。
修改aof文件的放置路径：
需注意：在修改了配置文件之后，需要重新启动redis.
如果使用命令redis-server+配置文件启动的redis，需要使用kill -p id杀掉redis进程；
如果使用命令service redis-server start这种方式启动的redis，需要使用service redis-server stop杀掉redis进程。
杀掉并重启从节点redis：
重启之后，每个redis就有自己的aof文件了。
（3）客户端与服务器之间建立连接
（4）效果演示
主节点建立key：
从节点获取key：
从节点建立key(失败)：
（5）查看节点的状态
主节点：
offset：主节点会不断收到数据，从节点也要同步数据，但这个同步不是瞬间完成的，offset就记录了从节点同步数据的进度。
从节点：
（6）断开连接
主节点与从节点之间也可以断开连接。
例如：断开6380端口对应的redis连接，从节点变为主节点
（7）拓扑
redis的复制拓扑结构可以支持单层或多层复制关系，根据拓扑复杂性可以分为：一主一从、一主多从、树状主从结构。
一主一从：
一主多从：
树状主从结构：
（8）数据同步psync
redis使用psync命令完成主从数据同步，同步过程分为：全量复制和部分复制。
全量复制：一般用于初次复制场景，会把主节点数据一次性全部发送给从节点；
部分复制：由于网络原因导致主从复制数据丢失，从节点再次连接上主节点后，若缺失的数据不多，主节点会部分复制数据给从节点。
实时复制：主从建立连接后，主节点会把自己收到的修改操作，通过tcp长连接，源源不断的传输给从节点，从节点就会根据这些请求修改自身的数据，保证主从节点数据一致。同时，主从节点也都有心跳检测机制，主节点每隔10s对从节点发生ping命令，判断从节点是否存活；从节点每隔1s向主节点发送命令告诉主节点当前复制偏移量。60s后没有响应，判断从节点下线，断开连接，从节点恢复连接后，心跳机制继续进行。
psync语法格式：psync replicationid offset
replicationid：指主节点的复制id，主节点启动或者从节点晋升为主节点都会生成一个replicationid
offset：偏移量，主节点每次在进行写入命令后，其偏移量会累加；从节点每次在复制主节点的数据后，其偏移量也会累加；当主节点的偏移量与主节点的偏移量相等时，此时主从节点数据一样。
注：当replicationid默认值为?，offset的默认值为-1时，此时为全量复制；
（9）psync运行流程
①初次复制，从节点发生psync命令给主节点，replid默认值为?，offset默认值为-1；
②主节点根据psync参数和自身数据情况决定响应结果：
如果回复+FULLRESYNC，则从节点需要进行全量复制；
如果回复+CONTINEU，从节点进行部分复制流程；
如果回复-ERR，说明redis主节点版本过低，不支持psync命令；
七、哨兵
1、哨兵的作用
Redis的主从复制模式下，一旦主节点挂了，不仅需要人工进行主从切换，还需要通知客户端更换到其他节点上，这种方式效率较低，于是redis就提供了哨兵(Redis Sentinel)来解决这个问题。
2、哨兵原理
每个redis sentinel都是一个单独的进程(一般为多个，且是奇数)，每个进程会和节点建立tcp长连接，定时发生心跳包。若规定时间内未得到回应，该哨兵就会认为此节点出现了故障，若此节点是主节点，其他哨兵也会来判断主节点是否是真的挂了，若哨兵达成共识认为主节点挂了，此时哨兵之间会通过raft算法选举出一个哨兵领导角色，由该哨兵负责在从节点中挑选出一个主节点，被挑选出的从节点执行slaveof no one，并且其他从节点要和新选出的主节点建立主从联系。哨兵节点也会自动通知客户端新的主节点，并且后续客户端进行写操作是写入到了新的主节点中。后续如果旧的主节点恢复了，它会成为一个从节点。
3、基于docker搭建redis哨兵环境
（1）基于ubuntu下安装docker
①安装依赖
②添加Docker官方GPG密钥
③添加Docker的软件源
④安装docker
⑤配置用户组
⑥安装工具
⑦重启docker
⑧查看版本
（2）安装docker-compose
（3）停止之前的redis服务器
（4）使用docker获取redis的镜像
（5）docker-compose进行容器编排
此时我们需要6个容器，其中3个Redis服务器(1主2从)，3个哨兵节点。
可以使用yml配置文件进行批量启动，3个redis服务器为1个配置文件，3个哨兵节点为1个配置文件。
①创建两个目录，分别放redis和哨兵节点的配置
②配置redis服务器的容器
③创建服务器的容器并启动
④配置redis哨兵节点的容器
⑤创建redis节点容器并启动
此时若直接使用命令redis-compose up -d会报错，是因为哨兵节点需要监控主节点或从节点中的一个，但这两部分是分成两部分来创建的容器，处于不同的局域网中，这两部分是不能互通的，此时需要将哨兵节点加入到主从节点局域网中。
查找主从节点的局域网：
将哨兵节点加入到主从节点的局域网中：
启动哨兵节点：
4、查看哨兵效果
（1）客户端分别连接不同端口服务器并查看服务器角色
（2）模仿主节点服务器宕机 观察其他从节点
其他从节点中的一个被改为主节点。此时，即使原本的主节点恢复正常，它也依旧是主节点，原本的主节点被改为从节点。
八、集群
1、集群概念
（1）广义的集群
指多个机器构成了分布式系统。
（2）狭义的集群
redis提供的集群模式指狭义的集群，主要是拓展节点的存储空间，解决存储空间不足的问题。
2、集群的作用
虽然redis在主从复制中可以拥有多个服务器支持读请求，但是此时每个节点中存储的依旧是全量数据，若数据过多，存储空间会不足，此时就需要多个机器存储数据，每个机器存储部分数据，且每个机器又会搭配一组从节点和哨兵节点。
3、集群原理
每个红框部分可以称为一个分片。
4、数据分片算法
对于增加的数据，应如何进行分片呢？？？
（1）哈希求余
①原理：假设有N个分片，编号为[0,N-1]。对于每个key，计算hash值，hash值%N，结果即为分片编号。
②优点：简单高效，数据分配均匀。
③缺点：一旦分片进行扩容，就需要对全部数据进行重新分配，需要搬运的数据较大，开销较多。
（2）一致性哈希算法
①原理
先将0-->2^32-1个数据空间映射到圆环上，数据按照顺时针方向增长。
假设现在有三个分片：
对于key求完hash值后，hash值在哪个区间内，即就属于对应分片。
若此时增加一个分片：
此时就需要对0号分片的数据进行重分配，判断是属于0号分片还是3号分片，但1号分片和2号分片对应数据不需要改变。
②优点：大大降低了分片扩容时数据搬运的规模，提高扩容操作效率。
③缺点：分片对应数据分配不均匀。
（3）哈希槽分区算法--redis使用
①原理：
假设有三个分片，将哈希值映射到16384个槽位上(哈希值%16384)，将这16384个槽位均匀的分配给每个分片上。
0号分片：[0,5461]，共5462个槽位；
1号分片：[5462,10923]，共5462个槽位；
2号分片：[10924,16384]，共5460个槽位。
此时就可以根据key计算hash值，将hash值进行映射得到哈希槽位，根据哈希槽位找到区间判断是几号分片即可。
若此时增加一个分片，一种可能的分配方式：
0号分片：[0,4095]，共4096个槽位；
1号分片：[5462,9557]，共4096个槽位；
2号分片：[10924,15019]，共4096个槽位。
3号分片：[4096,5461]+[9558,10923]+[15019,16384]，共4096个槽位。
ps：此时大家一定有个疑问，为什么是16384个槽位呢？？?
这主要是基于性能和资源利用的考虑，在redis节点发生心跳包时，需要将槽信息放入心跳包中，以便让节点了解当前集群的状态，若槽的数量过多，会导致心跳包的大小增加，进而增加网络传输负担和节点处理压力；若槽的数量过少，则可能无法充分利用集群的资源。因此，考虑到集群的稳定性和资源的充分利用，redis设计者选择了16384槽位作为默认槽位，且建议分片数量不要超过1000。
②优点
进行分片扩容或缩容较为方便。
③缺点
计算复杂。
5、基于docker搭建redis集群
（1）创建redis节点
创建11个redis节点，其中3个一组为1个分片，一组中有1个主节点2个从节点，剩余2个用于扩容示范。
考虑到创建节点较多，可以使用脚本：
创建一个目录：redis-cluster
在该目录下创建两个文件，第一个文件放docker配置；第二个文件放shell脚本，可以批量化执行，创建出11个节点的配置文件。
向generate.sh文件中写入脚本：
执行shell脚本：
执行成功后，就生成了11个配置文件：
（2）配置redis容器
向docker-compose.yml文件中添加docker配置（其中某一个redis节点的docker配置）：
172.30.0.0是静态ip地址中的网络号，要保证该ip是内网且不能和当前主机上其他网络号冲突(ifconfig命令可以查询)。
（3）启动redis容器
（4）构建集群
包括参与集群的端口号和每个分片包含的从节点个数。
集群信息：包括主从关系和槽位分配。
集群配置成功：
集群信息：
6、集群效果
（1）添加key
直接在101分片中添加key1：
此时发现会报错，是因为key1的hash值为9189，属于102分片，无法在101分片添加。
换一种方式添加key1：
添加-c选项后，就可以自动根据槽位自动进行分片转换了。
注意：在集群环境下，无法操作多个key。
（2）集群中主节点挂掉
挂掉redis1主节点：
此时发现redis5就会成为主节点。
当redis1恢复后，它也是以从节点方式进行运行的：
（3）集群环境下节点故障处理原理
每个节点，每秒钟会随机给一些节点发生ping包，通过节点是否在规定时间返回pong包判断节点是否正常。
假设A节点发生ping包给B节点，在规定时间内若A节点未收到B节点返回的pong包，A就会尝试和B重新进行tcp连接，若没有连接成功，A就会认为B挂掉了，并且通过Gossip协议和其他节点进行沟通，确认B是否挂掉，若超过一半的集群个数认为B挂掉了，此时A就会把B标记为FAIL，并告诉其他节点。
当B是从节点时，此时不会进行故障迁移；当B是主节点时，会进行故障迁移。
故障迁移：由B的从节点(假设为C和D触发故障迁移)。
①从节点先判断自己是否有资格竞选主节点，若太久没有和主节点通信，则从节点失去竞选资格；
②具有竞选资格的从节点会休眠一定时间，休眠时间和offset值有关，值越大，排名越靠前，休眠时间越少。
③休眠时间到的从节点会进行拉票操作，且只有主节点具有投票资格，当从节点的票数超过主节点个数一半时，该节点就会晋升成主节点。
④该节点会把晋升为主节点的消息告诉给其他集群节点，更新保存集群结构信息。
（4）整个集群环境宕机的情形
①一个分片的主从节点全部挂掉；
②一个分片主节点挂掉，但是没有从节点；
③短时间内，集群环境中超过一半的主节点全部挂掉。
7、集群扩容
实现效果：当前集群环境为3个分片，打算扩容为4个分片，110主机为主节点，111主机为从节点。
（1）将110主机对应节点加入集群环境中
110是一个master，但此时还没有槽位：
（2）重新分配哈希槽位
调用命令：
移动1/4的哈希值：
选择哪个节点(110对应的ID)来接受这些移动的哈希值：
选择这些slots从哪些节点搬运(填写all表示所有主节点都要进行搬运，done表示自定义)：
重新分配后的slots：
注意：在进行扩容时，搬运key时，对应key是无法进行访问的。
（3）将111主机对应节点加入集群环境中
111主机对应节点为110的从节点：
九、redis典型应用--缓存
数据访问速度：cpu寄存器>内存>硬盘>网络。
可以将数据存储在内存中，作为硬盘的缓存。数据库是将数据存储在硬盘中，redis是将数据存储在内存中，可以使用redis作为数据库的缓存，从而提高数据的访问效率。
1、实现过程
客户端发起查询请求，服务器先查询redis，如果redis中存在则直接返回数据，如果redis中不存在，则再去数据库中查询。
我们需要在redis中存放20%的热点数据，就可以使80%的请求不再真正查询数据库了。
2、热点数据
哪些数据属于热点数据呢？？？
（1）定期生成
每隔一定周期(一天/一周/一月)，对于访问的数据频率进行调查，选取前20%的数据作为热点数据，但这部分热点数据不具有实时性。
（2）实时生成
给redis设置容量上限(配置文件中maxmemory参数)，针对每次查询，如果在redis中查到了就直接返回，若干redis中不存在，就在数据库中查询，把查到的结果写入redis中。如果redis容量已经达到上限，此时就会触发缓存淘汰策略(配置文件中可以修改)。持续一段时间后，redis的数据就是热点数据了。
3、缓存淘汰策略
（1）volatile-lru：当redis容量达到上限后，在设置了过期时间的key中，根据最后一次使用时间算法进行淘汰，淘汰最久未使用的。
（2）allkeys-lru：当redis容量达到上限后，在所有key中，根据最后一次使用时间算法进行淘汰，淘汰最久未使用的。
（3）volatile-lfu：当redis容量达到上限后，在设置了过期时间的key中，根据最近一段时间访问次数算法进行淘汰，淘汰访问次数最少的。
（4）allkeys-lfu：当redis容量达到上限后，在所有key中，根据最近一段时间访问次数算法进行淘汰，淘汰访问次数最少的。
（5）volatile-random：当redis容量达到上限后，在设置了过期时间的key中，随机淘汰key。
（6）allkeys-random：当redis容量达到上限后，在所有key中，随机淘汰key。
（7）volatile-ttl：当redis容量达到上限后，在设置了过期时间的key中，越早过期的优先被淘汰。
（8）noeviction：默认策略，当redis容量达到上限后，新写入操作会报错。
4、缓存存在的问题
（1）缓存预热
①问题描述
刚开始启动redis或redis宕机时，此时redis上没有数据，全部请求都会发送到数据库，会给数据库带来压力。
②产生原因
redis上没有热点数据。
③解决方法
提前将热点数据准备好写入reids中。
（2）缓存雪崩
①问题描述
短时间内，redis上的大量key失效，导致数据库压力剧增。
②产生原因
redis宕机或者大量key同时达到过期时间。
③解决方法
部署高可用的redis集群或者对key不设置过期时间。
（3）缓存穿透
①问题描述
对于一些key，redis和数据库中都没有，但一直持续访问数据库获取结果，会给数据库带来压力。
②产生原因
业务设计不合理，比如缺失校验环节，导致非法key持续查询；错误操作导致数据库数据被误删；
③解决方法
针对要查询的key，检验key是否合法；使用布隆过滤器先判断key是否存在，再真正进行查询。
（4）缓存击穿
①问题描述
一些热点数据在redis上过期失效了，导致数据库压力骤增。
②产生原因
热点数据过期失效。
③解决方法
对于热点数据不设置过期时间；服务降级，限制同时请求数据库的并发数。
十、redis典型应用--分布式锁
1、分布式锁的作用
在一个分布式系统中，会涉及到多个redis服务器访问同一个公共资源的情况，此时就需要加锁来避免出现线程安全类似的问题。
但此时加锁有个问题，java的synchronized锁是针对于同一个进程的不同线程加锁，而分布式系统中，一个服务器就代表一个进程，此时就需要分布式锁来实现进程间的加锁。
2、分布式锁的原理
使用redis实现分布式锁。
对于多个服务器实现买票来说：A服务器需要实现买票请求，就在redis中使用setnx创建一个指定的key，相当于加锁。此时若B服务器也想实现买票请求，当在redis中操作setnx时，key已经存在，此时就会设置失败，B服务器是阻塞还是放弃自行决定；当A服务器实现买票请求后，进行delete操作删除key，相当于释放锁，此时其他服务器就可以进行加锁实现买票请求了。
3、分布式锁存在的问题
（1）锁未释放
①问题描述
在上述中，A服务器在买票过程中，此时A服务器突然挂掉了，但key没有删掉(未释放锁)，其他服务器也无法设置key(加锁)。
②问题解决
给key设置过期时间，若超过规定时间，则key就会失效(锁释放)。但若超过规定时间，加锁下的操作还未完成，此时释放锁就会出现问题。但也不能将过期时间设置太长，会影响其他服务器加锁操作。此时我们就可以考虑设置动态过期时间。
动态过期时间：刚开始设置一个过期时间(比如1s)，当key的过期时间快到达1s时，加锁下的操作还未完成，就使得key再增加1s，一直重复操作，直到加锁下的操作完成，就可以不再增加过期时间了。此时即使服务器挂掉了，过期时间不会增加，到达过期时间就会删除key。对于上述key的过期时间有专门的线程进行管理--看门狗。
（2）加锁解锁不是同一个服务器操作
①问题描述
在上述中，A服务器进行加锁后，B服务器又紧接着进行了解锁，此时可能会出现类似线程安全问题。
②问题解决
在加锁时引入校验机制。
每个服务器都有自己的身份编号，A服务器在redis中进行setnx时，value值填入自己的身份编号，此时B服务器若想删除该key，就需要获取key对应的value值，value值和自己身份编号相同才能删除，不相同则不能删除。
（3）删除key(释放锁)不是原子的
①问题描述
服务器在释放锁时需要先查询，再删除，两步操作不是原子的，存在问题。
②问题解决
为了使解锁操作具有原子性，可以使用redis的lua脚本。
lua也是一个编程语言，lua语言实现的一段逻辑，可以被原子的执行。此时就可以使用lua语言实现key删除逻辑，并将代码编写成一个.lua后缀的文件，后续执行key删除时，就可以使redis服务器执行该lua脚本，使得删除key是原子操作的。
lua语言编写的删除功能：
（4）redis挂掉了
①问题描述
在使用redis实现分布式锁时，也可能会出现redis挂掉的情况。
②问题解决
引入更多的redis节点作为备份，加锁时，给redis节点加锁成功的个数超过redis总节点数的一半时，此时才会加锁成功；其他服务器想加锁，就需要遍历全部redis节点判断是否存在key。释放锁时，也需要遍历全部redis节点删除key。(redlock算法)