分布式系统架构设计之分布式消息队列架构解析

分布式消息队列架构是构建在分布式系统之上的消息队列架构,旨在提高高性能、高可用性和可伸缩性。它包括以下架构相关部分:

1、架构优势

分布式消息队列架构的优势主要体现在以下几个方面:

01 高可用性

在分布式消息队列架构中,消息队列服务通常部署在多个节点上,每个节点都可以独立处理消息。这种设计方式确保了系统的高可用性,当某个节点发生故障时,其他节点可以继续提供服务,不会导致整体服务中断,同时,通过多副本和容错机制,可以进一步提高系统的可用性,确保消息的可靠传输和处理。

02 水平扩展性

分布式消息队列架构具有优秀的水平扩展性,随着业务量的增长,可以通过增加处理节点的方式来提高系统的处理能力。这种扩展方式是线性的,可以根据实际需求灵活调整,相比传统的单体应用,分布式架构更容易实现扩展,且扩展成本更低。

03 数据安全性

分布式消息队列架构通过数据持久化和复制机制确保数据的安全性,消息在传输过程中会被加密和校验,确保数据的完整性和准确性,同时,在多个节点上存储消息的副本,可以防止数据丢失和损坏,这种设计方式可以提高系统的可靠性和稳定性。

04 高性能

分布式架构可以利用多个节点的并行处理能力来提高系统的整体性能。通过负载均衡技术,可以将消息均匀地分发到各个处理节点上,避免单点过载。同时,分布式架构还可以利用缓存、异步处理等技术进一步提高性能。

05 灵活性

分布式消息队列架构通常提供丰富的 API 和配置选项,方便开发者根据实际需求进行定制和扩展。同时,分布式架构还支持多种消息传递模式(如点对点模式、发布-订阅模式等),可以满足不同场景下的需求。

06 可维护性

分布式架构通常配备完善的监控和运维工具,用于实时监控性能指标、识别潜在问题以及进行必要的调优。这些工具可以帮助开发者及时发现并解决问题,提高系统的可维护性和稳定性。

综上所述,分布式消息队列架构具有高可用性、水平扩展性、数据安全性、高性能、灵活性和可维护性等优势。这些优势使得分布式消息队列成为构建高可靠、高性能、高可扩展性系统的关键组件之一。

2、角色与组件

在分布式消息队列架构中,主要涉及以下几个角色和组件:

01 生产者 Producer

主要负责生成并发送消息到消息队列。这些消息可以是各种类型的数据,如文本、二进制数据、JSON对象等。

生产者与消息队列服务器建立连接,并通过特定的协议或 API 将消息发送到目标队列。发送完成后,生产者通常会收到一个确认消息,表示消息已成功被队列接收。

02 消费者 Consumer

从消息队列中读取并处理消息。消费者可以是一个独立的应用程序或服务,也可以是另一个消息队列的生产者。

消费者与消息队列服务器建立连接,并监听特定的队列。当有新消息到达时,消费者会拉取或接收这些消息,并进行相应的业务逻辑处理。处理完成后,消费者会发送一个确认消息给服务器,告知该消息已被成功消费。

03 代理节点 Broker

负责消息的存储、转发和管理。代理节点是分布式消息队列架构中的核心组件,它维护着消息队列的状态并保证消息的可靠传输。

消息可以存储在代理节点的内存中,也可以持久化到磁盘上。持久化存储可以确保在服务器重启或故障时,消息不会丢失。

代理节点根据特定的策略(如轮询、最少连接等)将消息转发给消费者。同时,为了确保消息的可靠传输,代理节点通常会实现消息的确认和重试机制。

04 主题 Topic 和队列 Queue

它们是消息的逻辑分类单位。生产者将消息发送到特定的主题或队列中,而消费者则从感兴趣的主题或队列中读取消息。

在发布-订阅模式中,主题用于定义消息的类别,而队列则是消息的具体存储位置。在点对点模式中,通常只使用队列来存储和传递消息。

