列族存储 | 自在学

列族存储：先想清楚怎么查，再决定怎么存

假设你正在给一座自动化工厂做设备监控。几千台传感器每秒都在上报温度、振动、电流和运行状态，值班人员最常问的却不是“把全部数据都给我”，而是下面这些很具体的问题：

某台设备今天最近 100 条采样是什么？
某条产线过去一小时出现过哪些告警？
某个租户的设备当前分别处于什么状态？
过期 30 天的原始遥测能不能自动清理？

数据刚开始只有几百万条时，一张关系表加几个索引似乎就能顶住。可当写入量、保存周期和设备数一起增长，我们很快会碰到三道坎：索引维护越来越重，单机容量不够，跨节点查询又很难预测延迟。列族存储正是为这类“写得多、规模大、访问路径相对明确”的问题准备的。

自动化设备遥测进入列族存储的场景

不过，列族存储并不是“把关系表横过来”，也不是“列越多越先进”。它真正改变的是建模顺序：我们先列出应用一定会执行的查询，再用行键、分区键、聚簇列和列族把这些查询安排成少量、连续、可定位的读写。理解了这个顺序，后面的概念才不会变成一堆零散术语。

本章会把 HBase 一类系统的“行键—列族—列限定符—时间版本”模型，与 Cassandra 的“分区键—聚簇列—普通列”模型放在一起讲。它们都属于宽列思路，但具体语义和查询接口并不完全相同。设计时要看你所用产品的规则，不能把某个产品的特性直接套到所有列族数据库上。

先建立一张正确的心智地图

为什么叫“宽列”

在普通关系表里，列由表结构统一声明，绝大多数行共享同一组列。宽列模型允许一行拥有很多列，而且某些实现允许不同的行出现不同列限定符。没有写入的单元格通常不占实际数据空间，因此它很适合稀疏、随对象而变化的数据。

想象一张设备表：温控器有“设定温度”，振动传感器有“峰值频率”，视觉相机有“曝光时间”。我们不必为了相机字段让每台温控器都背上一排空值。与此同时，真正影响性能的列族仍需要提前规划，因为同一列族的数据往往会被一起存储、压缩、缓存和回收。

“灵活”因此有明确边界：列限定符可以灵活，并不代表表设计可以随意；字段不占空间，也不代表一行可以无限增长；查询语言看起来像 SQL，也不代表可以任意联结和过滤。

HBase 视角：一个值由四个坐标定位

在 HBase 风格的数据模型里，一个单元格可以用下面四个坐标找到：

text

(行键, 列族:列限定符, 时间版本) -> 值

例如，我们可以这样理解一条设备记录：

text

行键：tenant-07#device-2048#2026-08-11
 
info:model              -> 温振一体传感器
info:workshop           -> 二号车间
metric:10:30:01#temp    -> 68.4
metric:10:30:01#vib     -> 3.8
metric:10:30:02#temp    -> 68.7

这里的 info 和 metric 是列族，model、workshop、10:30:01#temp 是列限定符。列族通常提前创建，列限定符则可以在写入时出现。一个单元格还可以保留多个带时间戳的版本，读取时若不指定版本，通常会拿到最新值。

Cassandra 视角：一张表由分区和排序共同塑形

Cassandra 使用 CQL 后，表面上更像关系表，但主键的结构承担了两件完全不同的事：

分区键决定一组数据落到哪些副本节点，是数据分布和定位的第一入口。
聚簇列决定同一分区内部的排序，也决定你能高效执行哪些范围查询。

假设主键是 PRIMARY KEY ((tenant_id, device_id, bucket_date), event_time, event_id)，括号里的三个字段共同组成分区键；后面的 event_time 和 event_id 是聚簇列。相同租户、设备和日期的数据会进入同一逻辑分区，再按采集时间和事件编号排序。

列族数据模型中的行键、列族与时间版本

下面这个小工具把两种观察角度放到同一块画布上。你可以用按钮切换，看看“一个单元格如何定位”和“一个查询如何落到分区”分别强调什么。

“超级列”是早期 Cassandra 数据模型里出现过的历史概念，不应再作为现代 CQL 建模的核心。现在表达嵌套结构时，通常会使用集合、用户自定义类型或重新设计查询表；表达一对多的时序记录时，更常用分区键配合聚簇列。

