64、CoMaP：动态协作式叠加型混搭平台的深入剖析

CoMaP：动态协作式叠加型混搭平台的深入剖析

1. 操作迁移机制

当新用户 U2 请求与用户 U1 相同的混搭应用时，基于 U1 请求的先前操作部署不再是最优的。例如，MPN2 与 U2 之间的通信会导致高延迟，因此需要再次进行迁移。在这个例子中，MPN2 考虑将 Op3 和 Op4 迁移到 MPN3 作为目标邻居。具体操作步骤如下：
1. MPN2 重复相同的迁移步骤，计算出新状态成本（NewStateCost = 12）、当前状态成本（CurrentStateCost = 22）和净收益（NetB = 10）。
2. 基于计算结果，MPN2 决定将 Op3 和 Op4 迁移到 MPN3。

当操作从 MPNi 迁移到 MPNj 时，MPNi 会通知部署了子操作和父操作的 MPNs 这一变化，并告知混搭控制器。混搭控制器会更新其混搭索引，以便在新的混搭请求到来时，能够根据最新的索引将执行任务导向合适的 MPNs。

迁移过程会定期执行，以确保 CoMaP 能够适应新请求的混搭应用、终端用户共享操作数量的变化，以及网络链路延迟和带宽的变化。迁移过程中的节点探测成本是可以接受的，因为探测仅在迁移过程中定期发生，且迁移在每个 MPN 本地进行，不会影响系统功能。

以下是操作迁移的流程图：

graph LR
    A[新用户请求相同混搭] --> B[MPN2 计算成本]
    B --> C{NetB > 0?}
    C -- 是 --> D[决定迁移 Op3 和 Op4 到 MPN3]
    D --> E[MPNi 通知相关 MPNs 和控制器]
    E --> F[控制器更新混搭索引]
    C -- 否 --> G[维持当前部署]

2. 故障恢复机制

CoMaP 中的故障源主要有两种：混搭控制器（MR）故障和混搭处理节点（MPNs）故障。

2.1 混搭控制器故障处理

为避免系统出现单点故障，通过复制混搭控制器来处理故障。其中一个是主控制器，其他是辅助控制器。所有控制器在系统信息和处理用户请求方面作用相同，但主控制器在故障恢复过程中略有不同。

控制器之间的交互如下：
- 检测共享操作：每个控制器需要了解所有终端用户发送的混搭应用中的操作。当一个控制器收到混搭应用时，会将信息直接发送给其他所有控制器。
- 故障通知：每个控制器有一个相同的节点列表，包含主控制器、辅助控制器和候选替代节点的信息。主控制器与辅助控制器交换心跳消息，若未收到回复，则认为该辅助控制器故障，并进行以下操作：
1. 使用候选集分配新的辅助控制器。
2. 将当前状态复制到新的辅助控制器。
3. 通知其他辅助控制器旧控制器故障和新控制器的存在。
- 主控制器故障：若辅助控制器未收到主控制器的心跳消息，则认为主控制器故障。此时，当前辅助控制器列表中的第一个控制器将替换主控制器，并进行以下操作：
1. 从当前辅助控制器列表中移除自己。
2. 将列表变化传播给其他控制器。
3. 向其他辅助控制器宣布自己为新的主控制器。

2.2 混搭处理节点故障处理

MPNs 与直接邻居交换心跳消息，若未收到回复，则认为邻居故障，并向本地控制器报告。控制器收到故障通知后，会将故障 MPN 上的操作重新分配到新的 MPN，并将新分配信息传播给主控制器和所有辅助控制器。

为减轻 MPN 故障的影响，会复制部分操作。系统管理员根据系统性能选择一定比例的过载 MPNs 复制其操作。MPN 复制操作时，会通知本地控制器，控制器再将此变化传播给其他控制器。

以下是故障处理的表格总结：
| 故障类型 | 处理方式 |
| ---- | ---- |
| 混搭控制器故障 | 复制控制器，主控制器与辅助控制器交换心跳消息，根据情况进行替换和状态复制 |
| 混搭处理节点故障 | MPNs 交换心跳消息，故障时报告控制器，控制器重新分配操作，复制部分操作减轻影响 |

