- 博客(40)
- 收藏
- 关注
RSS订阅原创 webflux源码解析(5)-response处理
之前的文章前后梳理了接收connection中的msg、将msg转成request、处理request的主流程，当业务代码执行完毕后，对response会有一段处理逻辑，本文对其进行梳理。
2024-08-27 14:32:35
784
原创 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
339
原创 webflux源码解析(3)-reactor netty
完成了从connection中接收请求动作，之后请求会传递到了，进入webflux处理请求的主流程。这个链路上的方法调用了subscribe 方法，触发了响应式调用链的执行
2024-08-20 18:48:08
919
3
原创 webflux源码解析(2)-reactor
分析之前，先看一下reactor提供的顶级接口发布者Publisher是一个可以发送无限序列元素的发布者，允许调用多次，每次调用都会启动一个新的。每个Subscription只能被一个Subscriber使用；Subscriber消费者只能订阅一次Publisher。//发布者/*** 订阅方法* 请求发布者启动数据流* @param s 消费者*/订阅者（消费者）其中只会被调用一次/*** 该方法在调用Publisher#subscribe(Subscriber)后执行。
2024-08-19 17:47:17
1182
原创 webflux源码解析(1)-主流程
WebFlux是Spring 5.0框架推出的一个全新的响应式Web框架，是基于Project Reactor构建的，它旨在利用响应式编程的特性来构建异步非阻塞的应用程序。在io密集型的场景中，使用webflux这类响应式io框架，能大幅提高系统的吞吐量。本文主要是关于其主流程的梳理，包括关键实例的创建、配置等。
2024-08-18 16:26:32
962
原创 xxl-job 源码梳理(2)-服务端
分片指的是任务分片广播执行的概念，当调度中心调度一个设置了分片参数的任务时，任务会被拆分成多个子任务（分片），每个分片会被分配一个唯一的序号（分片参数，通常从0开始）。由于scheduleThread周期性执行，为了处理周期间需要执行的任务，此处会判断，所触发任务后，下一次的待执行时间于当前时间相差不超过5秒，也会添加到时间轮中。是负责触发任务调度的线程，周期性地检查所有的任务计划（Cron表达式定义的任务），如果发现有任务到达执行时间，则将这些即将执行的任务放入到一个“时间轮”（
2024-08-08 21:01:44
773
原创 xxl-job 源码梳理(1)-客户端
上图是xxl-job的架构图，从架构图可以看出，xxl-job 分别有调度中心和执行器两大组成部分本文是关于执行器的梳理，也就是xxlJob客户端的代码，其中有几个关键部分：1.接收server端的请求（接收任务下发）2.将接收到的任务添加到待执行任务队列3.多线程消费任务（执行任务）4.将任务执行结果回写到结果队列5.回调线程消费结果队列，将结果发送至server端。
2024-08-08 20:53:08
949
原创 springboot项目logback日志框架分析
Logback的日志模式由一系列的转换器（converters）组成，每个转换器负责处理日志模式中特定的占位符。当Logback遇到一个占位符时，它查找对应的转换器来处理该占位符，然后将转换的结果插入到最终的日志输出中。上述已经将配置文件xml的内容解析为eventList，内存里也经注册了每个xml节点对应的处理规则，此处就是遍历eventList，根据不同的解析规则做处理配置内容。本文主要分析了 解析logback.xml配置文件的主流程、日志打印的占位符解析、异步日志的实现。：基于时间的滚动策略。
2024-08-07 11:30:33
847
原创 dubbo中provider的线程池分析
今天看到一个复盘，其中一个问题是接口延时高导致dubbo的线程池被打满，因此好奇dubbo具体的线程池实现。，解析这两个问题是dubbo运行的第一步，但在这之前是加载对应的配置解析器。Dispatcher 的不同实现类决定了线程池的策略，具体的配置如下（对于provider，是提供service服务，配置的是。对于consumer，是消费service服务，配置的是。创建了 invoker的实例后，最终调用的是。实例时就创建了，根据不同的配置有不同的实现。dubbo的配置是xml的文件，通常是一个。
2024-08-05 10:19:02
835
原创 outbound-connector 相关逻辑
connector承担的职责 是 zeebe的task跟外部系统通信，其中outboundConnector则是向外部系统发送信息，目前git社区已经支持其中包括 kafka 、rabbitMQ、rest-http、aws、eventBridge等。在代码实现层面，每一个 outboundConnector都是一个 JobHandler，跟我们对接zeebeClient直接定义的jobHandler没什么差别。
2024-06-25 20:17:37
656
原创 inbound-connector相关逻辑
connector承担的职责 是 zeebe的task跟外部系统通信，其中inboundConnector则是监听外部系统的信息，目前git社区已经支持其中包括 kafka 、rabbitMQ、rest-http、sqs、slack等。在代码实现层面，每一个 inboundConnector 就是一个listener，监听外部系统的变化，进而触发zeebe的相关任务。
2024-06-25 20:04:29
927
原创 springboot工程tomcat源码解析以及虚拟线程升级
在Tomcat中，请求被封装成一个任务（task）并提交给线程池处理的逻辑简单描述为：Tomcat通过不同的Connector 和其对应的 ProtocolHandler来 处理进来的请求。对于基于NIO的Connector（如 NioEndpoint ），它会在接收到请求后，将该请求封装成一个任务，并由线程池执行。Connector : 负责接收来自客户端的请求，并且可以有不同的实现，例如基于NIO的NioConnector。
2024-06-21 17:52:02
1140
1
原创 dubbo服务连接管理分析
dubbo是高性能的rpc框架，而选型时，通常会认为其适用的场景是高qps、小包请求，这种说法的基本逻辑是 dubbo是共用连接的，如果单个请求过慢 或者 包体过大，会造成连接资源竞争，进而导致性能下降。那如果已经用了dubbo，而确实请求的包体较大（例如我这里的500k），那么具体会有什么影响呢？本文从这个角度去分析dubbo在连接管理相关的逻辑。
2024-02-26 14:43:57
532
原创 SSE(server-sent event) - springboot示例
Server-Sent Events（SSE）是一种用于实现服务器向客户端实时推送数据的Web技术。与传统的轮询和长轮询相比，SSE提供了更高效和实时的数据推送机制。SSE基于HTTP协议，允许服务器将数据以事件流（Event Stream）的形式发送给客户端。客户端通过建立持久的HTTP连接，并监听事件流，可以实时接收服务器推送的数据。
2023-07-10 20:27:32
207
原创 zeebe的任务队列
zeebe的代码都是异步化处理的，整个项目中都是个中任务的封装，并提交到线程池中处理，任务队列在其中是很重要的一部分，zeebe也有不同维度的多个任务队列，在此梳理下。
2023-07-05 18:25:46
331
原创 zeebe的数据持久化 snapshot-runtime (RocksDB)
snapshot是周期性创建的，仅通过snapshot是无法恢复 在创建snapshot之后产生的事件，因此还需要从日志取出日志回放，完成整个运行状态的恢复。snapshot 通常用于读操作，它表示一个 DB 在某一时间点的一份快照，即一份只读的、不可变的 DB 数据。snapshot是所有运行中的event的投影，代表了当前进程的运行状态，其中包含了所有的active data，例如：已部署的流程、运行中的流程实例、还未执行完的jobs。此操作将 checkpoint 写入到文件系统中指定位置。
2023-07-03 19:48:22
303
原创 zeebe的job超时重试机制
在断电测试中，发现client端拉取job时，若在job执行过程中server端服务宕机（client未发送completeCommand到server端），重启server端后，刚执行到一半的任务会重新执行，而且一般是在server端重启后5分钟左右重新执行， 针对这一现在分析zeebe代码实现的原理。每次activeJob时，会往deadline的列簇中插入数据，之后周期性轮询其中的记录是否超时，取出超时的任务进行对应的处理。，该设置就是重试在5分钟之后执行的原因。此处对应的处理逻辑较为简单，即。
2023-07-03 15:19:39
290
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
186
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
2292
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
378
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
764
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
399
原创 orkes-conductor源码分析
个人认为，这是对conductor能力的增强，能在编排场景解决一些对执行耗时有一定要求的场景，但不不应作为主要场景使用，server端调用、递归执行，都会增加server端的负载。该版本在conductor进行了二次开发，目前验证发现其http task的执行非常高效，从这个角度发出分析下其实现原理（原生的http task的实现可参考。orkes-conductor 的http-task的执行相比于原生conductor高效的原因是。）是接收一个http请求开始的，会同步调用到。该方法是任务调度的核心，
2023-05-25 20:10:55
274
原创 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
303
原创 conductor server端源码解析(4)-任务的调度
conductor调度的核心是decider service，其根据当前流程运行的状态，解析出将要执行的任务列表，将任务入队交给worker执行。
2023-05-23 21:32:31
217
原创 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
242
原创 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
163
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
251
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
195
原创 conductor client端源码解析
自定义worker时会继承 com.netflix.conductor.client.worker.Worker该接口中定义了默认值 1000 ，即，若不指定拉取每秒拉取一次任务。
2023-05-23 20:36:37
201
1
原创 微服务中的通信&saga
0.前言 相关内容主要是阅读《微服务架构设计》的一些所得及吐槽，内容作为笔记、周记的属性更重，若有幸被人看到，欢迎吐槽、指正。1.微服务中的通信一对一一对多同步模式请求/响应无异步模式异步请求/响应 单向通知发布/订阅 发布/异步响应apid的语义化版本控制规范（Semvers）要求版本号由三个部分组成：MAJOR.MINOR.PATCH MAJOR:进行不兼容的更改时MINOR:进行向后兼容的增强时PATCH:进行向后兼容的错误修复时
2021-07-26 01:09:37
257
原创 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
1884
1
原创 零拷贝& mmap
零拷贝零拷贝介绍及原理一次系统调用涉及两次上下文切换DMA 负责将数据从磁盘拷贝到 page Cache，不需要cup参与，此时cpu可以做别的事情传统的拷贝调用read() write()方法，涉及4次上下文切换传统的拷贝(数据从磁盘到网络) 数据流转：磁盘——>page Cache(内核空间缓存) ——>用户空间内存 ——> socket缓存 ——>网卡 一个4次数据拷贝零拷贝有两种实现方式：* mmap + write()* sendfil
2021-06-21 00:42:42
515
原创 微服务底层逻辑&笔记
文章目录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
436
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人