ES异地双活方案

对于单机房而言,只要参考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

posted @ 2021-03-28 21:05  菩提树下的杨过  阅读(106)  评论(0编辑  收藏