源碼一致性

❶ svn和git的區別

SVN是Subversion的簡稱，是一個開放源代碼的版本控制系統，相較於RCS、CVS，它採用了分支管理系統，它的設計目標就是取代CVS。互聯網上很多版本控制服務已從CVS遷移到Subversion。
svn伺服器有2種運行方式：獨立伺服器和藉助apache運行。兩種方式各有利弊，用戶可以自行選擇。
svn存儲版本數據也有2種方式：BDB(一種事務安全型表類型)和FSFS(一種不需要資料庫的存儲系統)。因為BDB方式在伺服器中斷時，有可能鎖住數據，所以還是FSFS方式更安全一點。
集中式代碼管理的核心是伺服器，所有開發者在開始新一天的工作之前必須從伺服器獲取代碼，然後開發，最後解決沖突，提交。所有的版本信息都放在伺服器上。如果脫離了伺服器，開發者基本上可以說是無法工作的。下面舉例說明：
開始新一天的工作：
1、從伺服器下載項目組最新代碼。
2、進入自己的分支，進行工作，每隔一個小時向伺服器自己的分支提交一次代碼（很多人都有這個習慣。因為有時候自己對代碼改來改去，最後又想還原到前一個小時的版本，或者看看前一個小時自己修改了哪些代碼，就需要這樣做了）。
3、下班時間快到了，把自己的分支合並到伺服器主分支上，一天的工作完成，並反映給伺服器。
這就是經典的svn工作流程，從流程上看，有不少缺點，但也有優點。
缺點：
1、伺服器壓力太大，資料庫容量暴增。
2、如果不能連接到伺服器上，基本上不可以工作，看上面第二步，如果伺服器不能連接上，就不能提交，還原，對比等等。
3、不適合開源開發（開發人數非常非常多，但是Google app engine就是用svn的）。但是一般集中式管理的有非常明確的許可權管理機制（例如分支訪問限制），可以實現分層管理，從而很好的解決開發人數眾多的問題。
優點：
1、管理方便，邏輯明確，符合一般人思維習慣。
2、易於管理，集中式伺服器更能保證安全性。
3、代碼一致性非常高。
4、適合開發人數不多的項目開發。
5、大部分軟體配置管理的大學教材都是使用svn和vss。
Git是一款免費、開源的分布式版本控制系統，用於敏捷高效地處理任何或小或大的項目。
Git 是 Linus Torvalds 為了幫助管理 Linux 內核開發而開發的一個開放源碼的版本控制軟體。
Torvalds 開始著手開發 Git 是為了作為一種過渡方案來替代 BitKeeper，後者之前一直是 Linux 內核開發人員在全球使用的主要源代碼工具。開放源碼社區中的有些人覺得 BitKeeper 的許可證並不適合開放源碼社區的工作，因此 Torvalds 決定著手研究許可證更為靈活的版本控制系統。盡管最初 Git 的開發是為了輔助 Linux 內核開發的過程，但是我們已經發現在很多其他自由軟體項目中也使用了 Git。例如 最近就遷移到 Git 上來了，很多 Freedesktop 的項目也遷移到了 Git 上。
特點：
分布式相比於集中式的最大區別在於開發者可以提交到本地，每個開發者機器上都是一個完整的資料庫。
Git的功能特性：
從一般開發者的角度來看，git有以下功能：
1、從伺服器上克隆資料庫（包括代碼和版本信息）到單機上。
2、在自己的機器上創建分支，修改代碼。
3、在單機上自己創建的分支上提交代碼。
4、在單機上合並分支。
5、新建一個分支，把伺服器上最新版的代碼fetch下來，然後跟自己的主分支合並。
6、生成補丁（patch），把補丁發送給主開發者。
7、看主開發者的反饋，如果主開發者發現兩個一般開發者之間有沖突（他們之間可以合作解決的沖突），就會要求他們先解決沖突，然後再由其中一個人提交。如果主開發者可以自己解決，或者沒有沖突，就通過。
8、一般開發者之間解決沖突的方法，開發者之間可以使用pull 命令解決沖突，解決完沖突之後再向主開發者提交補丁。
從主開發者的角度（假設主開發者不用開發代碼）看，git有以下功能：
1、查看郵件或者通過其它方式查看一般開發者的提交狀態。
2、打上補丁，解決沖突（可以自己解決，也可以要求開發者之間解決以後再重新提交，如果是開源項目，還要決定哪些補丁有用，哪些不用）。
3、向公共伺服器提交結果，然後通知所有開發人員。
優點：
適合分布式開發，強調個體。
公共伺服器壓力和數據量都不會太大。
速度快、靈活。
任意兩個開發者之間可以很容易的解決沖突。
離線工作。
缺點：
資料少（起碼中文資料很少）。
學習周期相對而言比較長。
不符合常規思維。
代碼保密性差，一旦開發者把整個庫克隆下來就可以完全公開所有代碼和版本信息。

