区块链的事务问题
这个问题其实也就是典型的分布式事务问题,既然区块链属于分布式的范畴,所以区块链也存在事务问题。
这里我要以程序员的角度去分析这个问题:
在做与区块链交互的业务系统的时候,比如基于Nodejs的web3工具编写与 etherum以太坊只能合约交互,我们会经常使用ES6 Promise等异步机制与区块链交互,企图提高交互效率。这确实是很好的做法,而需要值得注意,非理性的使用会埋下很多BUG,而且这些BUG的出现时随机的,有时候会爆异常,有时候却不会。
这种不稳定的代码,你大可以断定有一定概率是因为非理智的使用异步请求造成的。
比如,你编写了一段业务逻辑,而且这段业务逻辑要求“事务完整性”(即,你这段代码,要么全部成功执行,要么全部实行失败或者执行回滚)。
而区块链按照CAP理论,满足了最终一致性和分区容错性,不具备可用性(每次请求都不会报错,但不保证是最新的)
所以,当你发起请求给区块链系统时,要么拿到最新数据,要么报错。
所以当你发起请求的时候,你如果报错了,你就得重试了,直到成功为止。
而我们刚刚说了,如果你的代码要求事务完整性,这个时候,如果这个事务执行到一半报错了,你要么就在报错的地方重试请求几次,直到成功,再不行就回滚,你之前的修改。
但不管怎么样,别让事务执行到一半,半死不活。因为薛定谔的猫