3. 实验评估

3.1 实验设置

使用模拟实验来评估“DIMA”方法对 CoMaP 性能的影响，并探讨应用故障恢复机制对系统的影响。实验环境模拟了多种操作，如 Fetch、Filter、Sort 等，类似于雅虎管道。系统由 4 个混搭控制器、100 个数据源、100 个终端用户和 1000 - 4000 个 MPNs 组成。终端用户请求的混搭应用总数为 1000 - 10000，请求速率为 5 - 65 次/单位时间。数据源来自 syndic8，其流行度分布也从该平台提取。每个混搭应用中的操作数量为 10 - 40，其中两个为获取操作，数据源根据流行度选择，其余操作随机选择。数据源大小为 1000 KB - 10000 KB，叠加拓扑为 2008 年的互联网拓扑，使用的节点数量为 1204 - 4204。

3.2 系统评估

CoMaP 中的系统成本基于两个因素衡量：每个混搭应用的平均延迟和每个混搭应用的平均网络使用量。“DIMA”方法与“Random”、“Source”、“Destination”和“Optimal”方法进行比较。

在不同实验中，改变一个参数并保持其他参数不变，得到以下结果：
- 操作数量变化 ：“Random”方案导致高延迟和高网络使用，是所有方案中最差的。“Source”和“Destination”方案的延迟和网络使用低于“Random”方案。“Optimal”方案的延迟和网络使用最低，但由于需要长时间的穷举搜索，不具有实用性。“DIMA”方法在延迟和网络使用方面优于“Random”、“Source”和“Destination”方法，性能接近“Optimal”方法。随着操作数量的增加，各方案与“Optimal”方案的差距增大，而“DIMA”方法通过迁移操作找到更好的部署选项，延迟增加最小。
- 数据源大小变化 ：随着数据源大小的增加，所有方案的系统成本都增加，这是由于数据量增加导致的计算和通信成本增加。
- MPN 数量变化 ：随着 MPN 数量的增加，“DIMA”方案与“Optimal”方案的差距增大，因为搜索空间增大，“DIMA”方案找到接近最优部署决策的难度增加。
- 迁移对系统成本的影响 ：在系统执行的三个不同阶段测量延迟和网络使用。在第一阶段，请求混搭应用并执行“DIMA”初始操作放置；第二阶段，继续执行混搭应用但无新请求；第三阶段，开始“DIMA”迁移过程且无新请求。结果显示，第一阶段延迟和网络使用增加，第二阶段达到最高成本并稳定，第三阶段迁移过程开始后，延迟和网络使用显著下降，这种循环贯穿 CoMaP 的生命周期。
- 故障恢复机制的影响 ：
- 延迟 ：应用故障恢复机制会增加延迟，原因包括：终端用户需要将混搭应用发送到更远的控制器；操作复制导致执行可能不经过延迟最小的 MPN；故障概率增加时，更多延迟最小的 MPN 故障，导致通信转向其他 MPN。
- 成功率 ：随着故障概率的增加，执行混搭应用的成功率降低，但使用故障恢复机制的成功率高于未使用的情况，因为操作复制增加了其可用性。
- 开销 ：故障恢复机制的开销通过网络使用量衡量，随着复制百分比的增加，开销增加，因为更多操作被复制，MPNs 和控制器之间的通信增加。

以下是不同方案在操作数量变化时的延迟和网络使用对比表格：
| 操作数量 | Random 延迟 (s) | Destination 延迟 (s) | Source 延迟 (s) | DIMA 延迟 (s) | Optimal 延迟 (s) | Random 网络使用 (KB) | Destination 网络使用 (KB) | Source 网络使用 (KB) | DIMA 网络使用 (KB) | Optimal 网络使用 (KB) |
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| 10 | 高 | 中 | 中 | 低 | 最低 | 高 | 中 | 中 | 低 | 最低 |
| 20 | 更高 | 中 | 中 | 低 | 最低 | 更高 | 中 | 中 | 低 | 最低 |
| 30 | 极高 | 中 | 中 | 低 | 最低 | 极高 | 中 | 中 | 低 | 最低 |
| 40 | 极高 | 中 | 中 | 低 | 最低 | 极高 | 中 | 中 | 低 | 最低 |

