Redis学习笔记
Redis
记录笔记。
简介
Redis是一个开源的key-value存储系统。
和Memcached类似,它支持存储的value类型相对更多,包括string(字符串)、list(链表)、set(集合)、zset(sorted set —有序集合)和hash(哈希类型)。
这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作,而且这些操作都是原子性的。
在此基础上,Redis支持各种不同方式的排序。
与memcached一样,为了保证效率,数据都是缓存在内存中。
区别的是Redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件。
并且在此基础上实现了master-slave(主从)同步。
安装Redis
已Redis6.2.10为例
- 检查gcc环境
gcc --version
- 安装gcc:
yum install gcc
- 安装gcc:
安装步骤:
- 下载
redis-6.2.10.tar.gz
到/opt (其它目录也行) - 执行
tar -zxvf redis-6.2.10.tar.gz
解压 - 进入redis-6.2.10/
cd redis-6.2.10/
- 执行编译
make
- 若出现错误:
make distclean
清除编译结果 - 再次执行
make
- 若出现错误:
- 执行安装
make install
,默认安装在/usr/local/bin/- 使用
make install PREFIX=/usr/local/redis
指定安装目录到/usr/local/redis
- 使用
查看默认安装目录:
- redis-benchmark:性能测试工具,可以在自己本子运行,看看自己本子性能如何
- redis-check-aof :修复有问题的 AOF 文件
- redis-check-dump:修复有问题的 dump.rdb 文件
- redis-sentinel : Redis 集群使用
- redis-server : Redis服务器启动命令
- redis-cli: 客户端,操作入口
前台启动:redis-server
后台启动:
- 复制redis.conf到/etc/ :
cp /opt/redis-6.2.10/redis.conf /etc/
- 编辑/etc/redis.conf
vim /etc/redis.conf
- 修改
daemonize no
为daemonize yes
- 修改
- 执行
redis-server /etc/redis.conf
启动Redis redis-cli
进入Redis后台,输入ping
测试启动状态
使用Screen窗口进行后台运行:
- 安装Screen:
yum install screen
- 创建或进入一个screen:
screen -R <名称>
- 进入Screen后执行
redis-server
Ctrl + A + D
退出screen
五大常用数据类型
Redis键
“键值对”
keys *
查看当前库所有key (匹配:keys *1)
exists <key>
判断某个key是否存在
type <key>
查看你的key是什么类型
del <key>
删除指定的key数据
unlink <key>
根据value选择非阻塞删除,仅将keys从keyspace元数据中删除,真正的删除会在后续异步操作。
expire <key> <s>
为给定的key设置过期时间(单位秒)
ttl <key>
查看还有多少秒过期,-1表示永不过期,-2表示已过期
select <db>
命令切换数据库
- 默认16个数据库,类似数组下标从0开始,初始默认使用0号库
dbsize
查看当前数据库的key的数量
flushdb
清空当前库
flushall
通杀全部库
Redis字符串
简介
String类型是二进制安全的。意味着Redis的string可以包含任何数据。比如jpg图片或者序列化的对象。
String类型是Redis最基本的数据类型,一个Redis中字符串value最多可以是512M
常用命令
set <key> <value>
添加键值对
setnx
当数据库中key不存在时,可以将key-value添加数据库setxx
当数据库中key存在时,可以将key-value添加数据库,与NX参数互斥setex
key的超时秒数setpx
key的超时毫秒数,与EX互斥
get <key>
查询对应键值
append <key> <value>
将给定的
strlen <key>
获得值的长度
以下命令是具有原子性的:
incr <key>
将 key 中储存的数字值增1,只能对数字值操作,如果为空,新增值为1decr <key>
将 key 中储存的数字值减1,只能对数字值操作,如果为空,新增值为-1incrby / decrby <key> <步长>
将 key 中储存的数字值增减。自定义步长。mset <key1><value1><key2><value2> ...
同时设置一个或多个 key-value对mget <key1><key2><key3> ...
同时获取一个或多个 valuemsetnx <key1><value1><key2><value2> ...
同时设置一个或多个 key-value 对,当且仅当所有给定 key 都不存在。
getrange <key> <起始位置> <结束位置>
获得值的范围,类似java中的substring,前包,后包
setrange <key> <起始位置> <value>
用
setex <key> <过期时间> <value>
设置键值的同时,设置过期时间,单位秒。
getset <key> <value>
以新换旧,设置了新值同时获得旧值。
数据结构
String的数据结构为简单动态字符串(Simple Dynamic String,缩写SDS)。是可以修改的字符串,内部结构实现上类似于Java的ArrayList,采用预分配冗余空间的方式来减少内存的频繁分配.
内部为当前字符串实际分配的空间capacity一般要高于实际字符串长度len。当字符串长度小于1M时,扩容都是加倍现有的空间,如果超过1M,扩容时一次只会多扩1M的空间。需要注意的是字符串最大长度为512M。
Redis列表
简介
“单键多值”
它的底层实际是个双向链表,对两端的操作性能很高,通过索引下标的操作中间的节点性能会较差。
可以进行“头插”或“尾插”。
graph LR v1 --> v2 --> v1 v2 --> v3 --> v2 v3 --> v4 --> v3 v4 --> v5 --> v4
常用命令
lpush/rpush <key><value1><value2><value3> ....
从左边/右边插入一个或多个值。
lpop/rpop <key>
从左边/右边吐出一个值。有值才有键。
rpoplpush <key1> <key2>
从
lrange <key> <start> <stop>
按照索引下标获得元素(从左到右)
lrange <key> 0 -1
查看list的全部值
lindex <key> <index>
按照索引下标获得元素(从左到右)
llen <key>
获得列表长度
linsert <key> before <value> <newvalue>
在
lrem <key> <n> <value>
从左边删除n个value(从左到右)
lset <key> <index> <value>
将列表key下标为index的值替换成value
数据结构
”快速链表quickList“
首先在列表元素较少的情况下会使用一块连续的内存存储,这个结构是ziplist,也即是压缩列表。它将所有的元素紧挨着一起存储,分配的是一块连续的内存。
当数据量比较多的时候才会改成quicklist。
因为普通的链表需要的附加指针空间太大,会比较浪费空间。比如一个列表里存的只是int类型的数据,结构上还需要两个额外的指针prev和next。
graph LR v1[zipList] --> v2[zipList] --> v1 v2 --> v3[zipList] --> v2 v3 --> v4[zipList] --> v3 v4 --> v5[zipList] --> v4
Redis将链表和ziplist结合起来组成了quicklist。也就是将多个ziplist使用双向指针串起来使用。这样既满足了快速的插入删除性能,又不会出现太大的空间冗余。
Redis集合
简介
Redis set对外提供的功能与list类似是一个列表的功能,特殊之处在于set是可以自动排重的。
Redis的Set是string类型的无序集合。它底层其实是一个value为null的hash表,所以添加,删除,查找的复杂度都是O(1)。
常用命令
sadd <key> <value1> <value2> ...
添加一或多个值到集合中,并忽略已存在的值`smembers <key>
取出该集合的所有值。sismember <key> <value>
判断集合是否含有某个值,是1,否0scard <key>
返回该集合的元素个数。srem <key> <value1> <value2> ...
删除集合中的某个元素。spop <key>
随机从该集合中吐出一个值。srandmember <key> <n>
随机从该集合中取出n个值。不会从集合中删除 。smove <source> <dest> <value>
移动集合中的某个值到另一个集合sinter <key1> <key2>
返回两个集合的交集元素。sunion <key1> <key2>
返回两个集合的并集元素。sdiff <key1> <key2>
返回两个集合的差集元素(key1中的,不包含key2中的)
数据结构
Set数据结构是dict字典,字典是用哈希表实现的。
Java中HashSet的内部实现使用的是HashMap,只不过所有的value都指向同一个对象。Redis的set结构也是一样,它的内部也使用hash结构,所有的value都指向同一个内部值。
Redis哈希
简介
Redis hash 是一个键值对集合。
Redis hash是一个string类型的field和value的映射表,hash特别适合用于存储对象。
类似Java里面的Map
flowchart LR key ==> sg subgraph sg[ ] field1 --> value1 field2 --> value2 field3 --> value3 end
常用命令
hset <key> <field> <value>
给集合中的 键赋值 hget <key1> <field>
从集合 取出 value hmset <key1> <field1> <value1> <field2> <value2>...
批量设置值hexists <key> <field>
查看哈希表中,给定域 field 是否存在。hkeys <key>
列出该hash集合的所有fieldhvals <key>
列出该hash集合的所有valuehincrby <key> <field> <incr>
为哈希表中的域的值加上增量1(可以是负数)hsetnx <key> <field> <value>
将哈希表 key 中的域 field 的值设置为 value ,当且仅当域 field 不存在
数据结构
Hash类型对应的数据结构是两种:ziplist(压缩列表),hashtable(哈希表)。当field-value长度较短且个数较少时,使用zipList,否则使用hashTable。
Redis有序集合Zset(Sorted Set)
简介
Zset拥有Set的特性。
Zset是有序集合,每个元素关联一个”分数(score)“(分数可以重复,也叫权重),按评分从高到低排序。
常用命令
zadd <key> <score1> <value1> <score2> <value2> …
将一或多个元素及其 score 值加入到有序集 key 当中。zrange <key> <start> <stop> [withscores]
返回有序集 key 中,下标在之间的元素 - 带withscores,可以让分数一起和值返回到结果集。
zrangebyscore <key> <min> <max> [withscores] [limit offset count]
返回有序集 key 中,所有 score 值介于 min 和 max 之间(包括等于 min 或 max )的成员。有序集成员按 score 值递增(从小到大)次序排列。zrevrangebyscore key maxmin [withscores] [limit offset count]
同上,改为从大到小排列。zincrby <key> <incr> <value>
为元素的score加上增量zrem <key> <value>
删除该集合下,指定值的元素zcount <key> <min> <max>
统计该集合,分数区间内的元素个数zrank <key> <value>
返回该值在集合中的排名,从0开始。
数据结构
Zset底层使用了两个数据结构
- hash,hash的作用就是关联元素value和权重score,保障元素value的唯一性,可以通过元素value找到相应的score值。
- 跳跃表,跳跃表的目的在于给元素value排序,根据score的范围获取元素列表。
配置文件
1 | # redis.conf |
其余配置选项会在下文陆续提到。
Redis发布和订阅
Redis 发布订阅 (pub/sub) 是一种消息通信模式:发送者 (pub) 发送消息,订阅者 (sub) 接收消息。
Redis 客户端可以订阅任意数量的频道。
订阅和发布
客户端可以订阅频道如下图
graph BT ch[channel1 频道] a([客户端A]) --订阅--> ch b([客户端B]) --订阅--> ch c([客户端C]) --订阅--> ch
当给这个频道发布消息后,消息就会发送给订阅的客户端
graph TB pb[PUBLISH channel1 hello] pb --> ch[channel1 频道] ch --hello--> a([客户端A]) ch --hello--> b([客户端B]) ch --hello--> c([客户端C])
发布订阅命令
subscribe <channel>
订阅频道
publish <channel> <msg>
发布信息,返回订阅者数量
发布订阅过程自动创建频道
发布的消息没有持久化,如果在订阅的客户端收不到hello,只能收到订阅后发布的消息
Redis新数据类型
Bitmaps
简介
Redis提供了Bitmaps这个“数据类型”可以实现对位的操作:
(1) Bitmaps本身不是一种数据类型, 实际上它就是字符串(key-value) , 但是它可以对字符串的位进行操作。
(2) Bitmaps单独提供了一套命令, 所以在Redis中使用Bitmaps和使用字符串的方法不太相同。 可以把Bitmaps想象成一个以位为单位的数组, 数组的每个单元只能存储0和1, 数组的下标在Bitmaps中叫做偏移量。
常用命令
setbit <key> <offset> <value>
设置Bitmaps中某个偏移量的值(0或1)
getbit <key> <offset>
获取Bitmaps中某个偏移量的值
bitcount<key> [start] [end]
统计字符串从start字节到end字节bit为1的数量
bitop <and|or|not|xor> <destkey> [key…]
bitop是一个复合操作, 它可以做多个Bitmaps的and(交集) 、 or(并集) 、 not(非) 、 xor(异或) 操作并将结果保存在destkey中。
HyperLogLog
简介
Redis HyperLogLog 是用来做基数统计的算法,HyperLogLog 的优点是,在输入元素的数量或者体积非常非常大时,计算基数所需的空间总是固定的、并且是很小的。
在 Redis 里面,每个 HyperLogLog 键只需要花费 12 KB 内存,就可以计算接近 2^64 个不同元素的基数。这和计算基数时,元素越多耗费内存就越多的集合形成鲜明对比。
但是,因为 HyperLogLog 只会根据输入元素来计算基数,而不会储存输入元素本身,所以 HyperLogLog 不能像集合那样,返回输入的各个元素。
常用命令
pfadd <key> <element> [element...]
添加指定元素到 HyperLogLog 中
- 如果执行命令后HLL估计的近似基数发生变化,则返回1,否则返回0。
pfcount <key> [key...]
计算HLL的近似基数,可以计算多个HLL,比如用HLL存储每天的UV,计算一周的UV可以使用7天的UV合并计算即可
pfmerge <destkey> <sourcekey> [sourcekey...]
将一个或多个HLL合并后的结果存储在另一个HLL中,比如每月活跃用户可以使用每天的活跃用户来合并计算可得
Geosptial
简介
Redis 3.2 中增加了对GEO类型的支持。GEO,Geographic,地理信息的缩写。该类型,就是元素的2维坐标,在地图上就是经纬度。
redis基于该类型,提供了经纬度设置,查询,范围查询,距离查询,经纬度Hash等常见操作。
常用命令
geoadd <key> <longitude> <latitude> <member> [longitude latitude member...]
添加地理位置(经度,纬度,名称)
geopos <key> <member> [member...]
获得指定地区的坐标值
geodist <key> <member1> <member2> [m|km|ft|mi]
获取两个位置之间的直线距离
georadius <key> <longitude> <latitude> <radius> [m|km|ft|mi]
以给定的经纬度为中心,找出某一半径内的元素
Jedis
jedis
Jedis和Lettuce比较
Redis整合SpringBoot
引入依赖项
1 | <dependency> |
注:Spring2.X集成redis所需common-pool2
自定义配置类
自定义Bean的原因是使数据能够正常序列化和反序列化存取Redis。
1 |
|
注:在序列化后value会多了双引号,但是不影响反序列化成String或其它类型。将Value和HashValue的Serializer设置为stringRedisSerializer可以解决双引号问题,但是将不能缓存实体类(序列化会报错)。
配置properties
application.properties
1 | #Redis服务器地址 |
application.yaml
1 | spring: |
事务和锁机制
事务的定义
Redis事务是一个单独的隔离操作:事务中的所有命令都会序列化、按 顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。
Redis事务的主要作用就是串联多个命令防止别的命令插队。
multi、exec和discard
multi
开启事务,进入命令组队
exec
执行命令队列
discard
放弃事务组队
1 | multi exec |
事务的错误处理
与MySQL事务错误处理方式不同。
- 组队阶段出现错误,全部退出组队。
- 执行阶段出现错误,其它命令正常执行。
watch和unwatch
watch <key> [key ...]
- 在执行multi之前,先执行watch可以监视一个(或多个) key ,如果在事务执行之前这个(或这些) key 被其他命令所改动,那么事务将被打断。
unwatch
- 取消 watch 命令对所有 key 的监视。
- 如果在执行 watch 命令之后,exec 命令或discard命令先被执行了的话,那么就不需要再执行unwatch了。
乐观锁
简介
乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。
粗略解释:我可以把东西取出来修改(但是这个东西还在),但是放回去的时候必须和取出来的时候的版本一致,不然就修改失败。
实现
利用watch监听key的值变化可以打断事务组队的作用实现Redis乐观锁
1 | public void optimisticLock() { |
悲观锁
简介
悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。
粗略解释:我把东西取出来修改(这个东西不在了),在放回去之前,其他人都不能修改这个东西。
实现
方式一:setnx实现
1 | public void pessimisticLock_setnx() { |
方式二:Lua脚本(推荐)
Redis在2.6推出了脚本功能,允许开发者使用Lua语言编写脚本传到Redis中执行。使用脚本的好处如下:
- 减少网络开销:将复杂的或者多步的redis操作,写为一个脚本,一次提交给redis执行,减少反复连接redis的次数。提升性能。
- 原子操作:Redis会将整个脚本作为一个整体执行,中间不会被其他命令插入,有一定的原子性。(java等客户端则会执行多次命令完成一个业务,违反了原子性操作)。
- 复用:客户端发送的脚本会永久存储在Redis中,意味着其他客户端可以复用这一脚本而不需要使用代码完成同样的逻辑。
1 | private final String script = |
Redis事务三特性
单独的隔离操作
- 事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。
没有隔离级别的概念
- 队列中的命令没有提交之前都不会实际被执行,因为事务提交前任何指令都不会被实际执行
不保证原子性
- 事务中如果有一条命令执行失败,其后的命令仍然会被执行,没有回滚
持久化操作
将Redis内存中的数据储存到硬盘。
持久化方式:
- RDB
- AOF
当RDB和AOF同时开启时,Redis默认使用AOF。
RDB
简介
在指定的时间间隔内将内存中的数据集快照写入磁盘, 也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。
流程
graph LR bgsave --1--> p[父进程] --2--> fork -- 3 --> o[响应其它命令] fork --> c[子进程] --4--> rdb[生成RDB文件] c --5通知父进程--> p p --> r([有其它子进程正在执行直接返回])
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到 一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。 整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能 如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
配置文件
1 | ### SNAPSHOTTING ### |
开启rdb备份后,在redis开启的时候会加载dump.rdb文件内容到内存中。
动态停止:redis-cli config set save ""
save和bgsave命令
save: 保存是阻塞主进程,客户端无法连接redis,等SAVE完成后,主进程才开始工作,客户端可以连接。
bgsave: 是fork一个save的子进程,在执行save过程中,不影响主进程,客户端可以正常链接redis,等子进程fork执行save完成后,通知主进程,子进程关闭。
优缺点
优点:
适合大规模的数据恢复
对数据完整性和一致性要求不高更适合使用
节省磁盘空间
恢复速度快
缺点:
- Fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑
- 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
- 在备份周期在一定间隔时间做一次备份,所以如果Redis意外down掉的话,就会丢失最后一次快照后的所有修改。
AOF
简介
以日志的形式来记录每个写操作(增量保存),将Redis执行过的所有写指令记录下来(读操作不记录), 只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
流程
graph TD write[命令写入] -- 1 append--> aof_buffer[AOF缓冲] -- 2 sync --> aof_file[AOF文件] -- 4 load --> reboot[重启] aof_file --3 rewrite --> aof_file
- 客户端的请求写命令会被append追加到AOF缓冲区内;
- AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中;
- AOF文件大小超过重写策略或手动重写时,会对AOF文件rewrite重写,压缩AOF文件容量;
- Redis服务重启时,会重新load加载AOF文件中的写操作达到数据恢复的目的;
配置文件
1 | ### APPEND ONLY MODE ### |
Rewrite流程
- bgrewriteaof触发重写,判断是否当前有bgsave或bgrewriteaof在运行,如果有,则等待该命令结束后再继续执行。
- 主进程fork出子进程执行重写操作,保证主进程不会阻塞。
- 子进程遍历redis内存中数据到临时文件,客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
- 子进程写完新的AOF文件后,向主进程发信号,父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
- 使用新的AOF文件覆盖旧的AOF文件,完成AOF重写。
优缺点
优点:
- 备份机制更稳健,丢失数据概率更低。
- 可读的日志文本,通过操作AOF稳健,可以处理误操作。
缺点:
- 比起RDB占用更多的磁盘空间。
- 恢复备份速度要慢。
- 每次读写都同步的话,有一定的性能压力。
- 存在个别Bug,造成恢复不能。
主从复制
相关内容
master主服务器,slave从服务器
读写分离,性能扩展
容灾快速恢复
flowchart app([应用]) -- 写 --> z[主] app -- 读 --> c1[从] app -- 读 --> c2[从] app -- 读 --> c3[从] z -- 复制 --> c1 z -- 复制 --> c2 z -- 复制 --> c3
注:从服务器可以拥有自己的从服务器,且数据依次传递。
相关Redis命令:
info replication
查看主从复制相关信息slaveof <ip> <port>
成为某个实例的从服务器slaveof no one
自己成为主服务器重启Redis失效,写入配置文件即可永久
主从读写情况:
服务器成为从服务器后会同步主服务器的数据
主服务器可以读写,写入操作后会从服务器会同步
- 从服务器只能进行读操作
主从掉线情况:
- 主服务器掉线:从服务器不变,等待主服务器上线
- 从服务器掉线:主服务器的从服务器数量减少,从服务器上线后slaveof即可
若主服务器有设置requirepass
则从服务器必须设置masterauth
。
主从复制原理
某服务器成为从服务器后会向主服务器发送数据同步请求(sync命令),主服务器启动后台程序将数据写入文件(RDB文件),然后文件给从服务器。(全量复制)
主服务器写入操作后会发送相同命令给从服务器进行同步(增量复制)
哨兵模式
哨兵模式(Sentinel),能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库。
命令:redis-sentinel <sentinel.conf>
编写sentinel.conf
1 | # 格式sentinel monitor <哨兵监控的服务器名称> <ip> <port> <同意迁移主服务器的最小哨兵数量> |
当主服务器故障了,会征求其它哨兵意见认为它是否故障,之后会征求其它哨兵意见选举新的主服务器。
选举新服务器条件:
- 优先级高的
- 偏移量最大的(拥有主服务器数据最全的)
- runid最小的
选举之后旧主服务器会放过来成为新主服务器的从服务器。
1 | # redis.conf |
集群
Redis 集群实现了对Redis的水平扩容,即启动N个redis节点,将整个数据库分布存储在这N个节点中,每个节点存储总数据的1/N。
Redis 集群通过分区(partition)来提供一定程度的可用性(availability): 即使集群中有一部分节点失效或者无法进行通讯, 集群也可以继续处理命令请求。
配置文件
1 | ### REDIS CLUSTER ### |
开启集群
进入编译好的解压的redis目录cd /opt/redis-6.2.10/src
执行以下命令,ip请使用真实ip
1 | redis-cli --cluster create --cluster-replicas 1 192.168.245.128:6379 192.168.245.128:6380 192.168.245.128:6381 192.168.245.128:6389 192.168.245.128:6390 192.168.245.128:6391 |
--replicas 1
采用最简单的方式配置集群,一台主机,一台从机。
-u
账号
-a
密码
redis-cli -c -p xxxx
进入集群客户端
-a xxx
登录密码
cluster nodes
查看集群节点信息
一个集群至少要有三个主节点。
选项 —cluster-replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。
分配原则尽量保证每个主数据库运行在不同的IP地址,每个从库和主库不在一个IP地址上。
slots
一个 Redis 集群包含 16384 个插槽(hash slot), 数据库中的每个键都属于这 16384 个插槽的其中一个,集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽, 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。
集群中的每个节点负责处理一部分插槽。
在集群中录入数据:
每次录入、查询、Redis都会计算该key属于哪个插槽,并重定向到对应节点进行操作。
不在一个slot下的键值,是不能使用mget,mset等多键批量操作。
- 可以使用{}对键进行分组,从而相同组的键值会被放入相同slot中。
- 例:
mset k1{group} v1 k2{group} v2
cluster keyslot <key>
计算键 key 应该被放置在哪个槽上。
cluster countkeysinslot <slot>
返回槽 slot 目前包含的键值对数量。
cluster getkeysinslot <slot> <count>
返回 count 个 slot 槽中的键 。
优缺点
优点:
- 实现扩容
- 分摊压力
- 无中心配置相对简单
缺点:
- 多键操作是不被支持的
- 多键的Redis事务是不被支持的。lua脚本不被支持
缓存穿透
key对应的数据在数据源并不存在,每次针对此key的请求从缓存获取不到,请求都会压到数据源,从而可能压垮数据源。比如用一个不存在的用户id获取用户信息,不论缓存还是数据库都没有,若黑客利用此漏洞进行攻击可能压垮数据库。
缓存击穿
key对应的数据存在,但在redis中过期,此时若有大量并发请求过来,这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存,这个时候大并发的请求可能会瞬间把后端DB压垮。
缓存雪崩
key对应的数据存在,但在redis中大量过期,此时若有大量并发请求过来,这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存,这个时候大并发的请求可能会瞬间把后端DB压垮。
缓存雪崩与缓存击穿的区别在于这里针对很多key缓存,前者则是某一个key
正常访问
分布式锁
setnx实现
1 | public void pessimisticLock_setnx() { |
Redisson
引入依赖
1 | <!-- https://mvnrepository.com/artifact/org.redisson/redisson-spring-boot-starter --> |
配置
方式一
直接使用application.yml里spring.redis的配置信息。
redisson和redis共用配置。
方式二
直接写在application.yml里:
1 | spring: |
Redisson 分布式锁实战与 watch dog 机制解读 - 上帝爱吃苹果-Soochow - 博客园 (cnblogs.com)
ACL
acl list