"不保证可靠"：监控系统与业务系统在可靠性设计上的根本分野

CAT在设计之初就明确把”不保证可靠”列为一项核心设计原则——允许监控消息丢失，这个看似反常识的取舍，实际上是CAT整体架构能做到高吞吐、简单可扩展的关键前提。监控系统的核心价值在于快速发现故障、快速定位故障、辅助性能优化，而这些价值高度依赖两个条件：一是全量采集（尽可能不遗漏任何一次调用的信息，才能还原真相），二是实时处理（信息价值随时间锐减，尤其在处理事故的过程中）；这两个条件叠加在一起，意味着系统要有能力承受极高的写入吞吐。如果同时还要求”消息绝对不丢失”（也就是常规业务系统追求的强可靠性），就必须引入各种确认、重试、持久化保证机制，这些机制的开销会直接拖累系统能够承受的吞吐上限，而监控系统一旦扛不住真实的高吞吐流量，反而会在故障排查最需要它的关键时刻掉链子——这就与”快速定位故障”这个核心价值背道而驰。因此CAT主动选择：允许消息丢失（目前服务端依然能做到4个9的可靠性，只是不做绝对保证），用这个让步换取架构的简单和吞吐能力的上限，同时把”CAT本身出故障不能影响业务正常运转”作为另一条底线——CAT挂了，只是监控能力暂时减弱，不能反过来拖累它本该监控和保护的业务系统。这个案例揭示了一条容易被忽视的系统设计原则：可靠系统和不保证可靠的系统，在架构设计上的差别是根本性的，不是”稍微降低一点可靠性”这种量的差异，而是从复杂度到吞吐能力都会因为放弃”绝对不丢消息”这一条要求而发生质变——设计任何系统之前，都应该先清楚地判断这个系统真正需要的是哪一种，而不能想当然地认为”可靠性当然是越高越好”。