我们需要实现一个简单的toggle服务器(rest应用程序(，它将使用toggle名称并在启用或禁用时返回。我们预计每天会有成千上万的请求。
Spring(反应式(webflux在这里有意义吗？
我的理解是，如果http线程有任何空闲时间的可能性，反应式rest api将是有用的——这意味着线程正在等待一些工作完成，并且在收到来自db读取或对其他服务的rest调用的响应之前无法继续。
我们的用例只是返回正在查询的切换值(可能来自某个缓存(。反应式休息服务对我们有用吗？与简单的弹簧引导应用程序相比，它有什么优势吗？
我来自"传统"spring/springmvc应用程序开发经验的背景，这些天我也开始学习spring-webflux，根据问题中提供的数据，以下是我的观察结果(免责声明：由于我是这个领域的初学者，所以对这个答案持保留态度(：
-
WebFlux与传统应用程序相比，实现起来不那么"直接"：维护成本更高，调试更困难，等等。
-
如果您的操作受I/O限制，WebFlux将大放异彩。如果要从内存缓存中读取数据，这不是I/O绑定操作。我也明白，"切换"数据的本质是，它不会发生太大变化，但会经常被访问(读取(，因此将它保存在一些内存缓存中确实有意义，除非你构建了一些根本不适合内存的巨大数据，但这是另一回事。
-
WebFlux+netty将允许您同时为提供数千个请求，tomcat采用传统的"每请求一个线程"模式，默认情况下仍允许队列中有200个线程+100个，如果超过这些值，它将失败，但netty将"幸存"。根据问题中提供的数据，我认为你不会从这里受益。每天10万个请求似乎是任何类型的服务器都可以轻松处理的，tomcat、jetty等等——你不需要那么"高负载"。
-
正如我在第"3"项中提到的，WebFlux在同时请求处理方面很好，但与传统方法相比，您可能不会获得任何性能改进，这与速度无关，而是与更好的资源利用率有关。
-
如果你要从数据库中读取数据，并且你确实想使用webflux，请确保你的数据库有反应驱动程序——当你运行流时，你应该一直"反应"，阻止数据库访问没有意义。
所以，最重要的是，如果我是你，我会从常规服务器开始，并考虑稍后转移到反应式堆栈(只要问题中指定的期望值不变，这种"稍后"可能永远不会出现(。
事实上，它的目标是通过使用比传统多线程方法更少的线程来最大限度地减少线程空闲，并获得更高的性能，在传统多线程方式中，每个请求使用一个线程，或者实际上使用一个工作线程池来防止创建太多线程。
如果你每天只收到数万个请求，而你的用例就这么简单，那么听起来你不需要为它计划任何特别的东西。一个普通的网络应用程序会表现得很好。