在金融领域，绝大多数的银行业应用设计都是基于传统单机关系型数据库，没有从整体应用架构考虑与第三代分布式数据库进行适配，尤其在银行核心系统应用第三代分布式数据库案例甚少，没有可复制的成功经验可以借鉴，从数据库自身机制和核心系统应用等方面，面临核心难点之乐观锁适配问题：
乐观锁在事前对表不会加锁，只在提交的时候比对提交版本号，不能保证每笔交易都能提交成功，在高并发的金融记账业务场景里，会造成大量的交易超时，出现用户短款现象，不能满足银行业务连续性和数据“强一致性”的要求。
大家针对这个核心难点问题有何解？有什么比较好的方法和经验吗？欢迎谈谈！
不知道“金融记账业务”是否指的是账务核心系统？我们对于账务核心没有做分布式数据库改造，对于记账来说，一致性放在第一位。 我们在选择哪些系统使用分布式数据库时，主要根据系统交易量是否具有明显波峰波谷特点、是否对可用性要求很高、数据增长是否非常快速这几个方面。分布式数据库的弹性扩缩容、高可用机制可以更好适配这些场景，提高行内资源使用率，保证重要时期系统稳定性。主要是面向网络交易的系统在用。你说的乐观锁无法做到强一致性的，所以这块是很难做到的，除非能牺牲少量一致性原则，否则。。。
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30
