系统软件架构重塑（下） ——以“一致性与并发”即以正确性和性能为出发点重构并发

接续《系统软件架构重塑（上）》

四、并发类系统软件的核心问题和本质

鉴于前述讨论，从并发的角度看，具备并发处理能力的系统软件，是不是更需要从横向角度去考虑并发系统的核心问题是什么？

我个人认为，并发系统的共性方面，其核心问题，只有两个：一是正确性问题，二是系统性能问题[1]。其他问题，是依附于这两个核心问题的次级重要问题或更次之。请注意，我们这里讨论的是并发这一共性背景下的核心问题，而不是每个系统的独有基本问题（如操作系统对硬件资源管理属于其独有的基本问题，不再讨论范围之列）。

首先，来看这两个核心问题，分别对这两个问题进行常规认知描述，通常大家认为：

1. 正确性 (Correctness)：是指软件系统按照预期的方式准确无误地执行其功能的能力。这意味着系统应该能够处理所有合法输入并产生正确的输出结果，同时对于非法或异常情况也应有适当的响应机制。
2. 性能 (Performance)：是指软件系统在给定资源条件下完成任务的速度、响应时间和资源利用率等方面的表现。高性能通常意味着快速响应、低延迟、高吞吐量以及合理的资源消耗。

这两个基本概念，是通用的，具有广泛的含义。因此也有些放之四海皆准的味道，但同时有失针对性，需要我们把这两个核心问题放到具体的环境中。

其次：我们在具体的环境中，并发环境中，讨论并发类系统的正确性和性能问题。

在并发环境下，因为并发存在，需要共同读写相同的对象，因此会产生正确性问题。

这在操作系统中，典型的表现是死锁现象，其涉及了系统能不能正确的调度用户的程序被正确执行；同时对对死锁的处理制约了系统的性能。

而在数据库中，死锁现象也存在，但其存在的前提是采用了封锁相关的并发算法，如果换用其他算法，则死锁问题不会存在；但是，影响数据正确性的问题，更多的是数据异常现象，数据异常也是因并发而产生的。

在操作系统中，并发产生了程序的正确性；在数据库中，并发更多引发了数据的正确性。分布式文件系统等，也存在类似的现象和问题。

对这些现象的处理，则影响了系统的性能。操作系统需要引入耗时的死锁检测机制使得并发性能下降，数据库采用可串行化理论排队处理并发而降低了并发度，额外地还需要死锁检测机制解决并发死锁导致性能更多地下降。为了解决性能问题，数据库不得不引入隔离级别来牺牲数据的正确性而换取性能。

第三：我们来看这两个核心问题之间的关系。

数据库中，采用隔离级别解决正确性和性能问题，是舍此及彼的方式的，把这两个问题割裂。那么为什么这两个问题是“鱼和熊掌不可兼得”的呢？现实情况是：我们缺乏理论层面描述这样的问题，而只有经验的流传；但事实上，在不同的数据库中因各自隔离级别的实现方式不同，性能表现会有很大差异，使得采用弱隔离级别想达到性能显著提升的想法不很现实；换句话说，只要采用恰当的实现技术，一些隔离级别之间的性能差异，不是巨大不可逾越的。因此，采用弱隔离级别提升性能的想法有点虚幻了。

但是，数据库领域，却鲜有对这两个核心问题的反思和研究，对他们之间的关系的理论描述则更为匮乏。作为核心问题，缺乏理论支撑，这一现象不正常。

在操作系统领域，死锁是一个重要问题。但对其解释和描述[2]，也仅限于就事论事的问题层面，似乎发现操作系统世界存在有死锁现象，则采用相关算法解决它即可，并没有把死锁和性能问题并列（并列之意为：认为这是同一个本质下的两个子面），协同去加以考虑和解决。

第四：跨系统地讨论正确性和性能的关系。

现在，我们站在某一特定并发类系统之外，把多个有共性的并发系统放在一起，来思考正确性和性能问题。

操作系统的死锁和数据库领域的数据异常之间，是否存在有共性的本质联系？

如果有着本质的联系，那如何表达它们？

