《中间件性能挑战赛--分布式统计和过滤的链路追踪》Java 选手分享

2020年6月份天池举办的《中间件性能挑战赛》可谓是异常激烈，本人抽业余时间报名参与，感受比赛惨烈的同时，也有诸多感慨哈，总结一个多月的赛程，多少有一些心得与大家分享

本文原创地址：https://www.cnblogs.com/xijiu/p/14235551.html 转载请注明

赛题

赛题地址： https://tianchi.aliyun.com/competition/entrance/231790/information

实现一个分布式统计和过滤的链路追踪

  • 赛题背景

    本题目是另外一种采样方式(tail-based Sampling)，只要请求的链路追踪数据中任何节点出现重要数据特征（错慢请求），这个请求的所有链路数据都采集。目前开源的链路追踪产品都没有实现tail-based Sampling，主要的挑战是：任何节点出现符合采样条件的链路数据，那就需要把这个请求的所有链路数据采集。即使其他链路数据在这条链路节点数据之前还是之后产生，即使其他链路数据在分布式系统的成百上千台机器上产生。

  • 整体流程

    用户需要实现两个程序，一个是数量流（橙色标记）的处理程序，该机器可以获取数据源的http地址，拉取数据后进行处理，一个是后端程序（蓝色标记），和客户端数据流处理程序通信，将最终数据结果在后端引擎机器上计算。具体描述可直接打开赛题地址 https://tianchi.aliyun.com/competition/entrance/231790/information。此处不再赘述

    image

解题

题目分析

可将整体流程粗略分为三大部分

  • 一、front 读取 http stream 至 front 节点
    • 网络io
  • 二、front 节点处理数据
    • cpu处理
  • 三、将 bad traces 同步至 backend，backend 经过汇总计算完成上报
    • 网络传输 + cpu

遵循原则：各部分协调好，可抽象为生成、消费模型，切勿产生数据饥饿；理想效果是stream流完，计算也跟着马上结束

方案一 （trace粒度）

最先想到的方案是以trace细粒度控制的方案

因题目中明确表明某个 trace 的数据出现的位置前后不超过2万上，故每2万行是非常重要的特征

  • ① 按行读取字符流
    • BufferedReader.readLine()
  • ② 分析计算
    • 在某个 trace 首次出现时（p），记录其结束位置 p + 2w，并将其放入待处理队列（queue）中
    • 如果当前 trace 为 badTrace，将其放入 BadTraceSet 中
    • 每处理一行，均从 queue 队列中拿出 firstElement，判断是否与之相等，如果相等，且为 badTrace，那么进入第3步
  • ③ 向 backend 发送数据 注：后续所有涉及网络交互的部门均为 netty 异步交互
    • 将当前 trace 对应的所有数据按照 startTime 排序
    • 将排好序的数据与该 trace 最后结束位置 endPosition 一并发送至 backend 节点
  • ④ backend 通知 front2 发送数据
    • backend 接收到从 front1 发送过来的 trace 数据，向 front2 发送通知，要求其发送该 trace 的全部数据
    • 注：此处交互有多种情况，在步骤5时，会具体说明
  • ⑤ front2 将数据发送至 backend 此处列举所有可能发生的情况
    • 场景 1：front1 主动上报 traceA 后，发现 front2 已经上报该 traceA 数据，结束
    • 场景 2：front1 主动上报 traceA 后，front2 未上报，front2 发现该trace在已就绪集合中，排序、上报，结束
    • 场景 3：front1 主动上报 traceA 后，front2 未上报，且 front2 的已就绪集合没有该 trace，在错误集合中发现该 trace，结束 注：因该 trace 存在于 badTraceSet 中，故将来某个时刻 front2 一定会主动上报该 trace
    • 场景 4：front1 主动上报 traceA 后，front2 未上报，且 front2 的已就绪集合没有该 trace，那么等待行数超限后，检查该 trace 是否存在于 badTraceSet 中，如果已存在，结束
    • 场景 5：front1 主动上报 traceA 后，front2 未上报，且 front2 的已就绪集合没有该 trace，那么等待行数超限后，检查该 trace 是否存在于 badTraceSet 中，如果不存在，排序、上报，结束 注：即便是 front2 中不存在该trace的信息，也需要上报
  • ⑥ 结果计算
    • 在收集到 front1 跟 front2 数据后，对2个有序集合进行 merge sort 后，计算其 MD5

方案分析

此方案的跑分大致在 25s 左右，成绩不甚理想，总结原因大致可分为以下几种

  • 交互场景较为复杂
  • 需要维护一块缓存区域
    • 如果该缓存区域通过行数来失效过期数据的话，那么需要额外的分支计算来判断过期数据，拖慢整体响应时间
    • 如果通过缓存大小来自动失效过期数据的话，那么大小设置很难平衡，如果太小，则可能会失效一些正常数据，导致最终结果不正确，如果太大，又会导致程序反应变慢，带来一系列不可控的问题

基于上述原因，为了充分利用 2万行的数据特征，引入方案二

方案二 （batch粒度）

