数据是随着业务量的增长而呈现爆破式的增长.
不久前,单机还能满足数据的完成存储,我们需要做的仅是数据备份安全.
但当一台机器无法完成数据存储的时候,通常是进行数据的拆分,在数据库方面,人们通过对数据库进行拆分以达到目的.
拆分方式:
1.水平拆分
2.垂直拆分
然而,一套基于数据的存储系统,数据的安全及数据的一致性尤为重要.秉着数据安全高于一些的宗旨.以下是一点感想:
数据一致性的保证:
W+R>N
W:成功写操作的最小节点数
R:成功读的最小节点数
N:复制的节点数
只要保证以上公式就能保证数据的一致性.
在这类的模型里,数据之间存在一个矢量锁(vector clock)来保证数据的最终一致性.
这类方案例如:voldemort,Cassandra…
这里讨论的不是这类nosql的读写能力,而是在异常情况下情况,比如在W=3的情况下,若其中一个W的写入出现滞后的情况,会引起全局写入的波动.此时会发现写入严重下降.引起的原因是单台机器的下降.
将以上方案进行一点变形,引入中心化思想-基于M-S架构的集群
写入的请求会先到到Master,再有Master异步分发到Slave机器中,不去关心写入的成功与失败,若系统运行了长时间,此时数据会出现不一致的情况(master绝对正常,slave中的数据开始延时了),此时需要通过数据校验来完成数据的一致性验证,这类方案在Mysql内部有很多.例如:可参看Mysql中半同步复制机制.
SemiSyncReplication
在mysql中,需要至少开启一个半同步的slave,在master提交事务[写]的之后,只有在只有有一个slave已经接受了这个事务,该事务才算成功.此时若master挂掉了,将会切换到slave上,并重新发起事务.这个可满足高可用性的需求,但若此时master挂掉了.恢复后若原有事务已经提交,就会导致复制出现问题.

将以上方案进行一点变形,引入全局时间服务器
机器等级均等,无中心节点,建立全局时间服务器.
写请求进入的时候,成功写入后异步分发给其他机器.同节点中机器间会进行数据校验.应为使用了全局时间,同一条数据在全部集群内只会存在一个版本.每次同步完成后,都会记录checkpoint.
记录散列到点上,可设计新策略进行二次散列,达到节点的优先选择.例如将机器的URL作为选取条件.实时要求的请求通过id得知自己在那台机器最新(相对的,发生错误的时间:在客户端提交到某天机器(A),.A分发到其他机器未成功(比如B),B还未进行本时刻的数据校验.前端请求到B上get数据,B的数据在此时不实时.).

只要保证拥有全局时间戳作为校验依据即可.
数据校验的过程会存在checkpoint,为了数据安全,唯一要做的保证磁盘空间足够,磁盘会记录数据的操作历史(写操作).数据的分类是按照时间来分割的.so,日志还能用于数据的行为跟踪.
以上仅为个人一点观点,欢迎提出意见.