我们需要实现一个简单的切换服务器（剩余应用程序），该服务器将使用切换名称并在启用或禁用后返回。我们预计每天的负载量为成千上万。
Spring（active）webflux在这里有意义吗？
我的理解是，如果http线程有空闲时间，则反应式休息api将很有用-这意味着线程正在等待某些工作完成，并且直到收到诸如db read或rest的调用之类的响应后，它才能继续进行其他服务。
我们的用例只是返回正在查询的切换值（可能来自某些缓存）。反应性休息服务对我们来说有用吗？与简单的Spring Boot应用程序相比，它具有任何优势吗？
最佳答案
我来自具有“传统” spring / spring-mvc应用开发经验的背景，这些天，我也开始学习spring webflux，根据问题中提供的数据，这是我的观察（免责声明：自从我正如我所说的，这是该领域的初学者，请带一点盐来回答这个问题：
与传统的应用程序相比，WebFlux的实现方式不太“直截了当”：维护成本更高，调试难度更大等。
如果您的操作受I / O约束，则WebFlux会发光。如果要从内存缓存中读取数据，则这不是I / O绑定操作。我也了解“切换”数据的本质是它不会改变太多，但是会经常访问（读取），因此在这里将其保留在某些内存缓存中确实是有意义的，除非您构建了不会完全适合记忆，但这是一个不同的故事。
WebFlux + netty可让您同时处理数千个请求，tomcat具有传统的“每个请求线程”模型，默认情况下仍允许200个线程+ 100个队列，如果超出这些值，它将失败，但是netty将“生存”。根据问题中显示的数据，我认为您不会从Netty中受益。
每天成千上万的请求似乎是任何类型的服务器都可以轻松处理的，无论是tomcat还是码头，无论如何-您在这里都不需要“高负载”。
正如我在项目“ 3”中所提到的，WebFlux在同时处理请求方面很出色，但是您可能不会获得比传统方法更高的性能，它与速度无关，而与资源利用率更高无关。
如果您打算从数据库中读取数据，并且想使用webflux，请确保您确实具有数据库的响应式驱动程序-运行流时，您应该一直处于“响应式”状态，阻止数据库访问没有意义。
因此，最重要的是，如果我是您，我将开始使用常规服务器，并考虑稍后再使用反应堆（只要问题中指定的期望没有变化，此“以后”就永远不会出现）。