写失败数据写入成功_数据密集型应用系统设计重点总结

复制

复制的作用

1. 提高可用性。即使系统的一部分出现故障，系统也能继续工作

2. 提高读取吞吐量。伸缩可以接受读请求的机器数量

3. 减少延迟。数据与用户在地理上接近

复制算法

三种流行的变更复制算法：单领导者，多领导者和无领导者

单主复制

数据一致性问题：每一次向数据库的写入操作都需要传播到所有副本上，否则副本就会包含不一样的数据。如何确保所有数据都落在了所有的副本上？

最常见的解决方案被称为基于领导者的复制(主从复制)，领导者接收写请求(且只允许领导者接收写请求)，将数据同步到追随者。

其中同步操作分为同步，半同步，异步，通常在服务端可以配置。

设置新从库

1. 获取主库的一致性快照

2. 将快照同步到从库进行加载

3. 从库连接到主库，根据日志序列号/坐标等标识，追上主库的数据变更

处理节点宕机的办法

• 从库宕机：追赶恢复

• 主库宕机：故障切换

自动故障切换的标准

1. 确认主库宕机。手段是判断超时

2. 选举新主库。共识问题：见分布式共识

3. 重置请求路由。如果老领导回来了，确保他现在是从库

故障切换的问题

1. 如果是异步复制。新主库未收到老主库宕机前最后的写入操作，老主库重新加入集群时，容易产生写入冲突(如mysql自增主键重复)

   解决方案是，丢弃老主库宕机前的写入。但会带来数据丢失的问题。如果数据库同时和外部存储联动，则还可能带来数据不一致的问题

2. 脑裂问题。旧主库重新加入集群时，集群可能认为存在两个主。

   解决方案是，关闭其中一个，但不合理的实现可能会发生两个都被关闭

3. 超时参数如何设置。

多主复制

多领导者复制的最大问题是可能发生写冲突。

如协同编辑，两个用户同时编辑页面，用户1将页面的标题从A更改为B，并且用户2同时将标题从A更改为C。

写入冲突 每个用户的更改已成功应用到其本地主库。但当异步复制时，会发现冲突。

解决方法是：