酒店预定系统

酒店预定系统本身设计过程中会遇到售卖系统两个常见问题，第一个同一个房间同一日期被多个订单预定，或者预定和库存数据不一致，这些都会涉及到金钱，需要在系统涉及是被重点考虑。

问题1:同一个房间同一个日期被多个订单预定

酒店商家考虑有顾客会取消订单，可以超卖10%的商品，但是需要保证同一个房间不能被预定多次。有两种场景可以导致同一个房间被预定多余多次，第一种是用户同一订单点击了多次，另外一种是多个用户同时预定了同一个房间。

对于第一种场景解决办法：当用户进入到下单详情页面是，服务端（客户端产生不可靠）产生一个唯一id作为幂等键跟随详情页信息返回。

对于第二种场景解决办法：

第一种是使用被关锁，在准备下单减库存时，使用select …for update 将这个库存表先锁起来，优点实现起来简单，确定，当需要锁定资源过多是，需要考虑各种资源的锁定顺序和关系，容易引起死锁。

第二种是使用乐观锁，在数据库里面增加一个version字段，当更新数据时，对于要更新记录加1，只有准备写入版本大于数据库版本才更新成功，否则重新从数据库获取，重复更新，存在一个自旋的过程，当竞争很激烈时整个服务性能会变差。

第三种使用数据库底层限制，CONSTRAINT check_room_count CHECK((total_inventory - total_reserved >= 0))，优点实现简单，缺点不是所有数据库都支持，并且当用户页面看到有库存，但可能下单不成功，引起用户不好体验，竞争激励时性能也会变差，整体来说不好的一面和乐观锁相似。

问题2:房间库存和订单数量不一致

在微服务设计中，有些公司库存和订单数据不在同一个数据库，如何保证库存和订单数量一致性将变成一个需靠考虑的问题：

第一种办法是使用分布式事务，两阶段提交2PC，可以保证强一致性，但是性能不好，真实中采取的很少。

第二种是采用最终一致性，下单的之前先锁库存（给库存设定一个锁定时间，过期自动释放锁定），然后再下单，如果下单失败或者没有没有支付，释放库存。
第三种：直接把库存和订单设计到同一个数据库里面，使用数据库的事物保证强一致性。

补充知识点

两阶段提交（Two-Phase Commit， 2PC），是分布式事务执行的一个过程，分布式事务执行分为三步骤，一个阶段协调者向所有参与者发送事物内容，询问是否可以提交事物，等所有参与者回复，所有参与者回复可以，才可以进入到第二阶段。第二阶段是协调者通知所有参与者执行分布式事务一些事准备，将undo和redo日志写入到事物日志中，只有所有参与者回复执行成功才会进入到第三阶段，否则撤销执行；第三阶段是协调者通知所有参与者提交事物，一个分布式事务才会执行成功，通常将前两个步骤成为第一个阶段，成为确认阶段。