❷ Zookeeper之兩階段提交源碼分析

zookeeper集群為了保證數據一致性，使用了兩階段提交。
在zookeeper集群的角色有：leader、follower、observer。
在這幾個角色中處理讀寫請求是不同的：
讀請求：從當前節點直接讀取數據
寫請求：在leader直接進行兩階段提交、在非leader則是把請求轉交給leader處理
所以，分析兩階段提交就是分析集群模式下的請求處理。在單機模式在請求處理是經過RequestProcessor請求處理鏈處理。
單個zookeeprt請求處理主要有以下幾步：
1、對當前請求生成日誌txn
2、持久化日誌txn
3、根據日誌txn更新Database
兩階段提交（2PC）步驟：

其中標綠色的PrepRequestProcessor、SyncRequestProcessor、CommitProcessor都繼承了ZooKeeperCriticalThread是一個線程。
org.apache.zookeeper.server.quorum.LeaderZooKeeperServer#setupRequestProcessors

org.apache.zookeeper.server.quorum.ProposalRequestProcessor#ProposalRequestProcessor

org.apache.zookeeper.server.quorum.LeaderRequestProcessor#processRequest

①、檢查是不是local session本地session，創建臨時節點會升級session
org.apache.zookeeper.server.quorum.QuorumZooKeeperServer#checkUpgradeSession

②、交給下一個請求處理器處理

作用與單機模式相同，給請求Request的Hdr和Txn賦值，然後交給下一個請求處理器處理

如果是寫請求(request.getHdr() != null)，則會把當前請求封裝為協議並發送給follower。發送之後交給SyncRequestProcessor持久化處理

org.apache.zookeeper.server.quorum.Leader#propose

org.apache.zookeeper.server.quorum.Leader#sendPacket
發送到所有其他Followe節點forwardingFollowers

把請求放入到queuedRequests阻塞隊列

①、對請求進行持久化與單機相同
org.apache.zookeeper.server.SyncRequestProcessor#run

向lead發送自己的ack（2PC發送ACK）

org.apache.zookeeper.server.quorum.Leader#processAck

org.apache.zookeeper.server.quorum.Leader#tryToCommit

org.apache.zookeeper.server.quorum.CommitProcessor#commit
提交當前請求，放入到committedRequests，最終會更新database

CommitProcessor類參數：
queuedRequests：表示接收到的請求，沒有進行兩階段的提交
queuedWriteRequests：表示接收到的寫請求，沒有進行兩階段的提交
committedRequests：表示可以提交的請求，在兩階段驗證過半之後進行會在本地進行committe操作，便添加到這個隊列
commitIsWaiting：表示存在可以提交的請求（committedRequests是否有值，有true）
pendingRequests：是一個map集合，表示每個客戶端sessionId的請求
Leader類參數：
outstandingProposals：表示記錄提議的請求的隊列，符合過半機制之後會移除
toBeApplied：表示記錄待生效的請求，在FinalRequestProcessor移除
①、processRequest
org.apache.zookeeper.server.quorum.CommitProcessor#processRequest

