自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(40)
  • 收藏
  • 关注

原创 webflux源码解析(5)-response处理

之前的文章前后梳理了接收connection中的msg、将msg转成request、处理request的主流程,当业务代码执行完毕后,对response会有一段处理逻辑,本文对其进行梳理。

2024-08-27 14:32:35 747

原创 webflux源码解析(4)-异常request处理

在webflux接收请求时,第一步实际上 netty-reacto r将 channel 中的字节信息解析成msg(实践中发现,当调用接口时若request存在异常,代码不会执行到业务代码,且不会有异常日志,初遇到时很让人困惑。返回错误信息时,response是框架层面定义的,没有response body,需要根据http code判断。此处梳理request的解析链路,重点关注异常request的处理。),进而解析成request,之后才是webflux的处理流程。

2024-08-27 14:04:01 306

原创 webflux源码解析(3)-reactor netty

完成了从connection中接收请求动作,之后请求会传递到了,进入webflux处理请求的主流程。这个链路上的方法调用了subscribe 方法,触发了响应式调用链的执行

2024-08-20 18:48:08 856

原创 webflux源码解析(2)-reactor

分析之前,先看一下reactor提供的顶级接口发布者Publisher是一个可以发送无限序列元素的发布者,允许调用多次,每次调用都会启动一个新的。每个Subscription只能被一个Subscriber使用;Subscriber消费者只能订阅一次Publisher。//发布者/*** 订阅方法* 请求发布者启动数据流* @param s 消费者*/订阅者(消费者)其中只会被调用一次/*** 该方法在调用Publisher#subscribe(Subscriber)后执行。

2024-08-19 17:47:17 1146

原创 webflux源码解析(1)-主流程

WebFlux是Spring 5.0框架推出的一个全新的响应式Web框架,是基于Project Reactor构建的,它旨在利用响应式编程的特性来构建异步非阻塞的应用程序。在io密集型的场景中,使用webflux这类响应式io框架,能大幅提高系统的吞吐量。本文主要是关于其主流程的梳理,包括关键实例的创建、配置等。

2024-08-18 16:26:32 934

原创 es的执行命令日志输出

希望能够在日志中打印具体执行的es命令,便于问题排查,但没有找到对应的功能,因此花了些时间实现了一版方案,在此记录下来。

2024-08-13 17:10:06 485

原创 xxl-job 源码梳理(2)-服务端

