关于分布式事务的一点感悟

[renyh]

来源：https://jihulab.com/apiforum/public/-/issues/10

馆际互借 API 设计的过程中，涉及到分布式事务概念。查了一些资料，了解到有 2PC 和 3PC 等不同的做法。

联想到以前开发系统中的一些体会。比如 dp2 系统内务前端，有一个从 Excel 文件导入到读者库的功能，界面是先从 Excel 文件读取读者记录，变换为适合导入 dp2 系统的格式，显示在一个列表界面。这时候新记录并没有真正保存到系统的读者库，这时只是提供给操作者查看，即将提交保存的记录内容。等操作者执行保存命令的时候，这些记录才真正保存到系统的读者库。

在最后保存的过程中，有一定概率，因为拟保存的记录通不过系统查重或者格式检查，发生报错。那么操作者从界面看到报错以后，要根据具体情况，决定放弃导入这部分记录，或者先修改这部分记录内容以后再尝试重新导入。

这种过程中，最后一步的报错会给操作者带来烦恼和压力。本着左移的思路，可以利用 dp2 系统读者记录保存时候的一种“模拟保存”的功能，让内务前端软件先自动尝试模拟保存这些读者记录，如果报错了，就直接把报错信息显示在列表界面上，表示“有这么一些记录即将保存，但估计其中一部分真正保存的时候会遇到报错，报错如下”。我觉得这种把检查和模拟左移的做法是很好的，可以减少操作者的压力感。因为一旦真正保存以后，清理已经保存的记录是令人烦恼的，这是一种压力的来源，通过模拟保存提前看到这种结局并做出应对，减轻了这种压力。

(另外一个典型例子是导入 .bdf 文件的功能。也是使用了模拟保存书目记录的功能)

根据这些以前的经验，我产生了一种设想，就是各个图书馆的 ILS 服务器需要支持“模拟借书”“模拟还书”等等操作。也就是按照真正的操作那样去走完几乎全过程，但在最后写入数据库的一刻并不真正写入。这样的目的是暴露“一旦真的这样操作可能会遇到的报错”。

所谓分布式事务协调，无非就是让参与的服务器一起完成一个大的操作，先问问各方“我打算这么做，你觉得行不行？”是很有好处的。如果不行，那就早点放弃整个操作，避免有些行了的服务器实际上写入了数据库，然后又重新被要求 Undo 刚才的操作。先问问各方，减少了一些损耗和麻烦。

当然，这种做法，前提是要求各方服务器首先具备“模拟操作”功能，这是很多系统原先不具备的功能，涉及到新的开发工作量。也许可以把这种模拟操作能力做成一种可选的功能。在分布式事务协调阶段，如果知道一些服务器节点并不具备这种模拟功能，也就不 3PC 了，直接 2PC，功能降级运行。

[renyh]

张 丹东

分布式系统的设计是非常考验知识经验+认知能力的事情，每一个单元的独立性，全局流程的顺畅，需要兼顾。

高校信息化在内部一直不顺畅，原因就是缺乏这种设计和协调能力。

现在要考虑跨校的系统之间的协调一致，确实应该从零做起，逐渐考虑提高才比较可行。