首先判斷是否需要兩階段提交。如果需要則會添加到queuedWriteRequests隊列
org.apache.zookeeper.server.quorum.CommitProcessor#needCommit
如果是更改操作則返回true

d、然後，再看一下這個while的退出條件。
①、從queuedRequests取出的是空
②、如果queuedRequests數據不為空，那麼requestsToProcess是大於0的。這時只有maxReadBatchSize < 0或readsProcessed <= maxReadBatchSize才能退出。
maxReadBatchSize < 0表示默認是-1，如果配置了這個參數當連續讀了readsProcessed時，也會退出。
③、pendingRequests和committedRequests不為空
e、commitIsWaiting有待提交的

org.apache.zookeeper.server.quorum.Leader.ToBeAppliedRequestProcessor#processRequest
刪除toBeApplied

其中標綠色的FollowerRequestProcessor、CommitProcessor、SyncRequestProcessor都繼承了ZooKeeperCriticalThread是一個線程。
org.apache.zookeeper.server.quorum.FollowerZooKeeperServer#setupRequestProcessors

開了兩條鏈：
FollowerRequestProcessor(firstProcessor)---->CommitProcessor----->FinalRequestProcessor
SyncRequestProcessor---->SendAckRequestProcessor

org.apache.zookeeper.server.quorum.FollowerRequestProcessor#processRequest
請求添加到queuedRequests隊列

FollowerRequestProcessor是一個線程，會從queuedRequests獲取請求
org.apache.zookeeper.server.quorum.FollowerRequestProcessor#run

createSession和closeSession也會轉發給lead節點處理

org.apache.zookeeper.server.quorum.SendAckRequestProcessor#processRequest
在用SendAckRequestProcessor處理之前會先調用SyncRequestProcessor進行持久化處理，由於與單機或lead處理相同就不單獨列出來了。
向領導者發送確認ack包

org.apache.zookeeper.server.quorum.Learner#writePacket

在經過FollowerRequestProcessor處理後，lead端會得到一個Request的請求
org.apache.zookeeper.server.quorum.LearnerHandler#run

org.apache.zookeeper.server.quorum.Leader#submitLearnerRequest

在連接Follower節點的客戶端發送更改命令請求會轉發到leader節點的prepRequestProcessor進行處理

1、run
org.apache.zookeeper.server.quorum.QuorumPeer#run

2、followLeader
org.apache.zookeeper.server.quorum.Follower#followLeader
不斷讀取從lead端的數據包

org.apache.zookeeper.server.quorum.FollowerZooKeeperServer#logRequest

其中標綠色的ObserverRequestProcessor、CommitProcessor、SyncRequestProcessor都繼承了ZooKeeperCriticalThread是一個線程。
org.apache.zookeeper.server.quorum.ObserverZooKeeperServer#setupRequestProcessors

也是開了兩條鏈：
ObserverRequestProcessor(firstProcessor)---->CommitProcessor----->FinalRequestProcessor
SyncRequestProcessor---->null
observer節點不參與兩階段提交，所以同步SyncRequestProcessor之後沒有ACK確認提交。這樣既提高了讀效率，又對寫效率沒有影響。請求處理鏈與leader、follower的功能相同不再累述。

zookeeper集群的兩階段提交，是在寫操作的情況下發生的。2PC的整體實現邏輯是在RequestProcessor請求處理鏈處理的。只有在接受到的ACK超過一半才會進行提交，提交的實現邏輯是在CommitProcessor中實現的，CommitProcessor處理器中裡面涉及多種集合、隊列等參數(需要首先了解這些參數意義，然後再讀CommitProcessor源碼)。

❸ 資料庫事務原子性，一致性是怎樣實現的

這個問題的有趣之處，不在於問題本身（「原子性、一致性的實現機制是什麼」），而在於回答者的分歧反映出來的另外一個問題：原子性和一致性之間的關系是什麼？

我特別關注了@我練功發自真心
的答案，他正確地指出了，為了保證事務操作的原子性，必須實現基於日誌的REDO/UNDO機制。但這個答案仍然是不完整的，因為原子性並不能夠完全保證一致性。

