共计 3112 个字符，预计需要花费 8 分钟才能阅读完成。
慕课网 2021-01-29 Redis 直播笔记 – 上（acl/ 客户端缓存 / 多级缓存）
redis6 装置留神点
咱们课程里疏忽了，就不去装置了，仅仅只提供装置文档，redis6 的装置其实和 redis5 装置差不多，只是须要留神 gcc 的版本须要进步，不然编译会出错。
参考慕课网手记地址：https://www.imooc.com/article…
acl 权限策略
根底概念
不晓得大家有没有听过 acl，zookeeper 中也有，acl 就是 access control list，权限管制列表，和平时接触的管理系统的权限是一样的，能够限度不同角色的操作权。
在 redis6 中，咱们能够设置不同的用户，对他们进行受权命令，管制可读可写，限度拜访缓存 key 的前缀等。这样能够更加进步 redis6 的数据安全性。因为是对于一些公司的生产库，能够让很多人去连贯查看，就特地有用。然而一般来说都是只有运维或者 redis 工程师能力拜访的。
大家想一想，晚期版本通过 requirepass 设置明码，这个不去设置，你的服务器很有可能被攻打，这个咱们架构班的同学有遇到过，被勒索比特币，或者成为肉鸡挖矿。所以这个明码必定要设置。
ACL 存储模式
acl 的权限的存储模式能够配置到 redis.conf 中，也能够内部文件 aclfile，我集体偏好后者，这也是官网举荐的形式。（因为 aclfile 文件产生批改只须要重载 acl 即可，而 conf 形式须要重启 redis）
咱们能够间接在命令行中创立用户去权限，而后再把用户保留到 conf 或者 aclfile 中。命令如下：
# 将 ACL 权限长久化到 redis.conf
config rewrite
# 将 ACL 权限长久化到 users.acl
acl save实操演练
- 开启 aclfile，指定门路
-
创立权限 acl 文件（留神：须要他前创立 acl 空文件，否则重启 redis 会报错）
touch /usr/local/redis/users.acl
重启 redis 并且进入客户端
查看过程
./redis-cli shutdown./redis-server redis.conf./redis-cli
auth default # 默认用户无明码 或者
./redis-cli # 能够间接进入 ACL 的应用
- 查看 acl 命令帮忙（学习一个新货色，基本上他们都会有帮忙文档的。像在 linux 中，大多都是 help，就有一大堆的命令提醒，前面还有英文的解释，这是最间接的学习形式）
acl help置信凡是有一些教训的，这些其实都应该看得懂
1)ACL：命令参数，要以 ACL 结尾
2)LOAD：从新加载 acl 文件，手动批改 acl 文件后，须要让 redis 服务从新加载，能力失效
3)SAVE：保留以后用户权限配置到 acl 文件
4)LIST：展现用户权限的详细信息
5)USERS：展现所有用户名
6)SETUSER：设置或者批改用户
7)GETUSER：取得用户全新信息
8)DELUSER：删除用户以及权限
9)CAT：展现所有权限分类，不同的操作归类不同
10)CAT < 某分类名 >：展现某分类具体蕴含哪些操作
11)GENPASS：生成明码
12)WHOAMI：以后登录者
13)LOG：日志
- 默认没有配置的时候，会有一个 default 用户，
on代表开启，off代表禁用。default为用户名，前面的内容为 ACL 规定形容，~*示意所有 key，+@all示意所有命令。所以这个示意用户 default 开启状态，并且，没有明码而且能够拜访所有命令以及所有数据。
- 取得所有的用户名
- 以后登录用户是谁
-
查看命令的分类：
acl cat：显示所有的命令类别
* 查某个类别下有哪些操作，就比方如下危险操作，这些命令都是危险的，对以后 redis 库可能会造成影响
创立用户
当初咱们来创立一下用户
-
创立或者批改用户，用户名辨别大小写，然而不倡议把同样的用户名分为大小写不同的两个
# 新增默认所有权限的用户 ACL SETUSER imooc on >123456 ~* +@all # 新增用户 itzixi，明码 123456，只能容许拜访 order 前缀的 key，能够应用 set 和 get 和 acl 命令 ACL SETUSER itzixi on >123456 ~order* +get +set +acl - 这个时候关上 acl 文件是空的，须要执行保留命令
-
保留命令到 aclfile
acl save
切换用户进行测试
- 切换到 itzixi 用户，并且测试，他只能 set 和 get，order 前缀的 key
* mget 不可用
为用户减少类别权限拜访
-
为用户 itzixi 新增某一个类别下的所有操作，比方这个类别就是 read 类别的所有读操作：
ACL SETUSER itzixi +@read- 多了一个 read 类别
* 这个时候能够应用 mget 操作了：
附
ACL LOAD：咱们也能够间接在 aclfile 中批改或新增 ACL 权限，批改之后不会立即失效，咱们能够在 redis 命令行中执行 acl load 将该 aclfile 中的权限加载至 redis 服务中。
客户端缓存 Client Side Cache
这是他的官网地址，有趣味能够看看：
https://redis.io/topics/clien…
咱们应该都晓得，redis 作为缓存中间件，目标是为了缩小热点数据对数据库的压力，并且提供更快的访问速度，redis 的性能要比一般数据库快很多。
然而 redis 也有瓶颈上线，因为申请到 redis 肯定会有网络 io 的损耗，并且也有数据的序列化以及反序列化的等等的一些开销，所以如果在本地把热数据再做一次缓存的话（Guava Cache 过程缓存，可能会有不统一的状况），那么能够使得申请性能更好，减速拜访，晋升客户端的响应速度了，因为数据提早就升高并且缩小了很多嘛。
大家能够想一下，什么场景下能够应用？
其实只有满足大量的申请，不怎么更改的数据，都能够。比方数据字典，咱们的我的项目中波及到一些超大型物流车的参数信息，这些基本上不会变动的，除非有相干的一些政策扭转，那么有些参数信息就要变更，要不然间接存本地缓存是十分难受的。
能够看一下这图，他实质上就是基于 redis-server 服务端来维系和利用后端的关系，用的 pub/sub 公布订阅的告诉机制，如果服务端缓存产生更改，那么能够向利用后端来推送，让其更新本地缓存。
其中利用是指的咱们的部署的我的项目，调用端。
理解一下：在 Reds6 之前的版本，应用的是 RESP2 协定，当初是 RESP3，这个是 REdisSerializationProtocol，是 Redis 服务端与客户端之间通信的协定。
实现客户端缓存的形式 – 默认模式
Redis-server 服务端会记录客户端拜访了哪些 key，这客户端 id 与 key 有惟一的映射关系，当其中的 key 产生变更时给客户端发送生效信息。这种模式会占用服务端所在服务器的内存。
实现客户端缓存的形式 – 播送机制
客户端订阅拜访过的 key 的前缀，当合乎的 key 产生变更就会被 redis-server 告诉（如果变更的 key 没有被客户端缓存，也会告诉），因为服务器端不记录客户端拜访的 key，所以不会过多占用 redis-server 端的服务器内存；
在这种模式下，服务端保护的是前缀 key，而不是默认模式的所有 key，所以这样对于内存的占用不会很高，只有批改匹配的前缀 key，那么订阅的客户端都会收到生效 key 的告诉。只不过因为定订阅的是前缀，他会收到很多的有效告诉。
在播送模式下，只有合乎客户端设置的 key 前缀的 key 产生新增、批改、删除、还有过期、淘汰等动作，即便该 key 没有被该客户端缓存，也会收到 key 的生效音讯；
多级缓存
直播过程中提到了多级缓存架构，能够通过这图理解一下，更具体的能够做到 4 层，nginx 能够做两层：