消息队列（MQ）的中间部分普及了很多年。在Internet应用程序中，它通常是更大的应用程序。我们都可以看到MQ的图。市场上有许多中间的中间件，包括但不限于RabbitMQ，RocketMQ，ActiveMQ，Kafka（流程中间部分）等等。许多开发人员已经掌握了一个或一个或更多消息中间件。但是，仍然有一些朋友对消息中的消息并不特别熟悉。由于各种原因，他们无法从中国起源的原理和细节中学习，这在使用时可能会引起此类问题。在此，我们分析了使用消息队列的典型问题（包括顺序消息，可靠性保证等），并提供一些解决方案。
在单个系统中，可以按顺序进行某些业务处理。当它进行跨系统（有时是相同的）时，更复杂的数据交互的需求（也可以理解为消息传输）将生成交互这些数据的方法，可以同步或异步。在传输数据异步的情况下，运营商通常需要在此基础上存储和分发消息。在此基础上，专门针对消息接收，存储，存储，和开发的专业应用程序，重新发布可以理解为消息队列的中间部分。
扩展：如果我们简单地使用数据库表记录数据，然后接受存储在数据表中的数据，并通过计时任务分配数据表的数据，那么我们已经实现了最简单的消息系统（这是本地消息表）。
我们可以认为，消息中间件的基本思想是使用高效且可靠的消息传输机制进行异步数据传输。在不同消息的中间，在此基本思想的指导下，由于场景的不同场景，功能，性能和总体设计概念的差异。
消息队列（MQ）本身已经实现了从生产者到消费者的一个道路通信模型。RabbitMQ，RocketMQ和Kafka常用的MQ是指实现此模型的消息中间件。在目前，最常用的消息主要是RabbitMQ，RocketMQ，Kafka，Kafka（分布式流处理平台），PULSAR（pulsar（分布式消息流平台）。在这里，我将两个流处理平台纳入其中，其他消息的一些早期消息逐渐消失了视觉。我们遵循两个主要原则：最大程度的熟悉原则（易于操作和维护，使用，使用，使用，可靠的），以及业务契合原则（中间部分的性能可以支持业务量并满足业务功能需求）。
这些常用信息中间零件的比较很容易找到，并且在此处不进行详细描述。大概：PULSAR不如RabbitMQ，RocketMQ和Kafka.rabbitmq很好，主要集中在可获取的新闻和RocketMQ上性能和功能同样重要。KAFKA主要用于大数据处理（PULSAR相似）。
让我们简要介绍异步，不洁和峰的重要性和价值（请参阅下面的以下流程图）：
对于用户注册接口，有2个业务点，已注册并发行了新移民，每个都需要50ms来处理逻辑。如果我们将这两个业务流程耦合在一个接口中，则总共需要100ms才能完成。此过程，当用户注册时，他们不在乎是否立即发出福利。只需尽快注册并尽快返回数据即可。新移民福利的一部分可以在主流过程之外处理。如果我们将其删除，仅在接口的主流过程中处理登录逻辑，并通过MQ推动消息，然后将新移民福利的分布推出逻辑可以以异步方式处理。发行新移民福利的业务通过异步任务慢慢处理。通过分解业务点，我们已经实现了解耦。在注册子公司中增加或降低功能点不会影响主要过程。此外，如果业务的主要过程在某个时刻很高，那么将压力分散到更长的时间以实现目的是异步的减少固定时间段的压力。这是流量的峰值。
**此外，单个线程模型的语言通常对消息中间件的需求更强烈。多线模型或Coroutine语言的语言可以通过其自己的多线程（或Coroutine）机制，但是考虑到持久性问题和管理困难，成熟的中间件仍然比中间件的中间件更多的部分更重要。适合异步数据通信，中间件还可以实现分布式系统之间的数据异步通信。
消息中间件的应用程序方案主要是：
因此，如果您的业务具有上述方案，或类似的功能和性能需求，则快速介绍消息中间零件以提高业务绩效。
尽管消息中间件的引入有很多好处，但使用时仍然存在许多问题。例如：
当然，我们可以将这些问题完善以上问题，并获得以下关键问题：
常规的消息中间零件和流处理中间零件通常可以自身支持顺序消息，但是根据中间件本身的不同设计目标，有不同的原理。结果，当我们使用业务中的中间部分时，我们必须进行定向性。不同的治疗方法。
以下顺序消息设计和分析使用常见消息或流中间件中的顺序问题：
兔子：
RabbitMQ的单个队列本身（队列）本身（队列）可以确保消息中的高级第一。在设计中，RabbitMQ提供的单队列数据存储在单个代理节点上。在打开镜像队列的情况下，图像的队列只是图像的队列。当它作为消息存在时，该服务仍由主排队提供。在这种情况下，单个队列上的消费自然是序列。
解决方案是使用需要按顺序进行强制性的相同的MQ队列，并且仅打开一个消费者的单个队列（并发处理过程的顺序，相同的多线程理论）。由此触发的单个队列可以采用卡夫卡的设计思想。要为单个任务打开一组队列，需要按顺序进行的消息基于其固定徽标（例如：ID），以将此设置分配给该组，而同一徽标的消息输入相同的队列，一个队列使用单个消费者的消费，可以确保消息的顺序和吞吐量。
如图所示：
卡夫卡：
Kafka是流处理中间件。在其设计中，没有队列的概念。消息的消息和接收取决于主题。一个主题可以具有多个分区。这些分区可以分散到多个经纪人节点，并且分区也可以困扰备份的副本，以确保其高可用性。
Kafka可以在同一主题中有多个消费者甚至消费者群体。在Kafka中，通常使用消费者组（消费者组可以在同一主题下相互消费）进行消费。消费者群体中有多个消费者。当消费者消费者消费者下的多个分区一个主题时，消费者和参与者的消费者和平衡将由卡夫卡进行调整。分区只能由同一消费者组的一个消费者消费。
在上述设计概念下，Kafka的内部保证同一分区中的消息是顺序的，并且主题下的信息顺序不能保证信息的顺序。当Kafka的消息生产者发送消息时，您可以选择发送消息给哪个分区。只要我们发送需要按顺序处理的消息并将其发送到主题下的同一分区以确保消息消耗的顺序。（多线程语言使用单个消费者。当多线程处理数据时，您需要确保处理顺序略有结束）。
RocketMQ：
RocketMQ的一些基本概念和原理可以通过Alibaba Cloud的官方网站做出一些理解：什么是消息队列RocketMQ版本？
RocketMQ的消息接收也基于主题。主题下有多个队列，该队列分布在一个或多个制动器上，以确保消息的高性能和接收（类似于Kafka的主题分区机制，但内部实施的原则不是内部实施原则。SAME）。。
RockEtMQ支持本地订单消息消耗，也就是说，以确保同一消息队列上的消息顺序消耗顺序。不支持整体顺序消耗。如果您想实现特定主题的全局序列消息消耗，则可以将主题的队列设置为1以牺牲高可用性。特定的插图可以参考阿里巴巴云文档：序列新闻2.0 -Message Quest requetmq Edition -Alibaba cloud Cloud
消息损失需要分为三个部分：消息生产者将消息发送到消息的中间部分，不会丢失消息。确定您可以消费发送到中间件而不会丢失的消息。
制作人发送消息而不会丢失：
消息中间零件通常具有消息发送确认机制（ACK）。对于客户端，只要消息发送需要ACK确认，您就可以根据返回的结果确定消息是否成功地发送到中间件。此步骤通常与中间件的存储和计划设计有关。中间件的设计，我们通常采取的措施如下：
在特定业务设计中，如果消息发送失败，我们可以根据业务的重要性获得相应的补偿，例如：
消息的消息不会丢失：
数字消息中间零件的消息接收和存储机制是不同的，但是它将根据其特征设计，并且最大保证该消息不会丢失：
RabbitMQ消息接收和保存：
RocketMQ消息的接受和保存：
卡夫卡（Kafka）在收到的新闻中的设计：
袋装保存及时性问题
消费者消费新闻不会丢失：
消息ACK带来了两个问题
无限阻止的问题可能是指RocketMQ消费的重试机制未能在消息上进行一定的设计：
重复消费问题。请参阅下一节。
在分析共同的中间件时，我们经常发现中间件设计人员会处理中间件用户的问题，即，业务开发人员。确实，业务消费处理要比消息生产商要复杂得多。Producer只需要确保消息成功发送到中间件，消费者需要在消费者脚本中处理各种复杂的业务逻辑。
为了解决重复消费的问题，核心是使用唯一的徽标来标记是否已经处理了消息。
通常，当我们引入消息传递中间件时，我们已经评估并测试了消息消费的生产和消费率，以使其尽可能平衡。但是，存在一些不可预测的紧急情况，这可能会导致消息的大量积压。目前，我们可以采用以下方法来处理：
临时紧急扩张
消息预防积压
延迟消息的功能在某些MQ中间件中实现。删除消息和定时消息实际上可以相互转换。
RockEtMQ：RocketMQ正时消息不支持任何时间准确性（用于性能考虑因素）。仅在特定级别上支持延迟消息。消息延迟级别通过经纪人方面的MessagedElaylevel配置。它为每个延迟级别，为相应的消息消费者队列，然后创建相应延迟级别的定时任务。消息消费者队列的原始主题和原始消息消费者队列是从消息消费者队列中取出的。
兔子：
通常有两种解决兔子的解决方案来延迟消息：首先，创建消息延迟死亡字母队列，并带有一个死字母的转发队列以实现消费延迟，但是如果上一条消息未达到ttl时间，则不会转发后一个消息转发队列；另一个是使用延迟的Exchange插件（rabbitmq_dlayed_message_exchange）。相应的队列被消耗。
Kafka本身不支持延迟或计时消息。如果要实现消息延迟，则需要使用其他解决方案。
使用数据库和计时任务来实现延迟消息：
常用数据库的索引结构支持数据的顺序索引。在数据库的帮助下，它可以轻松实现任何时间新闻的延迟消费。使用消费时间存储数据，打开计时任务，在满足启动后提取消息条件，然后将其转发到订单队列以处理或直接处理它（需要处理处理，不会出现后续的处理），但后续不会出现），但随后不会出现），但是将不会出现），但是随后不会出现），但是随后不会出现），但它不会在将来出现），但它不会以后出现），但它不会以后出现），但它不会在将来出现），但它不会以后出现），但不会以后出现），但不会以后出现），但不会出现。直接治疗需要通过吞吐量和并发来考虑。最好将其转发给普通排队为方便起见。定时任务消息的积压s由数据库提出的是可控的，但是吞吐量将受到限制。
使用有序的REID列表来获得延迟消息：
REID有序列表ZSET结构可以实现延迟消息。消息的费用时间添加到ZSET.ZRANGEBYSCORE到命令消费者消息
当然，该解决方案也有局限性。首先，必须对REDIS进行配置以防止消息丢失（如果配置是不合理的，则不能保证100％，但是每个命令的持久性会导致性能下降和称重）；其次，如果延迟的Messagetoo会导致消息的积压形成一个大钥匙。同样，您需要进行平衡的治疗，以重复消费和消费失败（当然，建议打开单个消费过程，以将延迟消息传输到普通队列到消费量）。
基于时间的任务计划：
在许多软件中，有基于时间的定时任务实现。使用时间轮和多级时车轮可以实现延迟的任务计划。如果我们想实现延迟的任务队列，我们可以考虑使用此算法来实现任务的调度，但是我们需要根据任务的延迟限制，满足特定需求和调度时间粒度（多级）。我不会在此处解释时间旋转算法。如果您有兴趣，可以自己搜索它。
通过引入上述部分，我相信您可以自然了解消息队列异步解耦的功能和核心思想，并对如何使用MQ来构建业务问题有一定的理解。大多数MQ使用问题只需要我们要进行更多思考并考虑细节以确保业务的高可用性。即使我们可以在这些解决方案中完善一些核心，以优化我们的业务，参考业务中的类似想法。例如，顺序保证其核心是顺序的消息生产者发送到唯一分区，然后在固定分区中保持消费者顺序消耗的顺序；避免消息丢失的核心是确认和降级机制；性别识别和步骤状态；积压处理的核心是迅速响应紧急计划；延迟消息的核心是消息分类，优化点是性能改进。
总结和解释科学方法。在学习问题处理计划的过程中，我们将完善相应的核心想法，并在使用中解释它。辅助，建立高度可用的业务结构，这是我们最需要做的。
参考：
文字/lisuxing
注意材料技术，并成为最时尚的技术人员！
原始：https：//juejin.cn/post/7096313051644690469