无主复制系统(1)-节点故障时写DB概述
2023-09-27 14:19:47 时间
单、多主复制的思路都是:客户端向某主节点发写请求,而DB系统负责将写请求复制到其他副本。
- 主节点决定写顺序
- 从节点按相同顺序应用主节点发送的写日志
某些数据存储系统另辟蹊径:放弃主节点,允许副本直接接受客户端写。最早的复制数据系统就是无主节点(或称之为去中心复制、无中心复制),但后来在关系DB主导的时代,这想法被忘却。在亚马逊将其用于其内部的Dynamo系统1后,它再一次成为流行的DB架构。Riak,Cassandra和Voldemort都是由Dynamo启发的无主复制模型的开源数据存储,所以这类DB也被称为Dynamo风格。
- 某些无主实现,客户端直接将写请求发到多副本
- 而另一些实现中,有个协调者(coordinator)节点代表客户端进行写入,但与主节点的DB不同,协调者不负责维护写入顺序
4.1 节点故障时写DB
假设三副本DB,其中一个副本当前不可用(或许正在重启以安装系统更新):
- 主节点复制模型下,若要继续处理写,则需执行故障切换
- 而无主模型,则不存在这切换
图-10:User 1234将写请求并行发送到三副本,两可用副本接受写,而那不可用副本无法处理。假设这俩成功确认写,User 1234收到两个确定响应后,即可认为写成功。完全能忽略那一个副本无法写入的情况。
等失效节点重新上线,而客户端开始读取它。节点失效期间发生的任何写入在该节点都尚未同步,因此可能读到过期数据。
为解决该问题,当某客户端从DB读数据时,它不是向1个副本发送请求,而是并行发送到多个副本。客户端可能会从不同节点获得不同响应,即来自一个节点的最新值和来自另一个节点的旧值。可利用版本号确定哪个值是更新的。
Dynamo不适用于Amazon以外用户。 令人困惑的是,AWS提供了一个名为DynamoDB的托管数据库产品,它使用了完全不同的体系结构:它基于单领导者复制。 ↩︎
相关文章
- 通过 kubectl 查看 K8s 内节点、Pod 资源使用情况
- 删除单链表中的某一个值为num的节点
- redis容器化后保证双主、一对主从不在同一节点,分配方式了解一下
- 删除链表倒数第N个节点
- zookeeper节点Watch机制实例展示
- 使用Minikube运行一个本地单节点Kubernetes集群(阿里云)
- easyui-treegrid移除树节点出错
- Qt编写安防视频监控系统8-双击节点
- JavaScript更新插入DOM节点
- 《剑指offer》-- 序列化二叉树、二叉搜索树的第k个节点、数据流中的中位数、滑动窗口的最大值
- 24模拟keepalved vrrp功能,监听主节点,如果主节点不可访问则备节点启动并配置LVS实现接管主节点的资源提供服务(提醒:注意ARP缓存)
- Unity 之 ShaderGraph Artistic节点解析汇总
- k8s helm 安装mysql8.0,单节点,一主两从架构
- 关于Cocos2d-x中精灵节点的透明度的设置
- 关于Cocos2d-x中节点的获取
- 关于Cocos2d-x中节点和精灵的关系以及初始化
- C# xml文件的创建,修改和添加节点 。
- 路由器二次开发一步一步把工业路由器变成一个高端的可指定出网、节点和链路的路由器,包含详细过程及快捷脚本(三)
- 王道数据结构 (3) 单链表 插入节点