阅读视图

初期规划由服务端基于 PAG 技术合成，为了让用户可以更自由的定制专属球星卡，经多端评估后确定：由 H5 端承接 “图片交互调整 - 球星卡生成” 核心链路，支持用户单指拖拽、双指缩放 / 旋转人像，待调整至理想位置后触发合成。而 PAG 作为腾讯自研开源的动效工作流解决方案，凭借跨平台渲染一致性、图层实时编辑、轻量化文件性能，能精准匹配需求，成为本次核心技术选型。

鉴于 H5 端需落地该核心链路，且流程涉及 PAG 技术应用，首先需对 PAG 技术进行深入了解，为后续开发与适配奠定基础。

二、PAG是什么？

这里简单介绍一下，PAG 是腾讯自研并开源的动效工作流解决方案，核心是实现 Adobe After Effects（AE）动效的一键导出与跨平台应用，包含渲染 SDK、AE 导出插件（PAGExporter）、桌面预览工具（PAGViewer）三部分。

它导出的二进制 PAG 文件压缩率高、解码快，能集成多类资源；支持 Android、iOS、Web 等全平台，且各端渲染一致、开启 GPU 加速；既兼容大部分 AE 动效特性，也允许运行时编辑 —— 比如替换文本 / 图片、调整图层与时间轴，目前已广泛用于各类产品的动效场景。

已知业界中图片基础编辑（如裁剪、调色）、贴纸叠加、滤镜渲染等高频功能，在客户端发布器场景下已广泛采用 PAG技术实现，这一应用趋势在我司及竞品的产品中均有体现，成为支撑这类视觉交互功能的主流技术选择。

正是基于PAG 的跨平台渲染、图层实时编辑特性，其能精准承接 H5 端‘图片交互调整 + 球星卡合成’的核心链路，解决服务端固定合成的痛点，因此成为本次需求的核心技术选型。

为了让大家更直观地感受「用篮球认识我」活动中 “用户上传图片生成专属球星卡” 玩法，我们准备了活动实际效果录屏。通过录屏，你可以清晰看到用户如何通过单指拖拽、双指缩放 / 旋转人像，完成构图调整后生成球星卡的全过程。

截屏2025-12-26 下午2.53.53.png

截屏2025-12-26 下午2.54.01.png

接下来，我们将围绕业务目标，详细拆解实现该链路的具体任务优先级与核心模块。

三、如何实现核心交互链路？

结合「用篮球认识我」球星卡生成的核心业务目标，按‘基础功能→交互体验→拓展能力→稳定性’优先级，将需求拆解为以下 6 项任务：

PAG 播放器基础功能搭建：实现播放 / 暂停、图层替换、文本修改、合成图导出，为后续交互打基础；
图片交互变换功能开发：支持单指拖拽、双指缩放 / 旋转，满足人像构图调整需求；
交互与预览实时同步：将图片调整状态实时同步至 PAG 图层，实现 “操作即预览”；
批量合成能力拓展：基于单张合成逻辑，支持一次性生成多张球星卡（依赖任务 1-3）；
全链路性能优化：优化 PAG 实例释放、图层渲染效率，保障 H5 流畅度（贯穿全流程）；
异常场景降级兼容：针对 SDK 不支持场景，设计静态图层、服务端合成等兜底方案（同步推进）。

在明确核心任务拆解后，首要环节是搭建 PAG 播放器基础能力 —— 这是后续图层替换、文本修改、球星卡合成的前提，需从 SDK 加载、播放器初始化、核心功能封装逐步落地。

四、基础PAG播放器实现

加载PAG SDK

因为是首次接触PAG ，所以在首次加载 SDK 环节便遇到了需要注意的细节：

libpag 的 SDK 加载包含两部分核心文件：

主体 libpag.min.js
配套的 libpag.wasm

需特别注意：默认情况下，wasm文件需与 libpag.min.js 置于同一目录，若需自定义路径，也可手动指定其位置。（加载SDK参考文档：pag.io/docs/use-we…

在本项目中，我们将两个文件一同上传至 OSS的同一路径下：

h5static.xx/10122053/li… h5static.xx/10122053/li…

通过 CDN 方式完成加载，确保资源路径匹配。

SDK加载核心代码：

const loadLibPag = useCallback(async () => {
  // 若已加载，直接返回
  if (window.libpag) {
    return window.libpag
  }
  
  try {
    // 动态创建script标签加载SDK
    const script = document.createElement('script')
    script.src = 'https://h5static.XX/10122053/libpag.min.js'
    document.head.appendChild(script)
    
    return new Promise((resolve, reject) => {
      script.onload = async () => {
        // 等待500ms确保库完全初始化
        await new Promise(resolve => setTimeout(resolve, 500))
        console.log('LibPag script loaded, checking window.libpag:', window.libpag)
        
        if (window.libpag) {
          resolve(window.libpag)
        } else {
          reject(new Error('window.libpag is not available'))
        }
      }
      // 加载失败处理
      script.onerror = () => reject(new Error('Failed to load libPag script'))
    })
  } catch (error) {
    throw new Error(`Failed to load libPag: ${error}`)
  }
}, [])

初始化播放器

加载完 SDK 后，window 对象会生成 libpag 对象，以此为基础可完成播放器初始化，步骤如下：

准备 canvas 容器作为渲染载体；
加载 PAG 核心库并初始化 PAG 环境；
加载目标.pag 文件（动效模板）；
创建 PAGView 实例关联 canvas 与动效文件；
封装播放器控制接口（播放 / 暂停 / 销毁等），并处理资源释放与重复初始化问题。

需说明的是，本需求核心诉求是 “合成球星卡图片”，不涉及PAG的视频相关能力，因此暂不扩展视频功能，在播放器初始化后完成立即暂停，后续仅围绕 “图层替换（如用户人像）”“文本替换（如球星名称）” 等核心需求展开。

核心代码如下：

const { width, height } = props


// Canvas渲染容器
const canvasRef = useRef<HTMLCanvasElement>(null)
// PAG动效模板地址（球星卡模板）
const src = 'https://h5static.XX/10122053/G-lv1.pag'


// 初始化播放器函数
const initPlayer = useCallback(async () => {
  
  try {
    setIsLoading(true)
    const canvas = canvasRef.current
    // 设置Canvas尺寸与球星卡匹配
    canvas.width = width
    canvas.height = height
    
    // 1. 加载PAG核心库并初始化环境
    const libpag = await loadLibPag()
    const PAG = await libpag.PAGInit({ useScale: false })
    
    // 2. 加载PAG动效模板
    const response = await fetch(src)
    const buffer = await response.arrayBuffer()
    const pagFile = await PAG.PAGFile.load(buffer)
    
    // 3. 创建PAGView，关联Canvas与动效模板
    const pagView = await PAG.PAGView.init(pagFile, canvas)
    
    // 4. 封装播放器控制接口
    const player = {
      _pagView: pagView,
      _pagFile: pagFile,
      _PAG: PAG,
      _isPlaying: false,
      
      // 播放
      async play() {
        await this._pagView.play()
        this._isPlaying = true
      },
      // 暂停（初始化后默认暂停）
      pause() {
        this._pagView.pause()
        this._isPlaying = false
      },
      // 销毁实例，释放资源
      destroy() {
        this._pagView.destroy()
      },
    }
  } catch (error) {
    console.error('PAG Player initialization failed:', error)
  } 
}, [src, width, height])

实现效果

播放器初始化完成后，可在Canvas中正常展示球星卡动效模板（初始化后默认暂停）：

接下来我们来实现替换图层及文本功能。

替换图层及文本

替换 “用户上传人像”（图层）与 “球星名称”（文本）是核心需求，需通过 PAGFile 的原生接口实现，并扩展播放器实例的操作方法：

图片图层替换：调用pagFile.replaceImage(index, image) 接口，将指定索引的图层替换为用户上传图片（支持 CDN 地址、Canvas 元素、Image 元素作为图片源）；
文本内容替换：调用pagFile.setTextData(index, textData) 接口，修改指定文本图层的内容与字体；
效果生效：每次替换后需调用 pagView.flush() 强制刷新渲染，确保修改实时生效。

实现方案

替换图片图层：通过pagFile.replaceImage(index, image)接口，将指定索引的图层替换为用户上传图片；
替换文本内容：通过pagFile.setTextData(index, textData)接口，修改指定文本图层的内容；
扩展播放器接口后，需调用flush()强制刷新渲染，确保替换效果生效。

初期问题：文本字体未生效

替换文本后发现设定字体未应用。排查后确认：自定义字体包未在 PAG 环境中注册，导致 PAG 无法识别字体。

需在加载 PAG 模板前，优先完成字体注册，确保 PAG 能正常调用目标字体，具体实现步骤如下。

PAG提供PAGFont.registerFont()接口用于注册自定义字体，需传入 “字体名称” 与 “字体文件资源”（如.ttf/.otf 格式文件），流程为：

加载字体文件（从 CDN/OSS 获取字体包）；
调用 PAG 接口完成注册；
注册成功后，再加载.pag文件，确保后续文本替换时字体已生效。

// 需注册的字体列表（字体名称+CDN地址）
const fonts = [
  {
    family: 'POIZONSans',
    url: 'https://h5static.XX/10122053/20250827-febf35c67d9232d4.ttf',
  },
  {
    family: 'FZLanTingHeiS-DB-GB',
    url: 'https://h5static.XX/10122053/20250821-1e3a4fccff659d1c.ttf',
  },
]


// 在“加载PAG核心库”后、“加载PAG模板”前，新增字体注册逻辑
const initPlayer = useCallback(async () => {
  // ... 原有代码（Canvas准备、加载libpag）
  const libpag = await loadLibPag()
  const PAG = await libpag.PAGInit({ useScale: false })
  
  // 新增：注册自定义字体
  if (fonts && fonts.length > 0 && PAG?.PAGFont?.registerFont) {
    try {
      for (const { family, url } of fonts) {
        if (!family || !url) continue
        // 加载字体文件（CORS跨域配置+强制缓存）
        const resp = await fetch(url, { mode: 'cors', cache: 'force-cache' })
        const blob = await resp.blob()
        // 转换为File类型（PAG注册需File格式）
        const filename = url.split('/').pop() || 'font.ttf'
        const fontFile = new File([blob], filename)
        // 注册字体
        await PAG.PAGFont.registerFont(family, fontFile)
        console.log('Registered font for PAG:', family)
      }
    } catch (e) {
      console.warn('Register fonts for PAG failed:', e)
    }
  }
  
  // 继续加载PAG模板（原有代码）
  const response = await fetch(src)
  const buffer = await response.arrayBuffer()
  const pagFile = await PAG.PAGFile.load(buffer)
  // ... 后续创建PAGView、封装播放器接口
}, [src, width, height])

最终效果

字体注册后，文本替换的字体正常生效，人像与文本均显示正确：

数字字体已应用成功

可以看到，替换文本的字体已正确应用。接下来我们来实现最后一步，将更新图层及文本后的内容导出为CDN图片。

PagPlayer截帧（导出PagPlayer当前展示内容）

截帧是将 “调整后的人像 + 替换后的文本 + 动效模板” 固化为最终图片的关键步骤。开发初期曾直接调用pagView.makeSnapshot()遭遇导出空帧，后通过updateSize()+flush()解决同步问题；此外，还有一种更直接的方案 ——直接导出PAG渲染对应的Canvas内容，同样能实现需求，且流程更简洁。

初期问题：直接调用接口导致空帧

开发初期，尝试直接使用PAGView提供的makeSnapshot()接口截帧，但遇到了返回空帧（全透明图片）情况经过反复调试和查阅文档，发现核心原因是PAG 渲染状态与调用时机不同步：

尺寸不同步：PAGView 内部渲染尺寸与 Canvas 实际尺寸不匹配，导致内容未落在可视区域；
渲染延迟：图层替换、文本修改后，GPU 渲染是异步的，此时截帧只能捕获到未更新的空白或旧帧。

解决方案

针对空帧问题，结合 PAG 在 H5 端 “基于 Canvas 渲染” 的特性，梳理出两种可行方案，核心都是 “先确保渲染同步，再获取画面”：

最终落地流程

调用 pagView.updateSize() 与 pagView.flush() 确保渲染同步；
通过canvas.toDataURL('image/jpeg', 0.9) 生成 Base64 格式图片（JPG 格式，清晰度 0.9，平衡质量与体积）；
将 Base64 图片上传至 CDN，获取可访问的球星卡链接。

点击截帧按钮后，即可生成对应的截图。

