Redis提供了豐富的功能，初次見到可能會感覺眼花撩亂，這些功能都是乾嘛用的？都解決了什麼問題？什麼情況下才會用到對應的功能？下面開始一步一步的解釋下。
基於本機記憶體的快取
#為了解決呼叫API依然需要2秒的問題，經過排查，其主要原因在於使用SQL取得熱點新聞的過程中消耗了將近2秒的時間，於是乎，我們又想到了一個簡單粗暴的解決方案，即把SQL查詢的結果直接緩存在當前api伺服器的記憶體中（設定快取有效時間為1分鐘）。後續1分鐘內的請求直接讀取緩存，不再花2秒鐘去執行SQL了。假如這個api每秒接收到的請求時100個，那麼一分鐘就是6000個，也就是只有前2秒擁擠過來的請求會耗時2秒，後續的58秒中的所有請求都可以做到即使響應，而無需再等2秒的時間。
服務端的Redis
在API伺服器的記憶體都被快取塞滿的時候，我們發現不得不另想解決方案了。最直接的想法就是我們把這些快取都丟到一個專門的伺服器上吧，把它的記憶體配置的大大的。然後我們就盯上了redis。 。 。至於如何配置部署redis這裡不解釋了，redis官方有詳細的介紹。接著我們就用上了一台單獨的伺服器當作Redis的伺服器，API伺服器的記憶體壓力得以解決。
持久化（Persistence）
單一的Redis伺服器一個月總有那麼幾天心情不好，心情不好就罷工了，導致所有的緩存都遺失了（redis的資料是儲存在記憶體的嘛）。雖然可以把Redis伺服器重新上線，但是由於記憶體的資料遺失，造成了快取雪崩，API伺服器和資料庫的壓力還是一下子就上來了。所以這時候Redis的持久化功能就派上用場了，可以緩解一下緩存雪崩帶來的影響。 redis的持久化指的是redis會把內存的中的數據寫入到硬碟中，在redis重新啟動的時候加載這些數據，從而最大限度的降低緩存丟失帶來的影響。
哨兵（Sentinel）和複製（Replication）
#Redis伺服器毫無徵兆的罷工是個麻煩事。那麼怎辦辦？答曰：備份一台，你掛了它。那麼如何得知某一台redis伺服器掛了，如何切換，如何保證備份的機器是原始伺服器的完整備份呢？這時候就需要Sentinel和Replication出場了。 Sentinel可以管理多個Redis伺服器，它提供了監控，提醒以及自動的故障轉移的功能；Replication則是負責讓一個Redis伺服器可以配備多個備份的伺服器。 Redis也是利用這兩個功能來確保Redis的高可用的。此外，Sentinel功能則是Redis的發布和訂閱功能的一個利用。
叢集（Cluster）
單一伺服器資源的總是有上限的，CPU資源和IO資源我們可以透過主從複製，進行讀寫分離，把一部分CPU和IO的壓力轉移到從伺服器。但是記憶體資源怎麼辦，主從模式做到的只是相同資料的備份，並不能橫向擴充記憶體；單一機器的記憶體也只能進行加大處理，但是總有上限的。所以我們就需要一個解決方案，可以讓我們橫向擴展。最終的目的既是把每台伺服器只負責其中的一部分，讓這些所有的伺服器構成一個整體，對外界的消費者而言，這一組分散式的伺服器就像是一個集中式的伺服器一樣
以上是redis有哪些功能的詳細內容。更多資訊請關注PHP中文網其他相關文章！
