在使用 Spring-Boot 和 Eureka 服務發現構建的微服務架構中，我正在為單獨的單個服務中的許多應用程序構建 C3P0 連接池。但是，當我嘗試將創建的連接池作為對象返回到它們的各個應用程序并使用來自該對象的連接時，它不起作用。例如 - 當我們直接使用 C3P0 創建 DataSource 時，我們編寫 -ComboPooledDataSource dataSource = new ComboPooledDataSource();
dataSource.setDriverClass(...);但是當我們想讓dataSource使用不同微服務中創建的Connection Pool時，有沒有example/Github可以獲取呢？
2 回答
楊__羊羊
TA貢獻1943條經驗 獲得超7個贊
DB 連接本質上是一個 TCP 連接，它由參與主機中的一對套接字唯一標識。這里的套接字意味著網絡地址（IP）和主機地址（端口）的組合。
當建立 TCP 連接時，所有這些詳細信息都存儲在稱為 TCB 的數據結構中的任一端點上。因此，您不能只將 TCP 連接從一臺主機遷移到另一臺主機。
有一些像這樣的關于 TCP 連接遷移的研究。但是，這里的主要目標不是性能（如在連接池中通過節省連接建立期間 TCP 3 次握手的時間），而是允許現有連接繼續，并且不會由于移動性或故障轉移導致的 IP 更改而中斷.
如果您參考上面的鏈接文件，核心概念是再次進行 3 次握手以創建與新 IP 的新連接。唯一的區別是在握手過程中，一些額外的控制數據將被傳遞以用新的主機數據更新 TCB，這樣正在進行的數據傳輸可以繼續進行，而不會因 IP 更改而中斷。
因此，您不能僅僅將數據庫連接從一臺主機轉移到另一臺主機，因為這些主機具有不同的 IP。我鏈接的上述論文是草稿版本。即使實現了它，它也無助于您的事業，因為正如我所說，遷移將再次需要握手，這是您在連接池中要避免的。
如果您以某種方式將數據源從一臺主機傳輸到另一臺主機，然后嘗試從中借用連接，則數據源在返回連接之前所做的連接測試將失敗，這將一直持續到所有連接都用盡，然后是新連接將創建該特定主機。所以，最終你不會從中得到任何東西。
最后，在單個微服務中托管所有連接池的想法（盡管由于上述事實而本質上是錯誤的）似乎與基于微服務的架構背道而馳。這會造成瓶頸，并且此微服務的任何問題都會導致您的整個基礎架構癱瘓。在微服務架構中，我們希望將問題本地化而不是傳播。您的個人微服務應該盡可能地自治，并且像隔板和斷路器這樣的模式可以實現這一目標。
智慧大石
TA貢獻1946條經驗 獲得超3個贊
不可能在服務之間傳遞填充的連接池，因為它們需要存在（并從中加載類）該 Java 應用程序的地址空間，并且物理連接也需要來自該 Java 應用程序。你需要以不同的方式解決這個問題。
可以在服務之間傳遞配置的數據源。這實際上將序列化或外部化數據源配置，并使用相同的配置構建一個新配置。請注意，并非所有數據源實現都支持這一點。
這在 Java 中已經存在多年，例如 JNDI 服務器如何用于查找分布式應用程序的配置數據，或者 JavaEE 應用程序如何與 Java 客戶端應用程序共享配置數據。根據我的經驗，這種做法越來越不常見，有利于使用 Spring Cloud Config 等。
添加回答
舉報
0/150
提交
取消