YZDHY的博客

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

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

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

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

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

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

数据导出器的顶层接口：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

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）

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