这样的高可用,我不要!

4,371 阅读5分钟

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

背景

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

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

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

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

思考

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

高可用不是组件高可用,是业务高可用。

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

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

业务先能用,然后讲可靠

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

主要流程不能阻断,可靠性降级

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

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

不能玩就限流,别硬撑

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

数据不能丢,我还能找回来

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

1、格式化的详尽日志,能够根据日志恢复 2、幂等业务,请求保证at least once语义 3、通过扫描,重试等手段,进行异常数据处理

别把高可用挂在嘴上,那很sb

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

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

End

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

更多精彩文章。

《微服务不是全部,只是特定领域的子集》

《“分库分表" ?选型和流程要慎重,否则会失控》

这么多监控组件,总有一款适合你

《Linux生产环境上,最常用的一套“vim“技巧》

《使用Netty,我们到底在开发些什么?》

Linux五件套之类的。

《Linux之《荒岛余生》(一)准备篇》

《Linux之《荒岛余生》(二)CPU篇》

《Linux之《荒岛余生》(三)内存篇》

《Linux之《荒岛余生》(四)I/O篇》

《Linux之《荒岛余生》(五)网络篇》