RocketMQ一（基本概念+集群注意点）

最新推荐文章于 2024-09-18 23:05:36 发布
最新推荐文章于 2024-09-18 23:05:36 发布
阅读量636 收藏 2
点赞数 1
分类专栏： 消息队列 文章标签： rabbitmq java kafka
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lxsxkf/article/details/120222140
版权

1. 概述

MQ，Message Queue，是一种提供消息队列服务的中间件。MQ的用途：限流削峰、异步解耦、数据收集

1.1 基本概念

  1. 消息（Message）：生产和消费数据的最小单位，每条消息必须属于一个主题。
  2. 主题（Topic）：Topic表示一类消息的集合，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位。producer:topic 1:n consumer:topic 1:1
  3. 标签（Tag）：为消息设置的标签，用于同一主题下区分不同类型的消息。
  4. 队列（Queue）：存储消息的物理实体。一个Topic中可以包含多个Queue，每个Queue中存放的就是该Topic的消息。一个Topic的Queue中的消息只能被一个消费者组中的一个消费者消费。
  5. 消息标识（MessageId/Key）：RocketMQ中每个消息拥有唯一的MessageId，MessageId有两个：在生产者send()消息时会自动生成一个MessageId（msgId)，当消息到达Broker后，Broker也会自动生成一个MessageId(offsetMsgId)。
  • msgId：由producer端生成，其生成规则为：
    producerIp + 进程pid + MessageClientIDSetter类的ClassLoader的hashCode + 当前时间 + AutomicInteger自增计数器
  • offsetMsgId：由broker端生成，其生成规则为：
    brokerIp + 物理分区的offset（Queue中的偏移量）
  • key：由用户指定的业务相关的唯一标识

1.2 系统架构

在这里插入图片描述

1.2.1 Producer

  • 负责生产消息。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。
  • RocketMQ中的消息生产者都是以生产者组（Producer Group）的形式出现的。生产者组是同一类生产者的集合，这类Producer发送相同Topic类型的消息。一个生产者组可以同时发送多个主题的消息。

1.2.2 Consumer

  • 消息消费者，负责消费消息。一个消息消费者会从Broker服务器中获取到消息，并对消息进行相关业务处理。
  • RocketMQ中的消息消费者都是以消费者组（Consumer Group）的形式出现的。消费者组是同一类消费者的集合，这类Consumer消费的是同一个Topic类型的消息。消费者组使得在消息消费方面，实现负载均衡（将一个Topic中的不同的Queue平均分配给同一个Consumer Group的不同的Consumer）和容错的目标变得非常容易。
  • 在这里插入图片描述
  • 消费者组中Consumer的数量如果超出Queue数量，则多出的Consumer将不能消费消息。

1.2.3 Name Server

  • NameServer是一个Broker与Topic路由的注册中心，支持Broker的动态注册与发现。
  • Broker管理：接受Broker集群的注册信息并且保存下来作为路由信息的基本数据；提供心跳检测机制，检查Broker是否还存活。
  • 路由信息管理：每个NameServer中都保存着Broker集群的整个路由信息和用于客户端查询的队列信息。Producer和Conumser通过NameServer可以获取整个Broker集群的路由信息，从而进行消息的投递和消费。
  • 路由注册：NameServer是无状态的。在Broker节点启动时，轮询NameServer列表，与每个NameServer节点建立长连接，发起注册请求。在NameServer内部维护着⼀个Broker列表，用来动态存储Broker的信息。Broker节点以心跳包的方式上报给NameServer，每30秒发送一次心跳。心跳包中包含 BrokerId、Broker地址(IP+Port)、 Broker名称、Broker所属集群名称等等。NameServer在接收到心跳包后，会更新心跳时间戳，记录这个Broker的最新存活时间。
  • 路由剔除：NameServer没有收到Broker的心跳，NameServer可能会将其从Broker列表中剔除。NameServer中有⼀个定时任务，每隔10秒就会扫描⼀次Broker表，查看每一个Broker的最新心跳时间戳距离当前时间是否超过120秒，如果超过，则会判定Broker失效，然后将其从Broker列表中剔除。
  • 路由发现：RocketMQ的路由发现采用的是Pull模型。当Topic路由信息出现变化时，NameServer不会主动推送给客户端，而是客户端定时拉取主题最新的路由。默认客户端每30秒会拉取一次最新的路由。
  • 客户端NameServer选择策略： 客户端到底连接的是哪个NameServer节点呢？客户端首先会生产一个随机数，然后再与NameServer节点数量取模，此时得到的就是所要连接的节点索引，然后就会进行连接。如果连接失败，则会采用round-robin策略，逐个尝试着去连接其它节点。首先采用的是随机策略进行的选择，失败后采用的是轮询策略。

