同步性能优化（一）

犹记得一年多以前，在 cita 项目组，同步优化也写过几篇文章，当时也是存在同步性能、逻辑问题，导致同步效率低下，进而重写了网络同步。ckb 上线近四个月的时候，陆续接到不少同步效率低下甚至无法同步的用户反馈，从二月底开始，我基本算是全力投入到 ckb 同步的优化任务中，不过与之前的优化不同，这次并不是单枪匹马，而是拆了几个方向，分人并行执行。

优化的研究方向

ckb 作为一个谁也不知道有多少节点的区块链，在任何改动进行之前，都有兼容性的强制需求，可以理解为前置心理负担。它的协议不是不能改，是有很大的成本和权衡点，一般情况下，默认是不考虑任何 break 点。

我们接到的反馈有：

• 同步很慢
• 无法同步
• 有不明原因的卡顿

对应这些问题，有很多检查和研究的方向：

• 可能存在的 bug
• 在某种未知状态下的异常状态导致异常卡顿
• 优化带宽利用率和 CPU 利用率
• 优化同步协议
• 优化代码实现

现状

这两个月，我基本在优化同步协议、带宽利用率这两个方向上做功，在做这些事的过程中，把遇到的 bug 顺手修复、实现问题顺手改进，而 cpu 利用率则有组内其他成员研究。

到目前为止，如果加上已经实现准备合入的代码来看，比两个月前，也就是 0.30 版本来看，同步速度提高了 6-8 倍的样子，是一个可喜的成绩，后续还有优化的空间，乐观估计一个数量级的提高，也就是对比 0.30 版本 10 倍的提高应该是可以完成的（心大的目标），那先来列举一下目前的同步性能，以 4 核机器、ip 为香港为例：

• 0.30.x ，4k-8k block/min，存在可能的卡死
• 0.31.0-0.31.1，10k-14k block/min
• 暂未合入的分支，18k-26k block/min

所有改动的代码都可以在 Github 项目地址查看，之后会分类对每一种优化做一点记录，这篇就不深入探讨了。

小结

这两个月其实是一个难得的体验，之前很少有机会集中精力只为了做优化，为了做方案实现，也看了不少类似方案的实现代码，通过各种对比，在可能的方向上做一些尝试。

请登录后评论