真正的起点：先把查询写出来

关系型建模常从实体和关系出发，再通过联结组合出不同查询。列族建模更像是给常用查询修专用车道：车道入口就是分区键，车道内部的排列规则就是聚簇列。入口选错，后面再加机器也救不了一次全表扫描。

我们继续使用设备遥测场景，先列出三个明确访问模式：

按设备和日期读取一段时间内的遥测。
按产线和日期读取最近告警。
按租户读取每台设备的当前状态。

这三个查询的入口、排序和返回字段都不一样。与其强迫一张“万能表”照顾所有方向，不如为每个稳定查询准备一张表。数据会有冗余，但每次读取都更直接，延迟也更容易预测。

从查询问题推导分区键和聚簇列

为“设备一天内的遥测”建表

先看第一个访问模式。我们希望一次查询只碰一个分区，并且数据天然按时间倒序排列：

sql

CREATE KEYSPACE IF NOT EXISTS automation
WITH replication = {
  'class': 'NetworkTopologyStrategy',
  'dc1': 3
};
 
CREATE TABLE IF NOT EXISTS automation.telemetry_by_device_day (
  tenant_id text,
  device_id text,
  bucket_date date,
  event_time timestamp,
  event_id timeuuid,

这份主键值得慢下来读一遍：

tenant_id 避免不同租户的同名设备混在一起。
device_id 让读写压力分散到大量设备。
bucket_date 把无限增长的设备历史切成一天一个分区。
event_time 让时间范围查询成为分区内的连续读取。
event_id 处理同一毫秒内多条事件的稳定排序和唯一性。

写入一条数据时，普通列可以只给这次真正存在的值：

sql

INSERT INTO automation.telemetry_by_device_day (
  tenant_id,
  device_id,
  bucket_date,
  event_time,
  event_id,
  temperature,
  vibration,
  running_state
) VALUES (
  'tenant-07',
  'device-2048',
  '2026-08-11',
  '2026-08-11T10:30:02.180Z',
  now(),
  68.7,
  3.8,
  '运行'
)

查询时，我们给出完整分区键，再对第一个聚簇列做范围限制：

sql

SELECT event_time, temperature, vibration, running_state
FROM automation.telemetry_by_device_day
WHERE tenant_id = 'tenant-07'
  AND device_id = 'device-2048'
  AND bucket_date = '2026-08-11'
  AND event_time >= '2026-08-11T10:00:00Z'
  AND event_time <  '2026-08-11T11:00:00Z'
LIMIT 100;

这条查询快，不是因为 SELECT 写得短，而是因为主键已经把目标数据安排在一个可定位、可连续扫描的分区里。

为什么要有日期桶

如果只用 (tenant_id, device_id) 做分区键，同一设备的所有历史会不断塞进同一个分区。运行几年后，这个分区可能变得非常宽，修复、压实、备份和读取都会更重。加入日期桶后，分区大小有了上限。

不过，桶也不是越小越好。每分钟一个桶会制造大量小分区，跨一小时查询就要发出 60 次读取。正确做法是拿真实写入频率、单条大小、保存周期和查询跨度估算，再用压测验证一天、一小时还是一周更合适。

一张表通常只服务一组相近查询

第二个访问模式是“按产线看告警”，入口不再是设备，而是产线。我们可以再建一张查询表：

sql

CREATE TABLE IF NOT EXISTS automation.alarms_by_line_day (
  tenant_id text,
  line_id text,
  bucket_date date,
  alarm_time timestamp,
  alarm_id timeuuid,
  device_id text,
  alarm_level text,
  alarm_code text,
  message text,
  PRIMARY KEY (
    (tenant_id, line_id, bucket_date),
    alarm_time,

同一条告警会写入设备视角和产线视角两张表。这就是反规范化：用可控的数据冗余换取简单而稳定的读取。代价也很真实——应用要负责多份数据的写入、重试、校对和删除策略。如果这些副本必须严格同步，就要在业务层设计幂等事件、事务消息或补偿流程，不能假装“多写一张表”天然没有一致性成本。

列族建模时，一个很好用的检查句是：“这条查询能否给出完整分区键，并在分区内部按聚簇顺序读取？”如果答案是能，设计通常已经走在正确方向；如果答案是不能，就要重新审视访问模式、查询表或索引，而不是急着加入允许过滤的选项。

分区键决定数据会不会均匀

分区键不只是查询条件，它还影响数据分布。Cassandra 会对分区键计算令牌，再把分区放到负责相应令牌范围的节点上。大量不同分区键通常能把压力摊开；少数极热分区则会让特定副本持续忙碌。

最常见的热点：时间戳放在最前面

在按行键字典序排列的宽列系统中，如果行键以持续递增的时间戳开头，新写入会集中在键空间的一端。即便集群有很多节点，最新数据仍可能压到同一个区域。更稳妥的办法是把高基数对象放在前面，再把时间用于后缀或桶：

text

不理想：20260811103002180#device-2048
更稳妥：device-2048#20260811#103002180

在使用哈希分区器的 Cassandra 中，单调时间戳不会以完全相同的方式形成“键空间尾部热点”，但如果所有写入仍共享同一个分区键，它照样会变成单分区热点。产品实现不同，问题表象不同，核心判断却相同：并发写入到底能不能分散到足够多的分区和副本节点。

错误行键造成热点与合理分区后的均匀写入

下面的分区实验台不计算某个真实数据库的容量上限，它用一个简化模型帮助你比较几种键设计。调整设备数、每台每秒事件数和桶宽，就能看到“单分区写入”和“分区数量”如何变化。

设计分区键时检查四件事

先估算基数。分区键要能产生足够多的不同取值，才有机会把数据和流量摊到集群各处；只有“地区”“状态”这类少量取值通常不够。

再估算单分区写入峰值。不要只看平均值，设备集中上线、整点任务和故障风暴都可能让某个分区突然变热。

接着估算分区生命周期内的总行数和总字节数。日期桶、小时桶或哈希分片都可以限制增长，但会增加跨桶读取和应用聚合成本。

最后用真实查询压测。写入均匀只是起点，还要观察尾延迟、压实积压、墓碑扫描、节点磁盘与网络是否均衡。

一次写入究竟经历了什么

列族系统之所以擅长持续写入，与它的存储路径密切相关。以 Cassandra 的 LSM 思路为例，更新数据时不需要先在磁盘上找到旧页再原地改写，而是先追加、后整理。

写入路径：先快速接住，再后台归并

一次典型写入可以拆成下面几步：

客户端把请求发给协调节点。
协调节点找到负责该分区的副本，并把写入发给它们。
每个副本把变更追加到提交日志，同时写入内存里的 MemTable。
达到条件后，MemTable 按排序结果刷成磁盘上的不可变 SSTable。
后台压实把多个 SSTable 合并，处理被覆盖的旧值和满足清理条件的墓碑。

Cassandra 从提交日志到 SSTable 的写入路径

提交日志负责故障恢复，MemTable 负责承接和排序近期写入，SSTable 负责持久保存。因为 SSTable 不会被原地修改，同一个分区的新旧版本可能散落在多个文件里，读取时需要合并结果；压实又会消耗额外磁盘读写。这就是高写入吞吐背后的账单。

“写入成功”不等于“MemTable 已经刷成 SSTable”，更不等于“所有副本都已确认”。前者由提交日志提供崩溃恢复基础，后者取决于本次请求选择的一致性级别。把持久化阶段和副本确认数混为一谈，会让故障判断变得很危险。

读取路径：找齐候选，再选出当前结果

读取不会只看一个文件。系统可能先检查 MemTable，再借助 Bloom Filter 和索引判断哪些 SSTable 可能包含目标分区，最后合并同一单元格或同一行的多个版本。时间戳、墓碑和 TTL 状态会参与“哪个值应该对客户端可见”的判断。

Bloom Filter 可以快速说明“某个 SSTable 肯定没有这个分区”或“可能有”，却不能保证“可能有”就一定有。它减少了无意义磁盘访问，但不会替代真正的数据读取。

压实不是可有可无的清洁任务

压实会读取多个 SSTable，生成新的合并文件，再删除不再需要的旧文件。它能减少读取时要合并的文件数，也让满足条件的墓碑和过期数据获得物理回收机会；与此同时，它会带来写放大和磁盘空间峰值。

自动化遥测通常带有明显时间窗口，运维时可以选择适合时序写入和过期规律的压实策略。无论选择哪种策略，都要同时观察待压实字节数、SSTable 数量、磁盘利用率、读写尾延迟和墓碑扫描，而不是只盯着平均吞吐。

副本与可调一致性：每次请求都在做取舍

为了让节点故障时仍能服务，数据会保存到多个副本。假设副本因子 RF = 3，一份分区数据会落在三个副本上。客户端连接的协调节点负责转发请求并等待足够多的响应。

在 Cassandra 的常见一致性级别里：

级别	等待的副本响应	直观特点	常见考虑
`ONE`	1 个	延迟较低，可用范围较宽	可能读到尚未追上最新写入的副本
`QUORUM`	多数副本	在延迟与新鲜度之间折中	`RF=3` 时需要 2 个响应
`ALL`	全部副本	要求最严格	任一副本不可达都可能让请求失败
`LOCAL_QUORUM`	本地数据中心的多数副本	避免跨地域等待	适合多数据中心的本地读写路径

副本因子为 3 时 ONE、QUORUM 与 ALL 的权衡

一个常用判断是让读确认数 R 与写确认数 W 满足：

text

R + W > RF

这意味着读集合和写集合至少会有一个副本重叠。以 RF=3 为例，读写都用 QUORUM 时，2 + 2 > 3。但这不是把系统变成单机事务数据库的魔法公式：并发写入的时间戳处理、跨数据中心复制、故障恢复和业务操作范围仍然需要单独理解。

下面可以自行调节副本数、读确认数和写确认数。工具会同时显示集合重叠条件与最多可容忍的不可用副本数，帮助你看到“一致性把握”和“请求可用性”为什么不能只选一边。

一致性级别是按操作选择的

同一张表不必永远使用同一级别。仪表盘上的非关键趋势图可能优先考虑低延迟；设备控制指令的状态确认则可能要求本地多数副本参与。真正的选择单位是业务操作，而不是“我们的数据库统一设成最终一致”这样一句过于笼统的口号。

遇到副本暂时不可用时，系统还会通过提示转交、读取修复和运维修复等机制缩短副本差异。它们能帮助数据重新汇合，却不能代替容量规划、定期修复与故障演练。高可用来自副本、拓扑、确认策略和运维纪律共同作用，不是只把节点数改大。

TTL、删除与墓碑：数据“过期”并不等于立刻消失

自动化系统常把原始遥测保存 30 天，把聚合结果保存一年。TTL 可以把生命周期直接附在写入值上：

sql

INSERT INTO automation.telemetry_by_device_day (
  tenant_id,
  device_id,
  bucket_date,
  event_time,
  event_id,
  temperature
) VALUES (
  'tenant-07',
  'device-2048',
  '2026-08-11',
  '2026-08-11T10:35:00Z',
  now(),
  69.1
) USING TTL 2592000;

30 天后，这个值对正常读取不再可见。但在分布式、不可变文件的存储方式下，系统不能简单地在原文件中抹掉几个字节。过期或显式删除会留下带时间戳的删除标记，也就是墓碑；墓碑需要传播到副本，并在满足安全条件后由压实回收。

这带来三个容易忽略的事实：

TTL 到期是逻辑不可见的时刻，不一定是磁盘空间立刻下降的时刻。
大范围查询扫过大量墓碑，会增加读取工作。
如果修复、宽分区、压实和回收窗口配置不协调，旧值可能长期占空间，错误清理还可能带来数据重新出现的风险。

因此，TTL 不是“免费定时删除”。使用前要把写入速率、到期分布、压实策略、修复周期和磁盘余量一起考虑。时序表如果每天有清晰的桶，通常也更容易让生命周期和物理文件边界靠近。

不要为了让空间马上下降就随意缩短墓碑安全窗口，也不要在没有修复纪律和故障演练的情况下启用激进清理。墓碑保留时间承担着让离线副本学会“这条数据已经删除”的职责，清得过早可能比清得慢更危险。

计数器、批处理与轻量事务的边界

列族数据库并非完全没有原子能力，但它们提供的保证通常围绕单行或单分区展开。我们需要先问“操作范围是什么”，再谈“是否原子”。

单行或单分区内的更新

HBase 的行级变更可以在一行范围内保持原子。Cassandra 同一分区内的变更也拥有比跨分区操作更清晰的原子与隔离边界。这个边界很适合“同时更新同一设备当前状态的多个字段”，却不能直接推导出“从账户 A 扣款并给账户 B 加款”也安全。

批处理不是批量提速按钮

CQL 的 BATCH 主要用来组织需要原子协调的一组变更，尤其是同一分区内的多项修改。把许多互不相关分区的写入塞进一个大批次，可能把协调压力集中起来，还会付出批次日志和跨节点协作成本。高吞吐导入通常更适合客户端受控并发和异步写入，而不是一个超大的跨分区批次。

轻量事务适合少量条件竞争

当你需要“只有版本号仍是 17 才更新为 18”这类比较后写入语义时，可以使用轻量事务。它比普通写入需要更多协调，因此适合设备主控权、唯一注册、状态转换等低频关键路径，不适合每秒海量遥测都走条件竞争。

sql

UPDATE automation.device_owner
SET owner_id = 'controller-b', version = 18
WHERE tenant_id = 'tenant-07'
  AND device_id = 'device-2048'
IF version = 17;

计数器要防止重试导致重复

Cassandra 的计数器列支持增减，但计数更新天然不是幂等操作。请求超时后，客户端可能不知道服务端到底有没有执行成功；直接重试一次，可能多加一次。计数器表还有独立的数据类型限制，也不能为计数器设置 TTL。

如果业务要求“一个事件只能计数一次”，更稳妥的思路往往是先用唯一事件编号保存幂等事实，再异步聚合，或者让流处理系统维护可重放的聚合结果。计数器适合允许小心处理重试语义的场景，不应该被当成所有精确账目的捷径。

把知识落回自动化系统

场景一：设备遥测与时间范围读取

这是列族存储最自然的用法之一。事件持续写入，访问模式通常围绕设备、测点和时间范围展开。分区键把设备与时间桶组合起来，聚簇列按采集时间排序，TTL 负责原始数据生命周期。

要注意的是，极少数高频设备可能远比其他设备热。你可以再加入采样通道或哈希分片，但读取时也要并行读取多个分片并归并结果。分片解决的是写入分散问题，代价是读路径更复杂。

场景二：告警时间线与审计事件

告警和审计日志通常只追加、不频繁原地修改，还需要按对象和时间回看。我们可以为“按设备”“按产线”“按操作人”分别设计查询表。每一张表都保存读页面所需的字段，避免在线联结。

这种冗余设计要配合不可变事件编号。写入超时后，应用可以用同一个编号重试；下游重建视图时，也能识别重复事件。你会发现，优秀的列族方案不仅是表结构设计，还包括事件语义和失败恢复设计。

场景三：设备当前状态

“当前状态”与“历史遥测”虽然来自同一设备，却是两种访问模式。历史表不断追加，当前状态表则以设备为粒度覆盖更新：

sql

CREATE TABLE IF NOT EXISTS automation.device_state_by_tenant (
  tenant_id text,
  device_id text,
  updated_at timestamp,
  running_state text,
  latest_temperature double,
  latest_alarm_level text,
  PRIMARY KEY ((tenant_id), device_id)
);

这个示例方便按租户列出设备，但如果一个租户拥有数百万设备，单一租户分区仍可能过大。可以加入稳定分片号，例如由设备编号计算 shard_id，让读取页面同时查询有限数量的分片。没有一种主键能脱离规模假设永远正确。

列族存储适合与不适合的业务边界

哪些时候不该选列族存储

需求主要是任意联结和临时分析

如果运营人员经常临时提出“按地区、产品、客户等级、渠道任意组合，再联结订单和退款”的问题，关系型分析系统或数据仓库更自然。列族表可以为已知报表准备专用视图，却不擅长在请求到来后临时发明新的联结路径。

业务核心是跨多行强事务

银行总账、复杂库存预占和需要多对象同步提交的流程，通常更依赖成熟的跨行事务语义。你当然可以在应用层引入工作流、补偿和事件日志，但那已经是额外系统复杂度。若规模并没有逼迫你承担这份复杂度，关系型数据库往往更稳妥。

数据量小、访问简单、团队缺少运维经验

几万条配置数据并不会因为放进分布式宽列集群就变得更有价值。节点拓扑、修复、备份恢复、压实、容量扩容和版本升级都需要经验。技术选型要看总成本，而不是只看峰值吞吐数字。

访问模式仍在剧烈变化

列族表结构围绕查询而建，查询方向变化可能意味着新建表、回填数据和双写迁移。产品原型期如果连主要列表和筛选方式都还没有稳定，先用查询更灵活的存储验证业务，常常会更轻松。

判断问题	更偏向列族存储	更偏向其他方案
主要负载	大规模持续写入、按键或时间范围读取	任意联结、复杂临时聚合
访问模式	少数稳定查询，可提前设计	方向经常变化，难以预知
数据分布	能找到高基数且均匀的分区键	天然集中在少数热点对象
事务范围	单行或单分区为主	跨多行、多表强事务为核心
团队能力	能运维副本、修复、压实和容量	希望降低分布式存储运维负担

一次完整的建模演练

题目：工厂有 20 万台设备，每台每 5 秒上报一次。页面要查询某台设备最近 24 小时的数据，也要按产线查看最近告警；原始遥测保存 30 天，告警保存一年。我们该怎样开始？

先把两个在线查询拆开。设备遥测查询的入口是租户、设备和日期，排序条件是采集时间；产线告警查询的入口是租户、产线和日期，排序条件是告警时间。它们不应该被迫共享一张万能表。

为遥测表选择“租户 + 设备 + 日期桶”作为分区键，把采集时间和唯一事件编号作为聚簇列。一次 24 小时查询最多读取相邻两个日期桶，再由应用归并结果。

为告警表选择“租户 + 产线 + 日期桶”作为分区键，并保留设备编号、级别、代码和页面需要展示的消息。相同告警通过稳定事件编号写入多个查询视图，重试时保持幂等。

分别设置生命周期。遥测写入使用 30 天 TTL，告警采用更长保存策略；同时让压实、墓碑安全窗口、修复周期和磁盘容量相互匹配。

这套过程的重点不是记住某个固定主键，而是形成一种设计习惯：访问模式、分区边界、排序方式、生命周期和失败语义要一起落到纸面上。

常见误区速查

误区一是“列族存储没有模式，所以不用设计”。实际情况正相反：物理列可以稀疏，访问模式却必须设计得更明确；分区键一旦不合适，扩容只会把错误放大。

误区二是“CQL 像 SQL，所以查询能力也一样”。CQL 的语法降低了学习门槛，但高效查询仍然围绕分区键、聚簇顺序和适当索引展开。联结、任意子查询和无边界过滤并不是它的主要路径。

误区三是“TTL 到期就立即释放磁盘”。到期数据先变为逻辑不可见，物理回收还要等待墓碑安全条件与压实过程。大量同时到期的数据会形成值得监控的后台工作量。

误区四是“副本多就一定不会丢，也一定读到最新”。副本因子、请求一致性级别、拓扑、修复和客户端重试缺一不可。你需要说清楚一次操作等待几个副本，以及超时后业务怎样判断结果。

练习：把主键思路说清楚

要查询某设备某天最近 100 条遥测，哪种 Cassandra 主键更贴合访问模式？

下面哪些现象值得怀疑存在分区或生命周期设计问题？

只要一次批处理写了多张表，它就等价于关系型数据库里的跨表事务。

当副本因子 RF 为 3，读确认数 R 为 2，写确认数 W 为 2 时，R + W ____ RF。

再做一道开放题：如果“某条产线每天产生的告警远多于其他产线”，你会怎样调整分区键，同时让页面仍能按时间查看该产线告警？

小结

列族存储解决的不是“字段太多”这么简单的问题，而是大规模分布式数据如何围绕已知访问路径组织。你需要先把查询说清楚，再用分区键决定数据位置，用聚簇列或行键顺序安排范围读取，用列族组织共同存储与管理的数据。

真正让系统稳定的，是一组彼此配合的选择：分区既要均匀又不能无限长；写入路径用追加和后台压实换取吞吐；副本和一致性级别在延迟、可用性与新鲜度之间取舍；TTL 简化生命周期，却带来墓碑与回收工作；反规范化减少在线联结，却要求我们认真处理多视图写入和幂等。

当你的自动化系统面对海量遥测、告警时间线、审计事件和稳定的范围查询时，列族存储往往很有力量。可如果核心诉求是任意联结、临时分析或跨多行强事务，我们也应该坦然选择更合适的数据库。好的架构不是把所有问题塞进同一种工具，而是知道每种工具最擅长承担哪一段责任。