高并发优化方案

一.提高单机并发

对于单机并发，主要就是两个操作：读和写

1.对于读的操作

• 优化代码和SQL调优，例如走索引
• 缓存，例如redis

2.对于写的操作

• 优化代码和SQL调优，例如走索引
• 变同步为异步写
• 合并写请求

---

我们对于写操作后两个方案进行深入介绍：

变同步为异步写

同步通讯：就如同打视频电话，双方的交互都是实时的。因此同一时刻你只能跟一个人打视频电话 

异步通讯：就如同发微信聊天，双方的交互不是实时的，你不需要立刻给对方回应。因此你可以多线操作，同时跟多人聊天。

那到底怎样操作呢？

对于一个业务操作来说同步为下：

对于异步来说：例如引入第三方技术mq

优点:

• 无需等待，大大减少响应时间利用MO暂存消息，起到流量削峰整形作用降低写频率，减轻数据库并发压力

缺点:

• 依赖MQ可靠性
• 没有减少数据库写次数，仅仅是降低频率

---

合并写请求

优点:

• 写缓存速度快，大大减少响应时间降低了数据库写频率和写次数，减轻数据库并发压力

缺点:

• 实现相对复杂
• 依赖缓存系统可靠性
• 不支持事务和复杂业务

---

二. 服务保护

在微服务远程调用的过程中，还存在几个问题需要解决。首先是业务健壮性问题:
例如在之前的查询购物车列表业务中，购物车服务需要査询最新的商品信息，与购物车数据做对比，提醒用户。大家设想一下，如果商品服务查询时发生故障，查询购物车列表在调用商品服 务时，是不是也会异常?从而导致购物车查询失败。但从业务角度来说，为了提升用户体验，即便是商品查询失败，购物车列表也应该正确展示出来，哪怕是不包含最新的商品信息。

--
还有级联失败问题:
还是查询购物车的业务，假如商品服务业务并发较高，占用过多Tomcat连接。可能会导致商品服务的所有接口响应时间增加，延迟变高，甚至是长时间阻塞直至查询失败。此时查询购物车业务需要查询并等待商品查询结果，从而导致査询购物车列表业务的响应时间也变长，甚至也阻塞直至无法访问。而此时如果查询购物车的请求较多，可能导致购物车服务的Tomcat连接占用较多，所有接口的响应时间都会增加，整个服务性能很差，甚至不可用。

---

1.方案一：请求限流

就是限制或控制接口访问的并发流量，避免服务因流量激增而出现故障

qps：通常指的是“每秒查询率”或“每秒处理请求数”，它衡量了一个系统或服务器在单位时间内能够处理多少请求。这个定义并不直接限定于“成功响应的请求”，而是包括了所有发送到系统并得到处理的请求，无论这些请求最终是成功处理还是失败处理。

---

2.方案二：线程隔离

当一个业务接口响应时间长，而且并发高时，就可能耗尽服务器的线程资源，导致服务内的其它接口受到影响。所以我们必须把这种影响降低，或者缩减影响的范围。线程隔离正是解决这个问题的好办法。

为了避免某个接口故障或压力过大导致整个服务不可用，我们可以限定每个接口可以使用的资源范围，也就是将其隔离“起来。

如图所示，我们给查询购物车业务限定可用线程数量上限为20，这样即便查询购物车的请求因为查询商品服务而出现故障，也不会导致服务器的线程资源被耗尽，不会影响到其它接口！

---

3.方案三：服务熔断

线程隔离虽然避免了雪崩问题，但故障服务(商品服务)依然会拖慢购物车服务(服务调用方)的接口响应速度。而且商品查询的故障依然会导致查询购物车功能出现故障，购物车业务也变的不可用了。
所以，我们要做两件事情:

• 编写服务降级逻辑:就是服务调用失败后的处理逻辑，根据业务场景，可以抛出异常，也可以返回友好提示或默认旧数据。
• 异常统计和熔断:统计服务提供方的异常比例，当比例过高表明该接口会影响到其它服务，应该拒绝调用该接口，而是直接走降级逻辑。

---

三.水平扩展

将热点服务水平扩展，做好负载均衡，提高整个集群的并发能力

四.总结