Webflux性能更好Mono

Question

我从webflux开始，我想知道以下哪项性能更好，因为它们看起来都很像我

- List<Customer> findAll()
- Mono<List<Customer>> findAll()
- Flux<Customer> findAll()

你能帮我弄清楚哪一个最好，为什么？谢谢

Answer 1

这是非常基本的，你应该了解Mono、Flux和具体的列表之间的区别

所有这些都产生了相同的东西，更重要的是它们是如何产生的。

所有示例都假设您的应用程序负载很重，或者您的数据库很慢。

当进行此调用时，执行调用的底层线程将调用数据库，然后等待数据库返回答案。在等待的过程中，它基本上什么都不会做。它会坐在那里什么也不做，直到数据库给出客户名单。

正如您所理解的，让线程只等待响应通常是浪费资源（内存）。

这种类型的调用将调用数据库并要求提供客户列表，如果数据库运行缓慢，线程将不会等待，而是实际开始执行其他操作。可能对数据库进行其他调用，或者处理其他由服务器自由决定的事情。在这里，从技术上讲，您可以说您正在对数据库进行async调用，并且在数据库处理请求时，线程可以自由地执行任何其他操作。

这使得线程的使用更加高效，确保所有线程总是有事可做。

当响应从数据库返回时，我们将传递整个List

在这里，我们要求提供一份客户名单，但我们不希望我们的回复是一次性的完整名单。相反，我们基本上是说“给我所有的客户，但当你在一个随用随用的庄园里找到他们时，就把他们交给我”。

它不会像前面两个例子那样一次就给你一个巨大的列表，相反，它可能会先给你8个客户，然后是10个，然后是8个，然后是15个，直到所有客户都被交付。

这通常只有在我们人类有非常大的列表时才会引起注意。如果对我们来说只有几个条目的话，那么这个列表看起来就像是一次性交付的。但是，如果数据库中有数百万个条目，你就会注意到其中的差异。

第一个例子List

Netty（webflux中使用的默认底层服务器实现）根据机器的内核数运行一定数量的工作线程。因此，让一个线程等待可能会造成巨大的性能损失。

第二个例子，如果你有一个小列表，你想一次发送列表，那么Mono

第三个例子，大的列表，连续的项目流，如果你有一个不断向客户推出价值的应用程序（web套接字），想想一个推动赔率的赌博网站，或者一个推动持续数据流的股市应用程序。

最后一点是关于数据库驱动程序的。为了使用Mono，针对数据库的Flux意味着您需要一个支持R2DBC标准的非阻塞数据库驱动程序。

如果您使用的数据库驱动程序不遵循它，那么您的所有调用都将像示例一一样，并且将在性能不佳的阻塞庄园中完成。

如果您真的需要与不支持R2DBC的db对话，可以通过一些方法来优化此类调用。但是，如果可能的话，应该避免这种db。