前叙:
今天上班的时候,测试老师发邮件反馈了一个投诉系统的缺陷,说是不同的投诉件在不同的处理阶段,会出现无法继续处理的现象。
我一看系统版本,原来是PgSQL版本出现的问题(因为最近和一个同事在做数据库迁移的工作,从Orale迁移到PgSQL~)。
因为需要迁移的东西非常多,所以难免会暴露出来一些问题和缺陷。好了,闲话不多说,我们来看看问题吧。
问题:
投诉系统现阶段有5种不同类型的投诉件,每种投诉件的业务流程也都各不相同。我们通过投诉系统来处理不同类型投诉件,并且每个业务处理步骤我们都可以在页面上查看,其目的是方便追责和查看处理方式等。
一般来说,页面显示的处理步骤都是倒序的,即马上要进行的处理步骤是显示在页面最顶部的,上一步处理的信息显示在这条记录的下面,以此类推,最底部显示的就是该投诉件第一次进行业务处理的信息。
但是因为数据库迁移,页面上显示的处理步骤的信息的顺序乱掉了,并且在乱掉后,案件就无法继续处理了。
分析:
经过排查,发现两个关键:
1.投诉系统是从数据库中,根据序列生成的Task_ID倒序获取投诉件的业务状态,然后将其和当前操作的业务状态进行比较,如果不同,该投诉件就无法处理;
2.数据库中,同一投诉件的Task_ID倒序查询结果,和页面显示的一样,是乱掉的,这导致倒序获取的业务状态,很可能不是最新的业务状态(即已经处理过的业务状态)。
举个栗子:
投诉件一开始先提交,提交的时候在数据库同步生成业务状态为“待调查”(生成的Task_ID为2023)的记录;
然后投诉件继续处理,进行案件调查,这个时候数据库再次生成业务状态为“待查勘”(生成的Task_ID为2021)的记录;
当进行到第三步案件查勘的时候,系统根据倒序查询,从数据库中取出的案件状态为“待调查”,但是当前操作的业务为“待查勘”,两者不相符,所以该投诉件就被系统PASS了。
那么,为什么序列生成的Task_ID不是逐渐递增的呢?而是偶尔会出现穿插的现象呢?
原因:
这个现象,我们称之为
“序列跳跃”(也有叫做序列跳号的)。之所以会出现这个现象,其实就是因为创建序列的时候,
设置了序列的高速缓存的缘故。
序列的高速缓存原本是用于提高性能的,但是它也有自己的一些特性:
1.
序列的高速缓存默认值为20;
2.
序列的高速缓存值有锁一样的特性(假如将一个SQL称为会话,那么这个会话存在期间,2023——2043这20个序列值就是它独有的,其他会话无法使用);
3.
序列的高速缓存值用不完就会被废弃(假如当前会话只使用了3个序列值,会话结束时,剩下的17个序列值会被直接废弃掉);
解决:
既然知道了原因,那么解决办法就十分简单了,我们现阶段测试的数据库是PGSQL,那么直接
将相关序列高速缓存值设置为1即可(PGSQL高速缓存最低为1,不允许为0,Oracle可以设置为0或不设置)。
题外话:
虽然序列跳号的现象,会让主键值不连续、甚至错乱,但是依旧能够保证唯一性,并且能够提高性能。所以我们可以
将设置了高速缓存的序列用在不需要保证递增或连续的字段上~ 免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341