摘要
Raft 分布式一致性算法在 2013 年发布，以容易理解、实现方式明确的特点，迅速在业界流行起来。本次分享将介绍 TiDB 如何使用 Raft 算法构建分布式可扩展的后端存储系统，以及 TiDB 在可靠性、可用性、性能等方面对 Raft 做的工程优化。Why Ralf
假设我们有某一个业务要实现数据存储方面的功能，最简单方法就是实现一个节点，所有的数据读写都是通过这一个节点。但是这样会存在各种各样的问题，比如数据量增大后无法承受压力，单节点如何向多节点分布，数据的一致性怎么保证，最严重的就是数据节点挂掉，数据全部丢失了。Replication
为了解决节点损坏的问题，业界通用的方案是采用Replication，在Master写数据的时候挂多个Slave，写完后保证将log同步到Slave，这样的流程下来才能认为写入是成功的。
通常情况下为了保证性能，我们都会使用异步复制（Async Replication），不过会产生一些问题。当Master挂掉了之后很有可能有些数据并没有同步到Slave，这时候如果把这个Slave提升到新的Master就会面临数据丢失的问题。
强同步（Sync Replication）解决了异步复制（Async Replication）可能潜在的问题。Master写入数据后必须保证Slave接收到log写入才算成功，当然这样会损耗一些性能，不过最严重在于Master挂掉后，Slave提升为Master，单节点的问题就又出现了。
为了保证系统中N台节点挂掉后，仍然能够对外提供服务，至少需要2N+1台机器，也就是传统的Quorum，这样最少就需要三台机器，但是数量的增大也会带来更多的问题。
首先Master挂掉后要需要判断该提升哪个Slave为新的Master。另外在多态集群下还容易遇到一个问题，就是在网络情况下以前的Master出现网络隔离，还在继续对外提供服务，而这时新的集群和Master已经形成了，新的数据被写入到新的Master，可是读取的却是旧的数据，这就是在分布式一致性领域所面临的线性一致性问题。
