【亲述】Uber容错设计与多机房容灾方案-高可用架构系列 - 架构设计 - 爱上编程技术博客

【亲述】Uber容错设计与多机房容灾方案-高可用架构系列 - 架构设计 - 爱上编程技术博客

non-sharded, stateless 类型服务非常容易解决单点故障。 通常load balancer可以按照固定的时间间隔，去health check每个node, 当某一个node出现故障时，load balancer可以把故障的node从pool中排除。

很多服务的health check设计成简单的TCP connect, 或者用HTTP GET的方式，去ping一个特定的endpoint。当业务逻辑比较复杂时，可能业务endpoint故障，但是health endpoint还能正常返回，导致load balancer无法发现单点故障，这种情况可以考虑在health check endpoint中增加简单的业务逻辑判断。

对于短时间的network故障，可能会导致这段时间很多RPC call failures。 在RPC client端通常会实现backoff retry。 failure可能有几种原因：

1. TCP connect fail，这种情况下retry不会影响业务逻辑，因为Handler还没有执行。
2. receive timeout, client无法确定handler是不是已经收到了request 而且处理了request，如果handler重复执行会产生side effect，比如database write或者访问其他的service， client retry可能会影响业务逻辑。

对于sharded service，关键是如何找到故障点，而且将更新的membership同步到所有的nodes。下面讨论几种sharding的方案：

1. 将key space hash到很多个小的shard space, 比如4K个shards。 通过zookeeper (distributed mutex) 选出一个master，来将shard分配到node上，而且health check每一个node。当遇到单点故障时，将已经assigned的shards转移到其他的nodes上。 因为全局只有一个single master, 从而保证了shard map的全局一致。当master故障时，其他的backup node会获得lock成为Master。
2. Consistent hashing方式。consistent hashing 通常用来实现cache cluster，不保证一致性。 因为每个client会独立health check每一个node, 同时更新局部的membership。 在network partition的情况或者某一个node不停的重启, 很可能不同的client上的membership不一致，从而将相同的key写在了不同的node上。 当一致性的需求提高时，需要collaborative health check, 即每个node要monitor所有其他node的health。 Uber在这里使用的是gossip protocol，node之间交换health check的信息。

大面积故障怎么办

Read full article from 【亲述】Uber容错设计与多机房容灾方案-高可用架构系列 - 架构设计 - 爱上编程技术博客