05 其他辅助组件
  • 负载均衡器:用于将生产者和消费者的请求均匀地分发到各个代理节点上,避免单点过载。
  • 监控与运维工具:提供实时的性能指标、日志分析和报警功能,帮助运维人员及时发现并解决问题。
  • API 网关:为外部应用提供统一的访问接口,实现权限控制、流量管理等功能。

这些角色和组件共同构成了分布式消息队列架构的基础框架,通过它们之间的协作和通信,实现了高性能、高可用性和可伸缩性的消息处理服务。

3、消息传递模式

消息传递模式在分布式消息队列中起到核心作用,主要有以下两种

01 点对点模式

基本原理:在点对点消息系统中,消息被持久化到一个特定的队列中。这意味着将有一个或多个消费者从该队列中消费数据。然而,每条消息只能被消费一次,即一旦某个消费者成功消费了队列中的某条消息,该消息将从队列中删除,其他消费者无法再次消费该消息。

特点:此模式确保了消息的可靠传输和处理的顺序性。生产者发送一条消息到队列,只有一个消费者能收到。这种模式在多个消费者之间实现了可靠的负载均衡。

适用场景:当需要确保每个消息都被精确处理一次,并且处理顺序至关重要时,点对点模式非常适用。

02 发布-订阅模式

基本原理:在发布-订阅消息传递模式中,消息被持久化到一个被称为topic的主题中。与点对点模式不同,消费者可以订阅一个或者多个topic,并消费该topic中所有的数据。重要的是,同一条数据可以被多个消费者消费,数据消费后不会立马删除。

角色:在这种模式下,消息的生产者被称为发布者(Publisher),而消息的消费者被称为订阅者(Subscriber)。只有订阅了特定topic的订阅者才会收到发布者发送到该topic的消息。

特点:发布-订阅模式允许消息的广播式传输,即一个消息可以被发送到多个消费者。此外,它也支持消息的过滤,订阅者可以基于特定的规则或条件来接收他们感兴趣的消息。

适用场景:当需要将消息发送给多个接收者,或者需要根据特定的条件过滤消息时,发布-订阅模式非常有用。它适用于实现实时通知、新闻馈送等应用场景。
 

总得来说,点对点模式和发布-订阅模式是分布式消息队列中的两种主要消息传递模式。它们各自具有不同的特点和适用场景,架构师们可以根据具体需求选择适当的模式来实现高效、可靠的消息传递和处理。

4、关键技术

这里我会介绍在分布式消息队列架构中的三个关键技术:

01 分区
  • 原理:分区是将大的数据集或消息流拆分成多个小的、更易于管理的部分,每个部分称为一个分区。每个分区在物理上独立于其他分区,可以单独处理和存储。
  • 优势:通过分区,可以提高消息处理的并行度,从而提升整体吞吐量。此外,分区还可以用于实现数据的局部性,优化存储和访问性能。
  • 实现:通常,分布式消息队列系统会允许用户指定分区的数量,并在多个代理节点之间均匀分配这些分区。生产者发送消息时会指定一个分区键,系统根据该键将消息路由到特定的分区。
02 副本
  • 原理:副本技术用于在多个节点上创建和维护数据的冗余副本,以提高系统的可用性和持久性。当某个节点发生故障时,其他节点上的副本可以用于恢复数据,确保服务的连续性。
  • 优势:副本不仅可以防止数据丢失,还可以提高系统的容错能力。此外,通过读取副本,还可以分担单个节点的读取负载,提升系统的扩展性。
  • 实现:分布式消息队列系统通常会在多个代理节点上维护消息的副本。这些副本之间通过复制协议保持同步,确保数据的一致性。常见的复制协议包括主从复制和多点复制。
