关于秒杀的系统架构优化思路

解决方案1：

将存库从MySQL前移到Redis中，全部的写操做放到内存中，因为Redis中不存在锁故不会出现互相等待，而且因为Redis的写性能和读性能都远高于MySQL，这就解决了高并发下的性能问题。而后经过队列等异步手段，将变化的数据异步写入到DB中。

优势：解决性能问题

缺点：没有解决超卖问题，同时因为异步写入DB，存在某一时刻DB和Redis中数据不一致的风险。

 

解决方案2：

引入队列，而后将全部写DB操做在单队列中排队，彻底串行处理。当达到库存阀值的时候就不在消费队列，并关闭购买功能。这就解决了超卖问题。

优势：解决超卖问题，略微提高性能。

缺点：性能受限于队列处理机处理性能和DB的写入性能中最短的那个，另外多商品同时抢购的时候须要准备多条队列。

 

解决方案3：

将写操做前移到MC中，同时利用MC的轻量级的锁机制CAS来实现减库存操做。

优势：读写在内存中，操做性能快，引入轻量级锁以后能够保证同一时刻只有一个写入成功，解决减库存问题。

缺点：没有实测，基于CAS的特性不知道高并发下是否会出现大量更新失败？不过加锁以后确定对并发性能会有影响。

 

解决方案4：

将提交操做变成两段式，先申请后确认。而后利用Redis的原子自增操做（相比较MySQL的自增来讲没有空洞），同时利用Redis的事务特性来发号，保证拿到小于等于库存阀值的号的人均可以成功提交订单。而后数据异步更新到DB中。

优势：解决超卖问题，库存读写都在内存中，故同时解决性能问题。

缺点：因为异步写入DB，可能存在数据不一致。另可能存在少买，也就是若是拿到号的人不真正下订单，可能库存减为0，可是订单数并无达到库存阀值。

 

总结

扩容+限流+内存缓存+排队

转载自：http://www.cnblogs.com/chenpingzhao/p/6195788.html