ETH节点同步时出现的问题

1. 起初同步的速度很快， 在距离最新区块还有100个左右时，速度突然变慢，等待长时间，发现还是追赶不上

> eth.syncing
{ 
    currentBlock: 5790584, // 同步到的区块高度 
    highestBlock: 5790660, // 所链接的节点的最高高度  
    pulledStates: 123621434, 
    knownStates: 123654211,
    startingBlock: 0 
}

2. 明明currentBlock显示已经同步到后面的区块，但是lastest区块依旧是0(创世区块)

> eth.getBlock("latest").number
0

3. 查询某个地址的余额时，明明已经同步到的区块下应该是有余额的，但是通过eth.getBalance()得到的还是0, 这个问题和上面的类似。

> eth.getBalance("0xa12d3......")
0

问题出现的原因

看似同步将要结束时，其实这只是完成了区块头信息下载的阶段，还需要等待状态下载完成，这个过程比获取区块要花费更多的时间。而且，状态的同步主要受磁盘IO限制，而不是带宽，所以才会有快要追赶上最新区块时，速度放慢，这是因为节点在做state下载。在同步未完成，是无法查询到过往的balance，合约中的state的。出现上述问题时，只有等待节点同步完成后，也就是:

> eth.syncing
false

就能正常获取过完的历史数据了。

解决方法

为了尽快同步完，建议：

1. 同步时采用fast模式，目前geth也默认采取fast模式同步。fast同步模式下，会先追赶上eth网络上的当前区块，然后对状态数据做一个快照，之后回像full节点一样进行后面的同步。full模式下的同步则会下载当前区块之前的每一条状态更变数据，整个同步的时间会持续很久。

2. 节点所在服务器采用更高的配置，内存最好16G或以上，硬盘选用SSD。这也是最行之有效的办法，笔者之前使用HHD硬盘，同步持续了2天都未结束，更换成SSD硬盘后，重新进行fast模式下的同步，一个晚上就同步成功。

3. 为了加快同步速度，手动添加节点。在控制台可以通过``net.peerCount`查看当前节点连接的外部节点数量，如果已知有外部稳定的节点，可以执行以下命令添加：

> admin.addPeer("enode://0d1b9eed7afe2d5878d5d8a4c2066b600a3bcac2e5730586421af224e93a58cd03cac75bf0b2a62fd8049cd3692a085758cc1e407c8b2c94bb069814a5e8d0f0@209.9.106.245:30303")
true

4. 在启动节点时设置缓存大小，有一定效果

# 最小16M，默认128M，可以根据内存情况适当扩大
geth --cache 1024

5. 在第一次开启同步后，建议在同步完成(eth.syncing显示false)之前，不要中断geth进程，否则建议删除此前的数据块，重新开始同步。

B计划

如果实在无法完成同步，可以使用第三方的节点服务。推荐infura提供的节点服务，稳定性不错，目前还是免费的。