阅读笔记（十五）分布式错误检测《Survey on Scalable Failure Detectors》

一. 简介

  《Survey on Scalable Failure Detectors》一文针对两种常见的大规模错误检测算法进行了评估。二者均是fail-stop模型，即无拜占庭问题的模型。其中一种是经典的gossip协议，采用心跳包实现强完成性的模型，另一种是Dynamo中采用的ping命令实现的最终完成性模型。本文对二者进行了简单介绍并评估了其性能优劣。

二. 算法介绍

1. Gossip

  Gossip是最经典的错误检测算法，其核心思想在于当一个节点发现和另一节点的心跳包未得到回应时，则自增心跳并向随机的一些节点广播自己目前的节点路由表。收到的节点会将该路由表和自身路由表判断，并存储版本号最大的心跳信息。如果有某个节点的版本号长期未更新，则说明该节点出现了错误。

2. GRR

  gossip算法采取的随机节点发送在后续研究中被优化为轮询转盘发送式gossip算法GRR（Gossip Round Robin)，即采用二进制指数轮询，因此可以将通知所有节点的时间控制在LogN，如下图所示为简单的示意图。

3. Dynamo错误检测

  Dynamo是亚马逊大名鼎鼎的分布式k-v存储模型，该文也非常值得一读。Dynamo算法采用随机ping命令和分布式错误确认。收到ping命令的节点需要回复ack。如果源节点未收到ack，则源节点会向k个其他节点发送请求，让他们也发送ping命令去ping这个节点，如果该k个节点也没有回复ack，则该节点被标记位错误节点。

  在该论文中，并未有提到节点恢复的具体做法，然而在真实的模型中，这部分是核心所在。采用ping命令去检测之前失效的节点是否恢复是极其低效的，尤其是当失败节点数增多的时候。因此，比较适合的恢复协议应该是采用ping/心跳包发送给所有的节点，去主动告知已恢复，并根据ack去更新新的路由表。

三. 算法分析和比较

1. 时延分析

  有图可见，Gossip的经典算法和BRR算法在节点数较少的情况下性能差距不大，而当节点数增多的时候，检测轮数差距明显。这要得益于指数算法带来的大数据处理速度。

  下图展示了消息丢失率不同的曲线，随着节点数增多检测所需次数的增长曲线。有图可见由于Dynamo采取多次ping命令而非gossip的通知，因此会需要更多轮的确认，没有gossip那么及时。同时，Dynamo算法的表现对丢包率不敏感，即丢包率对轮询次数影响不大。

  下图展示了在不同丢包率下，检测所需的时间。造成gossip和Dynamo差别的原因在于gossip在未收到心跳包回复的时候会先判定该节点失效，而Dyanmo则在k次ping失败后才会判断失效。

2. 误检测分析

  考虑到网络存在波动、时延、拥塞、短暂的分区等等因素，错误检测可能会存在误操作。如下图所示，展示了丢包导致的错误判断。而这里需要注意的是，经典Gossip算法强调的不是未收到ack，而是在规定时间内未收到ack。这里的时间和节点数成正相关。因此gossip-500对时延、丢包有着极好的容忍性，甚至可以做到无失误。而gossip-100则由于时间要求苛刻而无法达到。同理，BRR对时间的容忍性极差，因此误操作可能性更大。

  Dynamo依赖于k个节点的ping的结果，从而确认该节点是否失效。在下表中我们可以看到k的取值和误判数之间的关系。很明显随着规模的扩大错误率提高了。

3. 扩展性分析

  Gossip发送的消息格式为：

{int fromPort, HashMap < int, int > allCounters}

  因此，总长度为

4 bytes + N ∗ 2 ∗ 4 bytes = (8N + 4) bytes

  最终发送N个，即

N(8N + 4)bytes

  而Dynamo采取的消息格式为：

{int type, int fromPort, int toPort, intperiod, int relayPort}

  N个节点总消息为：

  所以相对于Gossip来说，Dynamo的扩展性更佳，消息总消耗带宽仅为线性增长。

四. 总结

  综合看来，gossip拥有较少的检测延时，但是对丢包率非常敏感，因此对固定大小的网络来说较为实用。而Dynamo没有保证检测时延，但是可以应付丢包率问题，并且易于扩展，适用于大型的分布式系统。