完成 PAG 播放器的基础功能（图层替换、文本修改、截帧导出）后，我们来聚焦用户核心交互需求 —— 人像的拖拽、缩放与旋转，通过封装 Canvas 手势组件，实现精准的人像构图调整能力。

五、图片变换功能开发：实现人像拖拽、缩放与旋转

在球星卡合成流程中，用户需自主调整上传人像的位置、尺寸与角度以优化构图。我们可以基于 Canvas 封装完整的手势交互能力组件，支持单指拖拽、双指缩放 / 旋转，同时兼顾高清渲染与跨设备兼容性。

功能目标

针对 “用户人像调整” 场景，组件需实现以下核心能力：

基础交互：支持单指拖拽移动人像、双指缩放尺寸、双指旋转角度；
约束控制：限制缩放范围（如最小 0.1 倍、最大 5 倍），可选关闭旋转功能；
高清渲染：适配设备像素比（DPR），避免图片拉伸模糊；
状态同步：实时反馈当前变换参数（偏移量、缩放比、旋转角），支持重置与结果导出。

效果展示

组件设计理念

在组件设计之初，我们来使用分层理念，将图片编辑操作分解为三个独立层次：

交互感知层

交互感知层 - 捕获用户手势并转换为标准化的变换意图

手势语义化：将原始的鼠标/触摸事件转换为语义化的操作意图
单指移动 = 平移意图
双指距离变化 = 缩放意图
双指角度变化 = 旋转意图
双击 = 重置意图

变换计算层

变换计算层 - 处理几何变换逻辑和约束规则

多点触控的几何计算：双指操作时，系统会实时计算两个触点形成的几何关系（距离、角度、中心点），然后将这些几何变化映射为图片的变换参数。
交互连续性：每次手势开始时记录初始状态，移动过程中所有计算都基于这个初始状态进行增量计算，确保变换的连续性和平滑性。

渲染执行层

渲染执行层 - 将变换结果绘制到Canvas上

高清适配：Canvas的物理分辨率和显示尺寸分离管理，物理分辨率适配设备像素比保证清晰度，显示尺寸控制界面布局。
变换应用：绘制时按照特定顺序应用变换 - 先移动到画布中心建立坐标系，再应用用户的平移、旋转、缩放操作，最后以图片中心为原点绘制。这个顺序确保了变换的直观性。
渲染控制：区分实时交互和静态显示两种场景，实时交互时使用requestAnimationFrame保证流畅性，静态更新时使用防抖减少不必要的重绘。

数据流设计

单向数据流：用户操作 → 手势解析 → 变换计算 → 约束应用 → 状态更新 → 重新渲染 → 回调通知。这种单向流动保证了数据的可追踪性。
状态同步机制：内部状态变化时，通过回调机制同步给外部组件，支持实时同步和延迟同步两种模式，适应不同的性能需求。

实现独立的人像交互调整功能后，关键是打通 “用户操作” 与 “PAG 预览” 的实时同步链路 —— 确保用户每一次调整都能即时反馈在球星卡模板中，这需要设计分层同步架构与高效调度策略。

六、交互与预览实时同步

在球星卡生成流程中，“用户调整人像” 与 “PAG 预览更新” 的实时同步是核心体验指标 —— 用户每一次拖拽、缩放或旋转操作，都需要即时反馈在球星卡模板中，才能让用户精准判断构图效果。我们先来看一下实现效果：

接下来，我们从逻辑架构、关键技术方案、边界场景处理三方面，拆解 “用户交互调整” 与 “PAG 预览同步” 链路的实现思路。

逻辑架构：三层协同同步模型

组件将 “交互 - 同步 - 渲染” 拆分为三个独立但协同的层级，各层职责单一且通过明确接口通信，避免耦合导致的同步延迟或状态混乱。

核心流转链路：用户操作 → CanvasImageEditor 生成实时 Canvas → 同步层直接复用 Canvas 更新 PAG 图层 → 调度层批量触发 flush → PagPlayer 渲染最新画面。

关键方案：低损耗 + 高实时性的平衡

为同时兼顾 “高频交互导致 GPU 性能瓶颈” 与 “实时预览需即时反馈” ，组件通过三大核心技术方案实现平衡。

复用 Canvas 元素

跳过格式转换环节，减少性能消耗，直接复用 Canvas 元素作为 PAG 图片源。

核心代码逻辑：

通过 canvasEditorRef.current.getCanvas() 获取交互层的 Canvas 实例，直接传入PAG 的 replaceImageFast 接口（快速替换，不触发即时刷新），避免数据冗余处理。

// 直接使用 Canvas 元素更新 PAG，无格式转换
const canvas = canvasEditorRef.current.getCanvas();
pagPlayerRef.current.replaceImageFast(editImageIndex, canvas); // 快速替换，不flush

智能批量调度：

分级处理更新，兼顾流畅与效率

针对用户连续操作（如快速拖拽）产生的高频更新，组件设计 “分级调度策略”，避免每一次操作都触发 PAG 的 flush（GPU 密集型操作）：

调度逻辑：

实时操作合并：通过 requestAnimationFrame 捕获连续操作，将 16ms 内的多次替换指令合并为一次；

智能 flush 决策：

若距离上次 flush 超过 100ms（用户操作暂停），立即触发 flushPagView()，确保预览不延迟；

若操作仍在持续，延迟 Math.max(16, updateThrottle/2) 毫秒再 flush，合并多次更新。

防抖降级：

当 updateThrottle > 16ms（低实时性需求场景），自动降级为防抖策略，避免过度调度。

核心代码片段：

// 智能 flush 策略：短间隔合并，长间隔立即刷新
const timeSinceLastFlush = Date.now() - batchUpdate.lastFlushTime;
if (timeSinceLastFlush > 100) {
  await flushPagView(); // 间隔久，立即刷新
} else {
  // 延迟刷新，合并后续操作
  setTimeout(async () => {
    if (batchUpdate.pendingUpdates > 0) {
      await flushPagView();
    }
  }, Math.max(16, updateThrottle/2));
}

双向状态校验：

解决首帧 / 切换场景的同步空白

针对 “PAG 加载完成但 Canvas 未就绪”“Canvas 就绪但 PAG 未初始化” 等首帧同步问题，组件设计双向重试校验机制：

PAG 加载后校验：handlePagLoad 中启动 60 帧（约 1s）重试，检测 Canvas 与 PAG 均就绪后，触发初始同步；
Canvas 加载后校验：handleCanvasImageLoad 同理，若 PAG 未就绪，重试至两者状态匹配；
编辑模式切换校验：进入 startEdit 时，通过像素检测（getImageData）判断 Canvas 是否有内容，有则立即同步，避免空白预览。

边界场景处理：保障同步稳定性

编辑模式切换的状态衔接

进入编辑：暂停 PAG 播放，显示透明的 Canvas 交互层（opacity: 0，仅保留交互能力），触发初始同步；
退出编辑：清理批量调度定时器，强制 flush 确保最终状态生效，按需恢复 PAG 自动播放。

文本替换与图片同步的协同

当外部传入 textReplacements（如球星名称修改）时，通过独立的 applyToPagText 接口更新文本图层，并与图片同步共享 flush 调度，避免重复刷新：

// 文本替换后触发统一 flush
useEffect(() => {
  if (textReplacements?.length) {
    applyToPagText();
    flushPagView();
  }
}, [textReplacements]);

组件卸载的资源清理

卸载时清除批量调度的定时器（clearTimeout），避免内存泄漏；同时 PAG 内部会自动销毁实例，释放 GPU 资源。

PAG人像居中无遮挡

假设给定任意一张图片，我们将其绘制到Canvas中时，图片由于尺寸原因可能会展示不完整，如下图：

那么，如何保证任意尺寸图片在固定尺寸Canvas中初始化默认居中无遮挡呢？

我们采用以下方案：

等比缩放算法（Contain模式）

// 计算适配缩放比例，确保图片完整显示
const fitScale = Math.min(
  editCanvasWidth / image.width,   // 宽度适配比例
  availableHeight / image.height   // 高度适配比例（考虑留白）
)

核心原理：

选择较小的缩放比例，确保图片在两个方向上都不会超出边界；
这就是CSS的object-fit: contain效果，保证图片完整可见。

顶部留白预留

实际的PAG模板中，顶部会有一部分遮挡，因此需要对整个画布Canvas顶部留白。

如下图所示：

为人像的头部区域预留空间
避免重要的面部特征被PAG模板的装饰元素遮挡

核心代码

// 顶部留白比例
const TOP_BLANK_RATIO = 0.2


const handleCanvasImageLoad = useCallback(
  async (image: HTMLImageElement) => {
    console.log('Canvas图片加载完成:', image.width, 'x', image.height)
    setIsImageReady(true)


    // 初始等比缩放以完整可见（contain）
    if (canvasEditorRef.current) {
      // 顶部留白比例
      const TOP_BLANK_RATIO = spaceTopRatio ?? 0
      const availableHeight = editCanvasHeight * (1 - TOP_BLANK_RATIO)


      // 以可用高度进行等比缩放（同时考虑宽度）
      const fitScale = Math.min(
        editCanvasWidth / image.width, 
        availableHeight / image.height
      )


      // 计算使图片顶部恰好留白 TOP_BLANK_RATIO 的位移
      const topMargin = editCanvasHeight * TOP_BLANK_RATIO
      const imageScaledHeight = image.height * fitScale
      const targetCenterY = topMargin + imageScaledHeight / 2
      const yOffset = targetCenterY - editCanvasHeight / 2
      
      canvasEditorRef.current.setTransform({ 
        x: 0, 
        y: yOffset, 
        scale: fitScale, 
        rotation: 0 
      })
    }
    // ...
  },
  [applyToPag, flushPagView, isEditMode, editCanvasWidth, editCanvasHeight]
)

在单张球星卡的交互、预览与合成链路跑通后，需进一步拓展批量合成能力，以满足多等级球星卡一次性生成的业务需求，核心在于解决批量场景下的渲染效率、资源管理与并发控制问题。

七、批量生成

在以上章节，我们实现了单个卡片的交互及合成，但实际的需求中还有批量生成的需求，用来合成不同等级的球星卡，因此接下来我们需要处理批量生成相关的逻辑（碍于篇幅原因，这里我们就不展示代码了，主要以流程图形式来呈现。

经统计，经过各种手段优化后本活动中批量合成8张图最快仅需3s，最慢10s，批量合成过程用户基本是感知不到。

关键技术方案

离线渲染隐藏容器：避免布局干扰
资源缓存与预加载：提升合成效率
并发工作协程池：平衡性能与稳定性
多层重试容错：提升合成成功率
图片处理与尺寸适配：保障合成质量
结合业务场景实现批量合成中断下次访问页面后台继续生成的逻辑：保障合成功能稳定性。

核心架构

资源管理层：负责PAG库加载、buffer缓存、预加载调度
任务处理层：单个模板的渲染流水线，包含重试机制
并发控制层：工作协程池管理，任务队列调度

整体批量合成流程

节拍拉取：按照固定时间间隔依次拉取资源，而非一次性并发获取所有资源

单个模板处理流程

并发工作协程模式

共享游标：多个工作协程共同使用的任务队列指针，用于协调任务分配。

原子获取任务：确保在并发环境下，每个任务只被一个协程获取，避免重复处理。

资源管理与缓存策略

批量合成与单卡交互的功能落地后，需针对开发过程中出现的卡顿、空帧、加载慢等问题进行针对性优化，同时构建兼容性检测与降级方案，保障不同环境下功能的稳定可用。

八、性能优化与降级兼容

性能优化

上述功能开发和实现并非一蹴而就，过程中遇到很多问题，诸如：

图片拖动卡顿
Canvas导出空图、导出图片模糊
批量合成时间较久
PAG初始加载慢
导出图片时间久

等等问题，因此，我们在开发过程中就对各功能组件进行性能优化，大体如下：

PagPlayer（PAG播放器）

资源管理优化：

// src变化时主动销毁旧实例，释放WebGL/PAG资源
if (srcChanged) {
  if (pagPlayer) {
    try {
      pagPlayer.destroy()
    } catch (e) {
      console.warn('Destroy previous player failed:', e)
    }
  }
}

WebGL检查与降级：

检查WebGL支持，不可用时降级为2D警告
验证Canvas状态和尺寸
PAGView创建带重试机制

字体预注册：

必须在加载PAG文件之前注册字体
使用File类型进行字体注册

CanvasImageEditor（Canvas图片编辑器）

高DPI优化：

自动检测设备像素比，适配高分辨率设备
分离物理像素和CSS像素，确保清晰度

内存管理：

