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中文網其他相關文章!