多线程
问题
单个主线程处理网络请求的速度跟不上底层网络硬件的速度。
优化
多个 IO 线程并行处理网络操作,可以提升实例的整体处理性能。
使用单线程执行命令操作,就不用为了保证 Lua 脚本、事务的原子性,额外开发多线程互斥机制了。
具体流程
1、服务端和客户端建立 Socket 连接,并分配给IO线程
2、IO 线程读取并解析请求
3、主线程执行请求操作
4、IO 线程回写 Socket 和主线程清空全局队列
相关配置:
io-threads-do-reads yes #启用多线程
io-threads 6 #线程个数要小于 Redis 实例所在机器的 CPU 核个数
服务端协助的客户端缓存(Tracking)
问题
如果数据被修改了或是失效了,如何通知客户端对缓存的数据做失效处理。
普通模式
实例会在服务端记录客户端读取过的 key,并监测 key 是否有修改。
一旦 key 的值发生变化,服务端会给客户端发送 invalidate 消息,通知客户端缓存失效了。
服务端对于记录的 key 只会报告一次 invalidate 消息
只有当客户端再次执行读命令时,服务端才会再次监测被读取的 key,并在 key 修改时发送 invalidate 消息
设置命令
CLIENT TRACKING ON|OFF
广播模式
服务端会给客户端广播所有 key 的失效情况
如果 key 被频繁修改,服务端会发送大量的失效广播消息,这就会消耗大量的网络带宽资源。
应用场景
客户端注册希望跟踪的 key 的前缀,当带有注册前缀的 key 被修改时,服务端会把失效消息广播给所有注册的客户端。
区别
广播模式下,即使客户端还没有读取过 key,但只要它注册了要跟踪的 key,服务端都会把 key 失效消息通知给这个客户端。
细粒度的权限控制
1、支持创建不同用户
ACL SETUSER normaluser on > abc #创建并启用一个用户 normaluser,把它的密码设置为“abc”
2、支持以用户为粒度设置命令操作的访问权限