我有一個應用程序，其中不同的用戶可以連接到不同的數(shù)據(jù)庫（可以是 MySQL 或 Postgres），在不同的數(shù)據(jù)庫中緩存這些連接的最佳方法是什么？我看到了一些連接池，但似乎它們更多地用于一個 db 多個連接而不是多個 db 多個連接。PS：為了添加更多上下文，我正在設計一個多租戶架構(gòu)，其中每個租戶連接到一個或多個數(shù)據(jù)庫，我可以選擇使用map[string]*sql.DB其中的關鍵是數(shù)據(jù)庫的 url，但是當我們有很多時它很難擴展數(shù)據(jù)庫的數(shù)量?；蛘呶覀儜摓槊總€通過連接 url 分片的傳入請求設置一個分片層，這樣每臺機器將包含適量的數(shù)據(jù)庫連接，形式為map[string]*sql.DB？我要構(gòu)建的軟件的一個示例是https://www.sigmacomputing.com/，用戶可以在其中連接到多個數(shù)據(jù)庫以處理不同的表。
4 回答
繁星淼淼
TA貢獻1775條經(jīng)驗 獲得超11個贊
MySQL 和 Postgres 都不允許在多個數(shù)據(jù)庫用戶之間共享連接，在連接憑據(jù)中指定單個數(shù)據(jù)庫用戶。如果您的意思是您的不同用戶擁有自己的數(shù)據(jù)庫憑據(jù)，那么就不可能在他們之間共享連接。
如果“不同用戶”是指您的應用程序用戶，并且如果他們共享單個數(shù)據(jù)庫用戶以在應用程序中更深入地訪問數(shù)據(jù)庫，那么您不需要對“緩存”連接做任何特別的事情。sql.DB默認情況下，保留并重用其池中的打開連接。
Go 會自動打開、關閉和重用帶有*database/sql.DB. 默認情況下，它最多保持 2 個連接打開（空閑），并在所有打開的連接都已經(jīng)忙時同時打開無限數(shù)量的新連接。
如果您需要對池效率與數(shù)據(jù)庫負載進行微調(diào)，您可能需要sql.DB使用方法更改配置.Set*，例如SetMaxOpenConns.
慕萊塢森
TA貢獻1810條經(jīng)驗 獲得超4個贊
你似乎有很多未知數(shù)。在這種情況下，我會應用良好的、舊的敏捷，并從您想要使用您已經(jīng)知道的工具實現(xiàn)的原型開始，然后對性能進行基準測試。我想你可能會驚訝 go 可以處理多少。
既然您了解如何map[string]*sql.DB用于此目的，我會同意的。你達到了一些極限？在 haproxy 后面添加另一臺機器。解決擴展問題并不一定意味著在 go 中編寫新的數(shù)據(jù)庫池。顯然，如果你需要這種能力，你總是可以做到的——pgx postgres 驅(qū)動程序有它自己的池實現(xiàn)，所以你可以在那里獲得靈感。然而，現(xiàn)在這樣做似乎是過早的優(yōu)化——解決你還沒有的問題。構(gòu)建原型map[string]*sql.DB很容易，測試它，基準它，你會看看你是否需要更多。
ps順便說一句，您很可能會在耗盡內(nèi)存之前達到第一個文件描述符限制。
PIPIONE
TA貢獻1829條經(jīng)驗 獲得超9個贊
假設您有多個用戶擁有多個具有 N 到 N 關系的數(shù)據(jù)庫，您可以將數(shù)據(jù)庫 URL 映射到數(shù)據(jù)庫詳細信息（如下所述）。
應該使用 configmap 或核心數(shù)據(jù)庫來處理哪些用戶可以訪問哪些數(shù)據(jù)庫的事實；對于數(shù)據(jù)庫詳細信息，我們可以有一個這樣的結(jié)構(gòu)：
type DBDetail {
sync.RWMutex
connection *sql.DB
}
該映射將是數(shù)據(jù)庫詳細信息(dbDetail) 的數(shù)據(jù)庫 URL，如果用戶正在寫入，它將調(diào)用：
dbDetail.Lock()
defer dbDetail.Unock()
而對于讀取而不是上面的，只需使用RLock。
正如 vearutop 所說，連接可能很痛苦，但使用它你可以有一個連接，或者在Lock之后通過另一個變量的增量和減量來設置限制。
Qyouu
TA貢獻1786條經(jīng)驗 獲得超11個贊
這里不一定有正確的架構(gòu)答案。這取決于系統(tǒng)的一些約束。
我可以選擇使用
map[string]*sql.DBwhere key 是數(shù)據(jù)庫的 url，但是當我們有大量數(shù)據(jù)庫時，它很難擴展。
這是否會充分擴展取決于對數(shù)據(jù)庫數(shù)量的預期。如果預計在不久的將來會有數(shù)十或數(shù)百個并發(fā)用戶，可能就足夠了。使用地圖后的下一步通常是過渡到功能更全的緩存（例如https://github.com/dgraph-io/ristretto）。
決定使用地圖還是緩存的一個因素是您如何想象數(shù)據(jù)庫連接的生命周期。打開連接后，該連接是否可以在進程的剩余生命周期內(nèi)保持打開狀態(tài)，或者是否需要在幾分鐘無用后關閉連接以釋放資源。
我們是否應該為每個通過連接 url 分片的傳入請求設置一個分片層，這樣每臺機器將包含適量的數(shù)據(jù)庫連接，形式為
map[string]*sql.DB？
這里的正確答案取決于預期有多少處理節(jié)點，以及是否會從將請求路由到特定機器中獲得額外的好處。例如，行級緩存和將用戶與彼此的請求隔離是一個優(yōu)勢，可以通過在池中共享用戶來獲得。但缺點是您最終可能會使用“熱”節(jié)點，因為單個用戶可能會產(chǎn)生大部分流量。
通常，對于這種情況，一個好的策略是真正明確地說明問題的約束。Jeff Dean 為這樣的情況創(chuàng)造了一條經(jīng)驗法則：
如果規(guī)模變化 10 倍或 20 倍，請確保您的設計有效，但 X 的正確解決方案 [is] 通常不是 100 倍的最佳解決方案
https://static.googleusercontent.com/media/research.google.com/en//people/jeff/stanford-295-talk.pdf
所以，如果在不久的將來，系統(tǒng)需要支持幾十個并發(fā)用戶。最簡單的支持數(shù)十到數(shù)百個并發(fā)用戶（可能沒有用戶分片的地圖或緩存就足夠了）。在系統(tǒng)能夠支持成千上萬的并發(fā)用戶之前，必須改變這種設計。擴展系統(tǒng)通常是一個很好的問題，因為它通常表明項目成功。
- 4 回答
- 0 關注
- 468 瀏覽
添加回答
舉報
0/150
提交
取消