当前位置：首页 > news >正文

电商网站设计模板dw/网络促销

news 文章来源：https://blog.csdn.net/u014534808/article/details/133828240 2025/3/11 8:54:09

电商网站设计模板dw,网络促销,雷州网站,o2o网站建设要多少钱您好，我是码农飞哥（wei158556），感谢您阅读本文，欢迎一键三连哦。 💪🏻 1. Python基础专栏，基础知识一网打尽，9.9元买不了吃亏，买不了上当。 Python从入门到精…

您好，我是码农飞哥（wei158556），感谢您阅读本文，欢迎一键三连哦。
💪🏻 1. Python基础专栏，基础知识一网打尽，9.9元买不了吃亏，买不了上当。 Python从入门到精通
😁 2. 毕业设计专栏，毕业季咱们不慌忙，几百款毕业设计等你选。
❤️ 3. Python爬虫专栏，系统性的学习爬虫的知识点。9.9元买不了吃亏，买不了上当。python爬虫入门进阶
❤️ 4. Ceph实战，从原理到实战应有尽有。 Ceph实战
❤️ 5. Java高并发编程入门，打卡学习Java高并发。 Java高并发编程入门

文章目录

- 1、消息队列
- 2、消息队列的应用场景
- 3、RocketMQ的简介
- 4、各类MQ的对比
- 5、RocketMQ的技术架构
- 6、RockerMQ领域模型
- - 1. 消息生产
  - 2. 消息存储
  - 3. 消息消费
- 参考

1、消息队列

消息队列（Message Queue，下面简称MQ）是一种用于分布式系统中各节点之间进行消息传输的，独立于平台的软件系统。如果把分布式系统中的各个节点比喻成商家和顾客的话，那么消息中间件就是快递公司。商家（生产者）将快递（消息）投递给快递公司，快递公司负责运送快递给顾客（消费者）。那么在分布式系统架构中为啥要用消息中间件呢？

2、消息队列的应用场景

消息队列在分布式系统中主要用于异步解耦，流量削峰等场景。就以订单流程为例。没有使用消息队列的情况下，用户下单，需要订单系统调用商品系统扣减库存，调用积分系统发放积分，调用优惠券系统抵扣优惠券。这几个系统都与订单系统耦合在一块了。任意一个系统的失败都可能导致下单失败。

使用消息队列之后，订单系统只需要发送一条消息，商品系统，积分系统，优惠券系统直接订阅订单系统发送的消息即可。

3、RocketMQ的简介

RocketMQ是阿里巴巴开源的一款消息队列，它具有低延迟，高吞吐量，高可靠性等特点。目前，RocketMQ在阿里巴巴内部有着广泛的应用，经历多次双十一的洗礼，RocketMQ的可靠性非常高。

4、各类MQ的对比

目前市面上常用的MQ有: kafka, RabbitMQ,RocketMQ,ActiveMQ。这四种MQ的主要对比如下图所示：

名称	RabbitMQ	ActiveMQ	RocketMQ	kafka
开发语言	Erlang	Java	Java	Scala&Java
客户端支持语言	支持，JAVA优先	语言无关	只支持JAVA	支持，JAVA优先
单机吞吐量	其次(万级)	最差（万级）	最高（十万级）	次之（十万级）
消息延迟	微秒级	\	比kafka快	毫秒级
数据可靠性	可以保证数据不丢失，有slave用作备份	master/slave	支持异步实时刷盘，同步刷盘，同步复制，异步复制	数据可靠，并且有副本机制，有容错容灾能力
HA	master/slave模式，master提供服务，slave仅作备份	基于Zookeeper+LevelDB的Master-Slave实现方式	支持多Master模式，多Master多Slave模式，异步复制模式，	支持replica机制，leader宕机后，备份自动顶替，并重新选举leader（基于zookeeper）
消息推拉模式	多协议，Pull/Push均有支持	多协议，Pull/Push均有支持	多协议，Pull/Push均有支持	Pull
成熟度	成熟	成熟	比较成熟	成熟
特点
支持协议	多协议支持：AMQP,XMPP,SMTP,STOMP		自有协议	自有协议，社区封装了HTTP协议支持
持久化	内存，文件，支持数据堆积，但数据堆积会影响生产速率	内存，文件，数据库	磁盘文件	磁盘文件，只要做到
事务	不支持	支持	支持	不支持，但可以通过Low Level API保证只消费一次
负载均衡	支持	支持	支持	支持
集群	支持	支持	支持	支持
评价	优点：由于Erlang语言的特性，mq性能较好，管理界面丰富，在互联网公司也有大规模应用；支持amqp。缺点：erlang语言难度较大，集群不支持动态扩展。	优点：成熟的产品，已经在很多公司得到应用。缺点：社区不活跃，会出现莫名其妙的问题，且会丢失消息	优点：模型简单。在阿里大规模应用，单日处理消息上百亿。

