区块链的事务问题

区块链的事务问题

这个问题其实也就是典型的分布式事务问题，既然区块链属于分布式的范畴，所以区块链也存在事务问题。

这里我要以程序员的角度去分析这个问题：

在做与区块链交互的业务系统的时候，比如基于Nodejs的web3工具编写与 etherum以太坊只能合约交互，我们会经常使用ES6 Promise等异步机制与区块链交互，企图提高交互效率。这确实是很好的做法，而需要值得注意，非理性的使用会埋下很多BUG，而且这些BUG的出现时随机的，有时候会爆异常，有时候却不会。

这种不稳定的代码，你大可以断定有一定概率是因为非理智的使用异步请求造成的。

比如，你编写了一段业务逻辑，而且这段业务逻辑要求“事务完整性”（即，你这段代码，要么全部成功执行，要么全部实行失败或者执行回滚）。

而区块链按照CAP理论，满足了最终一致性和分区容错性，不具备可用性（每次请求都不会报错，但不保证是最新的）

所以，当你发起请求给区块链系统时，要么拿到最新数据，要么报错。

所以当你发起请求的时候，你如果报错了，你就得重试了，直到成功为止。

而我们刚刚说了，如果你的代码要求事务完整性，这个时候，如果这个事务执行到一半报错了，你要么就在报错的地方重试请求几次，直到成功，再不行就回滚，你之前的修改。

但不管怎么样，别让事务执行到一半，半死不活。因为薛定谔的猫