消息队列必知必会 - 学习/实践

1.应用场景

三大作用 1.异步处理 2.流量控制 3.服务解耦 -- 这点目前没看明白 场景: 邮件服务， 秒杀，抢购... 消息队列的应用范围广泛，在一些典型且常用的消息队列应用场景中，比如像处理日志数据、监控、流计算等，你需要了解，对应不同场景，应该选用哪个消息队列产品？什么样的姿势才是最佳的使用方式

2.学习/操作

1. 文档 消息队列高手课_消息队列_MQ-极客时间 学习资源推荐 消息队列的最佳学习资料就是它们的官方文档，因为官方文档更加详细准确，并且随着版本迭代，很多第三方教程文档会过时，而官方文档总能保持与当前版本同步更新。以下是几个开源消息队列的官方文档：RocketMQ 官方文档：https://rocketmq.apache.org/docs/quick-start/ RocketMQ 中国开发者中心：http://rocketmq.cloud/zh-cn/ （感谢专栏用户 @0xFFFFFFFF 同学推荐） Kafka 官方文档： http://kafka.apache.org/documentation/ RabbitMQ 官方文档： https://www.rabbitmq.com/documentation.html 在使用消息队列的过程中，如果遇到问题，要善用搜索引擎，我推荐你首选 Google，次之是 Stack Overflow，相对而言，这些搜索引擎搜索到有价值信息的概率会更高一些。 Stack Overflow：https://stackoverflow.com/ 2. 整理输出 目录[共计42章] 01 | 为什么需要消息队列？ 01 | 为什么需要消息队列？_william_n的博客-CSDN博客 02 | 该如何选择消息队列？ 02 | 该如何选择消息队列?_william_n的博客-CSDN博客_消息队列的选择 03 | 消息模型：主题和队列有什么区别？ https://blog.csdn.net/william_n/article/details/122728204 04 | 如何确保消息不会丢失? 04 | 如何利用事务消息实现分布式事务？_william_n的博客-CSDN博客 05 | 如何确保消息不会丢失? 05 | 如何确保消息不会丢失?_william_n的博客-CSDN博客 06 | 如何处理消费过程中的重复消息？ 06 | 如何处理消费过程中的重复消息？_william_n的博客-CSDN博客 07 | 消息积压了该如何处理？ 07 | 消息积压了该如何处理？_william_n的博客-CSDN博客 08 | 答疑解惑（一） : 网关如何接收服务端的秒杀结果？ https://blog.csdn.net/william_n/article/details/122944551 09 | 学习开源代码该如何入手？ https://blog.csdn.net/william_n/article/details/122944383 10 TBD TBD 11 | 如何实现高性能的异步网络传输？ https://blog.csdn.net/william_n/article/details/123040890 12 | 序列化与反序列化：如何通过网络传输结构化的数据？ 12 | 序列化与反序列化：如何通过网络传输结构化的数据？_william_n的博客-CSDN博客 ... 17 | 如何正确使用锁保护共享数据，协调异步线程？ https://blog.csdn.net/william_n/article/details/123359199 有些还是没看明白， 还是要动手实践才行～ .... 更多章节TBD 3. 实践 ....  后续补充 ...

3.问题/补充

