1. 启动链

    使用如下命令检查下链节点是否启动。如果看到有如下 4 个进程，则代表链启动成功。如果进程数不满足 4 个，则进入到 nodes/127.0.0.1 目录，执行 ./start_all.sh 启动所有的链节点。

ps -ef|grep -i fisco

2. 检查链节点共识   

    链节点共识正常，则代表链正常，可以进行正常的交易处理。现在先让我们检查下节点共识是否 ok 。进入 nodes/127.0.0.1/node0/log 目录，ls -lrt ( 文件从旧到新进行排列 ）。可以看到如下输出。    

    这里我们取最下面的 log 文件进行查看，作者这里的文件是  log_2021030517.00.log， 各位读者大大需要根据自身节点的实际情况，取最新的日志文件。执行如下命令 tail 命令，可以看到有 “++++” 字样的输出，表示节点共识正常。这里大家只需要先了解下，节点有 "+++" 输出，表示链工作正常 （ 可以想象为手机正常工作，可以用来打电话，发短信等) ，具体共识的作用，大家可以百度下 pbft ，或是查看我的另一篇关于 group.x.genesis 文件的详解。

tail -f log_2021030517.00.log |grep +++

3. p2p 配置之 listen_ip ，listen_port   

    进入nodes/127.0.0.1/node0 目录，看到其中的 p2p 配置项如下。其中 listen_ip 和 listen_port 的作用和 rpc 中 的 listen_ip , listen_port 的作用如下。具体可参考我的上篇文章 “FISCO BCOS 实战教程（三）config.ini 配置详解之 rpc“

4. p2p 配置之 node.x

    查看 nodes/127.0.0.1/node0/config.ini，我们看到有四个配置项记录，分别是 node.0, node.1, node.2, node.3 。还记得我们搭建的时候的命令吗，搭链的时候，我们输入的参数 127.0.0.1:4 中的 4 指定了 127.0.0.1 这个机器上 （ 也就是本机机器 ) 有 4 个节点。所以这里有 4 个配置项，分别代表每个节点。以node0 为例，node0 就是通过这四个配置项和其他节点建立连接的。如果这几个配置项配置错误，会影响本节点和其他节点的共识。接下来，我们看下看下修改这些配置项会有什么影响。

bash build_chain.sh -l 127.0.0.1:4 -p 30300,20200,8545

        首先，进入 nodes/127.0.0.1/node0 目录，注释掉 node.0, node.1 , node.2, node.3 这几个配置项。然后执行 ./stop.sh; ./start.sh 重启 node0。

    之后，进入到 nodes/127.0.0.1/node0/log 目录，执行 ls -lrt 确认最新的日志文件。然后执行如下命令 （ 作者这里是 log_2021030517.41.log ，各位读者大大根据自身的实际情况修改 ），查看共识是否正常。从输出来看，共识是正常的，貌似修改这个配置不会造成任何影响。下面让我们继续进行实验。

tail -f log_2021030517.41.log | grep ++

    分别进入到 nodes/127.0.0.1/node1,  nodes/127.0.0.1/node2,  nodes/127.0.0.1/node3 目录，修改其中的 config.ini 文件配置如下。注释 node.0 的配置，然后重启 node1, node2, node3 节点。

        下面我们进入到 nodes/127.0.0.1/node0 目录，然后首先 ls -lrt 查看下最新的日志文件，然后使用 tail -f xxx.log |grep ++  查看共识。 这里我们可以看到，grep 没有输出任何信息，表示 node0 没有参与到共识之中。（如果去 node1/node2/node3 的 log 目录中 grep ++ 查看日志中的共识信息，可以发现 node1/node2/node3 的共识是正常的 ) 那么这个现象的原因是什么呢 ？ 当我们把 node0/config.ini 中 node.0, node.1, node.2, node.3 的配置注释后， node0 就不会主动去和 node1/node2/node3 建立 p2p 连接，但又因为 node1/node2/node3 的 config.ini 中存在 node0 的配置，所以这些节点会主动和 node0 建立 p2p 连接，注意到没有，这里只要有一方发起建立 p2p 连接就可以成功的建立 p2p 连接。到后面，当我们把 node1/node2/node3 的 config.ini 中 node0 的配置项也注释后，所有的节点都不主动发起和  node0 的 p2p 连接，所以 node0 和 其他节点断链了，无法进行共识。 

    这里，相当于模拟了 node0 和 node1/node2/node3 断链的情况。即当 node0  和  node1/node2/node3 因为网络问题和建立 p2p 连接时，会出现节点 （ node0 ) 共识异常的情况。关于共识，可以百度搜索下 pbft 共识算法，在后续的文章中也会进行详细的说明。

    下面，我们继续做下面的实验。node0/config.ini 配置内容如下。只保留 node.1 配置项，其他配置项注释。

    node1/config.ini 配置如下。配置项正常，没有注释。

    node2/node3 的 config.ini 配置项如下。 node0 配置项被注释，其他配置项正常。

    之后，进入到 nodes/127.0.0.1 目录，执行 ./stop_all.sh ;  ./start_all.sh 重启所有节点。重启成功，进入到 nodes/127.0.0.1/node0/log 目录。ls -lrt 找出最新的日志文件，然后执行 tail -f xxx |grep ++ 查看共识，我们可以看到共识正常。这是因为 node1 和 node0/node2/node3 都有 p2p 连接， node0 可以通过 node1 中转，把消息发送到 node2/node3 上。

5. 配置还原

    为了后续的实验，我们需要把 node0/node1/node2/node3 中的 config.ini 配置文件还原，去掉其中的注释，然后进行节点重启。

5. 总结

    p2p 配置项是节点之间的配置项，当出现网络异常时，会导致共识节点无法共识，就如我们上面模拟的一样。同时在节点迁移和扩容的时候，会涉及到修改这里的配置，在后续的章节中会有详细说明。