網友提問信息：
銀行核心業務系統最主要的技術特徵就是數據一致性，採用關係型集中式數據庫產品，故天然不用擔心數據一致性、事務響應時間的額外開銷、悲觀鎖、死鎖發現和死鎖解除。
但對OLTP分佈式數據庫而言，核心業務系統對應的就是分佈式事務一致性，在分佈式數據庫產品明確哪些產品可行、哪些廠商能成爲行業最後贏家之前，如何設計和實現分佈式事務一致性，各家銀行採用了許多不同的策略，從而產生了多個不同技術路線和技術流派，例如分佈式柔性事務、分佈式強一致性事務等等。
Amygo的解答如下：
OLTP分佈式數據庫 （或稱 分佈式事務數據庫） 必須要做到同 集中式數據庫 等同的 事務一致性、吞吐量應該更大、響應時間可控。 一個不支持分佈式事務強一致的數據庫產品 不能稱之爲 分佈式事務數據庫產品，剛好看到一份銀行核心系統轉賬業務場景性能測試的 普通一致 和 強一致 的 吞吐量、響應時間的對比，見文檔：
https://download.csdn.net/download/weixin_44994688/12262492
市場號稱能做交易或專注做交易產品的分佈式事務情況如下：
**1） 專注OLTP分佈式數據庫產品：**Oceanbase 、HotDB 做到了等同 集中式數據庫 的 事務一致性 和透明性，TDSQL、GoldenDB、DDM、GaussDB T依然是採用外接GTS服務或zookeeper的模式，屬於柔性事務
2) 專注HTAP多模數據庫產品： SequoiaDB 準確說不支持 、TiDB 還未等同集中式數據庫的 事務一致性 和透明性 ，另外響應時間 和吞吐量是大概是 螞蟻金服Oceanbase 和熱璞數據庫HotDB的 25%。
3)、OLTP分佈式數據庫廠商會走向兩極分化：
3.1）SequoiaDB 和 TiDB 追求多模數據庫路線，也即業務場景上支持75%的 OLTP 業務場景 和75%的OLAP 業務場景（注：交易響應時間不滿足高性能要求，分析計算能力不滿足大規模數據量計算），數據庫類型會完全融入 KV文檔類型類MongoDB語法，及兼容MySQL 語法、PostgreSQL語法；
3.2） Oceanbase 、HotDB 、 TDSQL、GoldenDB、DDM、GaussDB T 100%專注OLTP分佈式數據庫 方向，SQL語法及生態完全融入MySQL體系或PostgreSQL體系，及兼容Oracle數據庫語法。
OLTP分佈式事務數據庫的分佈式事務指標評判總結：
衡量一款分佈式事務數據庫產品的分佈式事務能力，要從：
（1） 業務代碼是否同集中式數據庫一樣的編碼處理邏輯 及數據庫連接地址配置
（2）數據一致性是否等同集中式數據庫的實時一致
（3）吞吐量能否水平擴展數十倍 集中式數據庫產品（或等同Oracle/DB2 跑中高檔小型機/AS400等的吞吐量）
（4）隱患核心系統業務每筆交易的響應時間是否可控在合理範圍之內（注：假定網絡時延足夠小，則至少確保銀行轉賬業務場景控制在 200毫秒以內/筆交易）
（5）分佈式事務中的鎖是否爲悲觀鎖
（6）分佈式事務中的死鎖能否自動發現和自動解除