https://note.lican.site/tags/mq/ Recent content in Mq on Hugo en © lican.asia All rights reserved Fri, 31 Dec 2021 12:54:50 +0800 https://note.lican.site/posts/posts/why-mq/ Fri, 31 Dec 2021 12:54:50 +0800 https://note.lican.site/posts/posts/why-mq/ <p>大家好，我是煎鱼。想是问题，做是答案。</p> <p>最近我有一个朋友公司踩了不少消息队列（MQ）的坑，让人无奈不已。因此计划写 MQ 系列的技术文章，来科普更多这块的知识。</p> <p>目前 MQ 也是互联网应用中非常常用的基础组件了，面试特爱问。基本有一定规模的系统都能看见他的踪影。</p> <p>无论是 RocketMQ、Kafka、RabbitMQ 等，都围绕着根本的设计出发产生不同的高级功能，甚至可能是雷同的设计有 N 个名字。</p> <h2 id="什么是-mq">什么是 MQ</h2> <p>MQ 一般代指消息队列（Message Queue）。它是一个抽象层，允许多个进程（可能在不同的机器上）通过各种模式（例如：点对点，发布订阅等）进行通信。</p> <p>也可以根据不同的实现，它可以被配置为保证可靠性、错误报告、安全、发现、性能等。</p> <h2 id="为什么需要-mq">为什么需要 MQ</h2> <p>在当下 MQ 的必要场景，比较经典的说辞就是 “异步、削峰、解耦”。是各类秒杀系统的设计核心，甚至会作为不少云厂商的卖点，每家都有自己的生态圈。</p> <p>核心分为三个要点：</p> <ul> <li>解耦。</li> <li>削峰。</li> <li>异步。</li> </ul> <h3 id="解耦">解耦</h3> <p>在业务系统设计中，我们常常会与一个平台系统 A，他汇聚了许许多多的系统的对接。例如，系统 A 作为平台拥有大量用户操作，自然就有非常多的用户行为。</p> <p>虽然他自己可能不大需要，但是其他子系统就不同了，会要系统 A 来调用他们提供的接口，传输各种行为数据。</p> <p>其链路依赖如下图：</p> <p><img src="https://image.eddycjy.com/84478d2799861f81519ede0ba4ceb91d.jpg" alt="多重依赖"></p> <p>这时候作为平台方的系统 A 就烦死了，来一个要对接一个，就得安排一个人排工期和迭代。对方还有可能出现系统不稳定，还得关注他们的稳定性和诉求。</p> <p>但用了 MQ 后就不一样了，如下图：</p> <p><img src="https://image.eddycjy.com/b6c79dbe5c848ed32e347de4042cd9b6.jpg" alt="MQ 解耦直接依赖"></p> <p>系统 A 只需要将消息放到 MQ 中去，不管以后是对接系统 B、C、D、E&hellip;，他都不需要太关心，不用一个个对接。用业务同学的话来讲，就是：“自己看文档，去 MQ 里拿，别来骚扰我”。</p> <p>以此 MQ 达到了系统间解耦的目的。</p> <h3 id="削峰">削峰</h3> <p>在 2C 类别的业务系统中，常常会有活动的概念，要面向用户做促销，像我们常见的双 11、618 都是这类营销，也是营销场景。</p> <p>但这种场景之下，会对系统产生较大的冲击。类似八二原则，也就是 80% 的流量集中在某个时间冲击进来，形成了流量尖峰（高 QPS），系统会因为承受不了如此大的压力，从而宕机。</p> <p>如下图：</p> <p><img src="https://image.eddycjy.com/e396606bb1aec70b43a7016933880f09.jpg" alt="用户直接并发访问"></p> <p>用户的请求会经由系统 A 直击数据库。当然，在活动场景下的大流量，数据库自然也就撑不住了。</p> https://note.lican.site/posts/posts/mq-nodus/ Fri, 31 Dec 2021 12:54:50 +0800 https://note.lican.site/posts/posts/mq-nodus/ <p>大家好，我是煎鱼。</p> <p>前段时间我们分享了漫谈 MQ 的第一期《要消息队列（MQ）有什么用？》，感觉打开了一个新的世界。</p> <p>但很快就有小伙伴意识到了不妙，既然 MQ 承接了多个系统，那岂不是该有的问题，他都有，又或是更甚。如下：</p> <p><img src="https://files.mdnice.com/user/3610/45b00332-9a06-49b6-a666-675890409c94.png" alt=""></p> <p>今天我们就进一步讲讲，<strong>设计 MQ 时很有可能会遇到的几个大难点</strong>，在业内又配套用了什么解决方案去处理。</p> <h2 id="几个难点">几个难点</h2> <p>从结论上来看，设计 MQ 这一个存在。会至少引发三大难点。堪称互联网经典的，也是面试官们最爱问的：</p> <ul> <li>高可用：代表系统的可用性程度，高可用性通常通过提高系统的容错能力来实现，从而减少系统宕机时间。</li> <li>高并发：代表通过设计保证系统能够同时并行处理很多请求，在同一个时间点，有很多用户同时访问同一系统、API、URL。</li> <li>高可靠：代表能够满足预计条件的一个系统或组件（例如：备份、故障处理、数据存储以及访问），比较经典的是 4 个9 等标准。</li> </ul> <h3 id="高可用">高可用</h3> <p>像前面评论区留言的兄弟截图表述的一样。</p> <p>虽然请求不直接找系统 A、B、C、D 了。但是请求都实打实的通过异步的方式打到了 MQ 上，就可以不断往 MQ 塞，变成了多个系统都在请求 MQ，可以认为压力比单系统同步调用大了不止一倍。</p> <p>同时 MQ 还要去做消费关系的维护，存储既有和新增的大量消息。是一个既要也要还要的典型场景。</p> <p>这样一来，新的一轮问题就出现了。就是要保证 MQ 的高可用，否则他轻轻松松就会被压到宕机，或是负载过高，出现一些匪夷所思的延迟。</p> <p>如何保证 MQ 的高可用，是一个大问题。</p> <h3 id="高并发">高并发</h3> <p>在高并发上的诉求上，其实是和高可用的场景是一样的。既然各业务系统都是异步的了，自然他也就不会像同步阻塞一样 “等” 你。</p> <p>像是我有一个朋友，他们喜欢批量清洗多租户的数据。业务程序也不怎么节制，几十、几百、上千万数据，利用 Go 语言写的，抄起 for-loop+go func 就是一把梭。刷刷刷一下子就就给打进 MQ 里。</p> <p>再多来几个业务系统这么干，这 MQ 并发就比较高了，单单维护就是头疼。很有可能事故背着背着，年底就 3.25 了。因为 MQ，在业务中的依赖非常重，是标准的核心基础设施。</p> <p>如何保证 MQ 能够承受高并发，是一个大问题。</p> <h3 id="高可靠">高可靠</h3> <p>对 MQ 来讲，高可靠性的诉求，又分为好几个角度去理解。如下：</p> <ul> <li>消息要靠谱：“我” 发的消息要能够可靠的到达 MQ，MQ 要能够正确的让消费者能够接收到推送或拉取。</li> <li>存储要靠谱：“我” 发的消息，还在 MQ 上时要存储好，不能发到 MQ 上就因为大量数据，丢了。又或是查询很慢。</li> <li>处理要靠谱：发了消息，可能会出现异常。发了消息，可能网络抖动，没有接收到。</li> </ul> <p>上述我们列了三点 “要靠谱” 的内容。实质上，对于 MQ 来讲，其每一块领域都要保证其可靠性，否则查起问题来，真的是会非常崩溃。</p>