1.2.4 Broker

  • Broker充当着消息中转角色，负责存储消息、转发消息。Broker同时也存储着消息相关的元数据，包括消费者组消费进度偏移offset、主题、队列等。
  • 在这里插入图片描述
  • Remoting Module：整个Broker的实体，负责处理来自clients端的请求。
  • Client Manager：客户端管理器。负责接收、解析客户端(Producer/Consumer)请求，管理客户端。例如，维护Consumer的Topic订阅信息
  • Store Service：存储服务。提供方便简单的API接口，处理消息存储到物理硬盘和消息查询功能。
  • HA Service：高可用服务，提供Master Broker 和 Slave Broker之间的数据同步功能。
  • Index Service：索引服务。根据特定的Message key，对投递到Broker的消息进行索引服务，同时也提供根据Message Key对消息进行快速查询的功能。
  1. Broker的集群部署：
  2. Broker一般都是以集群形式出现的。Broker节点集群是一个主从集群，即集群中具有Master与Slave两种角色。Master负责处理读写操作请求，Slave负责对Master中的数据进行备份。当Master挂掉了，Slave则会自动切换为Master去工作。所以这个Broker集群是主备集群。 Master与Slave 的对应关系是通过指定相同的BrokerName、不同的BrokerId 来确定的。**BrokerId为0表 示Master，非0表示Slave。**每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。

1.3 工作流程

  1. 启动NameServer，NameServer启动后开始监听端口，等待Broker、Producer、Consumer连接。
  2. 启动Broker时，Broker会与所有的NameServer建立并保持长连接，然后每30秒向NameServer定时发送心跳包。
  3. 发送消息前，可以先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，当然，在创建Topic时也会将Topic与Broker的关系写入到NameServer中。不过，这步是可选的，也可以在发送消息时自动创建Topic。
  4. Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取路由信息，即当前发送的Topic消息的Queue与Broker的地址（IP+Port）的映射关系。然后根据算法策略从队选择一个Queue，与队列所在的Broker建立长连接从而向Broker发消息。当然，在获取到路由信息后，Producer会首先将路由信息缓存到本地，再每30秒从NameServer更新一次路由信息。
  5. Consumer跟其中一台NameServer建立长连接，获取其所订阅Topic的路由信息，然后根据算法策略从路由信息中获取到其所要消费的Queue，然后直接跟Broker建立长连接，开始消费其中的消息。Consumer在获取到路由信息后，同样也会每30秒从NameServer更新一次路由信息。不过不同于Producer的是，Consumer还会向Broker发送心跳，以确保Broker的存活状态。

1.4 Topic的创建模式

手动创建Topic时，有两种模式：

  • 集群模式：该模式下创建的Topic在该集群中，所有Broker中的Queue数量是相同的。
  • Broker模式：该模式下创建的Topic在该集群中，每个Broker中的Queue数量可以不同。
    自动创建Topic时，默认采用的是Broker模式，会为每个Broker默认创建4个Queue。

1.5 读/写队列

读/写队列从物理上来讲，读/写队列是同一个队列。所以，不存在读/写队列数据同步问题。读/写队列是逻辑上进行区分的概念。一般情况下，读/写队列数量是相同的。

  • 比如读队列设置4个，写队列数值8个。代表了 写队列的另外4个队列是不会被消费到的。
  • 其这样设计的目的是为了，方便Topic的Queue的缩容。

2 集群搭建理念

