Docker7530
7.0 KiB
日期, 来源
| 日期 | 来源 |
|---|---|
| 2024-05-14 11:10 | 测试 |
问题详情
NRWLXT-28236 集团和省运营经理的域名个数全不正确
处理过程
- 确认集团运营经理首页数据来源？
- 确认集团运营经理域名列表域名总条数？
- 确认集团运营经理和省运营经理的后台接口是否一致？
/dashboard/index
domainSum（域名总数）
normalNum（正常运行）
disabledNum（已禁用）
deployingNum（部署中）
deployfailureNum（部署失败）
域名总数 = 正常运行 + 已禁用 + 部署中 + 部署失败
域名所有状态
-1: 初始化
0: 待排期
1: 待分发
2: 部署中
3: 已生效
4: 部署失败
5: 已停用
6: 部署中
7: 删除中
8: 停用中
9: 启用中
10: 待分发
11: 删除中
12: 删除中
13: 部署中
14: 部署中
15: 部署中
16: 删除中
17: 删除中
18: 部署中
19: 待配置
20: 部署中
21: 部署中
22: 删除中
23: 停用中
24: 启用中
25: 已保存
26: 待确认
27: 删除中
28: 部署中
29: 部署中
30: 部署中
31: 部署中
32: 部署中
33: 删除中
初始化 有 1 个，对应的是 -1。
待排期 有 1 个，对应的是 0。
待分发 有 2 个，对应的是 1 和 10。
部署中 有 13 个，对应的是 2, 6, 13, 14, 15, 18, 20, 21, 28, 29, 30, 31, 32。
已生效 有 1 个，对应的是 3。
部署失败 有 1 个，对应的是 4。
已停用 有 1 个，对应的是 5。
删除中 有 8 个，对应的是 7, 11, 12, 16, 17, 22, 27, 33。
停用中 有 2 个，对应的是 8 和 23。
启用中 有 2 个，对应的是 9 和 24。
待配置 有 1 个，对应的是 19。
已保存 有 1 个，对应的是 25。
待确认 有 1 个，对应的是 26。
首页主要逻辑
com.cmcc.cdn.platform.portal.controller.DashboardController#index
获取域名的核心 SQL：
SELECT state, COUNT(*) as count
FROM self_service_domain_config
WHERE tenant_id IN (:tenantIds)
GROUP BY state;
对于 tenantIds ：
集团运营经理 获取所有企业 id。
省运营经理 只获取名下企业 id（enterprise_manager_table 有关联关系）
通过上方 sql 获取域名的状态分组集合后根据状态对域名进行分类。
normalNum（正常运行）：已生效 （库中的 4）
disabledNum（已禁用）： 已停用 （库中的 6）
deployfailureNum（部署失败）：部署失败（库中的 5）
deployingNum（部署中）：去除上边 3 种状态都是部署中
对测试账号验证符合梳理逻辑
SELECT state, COUNT(*) as count
FROM self_service_domain_config
WHERE tenant_id IN (select enterprise_id from enterprise_info)
GROUP BY state;
SELECT SUM(count) as total_count
FROM (
SELECT state, COUNT(*) as count
FROM self_service_domain_config
WHERE tenant_id IN (select enterprise_id from enterprise_info)
GROUP BY state
) as subquery;
控制台主要逻辑
集团运营经理查全部
控制台点播：31840
控制台直播：299
控制台总数：32139
未统计 product 为 4 的 106 个
数据库总量：32245
集团运营经理首页全部：32243
差两个是因为这个两个域名的企业信息没有了。
省运营经理
获取所属省份下的 cache+ 和 esop 企业的域名。
总结
代码修改：
public List<Tuple> groupByState(List<String> tenantIds) {
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Tuple> cq = cb.createTupleQuery();
Root<SelfServiceDomainConfigPO> root = cq.from(SelfServiceDomainConfigPO.class);
// 因数据库中product为4的业务已下线，为保持首页查询逻辑和域名列表一致，进行过滤，product参考ProductsEnums。
Predicate productNotEqual4 = cb.notEqual(root.get("product"), cb.literal(4));
cq.multiselect(root.get("state"), cb.count(root))
.where(cb.and(root.get("tenantId").in(tenantIds), productNotEqual4))
.groupBy(root.get("state"));
return em.createQuery(cq).getResultList();
}
生产
2,2待分发
3,123部署中
4,9327已生效
5,30部署失败
6,263已停用
7,2部署中
8,43删除中
9,2停用中
13,30删除中
17,1删除中
20,2待配置
21,48部署中
- 关于首页 集团运营经理依据所有的企业 id 获取对应的域名。通过状态分类，正常运行（库中的 4 已生效）、已禁用（库中的 6 已停用）、部署失败（库中的 5 部署失败）、部署中（除上边 3 种状态均归类为部署中） 省运营经理只获取名下企业 id 对应的域名（enterprise_manager_table 为依据）。分类如上。
- 关于控制台 集团运营经理取全部，省运营经理获取所属省份下的 cache+ 和 esop 企业的域名。同时均未获取库中产品为 4（直播流媒体加速）的域名。
以 jira 单中测试环境账号为例
测试库中：15466 个域名
首页
域名总数：15465 （正常运行 + 已禁用 + 部署中 + 部署失败）（与库差一个域名是因为 www.myl0705.com 这个域名没了企业信息属于脏数据）
正常运行：7160
已禁用：353
部署中：7540
部署失败：412
控制台
点播：14890
直播：544
总数：15434（与域名库差 32 是因为未统计 produt 为 4 直播流媒体 32 个加速域名）
已生效 域名列表总数：7141 首页总数：7160 差 19 个是因为存在 19 个 product 是 4 的。
部署失败 域名列表总数：411 首页总数：412 差 1 个是因为存在 1 个 product 是 4 的。
已停用 域名列表：349 首页总数：353 差 4 个是因为存在 4 个 product 是 4 的。
部署中 域名列表：6252 首页总数：7540 差 1288 是因为首页的部署中为库中剩余的所有状态的域名：初始化、待排期、待分发、部署中、删除中、停用中、启用中、待配置、已保存、待确认
已生效、部署失败、已停用对不上均是由于 product 是 4 的域名造成的。
部署中 是因为首页的部署中为库中剩余的所有状态的域名：初始化、待排期、待分发、部署中、删除中、停用中、启用中、待配置、已保存、待确认。域名列表的只是部署中。
这边对首页进行处理 1.过滤掉 product 是 4 的域名；2.部署中过滤为只是部署中状态的域名个数。可以吗？
可以的。
自测
库中一共：32245
域名列表：32139 + product 为 4：106 符合 32245
直播：299
点播：31840
首页
首页：
总数：4274
正常：2680
禁用：70
部署失败：159
列表：
总数：4274
正常：2646+34
禁用：55+15
部署失败：159
域名总数 31779
正常运行 13564
已禁用 274
部署失败 1793
列表：
总数：31570+227=31797-18
正常：13414+159=13573-9
禁用：254+20=274
部署失败：1791+3=1794-1
域名总数 20107
正常运行 5424
已禁用 20
部署失败 1445
列表：
总数：20089+18=
正常：5409+15=
禁用：19+1=
部署失败：1445