前言
为何写这本书，初衷是在于总结一下自己在消息中间件的一些经验，自己接触这个好几年了，每天做的工作杂乱，即使自己经常写技术笔记和博文，也不是系统性。因此就想着自己把关于这个领域的知识经验总结一下，一个目的是回顾，一个是希望能给看到的人带来一点帮助，做个技术输出的人。
没有使用博文的方式，是因为不够系统，另一个原因是不能够持续迭代。做开发这么多年，懂得了一个真理，写代码需要写两遍，第一遍完成需求和功能，第二遍优化代码，这样才能写出好味道的代码。同理，做技术架构也是这个道理，没有一个永久合适的架构设计，随着时间推移，需求的变更，需要不断的修改和完善架构设计。这其中的奥秘都是在于迭代。聪明的人确实可以一次性写好代码，做好的架构设计。对于我们这类普通的人，只用记住，持续迭代下去，你会变得很优秀。
消息队列能解决哪些问题？
通常来说，我认为主要有四个场景：
- 异步架构
- 系统解耦
- 削峰（流量控制）
- 消息通讯
- 数据管道
绝大多数的文章基本提到的都是四点，数据管道是我自己添加的，像我们公司很多数据都发送到 kafka,并不是因为上面几个场景需要，往往是将其作为一个数据管道。这也是 kakfa 设计的初衷之一。
当然还有其他的场景：
- 连接流计算任务和数据
- 消息广播
消息队列带来的问题
人无完人，技术也一样，看任何事务都不能只看到优点，也得看看缺点，这样设计系统的时候才能做到胸有成竹。
- 延迟问题
- 增加系统复杂度
- 数据不一致
因为消息是异步处理，可能会存在堆积，也就会出现延迟问题。系统引入消息队列，增加了系统依赖，复杂度就会上升。对于数据不一致的问题，在消息队列的领域就是重灾区，例如：消息的可靠传输，消息重复发送，消息重复消费等等。
但这不妨碍我们在架构设计的过程中选择它。在架构师的武器库里，消息队列绝对是一把利器。还有一把瑞士军刀就是缓存。
消息队列必知常识
消息模型
消息队列的发展也是秉承演进，最早的消息模型是队列模型，多个消费者的话，需要将数据复制，形成多个队列，为了解决这个问题，演进出了订阅-发布模型。
队列模型代表产品：RabbitMQ
发布-订阅模型代表产品：Kafka、RocketMQ
消息获取方式
- Push(服务器主动推)
- Poll（客户端主动拉）
这两种方式各有优劣，Kafka 和 RocketMQ 都选择的是拉取的模式，减轻服务器的压力，劣势的话，获取消息不是那么的及时。往往这个延迟，可以由客户端决定。
消息队列的基本功能
- 支持发布/订阅模式
- 消息可堆积，消息数据持久化
- 消息可重复拉取
目前市面比较火的消息队列产品
网上有很多消息队列选型对比，在我看来有用，也没用。有用是能知道适合什么样的场景，没用的是往往我们很多选择还和公司的技术体系有关。公司技术体系层面考虑的是成本，运维。对于开发者往往在乎的是能不能支持这个功能。
做技术选型，不仅仅是技术问题，还有人，管理，组织等。
这个系列只关注与最火的三个产品：Kafka、RocketMQ、Pulsar
对于 Kafka 我比较熟悉，后两者从没有接触过，我也是在学习，了解一下同类产品的使用和设计，做到知己知彼。
本书所有的内容和观点，欢迎大家共同的交流与探讨。