你是否曾经目睹过在餐厅里排长队等待打饭的场景, 而所谓的同步链, 其运作模式便类似于整个食堂的众多窗口都必须等待最后一盘菜肴烹饪完成之后, 才能够正式开启用餐这一过程, 那么关于异步区块链的情况则是每一个打菜窗口都具备独立进行出菜操作的能力, 谁家的菜品准备好了就允许谁先行离开, 这番话的意思其实非常直白, 也就是说将原本需要全局范围内的同步协作机制转化为局部的不断推进机制, 以此来使得延迟时间从以分钟为单位的水平大幅缩减至以秒为单位的水平, 与此同时系统所能够处理的吞吐量也直接获得了数倍的增长效果。
麻烦也接着就来了。窗口一多, 状态一致性的事儿就开始让人犯愁了。你这边的情况就是, 窗口A都已经给3号人送完饭了, 另一边呢, 窗口B还在那儿等着处理2号的事儿。两边的小账本对不上号怎么办?
现在的常规办法是这样, 硬往系统里塞个轻量的对账员进去。这个对账员会定时运作, 把各个窗口的零散账目全都汇总起来, 变成一本总账。这走的是最终一致性那一路子。这不是强一致性, 只要你能接受这种延迟或者误差, 才可以接着往上用。
具体该怎么落地? Hyperledger的一些子模块, 还有Solana的并行验证机制,其实都在往这个方向努力。
要是你真的要用的话, 不要只是翻着白皮书看那些画的大饼, 请务必把并发度和冲突率拉出来进行压力测试对比, 书面上的理论数据跟真实的生产环境差距是非常大的。你手头的项目目前到底卡在哪个地方了?
