DTeam 技术日志

Doer、Delivery、Dream

小议以太坊应用状态同步

胡键 Posted at — Jan 10, 2022 阅读

除非业务逻辑非常简单单一,典型的以太坊应用一般都绕不开状态同步的问题。这里所说的状态指的是“交易状态”,所谓状态同步即指:将链上交易状态同步到业务数据库中。

为什么要做状态同步?

这个问题的答案很直接,无外乎两点:

有时,你会看到有些文章和书籍上提到:indexing 或 caching,其本质都是交易状态同步。

另外请注意:本文所指的状态同步都是指后端而言,前端状态同步要简单很多,各位可参见我的这篇文章

同步哪些数据?

用一句话回答就是:it depends。但并非没有章法可循,通常的步骤:

按以上三步走完,哪些数据要同步自然呼之欲出。

这里列出一些参考,主要无外乎以下几类:

在进入下一节之前,再啰嗦两句:

状态同步模式

状态同步模式的掌握离不开必要的基础知识,如果你对于 ethers.js 还不熟悉,那就可以就此止步,先去看看我的这两篇文章:

有同学可能会奇怪:为何不借助 the graph 的力量?很简单:

模式 1:Event Listener

这个模式的特点是:前端和后端没有任何通信,完全依赖以太坊的事件机制。两方的职责:

适用场合:

优点:

缺点:

模式 2:Tx Checker

与之相反,此模式要求前后端精确配合。整个交互可复杂可简单,毕竟涉及到两阶段提交的问题。简单的说,这里双方职责:

适用场合:

优点:

缺点:

模式 3:Log Watcher

此模式一般和前两个模式联合使用,通常作为一种补救措施。并且,它还有一个附加的好处:在适用于模式 1 的场景之下时,它客观上起到了数据库恢复器的作用。

它的参与方只有一个:后端,其职责就一个:查询日志,处理日志,修正数据库的不一致。

在实际使用时,它有两个阶段:启动阶段和运行阶段。这两个阶段请采用不同的查询日志的方式:

对于数据库熟悉的同学应该敏感地发现这个策略跟数据库的备份策略很像:全量备份和增量备份的结合。

总结

以上虽然交互双方是以前端和后端进行的说明,但“前端”换作另一个词或许更合适:交易发起方。因为 tx 未必只能前端发起。如,对于后端承担交易费用的场景,这个交易发起方则为后端。

但这个小的的变动并不影响以上模式的描述,在此只是提醒各位注意。

基本上,采用本文介绍的三种模式,就可以很容易的构建自己的状态同步基础设施。并且,同样的思路亦可应用到其他情形。

最后,广告时间:构建以上模式,离不开对于 ethers 这类工具的熟练掌握。小弟拙作则以大量的实际示例可帮助初学者快速迈过学习门槛:


友情链接


相关文章