这几年以来, 我们一直在从事链上数据服务的相关工作, 在这个过程里, httpx几乎已经成为了后端在调用区块链节点时的标准配置选择, 相比于传统的requests它具备原生的异步支持这个特点, 所以在进行高并发的区块数据拉取任务以及批量验证交易签名等操作的时候显示出非常明显的优势方面, 然而一旦真正落实到具体的项目开发实践中去的话, 那么在相关的配置细节上面所存在的一些问题和陷阱也是不在少数。
httpx区块链怎么调节点
接以太坊JSON-RPC最直接的方式：用async AsyncClient发POST到节点/geth端点，request头带Content-Type: application/json，body写method和params字段。
我通常的做法是封装上一层壳, 然后把nonce的管理、gas的估算以及区块标签的解析, 这些工作内容都提成独立的方法, 这样业务层只需要通过一行await代码就可以搞定所有的逻辑处理任务。
在处理小节点和本地的Anvil响应速度很快, 但是在主网全节点在高峰时段偶尔会卡顿。将超时阈值设置为15秒会比httpx默认的5秒更加稳定。
同时配置了使用指数退避的方式进行重试, 其中间隔时间分别是1秒、2秒和4秒, 并且最多进行3次重试。这种设置基本上可以应对节点端出现的瞬时抖动情况, 所以不需要在业务层面再额外编写补偿逻辑。
httpx区块链请求怎么优化
在处理高并发场景的时候, 我们千万千万不要为了每一个请求而去新建一个client。相反地, 我们应该去使用AsyncClient来构建一个支持长连接复用的连接池。这样的话, 我们可以直接省掉TCP握手以及TLS协商所带来的巨大开销。
特别是在批量拉取历史区块的业务环节中, 我们可以把几十条RPC调用全都塞进同一个event loop里面让它们并发地去执行运行, 经过这么一番操作之后, 其吞吐量能够翻上好几倍之多。
当你碰到那种响应体特别巨大的接口的时候, 例如说去调用eth_getLogs来拉取一个非常大的范围数据时, 选择使用流式读取的方式比对整个内存进行全量加载要更为友好和合适。
此外还有一点非常关键, 就是必须在每一个请求的header里面明确地加上JSON-RPC协议所规定的id字段, 因为这个id的作用在于当多个并发请求的结果同时返回时, 系统依靠这个id来进行正确的映射和匹配, 如果不这样做的话就非常容易出现数据包串错、张冠李戴的情况。
在实际的项目开发过程里, 把httpx和web3.py这两个库混着来用, 这种做法是比较常见的。
具体来看, httpx主要负责处理底层的RPC通信工作, 并且负责连接的管理；而web3.py则专注于ABI编码解码的任务, 以及提供关于链上交互的抽象功能。大家应当各自发挥自身的长处, 避免非要强迫其中一个库去独自完成所有的工作任务。
转载请注明出处：imtoken，如有疑问，请联系（）。
本文地址：https://www.zmdyd.cn/imazbqb/10237.html