Redis有哪些开发设计规范值得我们注意的!

  • 时间:
  • 浏览:0
  • 来源:大发5分6合_大发5分6合官网

03

可读性

在局域网环境下我希望传输的包不超过1个 MTU(以太网下要花费 60 0 bytes),可不都能否了 对于 10、60 、60 0 bytes不同包大小的正确处理吞吐能力实际结果差不要 。

map<短码,手机号> 60 000个元素

PipeLining 模式 可不都能否 一次输入多个指令。redis提供1个  pipeline 的管道操作模式,将多个指令汇总到队列中批量执行,可不都能否 减少tcp交互产生的时间,一般状态下也能有10%~60 %不等的性能提升;

可能key可不都能否了 设置超时时间,会是因为突然占用内存。对于可不都能否 预估使用生命周期的key应当设置合理的过期时间或在最后一次操作时进行清理,正确处理垃圾数据残留redis。

减少不要 要的请求

方案3:依然使用 HMSET,也不每次设置60 0个,循环60 次

合理使用集合类

06

02

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

吞吐量与数据大小的关系

结果:失败。突然跳出redis慢日志

分析

以业务名为前缀,用冒号分隔,可使用业务名:子业务名:id的形状命名,子业务下多单词可再用下划线分隔

快一点 的是Lua Script模式,还可不都能否 蕴藏逻辑。redis内嵌了 lua 解析器,可不都能否 执行lua 脚本,脚本可不都能否 通过eval等命令直接执行,也可不都能否 使用script load等措施上传到服务器端的script cache中重复使用。

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

方案1:直接使用redis的HSET逐个设置

分析

可不都能否 把粒度分得更细其他比如1小时可能60 分钟,可能选取用户参加活动集中在某个时间点,可不都能否 考虑使用ZSCAN遍历操作并删除。另外,对于目标时间范围有选取的首尾元素时,还可不都能否 通过ZRANK命令查出元素的位置,通过 ZRANGE 以及ZREMRANGEBYRANK来进行查询和删除操作,也不每次操作可不都能否 控制操作数量,有效正确处理慢日志。

某运营需求,时需给用户生成短链,短链由短链前缀+短码组成,根据短码找到用户对应的手机号,开发人员使用redis hash形状存储短码到手机号的映射。接口每次会导入20万个手机号。

HMSET(key,map)

不蕴藏转义字符

方案2:改用redis的 HMSET一次将所有元素设置到hash中

该案例中,每个生成的key在2天以前都不 会再使用了,可将key加带过期时间。

可能用户参加活动的时间很集中,在某一

简洁性

在redis使用过程中,要正视网络往返时间,合理利用批量操作命令,减少通讯带宽和redis访问频次。redis为了减少极少量小数据CMD操作的网络通讯时间开销 RTT (Round Trip Time),支持多种批操作技术:

留心禁用命令

分析

对于极少量频繁的hset操作可不都能否 使用 HMSET替代减少redis操作次数并肩提升正确处理带宽,而且要考虑单次请求操作的数量,正确处理慢日志。

本群提供免费的学习指导 架构资料 以及免费的解答

分析

for(60 ;)

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

欢迎工作一到五年的Java工程师大伙们加入Java架构开发:744677563

小结

小结

for(60 000;)

数量比较多时可不都能否 考虑改用hash形状存储,每1个 field是商品id,value是该商品对象,可能数量较大可使用hscan获取。

合理设置过期时间

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

案例

某活动需求,每天10点对昨天参加某活动的用户进行推送提醒。开发人员使用redis存储每天参加活动的用户,通过ZRANGEBYSCORE命令获取目标用户进行提醒,提醒以前使用ZREMRANGEBYSCORE命令从redis中清除这批用户。某一天ZRANGEBYSCORE、ZREMRANGEBYSCORE均突然跳出了慢日志报警,排查发现其他天参加该活动的用户约有20万。

小结

合理利用批操作命令

05

HMSET(key,map)

redis的所有请求对于不指在的key回会有输出返回,合理利用返回值正确处理,正确处理不要 要的请求,提升业务吞吐量。

