Tiance

现在的情形是这样的，假设chain-co选择最优节点时有3个节点都正在计算链的新状态，距离计算完成剩余时间分别为：5s,10s,3s; 目前的逻辑并不能做到请求剩余时间最少的同步节点API. 如果选择了剩余10s的节点,会导致API耗时很久,影响正常的业务,如出块的某些接口:MinerGetBaseInfo,MinerCreateBlock,MpoolSelects

第一个参考设计: (2) chain-co选择最优节点时,如果有多个节点同步高度相同,则全部记录,不是从中随机选一个作为最优; (2) 对需要状态计算完成才可以返回的接口,多线程调用最优列表中节点的API,返回第一个请求到的结果.

假设chain-co有3个同步节点，高度和同步新区块剩余时间分别为: | 高度 | 同步区块剩余时间 | | -------- | -----: | | 100 | 10s | | 100 | 2s | | 99 | 0s | 在这种情形下，chain-co选择最优节点大概率会是第一个，部分API需要等待最新区块同步完成，故耗时很久，如选择消息，请求BaseInfo等接口。