Redis 部署選型方案
==前言==
- 項目即将使用Redis，本文對Redis的部署方案，進行選型分析。
==一、部署方案介紹==
==1）、單機版==
1-單機版.jpg
單機版三個問題
- 1、記憶體容量有限
- 2、處理能力有限
- 3、無法高可用
==2）、多機版==
2-多機版.jpg
特性
- 1、複制（Replication）
- 2、哨兵（Sentinel）
- 3、叢集（Cluster）
Redis多機版部署特性功能
- 複制：擴充系統對于讀的能力
- 哨兵：為伺服器提供高可用特性，減少故障停機出現
- 叢集：擴充記憶體容量，增加機器，提高性能讀寫能力和存儲以及提高可用特性
==3）、複制==
Redis的複制（replication）功能允許使用者根據一個Redis 伺服器來建立任意多個該伺服器的複制品，其中被複制的伺服器為主伺服器（master），而通過複制建立出來的伺服器複制品，則為從伺服器（slave），master負責讀寫，slave一般隻負責讀。隻要主從伺服器之間的網絡連接配接正常，主從伺服器兩者會具有相同的資料，主伺服器就會一直将發生在自己身上的資料更新同步給從伺服器，進而一直保證主從伺服器的資料相同。
3-複制.jpg
特點：
- 1、master/slave 角色
- 2、master/slave 資料相同
- 3、降低master讀的壓力，在轉交從庫
問題：
- 1、無法保證高可用
- 2、沒有解決master寫的壓力
4）、哨兵
Redis sentinel 是一個分布式系統中監控redis主從伺服器，并在主伺服器下線時自動進行故障轉移，其中三個特性：
- 監控（Monitoring）：Sentinel 會不斷的檢查你的主伺服器和從伺服器是否運作正常。
- 提醒（Notification）：當被監控的某個Redis伺服器出現問題時，Sentinel可以通過API向管理者或者其他應用程式發送通知。
- 自動故障遷移（Automatic failover）：當一個主伺服器不能正常工作時，Sentinel會開始一次自動故障前一操作。 4-哨兵.jpg
Redis 部署選型方案 - 1、保證高可用
- 2、監控各個節點
- 3、自動故障遷移
缺點：
- 1、主從模式，切換需要時間丢資料
5）、叢集proxy
5-叢集proxy.jpg
Twemproxy
- Twemproxy 是一個Twitter開源的一個redis和memcache 快速/輕量級代理伺服器。
- Twemproxy是一個快速的單線程代理程式，支援Memcached ASCII協定和redis協定。
- 1、多種hash算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkis
- 2、支援失敗節點自動删除
- 3、後端Sharding分片邏輯對業務透明，業務方的讀寫方式和操作單個Redis一緻。
- 1、增加了新的proxy，需要維護其高可用。
- 2、failover邏輯需要自己實作，其本身不能支援故障的自動轉移。
- 3、可擴充性差，進行擴縮容都需要手動幹預。
6）、直連版（三主三從）(cluster)
6-直連版.jpg
- 1、無中心架構（不存在哪個節點影響性能瓶頸），少了proxy層。
- 2、資料按照slot存儲分布在多個節點，節點時間資料共享，可動态調用整數分布。
- 3、可擴充性，可線性擴充到1000個節點，節點可動态添加或删除。
- 4、高可用性，部分節點不可用時，叢集仍可用，通過增加Slave做備份資料副本。
- 5、實作故障自動failover，節點之間通過gossip協定交換狀态資訊，用投票機制完成Slave到Master的角色提升。
- 1、資源隔離性較差，容易出現互相影響的情況。
- 2、資料通過異步複制，不保證資料的強一緻性。