对于单机房而言，只要参考Elastic Search 官方文档，搭建一个集群即可
原理类似分布式选举那一套，当一个master节点宕机时，剩下2个投票选出1个新老大，整个集群可以继续服务。对于核心系统，只部署单机房总归有点不保险，万一单机房故障就废了（比如：断电断网、或光缆被挖断）。那有同学肯定会想，多弄几个机房，把集群中的节点分散到多个机房不就好了么？
理论上讲，上面这种结构是可行的，但实际应用中，要考虑的因素会更多：
1、1个机房变3个机房，这成本就得翻好几倍了，回想一下mysql之类的解决方案，master-slave架构顶多放2个机房就可以了。
2、如果3个机房分属异地，比如：上海、广州、北京，三个城市间数据传输必然增加延时，要降低延时一般是拉专线，这样一方面成本还会继续增加，而且这么长距离传输，网络抖动是难免的，抖动期间，会增加选举"误切换"的概率。
3、3个节点之间不断的数据同步，会使三地机房间的网络流量增加，特别是某个节点挂了，重新恢复后，会在短时间内从master上同步数据，有流量风暴的隐患。
当然，官方有一个Cross Cluster Replication(CCR)的方案，架构示意图如下：
原理上讲，这其实也是把一个集群的节点分散部署在2个idc机房，另外，该方案并非免费午餐，官方的描述中，这是企业级的商业收费服务：
那么，普通屌丝公司有没有经济点的做法，即相对省钱，又能达到高可用呢？
圈内有一句名言：“没有什么是不能通过增加一个抽象层解决的，如果没有，就再加一层”。
我们把这个问题分解一下，无非就是“读”高可用，以及“写”高可用，先来看“读”:
假设有2个机房A、B，每个机房各部署1个ES集群，然后有一个java服务，按现在流行的做法，不管是spring cloud也好，还是dubbo也罢，一般也是多机房部署，同样部署在A、B二个机房。可以在service内部引入一个检测机制，用2个线程，分别定时检测A、B二个机房的ES集群健康情况（类似心跳检测），然后把检测结果，写入java service实例的内部全局变量中，假设ES集群状态正常为up，如果挂了为down。这样每个机房的java service就能知道2个ES集群是否可用，然后结合自身所在的机房，优先就近访问(这1点不难做到，服务注册时，可以在meta data元数据里主动标识自身所属的ip，根据ip地址段，就能区分出所在机房)。即：如果A,B二个机房的ES集群都是up健康状态，A机房的java service访问同机房的ES实例，避免了跨机房调用。
当发生故障时，这里有2种情况，一种是某个机房的ES集群down了，但是该机房的java service还是正常的，类似下面：
B机房的ES集群故障，这时候检查结果会标识B:down，B机房的java service此时知道本机房的ES集群有问题，退而求其次，访问另一侧机房的ES.
如果某一侧机房彻底挂了，比如：断电、断网。这时候，剩下一侧机房的java service仍然是优先访问同机房的ES，整个系统仍然可用。
解决了双机房ES"读"的问题，再来看“写”的问题，可能有同学说了，这还不简单，直接双写就行了吧，一份数据，向A、B机房的ES集群各写一份。听想来貌似可行，但是有一些细节问题 ： 1、双写并非原子操作，如果A机房的ES集群写成功了，B机房的ES集群没写成功，该怎么办？ 2、当B机房的ES挂了，双写不进去时，过一段时间又恢复后，故障期间的数据，B机房的ES集群怎么补进去？如果手动事后补数据，虽然可行，但是毕竟麻烦。
这里，可以引入一层MQ，类似下图这样：
向ES写入的数据，先发到MQ，然后java service再消费这个Topic，要点在于，分成2个Consumer Group来消费，2个group分别对应于2侧的ES，即A-Group消费的Message，写入A机房的ES集群，B-Group消费的Message，写入B机房的ES集群。写入ES成功后，才Ack确认消费成功。由于2个group的消费是各自独立的(各自有各自的offset)。
当1侧ES down时，写入不成功，该Group的Message就不会Ack成功，一直压积着(而另1侧的group则不受影响)，等ES恢复时，会继续消费，把故障期间的数据，自动补进去。这样就免去了事后手动补数据的麻烦。
当然，这个方案的提前是MQ本身是高可用的，不过这个不难做到，已经有一些rocket mq双机房多活的案例，不在本文讨论范围，大家可以自行搜索。
参考文档：
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html
https://www.elastic.co/cn/blog/bi-directional-replication-with-elasticsearch-cross-cluster-replication-ccr
https://zhuanlan.zhihu.com/p/82702078
