Master-Slave
首先是Master-Slave结构，对于这种加构，Slave一般是Master的备份。在这样的系统中，一般是如下设计的：
读写请求都由Master负责。
写请求写到Master上后，由Master同步到Slave上。
从Master同步到Slave上，可以使用异步，也可以使用同步，可以使用Master来push，也可以使用Slave来pull。 通常来说是Slave来周期性的pull，所以是最终一致性。这个设计的问题是，如果Master在pull周期内垮掉了，那么会导致这个时间片内的数据丢失。如果你不想让数据丢掉，Slave只能成为Read-Only的方式等Master恢复。
当然，如果可以容忍数据丢掉的话，可以马上让Slave代替Master工作（对于只负责计算的结点来说，没有数据一致性和数据丢失的问题，Master-Slave的方式就可以解决单点问题了） 当然，Master Slave也可以是强一致性的， 比如：当写Master的时候，Master负责先备份，等成功后，再写Slave，两者都成功后返回成功，整个过程是同步的，如果写Slave失败了，那么两种方法，一种是标记Slave不可用报错并继续服务（等Slave恢复后同步Master的数据，可以有多个Slave，这样少一个，还有备份，就像前面说的写三份那样），另一种是回滚自己并返回写失败。（注：一般不先写Slave，因为如果写Master自己失败后，还要回滚Slave，此时如果回滚Slave失败，就得手工订正数据了）可以看到，如果Master-Slave需要做成强一致性有多复杂。
Master-Master
Master-Master，又叫Multi-master，是指一个系统存在两个或多个Master，每个Master都提供read-write服务。这个模型是Master-Slave加强版，数据间同步一般是通过Master间异步完成，所以是最终一致性。 Master-Master的好处是一台Master挂了，别的Master可以正常做读写服务，这个和Master-Slave一样，当数据没有被复制到别的Master上时数据会丢失。很多数据库都支持Master-Master的Replication的机制。
另外，如果多个Master对同一个数据进行修改的时候，这个模型的恶梦就出现了——需要对数据间的冲突进行合并，这非常困难?？纯碊ynamo的Vector Clock的设计（记录数据的版本号和修改者）就知道这个事并不那么简单，而且Dynamo对数据冲突这个事是交给用户自己搞的。就像SVN源码冲突一样，对于同一行代码的冲突，只能交给开发者自己来处理。（在本文后后面会讨论一下Dynamo的Vector Clock）
-
SDN中的分布式：
-
Ravana：SDN中的控制器容错
- 传统分布式系统和SDN中分布式的区别
- 同步交换机的状态的代价太高，影响包处理的性能
- 传统分布式系统中的方法不能同步交换机的状态，一旦控制器挂掉，重新选举出来的leader不知道从何配置交换机的状态；就算控制器可以roll-back到之前的状态，交换机也不能roll-back到一个安全的checkpoint
- 传统分布式系统和SDN中分布式的区别
