如何保证单机保证3w tps 访问量？

今天面试被问道一个问题，如何保证单机保证3wtps的访问量？

听到这个问题，第一反应有点蒙，想成了3w的并发量了，想了一下，目前的容器比如tomcat的最大并发量也就几千就扛不住了...

后来我先说IO模型使用NOI,能够处理小数据大并发的请求，然后从代码优化上说要尽量并行处理逻辑，以及优化JVM，调整堆大小，减少FullGC，使停顿时间减少，最终使每个请求的处理时间减少。

但是也知道这个说法挺不搭题的....

       后来面试官跟我说从两方面来分析，一方面是从请求上来说，将多个请求合并成一个请求发送，减少请求次数，一方面是把请求都改成异步的，后台处理，让请求过来之后就直接返回成功。

       当时感觉这两个方面说的也没问题。毕竟第一次出去面试，脑袋瓜子里有些蒙了，然后后边就是随便聊了一下我个人擅长的方面，我就说了一下自己项目上使用的springCloud,的一些核心组件及注册中心的实现原理等，然后就没有然后了...

感觉这次面试基本是凉了，但是也还好，做好了准备，第一次面试当做总结经验教训了吧。

回来的路上，也一直在思考这个问题，有了一些想法：

      1. 首先从题目的说明上，本身存在一些问题，说的是要保证3W的tps，但是如果将请求合并了，是减少了请求次数，但是也打不到3w的tps了啊，这样本身就不符合这个题目的要求了，所以我认为要么修改题目的说明，要么这个3w tps就是一个固定值，无法通过外部优化来减少了，只能从系统内部去优化。

      2. 然后从系统优化来说，这个题目本身也存在一定的问题，就是这3w的tps到底是峰值流量还是平时流量，是需要同步给出处理结果，还是可以接受异步的后续返回处理结果。

如果是需要同步给出处理结果，那么就只能从业务处理流程上进行优化，也就是尽量把串行的处理流程改成并行的处理流程，把查询尽量从数据库改到缓存中。但是即使这样，一个需要同步返回结果的3w tps单机处理，每个请求的处理时间=1%3000≈0.00033秒=0.33微妙，感觉在时间上是根本无法处理完一个业务流程的。如果一个业务流程无法处理完的话，那么请求就会出现堆积现象，堆积过多就会出现OOM，内存溢出了...所以我个人感觉这个单机3W同步处理的优化是不符合现实的，只能从业务上去处理，尽量把同步的业务逻辑改成异步的业务逻辑，即使改成异步的业务逻辑，虽然能够支撑住3w的tps，但是因为服务的处理速刷无法达到3wtps的处理速度，那么最终会造成内存的不断消耗，最终导致OOM的出现。

      3. 看这个tps到底是峰值还是平时了，如果只是峰值3w，平时很低，而且可以使用异步的话，那么就可以使用MQ了，请求过来直接把请求发送到MQ中去，不处理业务。然后创建消费者去消费这些消息。达到削峰填谷目的。

      4. 计算一下，如果一个请求的处理时间是10ms，那么单线程每秒的处理速度=1000%10=100个，采用并行处理，如果是一个四核八线程的处理器，理论上创建16个线程去处理，那么每秒的处理速度=100*16=1600个。不知道这样的计算方法是否正确.

知道答案的童鞋，可以在评论区交流