组件卸载时自动清理Canvas资源
启用高质量图像平滑，避免出现边缘锯齿
使用CSS touch-action控制触摸行为

EditablePagPlayer（可编辑PAG播放器）

智能批量更新系统：

// 高性能实时更新 - 使用RAF + 批量flush
const smartApplyToPag = useMemo(() => {
  return () => {
    rafId = requestAnimationFrame(async () => {
      await applyToPag() // 快速图片替换（无flush）
      smartFlush(batchUpdateRef.current) // 管理批量flush
    })
  }
}, [])

批量flush策略：

距离上次flush超过100ms立即flush
否则延迟16ms~updateThrottle/2合并多次更新
减少PAG刷新次数，提升性能

内存优化：

自动管理Canvas和PAG资源生命周期
智能预热：检测Canvas内容避免不必要初始化
资源复用：复用Canvas元素

PAGBatchComposer（批量PAG合成器）

高并发处理：

// 工作协程：按队列取任务直至耗尽或取消
const runWorker = async () => {
  while (!this.cancelled) {
    const idx = cursor++
    if (idx >= total) break
    // 处理单个模板...
  }
}

智能重试机制：

外层重试：最多3次整体重试，递增延迟
内层重试：PAG操作级别重试2次
首次延迟：第一个PAG处理增加500ms延迟

内存管理：

每个模板处理完成后立即清理Canvas和PAG对象
集成Canvas计数器监控内存使用
支持强制清理超时实例

性能监控debugUtils

提供详细的性能监控和调试日志
支持批量统计分析（吞吐量、平均时间等）

降级兼容

由于核心业务依赖 PAG 技术栈，而 PAG 运行需 WebGL 和 WebAssembly 的基础API支持，因此必须在应用初始化阶段对这些基础 API 进行兼容性检测，并针对不支持的环境执行降级策略，以保障核心功能可用性。

核心API检测代码如下：

export function isWebGLAvailable(): boolean {
  if (typeof window === 'undefined') return false
  try {
    const canvas = document.createElement('canvas')
    const gl =
      canvas.getContext('webgl') ||
      (canvas.getContext('experimental-webgl') as WebGLRenderingContext | null)
    return !!gl
  } catch (e) {
    return false
  }
}


export function isWasmAvailable(): boolean {
  try {
    const hasBasic =
      typeof (globalThis as any).WebAssembly === 'object' &&
      typeof (WebAssembly as any).instantiate === 'function'
    if (!hasBasic) return false
    // 最小模块校验，规避“存在但不可用”的情况
    const bytes = new Uint8Array([0x00, 0x61, 0x73, 0x6d, 0x01, 0x00, 0x00, 0x00])
    const mod = new WebAssembly.Module(bytes)
    const inst = new WebAssembly.Instance(mod)
    return inst instanceof WebAssembly.Instance
  } catch (e) {
    return false
  }
}


export function isPagRuntimeAvailable(): boolean {
  return isWebGLAvailable() && isWasmAvailable()
}

环境适配策略

兼容环境（检测通过）：直接执行 H5 端 PAG 初始化流程，启用完整的前端交互编辑能力。
不兼容环境（检测失败）：自动切换至服务端合成链路，通过预生成静态卡片保障核心功能可用，确保用户仍能完成球星卡生成的基础流程。

九、小结

本次「用篮球认识我」球星卡生成功能开发，围绕 “用户自主调整 + 跨端一致渲染” 核心目标，通过 PAG 技术与 Canvas 交互的深度结合，构建了从单卡编辑到批量合成的完整技术链路，可从问题解决、技术沉淀、业务价值三方面总结核心成果：

问题解决：解决业务痛点，优化用户体验

针对初期 “服务端固定合成导致构图偏差” 的核心痛点，通过 H5 端承接关键链路，保障活动玩法完整性：

交互自主性：基于 Canvas 封装的CanvasImageEditor组件，支持单指拖拽、双指缩放 / 旋转，让用户可精准调整人像构图，解决 “固定合成无法适配个性化需求” 问题；
预览实时性：设计 “交互感知 - 同步调度 - 渲染执行” 三层模型，通过复用 Canvas 元素、智能批量调度等方案，实现操作与 PAG 预览的即时同步，避免 “调整后延迟反馈” 的割裂感；
场景兼容性：针对 PAG 加载失败、WebGL 不支持等边界场景，设计静态图层兜底、服务端合成降级、截帧前渲染同步等方案，保障功能高可用性。

技术沉淀

本次开发过程中，围绕 PAG 技术在 H5 端的应用，沉淀出一套标准化的技术方案与组件体系，可复用于后续图片编辑、动效合成类需求：

组件化封装：拆分出PagPlayer（基础播放与图层替换）、CanvasImageEditor（手势交互）、EditablePagPlayer（交互与预览同步）、PAGBatchComposer（批量合成）四大核心组件，各组件职责单一、接口清晰，支持灵活组合；
性能优化：通过 “高清适配（DPR 处理）、资源复用（Canvas 直接传递）、调度优化（RAF 合并更新）、内存管理（实例及时销毁）” 等优化方向，为后续复杂功能的性能调优提供参考范例；
问题解决案例：记录 PAG 字体注册失效、截帧空帧、批量合成卡顿等典型问题的排查思路与解决方案，形成技术文档，降低后续团队使用 PAG 的门槛。

业务价值：支撑活动爆发，拓展技术边界

从业务落地效果来看，本次技术方案不仅满足了「用篮球认识我」活动的核心需求，更为社区侧后续视觉化功能提供了技术支撑：

活动保障：球星卡生成功能上线后，未出现因技术问题导致的功能不可用。
技术能力拓展：首次在社区 H5 端落地 PAG 动效合成与手势交互结合的方案，填补了 “前端 PAG 应用” 的技术空白，为后续一些复杂交互奠定基础。

后续优化方向

尽管当前方案已满足业务需求，但仍有可进一步优化的空间：

性能再提升：批量合成场景下，可探索 Web Worker 分担 PAG 解析压力，减少主线程阻塞。
功能扩展：在CanvasImageEditor中增加图片裁剪、滤镜叠加等功能，拓展组件的适用场景。

往期回顾

Ant Design 6.0 尝鲜：上手现代化组件开发｜得物技术
Java 设计模式：原理、框架应用与实战全解析｜得物技术
Go语言在高并发高可用系统中的实践与解决方案｜得物技术
从0到1搭建一个智能分析OBS埋点数据的AI Agent｜得物技术
数据库AI方向探索-MCP原理解析&DB方向实战｜得物技术

掘金专栏-得物技术

得物技术

2025年12月2日 10:45

一、前言

最近在项目中遇到了页面加载速度优化的问题，为了提高秒开率等指标，我决定从eebi报表入手，分析一下当前项目的性能监控体系。

通过查看报表中的cost_time、is_first等字段，我开始了解项目的性能数据采集情况。为了更好地理解这些数据的含义，我深入研究了相关SDK的源码实现。

在分析过程中，我发现采集到的cost_time参数实际上就是FMP（First Meaningful Paint） 指标。于是我对FMP的算法实现进行了梳理，了解了它的计算逻辑。

本文将分享我在性能优化过程中的一些思考和发现，希望能对关注前端性能优化的同学有所帮助。

二、什么是FMP

FMP (First Meaningful Paint) 首次有意义绘制，是指页面首次绘制有意义内容的时间点。与 FCP (First Contentful Paint) 不同，FMP 更关注的是对用户有实际价值的内容，而不是任何内容的首次绘制。

三、FMP 计算原理

3.1核心思想

FMP 的核心思想是：通过分析视口内重要 DOM 元素的渲染时间，找到对用户最有意义的内容完成渲染的时间点。

3.2FMP的三种计算方式

新算法 FMP (specifiedValue) 基于用户指定的 DOM 元素计算通过fmpSelector配置指定元素计算指定元素的完整加载时间

传统算法 FMP (value) 基于视口内重要元素计算选择权重最高的元素取所有参考元素中最晚完成的时间

P80 算法 FMP (p80Value) 基于 P80 百分位计算取排序后80%位置的时间更稳定的性能指标

3.3新算法vs传统算法

传统算法流程

遍历整个DOM树
计算每个元素的权重分数
选择多个重要元素
计算所有元素的加载时间
取最晚完成的时间作为FMP

新算法（指定元素算法）流程

核心思想： 直接指定一个关键 DOM 元素，计算该元素的完整加载时间作为FMP。

传统算法详细步骤

第一步：DOM元素选择

// 递归遍历 DOM 树，选择重要元素
selectMostImportantDOMs(dom: HTMLElement = document.body): void {
  const score = this.getWeightScore(dom);


  if (score > BODY_WEIGHT) {
    // 权重大于 body 权重，作为参考元素
    this.referDoms.push(dom);
  } else if (score >= this.highestWeightScore) {
    // 权重大于等于最高分数，作为重要元素
    this.importantDOMs.push(dom);
  }


  // 递归处理子元素
  for (let i = 0, l = dom.children.length; i < l; i++) {
    this.selectMostImportantDOMs(dom.children[i] as HTMLElement);
  }
}

第二步：权重计算

// 计算元素权重分数
getWeightScore(dom: Element) {
  // 获取元素在视口中的位置和大小
  const viewPortPos = dom.getBoundingClientRect();
  const screenHeight = this.getScreenHeight();


  // 计算元素在首屏中的可见面积
  const fpWidth = Math.min(viewPortPos.right, SCREEN_WIDTH) - Math.max(0, viewPortPos.left);
  const fpHeight = Math.min(viewPortPos.bottom, screenHeight) - Math.max(0, viewPortPos.top);


  // 权重 = 可见面积 × 元素类型权重
  return fpWidth * fpHeight * getDomWeight(dom);
}

权重计算公式：

权重分数 = 可见面积 × 元素类型权重

元素类型权重：

OBJECT, EMBED, VIDEO: 最高权重
SVG, IMG, CANVAS: 高权重
其他元素: 权重为 1

第三步：加载时间计算

getLoadingTime(dom: HTMLElement, resourceLoadingMap: Record<string, any>): number {
  // 获取 DOM 标记时间
  const baseTime = getMarkValueByDom(dom);


  // 获取资源加载时间
  let resourceTime = 0;
  if (RESOURCE_TAG_SET.indexOf(tagType) >= 0) {
    // 处理图片、视频等资源
    const resourceTiming = resourceLoadingMap[resourceName];
    resourceTime = resourceTiming ? resourceTiming.responseEnd : 0;
  }


  // 返回较大值（DOM 时间 vs 资源时间）
  return Math.max(resourceTime, baseTime);
}

第四步：FMP值计算

calcValue(resourceLoadingMap: Record<string, any>, isSubPage: boolean = false): void {
  // 构建参考元素列表（至少 3 个元素）
  const referDoms = this.referDoms.length >= 3 
    ? this.referDoms 
    : [...this.referDoms, ...this.importantDOMs.slice(this.referDoms.length - 3)];


  // 计算每个元素的加载时间
  const timings = referDoms.map(dom => this.getLoadingTime(dom, resourceLoadingMap));


  // 排序时间数组
  const sortedTimings = timings.sort((t1, t2) => t1 - t2);


  // 计算最终值
  const info = getMetricNumber(sortedTimings);
  this.value = info.value;        // 最后一个元素的时间（最晚完成）
  this.p80Value = info.p80Value;  // P80 百分位时间
}

新算法详细步骤

第一步：配置指定元素

// 通过全局配置指定 FMP 目标元素
const { fmpSelector = "" } = SingleGlobal?.getOptions?.();

配置示例：

// 初始化时配置
init({
  fmpSelector: '.main-content',  // 指定主要内容区域
  // 或者
  fmpSelector: '#hero-section',  // 指定首屏区域
  // 或者
  fmpSelector: '.product-list'   // 指定产品列表
});

第二步：查找指定元素

if (fmpSelector) {
  // 使用 querySelector 查找指定的 DOM 元素
  const $specifiedEl = document.querySelector(fmpSelector);


  if ($specifiedEl && $specifiedEl instanceof HTMLElement) {
    // 找到指定元素，进行后续计算
    this.specifiedDom = $specifiedEl;
  }
}

查找逻辑：

使用document.querySelector()查找元素
验证元素存在且为 HTMLElement 类型
保存元素引用到specifiedDom

第三步：计算指定元素的加载时间

// 计算指定元素的完整加载时间
this.specifiedValue = this.getLoadingTime(
  $specifiedEl,
  resourceLoadingMap
);

加载时间计算包含：

DOM 标记时间

// 获取 DOM 元素的基础标记时间
const baseTime = getMarkValueByDom(dom);