说明：为了更优雅处理数据过期及充分利用2万行特性，故衍生出此版本

因题目中明确表明某个trace的数据出现的位置前后不超过2万上，故每2万行数据可作为一个批次存储，过期数据自动删除

  • ① 按行读取字符流

    • BufferedReader.readLine()

  • ② 每2万行数据作为一个batch，并分配唯一的batchId（自增即可），此处涉及大量cpu计算，分为2部分

    • 在每行的 tag 部分寻找error=1或http.status_code!=200的数据并将其暂存
    • 将 traceId 相同的 span 数据放入预先开辟好空间的数据结构List<Map<String, List<String>>>中，方便后续 backend 节点拿取数据
    • 注：此处下载数据与处理数据并行执行，交由2个线程处理，一切为了提速

  • ③ 上报 badTraceId

    • 每切割 2万行，统计所有的 badTraceId，与 batchId 一并上报至 backend
    • 因同一个 span 数据可能分布在2个 front 节点中，所以有可能 front1 存在错误数据，front2 却全部正确，2个 front 又不能直接通信，所以此时需要同步至 backend，由 backend 统计全量的 badTraceIds
    • front 收到 backend 的通知后，进行当前批次错误 trace 数据的统计，因当前批次的数据有可能出现在上一个批次跟下一个批次，故一定要等到处理每行数据的线程已经处理完 currentBatchNum+1 个线程后，方能执行操作

  • ④ 通知2个 front 节点发送指定 traceIds 的全量数据

    • backend 主动向2个 front 发送获取指定 traceIds 的全量数据通知
    • front 将 span 数据排好序后上报至 backend
    • backend 执行二路归并排序后，计算整体 span 的 md5 值，反复循环，直至数据流读取完毕 注：因2个 front 节点为2核4g，backend 节点为单核2g，为减少 backend 压力，将部分排序工作下放至 front 节点

  • ⑤ 计算结果

    • 归并排序，计算最终结果

方案总结

当前方案耗时在20s左右，统计发现字符流的读取耗时15s，其他耗时5s，且监控发现各个缓冲区没有发现饥饿、过剩的情况，所以当前方案的瓶颈还是卡在字符流的读取、以及cpu判断上，所以一套面向字节流处理的方案呼之欲出

  • 跟读BufferedReader源码，发现其将字节流转换字符流做了大量的工作，也是耗时的源头，故需要将当前方案改造为面向字节的操作

方案三 （面向字节）

字符处理是耗时的根源，只能将方案改造为面向字节的方式，倘若如此，java 的大部分数据结构不能再使用

大层面的设计思想与方案二一致，不过面向字节处理的话，从读取流、截断行、判断是否为bad trace、数据组装等均需为字节操作

  • 好处：预分配内存，面向字节，程序性能提高
  • 弊端：编码复杂，需自定义数据协议

  • ① 读取字节流

    • 程序在初始化时，预先分配10个字节数据 byte[]，每个数组存放10M数据
    • io 与 cpu 分离，将读取数据任务交个某个独立线程，核心线程处理cpu

  • ② 数据处理

    • 用固定内存结构 int[20000] 替换之前动态分配内存的数据结构体 List<Map<String, List<String>>>，只记录每行开始的 position
    • 同时将 bad trace id 存入预先分配好的数组中

  • ③ 上报 badTraceId

    • 同方案二

  • ④ 通知2个 front 节点发送指定 traceIds 的全量数据

    • backend 主动向2个 front 发送获取指定 traceIds 的全量数据通知
    • 因在步骤二时，并没有针对 trace 进行数据聚合，所以在搜集数据时，需要遍历int[20000]，将符合要求的 trace 数据放入自定义规范的byte[] 注：刚开始设计的（快排+归并排序）的方案效果不明显，且线上的评测环境的2个 front 节点压力很大，再考虑到某个 trace 对应的 span 数据只有几十条，故此处将所有的排序操作都下放给 backend 节点，从而减轻 front 压力
    • 因 span 为变长数据，故自定义规范byte[]存储数据的设计如下
      • 预先分配10Mbyte[]，来存储一个批次中的所有 bad trace 对应 span 数据
      • 用2个 byte 存放下一个 span 数据的长度
      • 存储 span 数据
      • 最后返回byte[]及有效长度

  • ⑤ 计算结果

    • 排序，计算最终结果

线程并发

  • A-Thread: slot 粒度，读取 http stream 线程
  • B-Thread: block 粒度，处理 slot 中的 block，将 block 数据按行切割、抓取 bad trace id 等
  • C-Thread: block 粒度，响应 backend 拉取数据的请求
阻塞场景
  • A-Thread 读取 http stream 中数据后，将其放入下一个缓存区，如果下一个缓冲区还没有被线程C消费，那么A-Thread 将被阻塞
  • B-Thread 处理数据，如果B-Thread下一个要处理的byte[]数据A线程还未下载完毕，那么B-Thread将被阻塞（io阻塞）
  • C-Thread 为拼接 bad trace 的线程，需要 previous、current、next 3个 batch 都 ready后，才能组织数据，当B-Thread还未处理完next batch 数据时，C-Thread将被阻塞
