单机秒杀与分布式秒杀

单机
秒杀的场景，可以进行多级淘汰。
1 、秒杀之前几天，先把“预约”的账号洗一遍，留下预售数量 200%左右的账号，其他账号秒杀当天的请求直接抛弃。
2 、秒杀当场，按照请求缓存队列随机枪毙请求，剩下 110%。进入下单流程。
3 、最终下单再进行数据库严格校验。锁定账号——货品的对应信息
一、程序锁(正常)
   /**
    * 思考：为什么不用synchronized
    * service 默认是单例的，并发下lock只有一个实例
    */
private Lock lock = new ReentrantLock(true);//互斥锁 参数默认false，不公平锁

二、AOP程序锁(正常)

@Component
@Scope
@Aspect
@Order(1)
//order越小越是最先执行，但更重要的是最先执行的最后结束。order默认值是2147483647
public class LockAspect

/** * 思考：为什么不用synchronized * service 默认是单例的，并发下lock只有一个实例 */

private static Lock lock = new ReentrantLock(true);//互斥锁 参数默认false，不公平锁

三、数据库悲观锁(正常，效率差 for update)

四、数据库乐观锁(正常，数据库锁最优 version)

五、进程队列queue(正常)

分布式

一、rediss分布式锁(有一定几率会存在网络io异常,建议与aop实现可解决)

二、zk分布式锁(正常)

三、基于redis订阅、kafka队列、activeMQ等队列(正常)