资源加载时间

let resourceTime = 0;
// 处理直接资源（img, video, embed 等）
const tagType = dom.tagName.toUpperCase();
if (RESOURCE_TAG_SET.indexOf(tagType) >= 0) {
  const resourceName = normalizeResourceName((dom as any).src);
  const resourceTiming = resourceLoadingMap[resourceName];
  resourceTime = resourceTiming ? resourceTiming.responseEnd : 0;
}
// 处理背景图片
const bgImgUrl = getDomBgImg(dom);
if (isImageUrl(bgImgUrl)) {
  const resourceName = normalizeResourceName(bgImgUrl);
  const resourceTiming = resourceLoadingMap[resourceName];
  resourceTime = resourceTiming ? resourceTiming.responseEnd : 0;
}

综合时间计算

// 返回 DOM 时间和资源时间的较大值
return Math.max(resourceTime, baseTime);

第四步：FMP值确定

// 根据是否有指定值来决定使用哪个 FMP 值
if (specifiedValue === 0) {
  // 如果没有指定值，回退到传统算法
  fmp = isSubPage ? value - diffTime : value;
} else {
  // 如果有指定值，使用指定值
  fmp = isSubPage ? specifiedValue - diffTime : specifiedValue;
}

决策逻辑：

如果 specifiedValue > 0：使用指定元素的加载时间
如果 specifiedValue === 0：回退到传统算法

第五步：子页面时间调整

// 子页面的 FMP 值需要减去时间偏移
if (isSubPage) {
  fmp = specifiedValue - diffTime;
  // diffTime = startSubTime - initTime
}

新算法的优势

精确性更高

直接针对业务关键元素
避免权重计算的误差
更贴近业务需求

可控性强

开发者可以指定关键元素
可以根据业务场景调整
避免算法自动选择的偏差

计算简单

只需要计算一个元素
不需要复杂的权重计算
性能开销更小

业务导向

直接反映业务关键内容的加载时间
更符合用户体验评估需求
便于性能优化指导

3.4关键算法

P80 百分位计算

export function getMetricNumber(sortedTimings: number[]) {
  const value = sortedTimings[sortedTimings.length - 1];  // 最后一个（最晚）
  const p80Value = sortedTimings[Math.floor((sortedTimings.length - 1) * 0.8)];  // P80
  return { value, p80Value };
}

元素类型权重

const IMPORTANT_ELEMENT_WEIGHT_MAP = {
  SVG: IElementWeight.High,      // 高权重
  IMG: IElementWeight.High,      // 高权重
  CANVAS: IElementWeight.High,   // 高权重
  OBJECT: IElementWeight.Highest, // 最高权重
  EMBED: IElementWeight.Highest, // 最高权重
  VIDEO: IElementWeight.Highest   // 最高权重
};

四、时间标记机制

4.1DOM变化监听

// MutationObserver 监听 DOM 变化
private observer = new MutationObserver((mutations = []) => {
  const now = Date.now();
  this.handleChange(mutations, now);
});

4.2时间标记

// 为每个 DOM 变化创建性能标记
mark(count);  // 创建 performance.mark(`mutation_pc_${count}`)
// 为 DOM 元素设置标记
setDataAttr(elem, TAG_KEY, `${mutationCount}`);

4.3标记值获取

// 根据 DOM 元素获取标记时间
getMarkValueByDom(dom: HTMLElement) {
  const markValue = getDataAttr(dom, TAG_KEY);
  return getMarkValue(parseInt(markValue));
}

五、资源加载考虑

5.1资源类型识别

图片资源: 标签的 src属性

视频资源: 标签的 src属性

背景图片: CSS background-image属性

嵌入资源: , 标签

5.2资源时间获取

// 从 Performance API 获取资源加载时间
const resourceTiming = resourceLoadingMap[resourceName];
const resourceTime = resourceTiming ? resourceTiming.responseEnd : 0;

5.3综合时间计算

// DOM 时间和资源时间的较大值
return Math.max(resourceTime, baseTime);

六、子页面支持

6.1时间偏移处理

// 子页面从调用 send 方法开始计时
const diffTime = this.startSubTime - this.initTime;
// 子页面只统计开始时间之后的资源
if (!isSubPage || resource.startTime > diffTime) {
  resourceLoadingMap[resourceName] = resource;
}

6.2FMP值调整

// 子页面的 FMP 值需要减去时间偏移
fmp = isSubPage ? value - diffTime : value;

七、FMP的核心优势

7.1用户感知导向

FMP 最大的优势在于它真正关注用户的实际体验：

内容价值优先：只计算对用户有意义的内容渲染时间
智能权重评估：根据元素的重要性和可见性进行差异化计算
真实体验映射：更贴近用户的实际感知，而非技术层面的指标

7.2多维度计算体系

FMP 采用了更加全面的计算方式：

元素权重分析：综合考虑元素类型和渲染面积的影响
资源加载关联：将静态资源加载时间纳入计算范围
算法对比验证：支持多种算法并行计算，确保结果准确性

7.3高精度测量

FMP 在测量精度方面表现突出：

DOM 变化追踪：基于实际 DOM 结构变化的时间点
API 数据融合：结合 Performance API 提供的详细数据
统计分析支持：支持 P80 百分位等多种统计指标，便于性能分析

八、FMP的实际应用场景

8.1性能监控实践

FMP 在性能监控中发挥着重要作用：

关键指标追踪：实时监控页面首次有意义内容的渲染时间
瓶颈识别：快速定位性能瓶颈和潜在的优化点
趋势分析：通过历史数据了解性能变化趋势

8.2用户体验评估

FMP 为产品团队提供了用户视角的性能评估：

真实感知测量：评估用户实际感受到的页面加载速度
竞品对比分析：对比不同页面或产品的性能表现
用户满意度关联：将技术指标与用户满意度建立关联

8.3优化指导价值

FMP 数据为性能优化提供了明确的方向：

资源优化策略：指导静态资源加载顺序和方式的优化
渲染路径优化：帮助优化关键渲染路径，提升首屏体验
量化效果评估：为优化效果提供可量化的评估标准

九、总结

通过这次深入分析，我对 FMP 有了更全面的认识。FMP 通过科学的算法设计，能够准确反映用户感知的页面加载性能，是前端性能监控的重要指标。

它不仅帮助我们更好地理解页面加载过程，更重要的是为性能优化提供了科学的依据。在实际项目中，合理运用 FMP 指标，能够有效提升用户体验，实现真正的"秒开"效果。

希望这篇文章能对正在关注前端性能优化的同学有所帮助，也欢迎大家分享自己的实践经验。

往期回顾

1. Dragonboat统一存储LogDB实现分析｜得物技术

2. 从数字到版面：得物数据产品里数字格式化的那些事

3. 一文解析得物自建 Redis 最新技术演进

4. Golang HTTP请求超时与重试：构建高可靠网络请求｜得物技术

5. RN与hawk碰撞的火花之C++异常捕获｜得物技术

文 /阿列

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

Dragonboat统一存储LogDB实现分析｜得物技术

掘金专栏-得物技术

得物技术

2025年11月27日 13:56

一、项目概览

Dragonboat 是纯 Go 实现的（multi-group）Raft 库。

为应用屏蔽 Raft 复杂性，提供易于使用的 NodeHost 和状态机接口。该库（自称）有如下特点：

高吞吐、流水线化、批处理；
提供了内存/磁盘状态机多种实现；
提供了 ReadIndex、成员变更、Leader转移等管理端API；
默认使用 Pebble 作为存储后端。

本次代码串讲以V3的稳定版本为基础，不包括GitHub上v4版本内容。

二、整体架构

三、LogDB 统一存储

LogDB 模块是 Dragonboat 的核心持久化存储层，虽然模块名字有Log，但是它囊括了所有和存储相关的API，负责管理 Raft 协议的所有持久化数据，包括：

Raft状态 (RaftState)

Raft内部状态变更的集合结构

包括但不限于：

ClusterID/NodeID：节点ID
RaftState： Raft任期、投票情况、commit进度
EntriesToSave：Raft提案日志数据
Snapshot：快照元数据(包括快照文件路径，快照大小，快照对应的提案Index，快照对应的Raft任期等信息)
Messages：发给其他节点的Raft消息
ReadyToReads：ReadIndex就绪的请求

引导信息 (Bootstrap)

type Bootstrap struct {
    Addresses map[uint64]string // 初始集群成员
    Join      bool
    Type      StateMachineType
}

ILogDB的API如下：

type ILogDB interface {


    BinaryFormat() uint32 // 返回支持的二进制格式版本号


    ListNodeInfo() ([]NodeInfo, error) // 列出 LogDB 中所有可用的节点信息


    // 存储集群节点的初始化配置信息，包括是否加入集群、状态机类型等
    SaveBootstrapInfo(clusterID uint64, nodeID uint64, bootstrap pb.Bootstrap) error


    // 获取保存的引导信息
    GetBootstrapInfo(clusterID uint64, nodeID uint64) (pb.Bootstrap, error)


    // 原子性保存 Raft 状态、日志条目和快照元数据
    SaveRaftState(updates []pb.Update, shardID uint64) error


    // 迭代读取指定范围内的连续日志条目
    IterateEntries(ents []pb.Entry, size uint64, clusterID uint64, nodeID uint64, 
                   low uint64, high uint64, maxSize uint64) ([]pb.Entry, uint64, error)


    // 读取持久化的 Raft 状态
    ReadRaftState(clusterID uint64, nodeID uint64, lastIndex uint64) (RaftState, error)


    // 删除指定索引之前的所有条目, 日志压缩、快照后清理旧日志
    RemoveEntriesTo(clusterID uint64, nodeID uint64, index uint64) error


    // 回收指定索引之前条目占用的存储空间
    CompactEntriesTo(clusterID uint64, nodeID uint64, index uint64) (<-chan struct{}, error)


    // 保存所有快照元数据
    SaveSnapshots([]pb.Update) error


    // 删除指定的快照元数据 清理过时或无效的快照
    DeleteSnapshot(clusterID uint64, nodeID uint64, index uint64) error


    // 列出指定索引范围内的可用快照
    ListSnapshots(clusterID uint64, nodeID uint64, index uint64) ([]pb.Snapshot, error)


    // 删除节点的所有相关数据
    RemoveNodeData(clusterID uint64, nodeID uint64) error


    // 导入快照并创建所有必需的元数据
    ImportSnapshot(snapshot pb.Snapshot, nodeID uint64) error
}

3.1索引键

存储的底层本质是一个KVDB (pebble or rocksdb)，由于业务的复杂性，要统一各类业务key的设计方法，而且要降低空间使用，所以有了如下的key设计方案。

龙舟中key分为3类：

其中，2字节的header用于区分各类不同业务的key空间。

entryKeyHeader       = [2]byte{0x1, 0x1}  // 普通日志条目
persistentStateKey   = [2]byte{0x2, 0x2}  // Raft状态
maxIndexKey          = [2]byte{0x3, 0x3}  // 最大索引记录
nodeInfoKey          = [2]byte{0x4, 0x4}  // 节点元数据
bootstrapKey         = [2]byte{0x5, 0x5}  // 启动配置
snapshotKey          = [2]byte{0x6, 0x6}  // 快照索引
entryBatchKey        = [2]byte{0x7, 0x7}  // 批量日志

在key的生成中，采用了useAsXXXKey和SetXXXKey的方式，复用了data这个二进制变量，减少GC。

type Key struct {
    data []byte  // 底层字节数组复用池
    key  []byte  // 有效数据切片
    pool *sync.Pool // 似乎并没有什么用
}




func (k *Key) useAsEntryKey() {
    k.key = k.data
}


type IReusableKey interface {
    SetEntryBatchKey(clusterID uint64, nodeID uint64, index uint64)
    // SetEntryKey sets the key to be an entry key for the specified Raft node
    // with the specified entry index.
    SetEntryKey(clusterID uint64, nodeID uint64, index uint64)
    // SetStateKey sets the key to be an persistent state key suitable
    // for the specified Raft cluster node.
    SetStateKey(clusterID uint64, nodeID uint64)
    // SetMaxIndexKey sets the key to be the max possible index key for the
    // specified Raft cluster node.
    SetMaxIndexKey(clusterID uint64, nodeID uint64)
    // Key returns the underlying byte slice of the key.
    Key() []byte
    // Release releases the key instance so it can be reused in the future.
    Release()
}


func (k *Key) useAsEntryKey() {
    k.key = k.data
}


