1、数据分级概述：为什么需要数据分级？核心概念与业务驱动力

说到接口高可用，很多人第一反应就是加机器、搞限流、做熔断。你别笑，我刚开始也是这么想的。

但后来我发现，有个更根本的问题被忽略了——你的数据，到底值不值得你花这么多钱去保护？

你想想看，把用户头像的查询接口和支付下单的接口用同一套高可用策略，结果就是成本失控，该保的没保住，不该保的浪费了一堆资源。说白了，这就是没有数据分级意识。

1.1 为什么需要数据分级？——血的教训

我2018年接过一个电商平台的线上事故复盘。他们所有接口都挂了同一个熔断阈值，结果某个低频低价值的报表查询接口触发了熔断，把核心的下单接口也带崩了。那一晚，直接损失上千万。

为什么会这样？

因为所有数据一视同仁。低价值数据占用了高价值数据的高可用资源，甚至反过来把高价值数据拖下水。

所以，数据分级的核心动机其实就一个：把有限的保护资源，花在刀刃上。

1.2 核心概念：你到底要给数据打什么标签？

我个人习惯把数据分级看作三件事：等级、维度、边界。

• 等级：比如 L1（核心交易）、L2（用户隐私）、L3（业务过程）、L4（日志/缓存）。
• 维度：从安全性、一致性、可用性、实时性四个角度去打分。
• 边界：每个等级的数据，它的保护范围和融断隔离要划清楚。

这里有个表格，是我在做架构设计时经常用的对照表，你可以直接拿去用：

数据级别	定义	典型示例	安全要求	可用性目标
L1	核心交易/账务	订单、支付、余额	最高	99.999%
L2	用户隐私/敏感信息	手机号、身份证、地址	高标准	99.99%
L3	业务过程/衍生数据	商品详情、搜索历史	中等	99.9%
L4	日志/缓存/临时数据	用户行为日志、CDN缓存	低	99%（可接受降级）

嗯，这里要注意，L4 不等于没价值，只是说在资源争抢时它可以被牺牲掉。

1.3 业务驱动力：谁在逼你做数据分级？

很多团队不做数据分级，不是因为技术难，而是觉得“现在系统挺稳的”。直到出现下面这些情况：

1. 成本失控——所有接口都上多活+强一致性，结果月账单直线上涨。
2. 雪崩频发——低等级接口的异常流量打穿了公共的连接池核心接口跟着挂。
3. 合规压力——《数据安全法》《个保法》明确要求对个人敏感信息实施分级分类管理。不分级，就是违法。
4. 扩展瓶颈——你没法对所有数据做统一的“一刀切”高可用方案，系统越滚越大，越改越乱。

说白了，不分级，你永远在“裸奔”和“穿盔甲”之间反复横跳。不是保护过度，就是保护不足。

1.4 数据分级与高可用架构的关系

我经常把高可用架构比作一个医院。急诊室（L1）必须 24 小时有专家、有 ICU、有备用电源；普通门诊（L3）可以排排队，甚至偶尔停诊半天问题不大。如果你把门诊也当急诊来装修，那医院肯定开不下去。

所以，数据分级是高可用架构的“投资决策表”。它告诉我们：

• 哪些数据值得做异地多活（L1）；
• 哪些数据做同城容灾就够了（L2）；
• 哪些数据只用单机房加缓存（L3）；
• 哪些数据降级或丢弃也不影响核心业务（L4）。

下面这张图，就是我经常在团队里画的数据分级驱动高可用架构逻辑，你可以对着看：

1.5 实战建议：数据分级落地三步走

有些团队一上来就想画个完美的分级矩阵，结果搞了两个月还在开会。我的建议是：

• 第一步：先找个时间，把你们系统里所有接口的数据列一个清单，按“丢了会死”“丢了会赔”“丢了会烦”“丢了无所谓”四个档位先粗分一遍。
• 第二步：对于每个等级，明确它的可用性目标（SLO）和保护成本上限。比如 L1 可用性 SLA 必须 99.99%，但 L3 可以降到 99.9%。
• 第三步：按照分级结果，重新规划资源池和架构部署。L1 和 L2 的接口走独立的连接池和熔断器，别和 L3、L4 混在一起。

好了，这就是我对数据分级的理解。说到底，它是一种理性投资的思维——知道自己哪些数据值得砸重金保护，哪些数据差不多就行。下一节我们会细讲具体怎么给数据打标签，也就是数据分级的标准制定。先消化消化。