流程

1:通过库存服务缓存(缓存里面不仅有位图存储该时间点id的位置信息还有库存信息)的Redis获取令牌

2:拿着令牌向订单服务同步下单

        如果有令牌就执行下面的Redis，如果没有就直接返回

        扣减Redis库存缓存

                扣减成功:继续

                扣减失败:返回

                        前端重试整套流程

3:1锁2查3更新生成订单、本地消息表、发送消息给订单服务扣减库存，结果返回

1. 令牌机制 + Redis 缓存前置拦截（合理）

• 令牌本质是 “下单资格凭证”，通过库存服务的 Redis 缓存发放（结合位图可快速校验座位 / 时间点的可用性），能在高并发时快速拦截无资格请求（如已售罄场次），减少下游订单服务的压力。
• 位图存储位置信息（如座位是否被占用）设计巧妙：位图的位运算（如GETBIT判断单个座位状态，BITCOUNT统计剩余座位）高效且节省空间，适合体育场这类 “多位置单元” 的库存场景。

2. Redis 缓存扣减前置 + 失败重试（适配高并发）

• 步骤 2 先扣减 Redis 缓存，成功后再进入订单生成流程，本质是用 Redis 的高性能做 “第一道库存锁定”，避免大量无效请求打到数据库，符合高并发场景的 “缓存优先” 原则。
• 扣减失败让前端重试整套流程，能应对瞬时并发冲突（如多个请求同时抢最后一个库存），通过重试提高成功率，逻辑合理。

3. “锁 - 查 - 更”+ 本地消息表（保证一致性）

• 步骤 3 的 “1 锁 2 查 3 更新” 是数据库操作的标准防超卖逻辑：加锁避免并发修改，查实际库存做二次校验，更新订单和库存，确保数据库层面的数据准确性。
• 本地消息表 + 消息发送的设计，能保证 “订单生成” 与 “库存最终扣减” 的最终一致性（即使消息发送失败，可通过定时任务重试），解决分布式事务问题。

本地消息表解决分布式事务