金融企业应用分布式数据库全局强一致性与性能取舍，这方面问题如何考虑？

“分库分表”类型的分布式数据库一般采用强同步的方式实现写一致性，可用性较差，而原生分布式数据库一般采用Paxos/Raft等多节点同步一致性的技术，可用性较好。此外 “分库分表”类型的分布式数据库，应用在不知道数据的分片键的情况下，需要对所有主库发起SQL，导致性能较差；为提高系统性能，在操作数据时应用需要带上分片键，使得对应用的改造量很大。

是否启用强一致性，主要取决于业务架构。针对全局强一致是刚需，绝大部分业务都是需要的。只有当业务做过单元化改造，也做到局部的业务闭环下可考虑关闭全局一致，提升效率。

谢邀！本次回答是基于2022年国产数据库的发展阶段进行。对于金融行业，保证分布式数据库的强一致性是金融企业的首选。尤其对于银行业来说，哪怕不是核心系统，也不是什么重要系统，就是重要等级一般但是交易并发量高的系统。保证分布式数据库的强一致性，仍然是首选。至于性能方面的取舍，我不认为这是个问题。如果有问题的话，可能是某家银行引进的国产分布式数据库，还不够成熟稳定，或则用的不是国内头部几家大厂的分布式数据库产品。我们想想，MySQL开源社区版，很多商业银行用MySQL既能保障数据库的强一致性，也能支持一定的并发。如果花钱用了某款商用的国产分布式数据库（很可能是基于MySQL改进的），性能反而不如MySQL，或者没法保障事务的强一致性了。那我只能说：

1，别玩了，换头部厂家的国产分布式数据库吧。个别银行的核心系统的数据库已经完成了国产化改造，已经实现了超高并发的同时解决了强一致性的问题。这个问题的提出可能是客户用到了不够成熟的产品。
2，可能真的是这个系统的交易量太大，那就再等等，先别拿这个系统的数据库做国产化改造，再等等。先改造交易量小、并发低的系统，等两年再看看，那时候再根据国产数据库的发展情况对这个高并发系统开展国产化改造。

从分布式数据库的角度看，全局强一致性开启后会由专门的组件负责全局事务的管理，在数据查询时也需要判断数据的提交状态，对于存在大量分布式事务两阶段提交场景的应用，会有一定的查询性能的下降，大概会下降10%左右。从分布式数据库的发展来看，全局强一致性是必要的功能，起码把开启和关闭的权限交由客户决定，通过提高全局事务管理组件的性能和高可用，可以缓解性能下降的问题，对于事务较小的交易，例如单事务的平均SQL数量在100以内的交易，开启强一致性查询带来的性能损耗是完全可以接受的，而对于单事务的平均SQL数量在300以上的交易，那么开启后带来的性能损耗客户是有一点感知的，一个交易应用和数据库进行300次以上的交互，其中网络、数据库的耗时加起来，交易耗时可能达到500ms以上。当然这个问题也可以通过将事务改造成小事务来解决问题，当然也会给应用的改造带来一定负担。现阶段的情况来看，建议业务迁移分布式数据库时原则上是开启全局强一致性，通过优化抵消开启的损耗。