一、订阅与发布
1.服务器工作
服务器中维护着一个pubsub_channels字典,所有的频道和订阅关系都存储在这里。字典的键为频道的名称,而值为订阅频道的客户端链表。
-
当有新的客户端订阅某个频道时,会发生两种情况中的一种:
1)如果频道已经存在,则新的客户端会添加到pubsub_channels对应频道的链表末尾
2)如果频道原本不存在,则会为频道创建一个键,该客户端成为链表的第一个元素 -
当一个客户端退订一个频道的时候:
pubsub_channels对应键的链表会删除该客户端
-
发送信息
服务器会遍历pubsub_channels中对应键的链表,向每一个客户端发送信息
服务器还维护着一个pubsub_patterns链表,链表的pattern属性记录了被订阅的模式,而client属性记录了订阅模式的客户端
- 当有新的客户端订阅某个模式的时,会进行如下步骤:
1)创建一个链表节点,pattern属性记录订阅的模式,client记录订阅模式的客户端
2)将这个链表节点添加到pubsub_patterns链表中
- 当一个客户端退订某一个模式的时候:
服务器遍历pubsob_patterns找到对应的pattern同时也是对应该client客户端的节点,将改节点删除
- 发送信息
服务器遍历pubsub_channels,查找与channels频道相匹配的模式麻将消息发送给订阅了这些模式的客户端
2.命令
// 订阅频道
SUSCRIBE channel1 [channel2] [channel3]
// 订阅模式
PSUBSCRIBE pattern1 [pattern2] [pattern3]
// 取消订阅
UNSUBSCRIBE channel1 [channel2]
// 发布消息
PUBLISH channel message
// 查看已有的频道
PUBSUB subcommand [argument [argument ...]]
二、Redis6新数据类型
1.Bitmaps(大数据量统计个数)
1)概述
现代计算机用二进制(位) 作为信息的基础单位,合理地使用操作位能够有效地提高内存使用率和开发效率。Redis提供了Bitmaps这个“数据类型”可以实现对位的操作:
(1) Bitmaps本身不是一种数据类型, 实际上它就是字符串(key-value) , 但是它可以对字符串的位进行操作。
(2) 最大长度512M
(2) Bitmaps单独提供了一套命令, 所以在Redis中使用Bitmaps和使用字符串的方法不太相同。 可以把Bitmaps想象成一个以位为单位的数组, 数组的每个单元只能存储0和1, 数组的下标在Bitmaps中叫做偏移量。
2)命令
序号 | 命令 | 详细描述 |
---|---|---|
1 | setbit | 设置Bitmap中某个偏移量的值 |
2 | getbit | 获取Bitmaps中某个偏移量的值 |
3 | bitcount [start end] | 统计字符串从start字节到end字节比特值为1的数量 |
4 | bitop and(or/not/xor) [key…] | 统计多个字符串 |
3)示例
a>独立用户访问保存记录
每个独立用户访问网站记录在Bitmaps中,将访问网站的记做1,没有访问的用户记做0,用偏移量记做用户的id
设置键的第offset个位的值(从0算起),假设现在有20个用户,userid=1, 6, 11, 15, 19的用户对网站进行了访问, 那么当前Bitmaps初始化结果如图
这里就要借助上面提供的setbit
命令来设置了,unique:users:20201106
是key,比较长,直面意思就可以看出来代表2020-11-06这天的独立访问用户的Bitmaps
127.0.0.1:6379> setbit unique:users:20220415 1 1
(integer) 0
127.0.0.1:6379> setbit unique:users:20220415 6 1
(integer) 0
127.0.0.1:6379> setbit unique:users:20220415 11 1
(integer) 0
127.0.0.1:6379> setbit unique:users:20220415 15 1
(integer) 0
127.0.0.1:6379> setbit unique:users:20220415 19 1
(integer) 0
注:在第一次初始化Bitmaps时, 假如偏移量非常大, 那么整个初始化过程执行会比较慢, 可能会造成Redis的阻塞。
b>获取独立用户访问记录
获取独立用户在某天是否访问过网站,借助getbit
命令
获取id=8的用户是否在2020-11-06这天访问过, 返回0说明没有访问过:
127.0.0.1:6379> getbit unique:users:20220415 1
(integer) 1
127.0.0.1:6379> getbit unique:users:20220415 6
(integer) 1
127.0.0.1:6379> getbit unique:users:20220415 100 //100根本不存在,直接返回0
(integer) 0
c>统计个数
统计字符串被设置为1的bit数。一般情况下,给定的整个字符串都会被进行计数,通过指定额外的 start 或 end 参数,可以让计数只在特定的位上进行。start 和 end 参数的设置,都可以使用负数值:比如 -1 表示最后一个位,而 -2 表示倒数第二个位,start、end 是指bit组的字节的下标数,二者皆包含。
127.0.0.1:6379> bitcount unique:users:20220415
(integer) 5
127.0.0.1:6379> bitcount unique:users:20220415 1 2
(integer) 3
d>特殊统计
统计出两天都访问过网站的数量,使用bitop and
// 存入2020/04/15号访问用户
127.0.0.1:6379> setbit unique:users:20220415 1 1
(integer) 1
127.0.0.1:6379> setbit unique:users:20220415 2 1
(integer) 0
127.0.0.1:6379> setbit unique:users:20220415 5 1
(integer) 0
// 存入2020/04/16号访问用户
127.0.0.1:6379> setbit unique:users:20220416 1 1
(integer) 0
127.0.0.1:6379> setbit unique:users:20220416 7 1
(integer) 0
// 通过and进行合并 存入total
127.0.0.1:6379> bitop and total unique:users:20220415 unique:users:20220416
(integer) 3
// 求和 也就是上面共同访问的用户1
127.0.0.1:6379> bitcount total
(integer) 1
统计出这个月任何一天,只要访问过网站的用户数量,使用bitop or
// 通过or进行合并 存入
127.0.0.1:6379> bitop or all unique:users:20220415 unique:users:20220416
(integer) 3
// 统计
127.0.0.1:6379> bitcount all
(integer) 8
4)Bitmaps与set对比
从上面的示例中我们看到,该数据类型更多的用于统计计数,那么Redis提供的Set也可以完成这个操作,那么这两者有什么差异
假设网站有1亿用户, 每天独立访问的用户有5千万, 如果每天用集合类型和Bitmaps分别存储活跃用户可以得到表
set和Bitmaps存储一天活跃用户对比 | |||
---|---|---|---|
数据类型 | 每个用户id占用空间 | 需要存储的用户量 | 全部内存量 |
Set集合类型 | 64位 | 50000000 | 64位*50000000 = 400MB |
Bitmaps | 1位 | 100000000 | 1位*100000000 = 12.5MB |
很明显, 这种情况下使用Bitmaps能节省很多的内存空间, 尤其是随着时间推移节省的内存还是非常可观的
set和Bitmaps存储独立用户空间对比 | |||
---|---|---|---|
数据类型 | 一天 | 一个月 | 一年 |
集合类型 | 400MB | 12GB | 144GB |
Bitmaps | 12.5MB | 375MB | 4.5GB |
但Bitmaps并不是万金油, 假如该网站每天的独立访问用户很少, 例如只有10万(大量的僵尸用户) , 那么两者的对比如下表所示, 很显然, 这时候使用Bitmaps就不太合适了, 因为基本上大部分位都是0。
set和Bitmaps存储一天活跃用户对比(独立用户比较少) | |||
---|---|---|---|
数据类型 | 每个userid占用空间 | 需要存储的用户量 | 全部内存量 |
集合类型 | 64位 | 100000 | 64位*100000 = 800KB |
Bitmaps | 1位 | 100000000 | 1位*100000000 = 12.5MB |
2.HyperLogLog
1)概述
概述:用于进行一些去重统计,去重统计方式有很多种,HyperLogLog
用于支持当数据量很大的时候,通过降低一些精度来节约存储空间
在工作当中,我们经常会遇到与统计相关的功能需求,比如统计网站PV(PageView页面访问量),可以使用Redis的incr、incrby轻松实现。
但像UV(UniqueVisitor,独立访客)、独立IP数、搜索记录数等需要去重和计数的问题如何解决?这种求集合中不重复元素个数的问题称为基数问题。
解决基数问题有很多种方案:
(1)数据存储在MySQL表中,使用distinct count计算不重复个数
(2)使用Redis提供的hash、set、bitmaps等数据结构来处理
以上的方案结果精确,但随着数据不断增加,导致占用空间越来越大,对于非常大的数据集是不切实际的。
能否能够降低一定的精度来平衡存储空间?Redis推出了HyperLogLog
Redis HyperLogLog 是用来做基数统计的算法,HyperLogLog 的优点是,在输入元素的数量或者体积非常非常大时,计算基数所需的空间总是固定的、并且是很小的。
在 Redis 里面,每个 HyperLogLog 键只需要花费 12 KB 内存,就可以计算接近 2^64 个不同元素的基数。这和计算基数时,元素越多耗费内存就越多的集合形成鲜明对比。
但是,因为 HyperLogLog 只会根据输入元素来计算基数,而不会储存输入元素本身,所以 HyperLogLog 不能像集合那样,返回输入的各个元素。
2)命令
序号 | 命令 | 详细描述 |
---|---|---|
1 | pfadd < element> [element …] | 添加指定元素到 HyperLogLog 中 |
2 | pfcount [key …] | 计算HLL的近似基数 |
3 | pfmerge [sourcekey …] | 将一个或多个HLL合并后的结果存储在另一个HLL中 |
3)示例
a>存入访问记录
127.0.0.1:6379> pfadd study redis
(integer) 1
127.0.0.1:6379> pfadd study mysql
(integer) 1
127.0.0.1:6379> pfadd study nginx
(integer) 1
127.0.0.1:6379> pfadd study redis
(integer) 0
b>统计PV
统计基数
127.0.0.1:6379> pfcount study
(integer) 3
c>合并
通过pfmerge
合并基数
127.0.0.1:6379> pfadd have java
(integer) 1
127.0.0.1:6379> pfadd have spring
(integer) 1
127.0.0.1:6379> pfadd mybatis
(integer) 1
127.0.0.1:6379> pfadd have java
(integer) 0
// 合并
127.0.0.1:6379> pfmerge result study have
OK
// 查看基数
127.0.0.1:6379> pfcount result
(integer) 5
3.Geospatial
1)概述
Redis 3.2 中增加了对GEO类型的支持。GEO,Geographic,地理信息的缩写。该类型,就是元素的2维坐标,在地图上就是经纬度。redis基于该类型,提供了经纬度设置,查询,范围查询,距离查询,经纬度Hash等常见操作
2)命令
序号 | 命令 | 详细描述 |
---|---|---|
1 | geoadd< longitude> [longitude latitude member…] | 添加地理位置(经度,纬度,名称) |
2 | geopos [member…] | 获得指定地区的坐标值 |
3 | geodist [m | km | ft | mi ] | 获取两个位置之间的直线距离 |
4 | georadius< longitude>radius m | km | ft | mi | 以给定的经纬度为中心,找出某一半径内的元素 |
3)示例
三、新特征
1.ACL(了解)
1)概述
Redis ACL是Access Control List(访问控制列表)的缩写,该功能允许根据可以执行的命令和可以访问的键来限制某些连接。
在Redis 5版本之前,Redis 安全规则只有密码控制 还有通过rename 来调整高危命令比如 flushdb , KEYS* , shutdown 等。Redis 6 则提供ACL的功能对用户进行更细粒度的权限控制 :
(1)接入权限:用户名和密码
(2)可以执行的命令
(3)可以操作的 KEY
2)命令
序号 | 命令 | 描述 |
---|---|---|
1 | acl list | 查看用户权限列表 |
2 | acl cat | 查看权限指令类别 |
3 | acl whoami | 查看当前用户 |
4 | acl setuser [rule [rule …]] | 创建和编辑用户 |
3)ACL规则
下面是有效ACL规则的列表。某些规则只是用于激活或删除标志,或对用户ACL执行给定更改的单个单词。其他规则是字符前缀,它们与命令或类别名称、键模式等连接在一起。
ACL规则 | ||
---|---|---|
类型 | 参数 | 说明 |
启动和禁用用户 | on | 激活某用户账号 |
off | 禁用某用户账号。注意,已验证的连接仍然可以工作。如果默认用户被标记为off,则新连接将在未进行身份验证的情况下启动,并要求用户使用AUTH选项发送AUTH或HELLO,以便以某种方式进行身份验证。 | |
权限的添加删除 | + | 将指令添加到用户可以调用的指令列表中 |
- | 从用户可执行指令列表移除指令 | |
+@ | 添加该类别中用户要调用的所有指令,有效类别为@admin、@set、@sortedset…等,通过调用ACL CAT命令查看完整列表。特殊类别@all表示所有命令,包括当前存在于服务器中的命令,以及将来将通过模块加载的命令。 | |
-@ | 从用户可调用指令中移除类别 | |
allcommands | +@all的别名 | |
nocommand | -@all的别名 | |
可操作键的添加或删除 | ~ | 添加可作为用户可操作的键的模式。例如~*允许所有的键 |
2.IO多线程
Redis6终于支撑多线程了,告别单线程了吗?
IO多线程其实指客户端交互部分的网络IO交互处理模块多线程,而非执行命令多线程。Redis6执行命令依然是单线程。
Redis 6 加入多线程,但跟 Memcached 这种从 IO处理到数据访问多线程的实现模式有些差异。Redis 的多线程部分只是用来处理网络数据的读写和协议解析,执行命令仍然是单线程。之所以这么设计是不想因为多线程而变得复杂,需要去控制 key、lua、事务,LPUSH/LPOP 等等的并发问题。
另外,多线程IO默认也是不开启的,需要再配置文件中配置
io-threads-do-reads yes
io-threads 4
3.未完待续…
交互处理模块多线程,而非执行命令多线程。Redis6执行命令依然是单线程。
Redis 6 加入多线程,但跟 Memcached 这种从 IO处理到数据访问多线程的实现模式有些差异。Redis 的多线程部分只是用来处理网络数据的读写和协议解析,执行命令仍然是单线程。之所以这么设计是不想因为多线程而变得复杂,需要去控制 key、lua、事务,LPUSH/LPOP 等等的并发问题。
另外,多线程IO默认也是不开启的,需要再配置文件中配置
io-threads-do-reads yes
io-threads 4