03 负载均衡
  • 原理:负载均衡用于将工作负载均匀地分发到多个处理节点上,以防止某个节点过载而其他节点空闲。通过负载均衡,可以充分利用系统资源,提高整体性能和吞吐量。
  • 优势:负载均衡可以确保系统的可扩展性和高可用性。当某个节点发生故障时,负载均衡器可以将流量重定向到其他健康的节点上,确保服务的连续性。
  • 实现:在分布式消息队列系统中,负载均衡可以通过多种方式实现,例如使用专门的负载均衡器设备或软件、采用轮询、最少连接等算法进行动态分配。

这些关键技术是构建高效、可靠的分布式消息队列系统的基石。通过合理地运用这些技术,可以确保系统在处理大量消息时保持高性能、高可用性和可伸缩性。

5、一致性和可靠性保证

01 一致性保证
  • 事务一致性:确保消息的发送与业务操作的原子性。通过使用事务,可以确保业务操作与消息发送要么都成功,要么都失败。例如,在执行数据库操作后发送消息时,如果数据库操作成功但消息发送失败,则会回滚数据库操作以确保一致性。
  • 消息确认和重试:当消费者处理消息失败时,分布式消息队列会提供重试机制。消息可以被重新投递给消费者,直到达到预定的重试次数或消息过期。这确保了在短暂的网络故障或消费者处理错误时,消息不会被丢失。
02 可靠性保证
  • 持久性存储:为了确保消息的可靠性,分布式消息队列通常会将消息持久化存储到磁盘或其他持久化介质中。这意味着即使服务器崩溃或重启,消息也不会丢失,可以从持久化存储中恢复。
  • 副本与复制:通过在多个节点上创建和维护消息的副本,分布式消息队列提供了高可用性和数据冗余。当某个节点发生故障时,其他节点上的副本可以用于恢复数据,确保服务的连续性。
  • 消息顺序保证:对于需要保证消息顺序的场景,分布式消息队列提供了消息顺序性的保证。这通常通过在单个分区内保证消息的顺序来实现,消费者在处理消息时会按照发送顺序进行处理。
03 消息处理保证级别

分布式消息队列还提供了不同的消息处理保证级别:

  • At Least Once(至少一次):确保每条消息至少被处理一次,但可能导致重复处理。需要消费者端实现幂等性处理。
  • At Most Once(最多一次):保证消息不会被重复处理,但可能丢失。在分布式环境中难以实现完美的保证。
  • Exactly Once(恰好一次):确保每条消息只被处理一次,既不丢失也不重复。这是最理想的级别,但实现起来最为复杂,通常需要事务和其他技术的支持。

综上所述,分布式消息队列通过结合持久化、副本、事务、确认与重试机制以及不同的处理保证级别,确保了消息传递的一致性和可靠性。选择哪种保证级别取决于应用的业务需求和对数据一致性的要求。

6、容错与恢复

在分布式消息队列架构中,容错与恢复是确保系统高可用性和可靠性的关键组成部分。

01 容错机制
  • 冗余设计:分布式消息队列通常采用冗余设计来提高系统的容错能力。这包括在多个节点上复制消息和元数据,以确保在单个节点或组件发生故障时,系统能够继续运行。
  • 故障检测与隔离:系统具备故障检测机制,能够实时监测节点的健康状况。一旦检测到故障节点,系统会将其隔离,以防止故障扩散到整个集群。
  • 消息持久化:为确保消息的可靠性,分布式消息队列会将消息持久化到磁盘或其他持久化存储介质中。即使系统发生故障或重启,持久化的消息也可以被恢复并重新处理。
02 恢复机制
  • 故障转移:当某个节点发生故障时,分布式消息队列会自动将流量和服务转移到其他健康节点上。这确保了系统的连续性和可用性。
  • 数据恢复:如果发生故障的节点包含重要的数据,系统会启动数据恢复流程。这可能涉及从备份节点或其他持久化存储中恢复数据,以确保数据的完整性和一致性。
  • 重试与死信处理:对于处理失败的消息,分布式消息队列提供了重试机制。消息可以被重新投递给消费者进行处理,直到达到预定的重试次数或消息过期。对于无法处理的消息,系统会将其标记为死信,并提供相应的处理机制,如通知管理员或将其存储到死信队列中进行后续处理。

