iTop唯一性检查功能测试

唯一性检查在 CMDB 里比较重要,大部分 CI 都不希望重复。iTop 2.6 之前并没有支持唯一性检查功能,需要使用 DoCheckToWrite 函数在写入前自行检查。

老方法回顾

用DoCheckToWrite函数实现写入前的校验,比如下面的代码校验某些属性,保证其唯一性。还可以在写入前进行简单的校验,例如限制登录用户只能编辑自己link的Person。

内置唯一性检查

2.6 新增了 uniqueness_rules ,用户可以写 XML 来定义约束规则。比起 PHP 代码,方便了不少。比如标准模型中 Person 类的唯一性检查规则:

可以看到 uniqueness_rules 在 properties 下定义。这个规则限制每个组织下不能有相同员工号的 Personid 为 name 的规则,is_blocking 为 false,表明这个规则不是强制的,只会给出警告,依然能更新成功。毕竟,同名的人挺常见的。

其中 filter 的含义是,过滤某些不关心的情况,比如这个例子中,employee_number 为空的情况并不关心,允许为空并且不认为是重复项,因此用 filter 字段把这种情况过滤掉。

唯一性检查靠谱吗

测试 MGR 的时候,有几个功能会受到影响,出现重复项。因此想测试一下唯一性检查这个重要功能是否靠谱。测试方法也时通过 parallel 并发请求 iTop 接口,调用 API 的脚本如下:

保存为 unique.sh,使用 parallel 并发调用:

最终结果表明,在 MGR 单主,多主以及 单节点上都出现了问题。

image
创建了5个有相同工号的联系人

代码分析

代码注释里已经写明了可能的问题。。

加锁性能代价太大。。

dbobject.class.php 中:

注意到 DoCheckToWrite 的注释,This method is not meant to be called directly, use DBObject::CheckToWrite()!,看来我之前的做法也不完全正确。

结论

唯一性检查未使用 iTopMutex,即和 GET_LOCK 无关,和MGR也无关。在实践中,如果出现并发创建,是有一定几率出现重复项目的。不过也无需太过担心,实践中,两人同时创建相同对象的情况应该是很少的。如果出现了,也可以用 DB工具 来发现并修复问题。

image
System 下的 DB 工具

(全文完)

请勿全文转载,部分引用请注明出处。
本文链接地址: https://www.annhe.net/article-4622.html
博客能带货吗

发表评论

电子邮件地址不会被公开。 必填项已用*标注