从分布式事务到跨链

陆续读了一遍周志明老师的《凤凰架构》。读到分布式事务那章，我想起了早年的一次面试经历。

我自己本身是自学编程，然后捣鼓各种网站服务的野路子出身。有一次换工作，投了大厂的一个职位，得到了面试机会。

记得当时面试官问了我一个某种业务场景下如何保证数据的一致性的问题。说实话我自己原来的经验都是小网站小服务，基本没考虑过这种问题，数据不一致了？那就修呗。但我不敢这样给面试官回答呀，面试官问的是要如何保证数据的一致性，我这个保证不了。

于是我按照我零零散散看的一些书里的概念，什么事务，分布式事务扯了一通。最后面试官面露失望，告诉我这个在互联网场景里不可行，说我没有大型互联网服务的经验，不太合适。

然后我谦虚的问了一句，那应该用什么办法？面试官说互联网还是要追求效率，我们只要保证“最终一致性（Eventual Consistency）“就行了。我又追问一句，比如怎么做呢？面试官说比如数据不一致了可以触发个后台服务修。我内心。。。也只怪自己读书少，没学会这个词。

摸爬滚打互联网，云服务里十多年，然后我又捣鼓起了区块链。那天在一个跨链的技术讨论会上，我还说通用的跨链方案，实际上非常像分布式事务的解决方案。

如果把区块链看作一个分布式数据库，跨链就是要保证在一个数据库里进行某项操作后，在另外一个数据库中执行另外一个操作必然成功。如果是纯粹的 Token 场景，一个链上 lock 某种 Token，在另外一个链上 mint 出来，大概率不会失败。但如果涉及复杂的操作，就很难保证。

而现在大多数的通用跨链方案，基本都做了一个假设，跨链的应用需要保证，在第一个链上进行一项操作后，要在第二个链上进行的后续操作必须保证成功。但显然这个假设过于强烈。

如果按照分布式事务的思路来设计跨链。比如 SAGA 事务的思路是每个操作都需要设计一个补偿操作，一旦事物执行失败，则需要通过补偿操作来进行补偿。这个思路其实可以在跨链方案中借鉴，并且也足够通用，可以设计出对应用开发者友好的接口。

当然，跨链方案另外的难度在于两个链之间的证明，这个属于另外一个话题了。但分布式系统的道理是共通的。

周老师这本书属于那种百科全书式书籍，几乎涉及了分布式系统架构的所有主要方面。这样的书很容易写成辞典式的书籍，读起来没有味道，但周老师这本书却非常耐读，文字风格我也很喜欢，每一章都能从理论讲到实践，既可以引起思考，也可以指导实践，非常推荐。前面用“几乎”是因为这本书中主要少了区块链相关的内容，期待周老师在新版本中加入区块链的内容。