Redis介紹、使用、資料結構和叢集模式總結

Eric zhou發表於2024-04-21
Redis資料結構模式

Redis（Remote Dictionary Server）是一個開源的，基於記憶體的資料結構儲存系統，它支援多種資料結構，如字串（String）、列表（List）、集合（Set）、有序集合（Sorted Set）、雜湊（Hash）等。Redis不僅可以用作資料庫、快取和訊息代理，還可以透過複製、持久化、高可用性和分割槽提供強大的資料保障。以下是關於Redis的使用方式、資料型別、部署方式以及如何保證資料一致性的詳細內容：

Redis是多執行緒還是單執行緒？

Redis在其傳統的架構中是一個單執行緒模型，這意味著它使用單個執行緒來處理所有客戶端請求和執行命令。這種設計簡化了實現，避免了併發問題，並且由於其記憶體資料結構的快速訪問，Redis依然能夠實現高效能。 然而，Redis 6.0 版本引入了對多執行緒的支援，用於處理客戶端的網路請求，但它的核心命令處理仍然是單執行緒的。這意味著，儘管網路I/O操作可以並行處理，但實際執行Redis命令的仍然是單個執行緒，以此來保持命令執行的原子性和順序性。

引入多執行緒的主要目的是為了減少由於網路延遲導致的客戶端響應時間，特別是在處理大量併發連線時。多執行緒主要用於以下方面：

  1. 客戶端請求的讀取：從客戶端讀取請求。
  2. 客戶端響應的寫入：向客戶端傳送響應。

儘管如此，由於Redis命令的執行仍然是單執行緒的，因此它避免了複雜的併發控制，保持了內部資料結構的原子性和一致性。這也意味著Redis的事務和持久化操作仍然保持了原子性，這是Redis作為高可靠性資料儲存系統的重要特性之一。

Redis為什麼這麼快

Redis以其快速的訪問速度而聞名，其訪問速度快的原因主要包括以下幾點：

  1. 基於記憶體：Redis的所有資料都是儲存在記憶體中的，而記憶體的訪問速度遠遠高於硬碟。記憶體的讀寫操作是納秒級別的，而硬碟則是毫秒級別的。
  2. 高效的資料結構：Redis內部使用高效的資料結構，如跳錶（skip lists）、雜湊表（hash tables）和緊湊的列表（ziplists），這些資料結構都針對快速讀寫進行了最佳化。
  3. 單執行緒架構：Redis的網路I/O操作和命令處理是在一個執行緒中順序執行的，避免了多執行緒的上下文切換開銷和鎖競爭，使得命令執行更加高效。
  4. 非阻塞I/O：Redis使用非阻塞I/O模型，可以同時處理多個I/O操作，而不需要等待當前操作完成，這提高了I/O的效率。
  5. 命令執行原子性：Redis命令執行具有原子性，保證了即使在高併發情況下，資料的一致性和完整性也不會受到影響。
  6. 資料型別豐富：Redis支援多種資料型別，如字串、列表、集合、有序集合和雜湊等，這些資料型別都經過最佳化，可以快速執行各種操作。
  7. 資料持久化：雖然資料持久化可能會影響效能，但Redis提供了多種持久化選項，允許開發者根據需要選擇最合適的持久化策略，同時保持效能。
  8. 最佳化的網路模型：Redis使用自己實現的事件驅動模型，有效地處理網路事件，減少了網路延遲的影響。
  9. 高效的序列化和傳輸：Redis客戶端和伺服器之間的通訊使用RESP協議，它是一種簡單的、高效的文字協議，易於實現且解析開銷小。
  10. 多核CPU利用：儘管Redis命令處理是單執行緒的，但Redis 6.0開始引入了對多執行緒的支援，用於處理客戶端的網路請求，這可以進一步提高效能。
  11. 合理的使用快取：Redis作為快取資料庫使用時，可以極大減少對後端資料庫的訪問壓力，減少了資料載入的時間。

使用方式

Redis支援多種程式語言的客戶端，如Python、Java、C#、Node.js等，可以透過這些客戶端與Redis伺服器進行互動。此外，Redis還提供了命令列介面（CLI），使用者可以直接連線到Redis伺服器並執行命令進行操作。

Java 使用示例 (使用 Jedis 客戶端)

在Java中，Jedis是一個常用的Redis客戶端庫。

以下是使用Jedis客戶端連線到Redis伺服器並執行基本操作的示例：

import redis.clients.jedis.Jedis;

public class RedisExample {
    public static void main(String[] args) {
        // 連線到Redis伺服器
        Jedis jedis = new Jedis("localhost", 6379);

        // 設定一個鍵值對
        jedis.set("foo", "bar");

        // 獲取一個鍵的值
        String value = jedis.get("foo");

        // 輸出獲取的值
        System.out.println(value);

        // 關閉連線
        jedis.close();
    }
}

C# 使用示例 (使用 StackExchange.Redis 客戶端)

在C#中，StackExchange.Redis是一個流行的Redis客戶端庫。以下是使用StackExchange.Redis客戶端連線到Redis伺服器並執行基本操作的示例：

using StackExchange.Redis;
using System;

