> # 數據一致性 - 強一致性: 任何時刻，所有節點看到的數據都是相同的，讀操作能立即看到最新寫入的數據 - 有序執行（線性一致性) - 無序執行 (順序一致性) - (XA) - 弱一致性: 讀操作可能看到舊數據，并不能保證所有節點的數據完全同步 - 有序執行 (因果一致性) - 無序執行(最終一致性) - Kafka > # 秒殺系統 - 用Redis 緩存數量, 每次請求讀取商品庫存, - 庫存>0, 庫存-1, 返回成功, (需要原子性處理) - 庫存<=0, 返回失敗 > # 多個數據修改的時候怎么確保一致 - 強一致性還是最終一致性? - 是不是同一個庫, 同一個服務, 同一個事務 - 強一致性: 實時一致，適合對數據準確性要求高的場景，通過數據庫事務、鎖機制實現 - 最終一致性：允許短暫不一致，適合高并發但對實時性要求不高的場景，依賴異步消息或副本同步 - 扣余額 → 減庫存 → 創建訂單（全部在一個事務） 強一致性, 但是鎖的時間比較長 - Saga 是一種分布式事務模式，通過**本地事務 + 補償事務**實現最終一致性 - Seata四種事務模式AT、TCC、SAGA、XA詳解: https://baijiahao.baidu.com/s?id=1777717003459842931&wfr=spider&for=pc | **模式** | **一致性** | **性能** | **實現復雜度** | **業務侵入性** | **適用場景** | | --- | --- | --- | --- | --- | --- | | AT | 最終一致性 | 高 | 低 | 無 | 單數據庫分庫分表 | | TCC | 強一致性 | 高 | 高 | 高 | 金融交易、高并發場景 | | SAGA | 最終一致性 | 高 | 中 | 中 | 跨服務復雜業務流程 | | XA | 強一致性 | 低 | 低 | 無 | 跨數據庫強一致性場景 | > # Redis 單線程為什么這么快 - 內存操作 - Redis 使用 I/O 多路復用技術（如`select`、`epoll`、`kqueue`），單線程可以同時處理多個連接請求，避免了阻塞等待 - 高效的數據結構: 跳躍鏈表, 壓縮列表, 緊湊列表 > # Redis 哨兵模式和集群模式 - redis 持久化的時候會 會`fork`一個子進程 - Redis 哨兵模式: 從復制（Master-Slave）+ 自動故障轉移 - Redis Redis Cluster（集群模式） : 采用 **分片（Sharding）**，每個節點負責一定范圍的槽位 ~~~ root@winnie:/usr/local# /usr/local/redis-5.0.4/src/redis-cli --cluster create 192.168.1.170:8001 192.168.1.171:8003 192.168.1.172:8005 192.168.1.170:8002 192.168.1.172:8006 192.168.1.171:8004 --cluster-replicas 1c >>> Performing hash slots allocation on 6 nodes... Master[0] -> Slots 0 - 5460 Master[1] -> Slots 5461 - 10922 Master[2] -> Slots 10923 - 16383 ~~~ - slot : Redis Cluster 采用 **CRC16(key) % 16384** 計算 key 對應的 slot： - 使用 **哈希標簽 `{}`**，如 `user:{id}`，所有 `{id}` 相同的 key 都會落在同一個 slot > # list 怎么確保輸出有序 ``` LPush demo1 key1 key2 key3 key4 key5 key6 key7 key8 key9 key10 LRANGE demo1 0 4 // 輸出 key10 key9 key8 key7 key6 LRANGE demo1 5 9 //輸出 key5 key4 key3 key2 key1 LPUSH demo1 key11 LRANGE demo1 5 9 //輸出 key6 key5 key4 key3 key2 (如果有新數據插入和刪除,會導致數據重復或丟失) ``` ``` LPush demo1 key1 key2 key3 key4 key5 key6 key7 key8 key9 key10 LRANGE demo1 0 4 // 輸出 key10 key9 key8 key7 key6 LPUSH demo1 key11 LPOS demo1 key6 //獲取最后一個元素的游標 LRANGE demo1 6 10 //下一頁游標加一開始 (兩個命令需要原子性) ``` > # Kafka - Kafka 怎么確保消息有序 - 同一分區內是有序的, 不同分區間順序無法保證 - **指定 Partition**：直接控制消息進入哪個 Partition - **使用 Key**：相同 Key 的消息進入同一個 Partition - 自定義分區邏輯 - **單 Partition 的吞吐量有限**, - 當 Kafka 消費速度突然變慢，導致消息堆積時，可能的原因有很多。以下是一些常見的原因及其排查方 - 生產消息變多 - 消費者因某些原因執行時間長 - Rebalance 新消費者數據發生變化, 需要重新分配(某些加到因消費時間長被提出) - 節點負載過高