Redis使用规范

Redis的使用规范

key规范

• 以业务名为key前缀，用冒号隔开，以防止key冲突覆盖
• 确保key语义清晰额度情况下，长度尽量小
• key禁止宝航特殊字符，如空格、换行、单双引号以及转义符
• key尽量设置ttl,以保证不使用的key能够清除

value规范

• 如果大量存储bigKey是会有问题的，会导致慢查询，内存增长过快
• 要选择适合的数据类型。
• 给Key设置过期时间，同时注意不同业务的key，尽量过期时间分散一点
• 建议使用批量操作提高效率(Pipeline pipe = redis.pipelined())

高可用

Redis 支持主从同步，提供 Cluster 集群部署模式，通过 Sentine 哨兵来监控 Redis 主服务器的状态。

主从

启动一台 slave 的时候，他会发送一个 psync 命令给 master ，如果是这个 slave 第一次连接到 master，他会触发一个全量复制。master 就会启动一个线程，生成 RDB 快照，还会把新的写请求都缓存在内存中，RDB 文件生成后，master 会将这个 RDB 发送给 slave 的，slave 拿到之后做的第一件事情就是写进本地的磁盘，然后加载进内存。

哨兵

主观下线->客观下线->选举 Leader
缺点：

• Redis主机宕机后，哨兵模式正在投票选举的情况之外，因为投票选举结束之前，谁也不知道主机和从机是谁，此时Redis也会开启保护机制，禁止写操作，直到选举出了新的Redis主机。
• 只有一个主节点对外提高服务，没办法支持很高的并发
• 单个主节点的内存不宜设置得过大，否则会导致持久会文件过大，影响数据恢复。

cluster

Redis Cluster 使用分片机制，在内部分为 16384 个 slot 插槽，分布在所有 master 节点上，每个 master 节点负责一部分 slot。数据操作时按 key 做 CRC16 来计算在哪个 slot，由哪个 master 进行处理。数据的冗余是通过 slave 节点来保障
缺点

• 如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。

Redis的坑

慎用O(n)复杂度命令
慎用Redis的monitor命令
生产环境不能使用 keys指令
禁止使用flushall、flushdb
注意使用del命令
如果是List类型，你可以执行lpop或者rpop，直到所有元素删除完成。
如果是Hash/Set/ZSet类型，你可以先执行hscan/sscan/scan查询，再执行hdel/srem/zrem依次删除每个元素。
避免使用SORT、SINTER等复杂度过高的命令

缓存设计

数据不一致

如果服务对耗时不是特别敏感可以增加重试；如果服务对耗时敏感可以通过异步补偿任务来处理失败的更新，或者短期的数据不一致不会影响业务，那么只要下次更新时可以成功，能保证最终一致性就可以。

避免缓存穿透

数据库中未查询到的数据，可在 Redis 中设置特殊标识，以避免因缓存中无数据而导致每次请求均到达数据库。缓存穿透的解决方案，有以下两种：

对不存在的用户，在缓存中保存一个空对象进行标记，防止相同 ID 再次访问 DB。不过有时这个方法并不能很好解决问题，可能导致缓存中存储大量无用数据。
使用 BloomFilter 过滤器，BloomFilter 的特点是存在性检测，如果 BloomFilter 中不存在，那么数据一定不存在；如果 BloomFilter 中存在，实际数据也有可能会不存在。

避免缓存雪崩

当大量缓存集中在某一个时间段失效，这样在失效的时候也会给数据库带来很大压力。对于缓存雪崩的解决方案有以下两种：

搭建高可用的集群，防止单机的 redis 宕机。
设置不同的过期时间，防止同一时间内大量的 key 失效。

避免缓存击穿

某个 key 的缓存过期后，同一时间内有大量的请求均访问该 key，由于缓存过期，大量的请求均会访问数据库，并重建缓存；重建缓存的过程加锁，保证只有一个人执行，其他人等待。

持久化

Redis 提供了 RDB 和 AOF 两种持久化方式，RDB 是把内存中的数据集以快照形式写入磁盘，实际操作是通过 fork 子进程执行，采用二进制压缩存储；AOF 是以文本日志的形式记录 Redis 处理的每一个写入或删除操作。

RDB

把整个 Redis 的数据保存在单一文件中，比较适合用来做灾备，但缺点是快照保存完成之前如果宕机，这段时间的数据将会丢失，另外保存快照时可能导致服务短时间不可用。

AOF

对日志文件的写入操作使用的追加模式，有灵活的同步策略，支持每秒同步、每次修改同步和不同步，缺点就是相同规模的数据集，AOF 要大于 RDB，AOF 在运行效率上往往会慢于 RDB。

AOF重写

1.AOF 重写机制是通过 fork 出一个子进程来完成的，子进程会扫描 Redis 的数据库，并将每个键值对转换为相应的写入命令，然后写入到一个临时文件中 。
2.在子进程进行 AOF 重写的过程中，主进程还会继续接收和处理客户端的请求，如果有新的写操作发生，主进程会将这些写操作追加到一个缓冲区中，并通过管道通知子进程 。
3.子进程在完成 AOF 重写后，会将缓冲区中的写操作也追加到临时文件中，然后向主进程发送信号，通知主进程可以切换到新的 AOF 文件了 。
4.主进程在收到子进程的信号后，会将缓冲区中的写操作再次追加到临时文件中（以防止在此期间有新的写操作发生），然后用临时文件替换旧的 AOF 文件，并关闭旧的 AOF 文件 。