非阻塞與阻塞 Java 服務器與 JDBC 調用

Question

我們的 gRPC 需要處理 1000 QPS，每個請求都需要一系列順序操作，包括使用 JDBC 從數據庫讀取數據。處理單個請求最多需要 50 毫秒。

我們的應用程序可以用兩種方式編寫：

• 選項 1 - 經典的每個請求一個阻塞線程：我們可以創建一個大型線程池（~200）並簡單地為每個請求分配一個線程並讓該線程在等待 DB 時阻塞。
• 選項 2 - 以真正非阻塞的方式處理每個請求： . 這將要求我們使用非阻塞 MySQL 客戶端，我不知道它是否存在，但現在讓我們假設它存在。

我的理解是非阻塞方法具有以下優點和缺點：

• 優點：允許減少所需的線程數，從而減少 memory 占用空間
• 優點：節省操作系統的一些開銷，因為它不需要為等待 IO 的線程提供 CPU 時間
• 缺點：對於大型應用程序（其中每個任務都訂閱對前一個任務的回調），它需要將單個請求拆分到多個線程，從而產生不同類型的開銷。 如果同一請求在多個物理內核上執行，則可能會增加開銷，因為數據可能在 L1/L2 內核緩存中不可用。

問題 1：盡管非阻塞應用程序似乎是很酷的新事物，但我的理解是，對於不受 memory 限制且創建更多線程不是問題的應用程序，編寫非阻塞應用程序尚不清楚實際上比編寫阻塞應用程序的 CPU 效率更高。 有任何理由不相信嗎？

問題 2：我的理解也是，如果我們使用 JDBC，連接實際上是阻塞的，即使我們將應用程序的 rest 設為非阻塞，由於 JDBC 客戶端，我們失去了所有好處，在這種情況下，一個選項1 最有可能更好？

Answer 1

對於問題 1，你是對的——非阻塞並不是天生就更好（隨着虛擬線程的到來，與良好的舊線程請求相比，它將會變得更糟）。 充其量，您可以查看正在使用的工具，並使用小規模示例進行一些性能測試。 但坦率地說，這取決於工具，而不是策略（至少，在虛擬線程出現之前）。

對於問題 2，我強烈建議您選擇最適合您的工具/框架的解決方案。 待在您的生態系統內將使您能夠在需要優化時采取更靈活的行動。

但在所有條件相同的情況下，我強烈建議您堅持使用 thread-per-request，因為您正在使用 Java。忽略虛擬線程，thread-per-request 允許您使用和管理簡單的、阻塞的、同步的代碼。 您不必處理回調或通過混亂和零碎的日志來跟蹤邏輯。 簡單地為每個請求創建一個線程，讓它在它阻塞的地方阻塞，然后讓你的調度程序在任何給定時間處理哪個線程應該擁有 CPU 核心。

Answer 2

優點：節省操作系統的一些開銷，因為它不需要為等待 IO 的線程提供 CPU 時間

不僅僅是等待線程的CPU時間，還有在線程之間切換競爭CPU的開銷。 當你有更多的線程時，更多的線程將在 state 中運行，並且 CPU 時間必須在它們之間分配。 這就需要大量的memory管理進行切換。

缺點：對於大型應用程序（其中每個任務都訂閱對前一個任務的回調），它需要將單個請求拆分到多個線程，從而產生不同類型的開銷。 如果同一請求在多個物理內核上執行，則可能會增加開銷，因為數據可能在 L1/L2 內核緩存中不可用。

這也發生在“經典”方法中，因為阻塞調用將導致 CPU 切換到不同的線程，並且如前所述，CPU 甚至必須在可運行線程之間切換以隨着線程數量的增加共享 CPU 時間。

問題 1 ：[…] 對於不受 memory 限制且創建更多線程不是問題的應用程序

在Java的當前state中，創建更多線程總是會在某些時候成為問題。 使用 thread-per-request model，這取決於您有多少個並行請求。 1000，可能還行，10000……也許不行。

目前尚不清楚編寫非阻塞應用程序實際上是否比編寫阻塞應用程序的 CPU 效率更高。 有任何理由不相信嗎？

這不僅僅是效率問題，還有可擴展性問題。 對於性能本身，這需要進行適當的負載測試。 您可能還想檢查非阻塞 I/O 真的比多線程阻塞 I/O 快嗎？ 如何？

問題 2 ：我的理解也是，如果我們使用 JDBC，連接實際上是阻塞的，即使我們將應用程序的 rest 設為非阻塞，由於 JDBC 客戶端，我們失去了所有好處，在這種情況下，一個選項1 最有可能更好？

JDBC 確實是一個同步的 API。Oracle 作為異步等效項在 ADBA 上工作，但考慮到 Project Loom 將使它變得無關緊要，他們停止了它。 R2DBC提供了一個支持 MySQL 的替代方案。Spring 甚至支持反應式事務。