综上所述，“DIMA”方案在实现操作部署决策方面具有有效性，能够降低网络延迟和使用量。尽管应用故障恢复机制会带来一定的开销，但可以降低 CoMaP 的故障概率，避免单点故障。

4. 相关工作对比

在Web 2.0兴起之后，出现了多种混搭平台，但它们大多不具备分布式特性，这在一定程度上限制了其可扩展性。具体如下：
| 平台名称 | 特点 | 局限性 |
| ---- | ---- | ---- |
| Karma | 为终端用户提供基于示例构建的方法 | 非分布式，可扩展性受限 |
| Marmite | 作为Firefox插件在用户端工作 | 非分布式，可扩展性受限 |
| MashMaker | 用于从小部件构建混搭应用，支持用户共享小部件 | 非分布式，可扩展性受限 |
| DAMIA | 专注于企业领域和情景应用的数据集成服务 | 非分布式，可扩展性受限 |
| MARIO | 提出了用于混搭执行的规划算法，通过标签创建混搭应用 | 非分布式，可扩展性受限 |

同时，也有一些分布式组件执行平台被研究，但它们在成本度量、故障处理等方面与CoMaP存在差异。
| 平台名称 | 特点 | 与CoMaP差异 |
| ---- | ---- | ---- |
| [10]提出的分布式流处理平台 | 每个流在覆盖网络的多个代理节点处理，提出流处理操作放置方案 | 成本度量不如CoMaP全面，未考虑故障问题 |
| [1]提出的操作部署环境 | 基于分布式哈希表（DHT）路由进行部署 | 使用DHT选择节点可能导致节点选择不佳 |
| Borealis | 分布式流处理系统 | 操作部署未考虑网络覆盖变化，如链路延迟和带宽变化 |
| Medusa | 分布式流处理环境，以实现负载均衡的方式部署操作 | - |
| [12]研究的覆盖网络节点放置分析 | 关注在网络基础设施上放置机器 | CoMaP关注覆盖网络中混搭操作的放置 |

5. 总结与展望

作为Web 2.0的协作应用之一，混搭应用面临着可扩展性和性能方面的限制。CoMaP作为一个动态协作式叠加型混搭平台，具有多个创新特性。它提出了可扩展且高效的操作部署方案，通过“DIMA”方法在网络延迟和使用量方面取得了较好的效果，接近“Optimal”方案。同时，通过复制控制器和操作，实现了故障恢复机制，降低了系统的故障概率，避免了单点故障。

虽然CoMaP已经取得了一定的成果，但仍有一些方面可以进一步研究和改进。例如，在面对大规模网络和大量操作时，如何更高效地进行操作迁移和故障恢复；如何进一步优化成本度量，以更好地适应不同的网络环境和应用需求；以及如何在保证系统性能的前提下，降低故障恢复机制的开销等。未来的研究可以围绕这些方向展开，以提升CoMaP的性能和可扩展性，为混搭应用的发展提供更有力的支持。

以下是CoMaP的优势和待改进方向的列表总结：
- 优势 ：
- 可扩展且高效的操作部署方案。
- “DIMA”方法接近最优方案，降低网络延迟和使用量。
- 有效的故障恢复机制，降低故障概率。
- 待改进方向 ：
- 大规模网络和大量操作下的高效迁移和故障恢复。
- 优化成本度量以适应不同环境和需求。
- 降低故障恢复机制的开销。

graph LR
    A[CoMaP优势] --> B[可扩展部署方案]
    A --> C["DIMA接近最优"]
    A --> D[有效故障恢复]
    E[待改进方向] --> F[大规模高效处理]
    E --> G[优化成本度量]
    E --> H[降低恢复开销]

通过以上对CoMaP的深入剖析，我们可以看到它在解决混搭应用的可扩展性和性能问题上具有重要的价值，同时也为未来的研究提供了方向。希望更多的研究者能够关注和参与到这一领域，推动混搭应用的发展。