druid，連接池和微服務(wù)的問(wèn)題

我所知道的 druid 配置，是在一個(gè)服務(wù)上進(jìn)行配置
假如一臺(tái)機(jī)器上裝有 mysql
當(dāng)我們用連接池去連接的時(shí)候
根據(jù) https://blog.csdn.net/w059805... 說(shuō)法
連接池的大小公式是：

連接數(shù) = ((核心數(shù) * 2) + 有效磁盤數(shù))

這里應(yīng)該說(shuō)假定連接池大小的配置是在單一服務(wù)（工程）上配置

如果我們考慮微服務(wù)
有 N 個(gè)服務(wù)訪問(wèn)這個(gè) mysql 機(jī)器的情況
假如每個(gè)服務(wù)的配置都是上述公式
那么總的連接池?cái)?shù)就是 N((核心數(shù) 2) + 有效磁盤數(shù))了
這應(yīng)該就不對(duì)了
但是感覺(jué)也不能用這個(gè)連接數(shù)除以N來(lái)給每個(gè)服務(wù)分配連接數(shù)吧
因?yàn)镹是不確定的，因?yàn)槟悴恢朗裁磿r(shí)候某個(gè)服務(wù)掛了，或者什么時(shí)候多加幾個(gè)服務(wù)
其次，每個(gè)服務(wù)訪問(wèn)數(shù)據(jù)庫(kù)的量也有差異
這個(gè)如何理解?

其次，druid的配置監(jiān)控系統(tǒng) Servlet 也是在單個(gè)服務(wù)下配置
而訪問(wèn) url 諸如這種
http://IP:PORT/druid
那 N 個(gè)微服務(wù)豈不是會(huì)有 N 個(gè)配置監(jiān)控系統(tǒng) Servlet?
假如有幾個(gè)微服務(wù)處于同一臺(tái)機(jī)器上
那就還要配置不同的 url
這樣感覺(jué)怪怪的？

或許一個(gè)解決方案是把對(duì)同一個(gè) mysql 機(jī)器進(jìn)行訪問(wèn)的所有的 dao 層
從各個(gè)微服務(wù)中抽出來(lái)，獨(dú)立操作做成一個(gè)微服務(wù)可以解決上述問(wèn)題？
這樣的架構(gòu)奇怪嗎？

回答

編輯回答

落殤

而連接池大小的配置是在單一服務(wù)上配置
在 N 個(gè)服務(wù)訪問(wèn)這個(gè) mysql 機(jī)器的情況下
加入每個(gè)服務(wù)的配置都是上述公式
那么總的連接池?cái)?shù)就是 N((核心數(shù) 2) + 有效磁盤數(shù))了
這不是悖論嗎？
如何理解？

沒(méi)有什么悖論呀。舉個(gè)例子，比如一個(gè)mysql支持的并發(fā)連接最多100個(gè)，你有3個(gè)微服務(wù)應(yīng)用需要同時(shí)連接這個(gè)數(shù)據(jù)庫(kù)，每個(gè)微服務(wù)部署在一臺(tái)獨(dú)立的機(jī)器上，每個(gè)機(jī)器核心數(shù)為8，磁盤數(shù)為2。 3 (2 8 + 2) 遠(yuǎn)遠(yuǎn)小于100呀。

即使超過(guò)的mysql可以支持最大并發(fā)數(shù)，可以稍減少某些微服務(wù)的連接池連接數(shù)，沒(méi)有說(shuō)連接池中的連接數(shù)必須是(核心數(shù) * 2) + 有效磁盤數(shù)。

其次，配置監(jiān)控系統(tǒng) Servlet 也是在單個(gè)服務(wù)下配置
而訪問(wèn) url 諸如這種
http://IP:PORT/druid
那 N 個(gè)微服務(wù)豈不是會(huì)有 N 個(gè)配置監(jiān)控系統(tǒng) Servlet?
假如有幾個(gè)微服務(wù)處于同一臺(tái)機(jī)器上
那就還要配置不同的 url
這樣感覺(jué)怪怪的？

不奇怪呀，不同的微服務(wù)只需要關(guān)注自己的druid的監(jiān)控。如果需要總的監(jiān)控信息，mysql 提供了很多狀態(tài)變量，相關(guān)日志（比例慢查日期）等，當(dāng)然了有很多針對(duì)mysql的監(jiān)控的工具，這些工具收集分析這些日志，變量等信息，提供很友好的界面顯示。