进阶指南！Redis 用法总结( 三 ) _Redis

文章插图

从上图可以看到：节点 1 只负责执行 0 - 4999 的槽位，而节点 2 负责执行 5000 - 9999，节点 3 执行 9999- 16383。当进行写的时候：
【进阶指南！Redis 用法总结】
set key value命令通过 CRC16(key) & 16383 = 6789（假设结果），由于节点 2 负责 5000～9999 的槽位，则该命令的结果 6789 最终由节点 2 执行。当然如果在节点 2 执行一条命令时，假设通过 CRC 计算后得到的值为 567，则其应该由节点 1 执行，此时命令会进行转向操作，将要执行的命令流转到节点 1 上去执行。

文章插图

集群节点同步：
集群中每个主节点都会定时发送信息到其他主节点进行同步，如果其他主节点在规定时间内响应了发送消息的主节点，则发送消息的主节点认为响应了消息的主节点正常，反之则认为响应消息的主节点疑似下线，则发送消息的主节点在其节点上将其标记“疑似下线” 。

当集群中超过一半以上的节点认为某个主节点被标记为“疑似下线”，则其中某个主节点将疑似下线节点标记为下线状态，并向集群广播一条下线消息，当下线节点对应的从节点接收到该消息时，则从从节点中选举出一个节点作为主节点继续对外提供服务。

四、Redis为什么变慢了业务场景中，不知道大家是否碰到过 Redis 变慢的情况：

执行 SET、DEL 命令耗时也很久；
偶现卡顿，之后又恢复正常了；
在某个时间点，突然开始变慢了。

原因分析查看慢查询，由于笔者本身机器没有慢查询，所以这里看到是空（实在尴尬，这里没有可用的例子~~）

文章插图

由于 Redis 在 IO 操作和对键值对的操作是单线程的，所以直接在客户端 Redis-cli 上执行的 Redis 命令有可能会导致操作延迟变大；
使用复杂的命令会让 Redis的处理变慢，以及CPU过高，例如 SORT、SUNION、ZUNIONSTORE 聚合类命令（时间负责度O(N) ）；
查询的数据量过大，使得更多时间花费在数据协议的组装和网络传输过程中；
大 key 查询，比如对于一个很大的 hash、zset 等，这样的对象对 Redis 的集群数据迁移带来了很大的问题，因为在集群环境下，如果某个 key 太大，会导致数据迁移卡顿；
另外在内存分配上，如果一个 key 太大，那么当它需要扩容时，会一次性申请更大的一块内存，这也会导致卡顿。如果这个大 key 被删除，内存会一次性回收，卡顿现象会再一次产生。
集中过期，变慢的时间统一，所以业务中的 Key 过期时间尽量在统一的一个时间点加上一个随机数时间;
内存使用达到上限，当内存达到内存上限的时候，就不许淘汰一些数据，这个时候也可能导致 Redis 查询效率低；
碎片整理，Redis 在 4.0 版本后会自动整理碎片（由于内存回收过程中存在大量的碎片空间，不整理会导致 Redis 的空间少量浪费），而在整理碎片的过程中会消耗 CPU 的资源，从而影响了请求得到性能；
网络带宽，Redis 集群和业务混部，或者并发量过大以及每次返回的数据也很大，网卡带宽跑满的情况容易导致网络阻塞；
AOF 的频率过高，由于 AOF 需要将全部的写命令同步，如果同步的间隔比较短，也会影响到 Redis 的性能；
Redis 提供了 flushdb 和 flushall 指令，用来清空数据库，这也是导致 Redis 缓慢的操作。

五、Redis安全默认会监听 6379 端口，最好在 Redis 的配置文件中指定监听的 IP 地址，更进一步还可以增加 Redis 的 ACL 访问控制，对客户指定群组，并限限制用户对数据的读写权限。
访问 Redis 尽量走公司代理，由于 Redis 本身不支持 SSL 的链接，所以走公司代理可以保证安全。客户端登陆 Redis 必须设置 Auth 秘密登陆。