在不同的讀/寫數據源上拆分讀/寫請求
最近我對我正在處理的應用程序進行了一些性能測試，結果發現它並沒有做得很好（問題主要在後台和數據庫之間）。因此，在調查問題\解決方案時，我們發現使用讀/寫數據源（讀/寫 master 1 或多個讀取從屬）可能是一個不錯的方法。正如我在這些來源中發現的那樣：http: //fedulov.website/2015/10/14/dynamic-datasource-routing-with-spring/
總而言之，解決方案包括定義數據源，並在每個事務（@transaction）之前定義我們應該使用哪個數據源。但是由於已經有大量已定義的服務和事務（我的情況），在每一步選擇要使用的數據源似乎太費時了。
是否有自動拆分（選擇與 /post/update ）操作的方法？或用作路由查詢的代理的項目。（我見過 9 年前提出的這個問題，但我認為肯定有新的解決方案如何設置 Hibernate 以讀取/寫入不同的數據源？）。
我也讀過關於寫入和讀取之間的延遲問題，（我們是在談論 ms，s 延遲嗎？）讀取實例的數量會影響延遲嗎？在開始編寫程式碼之前如何防止此類行為。（一種可能採用的架構？一種設計模式？）
ps：我用的是spring、spring data jpa、hibernate、postgresql、hikari連接池。謝謝你的時間。
沒有自動的方法來區分數據修改查詢和讀取查詢。
想像以下 SQL 語句執行函式呼叫：
SELECT delete_all();如果不分析它的原始碼，就無法知道函式做了什麼。
因此，您必須在程式碼中做出決定（希望）知道哪些查詢修改數據，哪些不修改。
在 PostgreSQL 中使用流複製將讀取工作負載解除安裝到備用伺服器是可行的，但有一個警告：
預設情況下，複製是非同步的，因此在主伺服器上的事務送出和更改在備用伺服器上變得可見之間存在延遲。您的應用程序必須能夠處理此問題（或執行無法在複製主節點上執行的查詢）。
解決這個問題的唯一方法是使用同步複製
synchronous_commit = remote_apply，但這會大大增加事務送出所花費的時間，因為它必須等待更改在備用伺服器上重播，然後才能報告成功。
正如 Laurenz 所提到的，在數據庫級別上，您不能真正使用負載平衡（第三方工具可用）。一種方法是設置中間件來區分選擇查詢和其餘查詢。因此，例如，如果所有選擇查詢都可以發送到具有三個 ip 地址的一個 dns 條目（用於備用副本），並讓 dns 循環進行負載平衡。
不是一個直接的解決方案，但不是很難實施。
延遲實際上取決於三個主要因素。負載、網路連接和備用硬體。如果它們是同一數據中心和相同機器的一部分，則通常只需幾毫秒。