字节跳动青训营讲师非常用心给大家整理了课前、中、后的学习内容，同学们自我评估，选择性查漏补缺，便于大家更好的跟上讲师们的节奏，祝大家学习愉快，多多提问交流～
课程：分布式定时任务
概述
本节课程主要分为五个方面：
- 分布式定时任务整体架构
- 控制台Admin详细设计
- 触发器Trigger详细设计
- 调度器Scheduler详细设计
- 执行器Executor详细设计
课前部分主要罗列课程中涉及到的概念。对于不熟悉的概念，同学们可以提前查询预习；课中部分主要罗列每一部分的关键思路，帮助同学们跟上课程的进度；课后部分是一些问题，帮助同学们在课后梳理本课程的重点。
课前
分布式定时任务发展历史
- Linux命令-CronJob
- 单机定时任务-Timer、Ticker
- 单机定时任务-ScheduledExecutorService
- 任务调度- Quartz
- 分布式定时任务
分布式定时任务核心架构
- 控制台Admin
- 触发器Trigger
- 调度器Scheduler
- 执行器Executor
知识点扩充
- 时间轮
- 延时消息
- 离线计算引擎 Hive
- 实时计算引擎 Flink
课中
前言
- 每年春节抖音都会有很多有意思的玩法，如果同学们是字节的后端同学，怎么设计今年春节集卡瓜分20亿的技术方案？
-
业务流程
- 定时扫描抖音用户集卡状态
- 汇总计算用户的瓜分金额
- 定时开奖
-
技术体量
- 亿级用户规模
- 十亿级资金规模
- 百万级读写QPS
-
方案引出
- 自动化 + 定时执行 + 海量数据 + 高效稳定 = 分布式定时任务
发展历程
-
发展历史
-
Linux命令-CronJob
- 单机定时任务-Timer、Ticker
- 单机定时任务-ScheduledExecutorService
- 任务调度- Quartz
- 分布式定时任务
-
概述
-
定义
- 定时任务是指系统为了自动完成特定任务，实时、延时、周期性完成任务调度的过程。
- 分布式定时任务是把分散的、可靠性差的定时任务纳入统一的平台，并实现集群管理调度和分布式部署的一种定时任务的管理方式。
-
特点
-
执行模式
- 单机任务
- 广播任务
- Map任务
- MapReduce任务
-
现状
- 业内流行框架 | | Xxl-job | SchedulerX | TCT | Elastic-job | Saturn | | ----- | ------- | ---------- | --- | ----------- | ------ | | 来源公司 | 美团点评 | 阿里巴巴 | 腾讯 | 当当网 | 唯品会 | | 是否开源 | 是 | 否 | 否 | 是 | 是 | | 任务编排 | 子任务依赖 | 支持 | 支持 | 不支持 | 不支持 | | 任务分片 | 支持 | 支持 | 支持 | 支持 | 支持 | | 高可用 | 支持 | 支持 | 支持 | 支持 | 支持 | | 故障转移 | 支持 | 支持 | 支持 | 支持 | 支持 | | 可视化运维 | 支持 | 支持 | 支持 | 支持 | 支持 |
- 美团点评Xxl-job
- 阿里巴巴SchedulerX
- 腾讯TCT
-
-
关联方案
- 单机定时任务
- 大数据处理引擎
实现原理
-
整体架构
- 核心架构
- 数据流
- 功能架构
控制台Admin
触发器Trigger
方案一：腾讯字节方案
方案二：Quartz方案——时间轮
调度器Scheduler
资源来源
- 业务系统
- 定时任务平台
执行器Executor
业务应用
-
业务应用
- 所有需要定时、延时、周期性执行任务的业务场景，都可以考虑使用分布式定时任务
-
知识面扩充
- 分布式定时任务
- 单机定时任务
- 延时消息
- 离线计算引擎Hive
- 实时计算引擎Flink
课后
- 分布式定时任务可以帮助我们处理哪些业务场景？
- 春节集卡瓜分20亿的玩法，发奖金额计算、实时开奖两个阶段分别用到分布式定时任务什么执行模式？
- 有了分布式定时任务，单机定时任务还有适用场景么？
- 时间轮这种数据结构，在定时/延时场景相比其他数据结构有哪些优势？
- 分布式定时任务的调度中心怎么判断一台执行器的机器处于可被调度状态？
- 你能想到哪些业务场景，实时计算引擎优于分布式定时任务？
课程：消息队列原理与实战
概述
本节课程主要分为五个方面：
- 消息队列的前世今生
- 消息队列-Kafka
- 消息队列-BMQ
- 消息队列-RocketMQ
- 最佳实践
课前部分主要罗列课程中涉及到的概念。对于不熟悉的概念，同学们可以提前查询预习；课中部分主要罗列每一部分的关键思路，帮助同学们跟上课程的进度；课后部分是一些问题，帮助同学们在课后梳理本课程的重点。
课前
消息队列的前世
- 消息队列应用场景
- 消息队列的发展历史
常见消息队列
- Kafka使用场景、架构、高级特性
- Pulsar使用场景、架构、高级特性
- Rocket使用场景、架构、高级特性
课中
消息队列是什么
- 解耦
- 削峰
- 异步
- 日志处理
消息队列的前世今生
消息队列-Kafka
kafka使用场景，业务日志、用户行为数据、Metrics数据
基本概念，Producer、Cluster、Consumer、Topic、Partition
数据迁移、Offset、Partition选主
一条消息从生产到消费是如何处理的，Producer端逻辑、Broker端逻辑、Consumer端逻辑
消息队列-BMQ
Kafka在使用中遇到问题
BMQ架构
BMQ各模块是如何工作的，Broker、Proxy、HDFS、MetaStorage
BMQ多机房容灾
消息队列-RocketMQ
RocketMQ使用场景
RocketMQ和Kafka对比
RocketMQ架构介绍，Producer、Broker、Nameserver、Consumer
一条消息从生产到消费是如何处理的，Producer端逻辑、Broker端逻辑、Consumer端逻辑
消息队列在字节
一些最佳实践的场景，包括数据展示
课后
- 消息队列的应用场景有哪些？
- Kafka的哪些Feature让其可以支撑大吞吐写入的场景？
- Kafka Consumer Rebalance的流程简述？
- BMQ相比较Kafka有哪些优势？
- RocketMQ有哪些特有的Feature？
- RocketMQ事务消息处理流程简述？
- 你认为MQ后面应该如何发展？（开放题）
课程：RPC 原理与实践
概述
本节课程主要分为四个方面：
- RPC 相关的基本概念
- RPC 框架的分层设计
- 衡量 RPC 框架的一些核心指标
- 字节内部 RPC 框架 Kitex 实践分享
课前部分主要罗列课程中涉及到的概念。对于不熟悉的概念，同学们可以提前查询预习；
课中部分主要罗列每一部分的关键思路，帮助同学们跟上课程的进度；
课后部分是一些问题，帮助同学们在课后梳理本课程的重点。
课前
RPC 的基本概念
-
RPC的概念模型：User、User-Stub、RPC-Runtime、Server-Stub、Server
-
IDL(Interface Definition Language) 文件
- Thrift
- Protobuf
- 生成代码
- 编解码（序列化/反序列化）
-
通信协议
- 应用层协议
-
网络通信
-
IO 网络模型
- blocking IO
- unblocking IO
- IO multiplexing
- signal driven IO
- asynchronous IO
-
传输层协议
- TCP
- UDP
-
RPC 框架分层设计
-
编解码层
-
数据格式：
-
语言特定格式
-
文本格式
-
二进制编码
- TLV 编码：Thrift 使用 TLV 编码
- Varint 编码：Protobuf 使用 Varint 编码
-
-
选项：
- 兼容性
- 通用型
- 性能
-
-
传输协议层
-
消息切分
- 特殊结束符
- 变长协议：length+body
-
协议构造
- 以 Thrift 的 THeader 协议为例讲解
-
-
网络通信层
-
网络库
-
核心指标
- 吞吐高
- 延迟低
-
RPC 框架的核心指标
-
稳定性
-
保障策略
- 熔断
- 限流
- 超时
-
请求成功率
- 负载均衡
- 重试
-
长尾请求
- BackupRequest
-
-
易用性
- 开箱即用
- 周边工具
- 扩展性
-
观测性
- Log
- Metric
- Tracing
- 内置观测性服务
- 高性能
字节内部 Kitex 实践分享
- Kitex 整体架构
- 自研网络库 Netpoll
-
性能优化：
- 网络库优化
- 编解码优化
- 合并部署
课中
基本概念
-
相比本地函数调用，RPC调用需要解决的问题
- 函数映射
- 数据转换成字节流
- 网络传输
- 一次 RPC 的完整过程
-
RPC 带来的问题将由 RPC 框架来解决
- 服务宕机如何感知？
- 遇到网络异常应该如何应对？
- 请求量暴增怎么处理？
RPC 框架分层设计
编解码层
-
数据格式
- 语言特定格式：例如 java.io.Serializable
- 文本格式：例如 JSON、XML、CSV 等
- 二进制编码：常见有 Thrift 的 BinaryProtocol，Protobuf，实现可以有多种形式，例如 TLV 编码 和 Varint 编码
-
选型考察点
-
兼容性
-
通用型
-
- 空间开销
- 时间开销
-
- 生成代码和编解码层相互依赖，框架的编解码应当具备扩展任意编解码协议的能力
协议层
- 以 Thrift 的 THeader 协议为例
- 协议解析
网络通信层
- 阻塞 IO 下，耗费一个线程去阻塞在 read(fd) 去等待用足够多的数据可读并返回。
- 非阻塞 IO 下，不停对所有 fds 轮询 read(fd) ，如果读取到 n <= 0 则下一个循环继续轮询。
第一种方式浪费线程（会占用内存和上下文切换开销），第二种方式浪费 CPU 做大量无效工作。而基于 IO 多路复用系统调用实现的 Poll 的意义在于将可读/可写状态通知和实际文件操作分开，并支持多个文件描述符通过一个系统调用监听以提升性能。
网络库的核心功能就是去同时监听大量的文件描述符的状态变化(通过操作系统调用)，并对于不同状态变更，高效，安全地进行对应的文件操作。
RPC 框架核心指标
稳定性
-
保障策略
- 熔断
- 限流
- 超时控制
从某种程度上讲超时、限流和熔断也是一种服务降级的手段 。
-
请求成功率
- 负载均衡
- 重试
-
长尾请求
- BackupRequest
易用性
-
开箱即用
- 合理的默认参数选项、丰富的文档
-
周边工具
- 生成代码工具、脚手架工具
扩展性
- Middleware：middleware 会被构造成一个有序调用链逐个执行，比如服务发现、路由、负载均衡、超时控制等
- Option：作为初始化参数
- 核心层是支持扩展的：编解码、协议、网络传输层
- 代码生成工具也支持插件扩展
观测性
- 三件套：Log、Metric 和 Tracing
-
内置观测性服务，用于观察框架内部状态
- 当前环境变量
- 配置参数
- 缓存信息
- 内置 pprof 服务用于排查问题
高性能
- 连接池和多路复用：复用连接，减少频繁建联带来的开销
- 高性能编解码协议：Thrift、Protobuf、Flatbuffer 和 Cap'n Proto 等
- 高性能网络库：Netpoll 和 Netty 等
字节内部 Kitex 实践分享
- 框架文档 Kitex
-
自研网络库 Netpoll，背景：
a. 原生库无法感知连接状态
b. 原生库存在 goroutine 暴涨的风险
- 扩展性：支持多协议，也支持灵活的自定义协议扩展
-
性能优化，参考 字节跳动 Go RPC 框架 KiteX 性能优化实践
a. 网络优化
- i. 调度优化
- ii. LinkBuffer 减少内存拷贝，从而减少 GC
- iii. 引入内存池和对象池
b. 编解码优化
- i. Codegen：预计算提前分配内存，inline，SIMD等
- ii. JIT：无生产代码，将编译过程移到了程序的加载（或首次解析）阶段，可以一次性编译生成对应的 codec 并高效执行
-
合并部署
a. 微服务过微，引入的额外的传输和序列化开销越来越大
b. 将强依赖的服务统计部署，有效减少资源消耗
课后
- 行业内各个流行的 RPC 框架的优劣对比
- 从第三章节 RPC 的核心指标来看，Kitex 还有哪些功能是欠缺或者需要加强的？
- 了解微服务的新趋势 ServiceMesh，以及 RPC 框架和 ServiceMesh 的关系
- 关于 RPC 框架，业界有哪些新的趋势和概念？
- Netpoll 的优势在哪？相比其他高性能网络库例如 Netty 还有什么不足？
- Flatbuffer 和 Cap'n Proto 等编解码协议为什么高性能？