分片指的是任务分片广播执行的概念,当调度中心调度一个设置了分片参数的任务时,任务会被拆分成多个子任务(分片),每个分片会被分配一个唯一的序号(分片参数,通常从0开始)。由于scheduleThread周期性执行,为了处理周期间需要执行的任务,此处会判断,所触发任务后,下一次的待执行时间于当前时间相差不超过5秒,也会添加到时间轮中。是负责触发任务调度的线程,周期性地检查所有的任务计划(Cron表达式定义的任务),如果发现有任务到达执行时间,则将这些即将执行的任务放入到一个“时间轮”(

2024-08-08 21:01:44 752

原创 xxl-job 源码梳理(1)-客户端

上图是xxl-job的架构图,从架构图可以看出,xxl-job 分别有调度中心和执行器两大组成部分本文是关于执行器的梳理,也就是xxlJob客户端的代码,其中有几个关键部分:1.接收server端的请求(接收任务下发)2.将接收到的任务添加到待执行任务队列3.多线程消费任务(执行任务)4.将任务执行结果回写到结果队列5.回调线程消费结果队列,将结果发送至server端。

2024-08-08 20:53:08 917

原创 springboot项目logback日志框架分析

Logback的日志模式由一系列的转换器(converters)组成,每个转换器负责处理日志模式中特定的占位符。当Logback遇到一个占位符时,它查找对应的转换器来处理该占位符,然后将转换的结果插入到最终的日志输出中。上述已经将配置文件xml的内容解析为eventList,内存里也经注册了每个xml节点对应的处理规则,此处就是遍历eventList,根据不同的解析规则做处理配置内容。本文主要分析了 解析logback.xml配置文件的主流程、日志打印的占位符解析、异步日志的实现。:基于时间的滚动策略。

2024-08-07 11:30:33 802

原创 dubbo中provider的线程池分析

今天看到一个复盘,其中一个问题是接口延时高导致dubbo的线程池被打满,因此好奇dubbo具体的线程池实现。,解析这两个问题是dubbo运行的第一步,但在这之前是加载对应的配置解析器。Dispatcher 的不同实现类决定了线程池的策略,具体的配置如下(对于provider,是提供service服务,配置的是。对于consumer,是消费service服务,配置的是。创建了 invoker的实例后,最终调用的是。实例时就创建了,根据不同的配置有不同的实现。dubbo的配置是xml的文件,通常是一个。

2024-08-05 10:19:02 795

原创 outbound-connector 相关逻辑

connector承担的职责 是 zeebe的task跟外部系统通信,其中outboundConnector则是向外部系统发送信息,目前git社区已经支持其中包括 kafka 、rabbitMQ、rest-http、aws、eventBridge等。在代码实现层面,每一个 outboundConnector都是一个 JobHandler,跟我们对接zeebeClient直接定义的jobHandler没什么差别。

2024-06-25 20:17:37 639

原创 inbound-connector相关逻辑

connector承担的职责 是 zeebe的task跟外部系统通信,其中inboundConnector则是监听外部系统的信息,目前git社区已经支持其中包括 kafka 、rabbitMQ、rest-http、sqs、slack等。在代码实现层面,每一个 inboundConnector 就是一个listener,监听外部系统的变化,进而触发zeebe的相关任务。

2024-06-25 20:04:29 909

原创 springboot工程tomcat源码解析以及虚拟线程升级

在Tomcat中,请求被封装成一个任务(task)并提交给线程池处理的逻辑简单描述为:Tomcat通过不同的Connector 和其对应的 ProtocolHandler来 处理进来的请求。对于基于NIO的Connector(如 NioEndpoint ),它会在接收到请求后,将该请求封装成一个任务,并由线程池执行。Connector : 负责接收来自客户端的请求,并且可以有不同的实现,例如基于NIO的NioConnector。

2024-06-21 17:52:02 1077 1

原创 dubbo服务连接管理分析

dubbo是高性能的rpc框架,而选型时,通常会认为其适用的场景是高qps、小包请求,这种说法的基本逻辑是 dubbo是共用连接的,如果单个请求过慢 或者 包体过大,会造成连接资源竞争,进而导致性能下降。那如果已经用了dubbo,而确实请求的包体较大(例如我这里的500k),那么具体会有什么影响呢?本文从这个角度去分析dubbo在连接管理相关的逻辑。

2024-02-26 14:43:57 497

原创 mysql到oracle的ddl迁移

从目标库(mysql)导出一套完成的表结构到源库(oracle)

2024-02-21 22:39:28 429

原创 mybatis的xml解析为sql流程分析

将xml解析成sql的关键逻辑解析

2024-02-21 22:25:46 1280

原创 SSE(server-sent event) - springboot示例

Server-Sent Events(SSE)是一种用于实现服务器向客户端实时推送数据的Web技术。与传统的轮询和长轮询相比,SSE提供了更高效和实时的数据推送机制。SSE基于HTTP协议,允许服务器将数据以事件流(Event Stream)的形式发送给客户端。客户端通过建立持久的HTTP连接,并监听事件流,可以实时接收服务器推送的数据。

2023-07-10 20:27:32 192

转载 Mybatis-Plus整合多数据源

Mybatis-Plus整合多数据源

2023-07-06 14:12:15 186

原创 zeebe的任务队列

zeebe的代码都是异步化处理的,整个项目中都是个中任务的封装,并提交到线程池中处理,任务队列在其中是很重要的一部分,zeebe也有不同维度的多个任务队列,在此梳理下。

2023-07-05 18:25:46 308

原创 zeebe的数据持久化 snapshot-runtime (RocksDB)

snapshot是周期性创建的,仅通过snapshot是无法恢复 在创建snapshot之后产生的事件,因此还需要从日志取出日志回放,完成整个运行状态的恢复。snapshot 通常用于读操作,它表示一个 DB 在某一时间点的一份快照,即一份只读的、不可变的 DB 数据。snapshot是所有运行中的event的投影,代表了当前进程的运行状态,其中包含了所有的active data,例如:已部署的流程、运行中的流程实例、还未执行完的jobs。此操作将 checkpoint 写入到文件系统中指定位置。

2023-07-03 19:48:22 278

原创 zeebe的job超时重试机制

在断电测试中,发现client端拉取job时,若在job执行过程中server端服务宕机(client未发送completeCommand到server端),重启server端后,刚执行到一半的任务会重新执行,而且一般是在server端重启后5分钟左右重新执行, 针对这一现在分析zeebe代码实现的原理。每次activeJob时,会往deadline的列簇中插入数据,之后周期性轮询其中的记录是否超时,取出超时的任务进行对应的处理。,该设置就是重试在5分钟之后执行的原因。此处对应的处理逻辑较为简单,即。

2023-07-03 15:19:39 264 1

原创 zeeb中exporters 导出数据的position管理

该方法是获取对应的exportedId对应的position信息,最终实际是从rocksDB进行获取对应的数据(io.camunda.zeebe.broker.exporter.stream.ExportersState#findExporterStateEntry)此处更新position都是异步执行的,最终执行的方法是:io.camunda.zeebe.broker.exporter.stream.ExporterContainer#updateExporterState(long, byte[])

2023-06-29 20:50:04 165 1

原创 zeebe中exporters 代码分析

数据导出器的顶层接口:io.camunda.zeebe.exporter.api.Exporterio.camunda.zeebe.broker.Broker#buildExporterRepository取出exporters的配置,并遍历加载数据最终调用 io.camunda.zeebe.broker.exporter.repo.ExporterRepository#validate 做实例创建、配置校验io.camunda.zeebe.broker.exporter.stream.Export

2023-06-29 20:32:47 2175 1

原创 zeebe-client 端代码

JobWorker的默认实现为 io.camunda.zeebe.client.impl.worker.JobWorkerImpl#JobWorkerImpl。此时各项参数采用默认配置,具体配置的数值参见 io.camunda.zeebe.client.impl.ZeebeClientBuilderImpl。JobWorker的核心方法为 io.camunda.zeebe.client.impl.worker.JobWorkerImpl#poll。0.3倍的最大jobs活跃数(该值默认为32)

2023-06-29 19:47:32 348 1

原创 zeebe-拉取、执行任务主流程源码分析

发送response的方法:io.camunda.zeebe.gateway.impl.job.InflightActivateJobsRequest#tryToSendActivatedJobs。上述的handler.accept 方法调用的上述的lambda方法(注意debug位置),而其中的handler.apply 方法对应的则是(activateJob流程中)JobIntent 的枚举: io.camunda.zeebe.protocol.record.intent.JobIntent。

2023-06-28 23:56:44 723 1

原创 conductor数据可靠性分析——redis异常时的服务功能可用性梳理

如果redis异常,conductor是什么表现?对应的redis key为: conductor_zlcft.test.WORKFLOW_DEF_NAMES conductor_zlcft.test.WORKFLOW_DEF.coreSatelliteOpen。其对应的配置类为:com.netflix.conductor.contribs.listener.archive.ArchivingWorkflowListenerConfiguration。

2023-05-25 20:49:55 348

原创 orkes-conductor源码分析

个人认为,这是对conductor能力的增强,能在编排场景解决一些对执行耗时有一定要求的场景,但不不应作为主要场景使用,server端调用、递归执行,都会增加server端的负载。该版本在conductor进行了二次开发,目前验证发现其http task的执行非常高效,从这个角度发出分析下其实现原理(原生的http task的实现可参考。orkes-conductor 的http-task的执行相比于原生conductor高效的原因是。)是接收一个http请求开始的,会同步调用到。该方法是任务调度的核心,

2023-05-25 20:10:55 250

原创 conductor server端源码解析(5)-注册、启动一个流程

该方法会判断workflow的input和output数据大小是否需要外部存储(5M~10M),将数据存入都外部存储中 com.netflix.conductor.core.utils.ExternalPayloadStorageUtils#uploadHelper。所有的系统任务管理在 com.netflix.conductor.core.execution.tasks.SystemTaskRegistry。3.调度任务,执行系统任务,将异步执行的系统任务和用户自定义任务push到队列中。

2023-05-25 19:54:31 285

原创 conductor server端源码解析(4)-任务的调度

conductor调度的核心是decider service,其根据当前流程运行的状态,解析出将要执行的任务列表,将任务入队交给worker执行。

2023-05-23 21:32:31 193

原创 conductor server端源码解析(3)-systemTask

具体的执行过程见 com.netflix.conductor.core.execution.tasks.SystemTaskWorker#pollAndExecute。其中具体的任务执行为:com.netflix.conductor.core.execution.tasks.WorkflowSystemTask#start。所有的系统任务实现注册于 com.netflix.conductor.core.execution.tasks.SystemTaskRegistry。

2023-05-23 21:28:55 206

原创 conductor server端源码解析(2)-更新任务信息(mysql实现)

查询流程信息: com.netflix.conductor.dao.ExecutionDAO#getWorkflow(java.lang.String, boolean)若状态为“TIMED_OUT”,则删除queue中的信息: com.netflix.conductor.dao.QueueDAO#remove。若状态为“SCHEDULED”,则推迟队列中的消息:com.netflix.conductor.dao.QueueDAO#postpone。若流程为“终止”状态,则删除队列中的信息,方法直接返回。

2023-05-23 21:19:14 151 1

原创 conductor server端源码解析(1)-查询待执行任务(mysql实现)

调用接口 com.netflix.conductor.rest.controllers.TaskResource#poll。若队列中暂无对应的任务,或者查到的数据少于待请求的数据,则循环等待:(此处timeout默认100ms)4.将task表中的任务状态更新为 “IN_PROGRESS”以及其它参数回写到库中(更新任务数据)1.若task对象不存在或者状态为“终止”态,则删除队列中该任务信息,处理完成,否则进入下一步。该方法做两件事情:1.从库中查询对应的任务信息 2.更新任务状态。

2023-05-23 21:13:09 233 1

原创 conductor client端源码解析(批量拉取)

代码: com.netflix.conductor.client.automator.TaskRunnerConfigurer#TaskRunnerConfigurer。** 在任务积压时,一次pull的任务数量越多,理论上在pull上的平均耗时就越少,消费能力越强,但是,若设置太大,会影响低负载时的耗时;我们走的实现为:com.netflix.dyno.queues.redis.RedisDynoQueue#pop。pull任务时的耗时,批次越大,每次拉取任务的平均耗时就越低,此在梳理下其相关逻辑。

2023-05-23 21:05:24 170

原创 conductor client端源码解析

自定义worker时会继承 com.netflix.conductor.client.worker.Worker该接口中定义了默认值 1000 ,即,若不指定拉取每秒拉取一次任务。

2023-05-23 20:36:37 180 1

原创 conductor部署

conductor部署的一些关键点

2023-05-22 21:20:39 469 1

原创 condutor架构

conductor框架的架构

2023-05-22 20:59:02 339 1

原创 微服务中的通信&saga

0.前言  相关内容主要是阅读《微服务架构设计》的一些所得及吐槽,内容作为笔记、周记的属性更重,若有幸被人看到,欢迎吐槽、指正。1.微服务中的通信一对一一对多同步模式请求/响应无异步模式异步请求/响应 单向通知发布/订阅 发布/异步响应apid的语义化版本控制规范(Semvers)要求版本号由三个部分组成:MAJOR.MINOR.PATCH MAJOR:进行不兼容的更改时MINOR:进行向后兼容的增强时PATCH:进行向后兼容的错误修复时

2021-07-26 01:09:37 240

原创 spring事务注解中timeout配置

要点:Spring事务超时 = 事务开始 到 最后一个Statement创建之间的时间 + 最后一个Statement的执行的时间(即其queryTimeout)设置@Transactional(timout = 1)时,希望是当前方法在一个事务中,且事务执行时间应小于1秒中,若超过1秒则应抛出异常: Transaction timed out: deadline was Mon Jul 05 00:02:18 CST 2021但这其中有一个坑:case1: 抛出Transaction .

2021-07-05 00:08:12 1838 1

原创 零拷贝& mmap

零拷贝零拷贝介绍及原理一次系统调用涉及两次上下文切换DMA 负责将数据从磁盘拷贝到 page Cache,不需要cup参与,此时cpu可以做别的事情传统的拷贝调用read() write()方法,涉及4次上下文切换传统的拷贝(数据从磁盘到网络) 数据流转:磁盘——>page Cache(内核空间缓存) ——>用户空间内存 ——> socket缓存 ——>网卡 一个4次数据拷贝零拷贝有两种实现方式:* mmap + write()* sendfil

2021-06-21 00:42:42 468

原创 微服务底层逻辑&笔记

文章目录0.前言1.单体应用2.微服务2.1 微服务三个维度2.2 微服务是一种架构风格2.2.1 mvc分层2.2.2 六边形风格2.3 定义微服务架构2.3.1 识别操作系统2.3.2 拆分服务总结0.前言  相关内容主要是阅读《微服务架构设计》的一些所得及吐槽,内容作为笔记、周记的属性更重,若有幸被人看到,欢迎吐槽、指正。1.单体应用  单体应用最直观的感受就是一个服务做完所有的事情,java里就是一个可执行jar包。小公司、创业公司适合采用这中架构,创建一个工程就开始干,什么功能往里边怼

2021-06-20 23:50:28 418

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除