一、背景 随着得物App各业务功能的丰富和升级，得物App内可供用户体验的内容和活动逐步增多，在用户App内体验时长不断增长的大背景下，App使用过程中的体验问题变得愈发重要。同时，在整个功能研发流程

随着系统复杂度的指数级增长，我们对现有系统的可观测性进行了全面梳理，为了提高稳定性，我们希望建设一个业务场景维度全链路变更事件中心， 以“聚焦做好可观测性”为核心目标，通过建设监控平台的事件中心与全链

大仓应用从未发生因治理导致的线上故障，实现了高效、稳定、可持续的前端大仓应用研发稳定性治理体系。** 随着目前大模型的不断迭代，后续结合AI智能体对研发流程进行稳定性加固，相信大仓应用的稳定性会更上一

一、前言 在分布式系统架构中，消息队列如同畅通的“信息神经网络”，承担着解耦、削峰与异步通信的核心使命。在众多成熟方案中，RocketMQ凭借其阿里巴巴与Apache双重基因，以卓越的金融级可靠性、万

一、背景 近期，得物社区活动「用篮球认识我」推出 “用户上传图片生成专属球星卡” 核心玩法。 初期规划由服务端基于 PAG 技术合成，为了让用户可以更自由的定制专属球星卡，经多端评估后确定：由 H5

在前端开发领域，Ant Design 一直是企业级 React 应用的首选 UI 库之一。随着 Ant Design 6.0 的发布，我们又见证了一次聚焦于组件功能与用户体验的革新。

一、概述 简介 设计模式（Design Pattern）是前辈们对代码开发经验的总结，它不是语法规定，是解决特定问题的一系列思想，是面向对象设计原则的具象化实现， 是解决 “需求变更” 与 “系统复杂

一、引言 随着互联网技术的飞速发展，现代系统面临着前所未有的并发压力和可用性要求。从电商秒杀到社交媒体直播，从金融交易到物联网设备接入，系统需要处理百万级甚至千万级的并发请求，同时保证99.999%的

一、背景 某天打开组内的Grafana仪表盘，突然好奇我们的埋点从被触发后是如何一步一步变成所展示的各种图表的，于是在我进行一系列的探索之后，总结出了以下链路： 在指标工厂新建指标，确定埋点key和埋

一、MCP设计理念 在浅析 MCP 原理之前，有必要搞清楚两个问题：MCP 是什么？为什么会出现？ 以此明晰它存在的价值和意义。 首先，MCP（Model Context Protocol，模型上下文

一、前 言 作为新一代品质生活购物社区，得物App以正品电商和品质生活社区作为两大核心服务。成立十年来，它始终致力于帮助用户得到美好生活，已成为年轻用户重要的潮流阵地与品质生活购物平台。 得物在坚持严

一、前 言

最近在项目中遇到了页面加载速度优化的问题，为了提高秒开率等指标，我决定从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 是纯 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升级实践

文 /酒米

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

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

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

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

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

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

一、背 景

得物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 资源管理能力，适合进行多业务系统数据归集方案，实现数据库资源池化多种自定义方案。技术研究方面我们数据库团队会持续投入，将产品最好的解决方案引入现网环境。

往期回顾

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

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

3. RAG—Chunking策略实战｜得物技术

4. 告别数据无序：得物数据研发与管理平台的破局之路

5. 从一次启动失败深入剖析：Spring循环依赖的真相｜得物技术

文 /岱影

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

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

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

一、引言

在电商交易领域，管理类目作为业务责权划分、统筹、管理核心载体，随着业务复杂性的提高，其规则调整频率从最初的 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 天即可完成上线

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

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

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

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

五、总结

未来优化方向：

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

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

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

往期回顾

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

2. RAG—Chunking策略实战｜得物技术

3. 告别数据无序：得物数据研发与管理平台的破局之路

4. 从一次启动失败深入剖析：Spring循环依赖的真相｜得物技术

5. Apex AI辅助编码助手的设计和实践｜得物技术

文 /维山

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

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

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

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