Redis使用注意事项-解答前2期小伙伴提出的问题

2018年8月17日

Redis使用注意事项

接着前几节的话题继续闲聊Redis相关的使用注意事项。以下是前2期的文章连接,有兴趣的朋友可以读一读。

Redis是否需要设计Schema?

Redis最大的瓶颈是什么?

下面就来说一说hotkey的问题,那么小伙伴可能会问什么叫hotkey问题,顾名思义就是热点key,进一步解释就是访问非常频繁的Redis key。引用其它解释:缓存中的某些Key对应的value存储在集群中一台机器,使得所有流量涌向同一机器,成为系统的瓶颈,该问题的挑战在于它无法通过增加机器容量来解决。那么我们如何来解决这种问题呢?

1.通过设计本地缓存的方式,从Redis远程拉去到当前key的value后缓存到本地。这样有什么好处呢,就是不要每次都要去远程Redis key了。避免对系统的性能、网络流量影响。

2.通过设计多个子key,将单机的这个key散列到多机上,把请求流量打散到多台机器,提高性能,避免给系统造成瓶颈。本质上就是通过hash方式实现此目的。

以上就如何解决hotkey问题作者提出了2点解决方案。欢迎同学一起讨论。如果有好的解决方案,也可以与我一起探讨。

另外我们来说说Redis另外一个在系统设计过程中需要注意的问题-Bigkey。按名字解释就是Redis大key,对的就是这么个意思。由于之前我所在的团队性质决定的:对性能要求非常高,所以当出现小范围的性能都可能引起系统挂掉。之前出现过相关研发人员为了图方便省事,在公共redis实例上存储了一个这个key玩家uid列表。当前key数据量大小为4000w+个uid。可想而之每次应用系统要读取这个key时,会造成带宽和io网络io压力非常大。那么我们如何来解决这个问题呢。string类型控制在10KB以内,hash、list、set、zset元素个数不要超过10000个元素。那么必然会产生严重的问题:

1.如果你的Redis的服务是要持久化的或者是个主从架构,那么会出现以下问题,bgsave或者主从同步,会给网络io造成堵塞。

2.当app服务器获取这个bigkey时,给应用服务器也会造成严重的问题,本身app服务器的带宽不可能配置像Redis BD服务器那样的充足。

3.由于Redis是单线程的,bigkey的获取给可能会将单核CPU直接到100%的使用率,这可能会给客户端的瞬间连接造成拥塞甚至出现超时报错。

如何这些比较大的key呢,这里使用一个简单粗暴的方法:./redis-cli –bigkeys

后期我可以介绍点实现优雅的方案。本期篇幅有限,就不在这里介绍了。

那么我们如何避免的出现这样的问题出现呢。下面就来说说如何避免。

避免手段:

1.设计方案的时候使用一些手段把这些bigkey平均散列到多个Redis实例上。

2.能不能通过架构设计避免这些bigkey的出现呢,因此架构师再使用Redis作为中间件的时候,就要充分理解如何使用Redis非常关键。

好了,今天就说到了这里了。我来总结一波,给本次主题下个结论,Redis在使用过程中看似不需要设计Schema,其实是需要设计Schema的。不然会给后期的运维带来不可避免的问题。

One Reply to “Redis使用注意事项-解答前2期小伙伴提出的问题”

  1. Pingback: Redis使用注意事项-某电商公司案例系列一 – 方后国的博客

发表评论

电子邮件地址不会被公开。 必填项已用*标注