asio::promise yyds

Posted on February 4, 2022

最近在写以太坊的巧克力浏览器(区块链浏览器)。因为区块链浏览器需要访问历史的块,因此需要节点以 archive 模式同步。

遂运行了一个 geth。 然而半个月过去了,才同步了四百万高度,而且这四百万高度的最后一百万花了80%的时间。 同步速度以肉眼可见的速度下降,ETA 变的越来越长。 从一个月慢慢的增长到6个月。

于是寻找更快的客户端。找到了 erigon。erigon 号称2天完成 archive 节点同步。 结果牛逼是吹大了啊。最后耗费了10天完成了同步。

geth 在同步的时候, rpc 是可用的,geth 同步到哪里, eth_getBlockNumber 返回的高度就是哪里。 因此在同步的时候,我也开始同步巧克力浏览器的数据了。

巧克力浏览器是通过 eth_getblockbynumber 和 eth_gettransactionreceipt 把所有的交易数据都存入自己的数据库实现的。虽然其实可以等用户浏览到那个块再通过 rpc 获取数据,但是这样轻模式就没有检索功能了。所以还是需要解析所有的交易存入自己的数据库。

最终放弃 geth 二改用 erigon 的时候,巧克力浏览器才同步到一百多万的高度,就被迫停止了。

因为 erigon 只有完成同步,才会更新 eth_getBlockNumber 返回的高度。他同步的方式是先下载所有的块,然后执行,让后更新state数据,然后更新 rpc 接口的数据,然后获取最新高度,然后把落下的全下载回来,然后执行,让后更新state数据,然后更新 rpc 接口的数据,然后获取最新高度,然后把落下的全下载回来,然后执行,让后更新state数据,然后更新 rpc 接口的数据,然后获取最新高度…… 直到最后每次批处理的块只有1个,就算同步彻底完成。 如果 eth_getBlockNumber 一直返回 0 高度,我的浏览器就没法同步了,于是只能等。

问题是,他第一次的批量的时候,就试图从 0 一直批量执行到 1401万高度。结果,执行了10天才批量执行完。这一等就是十天, 等到了除夕前一天啊。执行完毕后,就再次落后十万高度了,于是进入第二次批处理。因为我在机械盘上运行 erigon,因此 erigon 最后会永远落后几百到几千个高度,不过这个是后话,第一次批处理完成后,我的浏览器又可以开起来同步了

结果,我对巧克力浏览器的同步速度非常的不满了。

因为,按同步速度估算,可没法10天完成巧克力浏览器的同步。大约需要20天,而且 ETA 在增加!最后可能达到了三年之久。为啥我能提前知道eta在增加呢?因为我观察到,同步空快很快,同步内部有交易的块就慢下来了。早期空块多,但是后期基本都是满块。满块的同步速度低到令人发指的超过数秒!

经过研究发现,速度是慢在了 get_transactionreceipt 上。这个接口对未缓存的交易返回速度需要数百毫秒。第二次调用其实几个毫秒就返回了. 而巧克力浏览器访问的都是数年前的交易,都是属于 old data。因此每次调用它都要等待几百毫秒。 如果一个块里有个一百个交易,同步速度就惊人的 slow down 了。

如果把get_transactionreceipt的调用并发化呢?

大过年的,大家在看春晚,我却在敲代码。在改进巧克力浏览器的同步速度。完成批量同步,需要对原来的代码进行2个改进,第一个改进,是让原来的 jsonrpc 接口支持 pipelining,其次是实现 等待所有协程完成 的一个 asio 协程工具。虽然用在线程上此类的工具汗牛充栋,但是用在asio的协程上的工具可是 non-exist的。 有了这2个工具,只要把原来 for each transaction ; do get_transactioreceipt ; done 的代码,改成一次创建所有的协程去 get_transactioreceipt . 然后等待协程返回然后收集结果。 基本上就是 c++ 版的 asyncjs 里的并发 map 操作。

原来的 jsonrpc client,采取的做法是 async_write 后 async_read (当然是带 yield 的协程版),这样每次只能等待 rpc 返回后才能发起下一个 rpc 调用。 如果不改进 这个客户端类的代码,就只能被迫使用连接池才能并发调用 get_transactioreceipt 了。因此改进了这个 rpc 对象的代码, 可以在多个协程里并发的调用 jsonrpc.async_req(params, yield);

