Redis哨兵模式（Sentinel、1主2從3哨兵6台伺服器配置實戰、客戶端調用、日誌解析、主觀下線、客觀下線、仲裁、腦裂問題、哨兵長與從節點投票選舉過程與原理）

来源:https://www.cnblogs.com/phpphp/p/18264191
-Advertisement-
Play Games

哨兵模式 官方文檔：https://redis.io/docs/latest/operate/oss_and_stack/management/sentinel 關聯博客：Redis主從複製（下文能用到） 極簡概括：自動監控Redis主節點是否故障的一種方案，若主節點故障，則Redis會根據投票數自 ...


哨兵模式

  • 官方文檔：https://redis.io/docs/latest/operate/oss_and_stack/management/sentinel
  • 關聯博客：Redis主從複製（下文能用到）
  • 極簡概括：自動監控Redis主節點是否故障的一種方案，若主節點故障，則Redis會根據投票數自動將從庫切換為主庫（這個過程，叫仲裁）。
  • 解決問題：在主從複製的架構模式下，Redis主節點掛掉後，從節點無任何補償操作，無人工干預的情況下導致整個緩存鏈路的寫功能喪失。而哨兵模式有哨兵看守機制，可以做到主機的檢測與自動切換從機為主機的功能。
  • 適用場景：對於需要7 * 24高可用，且公司原意投資相關運維成本的服務端應用。畢竟作為哨兵節點的Redis實例，將無法使用緩存服務，只能作為哨兵，而且要求哨兵數量往往是奇數個。
  • 優點：
    • 降低運維成本：強大的高可用機制，適當降低運維成本。
    • 自動恢復機制：當主節點掛掉後，哨兵會自動選出一個從節點作為主節點，繼續對外提供服務，無人值守。
  • 缺點：
    • 場景限制：小型公司Redis都可以不用，中型公司也不一定能用到Redis主從，更何況是哨兵這麼嚴謹的運維策略。
    • 資金問題：Redis需要堆多個伺服器，對公司而言是不小的支出，有一定門檻。
    • 延遲問題：主節點掛掉時，雖然可以做到自動切換，但是多個哨兵認為Redis能夠客觀下線時，這個過程需要時間的，雖然可以調整，但是這個時間內的Redis寫操作是失效的，因此有了集群策略。
    • 數據丟失問題：Redis主從是非同步複製，哨兵只是增加了自動化的切換功能，沒有像MySQL的redo log機制，無法保證數據100%不丟失。
    • 會引發腦裂問題（下文有說）。
  • 誤區：哨兵是哨兵，集群是集群，兩者無關。哨兵是主從複製架構的高可用優化方案，不是集群部署的高可用的方案。
  • 訪問流程：由原先的編程語言客戶端訪問Redis主節點或從節點，變成了客戶端訪問哨兵節點（通常不止一個哨兵，有奇數個哨兵組成一個哨兵集群，奇數好投票），由哨兵節點告訴客戶端訪問那個主節點或從節點，從而區分讀寫操作。

實操（1主+2從+3哨）

  • 三哨理由：一個小區也不只一個保全，至少2個保全輪班倒。但是哨兵有類似投票機制，最好用奇數個哨兵。
  • 環境決策：部署3個哨兵+1個Master+2個Slave，共6台伺服器。
  • Docker方案：當記憶體扛不住的時候可以用這個，但是拉鏡像時發現被牆了（國內混蛋專家搞的混蛋規則），鏡像拉不下來，本地也沒有，棄用了這條路線。
  • 運行環境：CentOS 7.6，每個系統分配256M記憶體，Linux可輕鬆啟動，共占用記憶體1.5GB，設備能承受，但磁碟占用挺高（特別是開機時），每個Redis實例都配置好了遠程連接功能（防火牆、遠程連接許可權、保護模式，都配置到位）。
  • IP分配：192.168.0.180（主）、192.168.0.181（從1）、192.168.0.182（從2）、192.168.0.183（哨1）、192.168.0.184（哨2）、192.168.0.185（哨3），如圖
                  	 192.168.0.183                           192.168.0.181
                  /                \                      /
              	/                    \                  /
               /                      \               /
