所以为了应对这种高并发场景，业界提出了一种方案叫 热点散列，即今天群里讨论的库存分桶。
其方案如下图所示：将同一商品的库存提前分配至多个“桶”中，根据路由规则（随机、UID取模）将库存请求路由至不同的桶，从而将集中于单实例的请求分散，此方案类似于水平扩展。
图片
至于“分桶”的技术实现，很多技术文章或解决方案都建议采用Redis来实现。具体而言，对任一秒杀活动的商品，可将其分成N份，每份对一个缓存Key，缓存Key的构成必须遵循一定的规律，便于路由，示例如下：
key: inventoryId_1，value: 库存数量
key: inventoryId_2, value: 库存数量
...
key: inventoryId_N, value: 库存数量
在扣减库存时，可以根据Key的编号区间，采用随机算法，UID取模等方式确定一个编号，然后组装Key访问缓存。
举个例子，假如inventoryId为20221821，将库存分配至100个桶，则根据相应Key的区间为[1,100]。
服务端收到商品库存扣减请求后，将请求中的参数UID取模，假设UID % 100 = 67，则组装Key为 20221821_67，基于20221821_67扣减对应缓存桶中的库存。
热点散列的核心思想为：在缓存中扣减库存，以提升系统的吞吐量；缓存扣减成功后，异步向数据库写入库存扣减流水并更新库存；此外，还需要通过定时任务等机制实现缓存与数据库的库存总量同步。
这个方案看上去很不错，但也会存在如下三个问题：
一、在缓存中扣减库存如何保证幂等性呢？若幂等性防控不足，则可能出现重复扣减，进而导致少卖。
二、缓存写操作和数据库写操作无法通过事务机制来保证强一致性，那么该如何有效的保证库存数据的一致性呢？
三、用户所见的库存应为总库存，即便总库存充足，一旦分桶，如何保证用户请求被路由到的分桶油足够的库存呢？
所以个人觉得，热点散列在理论上是解决库存热点问题最有效的方案，但在实际应用中，需要考虑的细节非常多。基于缓存的库存扣减的方案是比较粗糙的，它只满足一些特定场景的需要。对于淘宝、京东这类在想商品规模达数十亿的大型电商平台而言，所面临的问题要复杂得多，除了稳定性、可靠性、一致性，还包括库存分配，库存碎片，库存扩缩容、流量倾斜、商品少卖、商品超卖等。
上次去阿里交流的时候，阿里专家唐三说：在阿里，库存架构采用的方案是做库存单元化架构，这种方案应该是大型电商平台库存系统的终极解决方案。
