redis注意点

Posted on | Post modified:
redis注意点

redis需要注意的点

合理使用集合类

ZRANGEBYSCORE和ZREMRANGEBYSCORE命令的时间复杂度是 O(log(N) + M)，其中M是操作的元素个数，N是集合元素总数

  • 当一次性查询的量特别大的时候，需要分批次查询
  • 可以通过缩小每次查询的集合数量，可以将一天分成多段，分批次查询，比如把查24小时范围的用户改为查4小时范围的用户，分别查6次处理即可。
  • 如果一天都是很大，那么颗粒度可以更小，按小时，分钟数都可以

注意

使用 sortedset、set、list、hash等集合类的O(N)操作时要评估当前元素个数的规模以及将来的增长规模，对于短期就可能变为大集合的key，要预估O(N)操作的元素数量，避免全量操作，可以使用HSCAN、SSCAN、ZSCAN进行渐进操作。集合元素数量过大在使用过程中会影响redis的实际性能，元素个数建议尽量不要超过5000，元素数量过大可考虑拆分成多个key进行处理。

合理设置到期时间

需要对key加上过期时间，否则，一直生成的key会导致慢日志，如果使用不是需要全部的数据，那么就应该只找最相应的数据，如果全部需要应该落实到mysql等关系型数据库中

注意

如果key没有设置超时时间，会导致一直占用内存。对于可以预估使用生命周期的key应当设置合理的过期时间或在最后一次操作时进行清理，避免垃圾数据残留redis

合理使用批操作命令

一次性导入上万个数据的时候，不应该使用for循环来执行hset的操作，这样会导致接口响应超时
使用hmset一次性将元素都导入进去，也会导致慢日志

注意

对于大量频繁的hset操作可以使用 HMSET替代减少redis操作次数同时提升处理速度，但是要考虑单次请求操作的数量，避免慢日志。
在redis使用过程中，要正视网络往返时间，合理利用批量操作命令，减少通讯时延和redis访问频次。redis为了减少大量小数据CMD操作的网络通讯时间开销 RTT (Round Trip Time)，支持多种批操作技术：

  • MSET/HMSET等都支持一次输入多个key，LPUSH/RPUSH/SADD等命令都支持一次输入多个value,也要注意每次操作数量不要过多,建议控制在500个以内；

  • PipeLining 模式 可以一次输入多个指令。redis提供一个 pipeline 的管道操作模式，将多个指令汇总到队列中批量执行，可以减少tcp交互产生的时间，一般情况下能够有10%~30%不等的性能提升；

  • 更快的是Lua Script模式，还可以包含逻辑。redis内嵌了 lua 解析器，可以执行lua 脚本，脚本可以通过eval等命令直接执行，也可以使用script load等方式上传到服务器端的script cache中重复使用。

减少不必要的请求

某业务系统，当用户进入某个页面时会同时请求多个接口，每个接口都会校验用户状态是否有效，用户状态存在redis里并设置有过期时间，对于key未过期但是过期时间大于指定阈值的，需要重新设置有效时间，否则需要使用del命令删除掉。但是部分key由于过期其实已经不存在了，所以出现部分无效del命令。用户越多，就会有越多的无效命令。

  • ttl命令对于key不存在的情况会返回-2，若key不存在则不需要再调用del命令，可减少无效请求。

注意

edis的所有请求对于不存在的key都会有输出返回，合理利用返回值处理，避免不必要的请求，提升业务吞吐量。

避免value设置过大

某开发人员将一个商品集合信息序列化后用redis的字符串类型存储，使用的时候再反序列化成对象列表使用，大小超过1MB，在网络传输的时候由于数据比较大会触发拆包，会降低redis的吞吐量。

  • 数量比较多时可以考虑改用hash结构存储，每一个field是商品id,value是该商品对象，如果数量较大可使用hscan获取。

注意

String类型尽量控制在10KB以内。虽然redis对单个key可以缓存的对象长度能够支持的很大，但是实际使用场合一定要合理拆分过大的缓存项，1k 基本是redis性能的一个拐点。当缓存项超过10k、100k、1m性能下降会特别明显。关于吞吐量与数据大小的关系可见下面官方网站提供的示意图。

设计规范的key名

  • 保持简洁性

    以业务名为前缀，用冒号分隔，可使用业务名：子业务名：id的结构命名，子业务下多单词可再用下划线分隔
    举例：活动系统-人拉人红包活动-id，可命名为 ACTIVITY:INVITE_REDPACKET:001

  • 保持简洁性

    保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视

  • 不含转义字符

    不包含空格、换行、单双引号以及其他转义字符

留心禁用命令

  • keys、monitor、flushall、flushdb应当通过redis的rename机制禁掉命令，若没有禁用，开发人员要谨慎使用。其中flushall、flushdb会清空redis数据；keys命令可能会引起慢日志；monitor命令在开启的情况下会降低redis的吞吐量，根据压测结果大概会降低redis50%的吞吐量，越多客户端开启该命令，吞吐量下降会越多。
  • keys和monitor在一些必要的情况下还是有助于排查线上问题的，建议可在重命名后在必要情况下由redis相关负责人员在redis备机使用，monitor命令可借助redis-faina等脚本工具进行辅助分析，能更快排查线上ops飙升等问题。