2.1 数据复制与刷盘策略

在这里插入图片描述

  1. 复制策略
  • 复制策略是Broker的Master与Slave间的数据同步方式。分为同步复制与异步复制：
  • 同步复制：消息写入master后，master会等待slave同步数据成功后才向producer返回成功ACK
  • 异步复制：消息写入master后，master立即向producer返回成功ACK，无需等待slave同步数据成功
  1. 刷盘策略
  • 刷盘策略指的是broker中消息的落盘方式，即消息发送到broker内存后消息持久化到磁盘的方式。分为同步刷盘与异步刷盘：
  • 同步刷盘：当消息持久化到broker的磁盘后才算是消息写入成功。
  • 异步刷盘：当消息写入到broker的内存后即表示消息写入成功，无需等待消息持久化到磁盘。

2.2 Broker 集群模式

  1. 单Master
    只有一个broker（其本质上就不能称为集群）。存在单点问题。

  2. 多Master
    broker集群仅由多个master构成，不存在Slave。同一Topic的各个Queue会平均分布在各个master节点上。

  • 优点：配置简单，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高；
  • 缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅（不可消费），消息实时性会受到影响。
  • 以上优点的前提是，这些Master都配置了RAID磁盘阵列。如果没有配置，一旦出现某Master宕机，则会发生大量消息丢失的情况。
  1. 多Master多Slave模式-异步复制
  • broker集群由多个master构成，每个master又配置了多个slave。master与slave的关系是主备关系，即master负责处理消息的读写请求，而slave仅负责消息的备份与master宕机后的角色切换。
    +当master宕机后slave能够自动切换为master。不过由于slave从master的同步具有短暂的延迟（毫秒级），所以当master宕机后，这种异步复制方式可能会存在少量消息的丢失问题。
  1. 多Master多Slave模式-同步双写
  • 所谓同步双写，指的是消息写入master成功后，master会等待slave同步数据成功后才向producer返回成功ACK，即master与slave都要写入成功后才会返回成功ACK，也即双写。
  • 该模式与异步复制模式相比，优点是消息的安全性更高，不存在消息丢失的情况。但单个消息的RT略高，从而导致性能要略低（大约低10%）。
  • 该模式存在一个大的问题：对于目前的版本，Master宕机后，Slave不会自动切换到Master。
  1. 最佳实践
  • 一般会为Master配置RAID10磁盘阵列，然后再为其配置一个Slave。即利用了RAID10磁盘阵列的高效、安全性，又解决了可能会影响订阅的问题。
    1）RAID磁盘阵列的效率要高于Master-Slave集群。因为RAID是硬件支持的。也正因为如此， 所以RAID阵列的搭建成本较高。
    2）多Master+RAID阵列，与多Master多Slave集群的区别是什么？
  • 多Master+RAID阵列，其仅仅可以保证数据不丢失，即不影响消息写入，但其可能会影响到 消息的订阅。但其执行效率要远高于多Master多Slave集群
  • 多Master多Slave集群，其不仅可以保证数据不丢失，也不会影响消息写入。其运行效率要低于多Master+RAID阵列

2.3、磁盘阵列RAID

RAID原来为廉价冗余磁盘阵列，现在是独立磁盘冗余阵列的意思。

2.4 关键技术

2.4.1 镜像技术

  • 镜像技术是一种冗余技术，为磁盘提供数据备份功能，防止磁盘发生故障而造成数据丢失。最典型地的用法就是，同时在磁盘阵列中产生两个完全相同的数据副本，并且分布在两个不同的磁盘上。镜像提供了完全的数据冗余能力，当一个数据副本失效不可用时，外部系统仍可正常访问另一副本。而且，镜像不需要额外的计算和校验，故障修复非常快，直接复制即可。镜像技术可以从多个副本进行并发读取数据，提供更高的读 I/O 性能，但不能并行写数据，写多个副本通常会导致一定的 I/O 性能下降。
  • 镜像技术提供了非常高的数据安全性，需要至少双倍的存储空间。高成本限制了镜像的广泛应用，主要应用于至关重要的数据保护，这种场合下的数据丢失可能会造成非常巨大的损失。

