微信电影网站怎么做,找人做网站维护多少钱,哈尔滨手机建站模板,网站建设牜金手指花总十四目录
一、解决redis服务器端口问题
二、java环境下使用redis
三、javaSpringt环境下使用redis
四、redis持久化
1、持久化概念
2、redis持久化策略
3、RDB策略
4、AOF策略
5、混合持久化策略
五、redis事务
1、数据库事务
2、redis事务特点
3、redis事务的作用
4…目录
一、解决redis服务器端口问题
二、java环境下使用redis
三、javaSpringt环境下使用redis
四、redis持久化
1、持久化概念
2、redis持久化策略
3、RDB策略
4、AOF策略
5、混合持久化策略
五、redis事务
1、数据库事务
2、redis事务特点
3、redis事务的作用
4、redis事务操作
六、主从复制
1、主从模式
2、主从复制
七、哨兵
1、哨兵的作用
2、哨兵原理
3、基于docker搭建redis哨兵环境
4、查看哨兵效果
八、集群
1、集群概念
2、集群的作用
3、集群原理
4、数据分片算法
5、基于docker搭建redis集群
6、集群效果
7、集群扩容
九、redis典型应用--缓存
1、实现过程
2、热点数据
3、缓存淘汰策略
4、缓存存在的问题
十、redis典型应用--分布式锁
1、分布式锁的作用
2、分布式锁的原理
3、分布式锁存在的问题
一、解决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命令一样)
1get和set 2mget和mset 3incr和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文件并获取对应的错误报告。
3RDB策略的优缺点
优点rdb是二进制文件加载rdb恢复数据较快。
缺点rdb策略不能实时更新数据到rdb文件若此时redis服务器挂了且内存中最新的数据还未更新到rdb文件中此时这部分数据就丢失了创建子进程进行全量数据保存属于重量级操作频繁执行成本过高。
4、AOF策略
1实现原理
AOF是实时进行持久化的重启redis时执行AOF文件中的命令达到恢复数据的目的。 所有的写入命令会追加到aof缓存区中根据缓存区的刷新策略将数据更新到硬盘中(AOF文件)随着AOF文件越来越大需要定期对AOF文件进行重写达到压缩目的。当redis服务器进行重启时可以加载AOF文件进行数据恢复。
2AOF文件
首先需要开启aof当开启aof时rdb就不再生效了redis服务器重启时就不读取rdb文件了。
进入配置文件开启aof 写入键值对查看aof文件(路径和rdb一样) 3刷新策略
前面提到所有的写入命令会先放到aof缓冲区中根据刷新策略再将数据更新到硬盘中从而减少了操作硬盘的次数提高效率。
刷新策略在配置文件中 always命令写入缓冲区就向硬盘中写入写入频率最高数据可靠性最高性能最低
everysec同步线程每秒刷新一次缓冲区的数据到硬盘中写入频率较低数据可靠性较低性能较高
noredis不会主动刷新缓冲区数据到硬盘中而是直接交给操作系统去判断写入频率最低数据可靠性最低性能最高。
4AOF文件重写
前面提到当aof文件越来越大时需要定期对aof文件进行重写达到压缩的目的。
例如set key1 111; set key2 222; set key1 222;
最后的结果应该只有两条但如果不重写aof会保存3条数据此时就要求要定期对aof文件进行重写压缩文件。
aof文件重写原理 psfork之后的写入命令还需要写到缓冲区和旧aof文件是为了防止新aof文件突然挂了此时aof文件就没有fork之后的数据了数据不准确。
5AOF策略优缺点
优点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事务操作
1multi
开启一个事务执行成功返回ok。后面的每个命令会先放在客户端队列里。
2exec
执行一个事务。
3discard
放弃当前事务清空队列。 4watch
在执行事务时假设客户端1先修改了key1的值为100然后客户端2修改了key1的值为200按照时间先后顺序key1的值应为200但若exec命令是在客户端2之后此时key1的值就为100了此时这种情况就会造成歧义。
使用watch命令监督某个key若在执行事务时其他客户端修改了该key真正提交事务时服务器会发现监督的key版本号已经超过了事务开始时的版本号就会让事务执行失败所有命令都不执行。 5unwatch
取消对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时此时为全量复制
9psync运行流程 ①初次复制从节点发生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的镜像 5docker-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、缓存淘汰策略
1volatile-lru当redis容量达到上限后在设置了过期时间的key中根据最后一次使用时间算法进行淘汰淘汰最久未使用的。
2allkeys-lru当redis容量达到上限后在所有key中根据最后一次使用时间算法进行淘汰淘汰最久未使用的。
3volatile-lfu当redis容量达到上限后在设置了过期时间的key中根据最近一段时间访问次数算法进行淘汰淘汰访问次数最少的。
4allkeys-lfu当redis容量达到上限后在所有key中根据最近一段时间访问次数算法进行淘汰淘汰访问次数最少的。
5volatile-random当redis容量达到上限后在设置了过期时间的key中随机淘汰key。
6allkeys-random当redis容量达到上限后在所有key中随机淘汰key。
7volatile-ttl当redis容量达到上限后在设置了过期时间的key中越早过期的优先被淘汰。
8noeviction默认策略当redis容量达到上限后新写入操作会报错。
4、缓存存在的问题
1缓存预热
①问题描述
刚开始启动redis或redis宕机时此时redis上没有数据全部请求都会发送到数据库会给数据库带来压力。
②产生原因
redis上没有热点数据。
③解决方法
提前将热点数据准备好写入reids中。
2缓存雪崩
①问题描述
短时间内redis上的大量key失效导致数据库压力剧增。
②产生原因
redis宕机或者大量key同时达到过期时间。
③解决方法
部署高可用的redis集群或者对key不设置过期时间。
3缓存穿透
①问题描述
对于一些keyredis和数据库中都没有但一直持续访问数据库获取结果会给数据库带来压力。
②产生原因
业务设计不合理比如缺失校验环节导致非法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语言编写的删除功能 4redis挂掉了
①问题描述
在使用redis实现分布式锁时也可能会出现redis挂掉的情况。
②问题解决
引入更多的redis节点作为备份加锁时给redis节点加锁成功的个数超过redis总节点数的一半时此时才会加锁成功其他服务器想加锁就需要遍历全部redis节点判断是否存在key。释放锁时也需要遍历全部redis节点删除key。(redlock算法)