按照我個人的理解，在事務處理的ACID屬性中，一致性是最基本的屬性，其它的三個屬性都為了保證一致性而存在的。

首先回顧一下一致性的定義。所謂一致性，指的是數據處於一種有意義的狀態，這種狀態是語義上的而不是語法上的。最常見的例子是轉帳。例如從帳戶A轉一筆錢到帳戶B上，如果帳戶A上的錢減少了，而帳戶B上的錢卻沒有增加，那麼我們認為此時數據處於不一致的狀態。

在
資料庫實現的場景中，一致性可以分為資料庫外部的一致性和資料庫內部的一致性。前者由外部應用的編碼來保證，即某個應用在執行轉帳的資料庫操作時，必須在
同一個事務內部調用對帳戶A和帳戶B的操作。如果在這個層次出現錯誤，這不是資料庫本身能夠解決的，也不屬於我們需要討論的范圍。後者由資料庫來保證，即
在同一個事務內部的一組操作必須全部執行成功（或者全部失敗）。這就是事務處理的原子性。

為了實現原子性，需要通過日誌：將所有對
數據的更新操作都寫入日誌，如果一個事務中的一部分操作已經成功，但以後的操作，由於斷電/系統崩潰/其它的軟硬體錯誤而無法繼續，則通過回溯日誌，將已
經執行成功的操作撤銷，從而達到「全部操作失敗」的目的。最常見的場景是，資料庫系統崩潰後重啟，此時資料庫處於不一致的狀態，必須先執行一個crash
recovery的過程：讀取日誌進行REDO（重演將所有已經執行成功但尚未寫入到磁碟的操作，保證持久性），再對所有到崩潰時尚未成功提交的事務進行
UNDO（撤銷所有執行了一部分但尚未提交的操作，保證原子性）。crash
recovery結束後，資料庫恢復到一致性狀態，可以繼續被使用。

日誌的管理和重演是資料庫實現中最復雜的部分之一。如果涉及到並行處理和分布式系統（日誌的復制和重演是資料庫高可用性的基礎），會比上述場景還要復雜得多。

但是，原子性並不能完全保證一致性。在多個事務並行進行的情況下，即使保證了每一個事務的原子性，仍然可能導致數據不一致的結果。例如，事務1需要將100元轉入帳號A：先讀取帳號A的值，然後在這個值上加上100。但是，在這兩個操作之間，另一個事務2修改了帳號A的值，為它增加了100元。那麼最後的結果應該是A增加了200元。但事實上，
事務1最終完成後，帳號A只增加了100元，因為事務2的修改結果被事務1覆蓋掉了。

為了保證並發情況下的一致性，引入了隔離性，即保證每一個事務能夠看到的數據總是一致的，就好象其它並發事務並不存在一樣。用術語來說，就是多個事務並發執行後的狀態，和它們串列執行後的狀態是等價的。怎樣實現隔離性，已經有很多人回答過了，原則上無非是兩種類型的鎖：

一
種是悲觀鎖，即當前事務將所有涉及操作的對象加鎖，操作完成後釋放給其它對象使用。為了盡可能提高性能，發明了各種粒度（資料庫級/表級/行級……）/各
種性質（共享鎖/排他鎖/共享意向鎖/排他意向鎖/共享排他意向鎖……）的鎖。為了解決死鎖問題，又發明了兩階段鎖協議/死鎖檢測等一系列的技術。

一種是樂觀鎖，即不同的事務可以同時看到同一對象（一般是數據行）的不同歷史版本。如果有兩個事務同時修改了同一數據行，那麼在較晚的事務提交時進行沖突
檢測。實現也有兩種，一種是通過日誌UNDO的方式來獲取數據行的歷史版本，一種是簡單地在內存中保存同一數據行的多個歷史版本，通過時間戳來區分。

鎖也是資料庫實現中最復雜的部分之一。同樣，如果涉及到分布式系統（分布式鎖和兩階段提交是分布式事務的基礎），會比上述場景還要復雜得多。

