防止過多的連接的memcached（Enyim客戶端）

Question

我正在尋找建議，有效的解決方案與開放memcached的連接處理給出的常見問題帖：

什麼也不記得是從 阻止你不小心連接多倍。如果 你實例化一個memcached客戶端 對象作爲你試圖存儲的對象 的一部分，不要感到驚訝 當一個請求中的1,000個對象 創建1000個並行連接。 在列表中跳轉之前，請仔細查看此類 之類的錯誤。

另請參閱：Initializing a Memcached Client和Managing Connection Objects。

我考慮在緩存程序集中使用單例來提供memcached客戶端，儘管我確定必須有更好的方法，因爲鎖會引入（不需要的）開銷。

我很清楚客戶端的使用模式，我不清楚的是如何在可擴展性和性能方面高效地使用客戶端。其他人如何處理使用memcached客戶端？

這裏有一個爲你50的賞金。

Answer 1

我們有一個與redis客戶端類似的場景，最初是我們的解決方案是有一個通用的單一實例，我們通過lock同步訪問。這很好，但爲了避免延遲和阻塞，我們最終編寫了一個線程安全的流水線客戶端，它允許併發使用而沒有任何阻塞。我不太瞭解這些男人痛苦的協議，但我想知道是否有類似的東西在這裏適用。我真的很想嘗試調查，看看我是否可以將它添加到BookSleeve（我們的自定義OSS Redis客戶端），如果你可以稍等一會兒。

但我們是一般能夠跟上剛剛使用一個同步的共享實例（幾乎相同的事情作爲一個單身，取決於你是如何純粹）。

---

看着the FAQ，流水線確實是一種可能;我完全可以選擇在booksleeve內編寫異步/流水線的memcached客戶端。大多數原始IO /多路複用對於redis來說很常見。您可以考慮的其他技巧是使用get_multi等，而不是單獨獲取 - 儘管（我沒有看過），但我不知道您的當前客戶端是否支持此功能。

但我不知道它是如何形成鮮明對比的memcached到Redis的，但在我們的例子，切換到流水線/複用的API意味着我們並不需要使用多池（多連接） - 一個單一連接（正確流水線）能夠支持來自單個節點的大量併發使用。