消息队列中间件架构思路

消息队列每秒钟有5k个请求进来，然后每秒2k个请求出去，在高峰期可能会导致几十万甚至几百万的请求积压在消息队列中。然后可能会导致消息过期失效、消息丢失、特殊情况下消息一致性问题等等。消息队列可以带来削峰、异步、解耦等好处，但是缺点也是不容忽视的。框架集成一个中间件还要考虑系统的复杂度、系统的可用性等问题。

系统可用性降低：系统引入的外部依赖越多，越容易挂掉。服务器挂了，整个系统可用性降低。

系统复杂度提高：怎么保证消息重复性消费？怎么处理消息丢失问题？怎么保证消息传递的顺序性？

一致性问题：A系统处理完了直接返回成功了，用户都以为你这个请求就成功了，要是BCD三个系统，BD两个系统写库成功了，结果C系统写库失败了，数据就不一致了。

消息队列引入它有很多好处，但也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，系统复杂度也许会比原来复杂10倍。

消息队列的架构设计在了解其原理的基础上比较考设计能力，一个常见消息队列系统，从全局把握整体架构设计。

可伸缩性

首先MQ得支持可伸缩性，就是能够快速扩容增加吞吐量和容量，设计成分布式的，就像kafka的设计，broker -> topic -> partition，每个partition放一个机器，就存一部分数据。如果资源不够了，就给topic增加partition，然后做数据迁移，增加机器，就可以存放更多数据了，提供更高的吞吐量。

可用性

MQ的数据要落地磁盘，别进程挂了数据就丢了。落磁盘的时候顺序写，这样就没有磁盘随机读写的寻址开销，磁盘顺序读写的性能是很高的，kafka也是这