解决思路
  • A-B 同步：10个 slot 分配10个Semaphore，为 A-Thread 与 B-Thread 同步服务，A-Thread 产生数据后，对应 slot 的信号量+1，B-Thread 消费数据之前，需要semaphore.acquire()
  • B-C 同步：通过volatile及纳秒级睡眠Thread.sleep(0, 2)实现高效响应。实际测试，某些场景中，该组合性能超过Semaphore；C-Thread 发现 B-Thread 还未产出 next batch 的数据，那么进入等待状态
  • A-C 同步：同样利用volatile及纳秒级睡眠Thread.sleep(0, 2)

JVM调参

打印gc输出日志时发现，程序会发生3-5次 full gc，导致性能欠佳，分析内存使用场景发现，流式输出的数据模型，在内存中只会存在很短的一段时间便会失效，真正流入老年代的内存是很小的，故应调大新生代占比

java -Dserver.port=$SERVER_PORT -Xms3900m -Xmx3900m -Xmn3500m -jar tailbaseSampling-1.0-SNAPSHOT.jar &

直接分配约 4g 的空间，其中新生代占 3.5g，通过观测 full gc 消失；此举可使评测快2-3s

方案总结

此方案最优成绩跑到了5.7s，性能有了较大提升，总结快的原因如下：

  • 面向字节
  • 内存预分配；避免临时开辟内存
  • 使用轻量级锁
  • 避免程序阻塞或饥饿

奇技淫巧

奇技淫巧，俗称偷鸡，本不打算写该模块，不过很多上分的小技巧都源于此，真实的通用化场景中，可能本模块作用不大，不过比赛就是这样，无所不用其极。。。

快速读取字节数组

因java语言设计缘故，凡事读取比 int 小的数据类型，统一转为 int 后操作，试想以下代码

while ((byteNum = input.read(data)) != -1) {
	for (int i = 0; i < byteNum; i++) {
		if (data[i] == 10) {
			count++;
		}
	}
}

大量的字节对比操作，每次对比，均把一个 byte 转换为 4个 byte，效率可想而知

一个典型的提高字节数组对比效率的例子，采用万能的Unsafe，一次性获取8个byte long val = unsafe.getLong(lineByteArr, pos + Unsafe.ARRAY_BYTE_BASE_OFFSET); 然后比较2个 long 值是否相等，提速是成倍增长的，那么怎么用到本次赛题上呢？

span数据是类似这样格式的

193081e285d91b5a|1593760002553450|1e86d0a94dab70d|28b74c9f5e05b2af|508|PromotionCenter|DoGetCommercialStatus|192.168.102.13|http.status_code=200&component=java-web-servlet&span.kind=server&bizErr=4-failGetOrder&http.method=GET

用"|"切割后，倒数第二位是ip，且格式固定为192.168.***.***，如果采用Unsafe，每次读取一个 int 时，势必会落在192.168.中间，有4种可能192.、92.1、2.16、.168，故可利用此特性，直接进行 int 判断

int val = unsafe.getInt(data, beginPos + Unsafe.ARRAY_BYTE_BASE_OFFSET);
if (val == 775043377 || val == 825111097 || val == 909192754 || val == 943075630) {
}

此“技巧”提速1-2秒

大循环遍历

提供2种遍历字节数组方式，哪种效率更高

  • 方式1

    byte[] data = new byte[1024 * 1024 * 2];
int byteNum;
while ((byteNum = input.read(data)) != -1) {
	for (int i = 0; i < byteNum; i++) {
		if (data[i] == 10) {
			count++;
		}
	}
}

  • 方式2

    byte[] data = new byte[1024 * 1024 * 2];
int byteNum;
int beginIndex;
int endIndex;
int beginPos;
while ((byteNum = input.read(data)) != -1) {
	beginIndex = 0;
	endIndex = byteNum;
	beginPos = 0;
	while (beginIndex < endIndex) {
		int i;
		for (i = beginPos; i < endIndex; i++) {
			if (data[i] == 124) {
				beginPos = i + 1;
				times++;
				break;
			} else {
				if (data[i] == 10) {
					count++;
					beginIndex = i + 1;
					beginPos = i + 1;
					break;
				}
			}
		}
		if (i >= byteNum) {
			break;
		}
	}
}

两种方式达到的效果一样，都是寻找换行符。方式2不同的是，每次找到换行符都 break 掉当前循环，然后从之前位置继续循环。其实这个小点卡了我1个星期，就是将字符流转换为字节流时，性能几乎没有得到提高，换成方式2后，性能至少提高一倍。为什么会呈现这样一种现象，我还没找到相关资料，有知道的同学，还望不吝赐教哈

结束

这种cpu密集型的赛题，一向是 c/cpp 大展身手的舞台，前排几乎被其霸占。作为一名多年 crud 的 javaer，抽业余时间参加的比赛，最终拿到了集团第6的成绩

最终比赛成绩贴上哈

posted @ 2021-01-05 14:17  昔久  阅读(854)  评论(7)  编辑  收藏  举报