@
我練功發自真心
提到，其他回答者說的其實是操作系統對atomic的理解，即並發控制。我不能完全同意這一點。資料庫有自己的並發控制和鎖問題，雖然在原理上和操作系統
中的概念非常類似，但是並不是同一個層次上的東西。資料庫中的鎖，在粒度/類型/實現方式上和操作系統中的鎖都完全不同。操作系統中的鎖，在資料庫實現中
稱為latch（一般譯為閂）。其他回答者回答的其實是「在並行事務處理的情況下怎樣保證數據的一致性」。

最後回到原來的問題（「原子性、一致性的實現機制是什麼」）。我手頭有本Database
System
Concepts（4ed，有點老了），在第15章的開頭簡明地介紹了ACID的概念及其關系。如果你想從概念上了解其實現，把這本書的相關章節讀完應該能大概明白。如果你想從實踐上了解其實現，可以找innodb這樣的開源引擎的源代碼來讀。不過，即使是一個非常粗糙的開源實現（不考慮太復雜的並行處理，不考慮分布式系統，不考慮針對操作系統和硬體的優化之類），要基本搞明白恐怕也不是一兩年的事。

❹ equals()和==到底有什麼區別啊

1、功能不同

"=="是判斷兩個變數或實例是不是指向同一個內存空間。

"equals"是判斷兩個變數或實例所指向的內存空間的值是不是相同。

2、定義不同

"equals"在java中是一個方法。

"=="在JAVA中只是一個運算符合。

例子:

Student student1 = new Student();

Student student2 = new Student();

System.out.println(student1.equals(student2));

System.out.println(student1 == student2);

3、運行速度不同

"=="比"equals"運行速度快，因為"=="只是比較引用。

"equals"比"=="運行速度要慢。

(4)源碼一致性擴展閱讀

equals()方法特點：

1、自反性：x.equals（x）返回true；

2、對稱性：若x.equals（y）為true，則y.equals（x）亦為true；

3、傳遞性：若x.equals（y）為true且y.equals（z）也為true，則x.equals（z）亦為true；

4、一致性：x.equals（y）的第一次調用為true，那麼x.equals（y）的第二次、第三次、第n次調用也均為true，前提條件是沒有修改x也沒有修改y；

5、對於非空引用x，x.equals（null）永遠返回為false。

❺ Eureka源碼分析（六） TimedSupervisorTask

之前我們分析了eureka的注冊服務實例信息，下面我們來分析下eureka的續租。當一個租約到期後，就有兩種情況，一種是過期，EurekaServer將下線過期的節點，一種是續租，當EurekaServer檢測到節點還能正常通信時，將執行續租的操作。我們知道，檢測節點狀態是ScheledExecutorService的schele方法，那麼定時檢測節點狀態的任務是怎麼執行的呢，答案就是TimedSupervisorTask。我們先來看下TimedSupervisorTask都有哪些屬性

TimedSupervisorTask 執行時，提交 task 到 executor 執行任務。
當 task 執行正常，TimedSupervisorTask 再次提交自己到scheler 延遲 timeoutMillis 執行。
當 task 執行超時，重新計算延遲時間( 不允許超過 maxDelay )，再次提交自己到scheler 延遲執行。
再來看下run方法的具體實現

續租應用實例信息的請求，映射 InstanceResource的renewLease方法，看下具體的實現

調用 AbstractInstanceRegistry的renew方法，續租應用實例信息，看下具體的實現

調用 Lease的renew方法，設置租約最後更新時間( 續租 )，看下具體的實現

整個過程修改的租約的過期時間，即使並發請求，也不會對數據的一致性產生不一致的影響，因此不需要加鎖。
Eureka續租的操作就完成了。
TimedSupervisorTask的分析就到這里了。

❻ api中怎麼看equals 和string的源碼

在你的%JAVA_HOME%\src.zip裡面，你把那裡面的源文件解壓一下，就可以看到.java文件了

❼ 寫代碼怎麼交源文件的作業

