013、错误计数器增长与节点退出的临界条件一个分布式采集系统的午夜惊魂去年冬天，一个跑了快半年的分布式数据采集系统突然在凌晨两点开始大量丢数据。运维同事被电话叫醒，登上跳板机一看，监控面板上一大片节点从绿色变成灰色，集群拓扑图上像被虫蛀了一样，十几个采集节点陆续消失。重启服务能恢复，但过几十分钟又开始掉。折腾到天亮，最后发现根因跟一个不起眼的错误计数器有关。这个系统大概三十来个采集节点，每个节点负责从不同数据源拉取数据，然后写入一个共享的存储集群。节点之间通过一个轻量级的心跳机制维持成员关系，心跳包和业务数据走同一套网络通道。设计的时候觉得挺简单，实际跑起来才发现，网络抖动、对端响应慢、临时端口耗尽这些事全都会发生，而错误计数器在这些场景下的行为，跟教科书上讲的完全不是一回事。那次事故之后，我把错误计数器和节点退出的逻辑重新梳理了一遍，也踩了不少坑。这篇文章就把这些经验整理出来，重点讲那些公开资料里很少提的工程细节。错误计数器到底在数什么很多人以为错误计数器就是“出错了就加一”，但实际上，不同系统里这个计数器的语义差别很大。有的实现里，一次超时算一个错误；有的实现里，一次超时加上一次重试失败算两个错误；还有的实现里，只有连续失败才累加，中间成功一次就清零。我见过一个比较典型的实现，它的错误计数器是这样的：// 伪代码示意：一个常见的错误计数逻辑