为什么要使用redis：线下商城接口峰值直接压垮数据库的补救方案

门店核销小程序上线初期，运营压根没测算周末到店客流，所有人都在讨论为什么要使用redis，后台运维只抱着MySQL硬扛，没提前搭建缓存层。

周六下午两点商场人流彻底爆了，上千台手机同时调取核销码、会员积分数据，数据库连接池瞬间打满，页面加载直接转圈十分钟，收银台没法核销优惠券，顾客围在柜台前不停催促。线下门店店长接连打了五个电话到办公区，机房监控大屏上数据库CPU数值一路冲到百分之百，运维盯着后台报错日志反复刷新，短时间内大量重复查询全部砸向底层数据表，索引优化的方案临时改不动，分库分表的改造周期最少半个月，当下完全没有缓冲的余地。

临时拉来云服务器部署redis，半小时内完成基础配置，把门店核销码、会员基础信息全部写入缓存。线上同步调整接口代码，用户发起查询请求时优先读取redis内的数据，只有缓存里没有对应信息，才会去查询MySQL数据库。

调整完成之后重启小程序服务，商场里持续上涨的访问量依旧没有回落，但数据库的负载数值肉眼可见往下掉，CPU稳定在三十以内，收银台扫码核销的响应速度直接压缩到百毫秒级别。当时线上同步跑着两百多个核销请求，数据库只承接零星的新增核销记录，不再需要直面海量重复的查询操作。

门店运营当天晚上复盘客流数据，周末峰值查询量达到平日的八倍，要是依旧只依靠原生数据库运行，大概率会出现数据库宕机的状况，线下门店全天的核销业务都会彻底停滞。

后来才反应过来，门店的会员信息、核销券码这类数据，短时间内不会产生大幅改动，频繁重复查询只会白白消耗数据库算力，redis天然适配这类高频读取的数据场景。缓存拦截掉绝大部分重复请求，数据库只需要处理新增、修改这类写入操作，读写压力直接拆分开来。

有次线下做满减活动，提前一天把活动商品信息全部预加载进redis，活动开场十分钟上万用户同时查询活动规则，数据库全程没有出现负载异常，全程没有顾客反馈页面卡顿。换成之前无缓存的架构，这个流量规模足够让数据库产生长时间阻塞。

试过单独优化MySQL索引，调整数据表存储引擎，调大数据库连接池参数，这些操作只能小幅缓解查询卡顿，没办法从根源隔绝海量重复查询对数据库的冲击。redis的内存存储机制，读取数据的速度远高于磁盘存储的关系型数据库，大量请求不用穿透到底层磁盘，服务器整体资源占用都会下降不少。

门店运营也曾提出过搭建本地内存缓存，不用额外部署redis服务，试过之后发现线下多家门店的小程序数据无法同步，单台服务器的本地缓存数据独立存在，跨门店调取会员信息会出现数据不一致的问题。redis自带持久化机制，集群部署之后多台服务读取同一份缓存数据，门店之间的数据互通不会出现偏差，就算服务器短暂重启，缓存内的核心数据也不会直接丢失。

那天商场客流散去之后，坐在机房看着平稳跳动的监控曲线，手里翻着当天的接口访问日志，才真切摸透缓存落地的实际价值。