Redis使用注意事项-某电商公司案例系列一

2018年8月17日

原创作者:黎锦红

编辑:方后国

Redis介绍

Redis如今非常流行,几乎成了项目必备的组件之一,但是Redis不是万金油,不是所有应用场景都适合。但是前方还是有诗和远方。小明千万别放弃。

故事背景

故事发生在六月份中旬,那天窗外阳光正好,微风不燥,中午睡个懒觉刚刚好,还没来得及睡的时候,被告知,小明的午睡事件被无情的剥夺了,故事就是以这样的方式开始了,某个业务的Redis出问题了,让帮忙看看。这时候故事的主人公小明正式登场了。小明以迅雷不及掩耳之势解锁电脑,然后就无情的看到了企业微信轰炸似的流量告警,某台Redis机器带宽跑到了3Gb。

故事发生到这时候相信大家应该明白了发生什么事情,请允许我花几分钟的时间介绍发生故障的业务架构:

下面有请故事主人公小明介绍下这套Redis集群的架构:

Redis有8台32G8核的服务器组成,每个服务器跑两个redis实例,这样组成了8主8从的Redis Cluster集群,那么主人公之前跟云供应商说过要万兆的虚拟机,但是需要网络升级后才有,所以这套集群每个虚拟机的带宽其实是千兆。话不多说了,无图无真相啊,但是作者没有没有给我图啊。下期补上。

虽然目前我们没有专业的管Redis同学,但是Redis相关的监控系统,我们做的还是不错的,从监控获得几个消息,流量满了,慢查询告警也发了一堆,都是同一个key,使用命令都是LRANGE 0 -1。由此我们第一想法是,我们是不是遇到大key了,登陆查看一下key大小,一会8M,一会48M,从来没有低于8M,大部分时间都是几十M大小,而且失效时间一直刷新,于是将key发出来,让业务研发看看是什么问题。

问题确认

经过几分钟查阅代码,最终确定是逻辑有问题以及redis key类型使用不当造成。为什么说key类型使用不当呢?key存的是门店信息,包括经纬度之类很多信息,一千多家门店以列表形式存放,大小接近8M,而且要命的是,每次读取门店信息都是”LRANGE 0 -1″方式去取,由于最近才上的功能,刚开始没怎么用,所以流量没怎么体现出来。另外读取逻辑也是有问题的(逻辑是读取key,如果为空,则去MySQL中查询,查询完成后push到redis的list中,这其中每一步都是单独的),当多线程并发去读这个key时,多个线程返回的都为空时,都先往MySQL中查相关门店信息,然后push到这个list里面去,导致这个list有时候到上百兆,这么大之后只要几十个的并发,宽带分分钟跑满,知道原因后,将list以门店为维度去拆分,尽量精简内容,将不需要的字段全部删除,十几分钟后,整个世界似乎又安静了。

6.18活动系列之失败的优惠券活动-hotkey问题

今年618的时候,大家都在搞活动,当然,我们作为一个电商,少不了也开始蠢蠢欲动起来,于是,我们也策划优惠券的事情,刚开始说,优惠券是不限量的,所以大家都没有很在意,在app首页会有一个当前所有可用优惠券的小框框,有需要的点一下去领取即可。

主人公被甩锅

但是第二天来临的时候,不知道运营想要做什么,也搞整点抢券,然而并不通知我们,于是,618当天,离10点抢券开始还有几分钟的时候,发现我们app首页挂了,还没开始抢券已经先挂了,于是,整个公司又热闹了起来,看报错信息,部分是超时了,部分拿不到Redis连接,于是,大家纷纷又把锅推给了Redis。

主人公不服之调查真相

我们查看监控时,也发现,整个集群,只有一台Redis的连接数、带宽异常高,但是其他的都很正常,带宽还没达到瓶颈,但是也快了,整点抢券的券已经hash到每个集群的节点了,讲道理,就算是已经开抢了,也不至于只有一台Redis出现这样的情况啊,查看热key发现,疯狂刷的key竟不是这次每个整点抢券的key,于是经过研发一两分钟的排查,最终发现了是因为app首页的有一个调用可用优惠券的接口(全天不限量的),但是因为之前是不限量,不会有很大的并发,而这个优惠券信息都作为一个key放在其中某一台上面,value不是很大,平常并发不是很大,所以很少去关注,而我们增加了整点抢券后,大家在这个点都在疯狂刷app,而每刷一次都需要调用一下那个可用优惠券的接口,导致发生这种情况,等大家把事情搞明白,十点已经过几分了,所以这次抢券以失败告终,后面把这个不限量而内容不变的key放本地缓存了,后面的整点抢券都妥妥的过去了,所以设置key的时候要异常小心,考虑一下你的key会不会成为一个热点key,如果成为了热点key,该如何去优化。

既然问题发生了,下面直接放解决方案。

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

3 Replies to “Redis使用注意事项-某电商公司案例系列一”

  1. 登陆查看一下key大小,一会8M,一会48M,从来没有低于8M,大部分时间都是几十M大小,而且失效时间一直刷新,于是将key发出来,让业务研发看看是什么问题。
    1、我的缓存集群中数据量大概是50g,想要把大key找出来的话,有什么好建议,文章中提到的大key,一会儿8M,一会儿48M是怎么看的?
    2、失效时间一直刷新,这个是怎么看的?

发表评论

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