商品大促(比如阿里双11)、热点新闻(比如微博xx明星塌房),都很可能会访问同一个Redis key,导致出现Redis热点,所有的流量都打向同一台服务器,占满物理带宽然后崩溃。一旦Redis崩溃,就会去访问更慢的存储比如数据库,从而产生严重的雪崩。
1、发现热点key
(1)业务预先判断。比如秒杀商品一定是热点key。
(2)客户端自动判断。自定义客户端SDK,然后上传监控数据到实时分析平台,再通过一些广播组件比如etcd、zookeeper、kafka等广播给所有的节点。
(3)服务端自动判断。服务端根据请求信息,自动判断热点。
2、处理热点key
(1)方式
基本上都是在做多级缓存。也就是除了Redis缓存,本地也增加几层缓存。常见的就是Guava-Cache做本地缓存。
(2)考虑的问题
怎么保证本地缓存一致性?当value发生变化时,首先变化的那台服务器一定是强一致性的,可以立刻invalid本地缓存。修改Redis的缓存后,一般会有广播,广播给所有的服务器,让他们检查本地缓存是否有这个热点key,然后invalid本地缓存,保证最终一致性。
怎么保证正常业务不受影响?划分专门的热点区域(比如阿里Tair,有赞TMC)热点区域的所有带宽、存储都是独立的,和普通缓存区域划分开。然后通过返回的数据热点标记,让客户端下次访问时去访问热点区域而非普通区域。并且当热点区域缓存失效后,去普通区域拿数据,如果数据仍然很热,那么还是把数据会继续异步存入热点区域。
怎么保证最小侵入性?一般会集成专用的sdk,把侵入性代码都封装起来,然后底层框架会用Jedis,来兼容业务的其他Redis访问。
为什么SDK封装,都很少用lettuce、redisson?因为jedis更接近底层,而且更稳定,容易封装。
能看到这里的你,一定是个热爱编程的同学。如果想要有计划地准备大厂面试,欢迎关注。