2024-02-10 11:02:37 | 来源: 互联网整理
康宇峰是一位外表温柔，内心搞笑的程序员。 他经常访问技术社区。 他曾经对体育运动有着广泛的热爱。 他是篮球、羽毛球、游泳、自行车等方面的专家，喜欢涉猎行业最新资讯，喜欢电子产品。
消息队列中间件是分布式系统中的重要组件。 主要解决应用耦合、异步消息、流量削峰等问题。 实现高性能、高可用性、可扩展性和最终一致的架构。
异步处理以用户注册场景为例。 用户注册时，需要向用户发送激活邮件，并发送短信提醒用户打开邮件进行激活。 根据串口场景，需要遵循先发送邮件，再发送短信的流程。 使用消息队列可以实现发送电子邮件和发送短信的并行处理。 类似于两个可以并行执行的场景，不需要按顺序执行。 消息队列可以用来实现异步处理。 如果在并发量比较大的系统中，两个模块可以通过独立的应用来处理同时处理两个进程的业务。
流量剃须 流量剃须是消息队列中非常常见的场景，一般广泛应用于抢群活动中。 此类活动通常会因流量过多而导致流量突然增加。 如果扩展节点，在应用空闲时会造成资源浪费。 如果维持原来的应用程序规模，应用程序可能会挂起。 消息队列可用于将用户抢购请求添加到消息队列中，通过后端分布式多个应用程序处理用户抢购请求，并在处理完成时通知用户。 这样可以均匀分配流量，同时防止后端应用程序因并发超出应用程序能力而被挂起。 另外，对于闪购系统，可以设置定长队列。 用户请求存储在消息队列中。 如果库存超过限制，则会提示用户结束抢购。 随后用于订购、物流等操作。
服务解耦 我们之前讨论过闪购。 对于电商系统来说，用户下单后，会进行订单接收->产品发货->物流配送等流程。 现有的电商系统需要承受巨大的用户订单，而同步流程根本无法处理这些流程。 应用结构可以通过消息队列来实现。 订单系统、商品管理、物流配送、支付功能可以拆分为独立的应用。 消息队列可用于在各个应用程序中传输消息。 同时可以通过一些技术手段保证消息不重复、不丢失。 它快速响应用户并确保每个部分独立运行。 在业务逻辑复杂的场景下，增加节点可以保证整个流程快速完成。
最常用的消息队列是Kafka。 本文主要讲一下目前常用的两种消息队列。
1.Kafka及比较
Kafka最初是由该公司开发的。 它是一个分布式、分区（）、多副本（）、协调的分布式消息系统。 其最大的特点是可以实时处理大量数据，满足各种需求场景。 ：比如基于批处理系统、低延时实时系统、storm/Spark流引擎、web/nginx日志、访问日志、消息服务等，用scala语言编写，2010年贡献基金会并成为顶级开源项目。
阿里巴巴对Kafka做足了功课之后，吸收了Kafka无限的消息积累和高效的持久化速度的特点。 同时定制开发了很多用于淘宝交易、订单、充值等场景的功能，并用Java语言重新编写。 消息队列定位为无日志可靠消息传输，目前在阿里巴巴集团广泛应用于订单、交易、充值、流计算、消息推送、日志流式传输、分发等场景。 在吸收高并发和无限堆叠的同时，保证数据一致性、高可用、顺序性等特性，适合电商等要求较高的业务。 目前阿里巴巴已经贡献给开源社区，基本保留了所有现有功能。 下面是两种消息队列特性的比较。
数据可靠性
支持异步实时刷盘、同步刷盘、同步（备份）、异步
Kafka采用异步磁盘刷新方式，异步
总结：同步磁盘刷新比Kafka具有更高的单机可靠性，并且不会因为操作系统崩溃而导致数据丢失。 同时同步比Kafka异步更可靠，不存在数据单点。 另外，Kafka以topic为单位，支持主机宕机时自动切换备机。 然而，这里有一个问题。 由于是异步的，切换后会有数据丢失。 同时，如果重新启动，也会与现有数据发生冲突。
如果Kafka设计为宕机，它会从注册中心寻找新的动作（会出现主备数据不一致的情况）。
可以是多模式，数据同步复制（数据一致，也可以异步）。 如果其中一个发生故障，其他的仍然可用（仍然可以写入）。 如果主从结构出现故障，从机仍然可以提供消费服务（连接到数据后可以完成消费），但数据无法再写入其中。
性能对比
Kafka单机写入TPS约为100万条消息/秒，消息大小为10字节
单台机器每秒可以向单个 TPS 实例写入约 70,000 条消息。 如果单机部署3个的话，最大可以达到12万条消息/秒。 消息大小为 10 字节。
总结：Kafka单机TPS达到百万。 大多数使用Kafka的应用都会采用批量消费模式，将多条小消息合并并批量发送。 Kafka还有一种模式是单条消息收到ACK后。 这种模式与buffs的批量处理相比，效率相差很大，所以在Kafka场景中很少使用。
设计的出发点是保证消息的高可用，避免消息丢失，所以主要采用发送确认模式（消息发送到，成功返回给业务。是一个双向的发送和确认的过程，如果此时单向宕机，会导致消息丢失，业务错误），这种应用场景适合非常高并发和大数据场景（即牺牲高可用来保证并发）效率）。 另外，用Java语言编写的应用程序在高并发系统中会被缓存。 消息过多会增加GC的负担；
单机支持的队列数量
如果单台Kafka机器的队列/分区超过64个，负载会显着增加。 队列越多，负载就会越高，发送消息的响应时间就会变长。
单机最多支持5万个队列，负载不会有明显变化。
总结：队列多适合业务场景复杂的业务。 一台机器可以创建更多Topic。 每个Topic由一批队列组成，因此可以创建更多的消费者线程。 集群大小与队列数量成正比。 数量越多，集群就越大。
实时消息传递
Kafka：使用短轮询方式，实时性能取决于轮询间隔
：采用长轮询，与实时写入一致，消息写入延迟通常为几毫秒。
总结：
短轮询：定期向服务提供者发起请求获取数据
优点：前端和后端程序编写起来比较容易。
缺点：大部分请求无用，难以维护，浪费带宽和服务器资源； 响应结果乱序（因为是异步请求，当发送的请求没有返回结果时，后面的请求会再次发送。此时，如果后面的请求必须在前面的请求之前返回结果，那么当上一个请求返回的结果数据，它已经是过时且无效的数据）。
长轮询：客户端向服务器发送请求。 服务器收到请求后，保持连接，直到有新的消息，然后返回响应信息并关闭连接。 客户端处理完响应信息后，向服务器发送新的请求。
优点：没有消息时不会频繁请求，消耗资源少。
缺点：服务器保持连接消耗资源，难以管理和维护。
消费失败重试
Kafka：消费失败不支持重试
：消费失败支持定时重试，每次重试的间隔时间推迟。
总结：Kafka还可以通过编写代码来实现写入和消费失败的重试机制。 这个需求需要用户编写代码来实现。 Kafka只提供了这种方法，但并不是他推荐的使用方式。 他的设计模型只考虑到了这种情况，而不是要点。 设计中已考虑到这种情况。 官方API中提供了重试设置。 用户可以选择多种模式的重试机制和定制的重试逻辑。 简单场景下，用户只需要进行设置即可。 参数。 对于需要重试的场景，比如充值应用，如果当前时刻调用运营商网关，充值失败，可能是因为对方压力太大。 稍后调用就会成功。 例如支付宝对于银行扣款也有类似的要求。 这里的重试需要可靠的重试，即重试失败的消息不会因为宕机而丢失。
严格的消息顺序
Kafka支持消息顺序，但是一个()宕机后，消息会乱序（会根据注册中心调整到其他，数据同步会不一致）；
支持严格的消息顺序。 在顺序消息场景中，当一台机器宕机后，发送消息会失败，但不会乱序。
消息取决于应用场景。 理论上如果不出问题的话，Kafka也是可以顺序消费的。 应用程序在写入消息的时候也可以选择对应的()来保证同类型的数据是顺序的，但是Kafka在设计上并不追求严格的顺序消费（如果不选择，那么topic下的就会是随机选择的），但特殊情况下消息会乱序，但设计上可以保证跨分区的消息顺序消费，比如Mysql的分布。 需要严格的消息排序。
需要注意的是，Kafka和Kafka都只保证消息在队列中是顺序的。 应用程序消费者需要确保消息出队后按顺序消费。 两者的设计都是只关注自己的问题，把自己的应用留给接收者。 处理。
以下是顺序消费的基本逻辑
定时消息
Kafka不支持定时消息
支持两种类型的定时消息。 开源版本仅支持 Level（时间分类，如延迟2s、5s）。 适用于需要延时的场景。 值得注意的是，阿里云系统的消息队列支持定时消息，精确到毫秒级别，可以延迟到指定时间。
总结：Kafka不支持应用程序自己调度消息。 如果需要，用户可以通过生产应用端和消费应用端的程序逻辑来实现。 它支持应用程序自己的定时消息。 在开源版本中，用户可以选择延迟消耗步数。 这种模式一般适用于一些需要一定延迟的业务逻辑。
分布式交易消息
Kafka不支持分布式事务消息
开源4.3版本支持分布式事务消息
例如：用户从农业银行向招商银行转账100元。 农业银行和招商银行的系统分别部署在各自的机房内。 系统通过消息进行通信以防止过度耦合。 整个模型可以描述为：农业银行扣除100元后，向招商银行发送“已扣款”消息。 招商银行收到消息，知道农业银行已成功扣款，然后向其账户添加100元。 过程中需要保证农行扣款、招商银行付款（同时成功）。
实现逻辑发送后，由于不是完整的交易消息，因此消息无法立即被消费。 您可以继续或终止交易（）。 只有当pawn之后你才能消费这个消息。 RMQ 会定期询问是否可以结束那些因错误而未终止的生命周期，以达成交易的最终协议。 需要注意的是，分布式事务并不是万能的，需要应用侧从业务层面进行双重防护。
留言查询
Kafka不支持消息查询
支持根据Id查询消息，也支持根据消息内容查询消息（发送消息时指定一个Key，任意字符串，比如指定订单ID）
总结：消息查询对于定位消息丢失问题非常有帮助。 例如，订单处理失败，无论是未收到消息还是接收处理中出现错误。
10
消息回溯
Kafka理论上可以如下回溯消息
支持根据时间回溯消息，精确到毫秒，例如从一天前的某时某分秒开始重新消费消息。
总结：典型的业务场景包括订单分析，但是由于程序逻辑或者依赖系统故障，今天消费的消息全部失效，需要从昨天的零开始重新消费，所以基于时间的消息重放功能对于业务来说非常有用有帮助。 Kafka可以支持数据回溯，前提是要有相应的沉淀。 可以通过脚本、程序等方式将消息重新读入队列。官方API直接提供了传入时间参数，用于数据重新消费。
11
消息并行性
Kafka消费并行度取决于Topic中配置的分区数量。 例如，如果分区数为 10，则只有 10 个相应的消耗线或进程处于活动状态。 即消费并行度与分区数量一致。
消费并行有两种情况。 顺序消费的并行性和Kafka一模一样。 乱序模式下的并行度取决于线程的数量。 例如，Topic配置了10个队列，10台机器消费，每台机器100个线程，那么并行度为1000。
总结：消费并行度越大，理论上在主机资源丰富的情况下，可以通过扩大并行度来提高消费并发度。 提高系统吞吐量。
12
留言轨迹
查询消息何时接收、何时消费、在哪个主题等。
Kafka不支持消息跟踪
支持消息跟踪，（Java客户端版本1.2.7及以上）
总结：通过消息跟踪查询，我们可以知道消息何时入队、何时被消费、在哪个主题上，这有助于通过应用日志定位系统问题。
13
结束消息过滤
Kafka不支持端侧消息过滤
支持两种终端消息过滤方式。 1.根据Tag进行过滤，相当于子主题的概念。 您可以为同一主题下的消息打标签，消费时根据标签进行消费。 2.可以通过编码过滤任何形式的消息，甚至可以过滤和分割正文。
总结：过滤只涉及队列中的多种类型的数据。 我们当前的()有具有一定特征的数据，比如具有一定标签的数据，或者消息体中具有一定属性的数据。 按标签过滤更为常用，但按消息正文过滤应谨慎使用，因为这不是一种有效的方法。 当需要过滤时，我们可以在将生产者消息添加到队列时对其进行标记。
14
消息积累能力
Kafka的堆叠能力比Kafka更强，但单机也能支持亿级消息堆叠能力。 这种堆叠能力完全可以满足99%的业务需求。
15
到期
Kafka处理极大并发和大规模计算分析，同时可以接受一定的数据丢失（通常发生在极端情况下，或者资源使用超过限制），在这方面的性能同比是最好的- 年，目前已上市。 大型移动互联网应用基本上都是使用Kafka来处理系统中积累的日志数据。
阿里巴巴集团内部有大量应用在使用，每天产生海量消息，并已成功支持多个天猫双十一群发消息测试。 是数据削峰填谷的有力工具。
2. 关于使用
对于Java编程来说，开源社区提供的API基本上已经帮我们实现了生产和消费的逻辑。 我们只需要对官方API进行简单的开发即可使用。 比如消息生产和消费、批量生产和消费、拉取和监听模式、顺序消费等常见使用场景。 由于内容较多，建议您阅读官方API。
另外，系统部门集成的cmos-msg工具jar包，基于官方API对生产者和消费者进行了集成和封装。 包括单个和批量消息生产者。 以及拉取、监控等各种场景，以及顺序消费连接到任意官方服务器失败，非常容易直接集成到boot项目中。 建议您详细阅读cmos-msg帮助文档。
以上内容是根据查询相关资料并整理而成。 这不是我的原创作品。 感谢csdn提供支持，地址如下。
热门手游排行榜
