前不久，朋友的公司，出现了比较大的故障。故障引起的原因也比较好解释，因为使用了ActiveMQ的高可用级别(M-S架构，双写完成ACK），结果在高峰期间，造成了生产端消息拥堵，诸多请求无法落地，数据错乱。

一、背景

据他说，他们的应用，级别比电信应用还要高（牛皮一定要吹），所以消息系统要求一条消息都不能丢。他做到了，但是服务不能用了。

这个Case有何而来呢？据说是来自一次高管会议上，某位领导对其中的一个小问题情绪激动：他测试环境测试的某条数据，直接不见了，生产环境并未复现。矛头最终指向了消息系统，直接上升到断电后怎么办云云。

领导发威，事情要特事特办。架构组扯蛋似的熬夜讨论了改进的方案，从Kafka到RocketMQ，从落盘DB到升级到StoreHA方案，不亦乐乎。最终的讨论结果，就是采用极高可用的方式。领导的条件满足了，消息系统也是高可用的，但整个业务不是。最终的MQ吞吐量，连个DB都不如。

典型的枪杆子需求引起的优化故障。一定不少见。

二、思考

高可用是个伪命题，虽然有CAP等耳熟能详的理论支持，还是有很多人陷入了这个误区，包括技术决策人。架构作为全局把控人，能出现这样的错误，纯属低级。下面，是我自己对高可用的一点思考。

拿消息队列来说，并不是说保证消息队列的存活和消息的可靠，就完成了工作。还需要考虑生产端和消费端的拓扑和高可用。比如，生产端异常关闭，缓冲区的处理，低吞吐环境下的消息过盛处理；消费端的消息积压，以及死信处理。

你要是没有提前对业务进行容量分析，也没有相应的扩容手段，更没有对容易发生问题的环节进行监控，那么锅就是你的，没得跑。

业务都跑不下去了，你的服务端组件无论多么的可靠，也是废物。拿秒杀系统来说，你不会要求它先可靠的落地，反而会用一些次可靠的缓存系统进行缓冲，此所谓可用。只有保证了业务的正常流转，才能谈可靠性。

这就是大家常说的熔断。比如一个收银系统，不会等着你的后台真正处理了各种记账逻辑才会返回成功。它的主要目的就是收款，先让你把钱花出去再说，你不能因为一个消息发送失败，就要求支付也一块失败。这个时候，消息就作为一个旁路应用存在，必须设置合理的超时，以至熔断。

再比如放在事务中的一些高耗时操作，都是要命的玩法。

限流就是让用户在最外层就阻断，不让请求进来。用户虽然会看到失败的请求，但不会产生危害性的请求（逻辑交错执行的数据错乱）。撑不住就承认算了，请求导到后台，搞死了某个基础组件，更严重。

分布式系统谈的最多的就是最终一致性，但鲜有人知，最终一致性包括人工环节，甚至客服的介入。一般，产生异常数据的概率还是比较小的，人工可以处理过来。另外，还有其他优化手段：

格式化的详尽日志，能够根据日志恢复

幂等业务，请求保证at least once语义

通过扫描，重试等手段，进行异常数据处理

谈高可用很牛逼么？并不见得。你要能分析提出方的品性和认知能力，分析各种技术手段的后果。并不是谁的权利大谁的观点就正确，很多领导挥舞完大棒，脑子里就已经忘掉了2/3，不是本质问题不用关心。

分布式系统是个复杂的整体，不要以偏概全，搞定了某个组件并不等于搞定真个系统。领导会认为这样，你不能。

一些反例总能引起有益的思考。分析身边的需求，哪些是枪杆子需求，哪些是传话筒需求，都可以说不，坚持自己的专业认知！如果你不知道怎么说，可以把小姐姐味道这篇文章转给他，让他瞧瞧后果。