高并发|秒杀 抢票狂欢：基于Redis的高效抢票系统设计与实现，利用Redis优化抢票流程

高并发|秒杀 抢票狂欢：基于Redis的高效抢票系统设计与实现

最新消息：2025年春运抢票大战再创新高

据2025年8月最新数据显示,今年春运期间某大型票务平台单日最高访问量突破15亿次，热门线路车票在开售后平均0.3秒内售罄，面对如此惊人的并发压力，传统数据库架构已完全无法应对，而基于Redis的高效抢票系统正成为行业标配解决方案。

为什么传统系统在抢票场景下会崩溃？

"又卡死了！页面根本刷不出来！"——这可能是每个参与过抢票大战的用户共同的愤怒，传统系统在高并发场景下主要面临三大致命问题：

1. 数据库成为瓶颈：关系型数据库的ACID特性导致其并发处理能力有限，当数万用户同时查询和下单时，数据库连接池迅速耗尽。

2. 超卖问题：在库存扣减时，多个请求同时读取到"还有票"的状态，导致实际售出数量超过库存。

3. 系统雪崩：某个服务节点崩溃后引发连锁反应，最终整个系统不可用。

Redis如何成为抢票系统的"救世主"？

Redis之所以能解决这些问题,主要依靠其三大特性：

1. 内存操作：数据存储在内存中，读写速度达到微秒级，是传统磁盘数据库的100倍以上。

2. 单线程模型：避免了多线程竞争，保证原子性操作。

   

3. 丰富的数据结构：String、Hash、List、Set、ZSet等数据结构可以灵活应对不同场景。

实战：基于Redis的抢票系统核心设计

系统架构概览

用户层 → 负载均衡 → 应用服务器集群 → Redis集群 → 数据库(最终落地)

关键Redis数据结构设计

库存预热：提前将票务库存加载到Redis

# 设置高铁G123次北京-上海的车票库存
SET ticket:G123:2025-02-10:business_seat 100

购票记录：使用Hash存储用户购票信息

HSET order:20250210_123456 user_id 10086 mobile 13800138000 seat_num 08车12F

热门车次缓存：ZSET实现排行榜

ZADD hot_trains 1000 G123 800 D123 600 K123

核心抢票流程实现

def purchase_ticket(user_id, train_no, date, seat_type):
    # 1. 校验用户是否已购票
    if redis_client.sismember(f"user:{user_id}:orders", f"{train_no}:{date}"):
        return {"status": "fail", "msg": "每人限购一单"}
    # 2. 原子性扣减库存
    remaining = redis_client.decr(f"ticket:{train_no}:{date}:{seat_type}")
    if remaining < 0:
        # 库存不足回滚
        redis_client.incr(f"ticket:{train_no}:{date}:{seat_type}")
        return {"status": "fail", "msg": "已售罄"}
    # 3. 生成订单(先写Redis再异步落库)
    order_id = generate_order_id()
    redis_client.hmset(f"order:{order_id}", {
        "user_id": user_id,
        "train_no": train_no,
        "date": date,
        "seat_type": seat_type,
        "status": "unpaid",
        "create_time": datetime.now()
    })
    # 4. 设置15分钟支付时限
    redis_client.expire(f"order:{order_id}", 900)
    # 5. 记录用户购票信息
    redis_client.sadd(f"user:{user_id}:orders", f"{train_no}:{date}")
    return {"status": "success", "data": {"order_id": order_id}}

防刷策略实现

限流控制：使用Redis计数器实现IP限流

def check_rate_limit(ip):
    key = f"rate_limit:{ip}"
    current = redis_client.incr(key)
    if current == 1:
        redis_client.expire(key, 60)  # 60秒窗口
    return current <= 100  # 每分钟最多100次请求

验证码防护：Redis存储验证码及错误次数

def verify_captcha(session_id, user_input):
    key = f"captcha:{session_id}"
    correct_code = redis_client.get(key)
    if not correct_code:
        return False
    if user_input == correct_code:
        redis_client.delete(key)
        return True
    else:
        # 记录错误次数
        error_count = redis_client.incr(f"captcha_error:{session_id}")
        if error_count >= 3:
            redis_client.delete(key)  # 强制刷新验证码
        return False

性能优化进阶技巧

Redis集群部署方案

• 数据分片：按车次号hash分片，确保同一车次请求落到同一节点
• 读写分离：热数据从节点提供读服务
• 持久化策略：AOF每秒同步+RDB每小时备份

热点数据处理

# 使用本地缓存+Redis多级缓存缓解热点车次查询压力
def get_train_info(train_no):
    # 先查本地缓存
    local_cache = get_from_local_cache(train_no)
    if local_cache:
        return local_cache
    # 再查Redis
    redis_data = redis_client.get(f"train_info:{train_no}")
    if not redis_data:
        # 回源数据库
        db_data = db.query_train_info(train_no)
        # 设置Redis缓存(随机过期时间防缓存雪崩)
        redis_client.setex(f"train_info:{train_no}", 
                          random.randint(300, 600), 
                          db_data)
        redis_data = db_data
    # 写入本地缓存(短期有效)
    set_to_local_cache(train_no, redis_data, 60)
    return redis_data

库存回滚机制

def cancel_order(order_id):
    # 1. 查询订单信息
    order_info = redis_client.hgetall(f"order:{order_id}")
    if not order_info or order_info["status"] != "unpaid":
        return False
    # 2. 回滚库存
    redis_client.incr(
        f"ticket:{order_info['train_no']}:{order_info['date']}:{order_info['seat_type']}"
    )
    # 3. 更新订单状态
    redis_client.hset(f"order:{order_id}", "status", "canceled")
    # 4. 移除用户购票记录
    redis_client.srem(
        f"user:{order_info['user_id']}:orders",
        f"{order_info['train_no']}:{order_info['date']}"
    )
    return True

实测效果对比

我们在模拟环境中对传统方案和Redis方案进行了压测对比：

避坑指南：那些年我们踩过的Redis坑

1. 大Key问题：某个热门车次的信息被缓存为一个大JSON，导致节点负载不均

   解决方案：拆分为多个Hash字段存储

2. 缓存穿透：频繁查询不存在的车次号

   解决方案：布隆过滤器预先拦截

3. 集群脑裂：网络分区导致数据不一致

   

   解决方案：合理设置cluster-node-timeout

4. 持久化阻塞：BGSAVE导致服务短暂不可用

   解决方案：在从节点执行持久化操作

Redis抢票系统的演进方向

1. AI预测预热：基于历史数据预测热门车次，提前做好资源分配
2. 边缘缓存：结合CDN将部分数据推到离用户更近的位置
3. 多级库存：实现车站、区段、席别的动态库存调整
4. 无感排队：采用虚拟队列技术，避免用户反复刷新

写在最后

2025年的技术实践表明,合理运用Redis可以轻松应对百万级并发的抢票场景，但技术只是手段，真正的挑战在于如何在保证公平性的前提下提升用户体验，或许未来某天，当铁路运力足够充沛时，我们才能真正告别这场年复一年的"抢票大战"，在此之前，作为技术人，我们能做的就是不断优化系统，让这场年度"战役"少一些崩溃，多一些顺畅。