银行核心系统、渠道类系统如何做到多中心数据多活，各中心数据一致性如何保证？

就金融行业来讲，以目前的业务规则和科技现状来讲，实现异地多活（多个中心数据实时同步）没有可能。问题的关键还是在于远距离数据传输质量和延时。
如果说到别的业务场景来讲，如果数据的要求可以容忍最终一致性要求，那么多活倒是可以在一定程度上实现，但不是绝对的微观IO的多活，只是从业务层面上感觉到的多活。

同城系统一般距离60KM左右，采用独立光纤，网络稳定，交易时延完全可以接受，所以在同城进行双活，可选择的方案很多。对于核心银行系统，各个层面均要保证没有单点，但清除单点不一定要同城，有些部件仅需要在不同机架上做HA。银行必须保证数据安全，所以数据库系统必须进行同城双活、异地灾备。主流数据库系统均提供了多种类型的方案供选择，其中，采用半同步方式的主从复制方式是一种比较经济、可靠的选择。数据库集群功能强大，甚至可以提供分布式事务一致性，但是并发数、吞吐量有限，需要按需选择。
分布式数据一致性有多种选择，最终一致性或是基于二阶段提交的数据一致性。二阶段算法很多系统均提供，但是选择需要考虑并发量、吞吐量，可以在最终一致性不宜使用的场景下使用。最终一致性是比较好的解决方案，一般借助异步消息机制实现，在网络良好、交易无剧烈波动的情况下，可以接近同步效果，客户体验很好，实现难度不高。但无论采用哪种一致性，交易本身应支持重入或补偿机制，不应仅仅依赖技术保证业务一致性，这是应用系统应该做的。

神码融创发布的新一代银行核心系统可以实现分布式部署，在同城双中心间链路质量、带宽有保障的前提下可以实现双中心多活模式，数据库层通过oracle extend RAC模式实现双活。

cap始终在其中作梗。 针对银行系统 强一致，高可用的情况，只能在数据分片或者同机房上进行考虑。俗称单元化，将用户按照地理分布进行数据部署。将数据分为三种，全局性，地域性，可漂移的。 全局的多为只读参数，所有库都保存；地域性的多为用户业务数据可以按照用户分布进行部署；可漂移的针对弱一致的同步策略，常为产品，配置等。

互联网广域网时延、多活数据库数据一致的确是件非常头痛的事，好在我们电力系统有自己的传输系统。