分布式的数据

为了更高的负载，更高的可用性，更低的延迟，分布式的架构被利用起来，scale out，扩展能力是一个系统必须考虑的因素

• 数据的分布，常常会有2中途径，复制和分片
• 复制
  复制主要是提供冗余，高可用。但某些情况下，也可以用于提升性能
• 分片
  partitioning或者shading，将一份完整数据拆分为多个分片

Chapter 5 复制

单独考虑复制的前提是每一个节点可以包含所有的数据，而不需要分片。复制的难点在于各个副本的数据一致性。有3种算法去处理节点数据变化，single-leader, multi-leader, and leaderless replication，各自有利有弊，需要权衡
其他的考虑要素，诸如同步/异步，处理失败副本

1.1、leader和follows

Leader-based（master-slave）replication

• leader：数据写入的第一个节点
• folllows: 写入leader后，将写入请求也转发到follower，每个follower使用log或者change stream 去更新自己的copy
• 查询：一般leader和follower都进行read操作

1.2、同步和异步

同步和异步是一个重要的属性，指 复制这个过程是同步还是异步的

image.png

2者的区别很明显，同步保证副本和主上的同时更新，但延迟可能因为网络等很大，但异步速度快，确不能保证副本更新成功。因此有时候，也会有所谓的semi-synchronous，半同步，即在异步的节点上，选出一个要求同步，当这个同步节点挂掉时，在选一个异步节点改为同步

1.3、创建一个新follower流程

常规的操作是
1.创建一个主的快照
2.拷贝快到到新follower
3.新follower加载快照后，再向主订阅快照后的变化，通常使用一个位点，如mysql的binlog position
4.追上后即变成了一个正常的副本节点

1.4.节点宕机

• 副本节点宕机
  这个很简单，和之前创建时一样，通过日志去追就可以了

• 主节点宕机
  failover，故障切换，当主节点宕机后的一系列操作过程的统称，整个过程通常由一下几部分构成
  1.确定leader宕机：主节点的问题可能有网络，宕机等各种因素，如何确定主节点真正不可用并不简单，一般的架构都用了 延迟最为判断的标准。通过leader和follower之前的心跳探测频率等，如果响应超时，即认为leader宕机
  2.选举新的leader
  这是一个比较大的话题，但原则上一定是要选出 存储了最新最全信息的节点
  3.重新配置新leader
  如将客户端的写入定向到新的leader中等操作，防止旧的主节点恢复后出现双主节点。旧主节点哪怕恢复也应当做新的follower看待

• 故障转移时的一些需要考虑的点：
  1.异步情况下，副本节点当选为主节点，它可能并没有更新到最新的数据
  2.可能需要丢弃一些数据，而这很可能产生数据不一致的问题
  3.脑裂问题，多个节点认定自己为leader
  4.判断下线的超时时间，太长故障转移过慢，太短又很可能是误操作

1.5 复制日志的实现

• statement-base replication
  将每一条修改，增加，删除语句，进行同步，每一个副本节点将请求再自己这重新执行一次，即回放
  问题：