只有站立在特定系统之外，我们才有机会去思考并发共性、才能把横亘在不同系统中相似的现象摆在一起，一同加以研究。这样，也才有机会反观正确性和性能这样的问题是各自独立的问题，还是相关联而密不可分的问题。

在我们的研究认知中，我们认为并发系统下的正确性和性能是同一个问题的两个面，是密不可分的，必须协同考虑它们而不是分割看待。尤其是数据库系统中不能盲目认为隔离级别有效而牺牲正确性。

相关问题的描述和讨论，已经有较多文章输出，此处不再赘述（可参考《从根生长—第三代（分布式）数据库C2DB（上）》、《第三代分布式数据库（3）——一致性八仙图》、《第三代分布式数据库（7）——比较拉胯的PostgreSQL》等系列文章）。

第五：“一致性与并发”理论

“一致性”与“并发”等作为重要的研究课题，被Leslie Lamport、Jim Gray、Pat Helland、Eric Brewer等研究、推动和发展。但是，把“一致性与并发”统一到一个理论框架下，目前还没有相近的工作成果出现。

“一致性与并发”理论，核心内容讨论并发类系统的并发场景带来的正确性问题，以及在注重正确性问题的前提下（该前提把正确性提到机极致，提出100%确保正确性），同时如何最大化并发性能问题。“一致性与并发”理论的内容，将通过新书发出。该书即将面世。

第六：题外话——架构设计的方法论

在软件的架构设计中，出现过很多有价值的方法。例如：

1. 自下而上设计（Bottom-up Design）：这种方法从最基础的组件或元素出发，逐步构建和整合成更复杂的系统。它通常关注于解决具体的问题或实现特定的功能模块，然后将这些模块组合起来形成完整的系统。
2. 增量式开发（Incremental Development）：指在软件工程中，系统是通过一系列小的、逐步的改进来发展的。每个增量都增加了系统的功能或性能。
3. 演化式架构（Evolutionary Architecture）：一种允许系统结构随着时间推移而变化的方法，而不是一开始就确定所有细节。它支持持续交付和部署，能够灵活应对业务和技术的变化。
4. 敏捷开发（Agile Development）：该方法虽然不是严格意义上的“自下而上”，但敏捷开发提倡从小规模、快速循环的方式开始项目，注重客户合作和响应变化。
5. 渐进式增强（Progressive Enhancement）：最初用于描述Web开发的一种策略，即首先创建一个基本的功能版本，然后再添加更多高级特性以提升用户体验。

这些方法，都是因为软件的复杂性和不可控而诞生，但也展示了人们对软件技术缺乏把控能力。“自顶而下”的设计方法由此成为了一种奢望。这种奢望，折射出我们目前的极其有限的能力，但也能提醒我们需要革新方法，以把软件研发技术推进到下一个阶段——量化阶段。

五 、“正确性与性能”即一致性与并发，可重塑系统软件架构

近几年，Michael Stonebraker及其同事提出的数据库操作系统（Database in Operating System, DBOS）理念，旨在重新思考传统数据库与操作系统之间的界限，以更好地支持现代应用需求。

这是一次跨系统的对并发类系统进行的思考和探索。目前，DBOS的核心思想是将数据库管理系统的核心功能与操作系统的某些特性更紧密地结合在一起，从而提高性能、简化管理和增强安全性。它提倡打破传统数据库和操作系统之间的严格分界，通过整合两者的优势来优化数据处理任务。作者认为，当前OS的很多资源问题最终可以归结为Data问题，需要按照Data的思路来解决，因而提出了新的OS架构：基于DBMS的OS，这完全区别于传统的OS架构体系。他们声明：建议围绕两个原则构建面向数据库的操作系统：

1. 将所有应用程序和操作系统状态存储在分布式数据库的表中（如图1中的Level 2）。

2. 仅通过数据库事务访问状态。

