《Redis - 使用规范》
一: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。
- 两者不同:
- 不建议过多使用Redis事务功能
- Redis的事务功能较弱(不支持回滚),而且集群版本(自研和官方)要求一次事务操作的key必须在一个slot上(可以使用hashtag功能解决)。
- monitor命令
- 必要情况下使用monitor命令时,要注意不要长时间使用。
六:设置合理的淘汰策略
- 根据自身业务类型,选好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只响应读操作。