class Program
{
    static void Main(string[] args)
    {
        // 連線到Redis伺服器
        var redis = ConnectionMultiplexer.Connect("localhost");

        // 獲取IDatabase物件
        IDatabase db = redis.GetDatabase();

        // 設定一個鍵值對
        db.StringSet("foo", "bar");

        // 獲取一個鍵的值
        var value = db.StringGet("foo");

        // 輸出獲取的值
        Console.WriteLine(value);

        // 關閉連線
        redis.Close();
    }
}

Redis主要的資料型別

  1. 字串（String）：最基本的型別，可以儲存任何形式的字串，包括二進位制資料。字串型別是Redis中使用最頻繁的資料型別。
  2. 列表（List）：簡單的字串列表，按照插入順序排序。可以在列表的頭部或尾部新增元素，常用於實現佇列和棧。
  3. 集合（Set）：無序的字串集合，成員唯一，可以執行集合間的並集、交集、差集等操作。
  4. 有序集合（Sorted Set）：不允許重複的成員，每個元素都會關聯一個double型別的分數，透過分數進行排序。
  5. 雜湊（Hash）：鍵值對集合，適合儲存物件，可以對雜湊的欄位執行增加、刪除、獲取等操作。

Redis部署方式

  1. 單節點模式：最簡單的部署方式，但缺乏高可用性。
  2. 主從模式：主節點負責寫操作，從節點複製主節點的資料，可以提高讀取效能並提供資料冗餘。
  3. 哨兵模式：在主從模式的基礎上增加了自動故障轉移功能，提高了系統的可用性。
  4. 叢集模式：透過分片和複製，實現了資料的高可用性和自動分割槽，適合大規模部署。

Redis哨兵和叢集模式有什麼區別

Redis哨兵（Sentinel）和Redis叢集（Cluster）是提高Redis可用性和擴充套件性的兩種不同模式，它們有以下主要區別：

  1. 高可用性（HA）實現方式：
  • 哨兵模式：哨兵是Redis的高可用性解決方案，透過監控主伺服器和從伺服器的狀態，在主伺服器當機後自動進行故障轉移，將一個從伺服器提升為新的主伺服器。
  • 叢集模式：叢集模式不僅實現了高可用性，還實現了資料的分散式儲存。它透過分片（sharding）將資料分佈在多個節點上，每個節點負責儲存一部分資料。

2. 資料儲存和分佈：

  • 哨兵模式：哨兵模式下，每臺Redis伺服器儲存相同的資料，這可能導致記憶體浪費。
  • 叢集模式：叢集模式透過雜湊槽（hash slots）實現資料分片，每臺Redis節點儲存不同的資料，充分利用了叢集的記憶體資源8。

3. 可擴充套件性：

  • 哨兵模式：雖然實現了高可用性，但仍然是中心化的叢集實現方案，寫操作受單機瓶頸影響。
  • 叢集模式：叢集模式是去中心化的，可以水平擴充套件，適合大資料量和高併發的場景。

　　4. 節點角色：

  • 哨兵模式：哨兵模式中有主節點和從節點，哨兵節點負責監控和故障轉移，不參與資料儲存。
  • 叢集模式：叢集模式中每個節點既可以是主節點也可以是從節點，每個主節點負責一部分資料槽，提高了資料管理的靈活性。

　　5. 故障轉移和恢復：

  • 哨兵模式：故障轉移過程中可能會有短暫的服務不可用時間，因為需要哨兵進行投票選舉新的主節點。
  • 叢集模式：叢集模式下，故障轉移通常更迅速，因為每個節點都維護著叢集的狀態資訊，能夠快速響應節點故障。

　　6.使用場景：

  • 哨兵模式：適用於對資料一致性要求高、資料量不是特別大的場景。
  • 叢集模式：適用於資料量大、需要高併發讀寫和高可用性的場景。

　　7. 運維複雜性：

  • 哨兵模式：配置和運維相對簡單，但需要額外的哨兵節點來監控主從伺服器。
  • 叢集模式：配置和運維更復雜，需要正確設定分片策略和節點間的通訊。

Redis哨兵模式主要解決了主從複製架構中的高可用性問題，而Redis叢集模式則進一步解決了資料分片和分散式儲存的問題，適用於更大規模的資料和更高的併發需求。

資料一致性

保證Redis與資料庫之間的資料一致性是關鍵挑戰之一。以下是一些常見的策略和實踐：

  1. 更新策略：先更新資料庫，再刪除或更新Redis中的快取資料，確保查詢時能夠從資料庫獲取最新資料。
  2. 讀取策略：優先從Redis讀取資料，如果快取中沒有資料或資料過期，則從資料庫讀取並更新快取。
  3. 分散式鎖：在分散式環境下，使用分散式鎖確保同一時間只有一個節點進行資料更新操作。
  4. 訊息佇列：透過訊息佇列非同步處理資料更新，確保更新的順序一致性。
  5. 監控和日誌記錄：定期監控Redis和資料庫之間的資料一致性，並記錄所有操作，以便在發生問題時進行回溯和排查。
  6. 資料冗餘與備份：定期備份Redis和資料庫的資料，確保在發生故障時可以恢復資料。

相關文章