高并发性能提高和超卖的解决方案

背景介绍:

       对于一个互联网平台来讲，高并发是常常会遇到的场景。最有表明性的好比秒杀和抢购。高并发会出现三个特色：

 　　一、高并发读取

 　　二、高并发写入（一致性）

 　　三、出现超卖问题

      如何有效的解决这三个问题是应对高并发的关键。

通常系统都分为前端和后端。

前端如何应对？

一、缓存静态数据，例如图片，html页面，js等

二、搭建负载均衡集群，目前采用较多的为nginx

三、进行ip限制，限制同一个ip单位时间内发起的请求数量。或者创建ip黑名单，避免恶意攻击

四、考虑系统降级。好比当达到系统负载的时候返回一个静态处理页面

后端如何应对？

一、采用mysql读写分离，可是当高并发的时候mysql性能会下降。 通常来讲，MySQL的处理性能会随着并发thread上升而上升，可是到了必定的并发度以后会出现明显的拐点，以后一路降低，最终甚至会比单thread的性能还要差。好比加减库存的操做，一般并发量不高的作法为：update xxx set count=count-xx where curcount>xx；这样能够充分利用mysql的事务锁来避免出现超卖的状况。可是并发量上了后，会由于排他锁等待而大大下降性能。

二、采用redis数据库，前置到mysql。思路以下：

      2.1系统启动后，初始化sku信息到redis数据库，记录其可用量和锁定量

      2.2使用乐观锁，采用redis的watch机制。逻辑为：

           1.定义门票号变量，设置初始值为0。watchkey

           2.watch该变量,watch(watchkey);

           3.使用redis事务加减库存。首先获取可用量和抢购量比较，若是curcount>buycount，那么正常执行减库存和加锁定量操做：

               multi;

               redis incr watchkey;

               redis decrby curcount buycount;

               redis incrby  lockcount buycount;

               exec;

     因为上述操做都在事务内进行，一旦watchkey被其余的事务修改过，那么exec将返回nil，如此就放弃本次请求。通常都是在循环中重复尝试直到成功或没有可用量。

     最后经过订单信息流，保证mysql数据库的最终一致性。

三、其余方式但愿你们补充！