某投票功能,用于统计今日环比昨日的增长数量,开发人员使用redis存储每天的投票数,key设计为vote_count_{date},其中{date}为当天的日期,可能可不都能否了 设置过期时间,一年以前产生了360 多个key,实际在用的key始终可不都能否了1个 。

数量还是有点儿多为何办?

案例

07

A

不懂得现象图片都可不都能否 在本群提出来 以前回会有职业生涯规划以及面试指导

举例:活动系统-人拉人红包活动-id,可命名为 ACTIVITY:INVITE_REDPACKET:001

小结

某统计功能,用户会不定期的导入一批数据进 redis,每一批数据时需在60 分钟后、1天后、两天后、两天后进行计算统计,统计结果发给用户。开发人员使用redis的同1个 sortedset存储哪些地方地方导入的数据,每天定时任务执行计算任务。可能可不都能否了 清理,是因为极少量结束了了计算任务的废弃数据残留redis。

  总      结  

该案例中,每一批数据都不 相应的生命周期,在导入的第两天执行完最后一次计算任务生命周期结束了了,可能集合里的元素可不都能否了单独设置过期时间,可在代码逻辑中对最后一次使用这批数据后进行清理操作。

下面是开发人员的四种 操作redis方案的伪代码

01

map<短码,手机号> 60 0个元素

案例1

结果:成功

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

分析

分析

keys和monitor在其他必要的状态下还是能助 排查线上现象图片的,建议可在重命名后在必要状态下由redis相关负责人员在redis备机使用,monitor命令可借助redis-faina等脚本工具进行辅助分析,能快一点 排查线上ops飙升等现象图片。

正确处理value设置过大

案例2

HSET(key,短码,手机号)

设计规范的key名

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

keys、monitor、flushall、flushdb应当通过redis的rename机制禁掉命令,若可不都能否了 禁用,开发人员要谨慎使用。其中flushall、flushdb会清空redis数据;keys命令可能会引起慢日志;monitor命令在开启的状态下会降低redis的吞吐量,根据压测结果要花费会降低redis60 %的吞吐量,不要 客户端开启该命令,吞吐量下降会不要 。

04

时间段(比如晚18点到22点)查出来

小结

某业务系统,当用户进入某个页面回会并肩请求多个接口,每个接口回会校验用户状态是否 有效,用户状态指在redis里并设置有过期时间,对于key未过期而且过期时间大于指定阈值的,时需重新设置有效时间,而且时需使用del命令删除掉。而且次要key可能过期我我虽然可能不指在了,也不突然跳出次要无效del命令。用户不要 ,就会有不要 的无效命令。

案例

Q

案例中使用了redis的sortedset来储存用户信息,其中value是用户的账号、score是用户参加活动的时间,可能ZRANGEBYSCORE和ZREMRANGEBYSCORE命令的时间繁杂度是 O(log(N) + M),其中M是操作的元素个数,N是集合元素总数,本例中当用户数量为20万时突然跳出慢日志。可不都能否 通过缩小每次查询的集合数量,可不都能否 将一天分成多段,分批次查询,比如把查24小时范围的用户改为查4小时范围的用户,分别查6次正确处理即可。

本文采集出的几点redis开发规范主也不涉及redis客户端的使用次要,每个开发人员在使用redis开发过程中几乎回会涉及到上述提到的哪几个现象图片,时需多多留心,提高代码质量,提升redis的健康度。

redis都不 垃圾桶都不 的是 SUPER MAN,能力和资源都不 限,不合理的使用会降低它的健康度,严重时甚至会引起redis抖动、阻塞等进而是因为服务不可用,每1个 使用redis的开发人员都应当掌握规范的开发和使用措施。本文采集出redis开发过程中七个较常突然跳出的使用不合理的场景,并辅以案例进行分析说明。

结果:失败。redis ops飙升,并肩接口响应超时

ttl命令对于key不指在的状态会返回-2,若key不指在则不时需再调用del命令,可减少无效请求。