背景
主从集群，指由一个主数据库实例和多个从数据库实例组成，其中主数据库实例提供读写功能支持，而从数据库不提供对外服务或只提供只读功能支持，但也有从数据库提供读写功能支持，下面就这几种集群架构做详细的解读，并就如何实现从节点可更新机制进行探讨。
主从集群概述
主从集群的实现方式主要有以下几种：
- 基于磁盘镜像的主备集群
- 基于Proxy中间件的主从(多主)集群
- 基于共享磁盘的主从集群
- 基于日志重放(物理日志或逻辑日志)的主从集群
一、基于磁盘镜像的主备集群
基于磁盘镜像的主备集群是最早出现的一种高可用解决方案，对数据库系统没有特殊要求，不需要额外的功能支持，利用原有单机数据库系统即可搭建，主要利用磁盘镜像来实现主备之间数据的同步。
原理是利用磁盘镜像的机制，当主机数据更新后，在写入磁盘的同时将数据同步到备机的磁盘上，主机缓冲区中的数据并不能同步到备机。当主机down机后，除了缓冲区数据未同步之外，磁盘上的数据还可能因为部分写而导致数据错误。所谓部分写是由于IO的特性导致的。
通常磁盘IO以扇区为单位一次性读写，但真正的数据页通常大于一个扇区(512字节)，因此在down机时有可能只写了数据页的一部分，如一个数据页面大小为16K，down机时只写了此数据页的2K。后面会专门介绍数据库解决部分写的方法。
它的缺点也比较明显，主备机实例不能同时启动，只有当主机down机后，备机启动，并执行恢复操作，然后提供对外服务。因此，切换时间较长，而且备机的资源无法充分利用，适用于主机硬件损坏导致无法恢复的场景，也可用于计划检修等场景。
二、基于Proxy中间件的主从(多主)集群
基于proxy中间件可以搭建多主或主从集群，主要原理是利用proxy代理对应用请求进行分类、转发，当是写请求时，将写请求转发到集群中的每一台服务器；当是读请求时，将读请求转发到任意一台服务器即可。
基于proxy中间件搭建的集群，在数据库层面并不保证多机之间的数据一致性，而是由proxy来间接实现一致性，proxy通过检查发给所有服务器的写请求的执行结果，当任一服务器执行失败，就反向执行写请求，以保证多节点之间数据的一致性，这种一致性只是弱一致性，在数据库中也称为事务补偿机制。此外，也可以利用数据库本身提供的XA协议(如果数据库支持的话)，但为了提高一致性，会损失性能和可用性。
它的主要缺点是无法保证事务的强一致性，当一个节点down机后，其它节点后续的写请求无法在down机服务器上执行，会造成down机服务器的数据丢失。
三、基于共享磁盘的主从集群
基于共享磁盘的主从集群是目前比较常见的集群架构之一，原理是通过主从服务器读取共享磁盘的数据来进行数据同步。因为数据库服务器的缓存，所以除了从共享磁盘读取数据之外，还要进行日志的内存重放，以更新缓存的数据。
共享磁盘架构的主要问题是缓存的同步，当主机提交事务时，同时将日志发到从机，或将日志刷写到磁盘后通知从机读取，然后从机重放日志，更新缓冲区的数据，但从机禁止将缓冲区数据写回到磁盘，只有主机可以将数据写回到磁盘。另外一个问题是部分写的问题，后面会专门讨论。
根据主机提交事务的时机，可以实现异步、近同步、实时同步等不同模式。异步指主机提交事务时，将日志发给从机，但不关心是否发送成功即完成事务提交。因为有网络延迟、重放日志延迟等，主从之间的数据并不是实时同步的。通常日志发送采用专门的进(线)程来实现，从机的数据有可能delay主机很久，这要实际的生产环境有很大关系。
近同步指从机收到日志即向主机返回成功，主机即可完成事务提交，但此时从机尚未日志重放，会有稍许日志重放的延迟。
共享磁盘架构的主要的问题在于必须有集群文件系统的支持，依赖于集群文件系统来保证节点间的数据一致性，并且在数据库层面也要有分布式锁来防止写写冲突和读写冲突。
四、基于日志重放(物理日志或逻辑日志)的主从集群
基于日志重放的主从集群是最常见的集群构架，并且也有很多独立于数据库的产品。日志大体有两种，一种是逻辑日志，一种是物理日志。物理日志通常都比较小，易于保存和传输，但重放的代价比较大，对从机资源的消耗也比较大，mysql的主从集群就是典型的以逻辑日志为基础的主从集群。与之相反的是物理日志，通常物理日志都比较大，但物理日志重放的代价都比较小，对从机资源的消耗也比较小，但对网络资源的消耗比较大。
逻辑日志重放代价上最有利的场景一个应用场景就是全表更新；而物理日志重放代价上最有利的场景更新全表扫描中的一条记录。因此，不能简单的说，哪种日志更好，必须以实际的应用场景来具体分析。
数据库系统中解决部分写的常见方法
在数据库系统中，数据通常以固定大小的页面来保存，页面大小也通常是512字节的整数倍，512字节是通常磁盘一个扇区的大小，扇区是一次磁盘IO的最小单位。SSD盘通常扇区大小为4K。在数据库系统中，一般情况下，数据页面的大小都会远大于512字节，随着大数据的到来，8K，16K页面已经很常见。当数据页面比较大时，要将一个数据页面刷写到磁盘上就需要多次IO，但这多次IO之间并不是原子操作，在执行过程中很可能因为各种原因导致中断，如断电，磁盘损坏等，造成的后果就是磁盘上的数据页面前面部分已经更新，后半部分仍是旧的数据，也就是部分写。出现部分写后的数据页是无法使用的，典型的牛唇不对马嘴。使用raid条带化也可能会导致同样的问题。
在数据库系统实现过程中，必须如何发现并解决这个问题。首先我们来说一说单机系统中的解决方法。
首先数据库要能检测到这个问题，实现的方法也比较简单，在页面头上记录一个标志，如时间戳，然后在页面尾上也记录一个相同的标志，当读取数据页面后，只要检查一下标志是否相同即可证明页面是否存在部分写。需要注意的是每次页面更新后，标志也必须同时进行修改，不能使用原有页面的标志。还有一些代价更大的方法，如生成整个页面的摘要，然后记录到页头中，除了可以检查页面的部分写之外，还能防止页面被恶意篡改，但这对系统资源的消耗比较大。一种热衷的办法是计算部分页面数据的摘要，但要包含页面头和页面尾，这样就可以能检测页面的部分写，也能部分达到防止篡改的目的。
在实现页面部分写检测的功能之后，我们还要解决如何这个问题，我们的目的是能得到正确的数据，而不只是发现错误。当数据库发现页面错误之后，可以采用的办法是通过日志重放来恢复数据。如果要从系统最初的状态重头开始进行日志重放，那么代价太大，或者有些场景下就是不可能实现的。为了加速这个过程，数据库引用checkpoint来解决这个问题。当checkpoint时，当前所有缓冲区中被修改的页面都要被刷写到磁盘上，执行成功后，记录checkpoint日志，以后就可以从这个点进行恢复。这与部分写有什么关系呢？数据库在更新每个缓冲区的数据后，都会记录日志，日志内容记录了当前修改的内容，最重要的一点是在记录日志时，如果发现当前的缓冲区是在checkpoint之后的首次修改时，会做一个当前页面的快照，并将其记录到磁盘上，在postgresql中是将其记录到redo日志中，另外一些数据库是记录到一个专门的日志中，如mysql的double write。当这个缓冲区被多次修改后，若在将其刷写到磁盘的过程中出现的断机等异常情况，造成部分写后，系统重新启动读取页面时发现页面有部分写，那么会将之前记录到磁盘的快照覆盖出现部分写的数据页面，然后在此基础上进行日志重放，从而达到恢复部分写的结果。
在基于共享磁盘的主从集群中也会存在相同的问题，有可能是主要写了一半，而从机此时来读取数据，就会读取到错误的数据。利用前面时间戳或摘要的方法，可以轻易解决检测部分写的问题。如何读到正确的数据呢？一种简单易用的方法就是重读，当检测到数据页面错误时，重试几次就好了，就能解决绝大多数的问题了，如果总是读取不正确，就要考虑是不是磁盘坏掉了。报错给DBA也是一个不错的选择。如果非要数据库来解决了，也是可以的，同样采用在快照上重放日志就可以实现数据的恢复，但代价比较大，运行过程中进行数据页恢复的设计也比较复杂。
从节点可更新机制
通常在主从集群中，主节点是可以读写的，而从节点通常只能提供只读功能，能不能实现在从节点也可以读写支持呢？当然可以，常见的方法有如下几种：
- SQL转发
- 全局锁
- 主机延迟裁定
1.SQL转发
从节点接受应用请求后，经过词法语法分析后，若发现是更新类的操作，如DML，DDL等，将其转发给主节点，再将主节点执行后的返回结果转发回给应用程序。从节点本身实际并不真正执行更新操作，它依赖于主从之间的同步机制来更新本地缓存的数据。若不是实时同步更新，可能会导致应用程序在从节点更新，又在从节点读取到更新前的脏数据(历史数据)。若是更新较多的应用场景，从节点并不能承担分流的任务，主节点的负载不会有明显降低。
2.全局锁
如果集群实现了全局锁，从节点就可以真正在本地更新数据，但需要有额外的同步机制将从节点的数据同步到主节点。全局锁的实现可以使用集中式锁管理，也可以使用分布式锁管理，可以根据需要和应用场景来选择实现。 全局锁虽然解决了从节点的更新问题，但会对整个系统的性能造成较大影响，因为每次对数据页面的访问都要加全局锁，增加了大量额外的网络开销。并且还要实现从节点到主节点的数据同步机制。
3.主机延迟裁定
从节点收到应用程序的更新请求后，直接在备机执行syntax解析、SQL优化、执行等，在提交之前，向主节点发送裁定请求，以判定此写操作是否可以提交。向主节点发送的内容至少应包括更新前的数据快照、修改后的数据等，主节点收到裁定请求，比较更新前的数据快照是否与当前的数据相同，若相同则说明在从机修改数据之前此份数据没有被修改过，是在最新数据版本上进行的更新，则将更新的内容应用到主节点，如果需要记录日志，同时将日志刷写到磁盘。如果更新前的数据快照与当前的数据不相同，则说明在从机修改数据之前，主机已经修改过数据，但尚未同步到从机，因此必须回滚事务。
