这是我参与「第五届青训营 」伴学笔记创作活动的第 17 天
一、Redis键值设计
1、优雅的key结构
Redis的Key虽然可以自定义，但是最好遵循下面的几个最佳实践约定：
遵循基本的格式： [业务名称]:[数据名]:[id] ，长度不超过44字节，不包含特殊字符 优点： 可读性强、避免key冲突、方便管理
2、BigKey问题
什么是BigKey
BigKey指以Key的大小和Key中成员的数量来综合判定
Key本身的数据量过大：一个String类型的Key，它的值为5MB Key中的成员数过多：
一个ZSET类型的Key，它的成员数量为10000个
Key中成员的数据量过大：一个Hash类型的Key，它的成员数量虽然只有1000个但这些成员的Value值总大小为100MB 推荐： 单个key的value小于10KB 对于集合类型的key，建议元素数量小于1000 BigKey的危害
- 网络堵塞：少量的QPS就可能导致带宽使用率被占满，导致Redis实例，乃至物理机变慢
- 数据倾斜：bigkey所在的redis内存使用率远远超过其他实例，无法让数据分片的内存资源达到均衡
- Redis阻塞：对元素较多的hash、list、zset等做运算会耗时较久，使主线程被阻塞 CPU压力：对bigKey数据序列化和反序列化会导致cpu使用率飙升，影响redis实例 如何发现BigKey
如何删除
BigKey
BigKey内存占用较多，即便是删除都很耗时，导致redis主线程堵塞，引发一些列问题 redis 3.0以下版本 如果是集合类型，则遍历BigKey（扫描）的元素，先逐个删除子元素，最后删除bigKey redis4.0以后提供了异步删除的命令：unlink
3、恰当的数据类型
假如有hash类型的key，其中100万对feiid和value，feild是自增id，这个key什么问题怎么优化？
存在问题： hash的entry数量超过500时，会使用哈希表而不是ziplist，内存占用较多 可以通过hash-max-ziplist-entries配置entry上限调大，但是如果entry过多会导致bigkey问题
优化方案： 我们可以把hash打散的方式来优化
二、批处理优化
1、Pipeline
大量数据导入的方式
网络传输耗时相对来说是非常大的，所以我们要尽量避免多次请求
MSET
Redis提供了很多Mxxx这样的命令，可以实现批量插入数据
- mset（只能处理字符串）
- hmset（只能处理hash）
利用mset批量插入10万条数据：
注意：不要一次批处理中传输太多命令，否则单词命令占用带宽过多，会导致网络堵塞 Pipeline MSET虽然可以批处理，但是却只能操作部分数据类型，有复杂数据类型的批处理需要，建议使用Pipeline功能： Piepline是没有数据类型限制的可以任意做组合 但是Piepline的多个命令之间不像mset多条命令原子性，中间可能有其他代码执行，所以速度相对会比较慢
三、服务端优化
1、持久化配置
Redis持久化虽然可以保证数据安全，但也会带来很多额外开销，因此持久化要遵循以下建议： 用来做缓存的redis实例尽量不要开持久化功能 建议关闭RDB持久化功能，使用AOF持久化 利用脚本定期在slave节点做RDB，实现数据备份（不建议频繁做，一段时间做一次，尽量从节点做） 合理的rewrite阈值，避免频繁的bgrewrite 配置no-appendfsync-on-rewrite=yes，禁止rewrite期间做aof，避免aof引起堵塞。（因为在aof时主线程要将数据写到aof缓冲区，有独立线程刷盘，主线程还会判断耗时，如果耗时超过2秒，会堵塞主线程。这时加如正在执行bgrewrite，磁盘io会影响aof刷盘从而导致主线程堵塞，但是这个期间没有aof可能导致数据丢失） 部署建议： redis实例的物理机要预留足够内存来应付fork（可能内存翻倍）和rewrite（重写也要读取内存） 单个redis实例内存上限不要太大。可以加快fork（如果单节点过大，要同步更多数据）的速度、减小主从同步、数据迁移压力 不要与cpu密集型应用部署一起 不要与高硬盘负载应用一起部署（因为重写也要大量io也会影响性能）