// SetEntryKey sets the key value to the specified entry key.
func (k *Key) SetEntryKey(clusterID uint64, nodeID uint64, index uint64) {
    k.useAsEntryKey()
    k.key[0] = entryKeyHeader[0]
    k.key[1] = entryKeyHeader[1]
    k.key[2] = 0
    k.key[3] = 0
    binary.BigEndian.PutUint64(k.key[4:], clusterID)
    // the 8 bytes node ID is actually not required in the key. it is stored as
    // an extra safenet - we don't know what we don't know, it is used as extra
    // protection between different node instances when things get ugly.
    // the wasted 8 bytes per entry is not a big deal - storing the index is
    // wasteful as well.
    binary.BigEndian.PutUint64(k.key[12:], nodeID)
    binary.BigEndian.PutUint64(k.key[20:], index)
}

3.2变量复用IContext

IContext的核心设计目的是实现并发安全的内存复用机制。在高并发场景下，频繁的内存分配和释放会造成较大的GC压力，通过IContext可以实现：

键对象复用：通过GetKey()获取可重用的IReusableKey
缓冲区复用：通过GetValueBuffer()获取可重用的字节缓冲区
批量操作对象复用：EntryBatch和WriteBatch的复用

// IContext is the per thread context used in the logdb module.
// IContext is expected to contain a list of reusable keys and byte
// slices that are owned per thread so they can be safely reused by the
// same thread when accessing ILogDB.
type IContext interface {
    // Destroy destroys the IContext instance.
    Destroy()
    // Reset resets the IContext instance, all previous returned keys and
    // buffers will be put back to the IContext instance and be ready to
    // be used for the next iteration.
    Reset()
    // GetKey returns a reusable key.
    GetKey() IReusableKey // 这就是上文中的key接口
    // GetValueBuffer returns a byte buffer with at least sz bytes in length.
    GetValueBuffer(sz uint64) []byte
    // GetWriteBatch returns a write batch or transaction instance.
    GetWriteBatch() interface{}
    // SetWriteBatch adds the write batch to the IContext instance.
    SetWriteBatch(wb interface{})
    // GetEntryBatch returns an entry batch instance.
    GetEntryBatch() pb.EntryBatch
    // GetLastEntryBatch returns an entry batch instance.
    GetLastEntryBatch() pb.EntryBatch
}








type context struct {
    size    uint64
    maxSize uint64
    eb      pb.EntryBatch
    lb      pb.EntryBatch
    key     *Key
    val     []byte
    wb      kv.IWriteBatch
}


func (c *context) GetKey() IReusableKey {
    return c.key
}


func (c *context) GetValueBuffer(sz uint64) []byte {
    if sz <= c.size {
        return c.val
    }
    val := make([]byte, sz)
    if sz < c.maxSize {
        c.size = sz
        c.val = val
    }
    return val
}


func (c *context) GetEntryBatch() pb.EntryBatch {
    return c.eb
}


func (c *context) GetLastEntryBatch() pb.EntryBatch {
    return c.lb
}


func (c *context) GetWriteBatch() interface{} {
    return c.wb
}


func (c *context) SetWriteBatch(wb interface{}) {
    c.wb = wb.(kv.IWriteBatch)
}

3.3存储引擎封装IKVStore

IKVStore 是 Dragonboat 日志存储系统的抽象接口，它定义了底层键值存储引擎需要实现的所有基本操作。这个接口让 Dragonboat 能够支持不同的存储后端（如 Pebble、RocksDB 等），实现了存储引擎的可插拔性。

type IKVStore interface {
    // Name is the IKVStore name.
    Name() string
    // Close closes the underlying Key-Value store.
    Close() error


    // 范围扫描 - 支持前缀遍历的迭代器
    IterateValue(fk []byte,
            lk []byte, inc bool, op func(key []byte, data []byte) (bool, error)) error
    
    // 查询操作 - 基于回调的内存高效查询模式
    GetValue(key []byte, op func([]byte) error) error
    
    // 写入操作 - 单条记录的原子写入
    SaveValue(key []byte, value []byte) error


    // 删除操作 - 单条记录的精确删除
    DeleteValue(key []byte) error
    
    // 获取批量写入器
    GetWriteBatch() IWriteBatch
    
    // 原子提交批量操作
    CommitWriteBatch(wb IWriteBatch) error
    
    // 批量删除一个范围的键值对
    BulkRemoveEntries(firstKey []byte, lastKey []byte) error
    
    // 压缩指定范围的存储空间
    CompactEntries(firstKey []byte, lastKey []byte) error
    
    // 全量压缩整个数据库
    FullCompaction() error
}


type IWriteBatch interface {
    Destroy()                 // 清理资源，防止内存泄漏
    Put(key, value []byte)    // 添加写入操作
    Delete(key []byte)        // 添加删除操作
    Clear()                   // 清空批处理中的所有操作
    Count() int               // 获取当前批处理中的操作数量
}

openPebbleDB是Dragonboat 中 Pebble 存储引擎的初始化入口，负责根据配置创建一个完整可用的键值存储实例。

// KV is a pebble based IKVStore type.
type KV struct {
    db       *pebble.DB
    dbSet    chan struct{}
    opts     *pebble.Options
    ro       *pebble.IterOptions
    wo       *pebble.WriteOptions
    event    *eventListener
    callback kv.LogDBCallback
    config   config.LogDBConfig
}


var _ kv.IKVStore = (*KV)(nil)




// openPebbleDB
// =============
// 将 Dragonboat 的 LogDBConfig → Pebble 引擎实例
func openPebbleDB(
        cfg  config.LogDBConfig,
        cb   kv.LogDBCallback,   // => busy通知：busy(true/false)
        dir  string,             // 主数据目录
        wal  string,             // WAL 独立目录（可空）
        fs   vfs.IFS,            // 文件系统抽象（磁盘/memfs）
) (kv.IKVStore, error) {
    
    //--------------------------------------------------
    // 2️⃣ << 核心调优参数读入
    //--------------------------------------------------
    blockSz      := int(cfg.KVBlockSize)                    // 数据块(4K/8K…)
    writeBufSz   := int(cfg.KVWriteBufferSize)              // 写缓冲
    bufCnt       := int(cfg.KVMaxWriteBufferNumber)         // MemTable数量
    l0Compact    := int(cfg.KVLevel0FileNumCompactionTrigger) // L0 层文件数量触发压缩的阈值
    l0StopWrites := int(cfg.KVLevel0StopWritesTrigger)
    baseBytes    := int64(cfg.KVMaxBytesForLevelBase)
    fileBaseSz   := int64(cfg.KVTargetFileSizeBase)
    cacheSz      := int64(cfg.KVLRUCacheSize)
    levelMult    := int64(cfg.KVTargetFileSizeMultiplier)  // 每层文件大小倍数
    numLevels    := int64(cfg.KVNumOfLevels)
    
    
    //--------------------------------------------------
    // 4️⃣ 构建 LSM-tree 层级选项 (每层无压缩)
    //--------------------------------------------------
    levelOpts := []pebble.LevelOptions{}
    sz := fileBaseSz
    for lvl := 0; lvl < int(numLevels); lvl++ {
        levelOpts = append(levelOpts, pebble.LevelOptions{
            Compression:    pebble.NoCompression, // 写性能优先
            BlockSize:      blockSz,
            TargetFileSize: sz,                 // L0 < L1 < … 呈指数增长
        })
        sz *= levelMult
    }
    
    //--------------------------------------------------
    // 5️⃣ 初始化依赖：LRU Cache + 读写选项
    //--------------------------------------------------
    cache := pebble.NewCache(cacheSz)    // block缓存
    ro    := &pebble.IterOptions{}       // 迭代器默认配置
    wo    := &pebble.WriteOptions{Sync: true} // ❗fsync强制刷盘
    
    opts := &pebble.Options{
        Levels:                      levelOpts,
        Cache:                       cache,
        MemTableSize:                writeBufSz,
        MemTableStopWritesThreshold: bufCnt,
        LBaseMaxBytes:               baseBytes,
        L0CompactionThreshold:       l0Compact,
        L0StopWritesThreshold:       l0StopWrites,
        Logger:                      PebbleLogger,
        FS:                          vfs.NewPebbleFS(fs),
        MaxManifestFileSize:         128 * 1024 * 1024,
        // WAL 目录稍后条件注入
    }
    
    kv := &KV{
        dbSet:    make(chan struct{}),          // 关闭->初始化完成信号
        callback: cb,                           // 上层 raft engine 回调
        config:   cfg,
        opts:     opts,
        ro:       ro,
        wo:       wo,
    }
    
    event := &eventListener{
        kv:      kv,
        stopper: syncutil.NewStopper(),
    }
    
    // => 关键事件触发
    opts.EventListener = pebble.EventListener{
        WALCreated:    event.onWALCreated,
        FlushEnd:      event.onFlushEnd,
        CompactionEnd: event.onCompactionEnd,
    }
    
    //--------------------------------------------------
    // 7️⃣ 目录准备
    //--------------------------------------------------
    if wal != "" {
        fs.MkdirAll(wal)        // 📁 为 WAL 单独磁盘预留
        opts.WALDir = wal
    }
    fs.MkdirAll(dir)            // 📁 主数据目录
    
    //--------------------------------------------------
    // 8️⃣ 真正的数据库实例化
    //--------------------------------------------------
    pdb, err := pebble.Open(dir, opts)
    if err != nil { return nil, err }
    
    //--------------------------------------------------
    // 9️⃣ 🧹 资源整理 & 启动事件
    //--------------------------------------------------
    cache.Unref()               // 去除多余引用，防止泄露
    kv.db = pdb
    
    // 🔔 手动触发一次 WALCreated 确保反压逻辑进入首次轮询
    kv.setEventListener(event)  // 内部 close(kv.dbSet)
    
    return kv, nil
}

其中eventListener是对pebble 内存繁忙的回调，繁忙判断的条件有两个：

内存表大小超过阈值（95%）
L0 层文件数量超过阈值（L0写入最大文件数量-1）



func (l *eventListener) notify() {
    l.stopper.RunWorker(func() {
        select {
        case <-l.kv.dbSet:
            if l.kv.callback != nil {
                memSizeThreshold := l.kv.config.KVWriteBufferSize *
                    l.kv.config.KVMaxWriteBufferNumber * 19 / 20
                l0FileNumThreshold := l.kv.config.KVLevel0StopWritesTrigger - 1
                m := l.kv.db.Metrics()
                busy := m.MemTable.Size >= memSizeThreshold ||
                    uint64(m.Levels[0].NumFiles) >= l0FileNumThreshold
                l.kv.callback(busy)
            }
        default:
        }
    })
}

3.4日志条目存储DB

db结构体是Dragonboat日志数据库的核心管理器，提供Raft日志、快照、状态等数据的持久化存储接口。是桥接了业务和pebble存储的中间层。

// db is the struct used to manage log DB.
type db struct {
    cs      *cache       // 节点信息、Raft状态信息缓存
    keys    *keyPool     // Raft日志索引键变量池
    kvs     kv.IKVStore  // pebble的封装
    entries entryManager // 日志条目读写封装
}


// 这里面的信息不会过期，叫寄存更合适
type cache struct {
    nodeInfo       map[raftio.NodeInfo]struct{}
    ps             map[raftio.NodeInfo]pb.State
    lastEntryBatch map[raftio.NodeInfo]pb.EntryBatch
    maxIndex       map[raftio.NodeInfo]uint64
    mu             sync.Mutex
}

获取一个批量写容器

实现：

func (r *db) getWriteBatch(ctx IContext) kv.IWriteBatch {
    if ctx != nil {
        wb := ctx.GetWriteBatch()
        if wb == nil {
            wb = r.kvs.GetWriteBatch()
            ctx.SetWriteBatch(wb)
        }
        return wb.(kv.IWriteBatch)
    }
    return r.kvs.GetWriteBatch()
}

降低GC压力

获取所有节点信息

实现：

func (r *db) listNodeInfo() ([]raftio.NodeInfo, error) {
    fk := newKey(bootstrapKeySize, nil)
    lk := newKey(bootstrapKeySize, nil)
    fk.setBootstrapKey(0, 0)
    lk.setBootstrapKey(math.MaxUint64, math.MaxUint64)
    ni := make([]raftio.NodeInfo, 0)
    op := func(key []byte, data []byte) (bool, error) {
        cid, nid := parseNodeInfoKey(key)
        ni = append(ni, raftio.GetNodeInfo(cid, nid))
        return true, nil
    }
    if err := r.kvs.IterateValue(fk.Key(), lk.Key(), true, op); err != nil {
        return []raftio.NodeInfo{}, err
    }
    return ni, nil
}

