這次一定要教會你搭建Redis集群和MySQL主從同步(非Docker)

前言

一直都想自己動手搭建一個Redis集群和MySQL的主從同步，當然不是依靠Docker的一鍵部署（雖然現在企業開發用的最多的是這種方式），所以本文就算是一個教程類文章吧，但在動手搭建之前，會先聊聊理論的東西，以便於大家有一個集群和主從同步的概念，如果有同學不了解Redis和MySQL，可以看一下我之前的兩篇文章。

Redis由淺入深深深深深剖析

從入門到入土：令人脫發的數據庫底層設計

什么是Redis集群

簡介

Redis是一個快速高效的NoSQL型數據庫，由於其基於內存存儲、單線程、多路IO復用的特性，其QPS可以達到驚人的100000+（官方數據），但是即使有這么高的速度，在中國這么大的網民基數環境下，也存在着性能瓶頸。

首先拋開服務器故障不談，Redis集群首先可以使Redis性能得到線性提高，這是毋庸置疑的，其次Redis集群除了解決了效率問題，還可以解決服務器宕機造成的數據丟失問題，當某個Redis節點宕機，剩下的節點會繼續工作，並不會影響整體集群的使用，從而實現高可用。

Redis單機模式有什么問題

單機故障

在單機模式下的Redis，我們的應用中所有需要緩存的數據都依賴一台Redis服務器，應用的流量小可能看不出什么問題，但是隨着應用越來越大，流量越來越大，如果出現服務器宕機或者斷電的狀況，那么我們的應用整個一個緩存層在一段時間內（重啟）都將不復存在。

先不談基於Redis的分布式Session可能造成的問題，如果恰好遇上流量高峰，這些流量直接打在數據庫上，我們知道數據庫的IO效率遠不及Redis，這將大大提高應用負載，容易出現數據庫服務器的宕機，從而造成應用的宕機。

由此看來，單機版Redis如果出現故障，將有可能引起一系列的連鎖反應，造成不可逆的損失。

容量瓶頸

我們知道Redis是基於內存存儲的一個NoSQL數據庫，基於內存也是其高速高效的原因之一。雖然容量瓶頸在實際生產中並不常見（通常有意識地將搭載Redis的機器內存容量加高），但是不排除在某些極端條件下Redis會將一台機器的內存耗盡，造成數據丟失，甚至服務器宕機。

性能瓶頸

簡介中提到，雖然Redis在官方文檔中提到可以達到約100000+QPS，但是首先在日常環境的測試中，我們可能並達不到文檔中宣稱的QPS，換言之，這可能也就是一種理論值，就像是4G的理論網速在10-100Mbps，折合下載速度1.5M/s-10M/s。

但在日常生活中我們極少甚至從來沒有達到過這個速度過，一樣的道理。其次，在中國巨大的網民基數下，單機Redis滿足日常需求尚且捉襟見肘，如果碰上像雙十一、雙十二、春運這些特殊的環境，單台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();
    }
}

 

注意事項

在搭建集群的過程中有可能會遇到一直等待連接，但是集群無法連接成功的狀況，這是因為我們在搭建集群的時候防火牆沒有開啟對應的端口號導致的，我們不光要開啟我們對外連接的端口號，如7001、7002、7003，還要開啟對外連接端口號+10000的端口，用於集群內部相互通信，如節點端口為7001、7002、7003，那么我們還應該開啟17001、17002、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知音