综上所述：

早期的话ActiveMQ使用比较多，但是ActiveMQ没有经历过大吞吐量场景的验证，且可能会丢失消息，社区也不活跃，现在应用的比较少了。

RabbitMQ 得益于其活跃的开源社区以及高可用性被不少公司应用。但是Erlang语言阻止了大量的java开发工程师去深入研究和掌握它，对公司而言，几乎处于不可控的状态。

RocketMQ 作为经历过双十一大吞吐量场景的考验，Java语言开发的消息队列，现在被越来越多的公司采用。RocketMQ也已经捐给了Apache 基金会，社区较为活跃。

kafka主要应用于日志收集场景。

如果系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，需要低延迟和高稳定性，建议使用 RocketMQ。

如果需要处理海量的消息，像收集日志、监控信息或是埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，那 Kafka 是最适合的消息队列。

5、RocketMQ的技术架构

RockerMQ架构上主要分为四部分，如上图所示：

Producer: 消息生产者角色，支持分布式集群部署，主要用于发送消息，通常集成于业务系统。它相当于是发信者。
Consumer: 消息消费者角色，支持分布式集群部署，支持以push推，pull拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费，通常集成于业务系统。它相当于收信者。
Broker: 主要负责消息的存储、投递和查询以及服务高可用保证。它相当于是邮局其内部包含以下几个重要子模块。

4.1. Remoting Module: 整个Broker的实体，负责处理来自Clients端的请求。

4.2. Client Manager: 负责管理客户端（Producer/Consumer）和维护Topic订阅信息。

4.3. Store Service: 提供方便简单的API接口处理消息存储到物理磁盘和查询功能。
NameServer: 它是Broker的注册中心，支持Broker的动态注册与发现。它主要包括两个功能：Broker管理，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的提供者。然后提供心跳检测机制，检查Broker是否存活；路由信息管理，每个NameServer通常也是集群方式部署，各实例互不进行通信，Broker向每一台NameServer注册自己的路由信息， 所以，每一个NameServer实例上面都保存一份完整的路由信息，当某个NameServer因某种原因下线了，Broker仍然可以向其他NameServer同步其路由信息。NameServer是无状态的。

6、RockerMQ领域模型

如上图所示，RocketMQ中消息的生命周期主要分为消息生产、消息存储、消息消费这三部分。

生产者生产消息并发送到RocketMQ服务端，消息被存储到服务端的主题中，消费者通过订阅主题消费消息。

1. 消息生产

生产者（Producer）：用于产生消息的运行实体，一般集成于业务调用链路的上游。生产者是轻量级匿名无身份的。

2. 消息存储

主题（Topic）:

RocketMQ 消息传输和存储的分组容器，主题内部由多个队列组成，消息的存储和水平扩展实际是通过主题内的队列实现的。
队列（MessageQueue）:

RocketMQ 消息传输和存储的实际单元容器，类比于其他消息队列中的分区。RocketMQ 通过流式特性的无限队列结构来存储消息，消息在队列内具有顺序存储特性。
消息（Message）:

RocketMQ 的最小传输单元，消息具备不可变性，在初始化发送和完成存储后即不可变。

3. 消息消费

消费者分组（ConsumerGroup）:

RocketMQ发布订阅模型中定义的独立的消费身份分组。用于统一管理底层运行的多个消费者（Consumer）。同一个消费者组的多个消费者必须保持消费逻辑和配置一致，共同分担该消费者组订阅的消息，实现消费能力的水平扩展。
消费者（Consumer）:

RocketMQ 消费消息的运行实体，一般集成在业务调用链路的下游。消费者必须指定到某一个消费者组中。
订阅关系（Subscription）:

RocketMQ 发布订阅模型中消息过滤、重试、消费进度的规则配置。订阅关系以消费组粒度进行管理，消费组通过定义订阅关系控制指定消费组下的消费者如何实现消息过滤、消费重试及消费进度恢复等。RocketMQ 的订阅关系除过滤表达式之外都是持久化的，即服务端重启或请求断开，订阅关系依然保留。

参考

领域模型概述

千锋教育RocketMQ全套视频教程，快速掌握MQ消息中间件