GoldenDB事务一致性处理机制

1、GoldenDB事务一致性处理机制介绍技术创新 变革未来AgendaGoldenDB 数据库架构GoldenDB 事务机制事务处理模块优化实践GoldenDB是安全可靠的金融级交易型分布式数据库2007201120142015201620172018EBASEEBASE-MEMDHSSGoldenDBGoldenDB 1.0GoldenDB 2.0GoldenDB 3.0GoldenDB 4.0分布式数据库 雏形启动研发金融级分布式数据库正式发布 并在银行商用多家银行商用投产 政企行业规模发货金融核心交易性能超过40000TPS大型银行核心业务 并网运行2002文件数据库内存数据库 百万套设备

2、商用 千万套单板商用17年厚积薄发100%代码掌控100+发明专利APP1数据节点集群1DB-MDB-SDB-MDB-S数据节点集群2DB-MDB-SDB-MDB-S数据节点集群nDB-MDB-S计算节点集群管理节 点DBProxy 1DBProxy 2APP2ODBC / JDBCODBC / JDBC客户端接入层全局事务 管理节点DBProxy nAPPNODBC/JDBCGoldenDB分布式数据库总体架构实时一致的 分布式事务控制同城异地灾备 一致的备份恢复线性横向扩展 联机数据重分布丰富的监控体系 完善的运维能力GoldenDB数据库满足金融核心的关键要求AgendaGoldenDB

3、 数据库架构GoldenDB 事务机制事务处理模块优化实践、单机数据库分布式数据库原子性：多条记录的多次操作要 么一起成功，要么一起失败。原子性：多个数据分片上的多次操作要么 一起成功，要么一起失败。隔离性：不同连接(处理线程或 进程)不会相互访问到未提交事 务的数据。隔离性：多个计算节点上的不同连接不会 相互访问到在多个数据分片内未提交事务 的数据。持久性：事务提交前必须先将日 志落盘，机器重启后不丢失数据持久性：事务提交前必须将日志在分片主。从节点都得到复制，主节点故障时从节点 上仍能找回数据。AICD单机数据库：保证事务在事务内(原子性-A)、事务间(隔离性-I)和故障时(持久性-D)

4、的一致性(C)。分布式数据库：将数据库事务的ACID理论延伸到分布式架构下。tableDB1(主)DB2(主)DB3(主)DB1(从)DB2(从)DB3(从)APP1APP2APP3DBProxy1DBProxy2DBProxy3DBbilnolgogtableAPP1事务理论的分布式延伸要实现分布式事务的实时一致性（保证ACID ），难点在哪？部分DB提交失败，如何保证全局事务的原子性(A)？并发访问时，每个事务都不知道其他事务的状态，如何保证事务之间的隔离性(I)？以转账交易为例: 交易前2个账户资金余额各100，事务T1从账户1转账50到账 户2;在事务T1提交期间，由于DB1和DB2提

5、交时间有空隙，若此时事务T2读取2个账户的余额，会发现余额之和是50+100=150。存在事务T1对账户1上扣钱成功，给账户2加钱失败的情况。账户1减50账户2加50账户1提交查询账户1和DB1DB2APP1APP2DBProxy账户1向账户2转账50元事务T1事务T2败账户2提交，但提交失额额账户2的余额 查询账户1余余额50查询账户2余余额100分布式事务的难点 参与者在投赞成票之前可以单方面取消事务； 参与者投票之后不能改变它的投票； 处于READY状态的参与者依赖于协调者的决 策，提交或取消事务； 协调者根据全局规则进行全局提交或者全局 取消； 参与者和协调者在某些状态会等待消息，需

6、要启动定时器进行监控；正常的提交流程，日志写入数量为2N+3，消息数为4N，其中N为参与节点的数量；通过2PC协议保障原子性对业务的侵入性较大，所有业务都要增加反向操作逻辑/增加额外中间件处理过程中数据存在短暂不一致或更新延后，原子性不能100%保障 节点级故障需要不断重试，如不断失败须人为干预才能解决事务单元事务开始查看A账户是否100A账户减100事务结束确认消息发送消息发送者发消息消息发送者事务单元事务开始B账户加100插入去重表事务结束超时不断重试消息集群主业务数据库业务活动管理器 活动日志启动业务活动 登记业务操作提交/回滚业务活动Try Confirm Cancel数据节点1Try

7、 Confirm Cancel数据节点2从 业 务从 业 务通过业务改造保障原子性A=100from binlog:A 50-100A给B转账50元A-50B+50A=50OkA=100B=100FailureB=150A=50Grobol RollbackB=100RollbackCommitto binlog:A 100-50基于乐观锁的分布式一阶段提交辅助自动补偿机制: 一阶段提交 自动补偿回滚优点： 应用层无需实现补偿逻辑。 失败回滚是少数情况，整体性能高于两阶段提交。GoldenDB事务原子性实现机制通过回 滚进行 事务补 偿定位遍历生成执行提升回 滚性能表定义 缓存预分析 并行查找

