在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
背景 数据库的事务是原子操作,要么成功,要么失败。但是实际上在客户端的视角,可能有第三种状态:unknown状态。 当客户端提交事务结束(rollback , commit , prepare xact , rollback pxact , commit pxact)的请求后,数据库收到请求,数据库可能执行失败,也可能执行成功,不管怎样都要写对于的WAL日志,还有CLOG,然后数据库要将执行结果返回给客户端ACK。 这里存在几种可能,导致客户端不知道执行到底怎么样了? 收到客户端请求后,数据库没有返回任何ACK给客户端,客户端对这次请求很茫然,它只能人为数据库处于UNKNOWN的状态。 UNKNOWN 事务的处理 unknown事务,就是客户端没有收到commit/rollback ACK的事务。不知道是成功还是失败。 多节点(quorum based sync replication)与单节点都可能出现UNKNOWN事务,效果、形态一致。 如何处理unknown事务呢? unknown事务分为以下几种情况. rollback , commit , prepare xact , rollback pxact , commit pxact 几种情况的unknown处理方法: 1、两阶段解决unknown状态问题 prepare 阶段unknown, 切换leader后,客户端通过pg_prepared_xacts视图检查prepare xact状态,如果没有prepare xact则说明失败了,那么整个事务重新发起即可。如果prepare xact存在,说明prepare xact成功了。 commit or rollback prepare xact阶段unknown, 切换后检查prepare xact状态,存在则重试commit or rollback prepare xact。不存在则说明已经成功(我们认为2PC是一定成功的),无须处理。 2、非两阶段事务,rollback unknown无须处理,rollback失败或成功对于客户端来说结果是一样的。因为不管怎样都会回滚掉,这是数据库原子性保障的。 3、非两阶段事务,commit unknown处理,极度严谨的场景,程序可以设计事务状态可回溯,例如: 事务开始时,记录事务号或唯一流水号,事务号在数据库中是一个唯一的流水,可以根据事务号查询它的状态,比如postgresql。 但是并不是所有数据库都有这种接口,比如非物理流式复制的数据库,则可以在事务中增加全局唯一流水号来查看事务是否提交。这里利用了事务的原子特性,既要么全成功要么全失败。可以举个使用例子。 使用业务流水实现事务状态判断的例子: begin; |
请发表评论