0%

在 xxl-job-admin 中 XxlJobScheduler 是一个重要的类,初始化了所有的会用到的组件:

  • JobScheduleHelper 任务调度组件
  • JobTriggerPoolHelper 任务执行的线程池组件
  • JobRegistryHelper 维护执行器 executor 信息的组件
  • JobLogReportHelper 日志访问组件
  • JobCompleteHelper 回调处理组件
  • JobFailMonitorHelper 失败监听组件,负责告警等

几个组件都是单独的线程或者线程来进行核心逻辑的处理,所以在一开始会被初始化,在后台持续工作。

同时 XxlJobScheduler 还持有了一个 address -> executorClientMap,之后在执行任务时候是通过具体的地址取得 Client 对象(一个 Http 代理)来通知执行器执行。

组件的功能

JobRegistryHelper

这一部分职责比较简单,主要负责其他 Admin 和 Executor 的注册和移除。内部有两部分:

  • registryOrRemoveThreadPool 收到的注册或者移除请求都交给线程池异步处理。
  • registryMonitorThread 定期清理超过 3 个心跳周期(3*30s)没有请求 register 的其他 Admin、Executor,同时更新对应的 XxlJobGroup 记录。
阅读全文 »

MySQL

来看看 MySQL 保证数据不丢失的方案:

  1. 配置 sync_binlog=1 每次事务提交 binlog 都进行刷盘;
  2. 配置 innodb_flush_log_at_trx_commit=1 每次事务提交 redo_log 都进行刷盘;

bin_log、redo_log 持久化的意义不同:

  • bin_log 每次都进行持久化,保障了归档内容的完整性;
  • redo_log 每次持久化保证了故障恢复的能力,不丢失已完成的事务;
  • redo_log 二阶段提交的机制,完整恢复已提交事务需要 sync_binlog=1 配合。
    • 如果 redo_log 中事务为 commited,则恢复数据页
    • 如果 redo_log 中事务为 prepare,则判断 binlog,binlog 中存在则恢复,不存在则舍弃

主备通常不会采用半同步复制方案。只有半同步复制方案下才能保障主机宕机依旧能保有全部数据,但是这影响性能且容易让主机不稳定。异步方案则始终存在主备延迟问题,减轻延迟主要是降低从机负载、减少主机慢 MDL DDL。

阅读全文 »

Kafka 架构

  • Topic 消息主题,用来业务上区分不同类型的消息。
  • Partition 物理分区,是一个有消息组成的队列,消息的 offset 记录着它在某个 Partition 下的位置;每个 Topic 下都有若干 PartitionPartitio 上消息被消费 Kafka 并不关心,保留指定时间后删除或者 Partition 文件过大时删除
    • Leader Kafka 这里 Leader 是针对某个 Partition 而言,负责和 Producer、Consumer 交互
    • FollowerLeader 一样针对 Partitio 的概念,只负责同步备份数据,做 Leader 的备胎
  • Broker Kafka 服务端,即一个 Kafka 实例,会将自己的信息、Topic 信息注册到 ZK 上。
  • Producer Consumer 消息生产者和消费者,没什么好多说的。Consumer 也会向 ZK 注册自己的信息用来负载均衡.
    • ConsumerGroup 消费者组,一条消息只会被同一组内的一个 Consumer 消费,可以被不同组的 Consumer 消费;这个配置决定了 Kafka 表现为广播模式还是单播模式。

Kafka 重要术语

  • ISR In-Sync Replicas 同步中的 Partition 集合,其中包括 Leader 本身,刨除了落后过多的副本。
    阅读全文 »

集群角色

Leader
  • 集群内只有一个 Leader,负责调度处理事务请求,保证事务顺序性
  • 和 Follower 一样可以处理客户端的读请求
  • Leader 也是集群内部服务的调度者
Follower
  • 处理客户端的读请求;事务请求会转发给 Leader 处理
  • 参与投票,包括事务 Proposal、Leader 选举
Observer(3.3.0+)
  • 处理客户端的读请求;事务请求会转发给 Leader 处理
  • 不参与任何投票,无论是选举还是事务写过半成功;也会不作为 Leader 候选者
  • 因为不会成为 Leader, 所以不需要对数据进行持久化,故障恢复时会从 Leader 同步整个命名空间
  • 添加 Observer 可以在不降低事务能力的同时增加读请求的吞吐量

ZAB 协议

ZK 保证各服务端同步的核心是他的 Zookeeper Atomic Broadcast 协议。ZAB 被使用在 ZK 的选举过程和同步过程中。

