微服务库存并发与数据一致性
库存值是一个热点数据，下单时会发生高并发扣减操作，库存本身可以做为一个模块，为任何模块或服务提供库存这个热点数据的高并发操作的能力。
高并发下单对于用户请求的响应速度要求也比较高，需要尽量避免长时间的锁操作，可以采用 tcc+库存预留 的方案。
库存回退，退款时的操作，通常是对已扣减的库存进行回退，可以采用以下两种方案：
AT模式（不建议）：AT模式的问题在于全局锁可能被绕过，集中化管理的库存可以有效避免这个问题，但是在全局事务提交前库存资源都会被锁定，影响用户下单。
MQ事务：数据最终一致性，回退库存本身对实时性高求不高，退款操作后5秒内库存回退都能接受，同时不存在无库存可退的情况。
注：操作中除了需要记录库存操作外，还需要记录并管理所有资源消耗的库存数量，方便追踪且可做为库存回退时的回退依据，避免调用异常导致回退数量超过订单本身的数量。
tcc+库存预留方案存在一个问题，由于三阶段都数据对热点数据操作，所以三阶段都需要使用分布式锁，这样会导致业务执行串行化，单热点高并发下性能很差。另外虽然tcc是异步的，但是seata事务中会同步等待confirm执行后再返回接口请求，这里可能会拉长锁等待时间，比如：请求1执行完try，请求2抢到锁后开始执行try，请求2confirm阶段等待锁。最终请求1的响应时间为try*2+confirm的时长。
优化tcc方案：
1.confirm异步化：改善请求响应时间
#整体性能并无提升，锁冲突问题依然存在
其他库存方案：
1.库存分片：将单库存分成N个分片，userId%n得到分片库存，提升库存N倍并发能力
#引入复杂概念，需要注意处理分片库存不足时的策略
2.缓存+异步入库：redis缓存数据库值并提供数据操作，redis原子操作后记录操作异步写入数据库
#缓存数据同步复杂，缓存数据可能丢失等问题需要额外处理机制
取消数据库乐观锁，利用where自检大于0控制超卖问题，并发能力比分布式锁更高。