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

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

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

但是！！！V1版本购票存在问题（为了保障列车座位不超卖以及一个座位不分配给多名用户，选择使用分布式锁来保障数据安全和一致性。）：1.考虑到节假日高铁系统的瞬时高并发压垮系统，大量的抢票请求卡在获取分布式锁阶段（一般tomcat同一时间最多200个请求）因此大量请求会因为分布式锁的申请而发生阻塞，导致请求无法快速处理。这会导致后续请求长时间被阻塞，使系统陷入假死状态。无论请求的数量有多大，系统都无法返回响应。此外，随着请求的积累，还存在内存溢出的风险。更糟糕的是，如果 SpringBoot Tomcat 的线程池被分布式锁占用，查询请求也将无法得到响应。2. v1使用的分布式锁是非公平锁，为了