之前我们讲了通过数据库事务来保证扣库存的一致性，但这势必会造成TPS降低，那么我们有办法提高整体的TPS吗？库存分片就是一个不错的解决方案。
什么是库存分片？简单来说就是把原来一行库存记录拆分成多行。
首先我们看下TPS低的原因在哪，怎么造成的。假设我们现在有一个热点商品，当有大量订单请求扣一个库存的时候，为了保证一致性，第一个进入的session会开启一个事务->更新库存->提交事务。这个时候其他session会被阻塞，一直要等到第一个session提交。所有的并发请求到这里都会串行，总的TPS≈1秒/每个session处理时间。
库存分片怎么做呢，首先假设库存表有一行记录了商品id，库存数量(100)。
| 商品ID | 库存 |
|---|---|
| 123456 | 100 |
我们可以新建一张分片表，记录商品id，分片编号，并将总库存数均匀分布到分片表中：
| 商品ID | 分片编号 | 分片库存 |
|---|---|---|
| 123456 | 1 | 30 |
| 123456 | 2 | 30 |
| 123456 | 3 | 40 |
假设现在分成3份，请求扣库存的时候直接扣分片表的库存，根据分片编号通过负载均衡策略均匀的去扣分片库存。那么总的TPS = 原TPS*3。当然这只是一个大概量，因为逻辑上更复杂了。
看起来很简单吧，当然这只是理论层面的，真正实现起来还有很多要考虑的东西，比如如何均匀的分片库存，假如上表中的一样库存数不能被分片整除，势必会有一个分片数量多于其他分片，那么如何均匀的去扣每个分片的库存，策略是什么？其他分片扣完后最大的分片还有剩余该怎么办？是否需要动态分配库存分片能力？还有对于库存深度不一的商品是否都适用于库存分片？比如正常频率售卖的商品其实完全没有必要做库存分片，还有库存较浅的商品或者秒杀品也没有必要做库存分片，做了反而可能会给系统造成压力，甚至搞成雪崩。等等这些都需要在详细设计的时候考虑进去。
