作用 | 语法 |
---|---|
登陆本地redis | redis-cli 或者 redis-cli -p 6379 或者 redis-cli -p 6379 -a password #-a后面为password,此操作需要开启redis.conf文件中的 requirepass选项 |
登陆远程redis | redis-cli -h ip -p 6379 -a password |
查看redis信息 | info |
清除redis屏幕内容 | clear |
退出redis服务 | exit |
关闭redis服务 | shutdown |
切换数据库 | select (0-15) |
清除当前数据库数据 | flushdb |
清除所有数据库数据 | flushall |
查看redis中的key | keys * |
判断某个key是否存在 | exists key |
查看你的key是什么类型 | type key |
删除指定的key数据 | del key |
根据value选择非阻塞删除 仅将keys从keyspace元数据中删除,真正的删除会在后续异步操作 | unlink key |
10秒钟:为给定的key设置过期时间 | expire key 10 |
清除redis中的数据 | del test1 |
查看当前数据库的key的数量 | dbsize |
查看还有多少秒过期,-1表示永不过期,-2表示已过期 | ttl key |
取消时长设置 | PERSIST key |
作用 | 语法 |
---|---|
添加键值对 | set
|
查询对应键值 | get
|
向尾部追加值 | append
|
返回数据的长度,如果键不存在则返回0 | strlen
|
只有在 key 不存在时 设置 key 的值 | setnx
|
将 key 中储存的数字值增1 只能对数字值操作,如果为空,新增值为1 | incr
|
将 key 中储存的数字值减1 只能对数字值操作,如果为空,新增值为-1 | decr
|
将 key 中储存的数字值增减。自定义步长 | incrby / decrby <步长> |
同时设置一个或多个 key-value对 | mset … |
同时获取一个或多个 value | mget … |
同时设置一个或多个 key-value 对,当且仅当所有给定 key 都不存在。 | msetnx … |
获得值的范围,类似java中的substring,前包,后包 | getrange <起始位置><结束位置> |
用 覆写 所储存的字符串值,从<起始位置>开始(索引从0开始) | setrange <起始位置>
|
设置键值的同时,设置过期时间,单位秒。 | setex <过期时间>
|
以新换旧,设置了新值同时获得旧值。 | getset
|
String的数据结构为简单动态字符串(Simple Dynamic String,缩写SDS)。是可以修改的字符串,内部结构实现上类似于Java的ArrayList,采用预分配冗余空间的方式来减少内存的频繁分配.
如图中所示,内部为当前字符串实际分配的空间capacity一般要高于实际字符串长度len。当字符串长度小于1M时,扩容都是加倍现有的空间,如果超过1M,扩容时一次只会多扩1M的空间。需要注意的是字符串最大长度为512M。
作用 | 语法 |
---|---|
从左边/右边插入一个或多个值 | lpush/rpush … |
从左边/右边吐出n个值。值在键在,值光键亡。 | lpop/rpop
|
从 列表右边吐出一个值,插到 列表左边 | rpoplpush
|
按照索引下标获得元素(从左到右) | lrange
|
0左边第一个,-1右边第一个,(0-1表示获取所有) | lrange mylist 0 -1 |
按照索引下标获得元素(从左到右) | lindex
|
获得列表长度 | llen
|
在 的后面插入 插入值 | linsert before
|
从左边删除n个value(从左到右) | lrem
|
将列表key下标为index的值替换成value | set
|
List的数据结构为快速链表quickList。
首先在列表元素较少的情况下会使用一块连续的内存存储,这个结构是ziplist,也即是压缩列表。
它将所有的元素紧挨着一起存储,分配的是一块连续的内存。
当数据量比较多的时候才会改成quicklist。
因为普通的链表需要的附加指针空间太大,会比较浪费空间。比如这个列表里存的只是int类型的数据,结构上还需要两个额外的指针prev和next。
Redis将链表和ziplist结合起来组成了quicklist。也就是将多个ziplist使用双向指针串起来使用。这样既满足了快速的插入删除性能,又不会出现太大的空间冗余。
Redis set对外提供的功能与list类似是一个列表的功能,特殊之处在于set是可以自动排重的,当你需要存储一个列表数据,又不希望出现重复数据时,set是一个很好的选择,并且set提供了判断某个成员是否在一个set集合内的重要接口,这个也是list所不能提供的。
Redis的Set是string类型的无序集合。它底层其实是一个value为null的hash表,所以添加,删除,查找的复杂度都是O(1)。
一个算法,随着数据的增加,执行时间的长短,如果是O(1),数据增加,查找数据的时间不变
作用 | 语法 |
---|---|
将一个或多个 member 元素加入到集合 key 中,已经存在的 member 元素将被忽略 | sadd … |
获取集合中成员 | smembers
|
判断集合 是否为含有该 值,有1,没有0 | sismember
|
删除集合中的某个元素 | srem … |
随机从该集合中吐出一个值 | spop key |
获取集合中的成员个数 | scard
|
随机从该集合中取出n个值。不会从集合中删除 | srandmember
|
把集合中一个值从一个集合移动到另一个集合 | smove value |
返回两个集合的并集元素 | sunion
|
返回两个集合的交集元素 | sinter
|
返回两个集合的差集元素(key1中的,不包含key2中的) | sdiff
|
Set数据结构是dict字典,字典是用哈希表实现的。
Java中HashSet的内部实现使用的是HashMap,只不过所有的value都指向同一个对象。Redis的set结构也是一样,它的内部也使用hash结构,所有的value都指向同一个内部值。
Redis hash 是一个键值对集合。
Redis hash是一个string类型的field和value的映射表,hash特别适合用于存储对象。
类似Java里面的Map
作用 | 语法 |
---|---|
给 集合中的 键赋值
| hset
|
从 集合 取出 value | hget
|
批量设置hash的值 | hmset … |
查看哈希表 key 中,给定域 field 是否存在 | hexists
|
列出该hash集合的所有field | hkeys
|
列出该hash集合的所有value | hvals
|
为哈希表 key 中的域 field 的值加上增量 1 -1 | hincrby
|
将哈希表 key 中的域 的值设置为 ,当且仅当域 不存在 | hsetnx
|
Redis有序集合zset与普通集合set非常相似,是一个没有重复元素的字符串集合。
不同之处是有序集合的每个成员都关联了一个评分(score),这个评分(score)被用来按照从最低分到最高分的方式排序集合中的成员。集合的成员是唯一的,但是评分可以是重复了 。
因为元素是有序的, 所以你也可以很快的根据评分(score)或者次序(position)来获取一个范围的元素。
访问有序集合的中间元素也是非常快的,因此你能够使用有序集合作为一个没有重复成员的智能列表。
作用 | 命令 |
---|---|
将一个或多个 member 元素及其 score 值加入到有序集 key 当中。 | zadd … |
返回有序集 key 中,下标在 之间的元素带WITHSCORES,可以让分数一起和值返回到结果集。 | zrange [WITHSCORES] |
返回有序集 key 中,所有 score 值介于 min 和 max 之间(包括等于 min 或 max )的成员。有序集成员按 score 值递增(从小到大)次序排列 | zrangebyscore key minmax [withscores] [limit offset count] |
同上,改为从大到小排列 | zrevrangebyscore key maxmin [withscores] [limit offset count] |
为元素的score加上增量 | zincrby
|
删除该集合下,指定值的元素 | zrem
|
统计该集合,分数区间内的元素个数 | zcount
|
返回该值在集合中的排名,从0开始 | zrank
|
SortedSet(zset)是Redis提供的一个非常特别的数据结构,一方面它等价于Java的数据结构Map
zset底层使用了两个数据结构
hash,hash的作用就是关联元素value和权重score,保障元素value的唯一性,可以通过元素value找到相应的score值。
跳跃表,跳跃表的目的在于给元素value排序,根据score的范围获取元素列表。
配置大小单位,开头定义了一些基本的度量单位,只支持bytes,不支持bit,大小写不敏感
类似jsp中的include,多实例的情况可以把公用的配置文件提取出来
默认情况bind=127.0.0.1只能接受本机的访问请求
不写的情况下,无限制接受任何ip
生产环境肯定要写你应用服务器的地址;服务器是需要远程访问的,所以需要将其注释掉
如果开启了protected-mode,那么在没有设定bind ip且没有设密码的情况下,Redis只允许接受本机的响应
设置tcp的backlog,backlog其实是一个连接队列,backlog队列总和=未完成三次握手队列 + 已经完成三次握手队列。
在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。
注意Linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值(128),所以需要确认增大/proc/sys/net/core/somaxconn和/proc/sys/net/ipv4/tcp_max_syn_backlog(128)两个值来达到想要的效果
对访问客户端的一种心跳检测,每个n秒检测一次。
单位为秒,如果设置为0,则不会进行Keepalive检测,建议设置成60
是否为后台进程,设置为yes
守护进程,后台启动
指定日志记录级别,Redis总共支持四个级别:debug、verbose、notice、warning,默认为notice
四个级别根据使用阶段来选择,生产环境选择notice 或者warning
命令在连接上指定数据库id设置redis同时可以与多少个客户端进行连接。
默认情况下为10000个客户端。
如果达到了此限制,redismax number of clients reached
设置样本数量,LRU算法和最小TTL算法都并非是精确的算法,而是估算值,所以你可以设置样本的大小,redis默认会检查这么多个key并选择其中LRU的那个。
一般设置3到7的数字,数值越小样本越不准确,但性能消耗越小。
Redis提供了Bitmaps这个“数据类型”可以实现对位的操作:
Bitmaps本身不是一种数据类型, 实际上它就是字符串(key-value) , 但是它可以对字符串的位进行操作。
Bitmaps单独提供了一套命令,所以在中使用和使用字符串的方法不太相同。可以把想象成一个以位为单位的数组,数组的每个单元只能存储0和1,数组的下标在中叫做偏移量
作用 | 语法 |
---|---|
设置Bitmaps中某个偏移量的值(0或1) | setbit |
获取Bitmaps中某个偏移量的值 | getbit |
统计字符串被设置为1的bit数 额外的 start 或 end 参数,可以让计数只在特定的位上进行 | bitcount |
bitop是一个复合操作, 它可以做多个Bitmaps的and(交集) 、 or(并集) 、 not(非) 、 xor(异或) 操作并将结果保存在destkey中 | bitop and(or/not/xor) [key…] |
在工作当中,我们经常会遇到与统计相关的功能需求,比如统计网站PV(PageView页面访问量),可以使用Redis的incr、incrby轻松实现。但像UV(UniqueVisitor,独立访客)、独立IP数、搜索记录数等需要去重和计数的问题如何解决?这种求集合中不重复元素个数的问题称为基数问题。
作用 | 语法 |
---|---|
添加指定元素到 HyperLogLog中 | pfadd < element> [element …] |
计算HLL的近似基数,可以计算多个HLL,比如用HLL存储每天的UV,计算一周的UV可以使用7天的UV合并计算即可 | pfcount [key …] |
将一个或多个HLL合并后的结果存储在另一个HLL中,比如每月活跃用户可以使用每天的活跃用户来合并计算可得 | pfmerge [sourcekey …] |
Redis 3.2 中增加了对GEO类型的支持。GEO,Geographic,地理信息的缩写。该类型,就是元素的2维坐标,在地图上就是经纬度。redis基于该类型,提供了经纬度设置,查询,范围查询,距离查询,经纬度Hash等常见操作。
作用 | 语法 |
---|---|
添加地理位置(经度,纬度,名称) | geoadd< longitude> [longitude latitude member…] |
获得指定地区的坐标值 | geopos [member…] |
获取两个位置之间的直线距离 | geodist [m |
以给定的经纬度为中心,找出某一半径内的元素 四个参数 -》经度 纬度 距离 单位 | georadius< longitude>radius m |
Redis事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。
Redis事务的主要作用就是串联多个命令防止别的命令插队。
从输入Multi命令开始,输入的命令都会依次进入命令队列中,但不会执行,直到输入Exec后,Redis会将之前的命令队列中的命令依次执行。
组队的过程中可以通过discard。
组队中某个命令出现了报告错误,执行时整个的所有队列都会被取消
如果执行阶段某个命令报出了错误,则只有报错的命令不会被执行,而其他的命令都会执行,不会回滚。
悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。
乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。
在执行multi之前,先执行watch key1 [key2],可以监视一个(或多个) key ,如果在事务执行之前这个(或这些) key 被其他命令所改动,那么事务将被打断。
取消 WATCH 命令对所有 key 的监视。
如果在执行 WATCH 命令之后,EXEC 命令或DISCARD 命令先被执行了的话,那么就不需要再执行UNWATCH了
在指定的时间间隔内将内存中的数据集快照写入磁盘, 也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到 一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。 整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能 如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
在redis.conf中配置文件名称,默认为dump.rdb
配置文件的位置,默认是启动位置
格式:save 秒钟 写操作次数
当Redis无法写入磁盘的话,直接关掉Redis的写操作。推荐yes
对于存储到磁盘中的快照,可以设置是否进行压缩存储。如果是的话,redis会采用LZF算法进行压缩。
如果你不想消耗CPU来进行压缩的话,可以设置为关闭此功能。推荐yes.
检查完整性
在存储快照后,还可以让redis使用CRC64算法来进行数据校验,
但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能->推荐yes
先通过config get dir 查询rdb文件的目录
将*.rdb的文件拷贝到别的地方
rdb的恢复
动态停止RDB:redis-cli config set save “” #save后给空值,表示禁用保存策略
以日志的形式来记录每个写操作(增量保存),将Redis执行过的所有写指令记录下来(读操作不记录), 只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
客户端的请求写命令会被append追加到AOF缓冲区内;
AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中;
AOF文件大小超过重写策略或手动重写时,会对AOF文件rewrite重写,压缩AOF文件容量;
Redis服务重启时,会重新load加载AOF文件中的写操作达到数据恢复的目的;
默认的appendonly no,改为yes
可以在redis.conf中配置文件名称,默认为 appendonly.aof
AOF文件的保存路径,同RDB路径一致.
AOF和RDB同时开启,系统默认取AOF的数据(数据不会存在丢失)
始终同步,每次Redis的写入都会立刻记入日志;性能较差但数据完整性比较好
每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失。
redis不主动进行同步,把同步时机交给操作系统。
AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制, 当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩, 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof.
AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),redis4.0版本后的重写,是指上就是把rdb 的快照,以二级制的形式附在新的aof头部,作为已有的历史数据,替换掉原来的流水账操作。
no-appendfsync-on-rewrite:
如果 no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存,用户请求不会阻塞,但是在这段时间如果宕机会丢失这段时间的缓存数据。(降低数据安全性,提高性能)
如果 no-appendfsync-on-rewrite=no, 还是会把数据往磁盘里刷,但是遇到重写操作,可能会发生阻塞。(数据安全,但是性能降低)
Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
重写虽然可以节约大量磁盘空间,减少恢复时间。但是每次重写还是有一定的负担的,因此设定Redis要满足一定条件才会进行重写。
auto-aof-rewrite-percentage:设置重写的基准值,文件达到100%时开始重写(文件是原来重写后文件的2倍时触发)
auto-aof-rewrite-min-size:设置重写的基准值,最小文件64MB。达到这个值开始重写。
bgrewriteaof触发重写,判断是否当前有bgsave或bgrewriteaof在运行,如果有,则等待该命令结束后再继续执行。
主进程fork出子进程执行重写操作,保证主进程不会阻塞。
子进程遍历redis内存中数据到临时文件,客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
1).子进程写完新的AOF文件后,向主进程发信号,父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
使用新的AOF文件覆盖旧的AOF文件,完成AOF重写。
官方推荐两个都启用。
如果对数据不敏感,可以选单独用RDB。
不建议单独用 AOF,因为可能会出现Bug。
如果只是做纯内存缓存,可以都不用。
RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
只做缓存:如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
同时开启两种持久化方式
在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢?
建议不要,因为RDB更适合用于备份数据库(AOF在不断变化不好备份), 快速重启,而且不会有AOF可能潜在的bug,留着作为一个万一的手段。
性能建议
因为RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留save 900 1这条规则。
如果使用AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了。
代价,一是带来了持续的IO,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
只要硬盘许可,应该尽量减少AOF rewrite的频率,AOF重写的基础大小默认值64M太小了,可以设到5G以上。
默认超过原大小100%大小时重写可以改到适当的数值。
主机数据更新后根据配置和策略, 自动同步到备机的master/slaver机制,Master以写为主,Slave以读为主
######################redis6379.conf#######################
include /myredis/redis.conf
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb######################redis6380.conf#######################
include /myredis/redis.conf
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb######################redis6381.conf#######################
include /myredis/redis.conf
pidfile /var/run/redis_6381.pid
port 6381
dbfilename dump6381.rdb
info replication # 打印主从复制的相关信息
slaveof # 在从机上配置主机的ip和端口 在6380和6381上执行: slaveof 127.0.0.1 6379
从机会全量复制主机的内容,k1,k2,k3,k4都会复制
从机只可读,不可写
主机shutdown后,从机原地待命,等待主机重新启动,一切回复正常
可以复制,因为主机重启后和之前一样,主机写内容,会同步到从机中
其中一台从机down后情况如何?依照原有它能跟上大部队吗?
从机down后,会脱离大部队,如果重新启动,还想同步主机内容的话,需要重新执行命令
slaveof
Slave启动成功连接到master后会发送一个sync命令
Master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令, 在后台进程执行完毕之后,master将传送整个数据文件到slave,以完成一次完全同步
全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
增量复制:Master继续将新的所有收集到的修改命令依次传给slave,完成同步
但是只要是重新连接master,一次完全同步(全量复制)将被自动执行
上一个Slave可以是下一个slave的Master,Slave同样可以接收其他 slaves的连接和同步请求,那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。
用 slaveof
中途变更转向:会清除之前的数据,重新建立拷贝最新的
风险是一旦某个slave宕机,后面的slave都没法备份
主机挂了,从机还是从机,无法写数据了
当一个master宕机后,后面的slave可以立刻升为master,其后面的slave不用做任何修改。
用slaveof no one 将从机变为主机
反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库
sentinel monitor mymaster 127.0.0.1 6379 1
#其中mymaster为监控对象起的服务器名称, 1 为至少有多少个哨兵同意迁移的数量。
启动哨兵,执行redis-sentinel /myredis/sentinel.conf
当主机挂掉,从机选举中产生新的主机
重新启动原主机,原主机重启后会变为从机
由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重。
优先级在redis.conf中默认:slave-priority 100,值越小优先级越高
偏移量是指获得原主机数据最全的
每个redis实例启动后都会随机生成一个40位的runid
private static JedisSentinelPool jedisSentinelPool=null;public static Jedis getJedisFromSentinel(){if(jedisSentinelPool==null){Set sentinelSet=new HashSet<>();sentinelSet.add("ip:端口");JedisPoolConfig jedisPoolConfig =new JedisPoolConfig();jedisPoolConfig.setMaxTotal(10); //最大可用连接数jedisPoolConfig.setMaxIdle(5); //最大闲置连接数jedisPoolConfig.setMinIdle(5); //最小闲置连接数jedisPoolConfig.setBlockWhenExhausted(true); //连接耗尽是否等待jedisPoolConfig.setMaxWaitMillis(2000); //等待时间jedisPoolConfig.setTestOnBorrow(true); //取连接的时候进行一下测试 ping pongjedisSentinelPool=new JedisSentinelPool("mymaster",sentinelSet,jedisPoolConfig);return jedisSentinelPool.getResource();}else{return jedisSentinelPool.getResource();}
}
Redis 集群实现了对Redis的水平扩容,即启动N个redis节点,将整个数据库分布存储在这N个节点中,每个节点存储总数据的1/N。
Redis 集群通过分区(partition)来提供一定程度的可用性(availability): 即使集群中有一部分节点失效或者无法进行通讯, 集群也可以继续处理命令请求。
之前通过代理主机来解决,但是redis3.0中提供了解决方案。就是无中心化集群配置。
include /myredis/redis.conf
pidfile "/var/run/redis_6391.pid"
port 6391
dbfilename "dump6391.rdb"
cluster-enabled yes
cluster-config-file nodes-6391.conf
cluster-node-timeout 15000
cluster-enabled yes 打开集群模式
cluster-config-file nodes-6379.conf 设定节点配置文件名
cluster-node-timeout 15000 设定节点失联时间,超过该时间(毫秒),集群自动进行主从切换。
其中 :%s/6379/6380 是vim的替换命令
要确保nodes-xxxx.conf生成
组合之前,请确保所有redis实例启动后,nodes-xxxx.conf文件都生成正常
先到redis的src目录中
cd /opt/redis-6.2.1/src
运行集成集群命令
redis-cli --cluster create --cluster-replicas 1 192.168.242.110:6379 192.168.242.110:6380 192.168.242.110:6381 192.168.242.110:6389 192.168.242.110:6390 192.168.242.110:6391
说明:ip一定要真实ip,不能是localhost或者127.0.0.1
–replicas 1 采用最简单的方式配置集群,一台主机,一台从机,正好三组。
# 连接Redis
redis-cli -c -p 6379
# 查看集群信息
cluster nodes
cluster nodes
一个集群至少要有三个主节点。
选项 --cluster-replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。
分配原则尽量保证每个主数据库运行在不同的IP地址,每个从库和主库不在一个IP地址上。
在运行集成集群命令后,会出现“[OK] All 16384 slots covered ”
说明:一个 Redis 集群包含 16384 个插槽(hash slot), 数据库中的每个键都属于这 16384 个插槽的其中一个, 集群使用公式CRC16(key) %16384 来计算键key属于哪个槽.其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。
集群中的每个节点负责处理一部分插槽。 举个例子, 如果一个集群可以有主节点, 其中:
节点 A 负责处理 0 号至 5460 号插槽。
节点 B 负责处理 5461 号至 10922 号插槽。
节点 C 负责处理 10923 号至 16383 号插槽。
注意:在用mset 同时设置多个值的时候,需要把这些key放到同一个组中,不然会报错。可以通过{}来定义组的概念,从而使key中{}内相同内容的键值对放到一个slot中去
CLUSTER KEYSLOT k1 # 查询k1的插槽值
CLUSTER COUNTKEYSINSLOT 12706 # 查看指定插槽中的key数量,注意只能在插槽值所在的主机上能成功,例如:12706插槽在6381端口的主机上,但是在其他端口则查询失败
CLUSTER GETKEYSINSLOT 5474 2 # 返回指定插槽的指定数量的key
如果主节点下线?从节点能否自动升为主节点?注意:15秒超时
主节点恢复后,主从关系会如何?主节点回来变成从机。
如果所有某一段插槽的主从节点都宕掉,redis服务是否还能继续?
如果某一段插槽的主从都挂掉,而cluster-require-full-coverage 为yes ,那么 ,整个集群都挂掉
如果某一段插槽的主从都挂掉,而cluster-require-full-coverage 为no ,那么,该插槽数据全都不能使用,也无法存储。
redis.conf中的参数 cluster-require-full-coverage
即使连接的不是主机,集群会自动切换主机存储。主机写,从机读。
无中心化主从集群。无论从哪台主机写的数据,其他主机上都能读到数据。
key对应的数据在数据源并不存在,每次针对此key的请求从缓存获取不到,请求都会压到数据源,从而可能压垮数据源。比如用一个不存在的用户id获取用户信息,不论缓存还是数据库都没有,若黑客利用此漏洞进行攻击可能压垮数据库。
一个一定不存在缓存及查询不到的数据,由于缓存是不命中时被动写的,并且出于容错考虑,如果从存储层查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义。
对空值缓存:如果一个查询返回的数据为空(不管是数据是否不存在),我们仍然把这个空结果(null)进行缓存,设置空结果的过期时间会很短,最长不超过五分钟
设置可访问的名单(白名单):使用bitmaps类型定义一个可以访问的名单,名单id作为bitmaps的偏移量,每次访问和bitmap里面的id进行比较,如果访问id不在bitmaps里面,进行拦截,不允许访问。、
采用布隆过滤器:(布隆过滤器(Bloom Filter)是1970年由布隆提出的。它实际上是一个很长的二进制向量(位图)和一系列随机映射函数(哈希函数)。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法,缺点是有一定的误识别率和删除困难。
将所有可能存在的数据哈希到一个足够大的bitmaps中,一个一定不存在的数据会被 这个bitmaps拦截掉,从而避免了对底层存储系统的查询压力。
进行实时监控:当发现的命中率开始急速降低,需要排查访问对象和访问的数据,和运维人员配合,可以设置黑名单限制服务
key对应的数据存在,但在redis中过期,此时若有大量并发请求过来,这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存,这个时候大并发的请求可能会瞬间把后端DB压垮。
key可能会在某些时间点被超高并发地访问,是一种非常“热点”的数据。这个时候,需要考虑一个问题:缓存被“击穿”的问题。
(1)就是在缓存失效的时候(判断拿出来的值为空),不是立即去load db。
(2) 先使用缓存工具的某些带成功操作返回值的操作(比如Redis的SETNX)去set一个mutex key
(3) 当操作返回成功时,再进行load db的操作,并回设缓存,最后删除mutex key;
(4) 当操作返回失败,证明有线程在load db,当前线程睡眠一段时间再重试整个get缓存的方法。
key对应的数据存在,但在redis中过期,此时若有大量并发请求过来,这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存,这个时候大并发的请求可能会瞬间把后端DB压垮。
缓存雪崩与缓存击穿的区别在于这里针对很多key缓存,前者则是某一个key正常访问
构建多级缓存架构:nginx缓存 + redis缓存 +其他缓存(ehcache等)
使用锁或队列:用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写,从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况
设置过期标志更新缓存:记录缓存数据是否过期(设置提前量),如果过期会触发通知另外的线程在后台去更新实际key的缓存。
将缓存失效时间分散开:比如我们可以在原有的失效时间基础上增加一个随机值,比如1-5
Redis ACL是Access Control List(访问控制列表)的缩写,该功能允许根据可以执行的命令和可以访问的键来限制某些连接。
在Redis 5版本之前,Redis 安全规则只有密码控制 还有通过rename 来调整高危命令比如 flushdb , KEYS* , shutdown 等。Redis 6 则提供ACL的功能对用户进行更细粒度的权限控制:
(1)接入权限:用户名和密码
(2)可以执行的命令
(3)可以操作的 KEY
作用 | 语法 |
---|---|
展现用户权限列表 | acl list |
查看添加权限指令类别 加参数类型名可以查看类型下具体命令 | acl cat |
查看当前用户 | acl whoami |
创建和编辑用户ACL | acl setuser |
类型 | 参数 | 说明 |
---|---|---|
启动和禁用用户 | on | 激活某用户账号 |
启动和禁用用户 | off | 禁用某用户账号。注意,已验证的连接仍然可以工作。如果默认用户被标记为off,则新连接将在未进行身份验证的情况下启动,并要求用户使用AUTH选项发送AUTH或HELLO,以便以某种方式进行身份验证。 |
权限的添加删除 | +
| 将指令添加到用户可以调用的指令列表中 |
权限的添加删除 | -
| 从用户可执行指令列表移除指令 |
权限的添加删除 | +@
| 添加该类别中用户要调用的所有指令,有效类别为@admin、@set、@sortedset…等,通过调用ACL CAT命令查看完整列表。特殊类别@all表示所有命令,包括当前存在于服务器中的命令,以及将来将通过模块加载的命令 |
权限的添加删除 | -@
| 从用户可调用指令中移除类别 |
权限的添加删除 | allcommands | +@all的别名 |
权限的添加删除 | nocommand | -@all的别名 |
可操作键的添加或删除 | ~
| 添加可作为用户可操作的键的模式。例如~*允许所有的键 |
Redis6终于支撑多线程了,告别单线程了吗?
IO多线程其实指客户端交互部分的网络IO交互处理模块多线程,而非执行命令多线程。Redis6执行命令依然是单线程
Redis 6 加入多线程,但跟 Memcached 这种从 IO处理到数据访问多线程的实现模式有些差异。Redis 的多线程部分只是用来处理网络数据的读写和协议解析,执行命令仍然是单线程。之所以这么设计是不想因为多线程而变得复杂,需要去控制 key、lua、事务,LPUSH/LPOP 等等的并发问题。整体的设计大体如下
另外,多线程IO默认也是不开启的,需要再配置文件中配置
io-threads-do-reads yes
io-threads 4
之前老版Redis想要搭集群需要单独安装ruby环境,Redis 5 将 redis-trib.rb 的功能集成到 redis-cli 。另外官方 redis-benchmark 工具开始支持 cluster 模式了,通过多线程的方式对多个分片进行压测压。
Redis6新功能还有:
1、RESP3新的 Redis 通信协议:优化服务端与客户端之间通信
2、Client side caching客户端缓存:基于 RESP3 协议实现的客户端缓存功能。为了进一步提升缓存的性能,将客户端经常访问的数据cache到客户端。减少TCP网络交互。
3、Proxy集群代理模式:Proxy 功能,让 Cluster 拥有像单实例一样的接入方式,降低大家使用cluster的门槛。不过需要注意的是代理不改变 Cluster 的功能限制,不支持的命令还是不会支持,比如跨 slot 的多Key操作。
4、Modules API:Redis 6中模块开发进展非常大,因为为了开发复杂的功能,从一开始就用上模块。可以变成一个框架,利用来构建不同系统,而不需要从头开始写然后还要许可。一开始就是一个向编写各种系统开放的平台。