保存集群状态

实现：

type Update struct {
    ClusterID uint64  // 集群ID，标识节点所属的Raft集群
    NodeID    uint64  // 节点ID，标识集群中的具体节点


    State  // 包含当前任期（Term）、投票节点（Vote）、提交索引（Commit）三个关键持久化状态


    EntriesToSave []Entry    // 需要持久化到稳定存储的日志条目
    CommittedEntries []Entry // 已提交位apply的日志条目
    MoreCommittedEntries bool  // 指示是否还有更多已提交条目等待处理


    Snapshot Snapshot  // 快照元数据，当需要应用快照时设置


    ReadyToReads []ReadyToRead  // ReadIndex机制实现的线性一致读


    Messages []Message  // 需要发送给其他节点的Raft消息


    UpdateCommit struct {
        Processed         uint64  // 已推送给RSM处理的最后索引
        LastApplied       uint64  // RSM确认已执行的最后索引
        StableLogTo       uint64  // 已稳定存储的日志到哪个索引
        StableLogTerm     uint64  // 已稳定存储的日志任期
        StableSnapshotTo  uint64  // 已稳定存储的快照到哪个索引
        ReadyToRead       uint64  // 已准备好读的ReadIndex请求索引
    }
}




func (r *db) saveRaftState(updates []pb.Update, ctx IContext) error {
      // 步骤1：获取写入批次对象，用于批量操作提高性能
      // 优先从上下文中获取已存在的批次，避免重复创建
      wb := r.getWriteBatch(ctx)
      
      // 步骤2：遍历所有更新，处理每个节点的状态和快照
      for _, ud := range updates {
          // 保存 Raft 的硬状态（Term、Vote、Commit）
          // 使用缓存机制避免重复保存相同状态
          r.saveState(ud.ClusterID, ud.NodeID, ud.State, wb, ctx)
          
          // 检查是否有快照需要保存
          if !pb.IsEmptySnapshot(ud.Snapshot) {
              // 快照索引一致性检查：确保快照索引不超过最后一个日志条目的索引
              // 这是 Raft 协议的重要约束，防止状态不一致
              if len(ud.EntriesToSave) > 0 {
                  lastIndex := ud.EntriesToSave[len(ud.EntriesToSave)-1].Index
                  if ud.Snapshot.Index > lastIndex {
                      plog.Panicf("max index not handled, %d, %d",
                          ud.Snapshot.Index, lastIndex)
                  }
              }
              
              // 保存快照元数据到数据库
              r.saveSnapshot(wb, ud)
              
              // 更新节点的最大日志索引为快照索引
              r.setMaxIndex(wb, ud, ud.Snapshot.Index, ctx)
          }
      }
      
      // 步骤3：批量保存所有日志条目
      // 这里会调用 entryManager 接口的 record 方法，根据配置选择批量或单独存储策略
      r.saveEntries(updates, wb, ctx)
      
      // 步骤4：提交写入批次到磁盘
      // 只有在批次中有实际操作时才提交，避免不必要的磁盘 I/O
      if wb.Count() > 0 {
          return r.kvs.CommitWriteBatch(wb)
      }
      return nil
  }

保存引导信息

实现：

func (r *db) saveBootstrapInfo(clusterID uint64,
    nodeID uint64, bs pb.Bootstrap) error {
    wb := r.getWriteBatch(nil)
    r.saveBootstrap(wb, clusterID, nodeID, bs)
    return r.kvs.CommitWriteBatch(wb) // 提交至Pebble
}


func (r *db) saveBootstrap(wb kv.IWriteBatch,
    clusterID uint64, nodeID uint64, bs pb.Bootstrap) {
    k := newKey(maxKeySize, nil)
    k.setBootstrapKey(clusterID, nodeID) // 序列化集群节点信息
    data, err := bs.Marshal()
    if err != nil {
        panic(err)
    }
    wb.Put(k.Key(), data)
}

获取Raft状态

实现：

func (r *db) getState(clusterID uint64, nodeID uint64) (pb.State, error) {
    k := r.keys.get()
    defer k.Release()
    k.SetStateKey(clusterID, nodeID)
    hs := pb.State{}
    if err := r.kvs.GetValue(k.Key(), func(data []byte) error {
        if len(data) == 0 {
            return raftio.ErrNoSavedLog
        }
        if err := hs.Unmarshal(data); err != nil {
            panic(err)
        }
        return nil
    }); err != nil {
            return pb.State{}, err
    }
    return hs, nil
}

3.5对外存储API实现

龙舟对ILogDB提供了实现：ShardedDB，一个管理了多个pebble bucket的存储单元。

var _ raftio.ILogDB = (*ShardedDB)(nil)
// ShardedDB is a LogDB implementation using sharded pebble instances.
type ShardedDB struct {
    completedCompactions uint64             // 原子计数器：已完成压缩操作数
    config               config.LogDBConfig // 日志存储配置
    ctxs                 []IContext         // 分片上下文池，减少GC压力
    shards               []*db              // 核心：Pebble实例数组
    partitioner          server.IPartitioner // 智能分片策略器
    compactionCh         chan struct{}      // 压缩任务信号通道
    compactions          *compactions       // 压缩任务管理器
    stopper              *syncutil.Stopper  // 优雅关闭管理器
}

初始化过程

实现：

// 入口函数：创建并初始化分片日志数据库
OpenShardedDB(config, cb, dirs, lldirs, batched, check, fs, kvf):


    // ===阶段1：安全验证===
    if 配置为空 then panic
    if check和batched同时为true then panic


    // ===阶段2：预分配资源管理器===
    shards := 空数组
    closeAll := func(all []*db) { //出错清理工具
        for s in all {
            s.close()
        }
    }


    // ===阶段3：逐个创建分片===
    loop i := 0 → 分片总数:
        datadir := pathJoin(dirs[i], "logdb-"+i)  //数据目录
        snapdir := ""                           //快照目录(可选)
        if lldirs非空 {
            snapdir = pathJoin(lldirs[i], "logdb-"+i)
        }


        shardCb := {shard:i, callback:cb}      //监控回调
        db, err := openRDB(...)                //创建实际数据库实例
        if err != nil {                        //创建失败
            closeAll(shards)                   //清理已创建的
            return nil, err
        }
        shards = append(shards, db)


    // ===阶段5：核心组件初始化===
    partitioner := 新建分区器(execShards数量, logdbShards数量)
    instance := &ShardedDB{
        shards:      shards,
        partitioner: partitioner,
        compactions: 新建压缩管理器(),
        compactionCh: 通道缓冲1,
        ctxs:       make([]IContext, 执行分片数),
        stopper:    新建停止器()
    }


    // ===阶段6：预分配上下文&启动后台===
    for j := 0 → 执行分片数:
        instance.ctxs[j] = 新建Context(saveBufferSize)


    instance.stopper.RunWorker(func() {        //后台压缩协程
        instance.compactionWorkerMain()
    })


    return instance, nil                      //构造完成

保存集群状态

实现：

func (s *ShardedDB) SaveRaftState(updates []pb.Update, shardID uint64) error {
    if shardID-1 >= uint64(len(s.ctxs)) {
        plog.Panicf("invalid shardID %d, len(s.ctxs): %d", shardID, len(s.ctxs))
    }
    ctx := s.ctxs[shardID-1]
    ctx.Reset()
    return s.SaveRaftStateCtx(updates, ctx)
}


func (s *ShardedDB) SaveRaftStateCtx(updates []pb.Update, ctx IContext) error {
    if len(updates) == 0 {
        return nil
    }
    pid := s.getParititionID(updates)
    return s.shards[pid].saveRaftState(updates, ctx)
}

以sylas为例子，我们每个分片都是单一cluster，所以logdb只使用了一个分片，龙舟设计初衷是为了解放多cluster的吞吐，我们暂时用不上，tindb可以考虑：

四、总结

LogDB是Dragonboat重要的存储层实现，作者将Pebble引擎包装为一组通用简洁的API，极大方便了上层应用与存储引擎的交互成本。

其中包含了很多Go语言的技巧，例如大量的内存变量复用设计，展示了这个库对高性能的极致追求，是一个十分值得学习的优秀工程案例。

往期回顾

1. 从数字到版面：得物数据产品里数字格式化的那些事

2. 一文解析得物自建 Redis 最新技术演进

3. Golang HTTP请求超时与重试：构建高可靠网络请求｜得物技术

4. RN与hawk碰撞的火花之C++异常捕获｜得物技术

5. 得物TiDB升级实践

文 /酒米

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

从数字到版面：得物数据产品里数字格式化的那些事

掘金专栏-得物技术

得物技术

2025年11月25日 17:16

做数据前端，你会很快建立一个共识：怎样把枯燥的数字用合适的方式展示出来，是我们的第一要务，但这只是起点。如果说规范的数字排版是中后台系统的“地基” ，保证了信息的准确传达；那么可视化图

一文解析得物自建 Redis 最新技术演进

掘金专栏-得物技术

得物技术

2025年11月20日 14:42

自建 Redis 上线 3 年多以来，一直围绕着技术架构、性能提升、降低成本、自动化运维等方面持续进行技术演进迭代，力求为公司业务提供性能更高、成本更低的分布式缓存集群，通过自动化运维方式

Golang HTTP请求超时与重试：构建高可靠网络请求｜得物技术

掘金专栏-得物技术

得物技术

2025年11月18日 10:58

在分布式系统中，网络请求的可靠性直接决定了服务质量。想象一下，当你的支付系统因第三方API超时导致订单状态不一致，或因瞬时网络抖动造成用户操作失败，这些问题往往源于HTTP客户端缺乏完善的

得物TiDB升级实践

掘金专栏-得物技术

得物技术

2025年11月11日 11:08

一、背景

得物DBA自2020年初开始自建TiDB，5年以来随着NewSQL数据库迭代发展、运维体系逐步完善、产品自身能力逐步提升，接入业务涵盖了多个业务线和关键场景。从第一套TIDB v4.0.9 版本开始，到后来v4.0.11、v5.1.1、v5.3.0，在经历了各种 BUG 踩坑、问题调试后，最终稳定在 TIDB 5.3.3 版本。伴随着业务高速增长、数据量逐步增多，对 TiDB 的稳定性及性能也带来更多挑战和新的问题。为了应对这些问题，DBA团队决定对 TiDB 进行一次版本升级，收敛版本到7.5.x。本文基于内部的实践情况，从架构、新特性、升级方案及收益等几个方向讲述 TiDB 的升级之旅。

二、TiDB 架构

TiDB 是分布式关系型数据库，高度强兼容 MySQL 协议和 MySQL 生态，稳定适配 MySQL 5.7 和MySQL 8.0常用的功能及语法。随着版本的迭代，TiDB 在弹性扩展、分布式事务、强一致性基础上进一步针对稳定性、性能、易用性等方面进行优化和增强。与传统的单机数据库相比，TiDB具有以下优势：

分布式架构，拥有良好的扩展性，支持对业务透明灵活弹性的扩缩容能力，无需分片键设计以及开发运维。
HTAP 架构支撑，支持在处理高并发事务操作的同时，对实时数据进行复杂分析，天然具备事务与分析物理隔离能力。
支持 SQL 完整生态，对外暴露 MySQL 的网络协议，强兼容 MySQL 的语法/语义，在大多数场景下可以直接替换 MySQL。
默认支持自愈高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务无感。
支持 ACID 事务，对于一些有强一致需求的场景友好，满足 RR 以及 RC 隔离级别，可以在通用开发框架完成业务开发迭代。

我们使用 SLB 来实现 TiDB 的高效负载均衡，通过调整 SLB 来管理访问流量的分配以及节点的扩展和缩减。确保在不同流量负载下，TiDB 集群能够始终保持稳定性能。在 TiDB 集群的部署方面，我们采用了单机单实例的架构设计。TiDB Server 和 PD Server 均选择了无本地 SSD 的机型，以优化资源配置，并降低开支。TiKV Server则配置在本地 SSD 的机型上，充分利用其高速读写能力，提升数据存储和检索的性能。这样的硬件配置不仅兼顾了系统的性能需求，又能降低集群成本。针对不同的业务需求，我们为各个组件量身定制了不同的服务器规格，以确保在多样化的业务场景下，资源得到最佳的利用，进一步提升系统的运行效率和响应速度。

三、TiDB v7 版本新特性

新版本带来了更强大的扩展能力和更快的性能，能够支持超大规模的工作负载，优化资源利用率，从而提升集群的整体性能。在 SQL 功能方面，它提升了兼容性、灵活性和易用性，从而助力复杂查询和现代应用程序的高效运行。此外，网络 IO 也进行了优化，通过多种批处理方法减少网络交互的次数，并支持更多的下推算子。同时，优化了Region 调度算法，显著提升了性能和稳定性。