192.168.0.xxx  -->-> 192.168.0.184 ---> 192.168.0.180
               \                      /               \
                 \                   /                  \
                   \                /                     \  
                     192.168.0.185                           192.168.0.182
  • 主要配置說明：
配置3台哨兵：
高版本Redis自帶sentinel.conf文件，可直接用。
目前用的5，沒有獨立的配置文件，可在redis.conf中配置如下：
sentinel monitor 主節點名  主節點IP 主節點埠 確認客觀下線的最少哨兵數量。    // 配置鏈接，用於定位主機網路位置。
sentinel auth-pass 主節點名  主節點密碼        //配置主機密碼
sentinel down-after-milliseconds 主節點名 毫秒 //配置心跳失去連接多少毫秒後，讓哨兵認為主機宕機
sentinel failover-timeout 主節點名 毫秒        //配置執行故障轉移所需的超時時間
sentinel parallel-syncs 主節點名 數量          //切換新的主節點之後，可同時同步其餘從節點的個數，數字越小性能越低。
其它配置不常用，可參考官方手冊。

對於sentinel monitor 配置項，“確認客觀下線的最少哨兵數量”參數的介紹：
至少有N個哨兵節點，認為主節點有故障，才會將其下線。
由於哨兵節點自身負載問題，或網路鏈路有抖動問題，這會直接影響Redis哨兵檢測主節點的心跳，誤認為主節點是宕機。
但是容易有誤判，所以設定了指定的容錯額度，減少誤判率。
  • 實操：
第一步，先配置1主（不用配置）2從（需要在192.168.0.181和192.168.0.182上）：
我之前寫過完整文章，可參考https://blog.csdn.net/weixin_42100387/article/details/139667697

vim /usr/local/redis/etc/redis.conf
#配置主節點IP和埠
replicaof 192.168.0.180 6379
#配置主節點密碼
masterauth 123456

之後重啟redis

需要註意，必須把每個從機的密碼設置一致，方便哨兵模式主從切換實例，避免整個緩存模塊故障。



第二步，配置3哨兵：
以Redis 5為例,3台哨兵節點（192.168.0.183~185）配置以下主要內容，其餘配置可按需添加（因為不配置也有預設值，不會導致錯誤）：
補充：一個哨兵是可以監控多個master的，但是這對於開發幾乎用不上。
firewall-cmd --add-port=26379/tcp --zone=public --permanent && systemctl restart firewalld
vim /usr/local/redis/etc/sentinel.conf
bind 0.0.0.0
#哨兵預設埠
port 26379
daemonize yes
protected-mode no
pidfile /usr/local/redis/redis_26379.pid
logfile /usr/local/redis/redis_26379.log
sentinel monitor zs_master 192.168.0.180 6379 2
sentinel auth-pass zs_master 123456

之後啟動哨兵，用以下二選一命令的方式
/usr/local/redis/bin/redis-sentinel /usr/local/redis/etc/sentinel.conf
/usr/local/redis/bin/redis-server   /usr/local/redis/etc/sentinel.conf --sentinel

啟動後，redis 會為sentinel.conf額外增加如下配置：
sentinel myid 3feb02e7fd5a96152e217b76f11e72236c23668c
sentinel deny-scripts-reconfig yes
# Generated by CONFIG REWRITE
dir "/usr/local/redis/etc"
sentinel config-epoch zs_master 0
sentinel leader-epoch zs_master 0
sentinel known-replica zs_master 192.168.0.182 6379
sentinel known-replica zs_master 192.168.0.181 6379
sentinel current-epoch 0

它們的含義分別是：
sentinel myid：起個唯一標識，方便定位哨兵，類比MySQL表id。
sentinel deny-scripts-reconfig yes: 拒絕通過腳本進行配置更改，這有助於提高安全性，防止非授權的更改。
dir "/usr/local/redis/etc": 指定rdb文件的位置。
sentinel config-epoch zs_master 0: 記錄主節點zs_master的情況，用於判斷哨兵配置的更新情況。
sentinel leader-epoch zs_master 0: 記錄主節點zs_master的情況，用於判斷哨兵的領導者。
sentinel known-replica zs_master 192.168.0.182 6379: 記錄已知的從節點，這裡指定了IP地址和埠號。
sentinel current-epoch 0: 記錄當前的紀元（直譯就這意思），用於標識哨兵配置的更新情況。



