数据复制三种模式

数据复制

为何需要数据复制

• 使数据在地理位置上更接近用户，从而降低访问延迟。
• 当部分组件出现故障，系统依然可以继续工作，从而提高可用性。
• 扩展至多台机器以同时提供数据访问服务，从而提高读吞吐量。

主从复制

• 指定某一个副本为主节点。当客户写数据库时，必须将写请求发送给主节点，主节点首先将新数据写入本地存储。
• 其他节点则全部称为从节点。主节点把新数据写入本地存储后，然后将数据更改作为复制的日志或更改流发送给所有的从节点。每个从节点获得更改日志或更改流之后将其应用到本地，且严格保持与主节点相同的写入顺序。
• 客户端从数据库中读数据时，可以在主节点或者从节点上执行查询。再次强调，只有主节点才可以接受写请求；从客户端的角度来看，从副本都是只读的。

同步复制和异步复制

同步复制：主节点需要等待直到从节点确认完成写入，然后才会向用户报告完成。
异步复制：主节点发送完消息后立即返回，不用等待从节点的完成确认。
半同步：其中某一个从节点是同步的，而其他节点则是异步的。万一同步的从节点变得不可用或性能下降，则将另一个异步的从节点提升为不同模式。这样可以保证至少有两个节点（即主节点和一个同步从节点）拥有最新的数据副本。

多主节点复制

系统存在多个主节点，每个都可以接收写请求，客户端将写请求发送到其中的一个主节点上，由该主节点负责将数据更改事件同步到其他主节点和自己的从节点。

多主复制一个很大的缺点：不同数据中心可能会同时修改相同的数据，因而必须解决潜在的写冲突。

理论上，也可以做到同步冲突检测，即等待写请求完成对所有副本的同步，然后再通知用户写入成功。但是，这样做会失去多主节点的主要优势：允许每个主节点独立接受写请求。

最理想的策略是避免发生冲突，即如果应用层可以保证对特定记录的写请求总是通过一个主节点，这样就不会发生写冲突。例如总是确保特等用户的更新请求总是路由到特定的数据中心，并在该数据中心的主节点上进行读写。不同用户则对应不同的主数据中心（例如根据用户的地理位置来选择）。从用户的角度来看，这基本等价于主从复制模型。

无主节点复制

客户端将写请求发送到多个节点上（超过半数节点写入即为成功），读取时从多个节点上并行读取，以此检测和纠正某些过期数据。

读修复

当客户端并行读取多个副本时，可以检测到过期的返回值。例如用户从副本3获得的是版本6，而从副本1和2得到的版本是7。客户端可以判断副本3是一个过期值，然后将新值写入到该副本。

返熵过程

后台进程不断查找副本之间数据的差异，将任何缺少的数据从一个副本复制到另一个副本。与基于主节点复制的复制日志不同，此返熵过程并不保证特定的顺序复制写入，并且会引入明显的同步滞后。