这样的思想，表面看影响的是操作系统，但对数据库的架构也将产生影响。尽管目前没有文献指出所影响内容，但我们可略作探讨。例如，下图的“Level 3”中的IPC部分，对于操作系统而言，其IPC机制是对应用程序而必须提供的基础功能，数据库的进程或线程等需要借助操作系统提供的IPC机制并发或并行运行。而把IPC建立在数据库之上，则要么有两套IPC机制（或逻辑上算作一套物理层面分离为两部分），要么改变数据库的架构。再比如，“Level 3”中的Scheduler部分，必然对并发的任务进行执行，这样的任务架在“Level 2”上的Distributed DBMS，必然是依赖DBMS，而DBMS的自身的进程（或线程/协程）的并发执行，也依赖与操作系统的底层的Scheduler（如果不依赖则要有多层调度，性能会有损失），如果把操作系统层的Scheduler集成到DBMS中，必然影响到DBMS的架构，如果不集成，则Scheduler也会有两层，类似对IPC的处理，性能会有损失。另外，功能组件在逻辑上虽然分离，但在物理实现时，也需要做好边界划分，物理层面也会影响到“Level 1”和“Level 2”、以及“Level 2”和“Level 3”的实现，甚至可能影响到DBMS的架构。

但是，这样的思维，是借用数据库中的优势之处，弥补操作系统的不足。另外，其所基于的事务处理机制，还是数据库领域传统的事务处理方法。虽提及事务处理技术，但只是“用”而不涉及事务处理技术的形式化定义与改进等。

这样的跨系统的对并发类系统进行的思考和探索，与本文谈及的站在并发类系统之外统一思考一致性与并发的本质所处的角度是不同的。本文的“一致性与并发”理论，是对一致性与并发层面的本质问题探索，涉及其理和形式化定义，因此两者不同。

图1 DBOS架构

“一致性与并发”理论，也是一次跨系统的对并发类系统进行的思考和探索。但其向内探索，着重于探索什么是一致性、一致性如何影响着并发等这样的问题，着眼的是跨系统的共性问题而不是DBOS探索的跨系统的边界问题（但其实，两种方式都有望推动跨系统的融合与架构重塑）。但是，“一致性与并发”理论这样的探索结果，尽管属于理论层面，但其所得结论，会影响到数据库的架构设计。这是因为，其结论有助于把并发类系统软件的设计方法变为顶层设计、自上向下。其过程中的产物，量化方法，则有助于提高认知，把摸索的方式变为高屋建瓴的视角。

我们再来看图2。该图展示了我认知的数据库架构发展的历程。整个历程分为三个阶段：

1. 初级阶段：过去的70+年，是软件技术的初级阶段，在这个阶段，层次、网状、关系模型等是这个时代的标志。事务处理技术、查询优化、各式存储等是这个时代的光辉产物。在这个阶段，人们摸着石头过河，传统数据库技术从提出到成型，在不断发展中。但是，人们对于软件技术从整体上缺乏顶层设计，软件开发和设计，曲曲折折在布满荆棘的泥泞中前行。这个时代，软件技术不断分化和演化，分化是面向不同领域不断进行细化的过程，典型如处理硬件资源分离出独立的操作系统、处理数据分离出独立的数据库、处理用户请求分离出独立的应用中间件等；演化，则是各自不断进化的过程，尽管成就辉煌，但在进化的过程中，还处于一个随机演化的过程、还没有找到量化的路径。
2. 量化阶段：这是软件发展的第二个阶段，也是一个过渡阶段。软件技术需要进入到量化阶段以深刻认知每一个系统软件，其结果是便于为未来做顶层设计做好准备工作。这个阶段，不同系统也许其量化技术不同。对于数据库系统而言，或者对于并发类系统而言，现在有一种途径，可达到量化之路。这样的路径，就是从并发的共性去入手，从解决系统在并发场景下如何确保正确性以及同时确保性能去入手，但入手的方式不似传统的以解决问题为目的（如操作系统着手解决死锁即罢手、数据库采用一些并发算法解决数据异常即罢手），而是以深入而透彻地研究本质问题为抓手（如研究什么是数据异常，数据异常有多少种有哪些，数据异常之间存在什么关系、各种一致性之间的关系、一致性与性能的关系），才有希望进入量化阶段。只有深入而透彻地研究本质问题，才能量化问题、量化解决问题的方法、量化系统的主要矛盾加以量化解决之。
3. 完美阶段：这是软件发展的第三个阶段，是未来的高级阶段。也许是多个并发系统的融合阶段，也许是Stonebraker的DBOS阶段（或也许是OS和DB融合的阶段），更是一个智能加持的、不断能自我进化的阶段。但是自我进化应该有一个前提，那就是能在框架层面进行顶层的自我设计，能在局部算法层面自调优。而要做到这些，需要依赖的是量化阶段积累的方法论和数据、以及量化阶段揭示出的新的视角和思维，因此量化阶段是一个必需的过渡阶段，哪一个事务如果能进入到量化阶段，则有希望加速进入到智能阶段。量化阶段的产物，必然会有大量的精炼的“Rules”产出，帮助人们提纲挈领地认清事务真相。

