Redis 开发设计规范

一、Key-Value设计规范1. key名设计【建议】：可读性和可管理性以业务名(或数据库名)为前缀(防止key冲突)，用冒号分隔，比如业务名:表名:idugc:video:1【建议】：简洁性保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视，例如：user:{uid}:friends:messages:{mid}简化为 u:{uid}:fr:m:{mid}【强制】：长度50个字符以内,不要包含特殊字符反例：包含空格、换行、单双引号以及其他转义字符【强制】：控制key的总数量redis实例包含的键个数建议控制在 1 千万内，单实例的键个数过大，可能导致过期键的回收不及时。2. Value值设计【强制】：拒绝bigkey(防止网卡流量、慢查询)在Redis中，一个字符串最大512MB，一个二级数据结构（例如hash、list、set、zset）可以存储大约40亿个(2^32-1)个元素，但实际中如果下面两种情况，我就会认为它是bigkey。1).字符串类型：它的big体现在单个value值很大，一般认为超过10KB就是bigkey。2).非字符串类型：哈希、列表、集合、有序集合，它们的big体现在元素个数太多。一般来说，string类型控制在10KB以内；hash、list、set、zset元素个数不要超过5000。反例：一个包含200万个元素的list。非字符串的bigkey，不要使用del删除，使用hscan、sscan、zscan方式渐进式删除，同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期，会触发del操作，造成阻塞，而且该操作不会不出现在慢查询中(latency可查))，查找方法和删除方法【推荐】：选择适合的数据类型。例如：实体类型(要合理控制和使用数据结构内存编码优化配置,例如ziplist，但也要注意节省内存和性能之间的平衡) 反例:set user:1:name tom
set user:1:age 19
set user:1:favor football正例：hmset user:1 name tom age 19 favor football【强制】：控制key生命周期，redis不是垃圾站建议使用expire设置过期时间(条件允许可以打散过期时间，防止集中过期)，不过期的数据重点关注idletime。如果业务强制需求不过期，请说明具体原因。二、命令使用规范1.【推荐】 O(N)命令关注N的数量例如hgetall、lrange、smembers、zrange、sinter等并非不能使用，但是需要明确N的值。有遍历的需求可以使用hscan、sscan、zscan代替。2.【推荐】：禁用命令禁止线上使用keys、flushall、flushdb等，通过redis的rename机制禁掉命令，或者使用scan的方式渐进式处理。3.【推荐】避免使用select ,使用登录上去默认的db0redis的多数据库较弱，使用数字进行区分，很多客户端支持较差，同时多业务用多数据库实际还是单线程处理，会有干扰。哨兵模式中不建议使用多db，毕竟集群模式已经不能使用多db。4.【推荐】使用批量操作提高效率Ø原生命令是原子操作，pipeline是非原子操作Øpipeline可以打包不同的命令，原生不支持Øpipeline需要客户端和服务端同时支持Ø原生命令:如mget、mset。Ø非原生命令:可以使用pipeline提高效率。Ø但要注意控制一次批量操作的元素个数（例如500以内，实际也和元素字节数有关）。5.【建议】Redis事务功能较弱，不建议过多使用Redis事务功能不支持回滚，cluster 要求事务操作的key必须在一个slot上面。6.【建议】Redis集群版本在使用Lua上有特殊要求所有key都应该由 KEYS 数组来传递，redis.call/pcall 里面调用的redis命令，key的位置，必须是KEYS array, 否则直接返回error，-ERR bad lua script for redis cluster, all the keys that the script uses should be passed using the KEYS array所有key，必须在1个slot上，否则直接返回error, “-ERR eval/evalsha command keys must in same slot”7.【建议】必要情况下使用Monitor命令时，要注意不要长时间使用，造成缓冲区溢出，尽而内存抖动三、客户端使用规范1.【推荐】使用带有连接池的数据库，可以有效控制连接，同时提高效率，标准使用方式：//执行命令如下：
Jedis jedis = null;
try {
    jedis = jedisPool.getResource();
    //具体的命令
    jedis.executeCommand()
} catch (Exception e) {
    logger.error("op key {} error: " + e.getMessage(), key, e);
} finally {
    //注意这里不是关闭连接，在JedisPool模式下，Jedis会被归还给资源池。
    if (jedis != null)
    jedis.close();
}2.【建议】高并发下建议客户端添加熔断功能(例如netflix hystrix)3.【推荐】设置合理的密码，如有必要可以使用SSL加密访问4.【建议】设置合理的密码，如有必要可以使用SSL加密访问5.【建议】根据自身业务类型，选好maxmemory-policy(最大内存淘汰策略)，设置好过期时间。默认策略是volatile-lru，即超过最大内存后，在过期键中使用lru算法进行key的剔除，保证不过期 数据不被删除，但是可能会出现OOM问题。其他策略如下：allkeys-lru：根据LRU算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止。
allkeys-random：随机删除所有键，直到腾出足够空间为止。
volatile-random: 随机删除过期键，直到腾出足够空间为止。
volatile-ttl：根据键值对象的ttl属性，删除最近将要过期数据。如果没有，回退到noeviction
策略。
noeviction：不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息"(error) OOM
command not allowed when used memory"，此时Redis只响应读操作。四、合理使用1. 【推荐】冷热数据分离，不要将所有数据全部都放到Redis中虽然Redis支持持久化，但是Redis的数据存储全部都是在内存中的，成本昂贵。建议根据业务只将高频热数据存储到Redis中【QPS大于5000】，对于低频冷数据可以使用MySQL/ElasticSearch/MongoDB等基于磁盘的存储方式，不仅节省内存成本，而且数据量小在操作时速度更快、效率更高！2. 【推荐】不同的业务数据要分开存储不要将不相关的业务数据都放到一个Redis实例中，建议新业务申请新的单独实例。因为Redis为单线程处理，独立存储会减少不同业务相互操作的影响，提高请求响应速度；同时也避免单个实例内存数据量膨胀过大，在出现异常情况时可以更快恢复服务！3. 【推荐】存储的Key一定要设置超时时间如果应用将Redis定位为缓存Cache使用，对于存放的Key一定要设置超时时间！因为若不设置，这些Key会一直占用内存不释放，造成极大的浪费，而且随着时间的推移会导致内存占用越来越大，直到达到服务器内存上限！另外Key的超时长短要根据业务综合评估，而不是越长越好！4. 【推荐】对于必须要存储的大文本数据一定要压缩后存储对于大文本【超过500字节】写入到Redis时，一定要压缩后存储！大文本数据存入Redis，除了带来极大的内存占用外，在访问量高时，很容易就会将网卡流量占满，进而造成整个服务器上的所有服务不可用，并引发雪崩效应，造成各个系统瘫痪！5. 【强制】线上Redis禁止使用Keys正则匹配操作Redis是单线程处理，在线上KEY数量较多时，操作效率极低【时间复杂度为O(N)】，该命令一旦执行会严重阻塞线上其它命令的正常请求，而且在高QPS情况下会直接造成Redis服务崩溃！如果有类似需求，请使用scan命令代替！6. 【推荐】谨慎全量操作Hash、Set等集合结构在使用HASH结构存储对象属性时，开始只有有限的十几个field，往往使用HGETALL获取所有成员，效率也很高，但是随着业务发展，会将field扩张到上百个甚至几百个，此时还使用HGETALL会出现效率急剧下降、网卡频繁打满等问题【时间复杂度O(N)】,此时建议根据业务拆分为多个Hash结构；或者如果大部分都是获取所有属性的操作,可以将所有属性序列化为一个STRING类型存储！同样在使用SMEMBERS操作SET结构类型时也是相同的情况！7. 【建议】根据业务场景合理使用不同的数据结构类型目前Redis支持的数据库结构类型较多：字符串（String），哈希（Hash），列表（List），集合（Set），有序集合（Sorted Set）, Bitmap, HyperLogLog和地理空间索引（geospatial）等,需要根据业务场景选择合适的类型，常见的如：String可以用作普通的K-V、计数类；Hash可以用作对象如商品、经纪人等，包含较多属性的信息；List可以用作消息队列、粉丝/关注列表等；Set可以用于推荐；Sorted Set可以用于排行榜等！五、相关工具1.【推荐】：数据同步redis间数据同步可以使用：redis-port2.【推荐】：big key搜索对于Redis主从版本可以通过scan命令进行扫描，对于集群版本提供了ISCAN命令进行扫描，命令规则 如下, 其中节点个数node可以通过info命令来获取到：3.【推荐】：热点key寻找(内部实现使用monitor，所以建议短时间使用，生产环境一般不建议使用)六、使用场景u严禁在redis中存储需要持久化的数据；u只缓存热点数据1. 高并发场景下，热点数据缓存高并发场景下，合理的使用缓存不仅能够提升网站访问速度，还能降低后端数据库的压力。2. 排行榜类场景关系型数据库在排行榜类场景的查询速度普遍偏慢，借助Redis提供的list和sorted sets结构能实现各种复杂的排行榜应用。3. 限时业务的运用利用expire命令可以运用在限时优惠活动信息、订单库存过期、手机验证码等业务场景。4. 计数器Redis天然支持计数功能而且计数的性能也非常好，在高并发场景下优于传统的关系型数据库，常运用于商品的浏览数、视频的播放数、限制调用等。5.  社交网络点赞、踩、关注/被关注、共同好友等是社交网站的基本功能，社交网站的访问量通常来说比较大，而且传统的关系数据库类型不适合存储这种类型的数据，Redis提供的哈希、集合等数据结构能很方便的的实现这些功能。6.  分布式锁在高并发场景中，利用数据库锁来控制资源的并发访问，性能不理想，可以利用Redis的setnx功能来编写分布式的锁。