慕课网2021-01-29 Redis6直播笔记 - 上（acl/客户端缓存/多级缓存）

redis6安装注意点

我们课程里忽略了，就不去安装了，仅仅只提供安装文档，redis6的安装其实和redis5安装差不多，只是需要注意gcc的版本需要提高，不然编译会出错。 参考慕课网手记地址：https://www.imooc.com/article/313200

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会报错）

重启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文件是空的，需要执行保存命令

保存命令到aclfile

切换用户进行测试

• 切换到itzixi用户，并且测试，他只能set和get，order前缀的key

• mget不可用

为用户增加类别权限访问

为用户itzixi新增某一个类别下的所有操作，比如这个类别就是read类别的所有读操作：

• 多了一个read类别

附

ACL LOAD：我们也可以直接在aclfile中修改或新增ACL权限，修改之后不会立刻生效，我们可以在redis命令行中执行acl load将该aclfile中的权限加载至redis服务中。

客户端缓存 Client Side Cache

这是他的官网地址，有兴趣可以看看： https://redis.io/topics/client-side-caching

我们应该都知道，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可以做两层：