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

Question

使用Memcached與PHP進行會話存儲是個好主意嗎？ 我們將擁有大量服務器，我們必須從任何地方訪問會話數據，因此我們被迫使用數據庫（在我們的情況下將是MySQL）作為會話存儲或Memcached。 你怎么看？

Answer 1

我知道那些曾經使用過Memcached的人 - 它非常快，當然比數據庫快得多，而且是為了處理更多的並發而構建的。

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

顯而易見的解決方案，如果是這樣的話，是去許多基於磁盤的NoSQL /哈希表的數據庫，如一個MemcacheDB ，這是基於關閉的Memcached的。 或者看看： CouchDB ， MongoDB等等。每個守護進程（包括Memcached）在性能調優方面都比MySQL要復雜得多（其中包括密鑰和排序緩沖區，查詢緩存等各種東西都需要調整每個安裝/用例） - 我的意思是，使用Memcached除了分配內存並啟動它之外別無他法。

就個人而言，我喜歡使用更快，更合適（非SQL）的存儲來處理臨時事務，例如會話密鑰，但是如果你的數據庫沒有負載並且你沒有預料到它，那么你唯一丟失的就是存儲數據庫中的會話是慢一點，所以用戶看到更多的延遲。

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

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

Answer 2

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