序列跳号(跳跃)原因及解决「建议收藏」

序列跳号(跳跃)原因及解决「建议收藏」前叙: 今天上班的时候,测试老师发邮件反馈了一个投诉系统的缺陷,说是不同的投诉件在不同的处理阶段,会出现无法继续处理的现象。 我一看系统版本,原来是PgSQL版本出现的问题(因为最近和一个同事在做数据

序列跳号(跳跃)原因及解决

前叙:

  今天上班的时候,测试老师发邮件反馈了一个投诉系统的缺陷,说是不同的投诉件在不同的处理阶段,会出现无法继续处理的现象。

  我一看系统版本,原来是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或不设置)

题外话:

  虽然序列跳号的现象,会让主键值不连续、甚至错乱,但是依旧能够保证唯一性,并且能够提高性能。所以我们可以
将设置了高速缓存的序列用在不需要保证递增或连续的字段上~

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
转载请注明出处: https://daima100.com/7495.html

(0)
上一篇 2023-03-19
下一篇 2023-03-19

相关推荐

发表回复

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