高性能零售IT系统的建设02-对RabbitMQ乱用的治理

开篇

上文我们讲述了HTTP乱用、不规范引起的血灾。本文继续讲的是“血光之灾”的内容。好像前两篇怎么都这么“重口味”？

这是因为我要用两篇同样的同内容，它们都属于：涉及到的技术问题相当的简单，但在百人开发团队中也是最容易失控的并结合着真实案例，让大家体会到：技术不能单纯从技术角度去解决问题。在企业级开发、架构和技术管理以及特别是你已经把“屎山”放到了生产环境后所带来的各种复杂情况下如何去有效聪明治理、调优并且要在根本上避免这一类问题时是怎么样的一种手法。此时技术管理之美和架构之美才能真正体现出来。并以此二篇引出后续“监控方法论”和APM使用方法论。

问题的发现

我们生产的MQ对于大厂来说算是mini me一类的了，但是对于除大厂以外的应用，我们的MQ算是很强大了。我告诉大家我们的MQ有多少生产集群呢？

一度达到过3个环境几十台128GB内存、16C CPU的集群。

这个对于千级并发来说简直算是“豪华套餐了”、绰绰有余了。而就在于这样的一个RabbitMQ集群环境下，我们竟然发生了这样的事。

问题的表象

一个零售系统，它所要用到的MQ场景远不止上面几处，我只是列出了一些非常通用的场景，实际多达几百