并发 get_transactioreceipt 的版本上线后,同步速度一下子就改进了!块里交易量的多寡,对同步速度的影响就小下来了。当然是不能指望它毫无影响的 :)

这样就过了一个愉快的除夕和新年。

那么,代码就从

for all tx
    get_transactioreceipt ...
save_block

变成了

for for all tx
    asio::spawn(  get_transactioreceipt ... ) # 开一堆协程
wait all corotines
save_block

同步了几天,高度到了四百万了,按这个速度,10天即可完成同步。考虑到后期满块增加,也不会超过20天吧。看来三月份就可以满血上线了。

然而,到了立春前天一看日志,情况变不对劲了。速度又慢下来了。

原来是数据库操作慢下来了!原先空快多,交易量少。同步了三百万高度,交易量都不足千万。 但是到四百多万高度,交易量已经膨胀到超过一个亿了。

我的小 nas 哪里受得了这么大的表啊。数据库爆表了。马上花了数个小时的时间,做了分表。保存一个block内容的时间才从数百毫秒重新下降到20毫秒上下。 但是显然和初期的5毫秒上下保存有差距。

显然,如果把数据库的保存操作异步化,就可以提升速度。

这个虽然很简单,只要把保存这个操作放到单独的协程里进行即可。

但是,问题出在我的同步逻辑上。因为 jsonrpc 会丢失链接(手动重启 erigon 或者 erigon crash ),数据库也会挂(手贱和其他问题) 如果异步了,就不容易处理在挂掉的点上重新执行一遍这个逻辑。

这个时候,我很怀念 nodejs 的 promise/await , 如果有 promise 就好了,我的代码可以改成这样。

// NOTE rpc_get_block_data 还是并发的 get_transactionreceipt 哈
[fetch_ok, data] = await rpc_get_block_data(sync_height)

for (; sync_height < await rpc.get_blockheight();)
{
    next_block_data_promise =  rpc_get_block_data(sync_height + 1); // 马上获取下一个块, 后台获取,不等待结果
    if (fetch_ok)
    {
        save_ok = await save_to_db(data);
        if (save_ok)
        {
            sync_height++;
            [fetch_ok, data] = await next_block_data_promise; // 等待异步完成结果
       }
    }
    else
        [fetch_ok, data] = await rpc_get_block_data(sync_height); // 重获取一次
}

这样,如果 db 保存失败,sync_height 就不会增加,并且重新获取。 这样避免同步的过程中出现漏同步,出现空洞高度。这种写法还避免了完全异步fetch和save模式下的同步协作问题。大大简化了代码。

研究了一整天,最后发现了 asio 早已提供了 promise/await!

下面进入 boost::asio::experimental::use_promise 的世界!

上面这个代码,用 asio 的方式,写法就是这样

// NOTE rpc_get_block_data 还是并发的 get_transactionreceipt 哈
[fetch_ok, data] = rpc_get_block_data(sync_height, yield); // yield 说明上下文是在 asio::spawn 开启的协程里

for (; sync_height < rpc.get_blockheight(yield);)
{
    // 马上获取下一个块, 后台获取,不等待结果, 注意这里的 use_promise 替代了 yield
    next_block_data_promise =  rpc_get_block_data(sync_height + 1, asio::experimental::use_promise); 
    if (fetch_ok)
    {
        save_ok = save_to_db(data, yield);
        if (save_ok)
        {
            sync_height++;
            [fetch_ok, data] = next_block_data_promise.async_wait(yield); // 等待异步完成结果 这里的 wait 用了 yield
       }
    }
    else
        [fetch_ok, data] = rpc_get_block_data(sync_height, yield); // 重获取一次, 不用 promise 了
}

当然,自己的 rpc_get_block_data 也要经过修改,实现支持 yield/use_promise 双操作。 括弧 asio 自己的IO对象其实都支持 回调/yield/use_promise 三操作的。

promise/await 永远的神!

PS: 我运行在家nas上的巧克力浏览器,虽然还在同步,但是可以使用了 geth.home.microcai.org:3586

当然,因为是家里的 nas,so 只能用 ipv6 访问。不开放 ipv4 访问,免得麻烦。

稳定性不保证哈!随时调试。

Comments
blog comments powered by Disqus