Open geek-LHW opened 2 years ago
项目中，为了保证秒杀流程中事务的一致性，通过@Transactional注解，将减库存和生成订单进行事务管理，保证该操作的原子性。 redis缓存和数据库的最终一致性注意依靠： （1）项目启动，预加载数据库库存到redis中，保证秒杀前数据一致性 （2）redis原子操作扣减库存，通过消息队列(rabbitmq )本身的可靠性操作（ack机制等），消费端幂等处理，保证数据一致性 （3）最好再数据库消费，保证最终一致性 注意： 1.因为消费队列极小概率会丢消息，或者数据库层面小概率操作失败，会导致数据库有剩余的库存，和redis最终一致性有所偏差。可以自己通过一些技术方案进行改进这个小概率问题。 2.秒杀场景中更多关心的是库存超卖，或者一个用户多次购买。对于这2个问题，项目中都以解决。对于小概率数据库剩余库存现象，在这个场景中可以接受。当然你也可以通过一些技术方案解决，从消息队列、dubbo调用、数据库消费失败三方面入手，更好地完善它。
谢谢您的解答！很好的解决了我的疑惑！
geek-LHW
commented
2 years ago geek-LHW
commented
2 years ago
项目中，为了保证秒杀流程中事务的一致性，通过@Transactional注解，将减库存和生成订单进行事务管理，保证该操作的原子性。 redis缓存和数据库的最终一致性注意依靠： （1）项目启动，预加载数据库库存到redis中，保证秒杀前数据一致性 （2）redis原子操作扣减库存，通过消息队列(rabbitmq )本身的可靠性操作（ack机制等），消费端幂等处理，保证数据一致性 （3）最好再数据库消费，保证最终一致性 注意： 1.因为消费队列极小概率会丢消息，或者数据库层面小概率操作失败，会导致数据库有剩余的库存，和redis最终一致性有所偏差。可以自己通过一些技术方案进行改进这个小概率问题。 2.秒杀场景中更多关心的是库存超卖，或者一个用户多次购买。对于这2个问题，项目中都以解决。对于小概率数据库剩余库存现象，在这个场景中可以接受。当然你也可以通过一些技术方案解决，从消息队列、dubbo调用、数据库消费失败三方面入手，更好地完善它。