1. 非确定语句，如now()，rand(）等在不同机器上执行可能会有不同结果
2. 所有的设置主副需要一致，如主单数递增，副双数递增，则有些查询需要进行特殊处理
   很多的边界条件需要考虑，因此，一般现在不采用这个方式

• Write-ahead log（WAL） shiping
  相比于之前的statement，WAL参考我们之前的内容，它在实际的数据引擎中写入的操作，具体执行是和选用的引擎相关联的。
  wal避免了之前数据的不一致随机性，但也带来了新的问题，因为WAL是依赖于数据引擎的，这会导致强依赖，以后的升级或者改换实现，都必须停机做处理
• Logical (row-based) log replication
  在WAL的基础上，我们为了使日志与引擎解耦，所以第三种方式是逻辑日志，那么为什么我们又称之为 row-based log，那是因为逻辑日志的粒度一般是基于row的
  row-based到底记录了哪些数据
  1 add 时，记录新的所有列的值
  2 delete时，记录主键，或者记录主键和所有原有列的值
  3 update，新旧所有列的值。最起码是有改变的那几列
• Trigger-based replication
  触发器，更为灵活，但没用过，触发后还需要其他程序配合

1.6 复制日志带来的问题

单节点接入，扩展靠通过增加follower实现，一般用读写分离。这时候同步可能会导致写入过慢，异步的话，各个follower的数据一致性会受到影响。
这里只能说，我们保证最终数据一致性，即当停止写入后，随着时间，各个follower的数据会满足一致性
此时若网络出现问题，或写入接近处理能力，可能会造成数十秒，甚至分钟级的影响，在这实际汇中是需要注意的
问题举例1：read-after-write consistency
异步时，follower还没有写入，收到了读取请求

image.png

read-after-write consistency, also known as read-your-writes consistency
这个一致性，只是保证你的修改和你读取，你的读取一定是你修改后的数据，但不保证其他用户

实现方式
1.当只有自己能修改自己的数据时
每个用户读取自己的数据时，在leader上读，读取其他数据时，在follower上读
2.当别人也能修改自己的数据时
这个相对复杂，当异步时无法保证，只能记录key的更新时间，请求判断如一分钟以内更新到转发到主节点，一分钟以后到任意follow

还有目前的所谓跨设备一致性，同一个用户，在手机，pad，pc上的访问数据保持一致

问题举例2：monotonic read 单调读一致性

image.png

因为读不同的follow，导致读取结果不一致

解决方案，哪怕是读follower，同一个用户也要定位到同一个follower上

问题举例3：prefix read，保证结果的因果性，其实就是顺序

image.png

当旁观者，从不同的节点，可能先改变的后读到，违反了因果性。

• 这个例子和之前的不同点在哪？
  我觉得是强调的是因果，之前的例子都是一个partiiton的一份数据先后性，这个例子主要是2个partition数据由于各自复制导致的先后
  有一些类似于kafka先后2份数据，到不同的partition上就无法保证先后一致性的感觉

解决这个问题，需要保证的是一系列的写入，读取的时候也必须能按顺序读取。
实际中常常通过制定partition解决，因为依赖算法去解决这个成本一般较高

1.7 muti-leader replication

master–master or active/active replication，每一个都是其他节点的follower，但自己也是可以写入的
首先要明确使用场景：

• 多中心
  多中心是目前最常见的提高可靠性，提升服务速度的方式，每个中心还采用leader-follower，各个中心之间，同城双活和异地双活都是很大的工程

  
  
  image.png
• 离线服务
  此时的本地离线也可以写入，可以当做一个datacenter，只不过这个本地仓库可能和线上相差数个小时，甚至更久
  1.7 Collaborative editing
  协作编辑，作为商业办公的重要组成部分，重点是在解决冲突，当在某些方面，和之前离线的例子很像，每个人的编辑需要在本地先确认，在体现在其他人的数据中

多中心的问题---冲突
multi-leader，是的写入可以在多个leader上进行，随之而来的，write conflict是最主要的问题

• 冲突探测的异步和同步
  冲突的异步，后一个人将需要处理冲突，冲突的同步探测，会损失太多性能，还不如单leader架构
• 避免冲突
  鉴于冲突是很难解决的，避免冲突永远是最佳的选择，多个中心可以写入，但应该将写入尽量固定，同一个人写入回到离它最近的固定的datacenter，以避免在多个datacenter中写入，同步时产生冲突
• 收敛一致性
  多个写入时的顺序，需要保证按顺序执行，不然无法保证最终的数据
  1、 last write wins (LWW)，即用timestamp等，给每个写入一个uuid，最大的成功写入，但会有数据丢失的风险
  2.每个节点一个uuid，更大的节点拥有更高的优先权，也会有数据丢失的风险
  3.合并结果，例B/C
  4.保留所有数据，后续处理

典型的冲突处理方式
写入时如果有冲突，调用提前写好的handler
读取时进行提示

多节点复制

多节点的复制拓扑.png

1.7 leaderless replication

这个很陌生，amason有 in-house Dynamo system，工作中暂时没有碰到这种架构的，只做简单了解

leaderless

• Read repair
  当读取到旧版本数据时，会将更新的数据，往那个节点写入一份