场景:每秒10000-40000并发，最高将近50000并发量
一、硬件加持简单粗暴，单机视情况加内存，cpu等等，考虑加服务器做集群，或增加集群节点
二、架构选择
不会吧，不会吧，不会还有人在高并发场景下做成单体应用吧，假如某个接口并发量特别大，在不做限流的情况下是不是会把整个系统拖垮，其他功能也用不了，一个接口并发高导致服务器cpu或内存起飞，最终导致整个系统死掉。所以分布式架构是必须的，做成微服务，最坏结果也就是某个功能用不了，不影响其他功能。
我遇到过的实际场景，某业务接口并发量很高，不限流的情况下，服务器根本撑不住，cpu跑飞，导致系统一些简单功能也无法正常使用，所以必须分离，分离，分离，做成分布式微服务
三、代码优化
1、web容器选择目前tomcat使用最广泛，不过tomcat在高并发场景下性能并不是很好，使用undertow替代tomcat，并发性能稍微要好点，实际应用情况根据场景来使用，上线前压测是必须的。
2、线程池隔离
线程池执行任务的流程如下:创建核心线程数去处理任务，核心线程满了之后，任务进入队列等待核心线程释放，当队列也满了，则创建新的线程，直到达到最大线程数，最后通过放弃执行任务的策略来处理后面的任务。
（1）某些下游服务处理请求时间过长，创建多个静态线程池，针对不同的下游服务的请求只调用各自的线程池中的线程进行处理。不会因其他下游服务消费请求耗时长导致不能正常清分数据给其他服务。实现资源隔离。
（2）各个线程只做各自的事，互不干扰，可以避免线程阻塞，提升吞吐量
3、异步，并发编程
说白了就是多线程，一些可以异步处理的业务，可通过异步编程来实现接口响应速度
异步可以使用java8的CompletableFuture来实现，另外有并发编程框架可以选择，如disruptor，性能真的好。
4、请求合并
对于一些不关心返回结果的场景，可以采用请求合并的思想，先快速接住请求，放入一个队列，后台开线程去消费，这种做法可以很大程度上提高吞吐量，不过这种种做法可能在服务停掉的时候丢一部分数据，针对这种情况，可以采用如下方案:
采用RocksDb嵌入式存储引擎:
RocksDB就是FaceBook开放的一种嵌入式、持久化存储、KV型且非常适用于fast storage的存储引擎。
RocksDB的典型场景（低延时访问）:
1、需要存储用户的查阅历史记录和网站用户的应用
2、需要快速访问数据的垃圾检测应用
3、需要实时scan数据集的图搜索query
4、需要实时请求Hadoop的应用
5、支持大量写和删除操作的消息队列
具体信息百度上有
思路就是高并发场景下，接到的请求迅速存入RocksDb落盘，直接响应客户端，提升吞吐量。后台开线程从RocksDb取数据消费，这样既能很大程度上提升服务吞吐量，又能保证数据不丢失，不过需要注意的是后台消费速度必须跟得上存储速度，否则会有数据积压导致硬盘存满。
五、负载均衡
既然做了分布式集群，负载均衡就是必须的了
六、限流
限流很重要，可以在网关统一限流，配置限流策略，保证服务不雪崩。不过有的场景不能限流，必须吃下所有数据，我遇到的就是这种，很苦恼
