并发专栏： 高并发情况下的写业务

为什么会出现并发问题？

    并发问题指的是对相同资源的争夺，资源具有状态，不可重复使用，比如秒杀、购物，还有一种场景如相同请求也存在并发问题，也是对资源的争夺，比如争夺订单的状态。一般存在于写业务中。

 

 

 

 

 

1.使用锁：

    1.悲观锁：可以响应重复请求，幂等，缺点：高并发下请求堆积

    2.乐观锁：不处理重复请求，结果不幂等，采用redis缓存锁

    

2.结果幂等：

    优点：可以接收重复请求，返回一致的处理结果

    缺点：接收到相同请求还重新进行计算，占用资源，降低系统的吞吐量

 

3.分布式锁：

    接口层对请求拦截，如果存在正在执行的请求则返回，（从分布式系统中获取执行锁）

    优点：不进行重复计算，在高并发场景下为系统提供更高的吞吐量

    缺点： 使用缓存机制，当存在请求时则返回，占用缓存资源

 

4.异步操作：

    将写操作做异步处理，如全部写入消息队列中，将并行处理变为串行处理。

    优点： 极大的提高系统吞吐量，因为只有一个写入消息队列的操作，将处理的操作变为串行，保证了写入的顺序性

    缺点：1.引入了其他复杂度，需要考虑MQ的高可用 2.将并行操作变为串行，仍然会占用计算资源 3.将请求结果改变，客户端无法立即获取请求结果，需要重新请求获取结果接口

 

5.监控服务端压力：

    监控服务端压力，但某些服务出现高负载时应考虑限流、降级操作，提供容错机制，保证核心功能运行。

 

6.限流操作：

    监控请求IP，当达到一定频率时，对IP进行黑名单处理，因为一般情况下是高并发情况下，同一用户的频繁请求。

    参考：https://blog.csdn.net/fanrenxiang/article/details/80683378

7.验证token机制：

    1.当第一次请求服务端时返回一个token并在服务端有备份，在第二次请求时需要带token来，如果token不存在或token失效则不处理请求。

 

硬件层面的优化：

1.服务器集群，当达到一定的并发量时，压力不一定在服务器，DB压力也会很大。

2.myCat读写分离，分库分表