源码一致性

❶ 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会将这个变化发布到其他节点，以维持集群统一的状态信息