主机选举
  1. Server 进入 Looking 状态,每个 Server 发出投票给其他通信的 Server,主要内容包含
    • id(sid) 被推举的 Server 标识,初始情况下是本机 sid
    • zxid 被推举的 Server 的 zxid,初始情况下是本机的 zxid
    • electionEpoch 选举纪元,判断收到的投票是否是本轮选票
  2. Server 接收他人投票,验证本机状态和选票有效性
    阅读全文 »

应用限制的修改

在调优过程中,在修改应用程序本身参数之前,需要确认系统环境的配置是否满足要求。涉及到内存、文件描述符、文件大小等一系列的限制。而由于系统的保守,一般服务端应用的需求会大于系统的默认限制。那么如何查看和修改,就是首先要解决的问题了。

在 Linux 中,对应用程序的限制,首先可以从 ulimit 着手。

查看用户程序系统限制

使用 ulimit -{op} 来查看对应的变量限制。ulimit 是基于 PAM 的用户限制模块,一般除了一些系统的程序,一般用户都受此限制。先罗列几个常用的:

1
2
3
4
5
ulimit -a # 查看全部
ulimit -n # 文件描述符上限
ulimit -l # 应用程序允许锁定的内存量
ulimit -m # 应用程序允许占用的内存大小
ulimit -s # 应用程序线程栈大小
阅读全文 »

jps

查看 Java 进程及其相关信息。
常用用法:

1
2
jps # 所有 java 进程
jps -mv # 所有 java 进程及启动参数

常用参数:

  • l:输出启动类全类名
  • m:显示 main 方法接收到的参数
  • v:显示 JVM 进程及其接收的参数,通常配合 m 得到进程的启动命令
阅读全文 »

对 Netty ByteBuf 的探究

ByteBuf 是 Netty 在通信过程中数据传递的容器,类似于 Java NIO 中的 ByteBuffer,是通道 Channel 传输过程中的介质。

ByteBuf 类型

从池化与否上看,分为池化的 PooledByteBuf 和非池化的 UnpooledByteBuf

而从内存属性上看 ByteBuf 有着使用堆内存HeapByteBuf 以及基于直接内存映射DirectByteBuf。Netty 的高效也体现在 ByteBuf 的使用上,以 NIOEventLoop 来举例,在通道读写是后使用了 PooledDirectByteBuf 将字节缓冲的高效发挥到了极致。

阅读全文 »

这里仅记录一下 ByteBuf 相关的一下内存配置参数和默认情况,分析一下 Allocator 的组成,为分析 ByteBuf 做一些概念上的铺垫。

首先看几个 PooledByteBifAllocator 中的静态变量,挑了几个说明一下:

1
2
3
4
5
6
7
8
9
10
// 默认的 arena 数量,一个对应 HeapBuf 一个对应 DirectBuf
private static final int DEFAULT_NUM_HEAP_ARENA;
private static final int DEFAULT_NUM_DIRECT_ARENA;
// 默认 pageSzie、order 默认的 chunk = pageSize << order
private static final int DEFAULT_PAGE_SIZE;
private static final int DEFAULT_MAX_ORDER;
// 三个不同大小的 cacheSize
private static final int DEFAULT_TINY_CACHE_SIZE;
private static final int DEFAULT_SMALL_CACHE_SIZE;
private static final int DEFAULT_NORMAL_CACHE_SIZE;
阅读全文 »

内核配置

先来了解几个关于网络的内核配置。

目录

以 CentOS 7 为例,目录 /proc/sys/ 存放着内核相关配置,其中网络相关的主要集中在 /proc/sys/net/core//proc/sys/net/ipv4//proc/sys/net/ipv6/ 几个目录下。在这几个目录下,不同参数名称对应一个文件,修改文件值可以调整对应参数。

同时,想要修改 /proc/sys/ 下参数也可以通过修改 /etc/sysctl.conf 配置文件达到目的。如:想要修改 /proc/sys/net/ipv4/tcp_max_syn_backlog1024,可以添加一行 net.ipv4.tcp_max_syn_backlog = 1024。也可以将自定义配置放入 /etc/sysctl.d/ 中,自定义 60-<custom>.conf 的文件。具体可详见另一篇更改系统设置的文章。

阅读全文 »

TCP Options

TCP 报头通常包含 20 字节信息。但是同时可以携带额外的选项用来说明额外的信息(下图 Options)。

TCP-header.png

每一组选项包含 1 个字节的类型标识,1 个字节的长度声明,n 个字节的具体数据,最大不超过 40 字节。

阅读全文 »