通过 **Redis Lua 脚本原子特性**，完成用户购票令牌分配，通过令牌限流以应对海量用户购票请求。

业务背景：购票流程的核心逻辑是什么？：

1.通过自定义注解实现幂等性，防止用户重复提交（通过uniqueKeyPrefix+key来生成唯一注解，当相同的请求发送过来即返回Message）2.通过责任链来验证提交参数 3.通过分布式锁来避免分配相同的座位 4.远程调用订单服务生成订单号（基因法） 5.创建订单记录 6.延迟关闭订单（如何将消息消费在订单服务，涉及到远程循环依赖，需要避免）

但是！！！V1版本购票存在问题（为了保障列车座位不超卖以及一个座位不分配给多名用户，选择使用分布式锁来保障数据安全和一致性。）：1.考虑到节假日高铁系统的瞬时高并发压垮系统，大量的抢票请求卡在获取分布式锁阶段（一般tomcat同一时间最多200个请求）因此大量请求会因为分布式锁的申请而发生阻塞，导致请求无法快速处理。这会导致后续请求长时间被阻塞，使系统陷入假死状态。无论请求的数量有多大，系统都无法返回响应。此外，随着请求的积累，还存在内存溢出的风险。更糟糕的是，如果 SpringBoot Tomcat 的线程池被分布式锁占用，查询请求也将无法得到响应。2. v1使用的分布式锁是非公平锁，为了避免这种情况，我们需要按照公平锁的方式请求和释放锁，使用后的场景就是释放锁后再获取锁要严格按照请求分布式锁的先后顺序执行。3.假如一趟列车有几十万人抢票，但是真正能购票的用户可能也就几千人。也就意味着哪怕几十万人都去请求这个分布式锁，最终也就几十万人中的几千人是有效的，其它都是无效获取分布式锁的行为。那这块的分布式锁逻辑是不是可以优化呢？比如不让所有抢购列车的用户去申请分布式锁，而是让少量用户去请求获取分布式锁。这样优化的话，可以极大情况节省 Redis 申请分布式锁的开销压力。4. v1 版本购票接口的分布式锁锁定规则是锁定整个列车，也就是列车的唯一键列车 ID。相当于同一时间一趟列车只允许单个用户进行分配座位、创建订单等流程。如何去解决效率低的问题？

12306 中的限流算法类似于令牌桶，但是令牌通会以固定速率生成令牌，但是咱们这个不会，而是将没有出售的座位当作一个个令牌放到一个容器中。为了区分令牌桶，咱们下文称呼为令牌容器。用户购票需要去令牌容器获取令牌，成功则可以进入接下来的流程，获取失败直接返回，获取令牌后，令牌也会相对应的减少避免超卖。因此只有少部分获取令牌的用户可以请求分布式锁。外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

**执行流程：**1.如果令牌容器在缓存中失效需要重新读取并放入缓存；2.准备执行 Lua 脚本的数据；3.最终的执行 Lua 脚本获取令牌。