959

mq: rabbitmq, rocketmq, kafka

Rabbitmq 实现延迟队列的解决方式 1.死信队列 2.插件方式

RocketMQ 延时消息机制

Kafka文章目录Kafka1. 消息队列概述2. 消息队列应用场景2.1异步处理2.2应用解耦1. 消息队列概述消息队列中间件是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ2. 消息队列应用场景以下介绍消...

RocketMQ和Kafka的差异对比

Kafka 和 RocketMq 的对比

文章目录1.第一次分治2.第二次分治3.第三次分治4.第四次分治5.查询逻辑6.总结1.第一次分治kafka通过topic给用户提供数据的读写，对于不同的业务来说，可以定义不同的topic来达到数据分治的目的，不同的业务写入或者读取不同的topic，且不同的topic会尽可能分散在不同的broker中，提高数据的IO效率。虽然kafka没有限制topic的个数，但是也不要盲目多建，因为越多的topic，代表着越多的数据存储单元，容易导致同一个topic的数据在磁盘存储位置的不连续，从而降低数据读写的

4.Pulsar 主要功能和介绍4.1 多租户多租户是一种架构，目的是为了让多用户环境下使用同一套程序，且保证用户间数据隔离简单讲：在一台服务器上运行单个应用实例，它为多个租户（客户）提供服务多租户这一特性，使得各个部门之间可以共享同一份数据，不用单独部署独立的系统来操作数据，很好的保证了各部门间数据一致性的问题，同时简化维护成本。多租户的要求:使用身份证, 授权和acl确保安全性为每个租户强制执行存储配额支持在运行时更改隔离机制，从而实现操作成本低和管理简单多租户可以提供安全性和隔离

1.Apache Pulsar基本介Apache Pulsar 是一个云原生企业级的发布订阅（pub-sub）消息系统，最初由Yahoo开发，并于2016年底开源，现在是Apache软件基金会顶级开源项目。Pulsar在Yahoo的生产环境运行了三年多，助力Yahoo的主要应用，如Yahoo Mail、Yahoo Finance、Yahoo Sports、Flickr、Gemini广告平台和Yahoo分布式键值存储系统Sherpa。功能与特性:多租户灵活的消息系统云原生架构segmente

文章目录1. 什么是消息队列2. 消息队列有哪些使用场景。2.1 消息通讯3. 消息队列如何解决消息丢失问题？3.1 生产者保证不丢消息3.2 存储端不丢消息3.3 消费阶段不丢消息4. 消息队列如何保证消息的顺序性5. 如何保证数据一致性，事务消息如何实现1. 什么是消息队列你可以把消息队列理解为一个使用队列来通信的组件。它的本质，就是个转发器，包含发消息、存消息、消费消息的过程。最简单的消息队列模型如下：我们通常说的消息队列，简称MQ（Message Queue），它其实就指消息中间件，当前业界

文章目录1.缓存雪崩2.缓存穿透3.缓存击穿4.数据不一致5.数据并发竞争6.热点key问题7.BigKey问题1.缓存雪崩指缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。解决方案：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。逻辑上永不过期给每一个缓存数据增加相

文章目录1.Broker端配置详解1.1 必配参数1.2 监听器相关参数1.3 主题相关参数1.4 线程相关参数1.5 压缩相关参数1.6 ZooKeeper相关参数1.7 重平衡与选举相关参数1.8 日志刷写相关参数1.9 日志保留相关参数1.10 日志滚动切片相关参数1.11 元数据相关参数1.12 副本相关参数1.13 offset相关参数1.14 消息相关参数2.Topic级别配置详解2.1 日志清理压缩相关参数2.2 日志刷写相关参数2.3 索引相关参数2.4 消息、副本与选举相关参数2.5 日志

1.操作系统部署在 Linux 上I/O 模型数据网络传输效率1.1 I/O 模型层面I/O 模型是操作系统执行 IO 指令的方法。分别有五种类型阻塞式 IO非阻塞式 IOIO 多路复用信号驱动 IO异步 IO可以简单认为后面的模型比前面的模型要更高效，epoll 模型介于第三种和第四种之间，select 属于第三种。Kafka 的客户端底层使用了 Java 的 selector，而 selector 在 Linux 的实现是 epoll，在 Windows 上实现机制为

