云存储的黑暗面:元数据保障(下)阅读的一点记录

文章中中提到了一种方法WRN方法,在写入时,应该采用两阶段提交方案。

如果客户端直接写,假设只有一个元数据服务器写成功,那么我们无法得知这个元数据是否是写成功了,如果读到这个元数据,哪怕只有一个副本,也可能造成读数据的混乱。

我认为应该采用两阶段提交,如GFS,客户端在元数据服务集群中选择一个leader写,这个leader选择一个多数派,进行两阶段提交,如果写失败,不会提交,所以读元数据的时候不会读到。但是可能出现另一个问题,在两阶段提交的第二个提交阶段不能保证每个副本都收到了提交的命令。这里我想到的解决方案是,可以在这个leader中写日志。首先如果已经第一阶段完成,那么很可能第二阶段也会成功。如果不成功,那么可能是该服务器遭受了严重损坏,如宕机。但是此时我们仍认为该次写入是成功的,虽然不是多数派存储了最终数据。因为多台服务器同时宕机的情况很少,我们可以利用定期的副本之间的同步来,解决某些副本没有存储到的内容。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值