问题描述
传统的单副本存在单点故障；
解决方案
为了解决单点故障问题，软件系统工程师引入数据复制技术（多副本）；
通过数据复制方案：
1）提高服务可用性，避免单点故障。
2）提升读吞吐量、甚至就近部署在业务所在的地理位置，降低访问延迟。
原理简述
多副本常用的技术方案主要有：主从复制；去中心化复制；
主从复制
主从复制，比如 MySQL/Redis 单机主备版就基于主从复制实现的，
其又分为全同步复制、异步复制、半同步复制：
全同步复制，指主收到一个写请求后，必须等待全部从节点确认返回后，才能返回给客户端成功。因此如果一个从节点故障，整个系统就会不可用。这种方案为了保证多副本的一致性，而牺牲了可用性，一般使用不多。
异步复制，指主收到一个写请求后，可及时返回给 client，异步将请求转发给各个副本，若还未将请求转发到副本前就故障了，则可能导致数据丢失，但是可用性是最高的。
半同步复制，介于前两者之间，它是指主收到一个写请求后，至少有一个副本接收数据后，就可以返回给客户端成功，在数据一致性、可用性上实现了平衡和取舍。
去中心化复制
去中心化复制，它是指在一个 n 副本节点集群中，任意节点都可接受写请求，但一个成功的写入需要 w 个节点确认，读取也必须查询至少 r 个节点。
你可以根据实际业务场景对数据一致性的敏感度，设置合适 w/r 参数。比如你希望每次写入后，任意 client 都能读取到新值，如果 n 是 3 个副本，你可以将 w 和 r 设置为 2，这样当你读两个节点时候，必有一个节点含有最近写入的新值，这种读我们称之为法定票数读（quorum read）。
AWS 的 Dynamo 系统就是基于去中心化的复制算法实现的。它的优点是节点角色都是平等的，降低运维复杂度，可用性更高。但是缺陷是去中心化复制，势必会导致各种写入冲突，业务需要关注冲突处理。
参考文献
etcd 实战课（唐聪，腾讯云资深工程师，etcd 活跃贡献者）_极客时间