此日志输出与您的区块链连接过载有关。
此通知通常与公共 websocket 连接和/或免费第三方 NaaS 提供商的使用有关。要解决此连接问题，您可以运行自己的完整节点或更改层级或第三方 NaaS 提供商。另外建议使用0.10.8 或更高版本的Chainlink，因为HeadTracker 已在此处进行了修改并且执行效率更高。
关于这个问题，让我试着给你一个小的技术概述，这可能会阐明 Chainlink 节点对其远程完整节点的有效负载：
您的 Chainlink 节点与完整节点建立连接。 Chainlink 节点在那里发起各种订阅，这是 websocket 协议的一个特殊功能，可以实现双向通信。更准确地说，这意味着如果订阅的某个“状态”发生变化，就会通知 Chainlink 节点。基本上，节点使用 JSON-RPC 方法进行交互，并使用以下方法在内部启动和处理各种功能：
eth_getBlockByNumber,eth_getBalance,eth_getTransactionReceipt,eth_getTransactionCount,eth_getLogs,eth_subscribe,eth_unsubscribe,eth_sendRawTransaction和eth_Call
https://ethereum.org/uk/developers/docs/apis/json-rpc/
Chainlink 节点的大量交互特别是在同步过程中通过内部HeadTracker 服务执行。该服务启动“头部”订阅，以便与每个传入的新区块头交互。
在这个同步过程中，它使用 JSON-RPC 方法 eth_GetBlockByNumber 和 eth_getBalance 从块中获取所有必要的信息。所以这两种方法在每个块中都被使用/执行。现在请求的数量取决于 Chainlink 节点连接到的网络的平均阻塞时间
Kovan 测试网就是一个例子：
平均。这里的阻塞时间是 6.7 秒，这意味着您每天的请求数约为。 21.000
在完成工作请求期间，这些请求还包括以下方法：eth_getTransactionReceipt、eth_sendRawTransaction、eth_getLogs、eth_subscribe、eth_unsubscribe、eth_getTransactionCount 和 eth_call，这会根据数量显着增加总数的工作请求。
还应该注意的是，特别是对于更快的区块链（例如多边形），WebSocket 的负载非常高，您必须详细处理良好的全节点连接，因为许多全节点不会收到如此多的请求永久。