带你从0到1实现一个中间件-速率缓存中间件

✨这里是小松猿的博客✨小松，欢迎您的到来~✨

🍅系列专栏：无🍅

✈️本篇内容: 从0到1实现一个中间件-速率缓存中间件

🍱本篇收录完整代码地址：无🍱

楔子

灵感来自于一次线上事故，在一次秒杀活动开始之前，由于活动开始前没有对app各应用进行大规模的压测，只是进行了一些主要流程场景的压测。秒杀活动预约人数有9000多人，运维和高管都是在加机器，以为加机器就能扛过这一关，但是没有想到，应用会带来毁灭性的灾难。由于对于压测的结果觉得可以扛过这一次秒杀活动，基本上对所有接口都没有做缓存操作，只是在流量入口处使用sentinel做了限流（GTW网关），QPS值也是相当的大，设置的是2万，但是秒杀活动晚上一开始，app瞬间加死，还影响到了线下门店的业务（因为订单中心也被假死了）

这次事故的主要原因有两个：

1:第一点就是限流没有做好，太过理想化，在app加死期间对各应用作了限流，QPS在200左右，app逐渐恢复正常，说明各应用能承受的QPS只在几百以内，没有提前测出来这个阈值是不应该的

2:很多无关紧要的接口没有做缓存，而且还要访问db，这次事故的第二个主要原因就是DB连接不够，导致服务一直处于等待连接的状态，进而导致服务加死，最终导致app不可用，整个app处于加死状态，服务链路全崩

我就是站在这次事故的视角下思考了实时的解决这个问题，限流这方面已经有了sentine