总的来说,分布式消息队列架构通过冗余设计、故障检测与隔离、消息持久化、故障转移、数据恢复以及重试与死信处理等机制来实现容错与恢复。这些机制确保了系统在面临故障时能够保持高可用性和数据的可靠性,从而满足了分布式系统中对数据一致性和服务连续性的要求。

7、消息的持久化

在分布式消息队列架构中,消息的持久化是确保数据可靠性和一致性的关键特性之一。

01 消息持久化的重要性
  • 数据安全性:持久化可以确保即使在系统崩溃、重启或节点故障的情况下,消息也不会丢失。
  • 可靠的消息传递:对于需要保证消息可靠传递的应用,持久化是不可或缺的。
  • 恢复能力:如果系统出现问题,可以从持久化存储中恢复消息,避免数据丢失。
02 消息持久化的方式
  • 磁盘存储:最常见的持久化方式是将消息写入磁盘。这可以通过使用高性能的日志结构存储、数据库或其他文件存储技术来实现。
  • 分布式存储:在分布式环境中,消息可能会被复制到多个节点上,确保即使某些节点发生故障,消息仍然可以从其他节点上恢复。
  • 内存与磁盘结合:为了提高性能,一些系统可能会首先将消息写入内存,然后再异步地持久化到磁盘。这种方式提供了高性能的消息处理,同时也确保了消息的持久性。
03 权衡持久化和性能
  • 写入延迟:持久化到磁盘通常比写入内存要慢。因此,系统需要权衡持久性与性能之间的关系。
  • I/O压力:高频率的磁盘写入可能会导致I/O成为瓶颈。因此,优化磁盘I/O、使用高性能的存储设备或采用批量写入策略是提高性能的关键。
  • 数据压缩与加密:为了节省存储空间或提高数据安全性,系统可能会对持久化的消息进行压缩或加密。但这些操作可能会增加CPU的负担并降低性能。
04 持久化的保证级别
  • 同步持久化:每条消息在确认被成功持久化之前,都不会被认为是“已发送”或“已处理”。这种方式提供了最强的持久性保证,但可能会降低吞吐量。
  • 异步持久化:消息首先被确认,然后在后台异步地持久化。这种方式提高了吞吐量,但在极端情况下(如突然的系统崩溃)可能存在数据丢失的风险。
05 恢复策略
  • 从最近的备份恢复:系统定期创建持久化消息的备份,并在需要时从这些备份中恢复。
  • 从其他节点复制:在分布式环境中,可以从其他包含消息副本的节点中恢复数据。
  • 点恢复:某些系统允许恢复到特定的时间点,这对于解决因错误操作导致的数据问题非常有用。

总的来说,消息的持久性是分布式消息队列架构中的一个核心组件,它确保了即使在面临故障或错误时,消息也能被安全地存储和恢复。

8、消息的重复消费

在分布式消息队列架构中,消息的重复消费是一个常见且需要关注的问题。

01 为什么会出现消息重复消费?
  • 网络不稳定:在分布式环境中,网络的不稳定性可能导致消息传递的失败。当消费者未能成功确认消息处理时,消息队列可能会重新投递该消息,从而导致重复消费。
  • 消费者处理失败:如果消费者在处理消息时发生错误或崩溃,它可能没有向消息队列发送确认信号。队列因此会重新投递这条消息,期望消费者能够再次处理。
  • 重试机制:为了提高消息的可靠性,分布式消息队列通常会实现重试机制。当消费者处理消息失败时,队列会在一段时间后重试,这也可能导致消息的重复消费。
