Redis詳解之-叢集方案：高可用（使用Redis Sentinel）（三）
對以前的內容進行一下總結和複習。
- 瞭解Redis的基本引數配置和使用。
- 瞭解事件訂閱和持久化儲存方式（RDB和AOF）。
- Redis叢集方案：高可用（使用Redis Sentinel），官網Rdeis3.x推薦三主三從的方式，後面再介紹，參考（https://www.cnblogs.com/zhongkaijun/p/4728334.html）。
1、概述
從本篇文章開始，我們將向讀者介紹幾種Redis的高可用高負載叢集方案。除了介紹Redis 3.X版本中推薦的原生叢集方案外，還會介紹使用第三方元件搭建Redis叢集的方法。本文我們會首先介紹Redis的高可用叢集方案。
2、Redis高可用方案
Redis提供的高可用方案和我們介紹過的很多軟體的高可用方案類似，都是使用主從節點的思路。即是有一個Master節點在平時提供服務，另外一個或多個Slave節點在平時不提供服務（或只提供資料讀取服務）。當Master節點由於某些原因停止服務後，再人工/自動完成Slave節點到Master節點的切換工作，以便整個Redis叢集繼續向外提供服務。既然是要進行角色切換，且要求這些節點針對外部呼叫者來說沒有任何不同，最重要的就是Master節點和Slave節點的資料同步過程。資料同步最關鍵的設計思路是如何在資料一致性和同步效能上找到一個完美的平衡點。
同步複製的工作思路可以概括為：Master節點的任何資料變化都會立即同步到一個或多個Slave節點上。只要一個Slave節點同步失敗（例如超時），都會認為整個資料寫操作過程失敗。這樣的設計考慮側重於保證各節點上的資料絕對一致，完全沒有考慮對Master節點的響應效能，甚至會出現Master節點為了保證資料一致性而停止對後續寫操作請求的響應
非同步複製的工作思路可以概括為：Master節點首先保證對外部請求的響應效能，它和Slave節點的資料同步一般由一個新的程序/執行緒獨立完成。資料複製過程由Slave節點週期性發起或者由它一直駐留在Master節點的連線進行實時監控又或者由Master節點主動推送資料，再或者是同時使用多個非同步複製過程。由於在Slave節點進行資料同步時，Master節點一直在處理新的資料寫請求，所以Slave節點已完成同步的資料和Master上的實時資料一般會存在一些差異。例如MySQL原生支援的資料複製過程，就是一個非同步過程。
很顯然非同步複製思路在對呼叫者的響應效能上，表現要比同步複製好得多。但如果由於非同步複製而導致的節點間資料差異達到某種程度，就失去了資料同步的意義了。所以如何減少節點間的資料差異就成為非同步複製過程中需要關注的要點
2-1、主從複製工作過程
Redis的主從複製功能除了支援一個Master節點對應多個Slave節點的同時進行復制外，還支援Slave節點向其它多個Slave節點進行復制。這樣就使得架構師能夠靈活組織業務快取資料的傳播，例如使用多個Slave作為資料讀取服務的同時，專門使用一個Slave節點為流式分析工具服務。Redis的主從複製功能分為兩種資料同步模式：全量資料同步和增量資料同步。
上圖簡要說明了Redis中Master節點到Slave節點的全量資料同步過程。當Slave節點給定的run_id和Master的run_id不一致時，或者Slave給定的上一次增量同步的offset的位置在Master的環形記憶體中無法定位時（後文會提到），Master就會對Slave發起全量同步操作。這時無論您是否在Master打開了RDB快照功能，它和Slave節點的每一次全量同步操作過程都會更新/建立Master上的RDB檔案。在Slave連線到Master，並完成第一次全量資料同步後，接下來Master到Slave的資料同步過程一般就是增量同步形式了（也稱為部分同步）。增量同步過程不再主要依賴RDB檔案，Master會將新產生的資料變化操作存放在一個記憶體區域，這個記憶體區域採用環形構造。過程如下：
為什麼在Master上新增的資料除了根據Master節點上RDB或者AOF的設定進行日誌檔案更新外，還會同時將資料變化寫入一個環形記憶體結構，並以後者為依據進行Slave節點的增量更新呢？主要原因有以下幾個：
-
由於網路環境的不穩定，網路抖動/延遲都可能造成Slave和Master暫時斷開連線，這種情況要遠遠多於新的Slave連線到Master的情況。如果以上所有情況都使用全量更新，就會大大增加Master的負載壓力——寫RDB檔案是有大量I/O過程的，雖然Linux Page Cahe特性會減少效能消耗。
-
另外在資料量達到一定規模的情況下，使用全量更新進行和Slave的第一次同步是一個不得已的選擇——因為要儘快減少Slave節點和Master節點的資料差異。所以只能佔用Master節點的資源和網路頻寬資源。
-
使用記憶體記錄資料增量操作，可以有效減少Master節點在這方面付出的I/O代價。而做成環形記憶體的原因，是為了保證在滿足資料記錄需求的情況下儘可能減少記憶體的佔用量。這個環形記憶體的大小，可以通過repl-backlog-size引數進行設定。
Slave重連後會向Master傳送之前接收到的Master run_id資訊和上一次完成部分同步的offset的位置資訊。如果Master能夠確定這個run_id和自己的run_id一致且能夠在環形記憶體中找到這個offset的位置，Master就會發送從offset的位置開始向Slave傳送增量資料。那麼連線正常的各個Slave節點如何接受新資料呢？連線正常的Slave節點將會在Master節點將資料寫入環形記憶體後，主動接收到來自Master的資料複製資訊。
2-2、基本Master/Slave配置
Redis提供的主從複製功能的配置資訊，在Redis主配置檔案的“REPLICATION”部分。以下是這個部分的主要引數項說明：
-
slaveof <masterip> <masterport>：如果您需要將某個節點設定為某個Master節點的Slave節點，您需要在這裡指定Master節點的IP資訊和埠資訊。這個設定項預設是關閉的，也即是說Master節點不需要設定這個引數。另外，除了通過配置檔案設定外，您還可以通過Redis的客戶端命令進行slaveof設定。
-
slave-serve-stale-data：當master節點斷開和當前salve節點的連線或者當前slave節點正在進行和master節點的資料同步時，如果收到了客戶端的資料讀取請求，slave伺服器是否使用陳舊資料向客戶端提供服務。該引數的預設值為yes。
-
slave-read-only 是否將salve節點設定為“只讀”。一旦設定為“只讀”，表示這個Salve節點只會進行資料讀取服務，如果客戶端直接向這個Salve節點發送寫資料的請求，則會收到錯誤提示。建議採用預設的“yes”值進行設定。
-
repl-diskless-sync：上文已經介紹過Redis的主從複製功能基於RDB，後者的過程是將資料刷入RDB檔案（實際上是Linux的Page Cache區域），然後基於RDB檔案內容的更新情況和Salve當前已同步的資料標記點來進行Salve上的資料更新。所以這個過程實際會增加一定的資料延遲，消耗一定的處理資源。基於這個情況，Redis中提供了一種不經過物理磁碟裝置就進行主從資料同步的技術，稱為diskless。但是直到Redis version 3.2這個技術也一直處於試驗狀態，所以並不推薦在生產環境下使用：“
WARNING: DISKLESS REPLICATION IS EXPERIMENTAL CURRENTLY”。 -
repl-diskless-sync-delay：這個引數只有在上一個引數設定為“yes”時才起作用，主要是設定在進行兩次diskless模式的資料同步操作的時間間隔。預設為5秒。
-
repl-ping-slave-period：Slave節點向Master節點發送ping指令的事件間隔，預設為10秒。
-
repl-timeout：這是一個超時間，當某些操作達到這個時間時，Master和Slave雙方都會認為對方已經斷開連線。實際上您可以將這個時間看成是一個租約到期的時間。那麼這個操作時間會影響哪些操作呢？A、向Slave進行的資料同步操作本身不能超過這個時間；B、Slave向Master傳送一個PING指令並等待響應的時間；C、Master向Slave傳送PONG回覆並等待ACK的時間。
-
repl-disable-tcp-nodelay：這個選項的預設值為no，它對優化主從複製時使用的網路資源非常有用。要明白這個引數的含義，就首先要解釋一下tcp-nodelay是個什麼玩意兒？TCP資料報的報文頭包含很多屬性，這些屬性基本上起到記錄和保證傳輸目的、傳輸狀態的作用，但沒有資料報的所攜帶的業務資料（稱之為有效載荷）。那麼很明顯，20個位元組內容的資訊分成20個數據報進行傳輸和只用一個數據報進行傳輸，需要佔用的網路資源就完全不一樣。JohnNagle在1984年發明了一種減輕網路傳輸壓力的演算法，就是為了解決這個問題（演算法的名字就叫做“Nagle”，後續的技術人員又做了很多改進和升級）。其基本思路就是將要傳送的內容湊夠一定的數量後，再用一個數據報傳送出去。如果該屬性設定為yes，Redis將使用“Nagle”演算法（或類似演算法），讓資料報中的有效載荷湊夠一定數量後，在傳送出去；設定成no，Redis就不會這麼做。
-
repl-backlog-size：上文已經介紹過了Redis中為了進行增量同步所準備的環形記憶體區域，以及Redis這樣做的原因額，所以這裡就不再贅述了。這個選項就是用來設定環形記憶體的大小的，這個選項的預設值為1MB；正式的生產環境下可以稍微加大一些，例如5MB。
-
slave-priority：當前Slave節點的優先順序權重。我們後文會介紹一款Redis自帶的監控和故障轉移工具：Redis Sentinel，這個工具允許一個Master節點下有多個Slave節點，並且可以自動切換Slave節點為Master節點。如果Slave節點的優先順序權重值越低，就會再切換時有限成為新的Master節點。
-
min-slaves-to-write和min-slaves-max-lag：為了儘可能避免Master節點對應的多個Slave節點在資料複製過程中資料差異被越拉越大。Redis服務提供了一組拒絕資料寫操作的策略，這個策略可以解釋為：當Master上在min-slaves-max-lag時間（單位秒）間隔後，任然有min-slaves-to-write個Slave和它正常連線，那麼Master才允許進行資料寫操作。
2-3、Master和Slave設定例項
討論了Redis中主從複製的基本原理和Redis主配置檔案中針對主從複製的設定選項意義後，我們來看一個實際設定過程。注意，由於這個過程非常簡單所以我們會“非常快”。首先Master伺服器不需要針對主從複製做任何的設定（這不包括對主從複製過程的配置優化）。所以我們就直接來看Slave節點的配置：
- Slave節點上我們只需要做一件事情，就是開啟slaveof選項：
......
# slaveof選項的設定，給定master節點的ip和port就可以了
# 192.168.61.140就是master節點
slaveof 192.168.61.140 6379
......- 1
- 2
- 3
- 4
- 5
- 接著，我們馬上就可以看看同步效果了。首先確保您的master節點使工作正常的，然後就可以啟動Slave節點了：
......
5349:S 17 Dec 04:20:00.773 * Connecting to MASTER 192.168.61.140:6379
5349:S 17 Dec 04:20:00.773 * MASTER <-> SLAVE sync started
5349:S 17 Dec 04:20:00.774 * Non blocking connect for SYNC fired the event.
5349:S 17 Dec 04:20:00.775 * Master replied to PING, replication can continue...
5349:S 17 Dec 04:20:00.776 * Partial resynchronization not possible (no cached master)
5349:S 17 Dec 04:20:00.782 * Full resync from master: 976f0b31cbf6acd4fcc888301ea4639a7c591136:1
5349:S 17 Dec 04:20:00.864 * MASTER <-> SLAVE sync: receiving 119 bytes from master
5349:S 17 Dec 04:20:00.865 * MASTER <-> SLAVE sync: Flushing old data
5349:S 17 Dec 04:20:00.865 * MASTER <-> SLAVE sync: Loading DB in memory
5349:S 17 Dec 04:20:00.865 * MASTER <-> SLAVE sync: Finished with success
5349:S 17 Dec 04:20:01.068 * Background append only file rewriting started by pid 5352
5349:S 17 Dec 04:20:01.082 * AOF rewrite child asks to stop sending diffs.
5352:C 17 Dec 04:20:01.082 * Parent agreed to stop sending diffs. Finalizing AOF...
5352:C 17 Dec 04:20:01.082 * Concatenating 0.00 MB of AOF diff received from parent.
5352:C 17 Dec 04:20:01.082 * SYNC append only file rewrite performed
5352:C 17 Dec 04:20:01.082 * AOF rewrite: 6 MB of memory used by copy-on-write
5349:S 17 Dec 04:20:01.168 * Background AOF rewrite terminated with success
5349:S 17 Dec 04:20:01.168 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
5349:S 17 Dec 04:20:01.168 * Background AOF rewrite finished successfully
......- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
筆者在Slave節點上開啟了定期的RDB快照和AOF日誌功能，所以各位讀者可以忽略那些日誌資訊，直接關注“Connecting to MASTER ….”和“MASTER <-> SLAVE …….”這些日誌資訊就好。
- 以下是Master節點上給出的日誌資訊
......
5614:M 17 Dec 04:20:00.789 * Slave 192.168.61.145:6379 asks for synchronization
5614:M 17 Dec 04:20:00.789 * Full resync requested by slave 192.168.61.145:6379
5614:M 17 Dec 04:20:00.789 * Starting BGSAVE for SYNC with target: disk
5614:M 17 Dec 04:20:00.791 * Background saving started by pid 5620
5620:C 17 Dec 04:20:00.814 * DB saved on disk
5620:C 17 Dec 04:20:00.815 * RDB: 6 MB of memory used by copy-on-write
5614:M 17 Dec 04:20:00.875 * Background saving terminated with success
5614:M 17 Dec 04:20:00.877 * Synchronization with slave 192.168.61.145:6379 succeeded
......- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
看來Master節點收到了Slave節點的連線資訊，並完成了全量資料同步操作。
2-4、關閉RDB功能的說明
以上介紹的Master節點和Slave節點的設定是否特別簡單？是的，實際上只需要打開了Slave節點上“REPLICATION”區域的slaveof選項就可以讓Redis的主從複製功能運作起來。現在我們往回倒，回到上一篇文章的介紹。在上一篇文章介紹RDB快照功能的配置項時，文章提到了可以用以下方式關閉RDB快照功能：
# 以下為預設的設定為，註釋掉即可
# save 900 1
# save 300 10
# save 60 10000
# 在設定以下選項，就可以關閉RDB功能
save ""- 1
- 2
- 3
- 4
- 5
- 6
但是根據本文對Redis主從複製的介紹，我們可以發現Redis的RDB快照功能實際上是無法真正關閉的！以上所謂關閉RDB功能的設定，只是關閉了Redis服務在正常工作時定期快照的條件設定，但只要有Slave節點請求全量資料同步，Master節點就會強制做一次RDB快照。並且如果客戶端主動傳送BGSAVE命令，要求Redis服務進行RDB快照時，Redis也會被動執行RDB快照操作。
但是本文還是建議在組建Redis高可用叢集時，關閉Master節點上的RDB功能。讀者一定要清楚這樣做的原因：這不是為了像個別網路資料說的那樣真正關閉Redis的RDB快照功能，而是儘可能減少Master上主動進行RDB操作的次數，並將RDB快照工作轉移到各個Slave節點完成。
3、Redis Sentinel
Redis服務提供了效能較高的主從複製功能，但是沒有提供原生的Master——Slave的切換功能。也就是說如果您只是配置了Redis的主從複製功能，那麼在Master節點出現故障時，您必須手動將一臺Slave狀態的節點切換為Master狀態。當然這個問題在Redis Version 2.8 版本前是有標準解決方案的，那就是：Keepalived + Redis服務組成的高可用叢集。
由Keepalived監控Redis高可用叢集中Master節點的工作狀態，並在異常情況下切換另一個節點接替工作。但是，這個方案是有一些問題了，其中之一就是所有的Slave節點在Standby狀態時無法分擔Master節點的任何效能壓力——即使您設定了read-only等引數也不行，因為VIP根本不會把請求切過去。並且這種方式還不太方便監控Redis高可用叢集中各個服務節點的實時狀態。
從Version 2.8版本開始，Redis提供了一個原生的主從狀態監控和切換的元件——Redis Sentinel。通過它技術人員不但可以完成Redis高可用叢集的適時監控，還可以通過程式設計手段減輕叢集中Master節點中讀操作的壓力。本節內容，我們向讀者介紹這個Redis Sentinel的簡單使用。
3-1、基本配置
由於Redis Sentinel是Redis原生支援的，以Redis Version 3.2為例，在下載安裝後就可以直接使用命令“redis-sentinel”啟動Sentinel了。Sentinel的主配置檔案模板存放在Redis安裝目錄的下，預設名為“sentinel.conf”。以下命令可以啟動Sentinel（啟動Sentinel所依據的配置檔案是一定要攜帶的引數）：
# redis-sentinel ./sentinel.conf- 1
Redis Sentinel本身也支援叢集部署，而且為了在生產環境下避免Sentinel單點故障，所以也建議同時部署多個Sentinel節點。部署多個Sentinel還有一個原因，就是提高Master——Slave切換的準確性。以下的配置檔案介紹會說明這一點。
下面我們介紹一些Sentinel主配置檔案中的關鍵配置，注意Sentinel主配置檔案也有類似Redis主配置檔案提供的訪問保護模式（protected-mode）、訪問者許可權控制（auth-pass）等，但是它們的意義基本上類似前文介紹過的，在Redis主配置檔案中的相似內容，所以這裡就不再贅述了。
-
sentinel monitor <master-name> <ip> <redis-port> <quorum>：
這個屬性是Redis Sentinel中的最主要設定元素，換句話說如果要開啟Sentinel甚至可以只設置這個屬性。它包括了四個引數：master-name，這個引數是一個英文名說明了Sentinel服務監聽的Master節點的別名，如果一個Sentinel服務需要同時監控多個Master，這需要設定多個不同的master-name；ip和redis-port，指向sentinel需要監控的Redis叢集最初的那個Master節點（為什麼會是最初呢？後文會說明）的ip和埠；quorum，投票數量這個引數很重要，如果是Sentinel叢集方式下，它設定“當quorum個Sentinel認為Master異常了，就判定該Master真的異常了”。單個Sentinel節點認為Master下線了被稱為主管下線，而quorum個Sentinel節點都認為Master下線的情況被稱為客觀下線。
-
sentinel parallel-syncs <master-name> <numslaves>：
一旦原來的Master節點被認為客觀下線了，Sentinel就會啟動切換過程。大致來講就是從當前所有Slave節點選擇一個節點成為新的Master節點（這時在Redis中設定的slave-priority引數就會起作用了）。而其它的Slave其slaveof的Master資訊將被sentinel切換到新的Master上。而一次同時並行切換多少個Slave到新的Master上就是這個引數決定的。如果整個Redis高可用叢集的節點數量不多（沒有超過6個），建議使用預設值就可以了。
-
主配置檔案中被rewrite的引數內容：sentinel.conf檔案中的配置內容會隨著Sentinel的監控情況發生變化——由Sentinel程式動態寫入到檔案中。例如sentinel known-slave引數、sentinel current-epoch引數和sentinel leader-epoch引數。
注意，在Sentinel中您只需要配置最初的Master的監控位置，無需配置Master下任何Slave的位置，Sentinel會自己識別到這些Master直接的或者間接的Slave。
3-2、切換效果
介紹完配置後，我們來簡單看一個Sentinel工作和切換的例子。這個例子中的有一個Master節點和一個Slave節點，當Master節點出現故障時，通過Sentinel監控到異常情況並自動完成Slave狀態的切換。
-
首先請保證您的Master節點和Slave節點都是正常工作的，這個過程可以參見筆者之前文章的介紹：
節點地址 節點作用 192.168.61.140 Redis Master 192.168.61.145 Redis Slave 192.168.61.140 Redis Sentinel 這裡就不再贅述Redis Master和Redis Slave的內容了，因為在本文第2節中已經詳細介紹過。實際上您只需要開啟Slave節點的主配置檔案，並增加slaveof的配置資訊，將其指向Master的IP和埠就可以了。以下是Sentinel節點主要更改的配置資訊：
...... sentinel monitor mymaster 192.168.61.140 6379 1 ......- 1
- 2
- 3
由於在測試環境中我們只使用了一個Sentinel節點，所以設定sentinel monitor配置項中的quorum為1就可以了，代表有一個Sentinel節點認為Master不可用了，就開啟故障轉移過程。當然生產環境下不建議這樣使用。
-
之後我們使用以下Sentinel的主要配置資訊啟動Sentinel：
# redis-sentinel ./sentinel.conf ...... 8576:X 19 Dec 00:49:01.085 # Sentinel ID is 5a5eb7b97de060e7ad5f6aa20475a40b3d9fd3e1 8576:X 19 Dec 00:49:01.085 # +monitor master mymaster 192.168.61.140 6379 quorum 1 ......- 1
- 2
- 3
- 4
- 5
- 6
- 7
-
之後主動終止原來Master的執行過程（您可以直接使用kill命令，或者拔掉網線，又索性直接關機），來觀察Slave節點和Sentinel節點的日誌情況：
當斷開原來的Master節點後，Slave節點將提示連線失效並開始重試。當Sentinel開始進入故障轉移並完成後，Salve又會列印相應的過程資訊：
...... 8177:S 19 Dec 00:53:17.467 * Connecting to MASTER 192.168.61.140:6379 8177:S 19 Dec 00:53:17.468 * MASTER <-> SLAVE sync started 8177:S 19 Dec 00:53:17.468 # Error condition on socket for SYNC: Connection refused ...... 8177:M 19 Dec 00:53:18.134 * Discarding previously cached master state. 8177:M 19 Dec 00:53:18.134 * MASTER MODE enabled (user request from 'id=3 addr=192.168.61.140:51827 fd=5 name=sentinel-5a5eb7b9-cmd age=258 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 oll=0 omem=0 events=r cmd=exec') 8177:M 19 Dec 00:53:18.138 # CONFIG REWRITE executed with success. ......- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
從以上Slave節點的內容可以看到，Slave被切換成了Master狀態。那麼Sentinel本身有哪些重要的日誌資訊呢？如下所示：
...... // 當前Sentinel節點確定原Master主觀下線 8576:X 19 Dec 00:53:18.074 # +sdown master mymaster 192.168.61.140 6379 // 由於設定的quorum為1，所以一個Sentinel節點的主管下線就認為Master客觀下線了 8576:X 19 Dec 00:53:18.074 # +odown master mymaster 192.168.61.140 6379 #quorum 1/1 // 第三代，每轉移一次故障epoch的值+1， // 不好意思，在書寫測試例項前，本人已經自行測試了兩次故障轉移，所以這裡看到的epoch為3 // 這個資訊會自動寫入到Sentinel節點的主配置檔案中 8576:X 19 Dec 00:53:18.074 # +new-epoch 3 // 開始進行故障轉移 8576:X 19 Dec 00:53:18.074 # +try-failover master mymaster 192.168.61.140 6379 // 選舉出主導故障轉移的Sentinel節點，因為不是所有Sentinel節點都會主導這個過程 8576:X 19 Dec 00:53:18.084 # +vote-for-leader 5a5eb7b97de060e7ad5f6aa20475a40b3d9fd3e1 3 8576:X 19 Dec 00:53:18.084 # +elected-leader master mymaster 192.168.61.140 6379 8576:X 19 Dec 00:53:18.084 # +failover-state-select-slave master mymaster 192.168.61.140 6379 // 選擇提升哪一個slave作為新的master 8576:X 19 Dec 00:53:18.156 # +selected-slave slave 192.168.61.145:6379 192.168.61.145 6379 @ mymaster 192.168.61.140 6379 8576:X 19 Dec 00:53:18.156 * +failover-state-send-slaveof-noone slave 192.168.61.145:6379 192.168.61.145 6379 @ mymaster 192.168.61.140 6379 8576:X 19 Dec 00:53:18.211 * +failover-state-wait-promotion slave 192.168.61.145:6379 192.168.61.145 6379 @ mymaster相關推薦
Redis詳解之-叢集方案：高可用（使用Redis Sentinel）（三）
對以前的內容進行一下總結和複習。 瞭解Redis的基本引數配置和使用。瞭解事件訂閱和持久化儲存方式（RDB和AOF）。Redis叢集方案：高可用（使用Redis Sentinel），官網Rdeis3.x推薦三主三從的方式，後面再介紹，參考（https://www.cnb
Redis詳解之-叢集方案：高效能（使用原生Redis Cluster）（四）
對以前的內容進行一下總結和複習。 瞭解Redis的基本引數配置和使用。 瞭解事件訂閱和持久化儲存方式（RDB和AOF）。 Redis叢集方案：高可用（使用Redis Sentinel），官網Rdeis3.x推薦三主三從的方式，參考（https://www.cnblogs
Redis詳解之-叢集方案：高效能（Codis3.2+Redis Cluster）（五）
[[email protected] opt]# /usr/local/zookeeper/bin/zkCli.sh -server 192.168.10.101:2181 Connecting to 192.168.10.101:2181 2017-05-12 17:27:41,481 [my
.Net使用Redis詳解之ServiceStack.Redis（七）
序言 本篇從.Net如何接入Reis開始，直至.Net對Redis的各種操作，為了方便學習與做為文件的檢視，我做一遍註釋展現，其中會對list的阻塞功能和事務的運用做二個案例，進行記錄學習
keepalived詳解 及 keepalived配置LVS高可用叢集
keepalived詳解 及 keepalived配置LVS高可用負載均衡叢集 在前面《INUX叢集--均衡負載 LVS（一） LVS認知》等系列文章中我們全面認識了LVS，並手動進行了LVS的應用配置，我們知道所有使用者client端的請求都會經過LVS的
SpringCloud進擊 | 一深入：高可用的分散式配置中心（Spring Cloud Config）【Finchley版本】
1.前言 上一節：SpringCloud進擊 | 七淺出：服務閘道器 - 過濾器（Zuul Filter）【Finchley版本】 通常情況下，Config Server 與 Eureka 服務註冊中心一樣，也需要將其架構成高可用的叢集。所以，我們來改進一下，以一種更為簡單的方式 -
redis詳解（四）-- 高可用分散式叢集
一，高可用 高可用（High Availability），是當一臺伺服器停止服務後，對於業務及使用者毫無影響。 停止服務的原因可能由於網絡卡、路由器、機房、CPU負載過高、記憶體溢位、自然災害等不可預期的原因導致，在很多時候也稱單點問題。 （1）解決單點問題主要有2種方
OSPF詳解之三：OSPF LSA詳解
ospf lsa詳解 forwarding address OSPF LSA詳解OSPF V2版本中常用的主要有6類LSA，分別是Router-LSA、Network-LSA、Network-summary-LSA、ASBR-summary-LSA、AS-External-LSA、NSSA-LSA，接
小程序學習筆記二：頁面文件詳解之 .json文件
fresh 小程序 整體 屬性 spa hit rbac style mdi 頁面配置文件—— pageName.json 每一個小程序頁面可以使用.json文件來對本頁面的窗口表現進行配置，頁面中配置項會覆蓋 app.json 的 window 中相同的配置
spring-data詳解之spring-data-jpa：簡單三步快速上手spring-data-jpa開發
事務管理 out don 前言 map lns xid public lease 前言： 基於spring framework 4.x或spring boot 1.x開發環境 務必註意以下版本問題：Spring framework4.x(Spring boot1.x)對應s
[轉]javaCV開發詳解之5：錄製音訊(錄製麥克風)到本地檔案/流媒體伺服器(基於javax.sound、javaCV-FFMPEG)
本文轉載自部落格：https://blog.csdn.net/eguid_1/article/details/52702385 ------------------------------------------------------------------------------------
ALSA音效卡驅動中的DAPM詳解之二：widget-具備路徑和電源管理資訊的kcontrol
上一篇文章中，我們介紹了音訊驅動中對基本控制單元的封裝：kcontrol。利用kcontrol，我們可以完成對音訊系統中的mixer，mux，音量控制，音效控制，以及各種開關量的控制，通過對各種kcontrol的控制，使得音訊硬體能夠按照我們預想的結果進行工作。同時我
ALSA音效卡驅動中的DAPM詳解之七：dapm事件機制（dapm event）
前面的六篇文章，我們已經討論了dapm關於動態電源管理的有關知識，包括widget的建立和初始化，widget之間的連線以及widget的上下電順序等等。本章我們準備討論dapm框架中的另一個機制：事件機制。通過dapm事件機制，widget可以對它所關心的dapm事
基於Redis Sentinel的Redis叢集(主從&Sharding)高可用方案
本文主要介紹一種通過Jedis&Sentinel實現Redis叢集高可用方案，該方案需要使用Jedis2.2.2及以上版本（強制），Redis2.8及以上版本(可選，Sentinel最早出現在Redis2.4中，Redis2.8中Sentinel更加穩定)，Red
Java單元測試工具：JUnit4（三）——JUnit詳解之執行流程及常用註解
（三）執行流程及常用註解 這篇筆記記錄JUnit測試類執行時，類中方法的執行順序；以及JUnit中常用的註解。 1.JUnit的執行流程 1.1 新建測試類
大資料之hdfs詳解之三：put許可權剖析與常用命令
–無論是對於hdfs的讀和寫，對於使用者來說都是無感知的、透明的操作，使用者並不關心資料如何讀出來如何寫進去的，只要返回一個結果告訴使用者資料讀出來了或寫進去了，至於怎麼讀怎麼寫，使用者並不關心 補充： 讀：hdfs dfs -ls / = hdfs dfs
高併發的詳解及解決方案
一、什麼是高併發 高併發（High Concurrency）是網際網路分散式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證系統能夠同時並行處理很多請求。 高併發相關常用的一些指標有響應時間（Response Time），吞吐量（Throughput），每秒查詢率QPS（Quer
kafka配置檔案詳解之：server.properties
#每一個broker在叢集中的唯一表示，要求是正數。當該伺服器的IP地址發生改變時，broker.id沒有變化，則不會影響consumers的訊息情況broker.id=0#broker server服務埠 port =9092#處理網路請求的執行緒數量num
redis詳解——redis叢集搭建和使用（二）
上一章我寫到redis簡單的介紹和如何單機的使用，當我們redis相當重要的時候那麼接下來就需要搭建一個叢集了。 1 Redis叢集的介紹 1.1 redis-cluster（叢集）架構圖 架構細節: (1)所有的redis節點彼此互聯(PING-PONG機制),
【方法】Redis叢集生產環境高可用方案實戰過程
佈署方案說明 1、sentinel負責對redis叢集中的主從服務監控、提醒和自動故障轉移 2、redis叢集負責對外提供相關服務 Sentinel原理介紹 原理： s