四、TiDB升级之旅

4.1 当前存在的痛点

集群版本过低：当前 TiDB 生产环境（现网）最新版本为 v5.3.3，目前官方已停止对 4.x 和 5.x 版本的维护及支持，TiDB 内核最新版本为 v8.5.3，而被用户广泛采用且最为稳定的版本是 v7.5.x。
TiCDC组件存在风险：TiCDC 作为增量数据同步工具，在 v6.5.0 版本以前在运行稳定性方面存在一定问题，经常出现数据同步延迟问题或者 OOM 问题。
备份周期时间长：集群每天备份时间大于8小时，在此期间，数据库备份会导致集群负载上升超过30%，当备份时间赶上业务高峰期，会导致应用RT上升。
集群偶发抖动及BUG：在低版本集群中，偶尔会出现基于唯一键查询的慢查询现象，同时低版本也存在一些影响可用性的BUG。比如在 TiDB v4.x 的集群中，TiKV 节点运行超过 2 年会导致节点自动重启。

4.2 升级方案：升级方式

TiDB的常见升级方式为原地升级和迁移升级，我们所有的升级方案均采用迁移升级的方式。

原地升级

优势：方式较为简单，不需要额外的硬件，升级过程中集群仍然可以对外提供服务。
劣势：该升级方案不支持回退、并且升级过程会有长时间的性能抖动。大版本（v4/v5 原地升级到 v7）跨度较大时，需要版本递增升级，抖动时间翻倍。

迁移升级

优势：业务影响时间较短、可灰度可回滚、不受版本跨度的影响。
劣势：搭建新集群将产生额外的成本支出，同时，原集群还需要部署TiCDC组件用于增量同步。

4.3 升级方案：集群调研

4.4 升级方案：升级前准备环境

4.5 升级方案：升级前验证集群

4.6 升级方案：升级中流量迁移

4.7 升级方案：升级后销毁集群

五、升级遇到的问题

5.1 v7.5.x版本查询SQL倾向全表扫描

表中记录数 215亿，查询 SQL存在合理的索引，但是优化器更倾向走全表扫描，重新收集表的统计信息后，执行计划依然为全表扫描。

走全表扫描执行60秒超时KILL，强制绑定索引仅需0.4秒。

-- 查询SQL
SELECT
  *
FROM
  fin_xxx_xxx
WHERE
  xxx_head_id = 1111111111111111
  AND xxx_type = 'XX0002'
  AND xxx_user_id = 11111111
  AND xxx_pay_way = 'XXX00000'
  AND is_del IN ('N', 'Y')
LIMIT
  1;


-- 涉及索引
KEY `idx_xxx` (`xxx_head_id`,`xxx_type`,`xxx_status`),

解决方案：

方式一：通过 SPM 进行 SQL 绑定。
方式二：调整集群参数 tidb_opt_prefer_range_scan，将该变量值设为 ON 后，优化器总是偏好区间扫描而不是全表扫描。

asktug.com/t/topic/104…

5.2 v7.5.x版本聚合查询执行计划不准确

集群升级后，在新集群上执行一些聚合查询或者大范围统计查询时无法命中有效索引。而低版本v4.x、5.x集群，会根据统计信息选择走合适的索引。

v4.0.11集群执行耗时：12秒，新集群执行耗时2分32.78秒

-- 查询SQL
select 
    statistics_date,count(1) 
from 
    merchant_assessment_xxx 
where 
    create_time between '2025-08-20 00:00:00' and '2025-09-09 00:00:00' 
group by 
    statistics_date order by statistics_date;


-- 涉及索引
KEY `idx_create_time` (`create_time`)

解决方案：

方式一：调整集群参数tidb_opt_objective，该变量设为 determinate后，TiDB 在生成执行计划时将不再使用实时统计信息，这会让执行计划相对稳定。

asktug.com/t/topic/104…

六、升级带来的收益

版本升级稳定性增强：v7.5.x 版本的 TiDB 提供了更高的稳定性和可靠性，高版本改进了SQL优化器、增强的分布式事务处理能力等，加快了响应速度和处理大量数据的能力。升级后相比之前整体性能提升40%。特别是在处理复杂 SQL 和多索引场景时，优化器的性能得到了极大的增强，减少了全表扫描的发生，从而显著降低了 TiKV 的 CPU 消耗和 TiDB 的内存使用。

应用平均RT提升44.62%

原集群RT(平均16.9ms)

新集群RT(平均9.36ms)

新集群平均RT提升50%，并且稳定性增加，毛刺大幅减少

老集群RT(平均250ms)

新集群RT(平均125ms)

提升TiCDC同步性能：新版本在数据同步方面有了数十倍的提升，有效解决了之前版本中出现的同步延迟问题，提供更高的稳定性和可靠性。当下游需要订阅数据至数仓或风控平台时，可以使用TiCDC将数据实时同步至Kafka，提升数据处理的灵活性与响应能力。

缩短备份时间：数据库备份通常会消耗大量的CPU和IO资源。此前，由于备份任务的结束时间恰逢业务高峰期，经常导致应用响应时间（RT）上升等问题。通过进行版本升级将备份效率提升了超过50%。

高压缩存储引擎：新版本采用了高效的数据压缩算法，能够显著减少存储占用。同时，通过优化存储结构，能够快速读取和写入数据，提升整体性能。相同数据在 TiDB 中的存储占用空间更低，iDB 的3副本数据大小仅为 MySQL（主实例数据大小）的 55%。

完善的运维体验：新版本引入更好的监控工具、更智能的故障诊断机制和更简化的运维流程，提供了改进的 Dashboard 和 Top SQL 功能，使得慢查询和问题 SQL 的识别更加直观和便捷，降低 DBA 的工作负担。

更秀更实用的新功能：TiDB 7.x版本提供了TTL定期自动删除过期数据，实现行级别的生命周期控制策略。通过为表设置 TTL 属性，TiDB 可以周期性地自动检查并清理表中的过期数据。此功能在一些场景可以有效节省存储空间、提升性能。TTL 常见的使用场景：

定期删除验证码、短网址记录
定期删除不需要的历史订单
自动删除计算的中间结果

docs.pingcap.com/zh/tidb/v7.…

七、选择 TiDB 的原因

我们不是为了使用TiDB而使用，而是去解决一些MySQL无法满足的场景，关系型数据库我们还是优先推荐MySQL。能用分库分表能解决的问题尽量选择MySQL，毕竟运维成本相对较低、数据库版本更加稳定、单点查询速度更快、单机QPS性能更高这些特性是分布式数据库无法满足的。

非分片查询场景：上游 MySQL 采用了分库分表的设计，但部分业务查询无法利用分片。通过自建 DTS 将 MySQL 数据同步到 TiDB 集群，非分片/聚合查询则使用 TiDB 处理，能够在不依赖原始分片结构的情况下，实现高效的数据查询和分析。
分析 SQL 多场景：业务逻辑比较复杂，往往存在并发查询和分析查询的需求。通过自建 DTS 将 MySQL 数据同步到 TiDB，复杂查询在TiDB执行、点查在MySQL执行。TiDB支持水平扩展，其分布式计算和存储能力使其能够高效处理大量的并发查询请求。既保障了MySQL的稳定性，又提升了整体的查询能力。
磁盘使用大场景：在磁盘使用率较高的情况下，可能会出现 CPU 和内存使用率低，但磁盘容量已达到 MySQL 的瓶颈。TiDB 能够自动进行数据分片和负载均衡，将数据分布在多个节点上，缓解单一节点的磁盘压力，避免了传统 MySQL 中常见的存储瓶颈问题，从而提高系统的可扩展性和灵活性。
数据倾斜场景：在电商业务场景上，每个电商平台都会有一些销量很好的头部卖家，数据量会很大。即使采取了进行分库分表的策略，仍难以避免大卖家的数据会存储在同一实例中，这样会导致热点查询和慢 SQL 问题，尽管可以通过添加索引或进一步分库分表来优化，但效果有限。采用分布式数据库能够有效解决这一问题。可以将数据均匀地分散存储在多个节点上，在查询时则能够并发执行，从而将流量分散，避免热点现象的出现。随着业务的快速发展和数据量的不断增长，借助简单地增加节点，即可实现水平扩展，满足海量数据及高并发的需求。

八、总结

综上所述，在本次 TiDB 集群版本升级到 v7.5.x 版本过程中，实现了性能和稳定性提升。通过优化的查询计划和更高效的执行引擎，数据读取和写入速度显著提升，大幅度降低了响应延迟，提升了在高并发操作下的可靠性。通过直观的监控界面和更全面的性能分析工具，能够更快速地识别和解决潜在问题，降低 DBA 的工作负担。也为未来的业务扩展和系统稳定性提供了强有力的支持。

后续依然会持续关注 TiDB 在 v8.5.x 版本稳定性、性能以及新产品特性带来应用开发以及运维人效收益进展。目前 TiDB 内核版本 v8.5.x 已经具备多模数据库 Data + AI 能力，在JSON函数、ARRAY 索引以及 Vector Index 实现特性。同时已经具备 Resource Control 资源管理能力，适合进行多业务系统数据归集方案，实现数据库资源池化多种自定义方案。技术研究方面我们数据库团队会持续投入，将产品最好的解决方案引入现网环境。

往期回顾

得物管理类目配置线上化：从业务痛点到技术实现
大模型如何革新搜索相关性？智能升级让搜索更“懂你”｜得物技术
RAG—Chunking策略实战｜得物技术
告别数据无序：得物数据研发与管理平台的破局之路
从一次启动失败深入剖析：Spring循环依赖的真相｜得物技术

文 /岱影

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

得物管理类目配置线上化：从业务痛点到技术实现

掘金专栏-得物技术

得物技术

2025年11月6日 15:16

一、引言

在电商交易领域，管理类目作为业务责权划分、统筹、管理核心载体，随着业务复杂性的提高，其规则调整频率从最初的 1 次 / 季度到多次 / 季度，三级类目的规则复杂度也呈指数级上升。传统依赖数仓底层更新的方式暴露出三大痛点：

行业无法自主、快速调管理类目；
业务管理类目规则调整，不支持校验类目覆盖范围是否有重复/遗漏，延长交付周期；
规则变更成功后、下游系统响应滞后，无法及时应用最新类目规则。

本文将从技术视角解析 “管理类目配置线上化” 项目如何通过全链路技术驱动，将规则迭代周期缩短至 1-2 天。

二、业务痛点与技术挑战：为什么需要线上化？

2.1 效率瓶颈：手工流程与

高频迭代的矛盾

问题场景：业务方需线下通过数仓提报规则变更，经数仓开发、测试、BI需要花费大量精力校验确认，一次类目变更需 3-4 周左右时间才能上线生效，上线时间无法保证。

技术瓶颈：数仓离线同步周期长（T+1），规则校验依赖人工梳理，无法应对 “商品类目量级激增”。

2.2 质量风险：规则复杂度与

校验能力的失衡

典型问题：当前的管理类目映射规则，依赖业务收集提报，但从实际操作看管理三级类目映射规则提报质量较差(主要原因为：业务无法及时校验提报规则是否准确，是否穷举完善，是否完全无交叉)，存在大量重复 / 遗漏风险。

2.3 系统耦合：底层变更对

下游应用的多米诺效应

连锁影响：管理类目规则变更会需同步更新交易后台、智能运营系统、商运关系工作台等多下游系统，如无法及时同步，可能会影响下游应用如商运关系工作台的员工分工范围的准确性，影响商家找人、资质审批等场景应用。

三、技术方案：从架构设计到核心模块拆解

3.1 分层架构：解耦业务与数据链路

3.2 核心模块技术实现

规则生命周期管理：规则操作流程

提交管理类目唯一性校验规则

新增：id为空，则为新增

删除：当前db数据不在提交保存列表中

更新：名称或是否兜底类目或规则改变则发生更新【其中如果只有名称改变则只触发审批，不需等待数据校验，业务规则校验逻辑为将所有规则包含id，按照顺序排序拼接之后结果是否相等】

多级类目查询

构建管理类目树

/**
 * 构建管理类目树
 */
