分布式数据库核心难点之乐观锁适配问题探讨？

按照互联网的内存数据库方案能极大的提高性能，参考oceanbase的内存是最新的，增量刷新数据到盘里面。由于内存更新极快完全可以通过队列串行的方式修改一条记录。

乐观锁和悲观锁应用的场景不同，悲观锁更注重数据安全，更新数据前，读取数据时先利用数据库的锁机制将该数据行进行锁定，直到事务提交才释放，强调安全性，持有锁时间长，并发效率在某些场景效率不高；

乐观锁在最后提交的时候才去比较数据版本号，锁持有时间短，并发效率高，但是如果出现大量的数据冲突，会导致大量交易失败，所以乐观锁应用的前提应该是该业务场景下数据冲突的概率很小。

所以还是要结合业务场景和特点，在安全性保证的前提下，考虑使用乐观锁还是悲观锁，我们行大部分业务场景都是采用的悲观行锁，通过其他途径去提升并发效率，比如大事务改小事务，事务中锁尽量往后放等。

分布式数据库比集中式数据库有个全局一致性读的特殊性，现在分布式数据库通过增加全局时间戳组件实现了全局一致性读，能满足数据“强一致性”的要求。

乐观锁确实会出现成功率不高的问题，那就换悲观锁呗，那么带来了新的问题，多个会话同时更新一条数据，势必会带来争抢，tps也上不去，不如牺牲一点点性能，采用分而治之的思想，将账户按一定的规则拆分一下，成为多个子账户，会话按照一定的规则去访问子账户，这样就降低了争抢；不过...现在的分布式数据库还存在这个情况？

不知道“金融记账业务”是否指的是账务核心系统？我们对于账务核心没有做分布式数据库改造，对于记账来说，一致性放在第一位。
我们在选择哪些系统使用分布式数据库时，主要根据系统交易量是否具有明显波峰波谷特点、是否对可用性要求很高、数据增长是否非常快速这几个方面。分布式数据库的弹性扩缩容、高可用机制可以更好适配这些场景，提高行内资源使用率，保证重要时期系统稳定性。主要是面向网络交易的系统在用。你说的乐观锁无法做到强一致性的，所以这块是很难做到的，除非能牺牲少量一致性原则，否则。。。