前言
一直都想本身動手搭建一個Redis集羣和MySQL的主從同步，固然不是依靠Docker的一鍵部署（雖然如今企業開發用的最多的是這種方式），因此本文就算是一個教程類文章吧，但在動手搭建以前，會先聊聊理論的東西，以便於你們有一個集羣和主從同步的概念，若是有同窗不瞭解Redis和MySQL，能夠看一下我以前的兩篇文章。node
Redis由淺入深深深深深剖析mysql
從入門到入土：使人脫髮的數據庫底層設計nginx
什麼是Redis集羣
簡介
Redis是一個快速高效的NoSQL型數據庫，因爲其基於內存存儲、單線程、多路IO複用的特性，其QPS能夠達到驚人的100000+（官方數據），可是即便有這麼高的速度，在中國這麼大的網民基數環境下，也存在着性能瓶頸。程序員
首先拋開服務器故障不談，Redis集羣首先可使Redis性能獲得線性提升，這是毋庸置疑的，其次Redis集羣除了解決了效率問題，還能夠解決服務器宕機形成的數據丟失問題，當某個Redis節點宕機，剩下的節點會繼續工做，並不會影響總體集羣的使用，從而實現高可用。redis
Redis單機模式有什麼問題
單機故障sql
在單機模式下的Redis，咱們的應用中全部須要緩存的數據都依賴一臺Redis服務器，應用的流量小可能看不出什麼問題，可是隨着應用愈來愈大，流量愈來愈大，若是出現服務器宕機或者斷電的情況，那麼咱們的應用整個一個緩存層在一段時間內（重啓）都將不復存在。docker
先不談基於Redis的分佈式Session可能形成的問題，若是剛好趕上流量高峯，這些流量直接打在數據庫上，咱們知道數據庫的IO效率遠不及Redis，這將大大提升應用負載，容易出現數據庫服務器的宕機，從而形成應用的宕機。數據庫
由此看來，單機版Redis若是出現故障，將有可能引發一系列的連鎖反應，形成不可逆的損失。
容量瓶頸
咱們知道Redis是基於內存存儲的一個NoSQL數據庫，基於內存也是其高速高效的緣由之一。雖然容量瓶頸在實際生產中並不常見（一般有意識地將搭載Redis的機器內存容量加高），可是不排除在某些極端條件下Redis會將一臺機器的內存耗盡，形成數據丟失，甚至服務器宕機。
性能瓶頸
簡介中提到，雖然Redis在官方文檔中提到能夠達到約100000+QPS，可是首先在平常環境的測試中，咱們可能並達不到文檔中宣稱的QPS，換言之，這可能也就是一種理論值，就像是4G的理論網速在10-100Mbps，摺合下載速度1.5M/s-10M/s。
但在平常生活中咱們極少甚至歷來沒有達到過這個速度過，同樣的道理。其次，在中國巨大的網民基數下，單機Redis知足平常需求尚且捉襟見肘，若是碰上像雙11、雙12、春運這些特殊的環境，單臺Redis顯然會有性能不足的現象發生。
Redis集羣的三種模式
主從模式
主從模式是最簡單的一種Redis集羣模式，首先其思想就是一臺Redis服務器做爲主服務器（Master），一臺或多臺服務器做爲從服務器（Slave）。當以此種方式部署集羣時，集羣有以下特色：
- Master能夠進行讀寫操做，當寫操做致使數據發生變化時，將自動同步給Slave，Slave一般是隻讀的，而且接受從Master同步過來的數據。
- 一臺Master能夠有多臺Slave，但每臺Slave只能有一個Master。
- 某臺Slave宕機不影響其餘Slave和Master的讀寫，從新啓動後會將數據從新從Master同步過來。
- Master宕機後不影響Slave的讀，但該集羣再也不提供對Redis的寫入功能。
- Master宕機後不會從Slave中選舉主節點。
在此種模式下，咱們能夠對Redis集羣作容災備份和讀寫分離，可是要注意，容災備份並不能拯救你的誤操做，由於不管增刪改，Redis都將其做爲寫，同步到每一個Slave節點上，因此容災，是指不可預知的錯誤致使數據丟失，這種狀況下能夠從Slave節點中找到原數據的備份，從而進行數據恢復。
而讀寫分離就比較好理解了，上文中提到，Master節點能夠讀寫，而Slave節點一般只進行讀操做，索性直接將全部的讀操做都轉移到Slave節點上，這樣能夠減輕Master節點的IO壓力。
主從模式的工做原理（全量同步）:
Redis全量同步通常發生在Slave初始化階段，但其實在任什麼時候候Slave均可以向Master發起全量同步的請求，這時Slave須要將Master上的全部數據都複製一份。
- Slave鏈接主服務器，發送SYNC命令。
- Master接收到SYNC命令後，開始執行BGSAVE命令生成RDB文件並使用緩衝區記錄此後執行的全部寫命令。
- Master執行完BGSAVE後，向全部從服務器發送RDB文件，並在發送期間繼續記錄被執行的寫命令。
- Slave收到RDB文件後丟棄全部舊數據，載入收到的RDB。
- Master快照發送完畢後開始向Slave發送緩衝區中的寫命令。
- Slave完成對RDB的載入，開始接收命令請求，並執行來自Master緩衝區的寫命令。
主從模式的工做原理（增量同步）:
Redis增量同步通常發生在Slave已經初始化完成，開始正常鏈接Master的階段
- Master接收到寫請求，將寫命令發送到Slave。
- Slave執行接收到的些命令。
注：若是多個Slave同時宕機重啓，那麼就會同時向Master發送SYNC命令，那麼有可能會形成Master節點的IO劇增，有可能會引發宕機。
哨兵（Sentinel）模式
上文中介紹了Redis主從複製模式下的集羣策略，當Master宕機後，不會從Slave節點中選舉出Master，因此該集羣喪失了寫的能力，咱們只能人工去將Slave節點晉升爲Master節點，同時要通知應用方更新Master節點的IP地址，對於這種故障處理的方式在如今的環境下一般是不可接受的。因此從Redis2.8開始，Redis正式提供了哨兵模式的架構（故障轉移），來解決這個問題。
哨兵模式的工做特色：
- 哨兵模式是創建在主從模式的基礎上，當Master節點宕機以後，哨兵會從Slave節點中選擇一個節點做爲Master，並修改它們的配置文件，使其餘的Slave指向新的Master。
- 當原先宕機的Master節點從新啓動時，他將再也不是Master，而是做爲新Master的一個Slave節點存在。
- 哨兵節點是一個特殊的Redis節點（不存儲數據），本質上也是一個進程，因此也有掛掉的可能，因此哨兵也存在集羣模式。
哨兵模式工做原理：
- 每隔10秒，每一個哨兵節點會向Master和Slave節點發送info命令獲取最新的拓撲結構。
- 每隔1秒，每一個哨兵節點會向Master和Slave節點還有其它哨兵節點發送ping命令作心跳檢測，看看是否存在不可達的節點。
- 主觀下線，若是某個哨兵向一個節點發出的心跳檢測沒有獲得響應，那麼該哨兵認爲該節點已經下線。
- 客觀下線，當哨兵主觀下線的節點是主節點時，哨兵會向其餘的哨兵詢問對主節點的判斷，當下線判斷超過必定個數時，那麼哨兵會認爲主節點確實已經下線，那麼會對主節點進行客觀下線的斷定。
- 故障轉移，當Master節點客觀下線時，哨兵會從Slave節點中選擇一個節點做爲Master節點，選擇規則是選擇與主節點複製類似度最高的節點，選擇完成後會將其他的Slave節點指向新的Master節點，並監控原來的Master節點，當它回覆後做爲新Master節點的Slave存在，而且同步新Master節點的數據。
- 選舉領導者哨兵節點：當主節點被判斷客觀下線之後，各個哨兵節點會進行協商，選舉出一個領導者哨兵節點，並由該領導者節點對其進行故障轉移操做。
- 當使用sentinel模式的時候，客戶端不用直接鏈接Redis，而是鏈接哨兵的ip和port，由哨兵來提供具體的可提供服務的Redis實現，這樣當master節點掛掉之後，哨兵就會感知並將新的master節點提供給使用者。
Cluster模式
在上文的哨兵模式中，哨兵引入了主節點的自動故障轉移，進一步提升了Redis的高可用性。可是哨兵的缺陷一樣很明顯：哨兵沒法對Slave進行自動故障轉移，在讀寫分離場景下，Slave故障會致使讀服務不可用，須要咱們對Slave作額外的監控、切換操做。
此外，哨兵仍然沒有解決寫操做沒法負載均衡、及存儲能力受到單機限制的問題。
Redis Cluster模式是Redis3.0以後推薦的一種解決方案，其是由多個主節點羣組成的分佈式服務器羣，它具備複製、高可用和分片的特性。另外，Redis Cluster集羣不須要哨兵也能完成節點移除和故障轉移的功能。須要將每一個節點設置爲集羣模式，這種集羣模式沒有中心節點，可水平擴展，且集羣配置很是簡單。
Cluster集羣模式工做特色：
- 多個Redis節點互聯，數據共享。
- 全部的節點都是主從模式，其中Slave不提供服務，只提供備用。
- 不支持同時處理多個Key，由於須要分發到多個節點上。
- 支持在線增長、刪除節點。
- 客戶端能夠鏈接任何一個Master節點進行讀寫。
Cluster集羣模式工做原理：
Redis Cluster有固定的16384個hash slot(槽)，對每一個key計算CRC16值，而後對16384取模，能夠獲取key對應的hash slot。每一個master都會持有部分slot，好比有3個master，那麼可能每一個master持有5000多個hash slot，在redis cluster寫入數據的時候。
實際上是你能夠將請求發送到任意一個master上去執行。可是，每一個master都會計算這個key對應的CRC16值，而後對16384個hashslot取模，找到key對應的hashslot，找到hashslot對應的master。
主觀下線(pfail)：集羣中的每一個節點都會按期向其餘節點發送ping消息，若是在一段時間內一直通訊失敗，則發送節點方認爲接收節點存在故障，把接收節點標爲主觀下線(pfail)狀態。
客觀下線(fail)：當某個節點判斷另外一個節點主觀下線後，相應的節點狀態就會在集羣中進行傳播，若是集羣中全部節點都將它標爲主觀下線，那麼該節點爲客觀下線，並通知該節點的Slave進行故障轉移操做。
故障轉移：在某個節點客觀下線後，該節點的從節點開始故障轉移流程，首先進行資格檢查，每一個從節點檢查與主節點的斷開時間，超過必定時間的取消選舉資格，而後一樣在全部從節點中尋找複製偏移量最大的節點先開始進行選舉，只有持有槽的主節點纔有投票權，當從節點收集到過半的票數時，即晉升爲Master，隨即通知Slave當前Master變爲本身。
搭建Redis集羣
上文中說了三種Redis搭建的模式，分別是主從模式、哨兵模式、Cluster模式，關於前兩種網上有着很是多的教程，這裏就再也不從新演示了，這裏着重演示一下如何去搭建一個Redis Cluster集羣。
環境準備
CentOS 7，Redis5.0.4
場景描述
本次會啓動三臺CentOS 7服務器，每臺服務器上搭載三個Redis實例，一主二從，一共三個Master實例，六個Slave實例。
清單以下：
Master 1：IP：192.168.43.101 Port：7001 Master 2：IP：192.168.43.102 Port：7002 Master 3：IP：192.168.43.103 Port：7003 Slave 1：IP：192.168.43.101 Port：6001 Slave 2：IP：192.168.43.102 Port：6002 Slave 3：IP：192.168.43.103 Port：6003 Slave 4：IP：192.168.43.101 Port：6004 Slave 5：IP：192.168.43.102 Port：6005 Slave 6：IP：192.168.43.103 Port：6006
修改配置文件
熟悉Redis的應該明白，所謂Redis實例，實際上就是一個又一個的配置文件。要在服務器上啓動多臺不一樣Redis，實際上就是使用不一樣的配置文件來啓動Redis，因此第一步咱們要先對集羣中的每個Redis實例配置不同的配置文件。
綁定Redis地址
下列三臺主機上的配置文件均爲Master節點配置文件（修改bind屬性）
修改端口號
將端口號修改成自定義的端口號，默認爲6379,修改成咱們自定義的端口號。
開啓集羣模式並設置集羣配置文件
將cluster-enabled 設置爲yes，並將cluster-config-file設置爲自定義的文件。
這裏定義爲nodes-端口號.conf
修改集羣RDB快照和AOF文件的存放位置
修改dir屬性，這裏定義爲/home/redis-cluster/redis-master/
修改集羣密碼
修改masterauth屬性爲Redis（RequirePass）密碼。
開啓AOF持久化
修改appendonly屬性
appendonly yes
對六臺Slave節點進行一樣的修改配置操做
注意：上述指定的文件夾和文件名原則上對於每一個redis實例都應該是惟一的，便於區分。
啓動Redis實例
運行命令：
#第一臺主機 /usr/local/bin/redis-server /home/redis-cluster/redis-master/redis-master-7001.conf /usr/local/bin/redis-server /home/redis-cluster/redis-slave/redis-slave-6001.conf /usr/local/bin/redis-server /home/redis-cluster/redis-slave/redis-slave-6004.conf #第二臺主機 /usr/local/bin/redis-server /home/redis-cluster/redis-master/redis-master-7002.conf /usr/local/bin/redis-server /home/redis-cluster/redis-slave/redis-slave-6002.conf /usr/local/bin/redis-server /home/redis-cluster/redis-slave/redis-slave-6005.conf #第三臺主機 /usr/local/bin/redis-server /home/redis-cluster/redis-master/redis-master-7003.conf /usr/local/bin/redis-server /home/redis-cluster/redis-slave/redis-slave-6003.conf /usr/local/bin/redis-server /home/redis-cluster/redis-slave/redis-slave-6006.conf
查看進程 ps -ef | grep redis：
能夠看到如今啓動的redis實例已是集羣模式的了。
搭建集羣
輸入命令：
/usr/local/bin/redis-cli -a Object --cluster create --cluster-replicas 2 192.168.43.101:7001 192.168.43.102:7002 192.168.43.103:7003 192.168.43.101:6001 192.168.43.102:6002 192.168.43.103:6003 192.168.43.101:6004 192.168.43.102:6005 192.168.43.103:6006
其中 --cluster-replicas 2表明每一個Master攜帶2個Slave，那麼就是三個Master，每一個Master攜帶兩個Slave。
示意圖以下：
咱們能夠看到，Redis將三臺機器連成了一個總體，Master7001的Slave指向了其它兩臺服務器上的Slave，而其它兩臺服務器的Master也一樣跨服務器指向了，這就是RedisCluster高可用的策略，假設有一臺服務器完整地宕機了，因爲本身的Slave節點存在於別的服務器上，數據也能從新經過選舉選舉的方式恢復，不易引發數據的丟失。
另外咱們能夠看到，咱們在上文說過，Cluster集羣模式將集羣分爲16384個槽，這裏體現爲0-16383，分佈到了每個Master節點上，這對咱們以前的理論部分作了驗證。
測試
測試環節經過客戶端測試和Java程序測試，來模擬集羣模式下Redis的存儲策略。
客戶端測試
開啓客戶端，隨意鏈接一個master節點
/usr/local/bin/redis-cli -c -a 密碼 -h IP -p 端口
咱們能夠看到，當咱們set一個鍵值對的時候，Redis會自動爲咱們的key計算CRC16值，而後對16384取模，獲取key對應的hash slot，而後經過判斷該槽被那個Master所佔用，幫咱們重定向到那個Master節點，將鍵值對存入。
程序測試
在測試以前先把Redis中的數據清空，對三個Master節點分別執行flushall命令。
啓動程序：
1.正常存入數據時關閉某Master節點（模擬宕機）：
程序打印正在選舉…
2.選舉結束後繼續IO
代碼：
public class JedisDemo {
public static void main(String[] args) {
JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
Set<HostAndPort> nodes = new HashSet<>();
nodes.add(new HostAndPort("192.168.43.101",7001));
nodes.add(new HostAndPort("192.168.43.102",7002));
nodes.add(new HostAndPort("192.168.43.103",7003));
nodes.add(new HostAndPort("192.168.43.101",6001));
nodes.add(new HostAndPort("192.168.43.102",6002));
nodes.add(new HostAndPort("192.168.43.103",6003));
nodes.add(new HostAndPort("192.168.43.101",6004));
nodes.add(new HostAndPort("192.168.43.102",6005));
nodes.add(new HostAndPort("192.168.43.103",6006));
JedisCluster jedisCluster = new JedisCluster(nodes,100,1000,100,"Object","rediscluster",jedisPoolConfig,false);
for(int i = 0;i<2000;i++) {
try {
System.out.println("存入數據:"+i);
jedisCluster.set(String.valueOf(i),String.valueOf(i));
try {
Thread.sleep(300);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
String res = jedisCluster.get(String.valueOf(i));
System.out.println("取出數據:"+res);
}catch(Exception e) {
//出現節點宕機
System.out.println("正在選舉...");
System.out.println(new Date());
continue;
}
}
jedisCluster.close();
}
}
注意事項
在搭建集羣的過程當中有可能會遇到一直等待鏈接，可是集羣沒法鏈接成功的情況，這是由於咱們在搭建集羣的時候防火牆沒有開啓對應的端口號致使的，咱們不光要開啓咱們對外鏈接的端口號，如700一、700二、7003，還要開啓對外鏈接端口號+10000的端口，用於集羣內部相互通訊，如節點端口爲700一、700二、7003，那麼咱們還應該開啓1700一、1700二、17003這些端口。
若是遇到搭建失敗的狀況，從新搭建的時候必定要到dir指向的文件夾中將快照和AOF還有node.conf文件刪乾淨，不然沒法從新搭建。
搭建完畢
至此咱們已經完成了Redis集羣的搭建，在私下實踐的時候能夠試試使用Redis客戶端直接操做集羣時手動關閉某個Master，會出現什麼樣的情況，這個是文章中沒有提到的內容。
什麼是MySQL主從同步
數據是一個應用相當重要的一部分。從目的出發，主從同步有那麼點備份的意思，主庫（Master）將本身庫中的寫入同時同步給本身的從庫（Slave），當主庫發生某些不可預知的情況，致使整個服務器沒法使用時，因爲從庫中也有一份數據，因此數據能夠作到快速恢復，不形成或者減小形成數據的損失。
固然，這只是第一個層面，若是主從庫的做用僅限於此，那麼我我的認爲沒有必要分爲兩個數據庫，只須要按期將數據庫內容做爲快照發送到另外一臺服務器，或者每次寫入時將寫入內容實時發送到另外一臺服務器不就行了嗎，這樣不但能夠節約資源，也能夠起到容災備份的目的。
固然主從同步的做用毫不可能僅限於此，一旦咱們配置了主從結構，咱們一般不會讓從節點僅僅只做爲備份數據庫，咱們應該還會相應地配置上讀寫分離（可使用MyCat或者其它中間件，能夠本身瞭解一下，關於MyCat我在下一篇博客中會說這個，篇幅可能會有點長，因此就再寫一篇吧）。
在實際環境下，對於數據庫的讀操做數目遠大於對數據庫的寫操做，因此咱們可讓Master只提供寫的功能，而後將全部的讀操做都移到從庫，這就是咱們平時常說的讀寫分離，這樣不但能夠減輕Master的壓力，還能夠作容災備份，一箭雙鵰。
MySQL主從同步的原理
說完了主從同步的概念，下面來講說主從同步的原理，其實原理也很是簡單，沒有Redis集羣那麼多的概念。
實際上當咱們在MySQL中配置了主從以後，只要咱們對Master節點進行了寫操做，這個操做將會被保存到MySQL的binary-log（bin-log）日誌當中，當slave鏈接到master的時候，master機器會爲slave開啓binlog dump線程。當master 的 binlog發生變化的時候，Master的dump線程會通知slave，並將相應的binlog內容發送給Slave。而Slave節點在主從同步開啓的時候，會建立兩個線程，一個I/O線程，一個SQL線程，這在咱們後面的搭建中能夠親眼看到。
- I/0線程：該線程連接到master機器，master機器的binlog發送到slave的時候，IO線程會將該日誌內容寫在本地的中繼日誌（Relay log）中。
- SQL線程：該線程讀取中繼日誌中的內容，而且根據中繼日誌中的內容對Slave數據庫作相應的操做。
- 可能形成的問題：在寫請求至關多的狀況下，可能會形成Slave數據和Master數據不一致的狀況，這是由於日誌傳輸過程當中的短暫延遲、或者寫命令較多，系統速度不匹配形成的。
這大體就是MySQL主從同步的原理，真正在其中起到做用的實際上就是這兩個日誌文件，binlog和中繼日誌。
手動搭建MySQL主從同步
環境準備
本次搭建主從同步的環境：CentOS 7 ,MySQL 8.0.18（使用二進制包安裝）。
場景介紹
本次將會搭建MySQL的主從同步，其中一臺Master，兩臺Slave。
Master:IP :192.168.43.201 Port:3306 Slave1:IP:192.168.43.202 Port:3306 Slave2:IP:192.168.43.203 Port:3306
開始搭建
修改配置文件
當咱們安裝好MySQL以後，在/etc/目錄下會有一個my.cnf文件，打開文件，加入以下內容(別忘了修改以前作好備份)：
x
#該配置爲Master的配置 server-id=201 #Server id 每臺MySQL的必須不一樣 log-bin=/var/lib/mysql/mysql-bin.log #表明開啓binlog日誌 expire_logs_days=10 #日誌過時時間 max_binlog_size=200M #日誌最大容量 binlog_ignore_db=mysql #忽略mysql庫，表示不一樣步此庫
y
#該配置爲Slave的配置,第二臺Slave也是這麼配置，不過要修改一下server-id server-id=202 expire_logs_days=10 #日誌的緩存時間 max_binlog_size=200M #日誌的最大大小 replicate_ignore_db=mysql #忽略同步的數據庫
新增Slave用戶
打開Master節點的客戶端 ，mysql -u root -p 密碼
建立用戶 create user 'Slave'@'%' identified by '123456';
給新建立的用戶賦權：grant replication slave on '*.*' to 'Slave'@'%';
查看Master節點狀態
以上操做都沒有問題後，咱們在客戶端中輸入show master status查看master的binlog日誌。
配置兩個Slave節點
打開兩個Slave節點客戶端，在咱們的另外兩個Slave節點中輸入以下命令：
change master to master_user='Slave',master_password='123456',master_host='192.168.43.201',master_log_file='mysql-bin.000005',master_log_pos=155,get_master_public_key=1; #注意，這裏的master_log_file，就是binlog的文件名，輸入上圖中的mysql-bin.000005,每一個人的均可能不同。 #注意，這裏的master_log_pos是binlog偏移量，輸入上圖中的155，每一個人的均可能不同。
配置完成後，輸入start slave;開啓從節點，而後輸入show slave statusG;查看從節點狀態
能夠看到，在兩臺Slave的狀態中，咱們能親眼看到IO線程和SQL線程的運行狀態，這兩個線程必須都是yes，纔算配置搭建完成。
搭建完成
經過上述步驟，就完成了MySQL主從同步的搭建，相對Redis而言MySQL配置至關簡單。下面咱們能夠進行測試。
先看看三個MySQL的數據庫狀態：SHOW DATABASES;
能夠看到如今數據庫都是初始默認狀態，沒有任何額外的庫。
在Master節點中建立一個數據庫，庫名能夠本身設置。
CREATE DATABASE testcluster;
能夠看到，在Slave中也出現了Master中建立的數據庫，說明咱們的配置沒有問題，主從搭建成功。這裏就再也不建立表了，你們能夠本身試試，建立表再往表中插入數據，也是沒有任何問題的。
注意事項
若是出現IO線程一直在Connecting狀態，能夠看看是否是三臺機器沒法相互鏈接，若是能夠相互鏈接，那麼有多是Slave帳號密碼寫錯了，從新關閉Slave而後輸入上面的配置命令再打開Slave便可。
若是出現SQL線程爲NO狀態，那麼有多是從數據庫和主數據庫的數據不一致形成的，或者事務回滾，若是是後者，先關閉Slave，而後先查看master的binlog和position，而後輸入配置命令，再輸入set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;，再從新start slave;便可，如經過是前者，那麼就排查一下是否是存在哪張表沒有被同步，是否存在主庫存在而從庫不存在的表，本身同步一下再從新配置一遍便可。
結語
在寫這篇文章以前本身也被一些計算機領域的「名詞」嚇到過，相信有很多同窗都有同樣的體會，碰上某些高大上的名詞老是先被嚇到，例如像「分佈式」、「集羣」等等等等，甚至在沒接觸過nginx以前，連」負載均衡「、」反向代理「這樣的詞都讓人以爲，這麼高達上的詞，確定很難吧，但其實本身瞭解了nginx、ribbon等以後才發現，其實也就那麼回事吧，沒有想象中的那麼難。
因此寫這篇文章的初衷是想讓你們對集羣化或者分佈式或者其餘的一些技術或者解決方案不要有一種望而卻步的感受（感受計算機領域的詞都有這麼一種特色，詞彙高大上，可是其實思想是比較好理解的），其實本身手動配置出一個簡單的集羣並無那麼難。
若是學會docker以後再來配置就更加簡單了，可是更但願不要只侷限於會配置，配置出來的東西只能說你會配置了，可是在這層配置底下是前人作了至關多的工做，才能使咱們經過簡單配置就能實現一些功能，應該要深刻底層，瞭解配置下面的工做原理，這個纔是最重要的，也是體現一個程序員水平的地方。
最後，歡迎關注個人公衆號： Java知音