血祭的冷护法之恋今天下午突然 出现 测试环境 cpu飙高，干到了 60%，其他项目 响应时间明显变长。。。有点吓人，不想背锅

　　出问题的项目是 需要连接各个不同nacos 和不同的 namespace 进行对应操作的 一个项目，对nacos的操作都是httpClient 调用的api接口，「httpClient方法 没有问题，不用质疑这个」

　　但是上面这个提示信息 显示 是 线程内部的，而且是nacos client 内部的

　　你这么搞，让我很难受啊，我都是http 调用的，当时就是为了 防止开启无用的线程，这。。。。。「怎么」

　　这是构造方法啊，应该只初始化一次的啊，往上debug，我靠，NacosConfigService 类中调用了，「debug 看什么时候调用了 不就行了嘛」

　　这当时是为了灰度功能，定时数据校验用的 用了一个线程池，当时以为用了线程池 妥妥的。。。还特意调用的 Nocache 方法，让他创建新的nacos Config对象，做数据校对

　　这里可能你要问了 你说 为了防止网络隔离 才加的这个调度任务，什么是网络隔离啊？

　　假设一个Raft集群拥有三个节点，其中节点3的「网络被隔离」，那么按照「BasicRaft」的实现，集群会有以下动作：

　　网络恢复之后，Leader给节点3发送RPC的时候，节点3会拒绝这些RPC理由是发送方任期太小。

　　Leader收到节点3发送的拒绝后，会增大自己的Term，然后变成Follower。

　　随后，集群开始新的选举，大概率原本的Leader会成为新一轮的Leader。

　　多轮投票的安全问题是棘手的，必须避免同一高度不同轮数分别提交两个不同区块的情形。在Tendermint中，这个问题可以通过锁机制（locking mechanism）得到解决。

　　验证者只能「预投票(pre-vote)」他们被锁定的区块。这样就阻止验证者在上一轮中预提交(pre-commit)一个区块，之后又预投票了下一轮的另一个区块。

　　· 波尔卡解锁（Unlock-on-Polka ）：验证者只有在看到更高一轮（相对于其当前被锁定区块的轮数）的波尔卡之后才能释放该锁。这样就允许验证者解锁，如果他们预提交了某个区块，但是这个区块网络的剩余节点不想提交，这样就保护了整个网络的运转，并且这样做并没有损害网络安全性。

　　而日志中原本记录的term也需要将其替换成(term, node_id), 因为这两项加起来才能唯一确定一个leader. 之前raft里只需一个term就可以唯一确定一个leader.

　　「总结下来就是 按照字典排序 和 预投票锁 保证 当多个 term 相同的 candidate 相遇后，肯定会有一个 获得多数派投票」

　　我们如果出现 异常的网络隔离情况再回来，可能导致 数据的不一致，但是上面的 解决办法 因为 比较重，不适合我们，我们就单纯 引入「定时校对的调度任务 进行比较（和 对账一样）」

　　我对nacos config 连接进行 遍历查找 是否存活，不存活 我就shutdown，然后生成一个新的，而不是这种全部生成一边，毕竟人家 构造器开了线程。。。。

　　说回来还是因为 我当时自信了，没往这个调用下面看，在子类中 写的开线程 哈哈，行吧，改改 ，跑到测试环境 看看效果（CPU）

　　好像 测试环境响应时间 变长，和我没关系。。。。是别人压测呢，把带宽吃了。。。。。「看透不说透」