秒杀业务的思考

其实像营销系统，对活动的并发是很大的，这种情况就是要做到不影响其他核心的业务，要做到快速响应快速失败，采用库存滑块锁，锁粒度是每个库存，这样对每个库存加锁，加锁成功后写入到领取记录里面，可能会少卖：加锁成功但是添加记录失败。

能真正意义上避免超卖吗？其实从理论层面上来说的话是不能100%保证的，之前看过一篇文章，集群环境下对redis的incr 和 decr 命令进行了10万次的测试，会出现超过或者不够10万次，也就是说真实情况下，在并发的环境下incr会出现或多或少的偏差，那这种是避免不了的，但可以保证99.999的可靠性。另一方面，理论层面也可能出现锁丢失的问题，redis宕机了但是锁还没有同步到从节点，这种情况也是存在的，其实我们选择redis就是因为性能好，单机都可以达到每秒几万的写，因为也的设计初衷就是AP高可用性，如果说为了一点点数据不一致改用红锁或者使用CP架构的zookeeper，我觉得也是得分业务场景在可用性与一致性之间做出权衡，选择适合业务本身得技术实现方案。