8、共享内存SQL格式反向 binlogkey值利 用已提交事务回滚实现和优化 写写冲突，处理不当导致 脏写 丢失回滚（T1W、T2W、T1A，基于被回滚的数据做了update） 写读冲突，处理不当导致 脏读（脏读、不可重复读、读偏序、幻读） 读写冲突，处理不当导致 脏写 丢失更新（T1R、T2W、T1W，T2W被覆盖） 写偏序，一种违反语义的异常（黑白球问题，发生于快照级别隔离）导致异常的原因是因为并发调度未等价于任意一种串行处理结果事务隔离性的各种异常引自论文A Critique of ANSI SQL Isolation Levels隔离级别及对应的现象 严格按照串行顺序执行voltdb、R

9、edis 运用SS2PL技术，加锁解决幻读MySQL、SQL Server、Informix 可串行化的快照隔离SSI，解决写偏序PostgreSQL、FoundationDB达到可串行化隔离级别的三种实现方式锁的数量开始结束事务持续时间增长收缩Eswaran等人已经证明：遵守2PL算法的 并发调度一定是可串行化的。2PL-Lock Point确定LockPoint比较困难commit时释放写锁S2PL-commit时释放读、写锁SS2PL通过2PL进行事务并发控制引入全局事务管理器（GTM：Global Transaction Manager）实现全局事务的隔离性，并协助实现全 局事务的原子

10、性。关键说明： GTM统一管理全局事务 GTID的生命周期就是全局事务的生命周期IDGTIDAcntA100250C1001200IDGTIDAcntB1002100D1001200oldA1001100newA100250oldB1001100newB1002150Table:AccountTable:AccountbinlogGTID10021003C 1002R 1002DB2DBProxyGTMA-50GTID:1002begin;update Account set Acnt = Acnt-50 where ID = A；update Account set Acnt = Acnt+

11、50 where ID = B；commit;select Acnt from Account where ID in(A, B);ReleaseAPP1 JDBC/ODBCAPP2 JDBC/ODBC12 Create3DB14binlog563？B+50 GTID:1002引入GTM进行事务并发控制SS2PL：事务提交的的时候才释放读锁和写锁GTM封锁：事务提交之前，所有的GTID相关的数据都不能被读取和修改活跃事务列表里的GTID，相当于写锁。-保障了写写和写读冲突下的数据一致性。通过对读操作显式加锁，达到严格的SS2PL效果。-保障了读写冲突下的数据一致性。与SS2PL的比较现象：DB

12、Proxy查询到的活跃事务列表永远是旧的；DBProxy基于活跃事务列表做 的判断永远都是不准确的。解决办法：将所有的可能性冲突都认为是冲突。在返回活跃事务列表中，增加Max_GITD，Proxy判断GTID大于Max_GITD， 也认为是存在冲突的。预锁机制写一致性处理满足条件的记录上无锁满足条件的记录上有锁GTID不活跃GTID活跃事务处理总结读一致性处理脏读读已提交有排它锁无排它锁GTID不活跃GTID活跃可重复读有排它锁无排它锁可序列化加共享锁无冲突加共享锁有冲突GTID不活跃GTID活跃GTID不活跃GTID活跃事务处理总结AgendaGoldenDB 数据库架构GoldenDB 事

13、务机制事务处理模块优化实践待优化流程：GTID申请/释放GTID列表查询待优化瓶颈点：GTM需要对GTID的变化实时落盘，一次写盘大概1s，理论上限100万 TPS，能否突破？Proxy和GTM之间的消息交互，对网络资源消耗过大，理论瓶颈1.25GB 带宽如何利用？优化方向减少交互次数，降低交互数据量GTMDBProxycreate GTIDcreate GTIDcreate GTIDcreate GTID create GTIDGTMDBProxycreate 5 GTIDsGTMDBProxyrelease GTID1GTMDBProxyrelease GTID14、10release G

14、TID2release GTID3release GTID4 release GTID10申请/释放GTID优化：Proxy批量请求GTMDBProxyquery GTID ListThread1Thread2 Thread3 Thread4 Thread5query GTID Listquery GTID Listquery GTID Listquery GTID ListGTMProxy子线程DBProxyThread1Thread2 Thread3 Thread4 Thread5query GTID Listquery GTID Listquery GTID Listquery GTID

15、 Listquery GTID Listquery GTID List查询GTID列表优化：Proxy进行组提交代理线程汇总sql线程的请求，使用一份活跃事务列表应答。当在途请求没有返回时，代理线程不会发送新的查询请求。DBProxy1GTMDBProxy1QUERY GTIDLISTGTMQUERY GTIDLISTDBProxy2QUERY GTIDLISTQUERY GTIDLISTQUERY GTIDLISTGTM子线程QUERY GTIDLISTDBProxy2QUERY GTIDLIST查询GTID列表优化：GTM进行组提交GTM使用同一份活跃事务列表应答不同Proxy发来的请求。

16、当子线程没有拼装完返回列表时，不会处理新的请求。Proxy上所有的请 求，都需要过0.5ms才会有响应。Proxy获取到的事 务列表都落后 GTM 0.25ms。Proxy上所有的请 求，在00.5ms 内会收到响应。Proxy获取到的事 务列表都落后 GTM 0.25ms。0.25msPGPG组提交优化后对预锁机制的影响自适应算法，精简请求：依据请求数、累计时间和当前负载情况，实时修改发送周期数据压缩：通过记录GTID起始值(8Byte)和偏移量位图(255Byte)，数据包大小降到1K以 内Work ThreadMem Thread收请求写增量日志写增量日志回响应收请求回响应Work ThreadMem Threa