2.4.2 数据条带技术

数据条带化技术是一种自动将 I/O操作负载均衡到多个物理磁盘上的技术。更具体地说就是，将一块连续的数据分成很多小部分并把它们分别存储到不同磁盘上。这就能使多个进程可以并发访问数据的多个不同部分，从而获得最大程度上的 I/O 并行能力，极大地提升性能

2.4.3数据校验技术

数据校验技术是指， RAID 要在写入数据的同时进行校验计算，并将得到的校验数据存储在 RAID 成员磁盘中。校验数据可以集中保存在某个磁盘或分散存储在多个不同磁盘中。当其中一部分数据出错时，就可以对剩余数据和校验数据进行反校验计算重建丢失的数据。
数据校验技术相对于镜像技术的优势在于节省大量开销，但由于每次数据读写都要进行大量的校验运算，对计算机的运算速度要求很高，且必须使用硬件 RAID 控制器。在数据重建恢复方面，检验技术比镜像技术复杂得多且慢得多。

2.5 常见RAID等级详解

RAID0
在这里插入图片描述
RAID0 是一种简单的、无数据校验的数据条带化技术。

RAID1
在这里插入图片描述
RAID1 就是一种镜像技术。应用场景：对顺序读写性能要求较高，或对数据安全性要求较高的场景。

RAID10
在这里插入图片描述
RAID10是一个RAID1与RAID0的组合体，所以它继承了RAID0的快速和RAID1的安全。
简单来说就是，先做条带，再做镜像。发即将进来的数据先分散到不同的磁盘，再将磁盘中的数据做镜像。

RAID01
在这里插入图片描述
RAID01是一个RAID0与RAID1的组合体，所以它继承了RAID0的快速和RAID1的安全。
简单来说就是，先做镜像再做条带。即将进来的数据先做镜像，再将镜像数据写入到与之前数据不同的磁盘，即再做条带。

2.6 集群搭建注意点

  • master broker的配置文件
# 指定整个broker集群的名称，或者说是RocketMQ集群的名称 
brokerClusterName=DefaultCluster 
# 指定master-slave集群的名称。一个RocketMQ集群可以包含多个master-slave集群
 brokerName=broker-a
# master的brokerId为0 
brokerId=0
# 指定Name Server的地址 
namesrvAddr=192.168.59.164:9876;192.168.59.165:9876
  • slave的配置文件
