真别扯了，99%的人没搞清节点承载力包括啥，链早该崩了

导读： 我做了五年节点运维, 亲眼看到过非常多的团队把承载力这个词语当作一个非常模糊的概念来对待, 似乎他们认为只要服务器的数量充足这件事情就没什么问题了, 说一些比较难听的话...

我做了五年节点运维, 亲眼看到过非常多的团队把承载力这个词语当作一个非常模糊的概念来对待, 似乎他们认为只要服务器的数量充足这件事情就没什么问题了, 说一些比较难听的话, 节点中所包括的承载力的内容细节要比绝大多数人所认知的情况更为琐碎和具体。

节点承载力包括啥

最核心的一个部分, 是网络层吞吐了, 这个指的是什么呢, 就是每秒之中能够处理掉多少交易, 还有区块广播的情况, 如果你去运行一个全节点的话, 它的同步速度, 会直接停留在带宽和磁盘 IO 上面, 而 CPU 并不是瓶颈所在,很多人一开始就忙着堆服务器, 结果网络带宽没有得到充分的提升, 这等于水管太细了, 这样的话, 再有多的水也灌不进去。

要是进一步去仔细考察, 我们就会发现, 存储方面的承载能力才是真正的核心部分。对于一条已经持续运行了两年的区块链网络来讲, 其全节点所积累的数据总量很轻松地就能打破几百个TB的规模, 这里面涵盖了大量的历史区块信息、状态数据库中的数据以及merkle树结构, 所有这些都需要由硬件来进行承担和支撑。

如果磁盘空间的资源配置出现不足的情况, 那么节点就会直接在数据同步的阶段陷入卡死的状态。一旦发生了这样的情形, 后续涉及到的所有业务操作都将全面瘫痪, 无法继续进行正常的处理。

节点承载力怎么测

我平时基本不参与理论方面的推算, 直接施加高压。把真实的交易数据灌进去观察, 看看区块出块的时候延迟高不高, 在P2P广播产生风暴时丢包率是多少, 然后再一直盯着内存看状态树会不会把它吃得满满当当。实际数字的说服力比那些精美的幻灯片要管用得多。

还有一个容易被大家忽略掉的维度, 那就是共识层的容错上限。拜占庭容错比例、验证者数量、最终性延迟, 这些参数一旦确定下来, 节点能够承受多少负载就有了一个固定的天花板。你是没有办法通过调整参数, 把协议设计所达到的极限给突破上去的。

所以, 下次当有人对你说什么加两台设备能够扩充容量的话的时候, 你可以直接让他看一看存储使用量和带宽流量的这些曲线数据图, 承载能力这个概念根本就不是由哪单一的某个指标来决定的, 它是依靠整个网络架构共同作用的结果。