高并发优化方案

1.1.单机并发能力

1.2.变同步为异步

1.3.合并写请求

1.高并发优化方案

解决高并发问题从宏观角度来说有3个方向：

其中，水平扩展和服务保护侧重的是运维层面的处理。而提高单机并发能力侧重的则是业务层面的处理，也就是我们程序员在开发时可以做到的。

因此，我们本章重点讨论如何通过编码来提供业务的单机并发能力。

1.1.单机并发能力

在机器性能一定的情况下，提高单机并发能力就是要尽可能缩短业务的响应时间（ResponseTime），而对响应时间影响最大的往往是对数据库的操作。而从数据库角度来说，我们的业务无非就是读或写两种类型。

对于读多写少的业务，其优化手段大家都比较熟悉了，主要包括两方面：

• 优化代码和SQL

• 添加缓存

对于写多读少的业务，大家可能较少碰到，优化的手段可能也不太熟悉，这也是我们要讲解的重点。

对于高并发写的优化方案有：

• 优化代码及SQL

• 变同步写为异步写

• 合并写请求

代码和SQL优化与读优化类似，我们就不再赘述了，接下来我们着重分析一下变同步为异步、合并写请求两种优化方案。

1.2.变同步为异步

假如一个业务比较复杂，需要有多次数据库的写业务，如图所示：

由于各个业务之间是同步串行执行，因此整个业务的响应时间就是每一次数据库写业务的响应时间之和，并发能力肯定不会太好。

优化的思路很简单，我们之前讲解MQ的时候就说过，利用MQ可以把同步业务变成异步，*从而提高效率。

• 当我们接收到用户请求后，可以先不处理业务，而是发送MQ消息并返回给用户结果。

• 而后通过消息监听器监听MQ消息，处理后续业务。

如图：

这样一来，用户请求处理和后续数据库写就从同步变为异步，用户无需等待后续的数据库写操作，响应时间自然会大大缩短。并发能力自然大大提高。 三个一起监听

优点：

• 无需等待复杂业务处理，大大减少响应时间

• 利用MQ暂存消息，起到流量削峰整形作用 削峰填谷

• 降低写数据库频率，减轻数据库并发压力

缺点：

• 依赖于MQ的可靠性

• 降低了写频率，但是没有减少数据库写次数

应用场景：

• 比较适合应用于业务复杂， 业务链较长，有多次数据库写操作的业务。用mq操作

1.3.合并写请求

合并写请求方案其实是参考高并发读的优化思路：当读数据库并发较高时，我们可以把数据缓存到Redis，这样就无需访问数据库，大大减少数据库压力，减少响应时间。

既然读数据可以建立缓存，那么写数据可以不可以也缓存到Redis呢？

答案是肯定的，合并写请求就是指当写数据库并发较高时，不再直接写到数据库。而是先将数据缓存到Redis，然后定期将缓存中的数据批量写入数据库。

如图：

由于Redis是内存操作，写的效率也非常高，这样每次请求的处理速度大大提高，响应时间大大缩短，并发能力肯定有很大的提升。

而且由于数据都缓存到Redis了，积累一些数据后再批量写入数据库，这样数据库的写频率、写次数都大大减少，对数据库压力小了非常多！

优点：

• 写缓存速度快，响应时间大大减少

• 降低数据库的写频率和写次数，大大减轻数据库压力

缺点：

• 实现相对复杂

• 依赖Redis可靠性

• 不支持事务和复杂业务 redis本就不支持事务的ACID

场景：

• 写频率较高、写业务相对简单的场景比较适合应用于业务复杂， 业务链较长，有多次数据库写操作的