缓存计数器

电商场景里的缓存计数器：秒杀和超卖
  我们在秒杀和防超卖场景里的实现逻辑类似于淘宝这篇博客[注3]所提及的”分布式缓存计数器“，所以我就直接照搬过来了：
    分布式缓存的另一个应用场景是缓存计数器。

    对于多服务器的系统，分布式缓存提供了统一的存储和原子操作，便于集群环境下的使用。库存计数器是分布式缓存的一个典型应用场景， 对于集群中的每一台机器，库存都应该是一个统一的值，因此使用本地缓存记录库存，数据肯定是不准确的（下面会陈述例外情况）。因此，统一的存储空间是必要 的条件。

    由于库存数据被多台机器共享，因此，必须使用锁机制控制多个请求的并行并发问题。基于这样的机制就可以实行库存技术器的作用，防止货物超卖。最近的积分商城超值兑换就是使用的这种机制。

    这种机制下，需要注意操作的逻辑顺序，错误的顺序会导致意想不到的结果。积分兑换的业务流程为，用户看到要抢兑的商品，如果库存大于0，则用户可以点击抢兑操作，这时用户会获得兑换该商品的权限，从而优惠购买，这时库存商品应该减一。

    如果完全按照这个业务流程，我们会完成下面这三步操作：

验证库存是否大于0；
给用户打标，使其获得优惠购买资格；
获得资格后，原子减库存，记录用户购买记录。
    乍一看这样的逻辑是很正常的，但是考虑一下异常情况，就会发现它防不住超卖。如果库存只有一件，那么多个用户并发验证库存时，都大于0。这样并发的多个用户都会获得优惠资格，产生了超卖。

    正确的逻辑为：

验证库存是否大于0，小于0直接返回；
原子减库存，返回的结果如果小于0说明已经没有库存，直接返回；
如果返回的当前库存大于等于0，为用户打标，如果打标成功，记录用户购买记录；如果打标失败，回补原子库存。
    这样的方法，无法保证缓存中的值一定大于等于0，因为并发的发生会把缓存减为负数，但是，真正能够优惠购买的用户一定是小于等于库存数的。因为，每次原子减操作后，只有返回的库存值大于等于零的用户才能够获得购买资格。无论并发量有多大，原子操作都会成功的防止超卖的发生。

    对于上述的逻辑，可以应对绝大多数的情况。
    但是随着量的增加，这种方式也有风险。当用户量极大、货物的库存极少时，就变成了秒杀。这个时候，大量的用户涌入分布式缓存减库存，对分布式缓存有极大冲击，一旦分布式缓存挂掉，秒杀活动也就宣告失败。使用分布式缓存，目的是为了让用户准确的看到剩余库存数 目，秒杀活动非常快，用户还没有看清楚库存，活动就结束了。其实用户只关心有没有秒到商品，并不关心库存的剩余数量，因此，库存减得准不准确并不是主要矛盾，这时就可以放弃分布式缓存的设计，转而使用本地缓存存储库存数，这也就是本地缓存使用的第二个场景。
    比如， 一共有10件商品，2台机器，可以设置每台机器的本地内存中库存等于10，那么对于外网的千万个用户，就可以有20个人抢到商品，剩下的人都 被挡在库存之外。当这20个人抢到后，就可以实现另一个处理逻辑，从20个人中选出10个真正中标的人，获得10个商品的购买权限。这个选择的逻辑非常灵活，可随意定制。但是从20选10的操作，无论如何也比从千千万万个人中选10要好的多，这样可以确保秒杀的安全完成。
    如果秒杀的人继续增多，那么也可以通过客户端（即javascript）设置格挡率的方法，使少量的用户可以发出请求到服务器，绝大多数的用户都被挡在浏览器上。（注：一些技术人士在2013年吐槽小米网站抢购小米手机时，浏览器模拟排队等待其实没有发出任何网络请求，这就是客户端格挡率生效的结果。）