第三步，檢測1主2從是否能正常使用
可在主節點Redis會話中執行 set a 123，從節點執行 get a 判斷主從是否正常複製。



第四步，檢測3台哨兵是否啟動（3台設備分別執行，逐一檢測）：
ps aux | grep redis
root      81041  0.4  0.5 153996  2788 ?        Ssl  00:34   0:00 /usr/local/redis/bin/redis-sentinel 0.0.0.0:26379 [sentinel]
root      81084  0.0  0.2 112828   992 pts/0    R+   00:35   0:00 grep --color=auto redis

netstat -nlp | grep redis
tcp        0      0 0.0.0.0:26379           0.0.0.0:*               LISTEN      81041/redis-sentin

模擬主節點故障

經過實測：

  • 主節點執行shutdown模擬宕機，半分鐘內，Redis哨兵自動完成了主節點的下線，並將某個從節點切換為主節點。
  • 從節點升級為主節點的節點，以及其它從節點，的配置文件都會被強制更改，作用到配置文件，是持久化的。
  • 哨兵切換流程執行完畢後原主節點恢復訪問，那麼原主節點會變成從節點，不會因為本身的恢復，就再次改為主節點。
  • 一些情情況下，當掛掉的主節點再次啟動時，可成功啟動，但是redis的機制會把master-auth配置項乾丟掉，造成啟動之後（變為從節點）連不上主節點的情況。

哨兵對應日誌說明

  • 由於Redis哨兵模式趨向於自動化運維，所以日常日誌的排查七分重要，故在此說明其中1個哨兵（192.168.0.184）的日誌記錄概況（最起碼要看懂【何時主節點掛】、【讓誰做主節點】）。
  • 速查方法（根據關鍵字搜索，若搜索出多個值，最後一個為最新）：
    • 查詢何時主節點掛：odown master 原主節點名 原主節點IP 原主節點埠 #quorum
    • 查詢讓誰做主節點：+switch-master 原主節點名 原主節點IP 原主節點埠（後面緊跟新主節點）
  • 哨兵啟動時：
Redis哨兵初始化
99136:X 19 Jun 2024 05:58:54.697 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
99136:X 19 Jun 2024 05:58:54.697 # Redis version=5.0.9, bits=64, commit=00000000, modified=0, pid=99136, just started
99136:X 19 Jun 2024 05:58:54.697 # Configuration loaded
99137:X 19 Jun 2024 05:58:54.701 * Running mode=sentinel, port=26379.
99137:X 19 Jun 2024 05:58:54.701 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
99137:X 19 Jun 2024 05:58:54.702 # Sentinel ID is 0da5ef8126894b04e2572c4f2f9e1e636543ceee
主節點從節點信息獲取
99137:X 19 Jun 2024 05:58:54.702 # +monitor master zs_master 192.168.0.180 6379 quorum 2
99137:X 19 Jun 2024 05:58:54.720 * +slave slave 192.168.0.181:6379 192.168.0.181 6379 @ zs_master 192.168.0.180 6379
99137:X 19 Jun 2024 05:58:54.722 * +slave slave 192.168.0.182:6379 192.168.0.182 6379 @ zs_master 192.168.0.180 6379
添加了兩個哨兵
99137:X 19 Jun 2024 05:58:56.059 * +sentinel sentinel 91e7adffd0d7fc08fc1eb622001eb78b7c230901 192.168.0.183 26379 @ zs_master 192.168.0.180 6379
99137:X 19 Jun 2024 05:58:59.359 * +sentinel sentinel cadd108977e5634179172b6a2f84f4712f2c9185 192.168.0.185 26379 @ zs_master 192.168.0.180 6379
  • 主節點宕機時：