public List<ManagementCategoryDTO> buildTree(List<ManagementCategoryEntity> managementCategoryEntities) {
    Map<Long, ManagementCategoryDTO> managementCategoryMap = new HashMap<>();
    for (ManagementCategoryEntity category : managementCategoryEntities) {
        ManagementCategoryDTO managementCategoryDTO = ManagementCategoryMapping.convertEntity2DTO(category);
        managementCategoryMap.put(category.getId(), managementCategoryDTO);
    }
    
    // 找到根节点
    List<ManagementCategoryDTO> rootNodes = new ArrayList<>();
    for (ManagementCategoryDTO categoryNameDTO : managementCategoryMap.values()) {
        //管理一级类目 parentId是0
        if (Objects.equals(categoryNameDTO.getLevel(), ManagementCategoryLevelEnum.FIRST.getId()) && Objects.equals(categoryNameDTO.getParentId(), 0L)) {
            rootNodes.add(categoryNameDTO);
        }
    }
    // 构建树结构
    for (ManagementCategoryDTO node : managementCategoryMap.values()) {
        if (node.getLevel() > ManagementCategoryLevelEnum.FIRST.getId()) {
            ManagementCategoryDTO parentNode = managementCategoryMap.get(node.getParentId());
            if (parentNode != null) {
                parentNode.getItems().add(node);
            }
        }
    }
    return rootNodes;
}

填充管理类目规则



/**
 * 填充规则信息
 */
private void populateRuleData
(List<ManagementCategoryDTO> managementCategoryDTOS, List<ManagementCategoryRuleEntity> managementCategoryRuleEntities) {
    if (CollectionUtils.isEmpty(managementCategoryDTOS) || CollectionUtils.isEmpty(managementCategoryRuleEntities)) {
        return;
    }
    List<ManagementCategoryRuleDTO> managementCategoryRuleDTOS =managementCategoryMapping.convertRuleEntities2DTOS(managementCategoryRuleEntities);
    // 将规则集合按 categoryId 分组
    Map<Long, List<ManagementCategoryRuleDTO>> rulesByCategoryIdMap = managementCategoryRuleDTOS.stream()
            .collect(Collectors.groupingBy(ManagementCategoryRuleDTO::getCategoryId));
    // 递归填充规则到树结构
    fillRulesRecursively(managementCategoryDTOS, rulesByCategoryIdMap);


}


/**
 * 递归填充规则到树结构
 */
private static void fillRulesRecursively
(List<ManagementCategoryDTO> managementCategoryDTOS, Map<Long, List<ManagementCategoryRuleDTO>> rulesByCategoryIdMap) {
    if (CollectionUtils.isEmpty(managementCategoryDTOS) || MapUtils.isEmpty(rulesByCategoryIdMap)) {
        return;
    }
    for (ManagementCategoryDTO node : managementCategoryDTOS) {
        // 获取当前节点对应的规则列表
        List<ManagementCategoryRuleDTO> rules = rulesByCategoryIdMap.getOrDefault(node.getId(), new ArrayList<>());
        node.setRules(rules);
        // 递归处理子节点
        fillRulesRecursively(node.getItems(), rulesByCategoryIdMap);
    }
}

状态机驱动：管理类目生命周期管理

超时机制：基于时间阈值的流程阻塞保护

其中，为防止长时间运营处于待确认规则状态，造成其他规则阻塞规则修改，定时判断待确认规则状态持续时间，当时间超过xxx时间之后，则将待确认状态改为长时间未操作，放弃变更状态，并飞书通知规则修改人。

管理类目状态变化级联传播策略

类目生效和失效状态为级联操作。规则如下：

管理二级类目有草稿状态时，不允许下挂三级类目的编辑；
管理三级类目有草稿状态时，不允许对应二级类目的规则编辑；
类目生效失效状态为级联操作，上层修改下层级联修改状态，如果下层管理类目存在草稿状态，则自动更改为放弃更改状态。

规则变更校验逻辑

当一次提交，可能出现的情况如下。一次提交可能会产生多个草稿，对应多个审批流程。

新增管理类目规则：

一级管理类目可以直接新增（点击新增一级管理类目）
二级管理类目和三级管理类目不可同时新增
三级管理类目需要在已有二级类目基础上新增

只有名称修改触发直接审批，有规则修改需要等待数仓计算结果之后，运营提交发起审批。

交互通知中心：飞书卡片推送

变更规则数据计算结果依赖数仓kafka计算结果回调。
基于飞书卡片推送数仓计算结果，回调提交审批和放弃变更事件。

飞书卡片：

卡片结果

卡片操作结果

审批流程：多维度权限控制与飞书集成

提交审批的四种情况：

名称修改
一级类目新增
管理类目规则修改
生效失效变更

审批通过，将草稿内容更新到管理类目表中，将管理类目设置为生效中。

审批驳回，清空草稿内容。

审批人分配机制：多草稿并行审批方案

一次提交可能会产生多个草稿，对应多个审批流程。

审批逻辑

public Map<String, List<String>> buildApprover(
        ManagementCategoryDraftEntity draftEntity,
        Map<Long, Set<String>> catAuditorMap,
        Map<String, String> userIdOpenIdMap,
        Integer hasApprover) {
    
    Map<String, List<String>> nodeApprover = new HashMap<>();


    // 无审批人模式，直接查询超级管理员
    if (!Objects.equals(hasApprover, ManagementCategoryUtils.HAS_APPROVER_YES)) {
        nodeApprover.put(ManagementCategoryApprovalField.NODE_SUPER_ADMIN_AUDIT,
                queryApproverList(0L, catAuditorMap, userIdOpenIdMap));
        return nodeApprover;
    }
    
    Integer level = draftEntity.getLevel();
    Integer draftType = draftEntity.getType();
    boolean isEditOperation = ManagementCategoryDraftTypeEnum.isEditOp(draftType);
    
    // 动态构建审批链（支持N级类目）
    List<Integer> approvalChain = buildApprovalChain(level);
    for (int i = 0; i < approvalChain.size(); i++) {
        int currentLevel = approvalChain.get(i);
        Long categoryId = getCategoryIdByLevel(draftEntity, currentLevel);
        
        // 生成节点名称（如：NODE_LEVEL2_ADMIN_AUDIT）
        String nodeKey = String.format(
                ManagementCategoryApprovalField.NODE_LEVEL_X_ADMIN_AUDIT_TEMPLATE,
                currentLevel
        );
        
        // 编辑操作且当前层级等于提交层级时，添加本级审批人 【新增的管理类目没有还没有对应的审批人】
        if (isEditOperation && currentLevel == level) {
            addApprover(nodeApprover, nodeKey, categoryId, catAuditorMap, userIdOpenIdMap);
        }
        
        // 非本级审批人（上级层级）
        if (currentLevel != level) {
            addApprover(nodeApprover, nodeKey, categoryId, catAuditorMap, userIdOpenIdMap);
        }
    }
    
    return nodeApprover;
}


private List<Integer> buildApprovalChain(Integer level) {
    List<Integer> approvalChain = new ArrayList<>();
    if (level == 3) {
        approvalChain.add(2); // 管二审批人
        approvalChain.add(1); // 管一审批人
    } else if (level == 2) {
        approvalChain.add(2); // 管二审批人
        approvalChain.add(1); // 管一审批人
    } else if (level == 1) {
        approvalChain.add(1); // 管一审批人
        approvalChain.add(0); // 超管
    }
    return approvalChain;
}

3.3 数据模型设计

3.4 数仓计算逻辑

同步数据方式

方案一：

每次修改规则之后通过调用SQL触发离线计算

优势：通过SQL调用触发计算，失效性较高

劣势：ODPS 资源峰值消耗与SQL脚本耦合问题

因为整个规则修改是三级类目维度，如果同时几十几百个类目触发规则改变，会同时触发几十几百个离线任务。同时需要大量ODPS 资源；
调用SQL方式需要把当前规则修改和计算逻辑的SQL一起调用计算。

方案二：

优势：同时只会产生一次规则计算

劣势：实时性受限于离线计算周期

实时性取决于离线规则计算的定时任务配置和离线数据同步频率，实时性不如直接调用SQL性能好
不重不漏为当前所有变更规则维度

技术决策：常态化迭代下的最优解

考虑到管理类目规则平均变更频率不高，且变更时间点较为集中（非紧急场景占比 90%），故选择定时任务方案实现：

资源利用率提升：ODPS 计算资源消耗降低 80%，避免批量变更时数百个任务同时触发的资源峰值；
完整性保障：通过全量维度扫描确保规则校验无遗漏，较 SQL 触发方案提升 20% 校验覆盖率；
可维护性优化：减少 SQL 脚本与业务逻辑的强耦合，维护成本降低 80%。

数据取数逻辑

生效中规则计算

草稿+生效中规格计算

如果是新增管理类目，直接参与计算。

如果是删除管理类目，需要将该删除草稿中对应的生效管理类目排除掉。

如果是更新：需要将草稿中的管理类目和规则替换生效中对应的管理类目和规则。

数仓实现

数据流程图

四、项目成果与技术价值

预期效率提升：从 “周级” 到 “日级” 的跨越

管理一级 / 二级类目变更开发零成本，无需额外人力投入
管理三级类目变更相关人力成本降低 100%，无需额外投入开发资源
规则上线周期压缩超 90%，仅需 1 - 2 天即可完成上线

质量保障：自动化校验替代人工梳理

规则重复 / 遗漏检测由人工梳理->自动化计算
下游感知管理类目规则变更由人工通知->实时感知

技术沉淀：规则模型化能力

沉淀管理类目规则配置模型，支持未来四级、五级多级管理类目快速适配。

五、总结

未来优化方向：

规则冲突预警：基于AI预测高风险规则变更，提前触发校验
接入flink做到实时计算管理类目和对应商品关系

技术重构的本质是 “释放业务创造力”

管理类目配置线上化项目的核心价值，不仅在于技术层面的效率提升，更在于通过自动化工具链，让业务方从 “规则提报的执行者” 转变为 “业务策略的设计者”。当技术架构能够快速响应业务迭代时，企业才能在电商领域的高频竞争中保持创新活力。

往期回顾

大模型如何革新搜索相关性？智能升级让搜索更“懂你”｜得物技术
RAG—Chunking策略实战｜得物技术
告别数据无序：得物数据研发与管理平台的破局之路
从一次启动失败深入剖析：Spring循环依赖的真相｜得物技术
Apex AI辅助编码助手的设计和实践｜得物技术

文 /维山

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

大模型如何革新搜索相关性？智能升级让搜索更“懂你”｜得物技术

掘金专栏-得物技术

得物技术

2025年11月4日 10:46

你是否曾在社区搜索时遇到这样的困扰：想找一双“平价学生党球鞋”，结果出现的多是限量联名款？或者输入“初冬轻薄通勤羽绒服”，却看到厚重登山款？这类“搜不准”的情况，正是搜索相关性技术要解决的

阅读视图

一、背景

二、PAG是什么？

三、如何实现核心交互链路？

四、基础PAG播放器实现

加载PAG SDK

初始化播放器

替换图层及文本

PagPlayer截帧（导出PagPlayer当前展示内容）

五、图片变换功能开发：实现人像拖拽、缩放与旋转

功能目标

效果展示

组件设计理念

数据流设计

六、交互与预览实时同步

逻辑架构：三层协同同步模型

关键方案：低损耗 + 高实时性的平衡

边界场景处理：保障同步稳定性

PAG人像居中无遮挡

七、批量生成

关键技术方案

核心架构

整体批量合成流程

单个模板处理流程

并发工作协程模式

八、性能优化与降级兼容

性能优化

降级兼容

九、小结

往期回顾

文 /无限

一、前 言

二、什么是FMP

三、FMP 计算原理

3.1核心思想

3.2FMP的三种计算方式

3.3新算法vs传统算法

3.4关键算法

四、时间标记机制

4.1DOM变化监听

4.2时间标记

4.3标记值获取

五、资源加载考虑

5.1资源类型识别

5.2资源时间获取

5.3综合时间计算

六、子页面支持

6.1时间偏移处理

6.2FMP值调整

七、FMP的核心优势

7.1用户感知导向

7.2多维度计算体系

7.3高精度测量

八、FMP的实际应用场景

8.1性能监控实践

8.2用户体验评估

8.3优化指导价值

九、总结

往期回顾

文 /阿列

一、项目概览

二、整体架构

三、LogDB 统一存储

3.1索引键

3.2变量复用IContext

3.3存储引擎封装IKVStore

3.4日志条目存储DB

3.5对外存储API实现

四、总结

往期回顾

文 /酒米

一、背 景

二、TiDB 架构

三、TiDB v7 版本新特性

四、TiDB升级之旅

五、升级遇到的问题

六、升级带来的收益

七、选择 TiDB 的原因

八、总结

往期回顾

一、前言

一、背景