高性能容错事务内存技术解析

### 高性能容错事务内存技术解析 #### 1. HiperTM性能优势 HiperTM在事务处理方面展现出了卓越的性能。当有3个副本时，对于10%的只读事务，HiperTM的只写事务吞吐量超过了PaxosSTM。这一加速直接得益于HiperTM对写事务的推测处理，使得SCC能够在事务被A交付时提交大部分事务。 随着只读事务比例从10%变化到90%，HiperTM的性能和系统可扩展性显著提高。这主要是因为只读事务可以在本地执行，无需涉及OS - Paxos和其他节点进行计算。整个系统观察到的最大吞吐量约为每秒处理400K个事务，比PaxosSTM最多快约1.2倍。 在TPC - C基准测试中，将HiperTM与SCORe的性能进行了比较。TPC - C的平均事务执行时间比Bank的要长得多，这影响了整体吞吐量。然而，HiperTM仍然能够在事务执行与提交协调之间进行重叠操作。当有8个副本时，HiperTM的性能比SCORe高出多达10倍。原因在于SCORe需要为远程访问的对象进行查找，而HiperTM在本地执行，避免了这一开销。 此外，使用TPC - C基准测试测量了领导者故障对事务吞吐量的影响。领导者崩溃后，观察到最大性能下降约30%。这是因为直接连接到领导者副本的客户端需要时间来检测故障，并将其连接（用于读写事务）重新路由到其他副本。经过这段时间后，性能恢复到稳定状态。 | 性能指标 | 详情 | | ---- | ---- | | 只写事务吞吐量（3个副本，10%只读事务） | 超过PaxosSTM | | 最大吞吐量 | 约400K事务/秒 | | 比PaxosSTM最大加速比 | 约1.2倍 | | 8个副本时HiperTM比SCORe性能提升 | 多达10倍 | | 领导者崩溃后最大性能下降 | 约30% | #### 2. 相关技术对比 在事务系统的复制方面，已有许多相关工作。一些主动复制技术依赖原子广播来对事务请求进行排序，并在最终顺序通知后才执行事务。而HiperTM基于乐观原子广播，在事务最终交付之前就开始处理事务，即乐观交付时就开始处理。 投机性事务处理的概念最初被提出，并在后续研究中得到进一步探讨。例如，AGGRO是一种投机并发控制协议，在主动复制的事务系统中按顺序处理事务。但该协议仅提出了理论，未给出实际实现，因此开销情况未知。HiperTM的所有设计选择都基于实际性能问题，单线程处理和多版本内存用于只读事务的并行激活和无中止特性，在基于类似OS - Paxos的全序服务系统中，是性能和冲突检测开销之间的最佳权衡。与其他一些技术不同，HiperTM不会以多种序列化顺序执行同一事务，因为OS - Paxos在无故障执行时保证不重新排序。 基于全序的完全复制也在基于认证的事务处理中得到研究。在这种模型中，事务首先在本地处理，然后在提交阶段调用全序服务进行全局认证。但这些技术在消息大小增加时会受到（O）AB可扩展性瓶颈的影响。而HiperTM的消息长度不取决于事务操作，仅受调用事务的签名及其参数的限制。 Granola是一种基于单轮通信的复制协议，其并发控制技术使用单线程处理来避免同步开销，并且具有与SCC类似的作业调度结构。 ```mermaid graph LR classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; A(传统主动复制技术):::process --> B(依赖原子广播排序):::process C(HiperTM):::process --> D(基于乐观原子广播):::process E(AGGRO):::process --> F(投机并发控制):::process G(基于全序完全复制):::process --> H(本地处理后全局认证):::process I(Granola):::process --> J(单轮通信复制协议):::process ``` #### 3. 事务内存中的非干扰与局部正确性 事务内存旨在使并发编程变得高效且易于处理，它允许用户将一系列操作组合成具有全有或全无语义的原子事务。通常认为，事务内存必须确保所有已提交的事务构成一个尊重实时顺序的串行执行，而中止或未完成的事务不应“生效”。 这里探讨了“不生效”的另一个不太明显的特性——非干扰。即中止或未完成的事务不应迫使任何其他事务中止。在最强形式的非干扰中，从历史记录中删除一部分中止或未完成的事务，不应在不违反正确性标准的情况下将一个中止的事务变为已提交的事务。