双活不可避免的问题，双中心脑裂的保护机制如何考虑？

双活环境下的仲裁分很多的层次。例如文件系统复制，集群文件系统节点，数据库集群仲裁节点等等，包括网络，存储等。我现在见到的实际使用的防脑裂机制主要有两种： 一种是通过第三方仲裁，由第三方仲裁来决定哪一方存活。例如民生银行的对等双活环境，四川农信也在测试。还有一种是majority，也就是双中心投票者不一样多，也就是中心分主次，理论上主中心每次都会存活。这个在交行已经使用。

至于人工方式仲裁，那已经不是自动的了，不能算防止了脑裂。

但是在这样复杂的情况下（多层次），还是有可能出问题。应为层次比较多，有可能每一层选取了不同的中心存活，最终反而全盘宕掉。这是有这样的风险的。为了解决这个层次关系，一般考虑的方法是让底层先决定，然后基于这层的其他层次按照底层的结果来选择。这就是为什么在多个层次间，需要调整脑裂仲裁时间的原因。但还是不太保险。不知道还有什么更好的方式。

双中心脑裂肯定集群软件会通过仲裁来确定那个中心活着或者两个都死的。我所了解的有两种仲裁方式（majority这种请无视），第三方站点仲裁或人工仲裁的方式。第三方站点的好处就是可以自动仲裁，不过需要真的能找的到这个稳定的站点。人工仲裁方式就是仲裁需要花一定的时间，要等人到场执行命令，在找不到一个可靠的第三方站点时不失为一种办法。

这样的双活，只能保证生产和灾备的设备都利用起来了，而不能实现真正的双活，看来想实施理想中真正想要的双活，还是要具备第三站点。

基于目前业务双活主要是通过Oracle RAC实现的数据库双活，因此关于脑裂这里的保护机制一般都是通过仲裁方式，谁手快谁能活防止脑裂现象。

1：保护机制在双活中大多数厂商主要推荐第三站点仲裁，也就是说你需要建设第三个站点专门存储仲裁资源，做一个客观公正的第三方。

2：上述机制可以让故障发生时有自动进行切换过程，但是如果你没有第三方站点，或者第三方站点只能设置在生产站点（鸡肋）肿么办？答案很简单人工方式进行仲裁拉起操作例如（rsct）等等。