文档概述了用户购票生成订单的业务流程，包括从分布式锁到Lua的优化过程，以及支付流程和支付宝回调接口的流程。在这个过程中，用户购票时会从缓存中扣除余票数量，并将座位状态从未售卖修改为锁定中。支付回调过程中，缓存中的座位状态会从锁定中修改为已售卖。 ![[支付宝回调通知订单服务接口.webp]] 文档的核心在于解释数据库的状态是如何更新的，以及如何保证缓存和数据库的一致性。

在支付回调执行后，会将更新节目和座位的数据消息发送到延迟队列中，由节目服务消费消息进行数据库的更新。这里使用了ProgramOperateDataDto类来封装需要更新的数据，并通过DelayOperateProgramDataSend类将消息发送到延迟队列。节目服务通过DelayOperateProgramDataConsumer类消费消息，并调用ProgramService的operateProgramData方法来更新数据库中的座位状态和票档数量。

为了保证幂等性，操作前会验证节目ID和座位ID集合。更新操作包括验证座位状态、更新座位状态为已售卖，以及更新票档数量。这里使用自定义SQL来批量更新票档数量。

文档还提到了数据库和缓存一致性问题。在购票流程中，始终使用Redis的余票数量进行验证，扣减和还原操作也是在Redis中进行的，因此不会出现超卖的情况。大麦网不显示余票数量，因此避免了数据库和缓存显示不一致的问题。即使有余票数量显示的功能，订票系统的余票数量也不是实时更新的，因此这个问题在实际中并不严重。

最后，文档指出，订单服务更新缓存数据后，通过延迟队列发送消息到节目服务更新数据库数据。延迟队列可以替换成Kafka等消息中间件，数据库和缓存的不一致延迟时间取决于消息中间件的延迟时间，但由于消息中间件的效率高，这种不一致性的影响很小。 业务讲解-如何保障节目数据在缓存与数据库间的一致性