用於會話存儲的Memcached或MySQL - PHP

Question

將Memcached用於會話存儲與PHP是否不錯？我們將有很多服務器，並且我們必須從任何地方訪問會話數據，所以我們不得不使用數據庫（在我們的例子中將是MySQL）作爲會話存儲或Memcached。你怎麼看？

Answer 1

我知道那些使用過Memcached的人 - 它速度非常快，肯定比數據庫快很多，並且它的構建可以處理更多的併發。

純內存存儲的主要缺點是，如果/當您重新啓動守護程序時，所有會話數據都將被擦除。根據我的經驗，memcached是堅如磐石的，我從來沒有因爲失敗而重新啓動它，但是如果您的系統管理員不習慣這樣工作，或者您的系統經常更新，那麼這是一個考慮因素。這也取決於是否可以接受或不接受每月或每年一次的所有用戶會話（即在電子商務中，管理層可能不會這樣）。

明顯的解決方案是，如果是這種情況，則轉到許多基於磁盤的NoSQL /哈希表數據庫之一，例如基於Memcached的MemcacheDB。或者參見：CouchDB,MongoDB等。當涉及性能調優時，這些守護進程（包括Memcached）中的每一個守護進程都比MySQL要複雜得多（其中需要調整諸如鍵和排序緩衝區，查詢緩存等所有類型的東西每個安裝/用例） - 我的意思是，除了分配內存並啓動它之外，Memcached沒有太多的工作要做。個人而言，我喜歡使用更快速，更適合（非SQL）存儲臨時事物，如會話密鑰，但如果你的數據庫沒有負載，你不希望它是唯一的東西通過在數據庫中存儲會話而損失的是它速度稍慢，所以用戶會看到更多的延遲。

無論你走到哪裏，我都建議你編寫會話管理代碼，使得存儲引擎只是一個層，你可以相對輕鬆地交換不同的存儲引擎。如果您發現memcached或您選擇的任何操作都不正常，則不希望對應用程序進行重新編碼，並且您想嘗試其他操作。例如，我曾經爲一個使用memcached來緩存各種頁面和對象的集羣CMS應用程序編寫了一個緩存系統，但是當守護程序無法訪問時，它將故障轉移到緩存到共享內存或磁盤上的備用後端個人網絡服務器。 （在你的情況下，你不一定需要自動故障切換，只需要改變你對後端的想法）。

我提到MemcacheDB，因爲它使用Memcache協議，因此它非常容易在Memcached中交換對於MemcacheDB或反之亦然。

Answer 2

根據情況可能會更好地使用任一選項。使用memcached可以提供速度，但受內存限制。 MySQL或其他數據庫引擎的優勢在於它提供了更大的存儲容量，並且最重要的是，當我們將多臺服務器用於特定的Web應用程序時，可以集中會話。