當前哨兵認為主機已下線，主觀下線。
99137:X 19 Jun 2024 05:59:59.572 # +sdown master zs_master 192.168.0.180 6379
其它哨兵也認為主機已下線，並達到了sentinel monitor設定的閾值，主觀下線升級為客觀下線
99137:X 19 Jun 2024 05:59:59.627 # +odown master zs_master 192.168.0.180 6379 #quorum 2/2
故障切換，當前切換，讓0da5ef8126894b04e2572c4f2f9e1e636543ceee 哨兵說了算，其餘哨兵投票。
99137:X 19 Jun 2024 05:59:59.627 # +new-epoch 1
99137:X 19 Jun 2024 05:59:59.627 # +try-failover master zs_master 192.168.0.180 6379
99137:X 19 Jun 2024 05:59:59.628 # +vote-for-leader 0da5ef8126894b04e2572c4f2f9e1e636543ceee 1
99137:X 19 Jun 2024 05:59:59.630 # cadd108977e5634179172b6a2f84f4712f2c9185 voted for 0da5ef8126894b04e2572c4f2f9e1e636543ceee 1
99137:X 19 Jun 2024 05:59:59.630 # 91e7adffd0d7fc08fc1eb622001eb78b7c230901 voted for 0da5ef8126894b04e2572c4f2f9e1e636543ceee 1
選擇192.168.0.182作為主節點，客觀下線老主節點，並將180的主節點轉移為182的主節點，換人和交換權利的動作不重覆。
99137:X 19 Jun 2024 05:59:59.732 # +elected-leader master zs_master 192.168.0.180 6379
99137:X 19 Jun 2024 05:59:59.732 # +failover-state-select-slave master zs_master 192.168.0.180 6379
99137:X 19 Jun 2024 05:59:59.837 # +selected-slave slave 192.168.0.182:6379 192.168.0.182 6379 @ zs_master 192.168.0.180 6379
99137:X 19 Jun 2024 05:59:59.837 * +failover-state-send-slaveof-noone slave 192.168.0.182:6379 192.168.0.182 6379 @ zs_master 192.168.0.180 6379
99137:X 19 Jun 2024 05:59:59.907 * +failover-state-wait-promotion slave 192.168.0.182:6379 192.168.0.182 6379 @ zs_master 192.168.0.180 6379
99137:X 19 Jun 2024 06:00:00.239 # +promoted-slave slave 192.168.0.182:6379 192.168.0.182 6379 @ zs_master 192.168.0.180 6379
99137:X 19 Jun 2024 06:00:00.239 # +failover-state-reconf-slaves master zs_master 192.168.0.180 6379
99137:X 19 Jun 2024 06:00:00.298 * +slave-reconf-sent slave 192.168.0.181:6379 192.168.0.181 6379 @ zs_master 192.168.0.180 6379
99137:X 19 Jun 2024 06:00:00.788 # -odown master zs_master 192.168.0.180 6379
99137:X 19 Jun 2024 06:00:01.280 * +slave-reconf-inprog slave 192.168.0.181:6379 192.168.0.181 6379 @ zs_master 192.168.0.180 6379
99137:X 19 Jun 2024 06:00:01.281 * +slave-reconf-done slave 192.168.0.181:6379 192.168.0.181 6379 @ zs_master 192.168.0.180 6379
99137:X 19 Jun 2024 06:00:01.353 # +failover-end master zs_master 192.168.0.180 6379
99137:X 19 Jun 2024 06:00:01.353 # +switch-master zs_master 192.168.0.180 6379 192.168.0.182 6379
將180，181節點，當做從節點處理。
99137:X 19 Jun 2024 06:00:01.354 * +slave slave 192.168.0.181:6379 192.168.0.181 6379 @ zs_master 192.168.0.182 6379
99137:X 19 Jun 2024 06:00:01.354 * +slave slave 192.168.0.180:6379 192.168.0.180 6379 @ zs_master 192.168.0.182 6379
當前哨兵發現180從節點仍不能用，主觀下線。
99137:X 19 Jun 2024 06:00:31.393 # +sdown slave 192.168.0.180:6379 192.168.0.180 6379 @ zs_master 192.168.0.182 6379

編程語言調用

  • 以原生PHP為例：
// 創建Redis哨兵對象，通過這個對象獲取主節點的地址，這裡是寫死的，可以寫成數組，隨機訪問1個節點，用於減輕壓力。
$sentinel = new RedisSentinel('tcp://192.168.0.183', 26379);
//主機名
$master = $sentinel->getMasterAddrByName('zs_master');

if(! $master) {
    echo '主節點獲取失敗';
    die;
}


//獲取到的主節點地址進行寫操作
$redis = new Redis();
$redis->connect($master[0], $master[1]);
$redis->auth('123456');
$redis->set('key', 'val');


