多个主节点看到的执行顺序不一致,病了同时按照各自看到的写入顺序执行,那么数据库最终将处于不一致状态。
数据库必须以一种趋同的方式来解决冲突。
可能的解决方式
- 给每个写入分配唯一的 ID,如基于时间戳的最后写入者获胜。
- 为每个主节点分配一个唯一 ID,序列号高的优先于序列号低的主节点,可能导致数据丢失
- 以某种方式合并值,如按照字母顺序拼接在一起
- 利用预定义号的格式记录,然后依靠应用层逻辑,事后解决冲突(可能会提示用户)
多个主节点看到的执行顺序不一致,病了同时按照各自看到的写入顺序执行,那么数据库最终将处于不一致状态。
数据库必须以一种趋同的方式来解决冲突。
主节点与从节点 复制 单个节点可以完整存放所有数据副本,节点间进行主从复制。 配置新从节点 可以通过快照来加速新从节点复制: 对主节点的数据副本产生一个一致性快照,避免长时间锁定数据库。 拷贝快照到从节点 请求快照后面的更改日志 应用数据变更 节点失效 从节点失效:追赶式恢复 主节点失效:节点切换 自动切换 确认失效 选举新的主节点 使主节点生效 挑战 从节点复制不完整 各个数据层数据不一致,如 MySQL 和 Redis 之间 多个主节点选举:脑裂 如何有效检测主节点失效 复制日志实现 复制滞后问题 多主节点复制 使用场景 多数据中心 优点: 性能 容忍数据中心失效 容忍网络问题 缺点:写冲突 离线客户端操作 协作编辑 处理写冲突 同步与异步冲突检测 同步:等待写请求完成对所有主节点的同步再通知用户写入成功。 异步:等待单一主节点写入成功后通知用户卸乳成功,稍后多主节点数据同步的时候才能检测到冲突 避免冲突 收敛于一致的状态 自定义冲突解决逻辑 写入时解决 读取时解决 拓扑结构 环形拓扑 星型拓扑 全部-至-全部型拓扑 无主节点复制