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