当实例数量增长到数十甚至上百个、Key 总量达到千万级时，缺乏统一命名体系会导致问题排查效率降低、权限管理出错和资源归属不清。本文档从实例命名和 Key 命名两个维度定义标准化的命名规则，使团队成员可以通过名称直接识别资源所属的环境、业务和地域。
一、实例命名规则
规范的实例名称能够在控制台列表、监控面板和告警通知中直接传达实例的归属信息，帮助运维人员快速定位目标实例，降低误操作风险。建议按照环境、组织、业务、位置四个维度，以连字符
- 拼接的方式命名实例：{环境}-{分公司}-{项目组编号}-{业务名称}-{地域}-{专区}-{序号}
其中各字段的含义如下：
字段 | 说明 | 示例 |
环境 | 区分生产与开发，避免误操作影响线上服务 | prd（生产）、dev（开发） |
分公司 | 所属分公司名称缩写，便于费用归属和权限划分 | cx（财险）、rx（人险） |
项目组编号 | 项目组唯一标识，方便按团队粒度统计资源用量 | p001、p002 |
业务名称 | 该实例所服务的具体业务，使用有语义的英文缩写 | ordercache（订单缓存）、policysync（保单同步） |
地域 | 实例部署地域缩写，与腾讯云地域编码保持一致 | gz（广州）、sh（上海） |
专区 | 实例所属专区缩写 | gzcx01、shcx01 |
序号 | 同一业务下的实例序号，用于区分多实例部署 | 1、2 |
正确示例：
示例 | 说明 |
prd-cx-p001-ordercache-gz-gzcx01-1 | 生产环境，财险 P001 项目组的订单缓存实例，部署在广州财险01专区 |
dev-cx-p001-ordercache-gz-gzcx01-1 | 与上一条对应的开发环境实例 |
prd-cx-p002-policysync-sh-shcx01-1 | 生产环境，财险 P002 项目组的保单同步实例，部署在上海财险01专区 |
反面示例：
示例 | 问题 |
keewidb-01 | 缺少环境、业务等关键信息，无法判断归属 |
生产-财险-订单 | 使用中文命名，控制台和脚本中容易引发编码问题 |
prd_cx_p001 | 使用下划线分隔，与规范的连字符风格不一致 |
二、Key 命名规则
建议 Key 命名采用业务名为前缀、冒号分层的结构。这种方式可以防止不同业务之间的 Key 冲突，同时使 Key 具备自描述能力——通过名称即可判断其所属的业务系统和数据来源。建议按以下格式命名：
业务名:数据库名称:数据库表名称:数据ID
其中各字段的含义如下：
字段 | 说明 | 示例 |
业务名 | 业务系统缩写，作为全局唯一的命名空间前缀 | cx（财险）、rx（人险） |
数据库名称 | 数据来源的数据库名，便于溯源 | orderdb（订单库）、userdb（用户库） |
数据库表名称 | 数据对应的表名，定位到具体的数据实体 | order（订单表）、user（用户表） |
数据 ID | 数据表中的主键或唯一标识，精确定位到单条记录 | 202401150001、100238 |
正确示例：
示例 | 说明 |
cx:orderdb:order:202401150001 | 财险订单库中的订单记录，订单号为202401150001 |
cx:userdb:user:100238 | 财险用户库中的用户记录，用户 ID 为100238 |
rx:policydb:policy:PL20240001 | 人险保单库中的保单记录，保单号为 PL20240001 |
反面示例：
示例 | 问题 |
000110011 | 无前缀、无分层，无法判断业务归属和数据来源 |
cx_cxdb_user_000110011 | 使用下划线分隔层级，与冒号分层规范不一致 |
cx:cxdb:cxdb_user_info:000110011 | 表名中重复包含库名 "cxdb"，冗余且增加 Key 长度 |