//從節點讀操作。
$slave = $sentinel->slaves('zs_master');
if(empty($slave)) {
    echo '從節點獲取失敗';
    die;
}

//隨機從節點配置數組的下標，使其讀寫趨向於均衡，防止訪問壓力傾斜
$slave_arr_key = mt_rand(0, count($slave));

//這塊的從節點配置不能寫死，一定要寫活，萬一這裡的從節點，變成了主節點呢？
$redis->connect($slave[$slave_arr_key]['ip'], $slave[$slave_arr_key]['port']);
$redis->auth('123456');
$res = $redis->get('key');
print_r($res);


// 關閉連接
$redis->close();

composer require monospice/laravel-redis-sentinel-drivers

Laravel5.5以下版本需要再config/app.php中配置如下內容
'providers' => [
    ...
    Monospice\LaravelRedisSentinel\RedisSentinelServiceProvider::class,
    ...
],

在config/database.php的Redis段的同級中添加，這是演示，生產環境推薦參數寫活
這插件支持直接配置到.env，不用配config，但是一旦執行php artisan optimize加速，那麼env('config_key')將會是null，所以不用。
    'redis-sentinel' => [
        'default' => [
            ['host' => '192.168.0.183', 'port' => 26379,],
            ['host' => '192.168.0.184', 'port' => 26379,],
            ['host' => '192.168.0.185', 'port' => 26379,],
        ],

        'options' => [
        //主機名
        'service' =>  'zs_master',
        'parameters' => [
            'password' => '123456',
            'database' => 0,
        ],
    ],


若要配置Redos Facdeds：
.env文件添加REDIS_DRIVER=redis-sentinel
這個不用配置config，因為沒有地方配置，插件直接讀取env文件，測試php artisan optimize,發現能照常讀取。


若要配置Cache Facdeds:
config/cache.php的'default' => env('CACHE_DRIVER', 'file'), 此處最好修改env，將值改為redis-sentinel
並添加:
'stores' => [ //註意層級關係
    ...
    'redis-sentinel' => [
        'driver' => 'redis-sentinel',
        'connection' => 'default',
    ],
],


若要配置Session Facdeds:
config/session.php的'driver' => env('SESSION_DRIVER', 'file'),，此處最好修改env，將值改為redis-sentinel,
並將connection項設置為'',否則報錯。


若要配置Queue隊列：
config/queue.php的'default' => env('QUEUE_CONNECTION', 'sync'),， 此處最好修改env，將值改為redis-sentinel,
併在connections項內部配置：
    'redis-sentinel' => [
        'driver' => 'redis-sentinel',
        'connection' => 'default',
        'queue' => 'default',
        'retry_after' => 90, // Laravel >= 5.4.30
        'expire' => 90,      // Laravel < 5.4.30
    ],
測試延時隊列，可正常使用。

其餘常用配置說明

  • redis.conf
    • min-replicas-to-write 1與min-replicas-max-lag 10：這個是高可用的兩個配置項，它根筷子一樣通常在一塊出現，預設是禁用的配置，配置在主節點和從節點。表示主節點一個寫操作，至少有1個確認接收，且確認回覆（ack）時間不能超過10毫秒，否則返回的既不是nil也不是0，而是錯誤異常。它能夠保證主從複製時的高可用，弊端就是若有從節點掛掉，達不到min-replicas-to-write設置的數量，主節點寫入將會報錯，導致寫功能廢掉。一般情況下，前者設置看情況，後者設置為3000~5000。
    • replica-priority 100：被選中作為從節點的優先順序，從1設置為10，從2設置為100，則主節點掛掉，從1（小的優先）優先被設定為從機。

主觀下線（Sdown）與客觀下線（Odown）

  • 主觀下線：當前（單個）哨兵認為主節點掛了，有可能沒掛。
  • 客觀下線：多個哨兵都認為主節點掛了，則主節點大概率掛了，準備開始選舉其它從節點做主節點。

仲裁（Failover）

哨兵在主節點失效時進行自動故障轉移（failover）的行為。

腦裂（Split-brain）導致的數據丟失問題

  • 分散式系統的概念：腦裂是一種在分散式系統中可能出現的情況，指當網路故障導致部分節點無法與其它節點通信時，這些節點可能會錯誤地認為自己是系統中唯一的活躍實例，從而導致數據的不一致（一個地方每個山頭都獨立為王，那就亂了，多了個頭頭，好比腦裂了）。
  • 在哨兵模式下（極少出現）：客戶端與主節點連接正常，但是哨兵與主節點連接異常，那麼哨兵可能就會讓其它從節點變為主節點，此時分散式節點中，就會有多個主節點。然而客戶端仍舊和舊的數據通信（執行寫操作），在這個過程下，數據會丟失。
    若此時舊主節點恢復與哨兵的連接，舊主節點就會降級為從節點，舊主節點未同步的數據也會被新節點強制覆蓋。

腦裂（Split-brain）導致的數據丟失原因

  • 感謝IT老奇的架構600講：https://www.bilibili.com/video/BV1eF41147iL/?vd_source=19da1fcedca1050975549448303b95c2
  • 背景：接上文，因為腦裂問題引發的哨兵模式自動故障轉移（failover）的行為（仲裁），，舊的主節點，有著最近的進度。
  • 過程：當這個舊主節點與哨兵恢復連接後，並且已經有新的主節點誕生，舊主節點會被降級為從節點。
  • 數據丟失內部機制：舊主節點，會向新的主節點申請全量數據，新主節點會通過bgsave命令，非同步生成rdb文件，回傳到從節點，從節點拿到後先清空自身的所有數據，用一個乾凈的數據倉庫承接主節點發來的數據，這個清空的過程，造成了數據的丟失。
  • 結論：客戶端與Redis服務端通信期間，最新的進度沒了，數據自然也就丟失了。

腦裂（Split-brain）問題改善

由於網路的隔離，通信無法像MySQL本地事務那樣做到幾乎完美的一致性策略，說白了哨兵與主節點的通信斷了就是網斷了，斷了就是斷了，不可控也無規律，代碼寫的再好也不能解決這個問題。所以這個問題的解決方案，不能用解決修飾，用改善修飾會更好。

可在主節點和其它從節點添加min-replicas-to-write 與min-replicas-max-lag參數去改善，參數含義上文有講。
思路就是：判斷主節點寫入數據時從節點發送ack的數量，以及延遲，若發生腦裂，則主節點數量+1，從節點數量-1，達不到min-replicas-to-write閾值時，就會報錯。這也會導致緩存寫功能不可用，將異常兜底下推到代碼層。

哨兵監控主節點（哨兵切換步驟0）

哨兵探測主節點是否異常是用的心跳機制，就是每隔一段時間，向主節點發送ping進而保持連接。

哨兵長（Zhang）選舉（哨兵切換步驟1）

  • 動作：當主節點掛掉，哨兵進行選舉主節點時，實際上進行了兩步：第一步，哨兵會投票選舉一個哨兵長，第二步，哨兵長選舉主節點。
  • 選舉演算法：Redis使用的時Raft演算法。
  • 演算法流程（個人理解）：
    時序不同，數量不同會得到不同的結果，具體讀者可深入理解Raft演算法官方說明。
步驟 哨1 哨2 哨3
1 給自己投1票，將投票請求發送給哨2哨3，告訴他們自己要成為哨兵長
2 給自己投1票，將投票請求發送給哨1哨2，告訴他們自己要成為哨兵長
3 收到哨3請求，拒絕 收到哨3請求，同意
4 收到哨1請求，拒絕
5 1票同意 2票同意，成為哨兵長

主節點選舉（哨兵切換步驟2）

  • 引言：多個從節點，都有可能被選擇其中一個為主節點，隨機演算法可以實現，但是有更好的判斷策略，所以不用隨機，而這些策略受一些因素限制。
  • 因素1：如果發現副本伺服器與主伺服器斷開連接的時間超過所配置的主伺服器超時時間(down-after-milliseconds)的10倍，再加上從執行故障切換的哨兵的角度來看主伺服器也不可用的時間，則副本伺服器被認為不適合進行故障切換，並被跳過。
  • 因素2：優先順序：replica-priority參數，redis.conf中預設為100，開發人員根據當前實例情況可設置不同的值，有較小值的節點會被設置為主節點。
  • 因素3：進度大小：若優先順序一樣，就看進度，進度就是所謂的偏移量。偶爾受網路抖動或者其它因素影響，會有一個進度快（進度新），進度慢的，進度新的就做了主節點。若讓進度舊的做主節點，則會讓整個鏈路整體丟失小部分數據。
  • 因素4：若許可權和進度一樣，則就看Run ID，這個每個Redis實例上都會有，根據Run ID做ASICC的字典排序，最終選取一臺從節點實例做主節點。
  • 當某個從節點被哨兵選中當做主節點時，哨兵會發送replicaof no one命令給從節點，讓其不做任何節點的從節點。

從節點換綁主節點（哨兵切換步驟3）

能走到這個階段，就說明新的主節點已經誕生，其它從節點已經有了切換主節點的目標。
哨兵使用Redis發佈/訂閱消息功能，在主伺服器和所有從伺服器中連續廣播相關配置，直到每個節點配置完成。


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • FreeRTOS 簡單內核實現8 時間片輪詢
    0、思考與回答 0.1、思考一 為什麼要增加時間片輪詢？ 目前的 RTOS 內核已經支持搶占優先順序，即高優先順序的任務會搶占低優先順序的任務得到執行，但是對於同等優先順序的任務，如果不支持時間片輪詢，則只能有一個任務運行，並且由於優先順序相同所以除延時阻塞到期外也不會發生任務調度，因此需要增加時間片輪詢保證 ...
  • 在Ubuntu系統安裝Anaconda及Python
    本文介紹在Linux Ubuntu操作系統的電腦中，安裝Anaconda環境與Python語言的方法。 在之前的文章Anaconda與Python環境在Windows中的部署中，我們介紹了在Win10電腦中，安裝Anaconda環境與Python語言的方法；而在本文中，我們就詳細介紹一下在Linux ...
  • FreeRTOS簡單內核實現7 阻塞鏈表
    0、思考與回答 0.1、思考一 如何處理進入阻塞狀態的任務？ 為了讓 RTOS 支持多優先順序，我們創建了多個就緒鏈表（數組形式），用每一個就緒鏈表表示一個優先順序，對於阻塞狀態的任務顯然要從就緒鏈表中移除，但是阻塞狀態的任務並不是永久阻塞了，等待一段時間後應該從阻塞狀態恢復，所以我們需要創建一個阻塞鏈 ...
  • 文件系統(七)：文件系統崩潰一致性、方法、原理與局限
    liwen01 2024.06.16 前言 先提幾個問題：什麼是文件系統崩潰一致性？為什麼會出現文件系統崩潰一致性問題？有哪些方法可以解這個問題？它們各自又有哪些局限性？ window系統電腦異常後會藍屏、手機死機卡頓後我們會手動給它重啟，大部分設備的系統在遇到不可修複的嚴重異常後都會嘗試通過重啟來 ...
  • 如何根據自己的開發板型號下載和配置交叉編譯鏈
    本文介紹瞭如何根據所使用的不同開發板配置不同的交叉編譯環境. 由於在移植LVGL到不同開發板上時遇到了一些問題, 故在問題解決後整理和總結和該文章. ...
  • 花樣玩轉“所見即所得”的可視化開發UI
    隨著技術的發展，用戶對軟體的界面美觀度和交互體驗的要求越來越高。在這樣的背景下，可視化開發UI（User Interface）成為了提升用戶體驗和開發效率的重要工具。 通過圖形界面來設計和構建用戶界面的方法，可視化開發UI可以說改變了軟便開發的生態，與傳統的代碼編寫相比，它允許開發者使用拖放等直觀的 ...
  • TiDB體系架構
    本文分享自天翼雲開發者社區《TiDB體系架構》，作者:x****n 如圖所示，TiDB體系中三大組成部分：PD、TiDB Server、TiKV 1.PD：負責產生全局的TSO時間、控制Region在TIkv中的分佈、產生全局事務ID、還有其他ID。 2.TiDB：沒有數據落地，接收客戶端sql語句 ...
  • 解讀MySQL 8.0數據字典的初始化與啟動
    本文分享自華為雲社區《MySQL全文索引源碼剖析之Insert語句執行過程》，作者：GaussDB 資料庫。 本文主要介紹MySQL 8.0數據字典的基本概念和數據字典的初始化與啟動載入的主要流程。 MySQL 8.0數據字典簡介 數據字典（Data Dictionary, DD）用來存儲資料庫內部 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類