一：Redis 概述
- Redis 是内存级别的数据库，在一台普通电脑上，Redis 3.X 便可以读取 10 万个键值对(现在的Redis官方版本已经更新到了5.X，性能会更好)。
二：关于Redis 和 Memcached 的性能问题。
- 理论上 Memcached 为多线程模型，会比 Redis 性能好。
- 但是，Redis的性能已经足够好，在大部分场合下性能都不会成为它的瓶颈。
- 我们更应该关注的是 Redis 和 Memcached 的应用场景。
三：key 键名设计
**- 可读性和可管理性 **
- 以业务名(或数据库名)为前缀(防止key冲突)，用冒号分隔，比如业务名:表名:id
- 简洁性
- 保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视，如：( user:{uid}:friends:messages:{mid}简化为u:{uid}:fr:m:{mid} )
- 不要包含特殊字符
- 空格、换行、单双引号以及其他转义字符 等
四：value设计
- 不要使用特别大的键（bigkey）
- 虽然 Redis 官方说明了 key和string类型value限制均为512MB。
- 但是防止网卡流量、慢查询，string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000。
- 非字符串的bigkey，不要使用del删除，使用hscan、sscan、zscan方式渐进式删除
- 同时要注意防止bigkey过期自动删除问题(例如一个200万的zset设置1小时过期，会触发del操作，造成阻塞。
- 而且该操作不会不出现在慢查询中(latency可查))，查找方法和删除方法。
- 选择适合的数据类型
- 取代将数据存储为数千（或者数百万）独立的字符串，可以考虑使用哈希数据结构将相关数据进行分组。哈希表是非常有效率的，并且可以减少你的内存使用；
- 同时，哈希还更有益于细节抽象和代码可读。
- 合适时候，使用list代替set。如果你不需要使用set特性，List在使用更少内存的情况下可以提供比set更快的速度。
- Sorted sets是最昂贵的数据结构，不管是内存消耗还是基本操作的复杂性。
- 如果你只是需要一个查询记录的途径，并不在意排序这样的属性，那么建议使用哈希表
- 控制key的生命周期
- Redis不是垃圾桶，建议使用expire设置过期时间(条件允许可以打散过期时间，防止集中过期)。
- 不过期的数据重点关注idletime。
五：命令使用
- O(N)命令关注N的数量
- hgetall、lrange、smembers、zrange、sinter等并非不能使用，但是需要明确N的值。
- 在N值过大时候，有遍历的需求可以使用hscan、sscan、zscan代替。
- 禁用命令
- keys
- 客户端可查询出所有存在的键。(键太多导致Redis崩溃，缓存被穿透)
- flushdb
- 删除当前所选数据库的所有键。此命令永远不会失败。
- flushall
- 删除所有现有数据库的所有键，而不仅仅是当前选定的数据库。此命令永远不会失败。
- 禁止线上使用keys、flushall、flushdb等，通过redis的rename机制禁掉命令，或者使用scan的方式渐进式处理。
- 使用批量操作提高效率
- 原生命令：例如mget、mset。
- 非原生命令：可以使用pipeline提高效率。
- 两者不同：
- 原生是原子操作，pipeline是非原子操作。
- pipeline可以打包不同的命令，原生做不到
- pipeline需要客户端和服务端同时支持。
- 不建议过多使用Redis事务功能
- Redis的事务功能较弱(不支持回滚)，而且集群版本(自研和官方)要求一次事务操作的key必须在一个slot上(可以使用hashtag功能解决)。
- monitor命令
- 必要情况下使用monitor命令时，要注意不要长时间使用。
六：设置合理的淘汰策略
- 根据自身业务类型，选好maxmemory-policy(最大内存淘汰策略)，设置好过期时间。
- 默认策略是volatile-lru，即超过最大内存后，在过期键中使用lru算法进行key的剔除，保证不过期数据不被删除，但是可能会出现OOM问题(申请内存过大导致自杀)。
- 具体
-
image
- allkeys-lru：根据LRU算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止。
- allkeys-random：随机删除所有键，直到腾出足够空间为止。
- volatile-random:随机删除过期键，直到腾出足够空间为止。
- volatile-ttl：根据键值对象的ttl属性，删除最近将要过期数据。如果没有，回退到noeviction策略。
- noeviction：不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息"(error) OOM command not allowed when used memory"，此时Redis只响应读操作。
运维redis很久了，一直是口头给rd说各种要求，尝试把这些规范总结成文档
摘选一些可能比较通用的规则如下：
强制：所有的key设置过期时间（最长可设置过期时间10天，如有特殊要求，联系dba说明原因）
强制：禁止在测试环境，本地办公环境，开发跳板机，连接线上redis实例（实例归业务自运维的除外）
强制：禁止使用运维类的命令 keys monitor debug watch flush bigkeys
强制：list的长度最大长度不超过1万，size不超过1G
强制：key的长度不超过100个字符
建议：string类型value长度不超过10M
建议：做好容量规划，预先考虑内存占用过大后，业务的拆分和分片后的影响
建议：选择合适的数据类型（string,list,hash,set,sortset) ,使用特殊的数据类型（bit,geo)须提前与dba沟通
建议：使用常用的命令，m类操作，建议个数100个以下。
建议：不使用多个db,只使用db0,如果要区分业务线，在配置文件里定义各业务线使用的前缀
建议：有一套能区分业务归属的命名规范，key前缀是发生内存暴涨，性能问题时的分析定位问题的可行基础，Key的命名规范建议：
第1个字符小写定义数据类型：
string —>s,Hash—>h,Set—>s,Zset —>z,List —>l,Geo—>g
第2,3字符定义公开的业务分类：
第4-10个字符定义部门类的业务线细分
推荐的key中可使用符号.:#
不推荐使用的有：\ ? * {} [] ()
例：hCMappnode.product.detail:1312342
建议：不命名用对list,set,zset等分片支持不友好的操作如：union diff， 如果不能避免，注意使用大括号括起key的关键字
建议：在代码中捕扣redis连接异常。考虑一个redis实例短时当机时业务的降级处理，尤其是对redis的高频调用，有时候redis报错日志可能会打满磁盘
建议：不同业务线，不同重要程度的redis建议申请多个redis实例，避免业务线中使用的redis过大。
网友评论