从事区块链节点运维工作的人, 总有一天会碰到网络限速这一件事情。无论是API的调用频率被限制住了, 还是数据同步的速度被压低到极低的状态,区块链限速这个问题看起来很简单, 但是如果调节得不好, 很可能导致整个基于该区块链的业务全部停止运行。
我在这一行业已经工作了三四年的时间, 所踩过的坑也不少数, 现在把这些最关键的要点讲清楚。
区块链限速怎么设
节点侧的限速参数, 核心点就在于两个部分, 一个是QPS上限, 另一个是带宽阈值。很多技术人员在起步阶段会把QPS数值拉的非常高, 导致的结果是对端的交易所接口直接把你自己ban掉。
按照我个人的经验, 通常建议把上限设置为实际业务峰值点数一点五倍, 这样能够为突发流量留够缓冲空间, 千万不要让运行数据紧紧卡着天花板去跑。至于带宽这条线, 其设置必须跟节点的硬件配置紧密结合, 如果你拿只有两百兆内存或配置的机器去硬扛一吉流量的数据, 这完全就是在自找苦吃。
区块链限速怎么解
一旦遇到被限流的情况, 千万不要只是盯着参数去修改。应该先去查看日志文件, 看看是TCP连接的数量达到了上限, 还是RPC任务的队列出现了溢出情况。因为导致问题的原因不同, 所采取的处理方法也应该不同。如果发现连接数不足, 那就去调整ulimit这个限制值。
如果确实是出现队列为满的情况, 那么就应该增加worker线程的数量。我曾经亲眼目睹过一个技术团队, 他们连续更改了三次参数, 但是服务依然没有任何起色。最后经过仔细排查才发现, 其实是安全策略把长的连接给切断了, 为此白白浪费了大半天的时间进行无谓的折腾。
在限速这个问题上, 并没有那种放之四海而皆准的通用公式, 必须要时刻关注自己的链路状况以及当前的负载水平, 通过长时间的实践去慢慢调试。
参数的设定从来不是一次调整妥当就可以一劳永逸的, 随着链路上数据量的逐渐增长, 原来看起来足够使用的阈值可能会变得不再适用, 因此隔三差五地回头看一眼总是没有坏处的。
