不是一个好方案，一个商品库存数切片不同实例存储的确可以减少单个实例的压力，但是在业务上可行性有待商榷，如果当前切片实例没有库存，是不是要再请求别的切片实例？特别是库存数都被抢购完成后，后面的请求是不是都要请求4个切片节点做库存数的聚合才知道又没人退货，做库存数的聚合？

设计上是可行的，将秒杀请求也进行分片，库存的校验可以按照分库顺序扣。

我个人认为这个方式不是很好，因为单个sku分开后，需要对用户的请求做路由判断，假如一个用户请求本身就发出了两条，按照随机路由的方式，他有可能在两个切片中抢到商品。假如路由规则是固定的，那么会出现sku还有库存，但是用户就是抢不到的情况

如果秒杀请求能够比较均匀的分别打到4个实例上是没有问题的。 这个时候不返回剩余库存，不做聚合，能大幅度提高速度。

将800个商品均分至4个实例，并不能保证客户端请求被均分至不同的实例；毕竟用户的行为是无法预测的，有可能出现某个实例的请求量比较大

我觉得，是可行的，主要要考虑最后的余量怎么处理，0～2个分片上有余量，而3号分片上有余量，这样怎么处理，还有，就是最后的用余量足够，而每个分片的余量不够，这个又怎么去处理，我觉得这些处理好了，分片存储可以考虑使用。

每个实例200个库存，当某个请求在某个实例上查询不到库存时，并不是库存真的为0了，还需要去其它实例查询，这个是一个缺点。 好处时可以承受更大的流量。

使用多个实例的切片集群来分担秒杀请求，是否是一个好方法？ 使用切片集群分担秒杀请求，可以降低每个实例的请求压力，前提是秒杀请求可以平均打到每个实例上，否则会出现秒杀请求倾斜的情况，反而会增加某个实例的压力，而且会导致商品没有全部卖出的情况。 但用切片集群分别存储库存信息，缺点是如果需要向用户展示剩余库存，要分别查询多个切片，最后聚合结果后返回给客户端。这种情况下，建议不展示剩余库存信息，直接针对秒杀请求返回是否秒杀成功即可。 秒杀系统最重要的是，把大部分请求拦截在最前面，只让很少请求能够真正进入到后端系统，降低后端服务的压力，常见的方案包括：页面静态化（推送到CDN）、网关恶意请求拦截、请求分段放行、缓存校验和扣减库存、消息队列处理订单。 另外，为了不影响其他业务系统，秒杀系统最好和业务系统隔离，主要包括应用隔离、部署隔离、数据存储隔离。

老师好，想问下，用redis扣库存直接用HINCRBY已秒杀库存量，判断返回值>=总库存就是没库存，小于总库存就是扣减库存成功可以购买，这样判断有什么问题么？为什么要引入lua脚本来增加复杂度呢？