作为 Maximo 专业人士，我们常有一个简单的假设：ID 最大的记录一定是最新创建的。在传统的单服务器环境中，这一假设在大多数情况下似乎成立。  
‍

然而，在 IBM Maximo Application Suite (MAS) Manage 中，特别是在运行多个 Pod 时，这种逻辑可能会导致错误的结论。
‍

对于架构师、开发人员、报表编写人员和集成团队而言，了解 Maximo 如何在多个 Pod 之间管理数据库序列、缓存值并分配 ID 至关重要。

了解 Maximo 序列管理

Maximo 依赖数据库序列来为以下记录生成唯一标识符：

• 工单

• 服务请求

• 库存事务

• 采购事务

• 自定义业务对象
  ‍

具体实现方式会因数据库平台的不同而略有差异。

Oracle 和 Db2

Oracle 和 Db2 使用原生数据库序列对象。数据库本身负责管理序列，并确保所有应用程序实例中的唯一性。
‍

当 Maximo 需要新的标识符时，它会直接从数据库序列中请求下一个值。

SQL Server

从历史上看，运行在 SQL Server 上的 Maximo 使用的是 MAXSEQUENCE 表，而非原生 SQL Server 序列对象。
‍

在较新的 MAS Manage 版本中，如果配置得当，SQL Server 可以通过 NEXT VALUE FOR 机制利用原生 SQL Server 序列。
‍

无论使用何种数据库平台，核心目标始终如一：

高效且安全地 生成 唯一值，以应对高并发环境。

多个 MAS Manage Pod 是否共享同一个序列？

简短的回答是 是的.
‍

在 MAS Manage 中，所有 Pod 都连接到同一个共享数据库。因此，它们也共享相同的底层序列对象。
‍

序列并非独立存在于各个 Pod 中，而是：

• 序列驻留在数据库中。

• 每个 Pod 都从同一个序列请求数值。

• 数据库确保了数值的唯一性。

• 多个 Pod 可以同时生成记录而不会发生冲突。
  ‍

这意味着 UI Pod、集成 Pod、Cron Pod 和报表 Pod 均从同一个底层序列源获取数值。

什么是缓存？（看我刚才的操作了吗？）

为了提高性能，Maximo 通常不会在每次创建记录时都向数据库请求新的序列值。
‍

相反，它会预留数值块并将其存储在内存中。
‍

例如：

• UI Pod 1 预留序列 1 – 5

• UI Pod 2 预留序列 6 – 10
  ‍

这两个范围之所以唯一，是因为它们是从同一个数据库序列中分配出来的。
‍

每个 Pod 现在都有自己的本地缓存，无需频繁往返数据库即可创建记录。
‍

这显著提升了系统的可扩展性和性能。然而，许多报告和集成问题也由此产生……

为什么序列号并非按时间顺序排列

设想以下场景：

第一步： UI Pod 1 预留了值：1, 2, 3, 4, 5

第二步： UI Pod 2 预留了值：6, 7, 8, 9, 10

第三步： 在 UI Pod 2 中拥有会话的用户创建了一个工单

第四步： 片刻之后，在 UI Pod 1 中拥有会话的用户创建了另一个工单

结果如下：

如果按 ID 排序，工单 UI2 看起来更新，但实际上它是在 之前 创建的工单 UI1。
‍

序列值 保持唯一性，但它们不再代表 真实的创建顺序。

为何这很重要

许多用户在不知不觉中将记录 ID 作为一种捷径，用来回答诸如以下问题：

• 最新的工单是什么？

• 最近创建的服务请求是哪一个？

• 最新的库存交易是什么？

• 最后添加的资产是哪一个？
  ‍

在多节点 MAS 环境中，无法仅凭最高序列值可靠地回答这些问题。这样做可能会导致报告、仪表板、集成、数据迁移和商业智能输出结果不准确。
‍

我相信不止我一个人过去曾使用过类似下方的查询语句来获取最新值：

select * from <table>  
where <column> = ‘<value>’ and   
<table unique id> = (select max(<table unique id>) from <table> where <column> = ‘<value>’) 

为何 ROWSTAMP 并非解决方案

包括我在内的一些人曾尝试使用 ROWSTAMP 作为替代方案。
‍

这引发了另一个问题，因为该字段也会在记录发生以下情况时随之改变： 已更新.
‍

例如：  

如果按更新日期 (ROWSTAMP) 排序， WO10001 看起来比 WO10002 更新，尽管后者是后来创建的。
‍

这使得基于更新的字段在识别原始创建顺序时不可靠。

应该使用什么来代替？

正确的方法是使用 不可变 的创建时间戳。  
‍

示例包括：

• 创建日期

• 创建日期时间

• 系统创建的审计字段

• 其他仅插入时间戳列
  ‍

一个实用的经验法则是：

使用 ID 来标识身份： 序列生成的标识符可唯一标识一条记录。

使用时间戳来记录时间顺序： 创建时间戳显示了记录实际插入的时间。

两者结合以实现稳定排序： 当多条记录具有相同的时间戳精度时，结合时间戳和 ID 可以实现确定性排序。

总结

随着 MAS Manage 部署越来越多地利用 Kubernetes 和多个 Pod 来实现可扩展性，在传统单服务器 Maximo 环境中行之有效的假设变得不再那么可靠。
‍

序列号的设计初衷是为了解决一个问题： 唯一性。
‍

它们从未被设计用于证明 创建顺序。
‍

如果您的业务需求是确定最近发生的情况，请务必依赖真实的创建时间戳，而不是序列生成的标识符。这样做可以确保您的报告、集成和运营决策基于事实，而非缓存序列值偶然产生的排序。

‍