1. 我们常说的消息队列，其实应该说是消息代理，消息队列只是消息代理的实现中的一环技术。 常说的Apache ActiveMQ，RabbitMQ，Apache Kafka，都是消息代理的具体实现，还有基于云的消息代理服务实现[本质上也是基于某个消息代理具体的实现，只不过在远端的服务器厂商那里而已]， 如: AWS Kinesis和 AWS SQS[Simple Queue Service]。 2. 关于RocketMQ与Kafka的读写性能对比疑问 RocketMQ以Broker为单位，较粗的力度牺牲了灵活性，带来的好处是在写入的时候，同时写入的文件更少，有更好的批量（不同主题和分区的数据可以组成一批一起写入），更多的顺序写入，尤其是在Broker上有很多主题和分区的情况下，有更好的写入性能 ----------------------------------------- 老师，关于RocketMQ的Broker单文件写入CommitLog的问题，感觉上按照partition来写入的Kafka不是能有更高的并发写入吗，为什么写单个文件的RocketMQ会有更好的写入性能？ 作者回复: 这个是磁盘的特性决定的，磁盘的连续顺序写的性能要远远好于 并发写。 3. 老师，关于RocketMQ以broker为单位进行存储，那么读取的时候，每个主题岂不是得去不同的文件中分别读取批量消息，读取性能上是不是不如kafka呢？ 作者回复: 从存储结构上来说，确实是这样的。 starnavy回复： 好问题！而且系统运行起来之后，Kafka就不需要再以log（n）的复杂度查找每一条消息了，顺序读就行。这样即使刚开始需要多花点时间查找第一条消息，问题似乎也不大。但是，RocketMQ就不行，同一队列的消息存储位置不连续，得不断寻找下一条消息的位置。 4. 关于流计算和批计算 老师讲解 流计算与批计算的区别是什么？ 有些同学在《29 | 流计算与消息（一）：通过 Flink 理解流计算的原理》的课后留言提问，对于“按照固定的时间窗口定时汇总”的场景，流计算和批计算是不是就是一样的呢？对于这个问题，我们通过一个例子来分析一下就明白了。比如，你要在一个学校门口开个网吧，到底能不能赚钱需要事先进行调研，看看学生的流量够不够撑起你这个网吧。然后，你就蹲在学校门口数人头，每过来一个学生你就数一下，数一下一天中每个小时会有多少个学生经过，这是流计算。你还可以放个摄像头，让它自动把路过的每个人都拍下来，然后晚上回家再慢慢数这些照片，这就是批计算。简单地说，流计算就是实时统计计算，批计算则是事后统计计算，这两种方式都可以统计出每小时的人流量。那这两种方式哪种更好呢？还是那句话，看具体的使用场景和需求。流计算的优势就是实时统计，每到整点的时候，上一个小时的人流量就已经数出来了。在 T+0 的时刻就能第一时间得到统计结果，批计算相对就要慢一些，它最早在 T+0 时刻才开始进行统计，什么时候出结果取决于统计的耗时。但是，流计算也有它的一些不足，比如说，你在数人头的时候突然来了个美女，你多看了几眼，漏数了一些人怎么办？没办法，明天再来重新数吧。也就是说，对于流计算的故障恢复还是一个比较难解决的问题。另外，你数了一整天人头，回去做分析的时候才发现，去网吧的大多数都是男生，所以你需要统计的是在校男生，而不是所有人的数量。这时候，如果你保存了这一天所有人的照片，那你重新数一遍照片就可以了，否则，你只能明天上街再数一次人头。这个时候批计算的优势就体现出来了，因为你有原始数据，当需求发生变化的时候，你可以随时改变算法重新计算。总结下来，大部分的统计分析类任务，使用流计算和批计算都可以实现。流计算具有更好的实时性，而批计算可靠性更好，并且更容易应对需求变化。所以，大部分针对海量数据的统计分析，只要是对实时性要求没有那么高的场景，大多采用的还是批计算的方式。 网友评论 流计算和批计算的解释真是精彩啊！实时计算和离线计算在不同的业务场景下，各有千秋。流计算时效性强，比较实时，能够在分析数据之后提供数据以便生成业务决策，但是需要容灾，批计算是秋后算账，但是保留了元数据和底根，更随时对快照数据发起不同维度的计算分析，但是时效性不是那么强。 个人的想法，有时候也许可以两者都是用，只要业务需要～～～ 5. ZeroMQ现在都没人用了么？ 作者回复: 有啊，不过ZeroMQ它是Brokerless的设计，和其它MQ的使用场景不太一样。 另外网友回复：我们在用zeromq,超级棒的网络库，没有之一。 6. 简单的说，我们在单体应用里面需要用队列解决的问题，在分布式系统中大多都可以用消息队列来解决。 队列跟消息队列不是一回儿事？TBD 从字面意义上看，肯定是队列的范围更大～

4.参考

消息队列高手课_消息队列_MQ-极客时间 04 | 如何利用事务消息实现分布式事务？_william_n的博客-CSDN博客 29 | 流计算与消息（一）：通过Flink理解流计算的原理-极客时间

后续补充

...