YZDHY的博客

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

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

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

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

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

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

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