- 博客(1919)
- 资源 (12)
- 收藏
- 关注
RSS订阅原创 Kafka - java.lang.VerifyError: Uninitialized object exists on backward branch 193
我这里的版本虽然看起来对，但是JAVA_HOME不对。无论运行哪个版本的 JRE，都需要 JAVA_HOME 指向正确的 JDK 版本。这玩意儿一看就是JDK版本的问题。
2023-10-26 05:30:00
4920
2
原创 Kafak - 单机/集群快速安装指北(3.x版本)
因为Zookeeper集群当中记录着Kafka集群相关信息，Zookeeper集群一旦先停止，Kafka集群就没有办法再获取停止进程的信息，只能手动杀死Kafka进程了。分别在hadoop103和hadoop104主机上修改配置文件server.properties中broker.id=103、broker.id=104。注意：停止Kafka集群时，一定要等Kafka所有节点进程全部停止后再停止Zookeeper集群。注：broker.id不得重复。
2023-10-26 04:30:00
5390
原创 Kafka - 深入了解Kafka基础架构：Kafka的基本概念
- 1）Producer ：消息生产者，就是向kafka broker发消息的客户端- 2）Consumer ：消息消费者，向kafka broker获取消息的客户端- 3）Consumer Group （CG）：消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个broker可以有多个不同的topic，一个topic下的一个分区只能被一个消费者组内的一个消费者所消费；消费者组之间互不影响。消费者组是逻辑上的一个订阅者
2023-10-25 22:15:00
5567
原创 Kafka - 消息队列的两种模式
这种模式适用于一对多的通信，其中消息的发送者不需要关心谁会接收消息，通常用于事件处理、日志记录和实时通知等场景。消息队列主要分为两种模式：点对点模式（一个生产者对口一个消费者）和发布/订阅模式（一对多）。这种模式适用于一对一的通信，其中生产者和消费者之间有直接的关联，通常用于任务分发和处理。在实际的消息队列系统中，可以根据需求选择合适的模式来实现不同类型的消息传递。这两种模式有各自的优势和适用性，选择哪种模式取决于应用程序的需求。消息队列确实可以根据消息传递的模式分为。
2023-10-25 20:15:00
6056
原创 从传统云架构到云原生生态体系架构的演进
随着科技的不断发展，云计算领域也经历了巨大的变革。这一演进的核心焦点是从传统云架构过渡到云原生生态体系架构，这个过程在过去的几年里已经发生了显著变化。本文将深入探讨这一演进过程，以及它对企业和技术生态系统的影响。从传统云架构到云原生生态体系架构的演进代表了云计算领域的一次深刻变革。它带来了更好的性能、效率和可维护性，有助于满足不断变化的市场需求。随着技术的不断发展，云原生生态体系架构将继续演进，为未来的创新提供更多的机会。在这个快速变化的领域，不断学习和适应是至关重要的。
2023-10-23 20:45:00
6238
原创 Simple RPC - 02 通用高性能序列化和反序列化设计与实现
网络传输和序列化这两部分的功能相对来说是非常通用并且独立的，在设计的时候，只要能做到比较好的抽象，这两部的实现，它的通用性是非常强的。不仅可以用于 RPC 框架中，同样可以直接拿去用于实现消息队列，或者其他需要互相通信的分布式系统中。我们先来实现序列化和反序列化部分，因为后面的部分会用到序列化和反序列化。/*** 计算对象序列化后的长度，主要用于申请存放序列化数据的字节数组* @param entry 待序列化的对象* @return 对象序列化后的长度*//*** 序列化对象。
2023-10-19 21:30:00
5403
原创 每日一博 - Code如何被发布到生产环境
关于公司如何将代码发布到生产环境的是一个什么样的流程呢？下面的图示展示了典型的工作流程。步骤 1：流程始于产品负责人根据需求创建用户故事。步骤 2：开发团队从积压工作中挑选用户故事，将它们放入为期两周的开发周期的冲刺中。步骤 3：开发人员将源代码提交到代码仓库 Git。步骤 4：在 Jenkins 中触发构建。源代码必须通过单元测试、代码覆盖率阈值和 SonarQube 中的检查点。步骤 5：一旦构建成功，构建将存储在 artifactory 中。然后构建被部署到开发环境。
2023-10-18 20:45:00
4906
原创 AIGC - 入门向量空间模型
首先假设有一个数的集合 F，它满足“F 中任意两个数的加减乘除法（除数不为零）的结果仍然在这个 F 中”，我们就可以称 F 为一个“域”。我们处理的数据通常都是实数，所以这里我只考虑实数域。而如果域 F 里的元素都为实数，那么 F 就是实数域。为了让计算机理解现实世界中的事物，我们会把事物的特点转换成为数据，并使用多维度的特征来表示某个具体的对象。多个维度的特征很容易构成向量，因此我们就可以充分利用向量和向量空间，来刻画事物以及它们之间的关系。
2023-10-17 21:45:00
5441
原创 现代化日志解决方案 PLG （Promtail +Loki + Grafana ）
Promtail、Loki 和 Grafana 是一组开源工具，通常一起使用，用于帮助监控、收集、存储和可视化日志和指标数据的现代化日志解决方案。
2023-10-14 10:30:00
5434
原创 Simple RPC - 01 框架原理及总体架构初探
RPC，全称为Remote Procedure Call（远程过程调用），是一种计算机通信协议，用于允许程序在不同的计算机或网络节点上通过远程方式调用函数或方法。它允许开发者编写分布式应用程序，使得分布在不同位置的计算机能够像本地调用一样进行通信。以下是RPC的主要特点和工作原理：远程过程调用：RPC允许一个程序（客户端）调用另一个程序（服务器）上的函数或方法，就像调用本地函数一样，而无需了解底层网络通信细节。
2023-10-13 21:30:00
5302
原创 MQ - 42 消息中台：搭建企业内部统一的消息服务
MQ - 02 基础篇_通讯协议我们知道了协议分为公有协议和私有协议。公有协议有 MQTT、AMQP、OpenMessaging 等等，主流消息队列一般会设计自己的私有协议，比如 Kafka 协议、Pulsar 协议、RocketMQ 的 Remoting 协议等。另外消息队列从使用场景的角度看，分为了消息和流两个方向。所以在业务架构中，一般会同时使用多种消息队列来满足不同的使用场景。但是同时使用多款消息队列，从业务视角来看会增加学习和使用成本，从公司视角看会增加运维和资源成本。
2023-10-12 19:30:00
5177
原创 MQ - 41 容灾：跨地域、跨可用区的容灾和同步的方案设计
对于我们业务侧来说，我们需要保证业务在任何情况都能正常运行，即服务自身拥有容灾能力是基本要求。而消息队列作为基础组件，容灾是它的基本能力。我们将会详细讲一下消息队列集群在发生异常时如何做好容灾，以及异常时如何保证数据不丢失容灾是指当系统发生这些异常时，服务能够自动切换，并正常运行。我们是通过 RTO 和 RPO 来衡量容灾的质量。RTO 是指发生故障时业务系统所能容忍的最长停止服务时间，RPO 是指在故障期间能够容忍多少数据丢失。业务追求的是 RTO 和 RPO 都为 0，或者无限趋近于 0。
2023-10-11 21:30:00
5262
原创 MQ - 40 连接器：以MQ Connector为核心搭建数据集成架构的方案设计
在消息队列中，连接器也称为 Connector，它的作用是把不同数据源中的数据导入到消息队列，或者把消息队列中的数据导出到下游的各种存储引擎。连接器对于用户的价值是，可以很方便地将数据导入、导出消息队列。听起来，它和MQ - 38 Serverless : 基于Serverless架构实现流式数据处理中讲的基于 Serverless 实现流式计算和事件驱动架构的作用很类似，从功能上看，Flink 或 Spark 也能实现。那为什么还有连接器这个概念呢？它的价值是什么？
2023-10-10 20:45:00
5379
原创 MQ - 39 Serverless : 基于MQ和Serverless设计事件驱动架构
为了更好地理解它，我们先来回顾两个知识点。MQ - 07 基础篇_消费者客户端SDK设计(上)消费数据时 Push 模型的实时性是最高的MQ - 38 Serverless : 基于Serverless架构实现流式数据处理事件源数据的触发方式有一种是事件触发。从技术上来看，这两个知识点都是事件驱动架构的一种实现。接下来我们就详细了解一下什么是事件驱动架构，它有什么用，以及它的架构和底层运行原理。事件驱动架构，英文是 Event Driven Architecture，简称 EDA。
2023-10-09 19:45:00
5545
原创 MQ - 38 Serverless : 基于Serverless架构实现流式数据处理
为什么要搞明白上述问题？我们从一张架构图讲起。这是一张消息队列上下游生态的架构图，分为数据源、总线管道、数据目标三部分。可以看到消息队列在架构中处于缓存层，起到的是削峰填谷的缓冲作用。从技术上看，构建以消息队列为中心的数据流架构，有很多现成的技术方案和开源框架。比如分布式流计算框架 Spark/Flink，开源体系内自带的 Kafka Stream、SeaTunnel/DataX 等数据集成产品，或者 ELK 体系下的采集和数据处理的组件 Logstash，都具有处理数据的能力。
2023-10-08 20:15:00
5672
原创 MQ - 37 云原生：MQ的分层存储架构的实现方案
很多人对分层存储的概念比较模糊，经常会将它和存算分离混淆在一起。从功能上来看，两者是完全不一样的。存算分离架构主要解决的是集群架构的弹性问题，而分层存储架构解决的是低成本存储冷数据的问题。下图是两种形态的架构对比，存算分离是将计算层和存储层独立开来，分别负责计算相关逻辑和存储数据。分层存储在本地完成计算和存储逻辑，然后将 Broker 本地的冷数据上传到远程进行存储，需要时再拉下来处理。从技术上看，左边的存算分离架构也可以支持分层存储的特性，即把存储层中的冷数据再导入到另外一个存储系统存储。
2023-10-07 22:15:00
6792
原创 MQ - 36 云原生：业界MQ的计算存储分离的设计与实现
结合云原生、Serverless、EDA（Event-driven Architectures）、存算分离、分层存储、数据集成等一些业界较新的技术架构理念，来看一下消息队列如何与这些架构理念结合，以及结合后会具备哪些实际价值。我们先看一下消息队列的存算分离架构。存算分离中的“存”是指存储层，“算”是指“计算层”。简单理解“计算”就是功能相关的实现，“存储”是指数据落地持久化存储。消息队列中的存储层是指包括存储结构设计、消息存储格式、数据分段等具体的数据存储功能。
2023-10-07 19:45:00
6231
原创 每日一博 - 闲聊 Java 中的中断
在 Java 中，中断是一种线程协作方式。比如说，当线程 A 正在运行时，线程 B 可以通过中断线程 A，来指示线程 A 停止它正在执行的操作。但是线程 A 如何响应线程 B 的中断，是需要依靠线程 A 的代码处理逻辑来做决定的。
2023-09-29 23:16:10
5805
原创 MQ - 35 四款MQ的架构设计与实现的对比
4 款主流消息队列所支持的功能清单在上面的表格中，你会发现一个现象，Pulsar 支持的功能最多，RabbitMQ 和 RocketMQ 其次，Kafka 支持的功能最少。原因和它们自身的定位和发展历史有关。接下来我们从功能出发，来分析一下这 4 款主流消息队列的原理和使用方式。先来个说明，这节课中的每个部分都是独立的，你可以挑感兴趣的内容进行学习。总结下来，你会发现不同消息队列在功能方面的支持是很不一样的，侧重点各有不同。但是同一个功能的底层实现原理，大家的思路基本是一致的。
2023-09-29 07:45:00
5852
原创 MQ - 34 基础功能：在消息队列内核中支持WebSocket的设计
如何在消息队列内核中支持 WebSocket。我们就知道 WebSocket 是一个协议。我们在MQ - 03 基础篇_网络模块说过 消息队列在自身私有协议的基础上，还会支持像 HTTP 这样的公有协议。那为什么需要支持 WebSocket 协议呢？又是如何支持的？WebSocket 是一种实时协议，它在单个 TCP 连接上提供持久的全双工通信，即双向通信。双向通信非常适合需要实时更新的系统，简单说就是允许服务端主动推送数据给客户端的场景。比如金融行情、实时多人游戏、聊天应用程序和实时地理位置更新等等。
2023-09-28 20:15:00
5811
原创 MQ - 33 基础功能：Schema模块的设计
我们来看看消息队列中的 Schema 模块。看到 Schema 这个词， Schema 是什么？它有什么用？什么时候可以用到它？Schema 是数据结构定义的意思，即定义数据是什么格式的。消息队列中的 Schema 用来保证上下游数据在传递过程中，消息根据指定的格式和定义进行传递，从而解决上游的数据变更所导致的下游消费失败问题。消息队列 Schema 的核心是：客户端按照指定的数据格式发送数据，Broker 按照配置的数据格式进行校验，消费者根据指定的格式解析数据。
2023-09-27 20:45:00
5669
原创 MQ - 32 基础功能：消息查询的设计
从功能上来看，消息队列的核心功能是生产和消费，查询并不是它的主要工作，但在一些场景中用户还是需要对消息进行查询。最常见的场景是：用户觉得某条消息丢了，需要查询这条消息是否保存在 Broker 中，此时你会怎么做呢？除此之外，还有哪些场景会用到消息查询的功能呢？查询是消息队列的辅助功能，使用的场景和频率不高。从功能上看，一般会支持按消息位点查询、按时间戳查询、按消息 ID 查询、按消息 Key 或消息内容模糊查询四种场景。查询的核心是索引的构建。
2023-09-26 22:30:00
5957
原创 MQ - 31 基础功能： 优先级队列的设计
在很多业务场景中，我们会对客户进行分级，比如头部客户、中腰部客户、尾部客户等。此时有个需求是，在给这些客户发通知时，希望头部客户先收到通知，然后是腰部客户，最后是尾部客户。在这个场景中，我们就可以利用优先级队列的特性。如下图所示，只要我们发送通知的时候在每条消息上附带这个客户的优先级信息，比如头部客户的优先级是 10、中腰部是 5、尾部是 1，此时不管生产端发送数据的顺序是怎样的，消费端一定是先拿到优先级高的信息，然后进行推送。
2023-09-26 20:15:00
5762
原创 MQ - 30 基础功能：死信队列的设计
在日常业务的消费数据过程中，如果遇到数据无法被正确处理，就需要先手动把消息保存下来然后 ACK 消息，这样才能顺利消费下一条数据。此时如果消息队列拥有死信队列的功能，就不需要这么繁琐的操作，直接开启死信队列就可以实现同样的效果。为了了解死信队列的特性的底层实现， 我们会详细分析它们的技术方案从本质上来看，死信队列不是一个队列，而是一个功能。为什么这么说呢？
2023-09-26 06:30:00
5808
原创 MQ - 29 基础功能：事务消息的设计
我们来看看消息队列中的事务消息。作为一个研发人员，我们对于事务的概念可以说是如雷贯耳了，最熟悉的应该就是 MySQL 或 Redis 的事务事务有一个特点，它的概念很明确，也很常见，但是它在不同的存储引擎的作用以及实现都是不一样的。所以如果我们想使用某个引擎中的事务功能，就必须先理解一下引擎中实现的事务的功能是什么，能达到什么效果，再去理解和使用它，不能想当然地把经典的 MySQL 的事务的功能套入到新的引擎去使用。
2023-09-25 21:45:00
5863
原创 MQ - 28 基础功能：高性能的定时/延时消息的设计
在消息队列中，定时和延时消息的底层技术实现是一样的，我们后面统一用延时消息来称呼。下面我们从延时消息的使用场景和定义讲起。先来看一个延时消息典型的使用场景。在网上购买商品下单的过程中，有个功能是：下单完成后 30 分钟如果没有完成支付，则这个订单就自动被取消。如下图所示，从技术上来看，为了实现这个功能，最直观的思路是我们可以将订单数据存在 DB 的表中。然后通过定时程序每秒定时去扫描订单数据，判断如果超过 30 分钟则进行后续的处理。
2023-09-25 19:45:00
5902
原创 MQ - 27 基础功能：顺序消息和幂等的设计
在消息队列中，消息是否能有序是一个常常被问到的问题。因为在我们的业务中，比如在有序事件处理、数据实时增量同步等情况下，就需要消息队列支持顺序消息的机制。接下来我们就来看看消息队列中顺序消息的定义和实现。在消息队列中，消息的顺序性一般指的是时间的顺序性，排序的依据就是时间的先后。从功能来看，即生产端发送出来的消息的顺序和消费端接收到消息的顺序是一样的。牢记这个定义，对于我们后面理解顺序消息的实现很重要接下来我们来看看幂等的定义和实现机制，先来看看什么是幂等。
2023-09-23 12:15:00
5816
原创 MQ - 26 基础功能：Topic、分区、消费分组的设计
在基础篇和进阶篇，我们构建了一个分布式的消息队列集群。接下来我们就开始往这个集群里面添加各种功能。接下来分析消息队列的基本功能、顺序消息和幂等、延时和定时消息、事务消息、死信队列和优先级队列、消息查询、Schema、WebSocket 等功能的技术选型和设计思路。当我们将这些功能加入到集群之后，一个完整的消息队列基本就打造出来了。这里我们先聊4个静态 / 动态配置的实现：配置是集群的基础模块，看一下如何在集群中实现静态和动态配置。
2023-09-23 10:15:00
5853
原创 MQ - 25 RabbitMQ集群架构设计与实现
在集群构建方面，RabbitMQ 通过 Erlang 自带的分布式数据库 Mnesia 来实现元数据信息的存储。通过插件的形式支持多种节点发现机制，主要包括固定配置发现、类广播机制发现、第三方组件发现、手动管理四种类型。集群构建完成后，RabbitMQ 通过副本机制、镜像队列或仲裁队列来实现数据的一致性和可靠存储。镜像队列因为本身的一些架构缺陷，会逐步被仲裁队列替换。仲裁队列是基于 Raft 算法来实现的，写入的可靠性遵循多数原则，即只要多数节点写入成功就可以。
2023-09-23 08:45:00
6629
原创 MQ - 24 Pulsar集群架构设计与实现
从设计定位上来看，Pulsar 是作为 Kafka 的升级替代品出现的，它主要解决了 Kafka 在集群层面的弹性和规模限制问题。那么现在我们就从集群的角度来拆解一下 Pulsar 的架构设计和实现，先来看一下集群构建。Pulsar 社区发展非常快，可能没几天内容就会过期、失效或总结错误。所以如果需要了解最新的信息，建议你去看源码或官方的最新文档。但是万变不离其宗，当我们掌握了原理，无论如何变化，对我们来讲都不过是变化而已。
2023-09-23 06:15:00
5944
原创 MQ - 23 RocketMQ集群架构设计与实现
我们今天来看看消息方向的 RocketMQ 在集群构建、部署形态、数据可靠性、安全控制、可观测性等五个方面的设计实现在集群构建方面，节点发现是依赖 NameServer 完成的。元数据是存储在本地 Broker，在启动时上报到 NameServer 中的。在部署模式方面，RocketMQ 经历了 Master/Slave、Dledger、Controller 三种模式。其中 Controller 模式属于消息队列中常见的架构形式。在数据可靠性方面，RocketMQ 也是依赖副本来实现数据的高可靠。
2023-09-22 23:45:00
6040
原创 MQ - 22 Kafka集群架构设计与实现
MQ - 15 集群篇_如何构建分布式的消息队列集群（下）说了基于 ZooKeeper 和 KRaft 来构建集群的两种方式，在这里就不再重复。这里我们详细分析Kafka 副本之间的数据一致性、数据同步机制、Leader 切换、数据截断在集群构建方面，Kafka 支持依赖 ZooKeeper 和 KRaft 两种形态来存储元数据并完成集群构建，依赖 Controller 来完成集群的管理、Leader 切换等等。在数据可靠性方面，Kafka 依赖 ISR 协议来保证数据的高可靠。
2023-09-22 21:30:00
5905
原创 MQ - 21 可观测性_消息轨迹功能的设计
今天我们讲可观测性的第三部分：跟踪（Traces），在消息队列领域，Traces 通常被称为消息轨迹，意思是消息在系统中的运行轨迹。消息轨迹在业务消息方向是刚需，因为业务消息如果出现丢失，大概率会导致流程异常比如订单的快递运送流程没有正确处理一条订单号的消息，后续就会出现无法跟踪这个订单派送的问题。如果你负责过消息队列基础服务的日常值班，一定会经常接到用户反馈说消息丢了，想让平台查清楚为什么丢了。这个问题，你会怎么排查呢？如果想排查清楚，我们首先要搞清楚有没有丢，如果丢了，还要搞清楚是哪一个环节丢的。
2023-09-22 19:45:00
5686
原创 MQ - 20 可观测性_分布式监控体系的设计
可观测性”是近几年技术圈很火的话题，特别是 OpenCensus 和 OpenTracing 合并成立 OpenTelemetry 后，可观测性的发展速度越来越快，越来越成熟。OpenTelemetry 主要是解决可观测性数据的获取规范问题，类似消息队列领域的 AMQP 和 OpenMessaging，目的都是打造一个标准化规范。它系统地将可观测性分为指标（Metrics）日志（Logs）跟踪（Traces）三个方面在消息队列领域，可观测性建设主要也是围绕着这三点展开。
2023-09-22 08:15:00
5968
原创 MQ - 19 安全_限流方案的设计
数据维度的自我保护主要指如何保证服务端数据的安全，不被窃取。服务维度的自我保护主要指集群的限流机制，通过限制客户端的流量、请求、连接等保护自身不被击垮。我们先来看一下如何保证存储的数据不会被第三方窃取。集群在运行过程中，需要保证存储的数据安全，不会被第三方窃取，也需要能够保护好自身的服务，不会因为外力的原因而崩溃。即使在服务异常的情况下，也尽量保证自身的服务部分可用。数据保护的核心逻辑是通过加密保护数据。加密算法的选择需要兼顾安全性和加解密的速度。
2023-09-22 05:45:00
6218
原创 MQ - 18 安全_身份认证、资源鉴权和加密传输的设计
近几年业界的安全问题频繁发生，系统数据的安全性也越来越受到重视。作为消息队列的主要使用者， 消息队列是如何保证数据安全的？网络隔离、传输安全、集群认证、资源授权、自我保护、数据加密今天我们先来聊一聊网络隔离、传输安全、集群认证、资源授权四个部分，整体了解一下集群的安全控制，思考如何在传输过程、访问控制两方面保证数据安全消息队列的安全性主要由四部分组成，分别是：网络间的隔离（网络隔离）、传输过程中的安全性（传输安全）、连接建立时的身份认证（集群认证）、连接建立后的访问控制（资源授权）。
2023-09-21 23:45:00
6004
原创 MQ - 17 集群篇_（性能）分布式存储系统的编程技巧
这里总结了一些用 Java 开发存储系统时经常会用到的技巧。在我的经验中，我认为在大的设计框架差别不大的情况下，性能差异很多就是- 因为这些不起眼的细节。这里我们主要讲的是 IO 相关的优化操作，主要是因为消息队列本身就是一个重 IO 的存储系统，IO 模块的性能提升是整个系统性能提升的关键。Java IO 性能核心还是缓存、批量写和异步刷盘。从使用的角度，基本只要关注即可。在一些极限场景下，可以关注一下Direct IO的使用。同步刷盘并不是噩梦，可以通过一些代码上的优化，来提高同步刷盘的能力。
2023-09-21 22:30:00
5977
原创 MQ - 16 集群篇_分布式集群的数据一致性方案
一般我们讲分布式系统一致性和可靠性时，都会用大量的篇幅去讲 CAP、Raft、Paxos 等一致性协议。其实是没问题的，不管是 ZooKeeper 的 Zab、Kafka 的 ISR 和 KRaft，还是 Pulsar 基于 BookKeeper 实现的一致性协议，都是 Paxos 和 Raft 的实现或简化。如果对分布式系统的设计感兴趣，建议深入研究一下 CAP、Raft 和 Paxos。在消息队列中，都会通过主从架构和控制分区、副本的分布来提升集群性能和数据可靠性。在分区副本模型中，需要注意的是。
2023-09-21 21:15:00
5956
原创 MQ - 15 集群篇_如何构建分布式的消息队列集群（下）
我们先来看元数据存储服务的设计选型。在消息队列的集群架构中，元数据存储服务的选型和实现是整个架构设计的核心，其他模块的设计实现都是围绕着元数据存储服务来展开的目前，消息队列的主流实现方式都是依赖第三方组件来完成数据存储，常见的有 ZooKeeper、etcd 等。为了简化架构，我们还可以通过在集群内自建元数据存储服务来替代第三方组件，虽然需要研发投入，但从架构长期演进的合理性来看，我是推荐这种方式的，毕竟后期架构会很简洁。
2023-09-21 19:45:00
5953
原创 MQ - 14 集群篇_如何构建分布式的消息队列集群（上）
从技术上看，设计实现集群化的消息队列主要包含节点发现、节点探活、元数据存储、集群管理四个方面。接下来我们将围绕着这四个方面，来看一下具体是怎么思考、怎么实现集群的。集群构建的思路分为有状态服务和无状态服务，两种类型服务的构建思路是不一样的。有状态服务需要解决元数据存储、节点发现、节点探活、主节点选举等四部分。元数据存储主要有依赖第三方组件实现和集群内自定义实现元数据存储两个思路。第三方组件主要有 ZooKeeper、etcd 等，依赖第三方组件是当前主流的选择，因为其实现较为简单，前期稳定性较高。
2023-09-21 17:45:00
5920
X86-NFS rpm包
2020-11-24
中标龙芯-MIPS- NFS rpm包
2020-11-24
mybatisSource.zip
2020-06-14
apache-tomcat-8.5.50-src.zip
2020-06-02
「Tomcat源码剖析」.pdf
2020-06-01
Jest-5.3.4.zip
2020-01-19
Spring4CachingAnnotationsExample
2017-10-04
Java反编译工具
2015-06-04
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人