图2 并发类系统软件架构发展过程

所以，单就数据库系统类的并发系统软件而言，“一致性与并发”理论体系，有望陪伴我们进入并发场景下的量化阶段，根本原因是并发系统的核心问题被量化了。

另外，并发类系统软件的架构被改变，根本原因是对并发系统有了新认知。例如，在“一致性与并发”理论，操作系统的死锁被证明为是数据库数据异常的特例，而每一种数据异常都能被枚举，因此并发控制需要处理的每一种场景都是明确清晰可辨的，因此可量化处理与优化。

因此我们可以知道，操作系统的并发调度可以和数据库的并发控制技术融合为一体，由此证明实现Stonebraker的DBOS中把事务处理技术模块放到操作系统层是可行的。也由此可以知道，图1中的“Level 1”和“Level 2”本应该是融合到一起的，其可行的一种方式是把数据库肢解重构、把并发控制完全实现到操作系统层，把数据库的存储和“Level 3”层的文件系统融合，从而实现“OS+DB”的效果。这就是数据库架构重构。

从技术的角度上看，这是并发控制技术从数据库中的解耦（也是用一个较为完备的技术向其他系统融合的过程），解耦的结果，是带来架构变化和生产力的解放。历史上，解耦和融合带来过诸多的生产力解放，示例已经不胜枚举我们不再例举。

我们需要把握并发控制技术（甚至是事务处理技术的全部）从数据库中解耦向其他系统融合、然后为并发类系统软件的架构带来的重塑机会，同时数据库等软件架构也将发生大的变化。

而把握系统类软件架构重塑机会的机会与思维起点，是：以“一致性与并发”即以正确性和性能为出发点重构并发类系统软件。从该起点出发，通向新一代系统软件架构的、可见的一条路在于前述的量化之路。

六、结语

现今的软件架构设计原则和方法论，几乎都是“摸着石头过河”的试探性、随机的、自底向上的方式。这表明软件架构设计处于初级阶段。

我们期待未来做软件架构设计，一定能采用自顶向下的设计方法，使得软件系统更为完美。这种完美，是通过精简的本质性规则构建起来的软件架构。

但从初级阶段走向到完美阶段，找到精简的本质性规则，需要先步入量化阶段。

并发类系统软件，有望通过研究并发的共性问题，进入到量化阶段。并发类系统软件的研究成果，构成了“一致性与并发”的理论体系，该体系使得并发类系统软件面临的问题被量化、解决问题的方法被量化、并发类系统软件的共性被量化。

基于“一致性与并发”的理论体系，可以获得新的认知。新的认知可用于指导并发类系统软件的架构设计。

“OS+DB”，则是在新认知指导下对数据库架构重构的方向，也会是并发类系统软件架构重构的方向，把并发控制机制完全交给操作系统，把正确性和性能下压到操作系统，除了会精准解决并发问题，还将带来性能的显著提升。这是一种美好的设想，有望帮助系统软件进入“完美阶段”。

这种设想，美好、可行。其途径，量化技术必然会为软件架构带来新变化。每一类软件，努力走入到量化阶段，将会让软件技术步入快车道而奔驰前行。

[1] 有人认为：并发类系统软件的本质在于如何在多任务环境中实现高效的资源共享和任务协调，同时保证系统的正确性和可靠性。这不仅涉及到具体的算法和技术手段的选择，还要求对并发理论有深刻的理解，并能在实际应用中灵活运用这些知识。

[2] 操作系统领域如此解释死锁：典型的资源竞争问题，其根源在于资源分配策略不当。解决方法包括预防（如避免循环等待）、检测与恢复（如定时器超时后强制释放资源）、以及避免（如银行家算法）。