踩坑了！这4种高可用RocketMQ集群搭建方案，直击优秀开源框架灵魂

写在前面

很多小伙伴留言说让我写一些工作过程中的真实案例，写些啥呢？想来想去，写一篇我在以前公司从零开始到用户超千万的数据库架构升级演变的过程吧。

本文记录了我之前初到一家创业公司，从零开始到用户超千万，系统压力暴增的情况下是如何一步步优化MySQL数据库的，以及数据库架构升级的演变过程。升级的过程极具技术挑战性，也从中收获不少。希望能够为小伙伴们带来实质性的帮助。

1、为什么要使用消息队列?

分析:一个用消息队列的人，不知道为啥用，有点尴尬。没有复习这点，很容易被问蒙，然后就开始胡扯了。

回答:这个问题,咱只答三个最主要的应用场景(不可否认还有其他的，但是只答三个主要的),即以下六个字:解耦、异步、削峰

(1)解耦

传统模式:

传统模式的缺点：

• 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！

中间件模式:

中间件模式的的优点：

• 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。

(2)异步

传统模式:

传统模式的缺点：

• 一些非必要的业务逻辑以同步的方式运行，太耗费时间。

中间件模式:

中间件模式的的优点：

• 将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度

(3)削峰

传统模式

传统模式的缺点：

• 并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常

中间件模式:

中间件模式的的优点：

• 系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。

2、使用了消息队列会有什么缺点?

分析:一个使用了MQ的项目，如果连这个问题都没有考虑过，就把MQ引进去了，那就给自己的项目带来了风险。

我们引入一个技术，要对这个技术的弊端有充分的认识，才能做好预防。要记住，不要给公司挖坑！

回答:回答也很容易，从以下两个个角度来答

• 系统可用性降低:

  你想啊，本来其他系统只要运行好好的，那你的系统就是正常的。

  现在你非要加个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可用性降低

• 系统复杂性增加:

  要多考虑很多方面的问题，比如一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。

  因此，需要考虑的东西更多，系统复杂性增大。

但是，我们该用还是要用的。

3、消息队列如何选型?

先说一下