目录
Namespace
Item
Namespace与Item
Namespace修改
界面操作
存储逻辑
更新Item
创建Item
删除Item
Namespace发布
界面操作
存储逻辑
发布版本
发布顺序
题外
Namespace
Namespace是配置项的集合，类似于一个配置文件的概念。官网解释的更为全面，具体参看
Apollo核心概念之“Namespace” (apolloconfig.com)
Namespace对应的ApolloConfigDB 的Namespace表结构如下
其中NamespaceName字段取值规律如下
- Namespace的类型为properties时，取值为“名字”
- Namespace的类型为非properties时，取值为“名字.类型”，例如flowCtrl.yml
索引信息如下
Namespace表唯一索引是包含AppId、ClusterName、NamespaceName字段，表明Namespace字段是
- 应用隔离：不同应用的同名Namespace对应俩条不同的记录，是俩个不同的Namespace，配置项和值都可以不一致
- 集群隔离：同应用的不同集群的同名Namespace对应俩条不同的记录，是俩个不同的Namespace，配置项和值都可以不一致。但由于同属同一个AppNamespace，命名空间的类型（Format）是一致的
Item
配置文件可以存储多个配置，每个配置称为配置项。Namespace对应配置文件的概念，那么配置项就对应Item，包括key,value字段，以键值对的形式存储配置，记录配置最新的值。对应ApolloConfigDB.Item表
每条Item记录通过NamespaceId与Namespace关联，一个Item只属于一个Namespace,一个Namespace可以拥有多个Item。
其中key的取值规律为
- 关联当Namespace的类型非properties时，key值默认为content，例如上图中Id为3的Item记录，对应的Namespace类型为xml
- 当Namespace的类型为properties时，key取值为配置项名称
LineNum字段表示，当前item在关联的Namespace中配置项的排序位置。下图Item adress、name、sex的lineNum值分别为1、2、3
Namespace与Item
一个Item只属于一个Namespace,一个Namespace可以拥有多个Item，通过在ApolloConfigDB.Item表中的NamespaceId建立item与Namespace关联关系。查询应用下所有Item的sql如下
SELECT
t.AppId,
t.ClusterName,
t.NamespaceName,
t1.NamespaceId,
t1.Id AS itemId,
t1.LineNum,
t1.`Key`,
t1.`Value`
FROM
ApolloConfigDB.Namespace t,
ApolloConfigDB.Item t1
WHERE
t.Id = t1.NamespaceId
AND t.IsDeleted = 0
AND t1.IsDeleted = 0
ORDER BY
t.AppId,
t1.NamespaceId,
t1.LineNum执行结果如下
Namespace修改
界面操作
对Namespace修改其实是对Namespace关联的某个Item修改。修改过程中系统会记录修改的历史记录。portalUI中命名空间的【更改历史】可以查看。
包括更改类型、被修改的Item的key、旧值、新值、说明。
存储逻辑
修改历史是如何存储的呢？存储在ApolloConfigDB.Commit表中
记录是以命名空间为单位，通过AppId、ClusterName、NamespaceName来定位到唯一的命名空间，ChangeSets字段以json对象记录本次修改中变动的Item数据，包括三部分
- "createItems":[]，记录新增Item数组
- "updateItems":[]，记录更新的Item数组
- "deleteItems":[]，记录删除的Item数组
更新Item
更新Item sex的值为female2，并且增加说明“this is comment”
commit表新增记录的ChangeSets值如下，包含了Item sex修改前和修改后的对应ApolloConfigDB.Item表里的记录
{
"createItems":[],
"updateItems":[
{
"oldItem":{"namespaceId":1,"key":"sex","value":"female","lineNum":3,"id":18,"isDeleted":false,"deletedAt":0,"dataChangeCreatedBy":"apollo","dataChangeCreatedTime":"2022-12-28 20:24:40","dataChangeLastModifiedBy":"apollo","dataChangeLastModifiedTime":"2022-12-28 20:24:40"},
"newItem":{"namespaceId":1,"key":"sex","value":"female2","comment":"this is comment","lineNum":3,"id":18,"isDeleted":false,"deletedAt":1672483560987,"dataChangeCreatedBy":"apollo","dataChangeCreatedTime":"2022-12-28 20:24:40","dataChangeLastModifiedBy":"apollo","dataChangeLastModifiedTime":"2022-12-31 18:46:01"}
}
],
"deleteItems":[]
}创建Item
新增Item nickname,commit表新增记录的ChangeSets值如下，包含了新增的item对应ApolloConfigDB.Item表里的记录
{
"createItems":[
{
"namespaceId":7,"key":"nickname","value":"大王","lineNum":1,"id":23,"isDeleted":false,"deletedAt":0,"dataChangeCreatedBy":"apollo","dataChangeCreatedTime":"2022-12-31 15:16:43","dataChangeLastModifiedBy":"apollo","dataChangeLastModifiedTime":"2022-12-31 15:16:43"
}
],
"updateItems":[],
"deleteItems":[]
}删除Item
删除Item address,commit表新增记录的ChangeSets值如下，包含了删除的item对应ApolloConfigDB.Item表里的记录
{
"createItems":[],
"updateItems":[],
"deleteItems":[
{
"namespaceId":1,"key":"address","value":"HaiXiaDaDao88Hao，nanjingbank,pukou","comment":"","lineNum":1,"id":1,"isDeleted":true,"deletedAt":1672485861879,"dataChangeCreatedBy":"apollo","dataChangeCreatedTime":"2022-05-15 13:28:20","dataChangeLastModifiedBy":"apollo","dataChangeLastModifiedTime":"2022-12-31 19:24:21"
}
]
}Namespace发布
界面操作
Namespace的发布是以命名空间为单位，发布特定命名空间后，该命名空间包含的所有Item都会被发布。发布历史可以在portalUI中命名空间的右上角【发布历史】菜单查看
页面左侧记录了该命名空间发布记录，页面右侧记录了该命名空间每次发布后的所有Item最新值与本次发布前后存在变动的item的新旧值对比。
存储逻辑
发布版本
发布版本是如何存储的呢？存储在ApolloConfigDB.Release中 
发布版本记录以命名空间为单位，仍然是通过AppId、ClusterName、NamespaceName三个字段确定唯一的命名空间。Configurations字段是以json对象的形式记录本次发布后该命名空间所有Item的值。其他字段均为Apollo常用的表字段。
发布顺序
一个命名空间发布多次后，多个发布版本又是如何记录发布顺序的呢？
发布顺序通过ApolloConfigDB.ReleaseHistory表记录版本依赖来实现
其中版本依赖的记录以命名空间为单位，仍然是通过AppId、ClusterName、NamespaceName三个字段确定唯一的命名空间。其中ReleaseId记录当前的发布版本id，对应ApolloConfigDB.Release的id字段，PreviousReleaseId字段记录该发布版本依赖的前前一个发布版本id,也对应ApolloConfigDB.Release的id字段。通过这俩个字段实现将发布版本串联起来，展示完整的发布顺序。
如上图应用4am的application命名空间的发布顺序是0->1->2->3->9->25->28->36，其中0表示最初始的版本历史，无实际意义。对应ApolloConfigDB.Release表记录
题外
其实简单实现方式可以直接通过ApolloConfigDB.Release的t.DataChange_CreatedTime排序即可查看到特定命名空间的发布历史，SQL如下
SELECT
*
FROM
ApolloConfigDB. RELEASE t
ORDER BY
t.AppId,
t.ClusterName,
t.NamespaceName,
t.DataChange_CreatedTime;
