【面试准备】高并发方案

目前工作中使用的是单体式架构，如果扩展高并发方案，可能有如下几个压力：

• 系统拆分为多个子系统，应用间消息异步处理（MQ）
• 数据库读写压力
  • 查询场景下使用缓存
• 接口如果吃内存，JVM压力
• 十万级、百万级长链接压力

总体来说除了各点的高并发设计外，整体可以采用限流、加机器的方案。下面针对上述说的几个点，逐一分析扩展方案。

一、限流

可以从租户、用户、设备、IP等维度来进行限流，限制同用户的重复请求。

二、消息异步处理

MQ的特点有应用解耦、异步处理、削峰填谷。典型场景为秒杀场景。

2.1 RocketMQ

RocketMQ单机吞吐量可达十万级，kafka单机吞吐量可达百万级，均支持消息持久化。工作中用到了RocketMQ，在此以RocketMQ为例分析。
高并发异步解耦利器：RocketMQ究竟强在哪里

在大流量下，需要保证消息服务高可用，所以需要搭建集群。

• NameServer（集群方式部署）
  • Broker路由注册中心，每一个实例上都有完整的路由信息，无主从之分。提供心跳检测机制，检查Broker是否存活。
• Broker（集群方式部署）
  • 负责消息的存储、投递和查询，是消息服务高可用的核心。
  • Master Broker支持读和写，Slave Broker只支持读。
  • 当Master不可用的时候，Consumer会自动切换到Slave进行读，也就是说，当Master节点的机器出现故障后，Consumer仍然可以从Slave节点读取消息，不影响消费端的消费程序。
  • 为了保证写操作也是高可用，可以考虑构建双主双从最小集群。
    
    • 两个Broker组，保证了其中一个Broker组的Master节点挂掉之后，另一个Master节点仍然可以接受某一个Topic的消息投递；
    • 主从同步采用SYNC_MASTER，保证了生产者写入消息到Master之后，需要等到Slave也复制成功，才返回消息投递成功。这样即使主节点或者从节点挂掉了，也不会导致丢数据；
    • 由于主节点有了从节点做备份，所以，落盘策略可以使用ASYNC_FLUSH，从而尽可能的提高消息的吞吐量；
    • 如果只提供两台服务器，要部署这个集群的情况下，可以把Broker Master1和Broker Slave2部署在一台机器，Broker Master2和Broker Slave1部署在一台机器。
• Producer
• Consumer

三、数据库读写压力

• 查询可以增加缓存。
• 优化索引。
  • 合理设计索引、索引覆盖、避免索引失效等。
• 使用主从架构，来实现读写分离和负载均衡。
  • 主库用于写操作和数据同步，从库用于读操作和备份。
• 分库分表。
  • 减少单表或单服务器的负载，避免锁竞争和慢查询。
• 分布式事务（工作中暂不涉及）
  • 分布式事务可以协调多个MySQL数据库之间的事务，以满足跨库操作的需求。常见的分布式事务解决方案包括TCC、XA和Saga等。分布式事务可以通过分布式锁、分布式事务管理器和消息中间件等技术来实现。

四、内存压力

进行JVM调优，或加机器。

五、十万级、百万级长链接压力

SpringBoot内置Tomcat，默认最大线程数200、最大连接数10000，也就是说支持的最大并发量是10000。

• server.tomcat.accept-count
  • 等待队列长度，当可分配的线程数全部用完之后，后续的请求将进入等待队列等待，等待队列满后则拒绝处理，默认100
• server.tomcat.max-connections
  • 最大可被连接数，默认10000。
• server.tomcat.max-threads
  • 最大工作线程数，默认200。
• server.tomcat.min-spare-threads
  • 最小工作线程数，初始化分配线程数，默认10。

默认配置下，连接超过10000后会出现拒绝连接情况，触发的请求超过200+100后拒绝处理(最大工作线程数+等待队列长度)。