DTS中某商业银行通过DTS构建私有云的两地三中心容灾架构的案例是什么？

重点分享一下这个案例。应中国人民银行的要求，所有的银行都需要提供“两地三中心”的容灾能力，“两地三中心”也成为了银行的标配。而在这之前，很多的银行曾出现过因为数据库版本升级、数据库运维以及其他原因造成服务不可用的问题，但是对于很多银行而言，是不敢轻易切换目的库的，因为这可能对于银行的业务造成很大的影响。银行不敢切换到目的库的本质原因就是他们无法保证目的库能够正常使用。而通过DTS这款产品能够确保目的库通过异地的两地三中心搭建出来一个备库，使其能够实时使用的并且有效。因为通过文件这种方式无法验证副本集是否是有效的，而DTS却是通过备库与第三方库进行有效性验证。

   上图中的两地是深圳和杭州，杭州有两个机房IDC A和B，深圳有IDC C，这样的情况下需要搭建两地——深圳和杭州，三中心——IDC A、B、C三个机房这样的异地多活的架构。使用下图的这种方案是比较轻松的，因为在同城内部是通过阿里云RDS实现运载的，对于异地的情况可以通过使用DTS实现深圳机房的数据运载，而且RTO或者RPO基本在1秒左右。除此之外，将服务切到杭州去之后还可以通过DTS切回到杭州。而成本也会降低一些，这是因为首先对于同城部分，阿里云RDS已经帮助用户实现了；对于异地的数据库而言，从节省成本的角度，可以自己搭建，当然也可以通过RDS来实现。最重要的一点就是目的端的数据库是实时的、有效的，并且能够提供可靠的在线服务。
   在上述案例中，如果IDC A出现了故障，这时候RDS会去做主备切换，但是服务却不会受影响。如果现在用户100%的流量都写入到杭州，应用端会自动切换到IDC B上来，保证整个服务是可用的。



   如果上述案例中的IDC A和B都挂掉了，也就说整个杭州的机房全部挂掉了，在这样的情况下该如何保证服务的可用性？实际上这时候需要通过查看DTS的界面来看其延时是多少，如果延时很小就可以做一些标准的切换流程，把应用的流量切换到深圳去。这个时候即便是整个杭州的机房全部挂掉了，也能够保证服务的正常运行。刚才提到的RPO是1秒，如果可以做到更好，就可以实现杭州节点中的数据在机房恢复之后还能找回来，只是可能某一秒的数据没有写过来，但是当杭州的节点恢复了，数据还是可以同步到深圳节点去的。