12306（中国铁路客户服务中心）的购票系统是一个典型的高并发、高流量的系统。在春运和节假日等高峰期间，购票需求量极大，用户的请求频繁且集中，系统必须通过多种技术手段来进行 限流 和 负载均衡，确保购票服务的稳定性与可靠性。以下是12306购票系统实现限流的技术方案和细节。

1. 限流与排队

12306的购票系统通过一些方式来管理用户请求，避免因过多的并发请求导致系统崩溃或响应过慢。以下是主要的限流机制：

1.1 用户排队机制

当大量用户同时访问12306时，为了避免系统过载，12306采用了排队机制。用户在访问购票系统时，如果请求量超过了系统处理能力，用户会被引导到一个虚拟的“排队页面”。这个页面展示了排队人数和预计等待时间。

• 排队逻辑：当请求到达12306时，系统根据请求的并发量和当前系统负载，决定是否将该请求加入排队队列。系统会按照排队顺序逐一处理请求，确保每个请求都能获得处理，但不会让过多请求直接打到后台数据库和核心服务上。
• 动态调整排队人数：根据系统的实时负载，排队页面的提示信息会不断调整，给用户实时反馈。例如，如果负载较高，系统可能会提示排队人数过多，建议稍后重试。

1.2 令牌桶与漏桶算法

为了控制请求的流量，12306可能会使用流行的 令牌桶算法（Token Bucket）和 漏桶算法（Leaky Bucket）等限流算法。这些算法能够控制单位时间内进入系统的请求数量，防止瞬时流量过大。

• 令牌桶算法：请求进入系统前，先要从桶中获取令牌。如果令牌桶为空，则请求会被延迟或者丢弃，避免系统过载。令牌桶有固定的速率生成令牌，从而控制系统的负载。
• 漏桶算法：类似于令牌桶，漏桶算法也有流量限制的作用。它规定每秒能够处理的请求量，如果超过了设定的速率，超出的请求将被丢弃或者延迟，确保系统在高并发时能够平稳运行。

1.3 滑动窗口

12306也可能使用 滑动窗口算法，这是另一种限流的常用手段。它允许系统在一定时间窗口内处理一定数量的请求，超出部分会被限制。

• 实现方式：例如，系统可能允许每个IP或每个用户在10秒内最多发起5个请求，10秒后，窗口会重新计算，清除过期的请求，允许新的请求进来。

2. 消息队列（MQ）

为了处理高并发场景，12306可能会使用 消息队列（MQ） 来解耦前端请求和后台业务处理。通过引入消息队列，系统可以将一些非实时的业务处理异步化，避免过多的并发请求直接打到数据库和核心服务上。

• 具体流程：

  • 当用户提交购票请求时，前端系统将请求放入消息队列（如 RabbitMQ 或 Kafka）中。
  • 后端系统从消息队列中异步获取请求，按照队列中的顺序逐一处理。这种方式避免了直接对数据库和核心系统进行高并发访问，减轻了系统压力。
  • 消息队列通常配合 消费者 和 生产者 模式，消费者按一定速率消费消息，避免过度消费。

• 优势：

  • 解耦：前端系统与后端系统通过消息队列解耦，避免了直接通信导致的性能瓶颈。
  • 流量削峰：消息队列能有效分散请求负载，在高并发时能将请求缓存在队列中，平缓流量波动。
  • 异步处理：部分购票业务（如发票生成、支付验证等）可以通过异步方式处理，避免阻塞主流程。

3. 库存校验与“库存不足”提示

购票时，12306需要实时查询票务库存并做库存校验。在高并发下，系统会面临 库存不足 的情况，这时会向用户显示“库存不足”的提示。其具体实现细节如下：

3.1 分布式锁与数据一致性

为了确保多个用户在同一时刻不会同时购买到同一张票，12306通常会使用 分布式锁 来保证同一时刻只有一个请求能够修改库存。

• 分布式锁的实现：12306可能使用 Redis、ZooKeeper 等分布式存储系统来实现分布式锁。每次用户请求购票时，系统会首先获得锁，确保在锁释放之前其他请求无法修改库存信息。
• 锁粒度：为了提高并发效率，分布式锁的粒度通常会做得比较精细，可能会按照车次、时间段等维度来进行锁定，而不是整个库存。

3.2 库存同步与实时更新

12306系统需要实时更新票务库存信息，并且保持高并发下的数据一致性。系统通常使用 缓存（如 Redis）来存储票务信息，减少数据库查询压力。

• 库存缓存：在高并发请求下，Redis等缓存系统能迅速提供库存数据，避免数据库成为瓶颈。
• 异步更新：当库存发生变化时，系统会异步更新数据库中的真实数据，保证数据库的最终一致性。Redis的缓存会有过期机制，确保库存信息的准确性。

3.3 最终一致性

在高并发情况下，库存的实时更新可能会存在一定的延迟或数据不一致问题，因此12306需要使用 最终一致性 的策略。在实际操作中，票务的库存减少是通过一系列异步处理和检查机制来保证的，确保最终的库存状态准确。

4. “排队过多，请稍后重试”

当用户在排队过程中，系统发现用户请求的并发量已经过高，无法继续处理时，可能会提示“排队过多，请稍后重试”。

• 具体原因：这种情况通常发生在系统的并发请求达到极限时，服务器通过限流策略控制系统流量。此时，用户请求被暂时拒绝，提示用户稍后再试，减少系统的压力。
• 技术实现：这种提示通常与 滑动窗口 或 令牌桶 算法等限流策略密切相关。当流量过高时，用户的请求会被暂时拒绝，给出排队信息，等待流量恢复后再进行请求。

总结

12306购票系统的限流和流量控制是一个复杂的技术体系，结合了多种技术来保证系统的高并发处理能力，避免系统崩溃或性能瓶颈。主要包括：

• 排队机制：将用户请求排队处理，避免高并发直接冲击后台。
• 限流算法：令牌桶、漏桶和滑动窗口等算法控制系统流量，避免过载。
• 消息队列：使用消息队列异步处理购票请求，减轻系统压力，平滑流量。
• 库存校验与分布式锁：确保库存的实时更新和一致性，避免超卖情况。
• 最终一致性：在高并发时确保数据的一致性，使用缓存和异步处理策略提高效率。

通过这些技术手段，12306系统能够有效应对大量用户的并发访问，保证购票流程的稳定性和准确性。