brokerClusterName=DefaultCluster 
# 指定这是另外一个master-slave集群 
brokerName=broker-b 
# slave的brokerId为非0 
brokerId=1
安装搭建rocketmq集群
hjkl_uiop的博客
09-12 3914
下载地址：https://dlcdn.apache.org/rocketmq/4.9.1/ 下载后可以解压后通过工具上传到服务器。 部署需求（如果是两台机器，可以做一主一从，即broker-a主节点和nameserver在一台机器，broker-a-s从节点和console（rocketmq监控平台）在另一台机器） 在132机器mq目录下创建存储路径： mkdir store mkdir store/commitlog mkdir store/consumequeue mkdir store/index
全站最硬核 百万字强肝RocketMq源码 火热更新中~（一百零九）集群搭建理论
自救 唯有自强
02-21 289
文章目录集群搭建理论数据复制与刷盘策略复制策略刷盘策略Broker集群模式单Master多Master多Master多Slave模式-异步复制多Master多Slave模式-同步双写最佳实践 集群搭建理论 数据复制与刷盘策略 复制策略 复制策略是Broker的Master与Slave间的数据同步方式。分为同步复制与异步复制： 同步复制：消息写入master后，master会等待slave同步数据成功后才向producer返回成功ACK 异步复制：消息写入master后，master立即向producer
RocketMQ的组织架构和基本概念，Dledger高可用集群架构原理
qq_1149513559的博客
02-09 2088
文章目录1. MQ产品介绍2. rocketMQ组织架构①：NameServer②：Broker③：Producer**④：Consumer 1. MQ产品介绍          1.1 什么是MQ？为什么要用MQ？         MQ：MessageQueue，消息队列。 队列，是一种FIFO 先进先出的数据结构。消息由生产者发送到MQ进行排
RocketMQ实战与集群架构详解
最新发布
qq_45061342的博客
09-18 1552
RocketMQ是阿里巴巴开源的一个消息中间件，在阿里内部历经了双十一等很多高并发场景的考验，能够处理亿万级别的消息。2016年开源后捐赠给Apache，现在是Apache的一个顶级项目。 早期阿里使用ActiveMQ，但是，当消息开始逐渐增多后，ActiveMQ的IO性能很快达到了瓶颈。于是，阿里开始关注Kafka。但是Kafka是针对日志收集场景设计的，它的高级功能并不是很贴合阿里的业务场景。尤其当它的Topic过多时，由于Partition文件也会过多，这就会加大文件索
rocketMQ集群
michael_linux的博客，一个小小小学生。滴水穿石，步步为营，只为那刹那芳华。
06-08 378
RocketMQ的前身是Metaq 能够保证严格的消息顺序 提供丰富的消息拉取模式 高效的订阅者水平扩展能力 实时的消息订阅机制 支持事务消息 亿级消息堆积能力 1单节点rocketMQ安装 1.1 在hosts文件中配置地址与IP映射关系 [root@localhost rocketmq4.4.0]# vim /etc/hosts 192.168.100.100 rocketmq-nameserver1 192.168.100.100 rocketmq-master1 1.2 将解压文件放到 /op
RocketMQ（一）基本使用及集群搭建
qq_43744488的博客
08-07 415
1. MQ介绍 1.1 为什么要用MQ 消息队列是一种“先进先出”的数据结构 其应用场景主要包含以下3个方面 应用解耦 系统的耦合性越高，容错性就越低。以电商应用为例，用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障或者因为升级等原因暂时不可用，都会造成下单操作异常，影响用户使用体验。 使用消息队列解耦合，系统的耦合性就会提高了。比如物流系统发生故障，需要几分钟才能来修复，在这段时间内，物流系统要处理的数据被缓存到消息队列中，用户的下单操作正常完成。当物流系统回复后，
rocketmq集群搭建资源以及搭建详细步骤（全套）
03-04
首先，我们来了解一下RocketMQ集群的基本概念。在RocketMQ中，集群主要由NameServer、Broker和Producer/Consumer等角色组成。NameServer是服务注册与发现的中心，Broker负责存储和转发消息，Producer负责发送消息，...
RocketMQ基本概念
felix
05-20 109
1 消息模型（Message Model） RocketMQ主要由** Producer、Broker、Consumer** 三部分组成，其中Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。Broker 在实际部署过程中对应一台服务器，每个 Broker 可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的 Broker。Message Queue 用于存储消息的物理地址，每个Topic中的消息地址存储于多个 Message Queue 中。C
【四】、 RocketMQ消息分类+实操
程序猿
03-06 148
Apache RocketMQ 拥有丰富的消息类型，可以支持不同的应用场景，在不同的场景中，需要使用不同的消息进行发送。
Apache RocketMQ之JMS基本概念及使用
挂机的阿洋zzZ
12-23 3899
Apache RocketMQ之JMS基本概念及使用 优秀博客： https://blog.csdn.net/canot/article/details/53676350 https://blog.csdn.net/caidaoqq/article/details/45938919 https://blog.csdn.net/u013123635/article/details/7836236...
RocketMQ 简介与基本概念解析
RocketMQ是一种分布式消息中间件，最初由阿里巴巴集团开发并开源。它是基于主题（Topic）和标签（Tag）的发布/订阅模式，具有高性能、高可靠性和高可扩展性的特点。RocketMQ支持超大规模的消息流处理和传递能力，被...
rocketMQ系列（3） RocketMQ架构
liuerchong的博客
09-28 333
由这张图可以看到有四个集群，分别是 NameServer 集群、Broker 集群、Producer 集群和 Consumer 集群： NameServer: 提供轻量级的服务发现和路由。 每个 NameServer 记录完整的路由信息，提供等效的读写服务，并支持快速存储扩展。 Broker: 通过提供轻量级的 Topic 和 Queue 机制来处理消息存储,同时支持推（push）和拉（pull）模式以及主从结构的容错机制。 Producer：生产者，产生消息的实例，拥有相同 Producer Grou.
第二章:如何运行
weixin_43206491的博客
01-29 2345
知识前提 阅读本篇文章您应该了解或掌握一些前置知识: 基本概念 特性 聊聊NameServer NameServer是一个Broker与Topic路由的注册中心，支持Broker的动态注册与发现。 在早期版本的时候（MetaQ v2.0版本及之前），依赖的仍然是Zookeeper。后来RoketMQ开始去掉了Zookeeper依赖，使用了自己的NamerServer。 主要包括下面功能: Broker管理：接受Broker集群的注册信息并保存下来作为路由信息的基本数据；提供心跳检测机制，检查Broker
RocketMQ集群搭建
Xx__WangQi的博客
04-15 725
目录 1、机器环境 2、创建用户 3、系统配置 3.1 免密登录 3.2 关闭防火墙 4、安装java 5、安装RocketMQ 6、配置RocketMQ集群 6.1 配置第一组broker-a 6.2 配置第二组Broker-b 7、启动RocketMQ 7.1 先启动nameServer。 7.2 再启动broker 7.3 启动状态检查 7.4 测试mqadmin管理工具 7.4.1 Topic相关： 7.4.2 集群相关 7.4.3 Broker相关 7..
RocketMQ原理梳理总结
demohui的博客
07-28 2107
RocketMQ是阿里对外开源的一种分布式消息中间件，在阿里内部被叫做MetaQ，具有良好的可靠性、可用性以及稳定性 一：概念理解 NameServer 路由服务，类似于kafka中的zk，主要存储了Broker的路由信息，供Producer和Consumer使用，不然Producer怎么知道往哪个Broker发送消息，多个NameSever之间是互相独立且没有通信的，每个NameSever都会保存所有路由信息。 Broker 部署RocketMQ进程的服务被称之为Broker，Broker会接收
不科学，RocketMQ生产者在一个应用服务竟然不能向多个NameServer发送消息
m0_71777195的博客
11-19 901
目前有两套RocketMQ集群，集群A包含topic名称为，集群B包含topic名称为，在应用服务OrderApp上通过创建两个实例发送消息给集群A和集群B，架构图如下：// 创建第一个DefaultMQProducer// 设置nameServer地址try {// 发送消息System.out.println("cluster_A_topic 发送成功！");break;System.out.println("cluster_A_topic 持久化失败！");break;
rocketmq集群搭建以及消息顺序消费，消息事务等功能理解
weixin_36279234的博客
06-13 1103
下载当前最新版本的rocketmq：Release Notes - Apache RocketMQ - Version 4.9.3 - Apache RocketMQ rocketmq是java实现的，由于它的高并发而且低延迟的特性，所需要的内存很大，解压后需要修改runserver.sh和runbroker.sh配置文件的堆大小以及元数据空间大小，将默认的java heap配置根据自己虚机的资源进行调整。我的机器实在太烂，堆内存设置比较小runserver.sh runbroker.sh 修改c
rocketMQ消息模式（集群和广播）
qq_26896085的博客
03-19 3805
消息模式 DefaultMQPushConsumer实现了自动保存offset值以及实现多个consumer的负载均衡。 //设置组名 DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("HAOKE_IM"); 通过groupname将多个consumer组合在一起，那么就会存在一个问题，消息发送到这个组后，消息怎么分配呢？...
RocketMQ-集群模式
程序员劝退师的博客
12-18 683
单Master 只有一个Broker(其本质上不能称为集群)，这种方式也只能在测试环境使用，生产环境最好不要使用！ 多Master Broker集群仅由多个MasterBroker构成，不存在Salve，同一个Topic的各个Queue会平均分布各个Master节点上 优点： 配置简单，单个Master宕机或则重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢失，（异步刷盘丢失少量消息，同步刷盘一条不丢失），性能最高。 缺点 单机机器宕机
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值