我在 Spring Boot RESTful 服務中有一個應用程式。我的應用程式沒有理想的吞吐量，并導致客戶端在大量并發請求中超時。在這種情況下，機器甚至沒有達到其記憶體和 CPU 的 20%。
所以，我決定使用回應式 RESTful。制作反應式控制器是否會提高吞吐量，或者是否有必要使其他內部方法（如服務和存盤庫）也反應式？
例如，是否足夠寫如下：
@GetMapping
private Flux<Employee> getAllEmployees() {
return employeeRepository.findAllEmployeesReqular();
}
還是有必要這樣寫，內部方法也是反應式的？
@GetMapping
private Flux<Employee> getAllEmployees() {
Flux<Employee> employees =employeeRepository.findAllEmployeesReactive();
return employees;
}
uj5u.com熱心網友回復：
反應式和非阻塞通常不會使應用程式運行得更快。反應式和非阻塞式的預期好處是能夠使用少量、固定數量的執行緒和更少的記憶體需求來擴展應用程式。它使應用程式在負載下更具彈性，因為它們以更可預測的方式擴展。因此，最好使用完整的反應式方法來使 API 在負載下可擴展和更具彈性，并可以提供更好的結果。
有關更詳細的說明，您也可以參考此處鏈接。
uj5u.com熱心網友回復：
讓應用程式完全回應通常是一個好主意。
在您的第一個示例中，該方法getAllEmployees()回傳 aFlux<Employee>但呼叫非反應性，即阻塞方法employeeRepository.findAllEmployeesReqular()。
getAllEmployees()絕不會表現得反應，因為它正在呼叫潛在的執行緒阻塞存盤庫。
只有當下游的所有其他方法也是反應式時，對方法的呼叫才能是反應式的。
如果您的呼叫下游由 12 個方法組成，并且只有其中一個阻塞了您的執行緒，則整個呼叫將阻塞。
反應式應用程式會運行得更快嗎？
不，不是自動的。如果做得好，反應式應用程式將始終回應。他們不會阻止。它們不會在負載下阻塞，也不會在錯誤下阻塞（參見https://www.reactivemanifesto.org）。因此，由于沒有阻塞，他們可能會感覺更快。
此外，在大多數情況下，您會認識到更高的 CPU 負載，因為在避免阻塞呼叫之后，回應式應用程式往往會更好地利用 CPU。
uj5u.com熱心網友回復：
一個完全反應式的解決方案比混合它們更好，Spring 有反應式存盤庫，所以你不需要照顧它，只需要匯入正確的庫就可以了。
在您的第一個示例中，getAllEmployees() 方法回傳一個 Flux，但呼叫了一個非反應性的，即阻塞方法 employeeRepository.findAllEmployeesReqular()。getAllEmployees() 絕不會表現得反應，因為它正在呼叫潛在的執行緒阻塞存盤庫。
這并非全部正確，在您的第一個示例中，您將收到一個錯誤，即編譯器錯誤。
正確的例子是：
@GetMapping
private Flux<Employee> getAllEmployees() {
return Flux.fromIterable(employeeRepository.findAllEmployeesReqular());
}
將串列從阻塞執行轉換為 Flux（也可以使用Flux.defer）Flux.fromStream。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/436344.html
標籤：爪哇 弹簧靴 spring-webflux 反应式
上一篇：專案運行時不會創建新日期