12306候补购票背后的Redis黑科技

12306候补购票背后的Redis黑科技

引用

CSDN

等

11

来源

1.

https://blog.csdn.net/shumeigang/article/details/137976144

2.

https://blog.csdn.net/qq_45038038/article/details/135992700

3.

https://cloud.baidu.com/article/3139679

4.

https://blog.csdn.net/u013625306/article/details/136842107

5.

https://blog.csdn.net/huanghuozhiye/article/details/136077535

6.

https://blog.csdn.net/qq_44701525/article/details/140251414

7.

https://www.cnblogs.com/0630sun/p/18169618

8.

https://juejin.cn/post/7372443227939012646

9.

https://news.hubeidaily.net/pc/c_3420434.html

10.

https://cloud.tencent.com/developer/article/2465674

11.

https://cloud.tencent.com/developer/article/2403499

每年春运期间，12306都会迎来一场“大考”。作为全球最大实时票务交易系统，它需要应对百万级并发访问和复杂的库存管理挑战。2019年推出的候补购票功能，更是对系统提出了新的要求。而在这背后，Redis这位“隐形功臣”发挥了关键作用。

与普通电商不同，火车票库存是动态变化且相互影响的。比如一个行程涉及多个站点，卖出一张票可能会影响多个区段的库存。此外，还要应对黄牛抢票、用户频繁刷新等带来的巨大压力。

1. 高性能缓存提升访问速度

Redis作为内存数据库，具有极高的读写性能。12306利用Redis的Hash结构存储票源信息，将车站到车站之间的车次、余票、票价等信息缓存起来。当用户查询时，直接从Redis读取，大大加快了响应速度。

2. 分布式锁保证数据一致性

在高并发场景下，多个用户可能同时购买同一张票。12306通过Redis实现分布式锁，确保同一时刻只有一个用户能成功购票，避免了超卖问题。

3. 本地库存+Redis统一管理

为了提高系统可用性，12306采用了本地库存和Redis双重管理的模式。每台服务器本地存储一定数量的库存，当用户购票时先扣除本地库存，再异步更新Redis中的库存信息。这种设计既提高了并发处理能力，又解决了机器宕机导致的库存损失问题。

4. 消息队列实现异步处理

用户提交候补订单后，系统会将其放入Redis的消息队列中。这样即使在高并发情况下，系统也能有序处理每个请求，不会因为瞬时压力导致系统崩溃。

5. 限流和熔断机制

Redis的计数器功能被用来实现请求限流，防止系统被恶意攻击或突发流量击垮。当检测到异常流量时，系统会自动熔断，保护核心服务的稳定运行。

在Redis中，余票信息和数量是分开存储的。余票信息的key设计为：

remaining_ticket_info:{year}:{month}:{day}:{起始车站}:{终止车站}

value包含车次号、余票信息、票价等。而余票数量则单独存储：

remaining_ticket_num:{year}:{month}:{day}:{起始车站}:{终止车站}

这种设计的好处是，当余票数量变化时，不需要频繁更新其他信息，提高了系统效率。

1. 性能提升：通过缓存和异步处理，系统能够轻松应对百万级并发访问。
2. 用户体验优化：候补购票功能的实现，让购票过程更加公平透明。
3. 安全性增强：分布式锁和限流机制有效防止了黄牛抢票。
4. 运维效率提高：实时监控和报警机制让系统故障能够及时发现和处理。

12306候补购票系统的成功，离不开Redis这位“黑科技”的支持。它不仅解决了超高并发和复杂业务逻辑的挑战，还为用户带来了更便捷、公平的购票体验。这个春运，让我们向这位“隐形功臣”致敬！