数据库同城双活实例该如何分布？

1：首先需求确认的是，你做同城双活的目的和效果。我个人通常会把双活分为对内和对外。用于区别互联网类型的访问就是业务，和对内受限于网络和设备的两种情况。好比银行的网银和ATM。
2：我个人接触的通常是对内的，受限于网络和设备一类的规划。这类情况下，通常都会需求在双中心的任一个中心发生故障时，另一个中心可以接管业务（哪怕慢点也要能用），在这样的情况下，就肯定会有资源的富余、再追求业务负载的平衡其实就不是一个很好的建议了。
2.1：如果刚刚这个情况也是你们的情况，那实际上我比较推荐的方式是针对业务去划分，比如要求时效性很高的联机交易，那应当是优先本地处理（写入情况针对你们的安全要求来衡量）；在优先本地处理的时产生的业务压力不平衡，可以通过改变非关键业务的方式进行一定的补偿，比如将数据备份、数据抽取等业务放到压力较小的一个中心。对内我的意见是不追求业务负载的平衡而且追求性能。
-
3：如果是对外的双活，那个做法就太多了。在要求强一致性的情景中，可以使用传统对内方式的双写双活实现，一致性要求不高的情况下（例如新建数据xx分钟后方能查询）的情况下，使用数据库中间件的分表/分库+数据总线/异步同步就可以做了，
3.1：在对外的情况下通常会基于GSLB一类的负载，通常追求多中心负载平衡来提高效率和降低成本，

如果是要做双活，当然是希望两边承载相同的业务和量，所以实例的分布是对等的。

可以考虑DB2 PureScale架构，同城异地双活都可以，实例是share的

做同城多节点数据库集群（如同城4节点oracle RAC）