Redis使⽤注意事项（欢迎补充）
整理⾃：
⼀、键值设计
1. key 名设计
1. 【建议】: 可读性和可管理性
以业务名 (或数据库名) 为前缀 (防⽌ key 冲突)，⽤冒号分隔，⽐如业务名: 表名:id
例如：ugc:video:1
2. 【建议】：简洁性
保证语义的前提下，控制 key 的长度，当 key 较多时，内存占⽤也不容忽视，
例如：user:{uid}:friends:messages:{mid}简化为 u:{uid}??m:{mid}。
3. 【强制】：不要包含特殊字符
反例：包含空格、换⾏、单双引号以及其他转义字符
详细解析
2. value 设计
1. 【强制】：拒绝 bigkey(防⽌⽹卡流量、慢查询)
string 类型控制在 10KB 以内，hash、list、set、zset 元素个数不要超过 5000。
反例：⼀个包含 200 万个元素的 list。
⾮字符串的 bigkey，不要使⽤ del 删除，使⽤ hscan、sscan、zscan ⽅式渐进式删除，同时要注意防⽌ bigkey 过期时间⾃动删除问题 (例如⼀个 200 万的 zset 设置 1 ⼩时过期，会触发 del 操作，造成阻塞，⽽且该操作不会不出现在慢查询中 (latency 可查))。
2. 【推荐】：选择适合的数据类型。
例如：实体类型 (要合理控制和使⽤数据结构内存编码优化配置, 例如 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
3. 【推荐】：控制 key 的⽣命周期，redis 不是垃圾桶。
建议使⽤ expire 设置过期时间 (条件允许可以打散过期时间，防⽌集中过期)，不过期的数据重点关注 idletime。
4. 【推荐】：hash，set，zset，list 存储过多的元素优化 可以将这些元素分拆。
通过hash取模的⽅式 正常存取流程是 hget(hashKey, field) ; hset(hashKey, field, value) 现在，固定⼀个桶的数量，⽐如 100，每次存取的时候，先在本地计算field的hash值，模除 100， 确定了该field落
在哪个key上。
newHashKey  =  hashKey + hash(field) % 10000;
hset (newHashKey, field, value) ;
hget(newHashKey, field)
⼆、命令使⽤
1. 【推荐】 O(N) 命令关注 N 的数量
例如 hgetall、lrange、smembers、zrange、sinter 等并⾮不能使⽤，但是需要明确 N 的值。有遍历的需求可以使⽤ hscan、sscan、zscan 代替。Redis的命令时间复杂度可以看这⾥
2. 【推荐】：禁⽤命令
禁⽌线上使⽤ keys、flushall、flushdb 等，通过 redis 的 rename 机制禁掉命令，或者使⽤ scan 的⽅式渐进式处理。
3. 【推荐】合理使⽤ select
redis 的多数据库较弱，使⽤数字进⾏区分，很多客户端⽀持较差，同时多业务⽤多数据库实际还是单线程处理，会有⼲扰。
4. 【推荐】使⽤批量操作提⾼效率
原⽣命令：例如 mget、mset。
⾮原⽣命令：可以使⽤ pipeline 提⾼效率。
但要注意控制⼀次批量操作的元素个数(例如 500 以内，实际也和元素字节数有关)。
注意两者不同：
1. 原⽣是原⼦操作，pipeline 是⾮原⼦操作。
redis五种数据结构2. pipeline 可以打包不同的命令，原⽣做不到
3. pipeline 需要客户端和服务端同时⽀持。
5. 【建议】Redis 事务功能较弱，不建议过多使⽤
Redis 的事务功能较弱 (不⽀持回滚)，⽽且集版本 (⾃研和官⽅) 要求⼀次事务操作的 key 必须在⼀个 slot 上 (可以使⽤ hashtag 功能解决) hashtag的解决⽅案：可以使⽤twitter的 twemproxy
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 命令时，要注意不要长时间使⽤。
三、配置属性优化
maxclients 限制同时连接的客户数量。当连接数超过这个值时， redis 将不再接收其他连接请求，客户端尝试连接时将收到 error 信息。特殊值”0”表⽰没有限制。
timeout 设置客户端连接时的超时时间，单位为秒。当客户端在这段时间内没有发出任何指令，那么关
闭该连接，默认为0则表⽰没有超时时间，如果设定了超时时间，需要注意客户端redis连接池的timeout问题
client-output-buffer-limit
config set client-output-buffer-limit ‘slave 256mb 64mb 60’
这⾥对是客服端是slave的做限制 256mb 是⼀个硬性限制，当output-buffer的⼤⼩⼤于256mb之后就会断开连接。64mb 60 是⼀个软限制，当output-buffer的⼤⼩⼤于64mb并且超过了60秒的时候就会断开连接，所以当预估有bigkeys的时候需要进⾏调试
lua-time-limit 限制脚本的最长运⾏时间，默认为5秒钟。当脚本运⾏时间超过这⼀限制后，Redis将开始接受其他命令但不会执⾏（以确保脚本的原⼦性，因为此时脚本并没有被终⽌），⽽是会返回“BUSY”错误，避免redis阻塞情况
memory-policy 查询内存溢出策略 默认策略是volatile-lru，即超过最⼤内存后，在过期键中使⽤lru算法进⾏key的剔除，保证不过期数据不被删除，但是可能会出现OOM问题。 >maxmemory-policy 六种⽅式
1. volatile-lru：只对设置了过期时间的key进⾏LRU（默认值）
2. allkeys-lru ： 删除lru算法的key
3. volatile-random：随机删除即将过期key
4. allkeys-random：随机删除
5. volatile-ttl ： 删除即将过期的
6. noeviction ： 永不过期，返回错误
五、集批量操作优化
⾸先要知道⼀个概念叫缓存⽆底洞问题，该问题由 facebook 的⼯作⼈员提出的， facebook 在 2010 年左右，memcached 节点就已经达3000 个，缓存数千 G 内容。他们发现了⼀个问题—memcached 连接频率，效率下降了，于是加 memcached 节点，添加了后，发现因为连接频率导致的问题，仍然存在，并没有好转，称之为”⽆底洞现象”。
为什么会出现这个现象，请对⽐下⾯两张图⽚，图⼀是多IO版本，也就是说当存在的节点异常多的时候，IO的代价已经超过数据传输，上⽂提到的facebook的节点已经超过3000个，在这种情况下再增加节点已经没法再提⾼效率了。
图⼀ 多IO版本
图⼆ 单IO版本
redis引⼊cluster模式后，批量获取操作mget也⾯临同样的问题。redis是传统的key-value的存储模式，RedisCluster将数据按key哈希到16384个slot上，每个redis node负责⼀部分的slot。mget需要执⾏的操作就是从redis node获取所有的key-value值，然后进⾏merge然后返回。
其实IO的优化思路都⽐较通⽤，⽆⾮就是提⾼命令本⾝效率，串⾏改并⾏，单个转批量。摘录⼀段⽹
上的IO优化思路总结：
(1) 命令本⾝的效率：例如sql优化，命令优化
(2) ⽹络次数：减少通信次数
(3) 降低接⼊成本：长连/连接池,NIO等 (4) IO访问合并:O(n)到O(1)过程：批量接⼝(mget)
具体⽅案
①串⾏命令：由于n个key是⽐较均匀地分布在Redis Cluster的各个节点上，因此⽆法使⽤mget命令⼀次性获取，所以通常来讲要获取n个key的值，最简单的⽅法就是逐次执⾏n个get命令，这种操作时间复杂度较⾼，它的操作时间=n次⽹络时间+n次命令时间，⽹络次数是n。很显然这种⽅案不是最优的，但是实现起来⽐较简单。
List<string> serialMGet (List<String> keys) {
//结果集
List<string> values - new ArrayList<String>();
/
/n次串⾏get
for (String key : keys) {
String value = (key);values.add (value);
}
return values;
②串⾏IO：Redis Cluster使⽤CRC16算法计算出散列值，再取对16383的余数就可以算出slot值，同时Smart客户端会保存slot和节点的对应关系，有了这两个数据就可以将属于同⼀个节点的key进⾏归档，得到每个节点的key⼦列表，之后对每个节点执⾏mget或者Pipeline操作，它的操作时间=node次⽹络时间+n次命令时间，⽹络次数是node的个数，整个过程如下图所⽰，很明显这种⽅案⽐第⼀种要好很多，但是如果节点数太多，还是有⼀定的性能问题。
Map<String, String> serialIOMget (List<String> keys) {
// 结果集
Map<String, String> keyValueMap = new HashMap<>();
// 属于各个节点的key列表,JedisPool要提供基于ip和port的hashcode⽅法
Map<JedisPool, List<String>> nodeKeyListMap= new HashMap<>();
// 遍历所有的key
for (String key : keys) {
// 使⽤CRC16本地计算每个key的slot
int slot = Slot(key);
//通过iediscluster本地slot->node映射获取slot对应的node
JedisPool jedisPool = ConnectionHandler().getJedisPoolFromSlot(slot);            // 归档
if (ainsKey(jedisPool)) {
<(jedisPool).add(key);
} else {
List<String> list = new ArrayList<String>();
list.add(key);
nodeKeyListMap.put(jedisPool, list);
}
}
// 从每个节点上批量获取，这⾥使⽤mget也可以使⽤pipeline
for (Map.Entry<JedisPool, List<String>> entry : Set()) {
JedisPool jedisPool = Key();
List<String> nodeKeyList = Value();
// 列表变为数组
String[] nodeKeyArray = Array(new String[nodeKeyList.size()]);
/
/ 批量获取，可以使⽤mget或者Pipeline
List<String> nodeValueList = Resource().mget(nodeKeyArray);
// 归档
for (int i = 0; i < nodeKeyList.size(); i++) {
keyValueMap.(i), (i));
}
}
return keyValueMap;
}

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。