自动售货机后台并发量上来了怎么办？用Redis做缓存，4个策略搞定高频查询、库存实时扣减和支付防重，性能提升5倍不是梦。
售货机后台的性能瓶颈在哪里？
一台自动售货机的后台系统，随着设备规模的扩大，性能问题会逐渐暴露。一个典型场景：1000台设备同时在线，每台每10秒上报一次心跳和状态数据，后台每秒要处理100个写入请求。再加上用户端的商品查询、库存查看、历史交易查询------数据库很容易扛不住。
Redis 作为高性能的内存数据库，在智能零售后台系统中扮演着关键角色。它能把热点数据从MySQL等关系型数据库中解放出来，大幅提升读写速度。
策略一：热销商品缓存，扛住高并发查询
用户打开小程序或者售货机屏幕，第一件事就是看有哪些商品、多少钱。这个查询频次最高。
传统方案每次都去查MySQL的商品表，查询量大时数据库响应变慢，页面加载超过3秒用户体验就很差了。
Redis的解决方案是在内存中存储每台自动售货机的商品列表，用Hash数据结构管理。Key格式类似"机器编号:商品列表"，商品信息更新后写入Redis并设置过期时间。查询时先读Redis，命中直接返回，未命中再查MySQL并回写到Redis。这样商品查询响应时间能从50毫秒降到1毫秒以内，数据库查询压力减少90%以上。
策略二：库存实时扣减，防超卖
两台设备同时售出最后一个可乐，库存扣减不能出错。传统方案用MySQL行锁或者乐观锁控制并发扣减，在高并发场景下锁竞争导致吞吐量急剧下降。
Redis的解决方案使用原子操作做库存扣减和回滚。每次扣减前先读取库存，大于零才执行原子减一操作。如果原子减一后变成负数，说明超卖了，需要立即做一次原子加一回滚。
关键注意点是：Redis库存扣减后，必须通过消息队列异步同步到MySQL做持久化，避免Redis宕机导致库存数据全部丢失。同步时注意不要重复扣减，消息队列消费端要做好幂等处理。
策略三：支付去重，防止用户重复付款
用户扫码支付时网络卡顿，多点了两次确认，微信服务器回了两个支付成功的回调。传统方案在MySQL里用唯一索引约束订单号，重复插入会报错，但每次回调都写一次数据库性能差，还可能出现死锁。
Redis的解决方案使用分布式锁机制。用SETNX命令尝试获取锁，Key格式是"订单号:锁"，设置15秒过期时间。如果成功拿到锁才处理支付回调，拿不到锁说明已经在处理中，直接丢弃重复回调。这个方案避免了重复回调导致的重复出货，同时将支付处理的吞吐量提升了3倍。
策略四：设备在线状态实时监控
运维大屏上要实时显示所有自动售货机的在线离线状态。传统方案每10秒写一次数据库的设备心跳表，查询在线设备数时要跑COUNT查询，数据量大时非常慢。
Redis的解决方案使用Set结构存储在线设备ID。每台设备上报心跳时，执行EXPIRE命令设置25秒过期时间。定时任务每隔30秒扫描所有设备心跳Key，过期的自动移除。在线设备总数直接用SCARD命令获取，毫秒级返回。
关键注意点是：设备心跳Key的过期时间要设置成心跳间隔的2到3倍。比如设备10秒上报一次，过期时间设25秒，允许少量丢包不影响判断。
Redis使用中的注意事项
内存管理方面，Redis是内存数据库，数据量上来后内存消耗很快。建议设置maxmemory限制，并开启LRU淘汰策略。缓存类数据要有合理的过期时间。
持久化方面，库存数据等关键数据一定要做RDB加AOF双持久化。RDB做全量备份，AOF记录增量操作，最大限度保证数据不丢失。
连接池方面，高并发场景下每个请求都创建Redis连接会导致性能问题。用连接池复用连接，常见的连接池大小设置在50到200之间。
总结
Redis在自动售货机后台系统中有着不可替代的地位。从热销商品缓存的毫秒级响应，到库存扣减的原子操作，从支付去重的分布式锁到设备在线的实时监控------这4个策略覆盖了售货机后台最核心的高性能需求。
建议不要为了用Redis而用Redis。简单查询依然走MySQL，只在访问频次高、对响应时间敏感的环节引入Redis。做加法前先想清楚缓存一致性的问题，看业务能不能容忍短暂的数据不一致。