02 如何解决消息重复消费的问题?
  • 幂等性处理:确保消费者处理消息的操作是幂等的,即多次执行相同的操作不会产生不同的结果。这样,即使消息被重复消费,也不会对系统造成不良影响。
  • 全局唯一ID:为每条消息分配一个全局唯一的ID。消费者在接收到消息后,首先检查该ID是否已经被处理过。如果已处理,则直接忽略该消息;否则,进行处理并记录ID。
  • 使用事务:将消息的接收和处理放在同一个事务中。如果处理失败,可以回滚事务,避免消息的确认和重复消费。
  • 死信队列:当消息被重复消费超过一定次数后,可以将其移入死信队列。这可以防止消息无休止地被重复处理,同时也为开发者提供了一个查看和处理这些“问题”消息的地方。
03 权衡考虑
  • 性能与一致性的权衡:为了避免消息的重复消费,可能会采取一些措施如数据库锁、分布式锁等,这些可能会影响系统的性能。因此,需要根据业务需求和系统负载来权衡性能与一致性。
  • 监控与告警:建立完善的监控机制,当检测到消息的重复消费时,能够迅速发出告警并通知开发者介入处理。

消息的重复消费是分布式消息队列中的一个挑战。通过合理的设计和采取适当的措施,可以有效地减少或避免这一问题对系统造成的不良影响。

9、监控与运维

在分布式消息队列架构中,监控与运维是确保系统稳定性、性能和可靠性的关键环节。

01 监控的重要性
  • 实时掌握系统状态:通过监控,运维人员可以实时了解系统的运行状态、资源使用情况以及潜在的问题。
  • 预防与定位故障:通过对系统各项指标的监控,可以提前发现潜在的故障点,或在故障发生时迅速定位问题。
  • 优化性能:通过对系统性能的持续监控,可以发现性能瓶颈,进而进行针对性的优化。
02 监控的层次

分布式消息队列的监控通常包括以下几个层次:

  • 基础层监控:主要关注主机和底层资源的状态,如CPU、内存、网络吞吐、硬盘I/O和硬盘使用等。
  • 中间件层监控:对消息队列所使用的中间件进行监控,如Nginx、Redis、Kafka等,了解它们的性能、连接数和错误率等关键指标。
  • 应用层监控:关注消息队列自身的运行状态和性能指标,如队列长度、消息速率、消费者连接数、消息延迟等。
03 运维的职责与挑战
  • 系统部署与配置:负责消息队列系统的部署、配置和更新,确保系统在不同环境下的稳定性和可用性。
  • 故障处理与恢复:在系统出现故障时,迅速定位并解决问题,同时制定和执行故障恢复计划。
  • 性能调优:根据监控数据分析系统的性能瓶颈,进行针对性的优化,提高系统的吞吐量和响应速度。
  • 容量规划:预测系统的未来负载,提前规划并扩展所需的硬件和软件资源。
04 自动化运维与工具支持

为了提高运维效率和准确性,分布式消息队列架构通常会采用自动化运维工具,如 Ansible、Chef、Puppet 等。这些工具可以帮助实现系统的自动化部署、配置管理、故障恢复和性能调优等功能。

05 最佳实践
  • 建立完善的监控体系:覆盖系统的各个层次和关键组件,确保无死角监控。
  • 设定合理的告警阈值:避免告警泛滥或漏报,确保运维人员能够及时响应和处理问题。
  • 定期审查监控数据和日志:主动发现潜在问题,进行预防性维护。
  • 持续学习和掌握新技术:跟随技术和工具的发展,不断提升运维能力和效率。

总的来说,分布式消息队列架构中的监控与运维是一个综合性强、技术要求高的领域。通过完善的监控体系、专业的运维团队和先进的自动化工具,可以确保消息队列系统的稳定、高效运行。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/607036.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

ARM架构—— Cortex-M3与Cortex-M4特点概述

