软件开发中间件
中间件相关
怎么又有bug单
走走停停
展开
-
MQ刷盘机制
mq刷盘机制原创 2022-11-09 10:57:26 · 420 阅读 · 0 评论 -
MQ消费堆积问题解决思路
MQ消费堆积问题原创 2022-11-09 10:56:35 · 1132 阅读 · 0 评论 -
RabbitMq中的warren模式和shovel模式
RabbitMq中的warren模式和shovel模式原创 2022-11-09 10:45:52 · 324 阅读 · 0 评论 -
rocketmq存储消息怎么存的 存在哪
rocketmq消息存储在哪里原创 2022-10-23 12:16:12 · 392 阅读 · 0 评论 -
Redis 更新(set) key值 会重置过期时间问题
redis setkey会重置过期时间吗原创 2022-09-17 12:50:47 · 3854 阅读 · 0 评论 -
图解Kafka,看完就学会
Kafka 是主流的消息流系统,其中的概念还是比较多的,下面通过图示的方式来梳理一下 Kafka 的核心概念,以便在我们的头脑中有一个清晰的认识。Kafka 是一套流处理系统,可以让后端服务轻松的相互沟通,是微服务架构中常用的组件。生产者服务 Producer 向 Kafka 发送消息,消费者服务 Consumer 监听 Kafka 接收消息。一个服务可以同时为生产者和消费者。Topic 是生产者发送消息的目标地址,是消费者的监听目标。一个服务可以监听、发送多个 Topics。Kafka 中原创 2022-06-17 12:05:19 · 155 阅读 · 0 评论 -
redis宕机后设置的redis连接超时时间还有效吗
redis宕机后,设置的redis连接超时时间还有效吗?最近在实际的开发中遇到了这个问题。大家要模拟redis故障的场景,观察业务系统会受多大的影响,会不会阻塞主流程。而在模拟redis宕机之后,发现之前设置的超时时间并未生效。现象是超时时间设置了1000ms,但是实际调用redis服务返回快速失败只用了20ms,这说明超时时间并未生效。于是我自己写了一个demo,来验证下redis宕机后,设置的redis连接超时时间是否还有效。MyRunnable01:ProduceRequest:Queue原创 2022-06-02 10:27:10 · 400 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(一百一十二)NameSrv的作用及高性能顺序写盘
Namesrv就是一个注册中心,存储当前集群所有Brokers信息、Topic跟Broker的对应关系。Namesrv用于存储Topic、Broker关系信息,功能简单,稳定性高。多个Namesrv之间相互没有通信,单台Namesrv宕机不影响其他Namesrv与集群;即使整个Namesrv集群宕机,已经正常工作的Producer,Consumer,Broker仍然能正常工作,但新起的Producer, Consumer,Broker就无法工作。Namesrv压力不会太大,平时主要开销是在维持心跳和提原创 2022-05-31 14:25:36 · 214 阅读 · 0 评论 -
Sentinel限流算法详解(硬啃)
文章目录常见四种限流算法固定窗口计数器滑动窗口计数器漏桶(也有称漏斗 Leaky bucket)令牌桶( Token bucket)Sentinel源码举例滑动窗口漏桶常见四种限流算法固定窗口计数器固定窗口,相比其他的限流算法,这应该是最简单的一种。它简单地对一个固定的时间窗口内的请求数量进行计数,如果超过请求数量的阈值,将被直接丢弃。这个简单的限流算法优缺点都很明显。优点的话就是简单,缺点举个例子来说。比如我们下图中的黄色区域就是固定时间窗口,默认时间范围是 60 秒,限流数量是 100。如原创 2022-05-06 14:58:12 · 6525 阅读 · 1 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(一百一十一)查漏补缺之rocketMQ重试机制
文章目录rocketMQ重试机制at least oncerocketMQ重试机制重试机制是 从 broker发往consumer消费的路上,消费失败;然后producer会重新向broker发消息。但是重试消息的topic与原topic还是有区别的可以看到是%RETRY%+消费失败的consumerGroup名重试16次仍然失败,会进入死信队列。(默认重试16次,最后一次的间隔时间是2小时)这个重试次数是可配的,比如也可配20次。不过从16次往后的间隔时间都是2小时,这个是RocketmQ原创 2022-05-03 18:57:09 · 361 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(一百一十)重试队列
重试队列重试次数 间隔时间重试次数与上次重试的时间间隔110秒230秒31分钟42分钟53分钟64分钟75分钟86分钟97分钟重试次数与上次重试的时间间隔108分钟119分钟1210分钟1320分钟1430分钟151小时162小时一条消息在一直消费失败的前提下,会在第4小时46分钟的时候进行第16次重试。若仍然失败,则投到死信队列。消费原创 2022-03-28 17:31:53 · 337 阅读 · 0 评论 -
es 如何用kibana复合查询(多个查询条件)
es的复合查询 举例如下:在bool标签下,使用must,should进行复合查询GET _search{ "query": { "bool": { "must": { "match":{ "agentId": "9585" } }, "must": { "match":{ "caseId": "10481" } } } }原创 2022-03-03 18:26:27 · 4589 阅读 · 0 评论 -
什么是布隆过滤器 为什么它能解决缓存击穿
首先什么是缓存击穿?查询一个在缓存内必然不存在的数据,导致每次请求都要去存储层去查询,这样缓存就失去了意义。如果在大流量下数据库可能挂掉。那什么是布隆过滤器?它的核心是一个很长的二进制向量和一系列的hash函数。比如我现在有三个商品存在数据库中,那么我就有三个商品id,如果直接查库,那么存在缓存击穿,(假如所查询的商品id压根不存在)那么要如何解决缓存击穿呢?显然关键就是对于不存在的id,不要让系统查库,能够通过内存拦截即,利用布隆过滤器,过滤掉数据库中压根不存在的商品id做法是:对商品i原创 2022-03-09 19:04:20 · 225 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(一百零九)集群搭建理论
文章目录集群搭建理论数据复制与刷盘策略复制策略刷盘策略Broker集群模式单Master多Master多Master多Slave模式-异步复制多Master多Slave模式-同步双写最佳实践集群搭建理论数据复制与刷盘策略复制策略复制策略是Broker的Master与Slave间的数据同步方式。分为同步复制与异步复制:同步复制:消息写入master后,master会等待slave同步数据成功后才向producer返回成功ACK异步复制:消息写入master后,master立即向producer原创 2022-02-21 19:18:16 · 265 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(一百零八)RocketMQ单机安装与启动
文章目录架构图单机安装与启动环境要求:系统要求是 64 位的,windows,mac,linux都可以。JDK要求是1.8及其以上版本的启动架构图单机安装与启动环境要求:系统要求是 64 位的,windows,mac,linux都可以。JDK要求是1.8及其以上版本的进入rocketmq官网,下载最新包即可下载最新包之后解压,输入如下命令启动:启动启动NameSrv: sh bin/mqnamesrv & 启动Broker:sh bin/mqbroker -n loca原创 2022-02-21 19:14:49 · 346 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(一百零七)RocketMQ基本概念
文章目录RocketMq基本概念消息(Message)主题(Topic)标签(Tag)队列(Queue)消息标识(MessageId/Key)RocketMq基本概念消息(Message)消息是消息系统传输信息的物理载体,同时也是生产和消费数据的最小单元注意:每条消息必须属于一个主题topic主题(Topic)Topic表示一类消息的集合,每个主题包含若干队列,每个队列包含若干条消息。每条消息只能属于一个主题,是RocketMQ进行消息订阅的基本单位。一个生产者可以同时发送多种Topic的消原创 2022-02-21 19:01:30 · 75 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(一百零六)MQ中的协议
文章目录MQ常见协议JMSSTOMPAMQPMQTTMQ常见协议JMSJMS,Java Messaging Service(Java消息服务)。是Java平台上有关MOM(Message OrientedMiddleware,面向消息的中间件 PO/OO/AO)的技术规范,它便于消息系统中的Java应用程序进行消息交换,并且通过提供标准的产生、发送、接收消息的接口,简化企业应用的开发。ActiveMQ是该协议的典型实现。STOMPSTOMP,Streaming Text Orientated Me原创 2022-02-21 19:00:02 · 75 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(一百零五)事务消息
事务消息并不是实际消息可回退,而是在实际发送消息之前,有一个预消费的动作。举例:比如我准备回家,但是我本身没有钥匙,所以我需要确定家里有人,不然的话我人跑到家才发现家里没人,这不是白跑了吗?所以我先打个电话问问家人在不在家,如果在家,我才出发回家。实际回家,和打电话 是两件事也就是说预消费和真实的消费,本身还是不一样的。图解:代码:consumer不需要特殊处理,就不写了producer是需要专为事务消息做改造的:ProducerServiceImpl:@Servicepublic原创 2022-02-01 23:16:37 · 1681 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(一百零四)事务消息
RocketMQ事务分布式事务的两种常见实现方式:2pc tcc2pc两阶段提交 遵循XA协议 、其实可以理解为”预提交“tcc三阶段提交 try confirm cancelRocketMQ中采用2pc 两阶段提交RocketMQ中事务消息流程图源码:private GetResult getHalfMsg(MessageQueue messageQueue, long offset) { GetResult getResult = new GetResult()原创 2022-02-01 14:06:27 · 3574 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(一百零三)经典面试题
追问:为什么要主动拉取消息而不使用事件监听方式?事件驱动方式是建立好长连接,由事件(发送数据)的方式来实时推送。如果broker主动推送消息的话有可能push速度快,消费速度慢的情况,那么就会造成消息在consumer端堆积过多,同时又不能被其他consumer消费的情况。而pull的方式可以根据当前自身情况来pull,不会造成过多的压力而造成瓶颈。所以采取了pull的方式。8.broker如何处理拉取请求的?Consumer首次请求BrokerBroker中是否有符合条件的消息有响应Con原创 2022-02-01 14:05:26 · 175 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(一百零三)经典面试题
7.消费消息是push还是pull?RocketMQ没有真正意义的push,都是pull,虽然有push类,但实际底层实现采用的是长轮询机制,即拉取方式broker端属性 longPollingEnable 标记是否开启长轮询。默认开启public void pullMessage(final PullRequest pullRequest) { final ProcessQueue processQueue = pullRequest.getProcessQueue(); if原创 2022-02-01 14:04:57 · 93 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(一百零二)经典面试题
org.apache.rocketmq.store.DefaultMessageStore.CleanCommitLogService#isTimeToDeleteprivate boolean isTimeToDelete() { String when = DefaultMessageStore.this.getMessageStoreConfig().getDeleteWhen(); if (UtilAll.isItTimeToDo(when)) { DefaultM原创 2022-02-01 14:04:24 · 173 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(一百零一)经典面试题
源码如下:org.apache.rocketmq.store.DefaultMessageStore.CleanCommitLogServiceclass CleanCommitLogService { private final static int MAX_MANUAL_DELETE_FILE_TIMES = 20; private final double diskSpaceWarningLevelRatio = Double.parseDouble(System原创 2022-02-01 14:03:48 · 1392 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(一百)经典面试题
接下来我们再冲一波rocketMQ的经典面试题:1.多种MQ如何选型?MQ描述RabbitMQerlang开发,对消息堆积的支持并不好,当大量消息积压的时候,会导致 RabbitMQ 的性能急剧下降。每秒钟可以处理几万到十几万条消息。RocketMQjava开发,面向互联网集群化功能丰富,对在线业务的响应时延做了很多的优化,大多数情况下可以做到毫秒级的响应,每秒钟大概能处理几十万条消息。KafkaScala开发,面向日志功能丰富,性能最高。当你的业务场景中,每秒钟消原创 2022-02-01 14:03:05 · 202 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(九十九)延时队列
延迟消息与消费重试的关系RocketMQ提供了消息重试的能力,在并发模式消费消费失败的情况下,可以返回一个枚举值RECONSUME_LATER,那么消息之后将会进行重试。如:org.apache.rocketmq.client.consumer.listener.MessageListenerConcurrently#consumeMessage@Overridepublic ConsumeConcurrentlyStatus consumeMessage(List<MessageExt>原创 2022-01-31 20:04:35 · 192 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(九十八)延时队列
参看源码:org.apache.rocketmq.store.schedule.ScheduleMessageService.DeliverDelayedMessageTimerTask#messageTimeupprivate MessageExtBrokerInner messageTimeup(MessageExt msgExt) { MessageExtBrokerInner msgInner = new MessageExtBrokerInner(); msgInner.set原创 2022-01-31 20:04:01 · 207 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(九十七)延时队列
第三步:延迟服务消费SCHEDULE_TOPIC_XXXX消息Broker内部有一个ScheduleMessageService类,其充当延迟服务,消费SCHEDULE_TOPIC_XXXX中的消息,并投递到目标Topic中。ScheduleMessageService在启动时,其会创建一个定时器Timer,并根据延迟级别的个数,启动对应数量的TimerTask,每个TimerTask负责一个延迟级别的消费与投递。相关源码如下所示:org.apache.rocketmq.store.schedule原创 2022-01-31 20:03:24 · 192 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(九十六)延时队列
第二步:转发消息到延迟主题的CosumeQueue中CommitLog中的消息转发到CosumeQueue中是异步进行的。在转发过程中,会对延迟消息进行特殊处理,主要是计算这条延迟消息需要在什么时候进行投递。投递时间=消息存储时间(storeTimestamp) + 延迟级别对应的时间需要注意的是,会将计算出的投递时间当做消息Tag的哈希值存储到CosumeQueue中相关源码参见:org.apache.rocketmq.store.CommitLog#checkMessageAndReturn原创 2022-01-31 20:02:52 · 876 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(九十五)延时队列
同时,还会将消息原来要发送到的目标Topic和队列信息存储到消息的属性中。相关源码如下所示:org.apache.rocketmq.store.CommitLog#asyncPutMessagepublic CompletableFuture<PutMessageResult> asyncPutMessage(final MessageExtBrokerInner msg) { // Set the storage time msg.setStoreTimestamp(Sys原创 2022-01-31 09:17:49 · 106 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(九十四)延时队列
注意各种mq,对于延时消息的实现思路都是基本一样的:Broker端内置延迟消息处理能力,将延迟消息通过一个临时存储进行暂存,到期后才投递到目标Topic中。如下图所示:步骤说明如下:producer要将一个延迟消息发送到某个Topic中Broker判断这是一个延迟消息后,将其通过临时存储进行暂存。Broker内部通过一个延迟服务(delay service)检查消息是否到期,将到期的消息投递到目标Topic中。这个的延迟服务名字为delay service,不同消息中间件的延迟服务模块名称可能不原创 2022-01-31 09:17:16 · 441 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(九十三)延时队列
2:初始存储偏移量所用的内存this.byteBufferIndex.flip();this.byteBufferIndex.limit(CQ_STORE_UNIT_SIZE);this.byteBufferIndex.putLong(offset);this.byteBufferIndex.putInt(size);this.byteBufferIndex.putLong(tagsCode);这里将消息的偏移量、大小、tagsCode等信息,都暂存到了一块ByteBuffer中。3:获取此原创 2022-01-31 09:15:53 · 85 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(九十二)延时队列
this.dispatcherList = new LinkedList<>();this.dispatcherList.addLast(new CommitLogDispatcherBuildConsumeQueue());this.dispatcherList.addLast(new CommitLogDispatcherBuildIndex());doDispatch()会遍历CommitLogDispatcher,调用它们的dispatch()方法。其中专门用来通知Consume原创 2022-01-31 09:15:14 · 114 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(九十一)延时队列
简介每个ConsumeQueue都有一个id,id 的值为0到TopicConfig配置的队列数量。比如某个Topic的消费队列数量为4,那么四个ConsumeQueue的id就分别为0、1、2、3。ConsumeQueue是不负责存储消息的,只是负责记录它所属Topic的消息在CommitLog中的偏移量,这样当消费者从Broker拉取消息的时候,就可以快速根据偏移量定位到消息。ConsumeQueue本身同样是利用MappedFileQueue进行记录偏移量信息的,可见MappedFileQueu原创 2022-01-31 09:14:10 · 90 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(九十)延时队列
接下来看下executeOnTimeup( )里面具体干了什么:public void executeOnTimeup() { ConsumeQueue cq = ScheduleMessageService.this.defaultMessageStore.findConsumeQueue(TopicValidator.RMQ_SYS_SCHEDULE_TOPIC, delayLevel2QueueId(delayLevel));首先根据topic原创 2022-01-30 10:58:03 · 317 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(八十九)延时队列
就是一个public abstract class TimerTask implements Runnable {Runnable的运行,和一个延时时间。延迟delay毫秒后执行,主要还是关心下DeliverDelayedMessageTimerTask(level, offset)这个类干了什么org.apache.rocketmq.store.schedule.ScheduleMessageService.DeliverDelayedMessageTimerTask#DeliverDel原创 2022-01-30 10:56:41 · 79 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(八十八)延时队列
接下来是一个start方法public void start() { if (started.compareAndSet(false, true)) {先确保start方法没有被调用过,用一个布尔类型的原子变量来保证。接下来的代码看起来是核心的延时消息原理相关的代码,我们看的细一点:super.load();this.timer = new Timer("ScheduleMessageTimerThread", true);首先调用父类的load()方法,这个load就不细看了,原创 2022-01-30 10:55:59 · 129 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(八十七)延时队列
commitLog与offset如下图所示,producer发送消息到broker之后,会将消息具体内容持久化到commitLog文件中,再分发到topic下的消费队列consume Queue,消费者提交消费请求时,broker从该consumer负责的消费队列中根据请求参数起始offset获取待消费的消息索引信息,再从commitLog中获取具体的消息内容返回给consumer。在这个过程中,consumer提交的offset为本次请求的起始消费位置,即beginOffset;consume Queu原创 2022-01-30 10:54:41 · 332 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(八十六)延时队列
offset在rocketMQ中,offset用来管理每个消息队列的不同消费组的消费进度。对offset的管理分为本地模式和远程模式,本地模式是以文本文件的形式存储在客户端,而远程模式是将数据保存到broker端,对应的数据结构分别为LocalFileOffsetStore和RemoteBrokerOffsetStore。默认情况下,当消费模式为广播模式时,offset使用本地模式存储,因为每条消息会被所有的消费者消费,每个消费者管理自己的消费进度,各个消费者之间不存在消费进度的交集;当消费模式为集群消原创 2022-01-30 10:52:56 · 1006 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(八十五)延时队列
private final DefaultMessageStore defaultMessageStore;private final AtomicBoolean started = new AtomicBoolean(false);private Timer timer;private MessageStore writeMessageStore;private int maxDelayLevel;再往下是一个默认的消息存储,一个代表是否开始的原子布尔量定时器timer,写消息存储最大延时原创 2022-01-30 10:12:19 · 275 阅读 · 0 评论 -
全站最硬核 百万字强肝RocketMq源码 火热更新中~(八十四)延时队列
延时队列如何实现说明:rocketmq实现的延时队列只支持特定的延时时间段,1s,5s,10s,…2h,不能支持任意时间段的延时具体实现:rocketmq发送延时消息时先把消息按照延迟时间段发送到指定的队列中(rocketmq把每种延迟时间段的消息都存放到同一个队列中)然后通过一个定时器进行轮训这些队列,查看消息是否到期,如果到期就把这个消息发送到指定topic的队列中,这样的好处是同一队列中的消息延时时间是一致的,还有一个好处是这个队列中的消息时按照消息到期时间进行递增排序的,说的简单直白就是队列中原创 2022-01-30 10:10:53 · 190 阅读 · 0 评论