高并发现象解决

如何解决高并发现象：

前端：扩容，静态化，限流，有损服务。把一些内容预先加载到客户端本地缓存，减少加载时间消耗。

后端：

       引入负载均衡，把服务部署在多态服务器上解决。

       解决方案1： 线程池解决

       解决方案2： 将存库从MySQL前移到Redis中，所有的写操作放到内存中，由于Redis中不存在锁故不会出现互相等待，并且由于Redis的写性能和读性能都远高于MySQL，这就解决了高并发下的性能问题。然后通过队列等异步手段，将变化的数据异步写入到DB中。

　　优点：解决性能问题

　　缺点：由于异步写入DB，存在某一时刻DB和Redis中数据不一致的风险。

       解决方案3： 引入消息队列，然后将所有写DB操作在单队列中排队，完全串行处理。在不使用消息队列服务器的时候，用户的请求数据直接写入数据库，在高并发的情况下数据库压力剧增，使得响应速度变慢。但是在使用消息队列之后，用户的请求数据发送给消息队列之后立即返回，再由消息队列的消费者进程从消息队列中获取数据，异步写入数据库。由于消息队列服务器处理速度快于数据库（消息队列也比数据库有更好的伸缩性），因此响应速度得到大幅改善。

　　优点：略微提升性能。

　　缺点：性能受限于队列处理机处理性能和DB的写入性能中最短的那个。

       解决方案4： 将写操作前移到Memcached中，同时利用Memcached的轻量级的锁机制CAS来实现减库存操作。

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

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

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

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

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

 

 

原文参考：https://www.cnblogs.com/billyxp/p/3701124.html