一、Cortex-M3与Cortex-M4异同点 相同点: 基于ARM-v7-M架构。三级流水线设计。哈佛总线架构,统一的存储器空间:指令和地址总线使用相同的地址空间。32位寻址,支持4GB 存储空间。基于ARM AMBA(高级微控制器总线架构&a…

在docker上运行LCM

目录 1.加载镜像并进入容器 2.安装依赖 3.在docker外部git-clone lcm 4.将get-clone的lcm复制到容器中 5.编译库 6.将可执行文件复制到容器中 7.进入可执行文件 8.编译可执行文件 9.再开一个终端运行程序 10.将以上容器打成镜像并导出 1.加载镜像并进入容器 sudo do…

基于多反应堆的高并发服务器【C/C++/Reactor】(中)在TcpConnection 中接收并解析Http请求消息

一、在TcpConnection 中多添加和http协议相关的request和response struct TcpConnection {struct EventLoop* evLoop;struct Channel* channel;struct Buffer* readBuf;struct Buffer* writeBuf;char name[32];// http协议struct HttpRequest* request;struct HttpResponse* r…

LabVIEW在旋转机械故障诊断中的随机共振增强应用

在现代工业自动化领域,准确的故障诊断对于保障机械设备的稳定运行至关重要。传统的故障检测方法往往因噪声干扰而难以捕捉到微弱的故障信号。随着LabVIEW在数据处理和系统集成方面的优势日益凸显,其在旋转机械故障诊断中的应用开始发挥重要作用&#xff…

Spring学习 Spring整合MyBatis

6.1.创建工程 6.1.1.pom.xml <?xml version"1.0" encoding"UTF-8"?> <project xmlns"http://maven.apache.org/POM/4.0.0"xmlns:xsi"http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation"http://maven.ap…

20240108移远的4G模块EC20在Firefly的AIO-3399J开发板的Android11下调通的步骤

20240108移远的4G模块EC20在Firefly的AIO-3399J开发板的Android11下调通的步骤 2024/1/8 17:50 缘起&#xff1a;使用友善之臂的Android11可以让EC20上网&#xff0c;但是同样的修改步骤&#xff0c;Toybrick的Android11不能让EC20上网。最后确认是selinux的问题&#xff01; …

Linux文件系统与日志分析

目录 一、Linux文件系统 1、inode与block 2、查看inode号码的命令 3、inode包含文件的元信息 4、Linux系统文件的三个主要时间属性 5、用户通过文件名打开文件时系统内部过程 6、inode的大小 7、inode的特点 二、日志 1、日志的功能 2、日志文件的分类 3、系统日志…

解锁前端新潜能:如何使用 Rust 锈化前端工具链

前言 近年来&#xff0c;Rust的受欢迎程度不断上升。首先&#xff0c;在操作系统领域&#xff0c;Rust 已成为 Linux 内核官方认可的开发语言之一&#xff0c;Windows 也宣布将使用 Rust 来重写内核&#xff0c;并重写部分驱动程序。此外&#xff0c;国内手机厂商 Vivo 也宣布…

语言栏中的半角和全角

语言栏中的半角和全角 1. 语言栏2. Halfwidth and fullwidth forms3. Monospaced fontReferences 1. 语言栏 任务栏设置 时间和语言 输入 高级键盘设置 文本服务和输入语言 2. Halfwidth and fullwidth forms 半角和全角&#xff0c;别名半形和全形。 In CJK (Chinese, Japa…

sentinel入门,转载的,不记得在哪复制的了

sentinel 基本概念 开发的原因&#xff0c;需要对吞吐量&#xff08;TPS&#xff09;、QPS、并发数、响应时间&#xff08;RT&#xff09;几个概念做下了解&#xff0c;查自百度百科&#xff0c;记录如下&#xff1a; 响应时间(RT)   响应时间是指系统对请求作出响应的时间。…

基于多反应堆的高并发服务器【C/C++/Reactor】(中)HttpResponse的定义和初始化 以及组织 HttpResponse 响应消息

一、HttpResponse的定义 1.定义状态码枚举 // 定义状态码枚举 enum HttpStatusCode {Unknown 0,OK 200,MovedPermanently 301,MovedTemporarily 302,BadRequest 400,NotFound 404 }; 2.HTTP 响应报文格式 这个数据块主要是分为四部分 第一部分是状态行第二部分是响应…

Hyperledger Fabric 管理链码 peer lifecycle chaincode 指令使用

链上代码&#xff08;Chaincode&#xff09;简称链码&#xff0c;包括系统链码和用户链码。系统链码&#xff08;System Chaincode&#xff09;指的是 Fabric Peer 中负责系统配置、查询、背书、验证等平台功能的代码逻辑&#xff0c;运行在 Peer 进程内&#xff0c;将在第 14 …

基于多反应堆的高并发服务器【C/C++/Reactor】(中)HttpRequest模块 解析http请求协议

一、HTTP响应报文格式 HTTP/1.1 200 OK Bdpagetype: 1 Bdqid: 0xf3c9743300024ee4 Cache-Control: private Connection: keep-alive Content-Encoding: gzip Content-Type: text/html;charsetutf-8 Date: Fri, 26 Feb 2021 08:44:35 GMT Expires: Fri, 26 Feb 2021 08:44:35 GM…

今日实践 — 附加数据库/重定向失败如何解决?

WMS数据库与重定向 前言正文如何建立数据库连接&#xff1f;第一步&#xff1a;打开SSMS&#xff0c;右击数据库&#xff0c;点击附加第二步&#xff1a;点击添加第三步&#xff1a;找到自己的数据库文件&#xff0c;点击确定按钮第四步&#xff1a;若有多个数据库&#xff0c;…

如何使用静态IP代理解决Facebook多账号注册并进行网络推广业务?

在当今的数字时代&#xff0c;社交媒体成为了企业进行网络推广的一个重要途径&#xff0c;其中&#xff0c;Facebook是最受欢迎的社交媒体之一&#xff0c;因为它可以让企业通过创建广告和页面来推广他们的产品或服务。 但是&#xff0c;使用Facebook进行网络推广时&#xff0…

【代码复现系列】paper:CycleGAN and pix2pix in PyTorch

或许有冗余步骤、之后再优化。 1.桌面右键-git bash-输入命令如下【git clone https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix】 2.打开anaconda的prompt&#xff0c;cd到pytorch-CycleGAN-and-pix2pix路径 3.在prompt里输入【conda env create -f environment.y…

基于YOLOv7开发构建道路交通场景下CCTSDB2021交通标识检测识别系统

交通标志检测是交通标志识别系统中的一项重要任务。与其他国家的交通标志相比&#xff0c;中国的交通标志有其独特的特点。卷积神经网络&#xff08;CNN&#xff09;在计算机视觉任务中取得了突破性进展&#xff0c;在交通标志分类方面取得了巨大的成功。CCTSDB 数据集是由长沙…

OpenFeign超时控制

OpenFeign超时控制 前面简单介绍了Feign和OpenFeign的关系&#xff0c;言归正传&#xff0c;接下来我们看看OpenFeign如何设置调用超时&#xff0c;openFeign其实是有默认的超时时间的&#xff0c;默认分别是连接超时时间10秒、读超时时间60秒&#xff0c;源码在feign.Request…

十九:爬虫最终篇-平安银行商城实战

平安银行商场实战 需求 获取该商城商品信息 目标网址 https://m.yqb.com/bank/product-item-50301196.html?mcId1583912328849970&loginModepab&historyy&sceneModem&traceid30187_4dXJVel1iop详细步骤 1、寻找数据接口 2、对比payload寻找可疑参数 3、多…

图像融合论文阅读:CrossFuse: 一种基于交叉注意机制的红外与可见光图像融合方法

article{li2024crossfuse, title{CrossFuse: A novel cross attention mechanism based infrared and visible image fusion approach}, author{Li, Hui and Wu, Xiao-Jun}, journal{Information Fusion}, volume{103}, pages{102147}, year{2024}, publisher{Elsevier} } 论文…