ISR什么时候收缩ISR什么时候扩展ISR的传播机制Broker宕机之后怎么ISR的收缩？Kafka在启动的时候,会启动一个副本管理器ReplicaManager,这个副本管理器会启动几个定时任务。ISR过期定时任务isr-expiration,每隔replica.lag.time.max.ms/2毫秒就执行一次。ISR变更的传播定时任务isr-change-propagation,每隔2500毫秒就执行一次。replica.lag.time.max.ms : 如果一个follower.

1.RocketMQ由哪些角色组成，每个角色作用和特点是什么2.RocketMQ中的Topic和JMS的queue有什么区别queue 就是来源于数据结构的 FIFO 队列。而 Topic 是个抽象的概念，每个 Topic 底层对应N个 queue，而数据也真实存在 queue 上的。3.RocketMQ Broker中的消息被消费后会立即删除吗「不会」，每条消息都会持久化到CommitLog中，每个Consumer连接到Broker后会维持消费进度信息，当有消息消费后只是当前Consumer的消

文章目录1.查询配置2.增删改 配置3.kafka-console-producer1.查询配置1.查询单个Topic配置(只列举动态配置)sh bin/kafka-configs.sh --describe --bootstrap-server xxxxx:9092 --topic test_create_topic 或者 sh bin/kafka-configs.sh --describe --bootstrap-server 172.23.248.85:9092 --entity-typ

文章目录1.TopicCommand1.1.Topic创建1.2.删除Topic1.3.Topic分区扩容1.4.查询Topic描述1.5 查询Topic列表1.TopicCommand1.1.Topic创建bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 3 --partitions 3 --topic test相关可选参数：1.2.删除Topicbin/kafka-top

1.Kafka 的技术难点Kafka 为实时日志流而生，要处理的并发和数据量非常大。可见，Kafka 本身就是一个高并发系统，它必然会遇到高并发场景下典型的三高挑战：高性能、高可用和高扩展。为了简化实现的复杂度，Kafka 最终采用了很巧妙的消息模型：它将所有消息进行了持久化存储，让消费者自己各取所需，想取哪个消息，想什么时候取都行，只需要传递一个消息的 offset 进行拉取即可。最终 Kafka 将自己退化成了一个「存储系统」。因此，海量消息的存储问题就是 Kafka 架构设计中的最大技术难

Kafka使用的是Logging（日志文件）这种很原始的方式来存储消息对于存储设计有一些知识点: Append Only、Linear Scans、磁盘顺序写、页缓存、零拷贝、稀疏索引、二分查找等等。Append Only Data Structures 的一些存储系统比如HBase, Cassandra, RocksDB文章目录1.Kafka存储难度2.Kafka 的存储选型分析2.1 存储领域的基础知识2.2 Kafka 的存储选型考虑3.Kafka 的存储设计1.Kafka存储难度Kafka

1.什么是消息中间件消息中间件是基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统。消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。2.kafka 是什么？有什么作用Kafka 是一个分布式的流式处理平台，它以高吞吐、可持久化、可水平扩展、支持流数据处理等多种特性而被广泛使用消息系统：kafka与传统的消息中间件都具备系统解耦、冗余存

文章目录1.消费消息的性能优化手段1.1 稀疏索引1.2 mmap1.3 零拷贝1.4 批量拉取1.消费消息的性能优化手段1.1 稀疏索引Kafka 利用offset 和 timestamp 查到消息。B Tree 类的索引并不适用于 Kafka。哈希索引看起来却非常合适。为了加快读操作，如果只需要在内存中维护一个「从 offset 到日志文件偏移量」的映射关系即可，每次根据 offset 查找消息时，从哈希表中得到偏移量，再去读文件即可。（根据 timestamp 查消息也可以采用同样的思路.

1. 存储消息的性能优化手段存储消息属于 Broker 端的核心功能IO多路复用, 磁盘顺序写, page缓存, 分区分段结构1.1 IO 多路复用对于 Kafka Broker 来说，要做到高性能，首先要考虑的是：设计出一个高效的网络通信模型，用来处理它和 Producer 以及 Consumer 之间的消息传递问题。SocketServer :Kafka采用的是Reactor 网络通信模型1 个 Acceptor 线程，负责监听新的连接，然后将新连接交给 Processor 线程处.