寫代碼交源文件的作業操作方法：
首先統一源代碼路徑:
1.分支:由存檔的主幹創建，操作員研究和開發項目以實現新的功能需求。
2.主幹:合並物理測試分支，操作員為質控測試；用於環境測試、功能測試、預發布環境和生產環境。
3.標簽:預發布環境驗收完成後，發布生產環境並存檔版本，使用操作人員的品控測試記錄生產環境的穩定版本，方便回滾主操作。
其次，通過APP開發源碼版本提交記錄映射服務版本號，以保證不同服務版本的源代碼的一致性。
1.確定基線主幹:項目演示特性開發穩定版本。
2.拉分支來自穩定的主幹，用於實現新功能。
3.合並主幹由測試分支合並，用於功能測試、測試環境、預發布環境和生產環境的運行。合並中繼線的前提是提供測試郵件。測試郵件應該有以下六個元素:版本號、分支路徑、腳本路徑、項目名稱、功能邊界和部署手冊。

❽ Eurake源碼分析（十一） 增量獲取

下面我們來說一下eureka的增量獲取。
Applications.appsHashCode ，應用集合一致性哈希碼。

增量獲取注冊的應用集合( Applications ) 時，Eureka-Client 會獲取到：

Eureka-Server 近期變化( 注冊、下線 )的應用集合
Eureka-Server 應用集合一致性哈希碼
Eureka-Client 將變化的應用集合和本地緩存的應用集合進行合並後進行計算本地的應用集合一致性哈希碼。若兩個哈希碼相等，意味著增量獲取成功；若不相等，意味著增量獲取失敗，Eureka-Client 重新和 Eureka-Server 全量獲取應用集合。
計算公式
appsHashCode = status+count

使用每個應用實例狀態( status ) + 數量( count )拼接出一致性哈希碼。若數量為 0 ，該應用實例狀態不進行拼接。狀態以字元串大小排序。

舉個例子，8 個 UP ，0 個 DOWN ，則 appsHashCode = UP_8_ 。8 個 UP ，2 個 DOWN ，則 appsHashCode = DOWN_2_UP_8_ 。
看下Applications的getReconcileHashCode方法

調用 populateInstanceCountMap方法，計算每個應用實例狀態的數量，看下具體的實現

調用 getReconcileHashCode方法，計算 hashcode，看下具體的實現

調用 DiscoveryClient的getAndUpdateDelta方法，增量獲取注冊信息，並刷新本地緩存，看下具體的實現

調用 updateDelta方法，將變化的應用集合和本地緩存的應用集合進行合並，看下具體的實現

ApplicationsResource，處理所有應用的請求操作的 Resource ( Controller )。

接收增量獲取請求，映射 ApplicationsResource#getContainers() 方法。
AbstractInstanceRegistry.recentlyChangedQueue，最近租約變更記錄隊列。看下具體的實現

當應用實例注冊、下線、狀態變更時，創建最近租約變更記錄( RecentlyChangedItem ) 到隊列。

後台任務定時順序掃描隊列，當 lastUpdateTime 超過一定時長後進行移除。

配置 eureka.， 移除隊列里過期的租約變更記錄的定時任務執行頻率，單位：毫秒。默認值 ：30 * 1000 毫秒。
配置 eureka.retentionTimeInMSInDeltaQueue，租約變更記錄過期時長，單位：毫秒。默認值 ： 3 * 60 * 1000 毫秒。
在 generatePayload方法里，調用 AbstractInstanceRegistry的getApplicationDeltas方法，獲取近期變化的應用集合，看下具體的實現

eureka的增量獲取過程就完成了。

❾ Elasticsearch源碼分析-索引分析(一)

首先，我們來看一個索引請求：

這個請求的主要作用是向item索引中添加一個索引文檔，文檔信息：
文檔 id: 28589790
欄位id: 28589790
欄位text: 這是一個索引文本
如果索引中已經包含id為28589790的索引，elasticsearch將會使用這條數據進行覆蓋