Kafka 的高性能设计可以说是全方位的，从 Prodcuer 、到 Broker、再到 Consumer，Kafka 在掏空心思地优化每一个细节，最终才做到了这样的极致性能。1. 如何理解高性能设计对于线程池、多级缓存、IO 多路复用、零拷贝等技术是一个系统性的问题，至少需要深入到操作系统层面。从 CPU 和存储入手，去了解底层的实现机制，然后再自底往上，一层一层去解密和贯穿起来。高性能设计离不开的就是计算和IO计算：1、让更多的核来参与计算：比如用多线程代替单线程、用集群代替单机等。2、减少

文章目录1.RocketMq架构2.消息不丢失2.1 同步发送2.2 异步消息2.3 刷盘机制2.4 Broker 多副本和高可用2.5 消息确认2.6 Consumer 重试2.7 事务消息2.8 消息索引2.9 极端1.RocketMq架构Producer,Consumer,Brocker,Name Server2.消息不丢失1.Producer发送消息2.Brocker保存消息3.Consumer 消费消息4.Brocker主从切换2.1 同步发送public void send(

RocketMQ 是阿里巴巴的分布式消息中间件，在 2012 年开源，在 2017 年成为 Apache 顶级项目。文章目录1.集群架构1.1 Name Server 集群1.2 Broker1.3 Producer1.4 Consumer2 MessageQueue3 Consumer4 Broker 高可用集群5 消息存储5.1 CommitLog5.2 ConsumeQueue5.3 Index 文件5.3.1 IndexHead5.3.2 Hash 槽5.3.3 Index 条目5.3.4 总结6

1.RPC 架构2.同步异步调用3.流行的 RPC 框架文章目录1.RPC 架构2.同步调用与异步调用3.流行的 RPC 框架4.HTTP 服务5.总结1.RPC 架构先说说 RPC 服务的基本架构吧。我们可以很清楚地看到，一个完整的 RPC 架构里面包含了四个核心的组件。ClientServerClient StubServer Stub（这个Stub大家可以理解为存根）客户端（Client），服务的调用方。服务端（Server），真正的服务提供者。

文章目录1.部署 Pulsar2.Pulsar 客户端3.测试4.总结1.部署 Pulsardockerdocker run -it -p 6650:6650 -p 8080:8080 --mount source=pulsardata,target=/pulsar/data --mount source=pulsarconf,target=/pulsar/conf apachepulsar/pulsar:2.9.1 bin/pulsar standalone2.Pulsar 客户端Java

Redis为kv的,而Redis底层又是由c语言写成的,一切皆字典dict,和java的一切皆对象ObjectRedis的key类型一般为字符串,value为redis类型RedisObject这里的kv称为dictEntry相当与java中的Map<String, redisObject>bitmap底层为String类型,hyperloglog底层为String,GEO底层为zset1.上帝视角redisServer -> redisDB -> dict ->

可靠消费Redis：没有相应的机制保证消息的消费，当消费者消费失败的时候，消息体丢失，需要手动处理RabbitMQ：具有消息消费确认，即使消费者消费失败，也会自动使消息体返回原队列，同时可全程持久化，保证消息体被正确消费可靠发布Reids：不提供，需自行实现Redis的消息队列，如果在从队列pop出去的时候，worker处理失败的话，数据不会回到队列中，需要从业务中手动把失败的处理数据push到队列中；RabbitMQ：具有发布确认功能，保证消息被发布到服务器RabbitMQ有一个消息确认机制

文章目录如何确保消息正确地发送至 RabbitMQ？ 如何确保消息接收方消费了消息如何避免消息重复投递或重复消费消息基于什么传输消息如何分发消息怎么路由如何确保消息持久化RabbitMQ 的集群mq 的缺点如何确保消息正确地发送至 RabbitMQ？ 如何确保消息接收方消费了消息发送方确认模式将信道设置成 confirm 模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的 ID。一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息

1.导入jar包 <dependencies> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> </dependency> <dependency> <groupId>org.springframework.

Spring与MQ1.jar包<!-- activeMQ jms 的支持 --><dependency> <groupId>org.springframework</groupId> <artifactId>spring-jms</artifactId> <version>4.3.23.RELEASE</version></dependency><dependen

一. 初步安装使用ActiveMQ扩展出：API 接受发送MQ 的高可用MQ 的集群容错配置MQ 的持久化延时发送签收机制Spring/SpringBoot 整合1.1 为什么要使用 MQ ？解决了耦合调用、异步模型、抵御洪峰流量，保护了主业务，消峰。1.2 安装[root@z99 ~]# cd /opt/[root@z99 opt]# lsapache-activemq-5.15.15 apache-activemq-5.15.15-bin.tar.gz redis-