elasticsearch使用HttpRequestHandler.messageReceived()方法接受用戶請求，然後調用dispatchRequest()方法對請求進行轉發。
當請求跳轉到RestController時，會調用getHandler()方法根據請求的Path獲取對應的handler，由上文可以看出 item/show/28589790 會匹配到RestIndexAction

handler.handleRequest()方法最終會調用RestIndexAction.handleRequest()方法對索引參數進行解析，創建索引請求對象indexRequest，然後調用client.index()開始創建索引

在索引請求中，支持下列參數：
routing: 路由信息，具有相同路由信息的文檔存儲在同一分片上
parent: 文檔的parent id， 如果未設置路由，則會自動將其設置為路由
timestamp: 文檔產生的時間戳
ttl: 過期時間
timeout: 超時時間
refresh: 此索引操作之後是否執行刷新，從而使文檔可被搜索，默認為false
version: 文檔的版本號
version_type: 版本類型，默認internal，支持internal、external、external_gt、external_gte和force
op_type: 索引操作類型，支持create和index
replication: 副本類型，支持async、sync和default
consistency: 一致性，支持one、quorum、all和default
請求的content即索引的source，文檔內容
在封裝完索引請求後，就要調用 client.index() 執行索引

在index()方法中，使用的Action是IndexAction.INSTANCE

這個action在ActionMole中被TransportIndexAction注冊

因此在NodeClient的execute()方法中根據action獲取到的transport action為TransportIndexAction

由於TransportIndexAction繼承了TransportAction，因此調用過程為NodeClient.execute() -> TransportAction.execute() -> TransportIndexAction.doExecute()
索引的大體流程為：先判斷是否需要創建索引，如果是則先創建索引，然後寫入文檔數據，否則直接寫入文檔數據

elasticsearch主要使用AutoCreateIndex.shouldAutoCreate()方法來判斷是否需要創建索引

其中參數和globallyDisabled的含義：
action.auto_create_index: elasticsearch配置文件的的配置項，表示是否允許創建索引
needToCheck: 是否需要檢查能否創建索引，只有當action.auto_create_index為false時不需要檢查，直接返回無法創建索引
globallyDisabled: 是否全局禁用創建索引，只有當action.auto_create_index為false時全局禁用創建索引，直接返回無法創建索引
如果當前集群中已經包含了要創建的索引，那麼也不需要創建索引。其他情況則根據action.auto_create_index配置的正則表達式來判斷
如果允許創建索引，則開始創建索引名的流程

首先創建 創建索引 的請求createIndexRequest，設置了4個參數，分別是索引名index、索引mapping、創建索引的原因cause和master節點超時時間masterNodeTimeout

然後開始調用createIndexAction.execute()方法創建索引名

從下面的類圖可以看出，TransportCreateIndexAction繼承了TransportMasterNodeOperation，調用過程即TransportAction.execute()-> TransportMasterNodeOperation.doExecute()方法來完成操作

在TransportMasterNodeOperation中主要是保證操作在master節點上執行

這個操作主要保證了兩點：
（1）如果當前節點不是master，則將請求發送到master節點執行masterOperation()方法
（2）如果當前集群block了，則等待集群狀態更新，然後重新執行完整的innerExecute()方法

然後進入到TransportCreateIndexAction.masterOperation()方法中，創建對象，用來創建索引時更新集群狀態信息的請求，其中settings和mappings及aliases默認為空集合

然後調用MetaDataCreateIndexService的createIndex()方法，如果能獲取到鎖信息則直接執行重載的createIndex()方法，否則交給線程池去執行

在重載從createIndex()方法中，通過提交一個更新集群狀態的任務來實現創建索引的具體邏輯

提交StateUpdateTask任務時，會創建一個UpdateTask對象，然後執行其run()方法，即MetaDataCreateIndexService中創建的AckedClusterStateUpdateTask匿名對象

在UpdateTask的run()方法中，會調用ClusterStateUpdateTask.execute()方法獲取新的集群狀態，

在完成索引創建完成後，集群狀態信息會發生變化，elasticsearch會將這個變化發布到其他節點，以維持集群統一的狀態信息