【架构】为什么需要主从复制与分片

前言

今天看了一本书，作者提醒大家严谨得讨论一致性、容错性。也揭示了需要对架构设计永远充满谦卑之情，没有完美的方案，只有相对得更优解。

• 本文讲主从复制
  在大型公司内，作为开发人员，往往是选择不了数据库端的架构的。而主从复制则是主流的选择，在主从复制模式下如何处理业务上的一致性是开发需要关注的问题
• 分片
  考虑到网上大多数的内容都称之为“分片”，其实“分区”才是正确的说法，只是不同软件厂商对“分区”取了不一样的名字。
  • ES——shard
  • HBase——region
  • Bigtable——tablet

1. 主从复制的出现所解决的问题

1.1. 主从复制 多主复制 无主复制

以数据库为主的复制技术，主从复制较容易实现。其思想是以一个主库作为写入入口，其他从库用于同步主库的数据，为客户端的读访问进行负载均衡，同时避免了多个库的写冲突问题。在多主复制和无主复制的情况下，一定会遇到多个数据库的写冲突，解决冲突最好的办法就是避免冲突，这个思想有点像Java中的ThreadLocal。主从复制只有单个写通道，自然避免了多个数据库的写冲突。但是还是要强调的是，单个数据库下的写冲突不是主从复制能避免的，任意单体环境下数据库都需要用隔离级别与锁技术保证一致性

MySQL PostgreSQL Oracle 等数据库都内置主从复制，意味着主从复制可以不需要任何客户端代码既可以实现。

1.2. 复制技术的优势

• 使数据在地理位置上更接近用户，从而降低访问延迟
  游戏分西南大区 华南大区 北部大区等

• 当部分组件出现故障，系统任然可以继续工作，从而提高高可用性
  获取集群的优势
  试想一下，主节点故障了怎么办？—— 选举一个新的主节点（后文会讲这里的解决方案）

• 扩展至多台机器以同事提供数据访问服务，从而提高读吞吐量
  提高读的并发能力

2. 使用异步复制

书中介绍了同步复制和异步复制，先分析这两个技术需要支持的业务场景

• 同步复制
  业务：确保系统中所有的读取都是跟主库保持一致
  技术：全局加锁按顺序更新
• 异步复制
  业务：仅能确保主库的数据是最新
  技术：不需要加锁，广播更新日志，数据同步的事情可以交给后台的线程执行

如果系统的瓶颈是读的访问能力，那么请直接使用异步复制。异步复制会存在问题，但是问题或已被数据库厂商简化解决。特别得，如果业务端对数据滞后不敏感，则不需要采用同步复制而牺牲并发性能而。

2.1. 业务端对滞后性不敏感

• 看球
  由于多节点读的负载均衡，如果存在500ms的数据滞后，用户互相是感知不到的，因为看球常常接的是一个客户端，不常有两个客户端在房间里同时播放。若数据滞后达到1s左右，用户也不会抱怨是软件架构的问题，因为网络波动造成延迟已经是共识问题了，业务端不需要再为客户端提供完全的实时性保障，但是两个用户看球的内容最终都是一样的，这就是所谓的最终一致性保障。

2.2. 保障自己的信息是最新的

• 最新关注自己的更改
  在CSDN上自己发的贴子的更改要立马体现，自己看其他用户的帖子允许一部分滞后信息。
  自己写入数据，一定是往主库读，那么在业务端做如下控制：

  1. 登录用户的id == 需要访问的用户的id —> 读主库
  2. 否则，读从库

• 多次自己读的信息不出现回退
  为什么会造成回退呢？ 已知从库A已经最新，从库B还在同步滞后的信息，先读A再读B就会造成信息回退。
  如何解决？ 每个用户读取的内容都只路由到一个读库，为了避免产生热点库，用哈希表的思想均匀分布用户-库的关系。

• 客户端和服务端的组合拳
  客户端记录请求获得的数据版本，再次请求

3. 主从复制的最终一致性和高可用

3.1 不停机为集群添加从库

1. 从库B请求主库A那获得一个一致性快照
2. 从库B根据快照记录生成自己的，主库A记录数据更改日志
3. 从库B请求主库A获得快照之后的更改日志，追加数据
4. 从库B成功加入集群

3.2 全序的日志

1. 主库按更新的数据日志，广播给所有从库
2. 从库收到，按顺序写入，保障与主库写入顺序一致
   2.1 如果发生网络抖动，已知日志记录1，日志记录2，从库先收到日志记录2 怎么办？
   参考TCP的滑动窗口，从库阻塞更新，等待日志记录1到达再一起更新
   如果日志记录1丢失，从库可以请求获取日志1 的记录

3.3 动态的问题

动态的问题往往是比较难解决的，主要有

1. 从节点挂掉，原来的路由规则修改
   旧路由要废弃，不然会有部分用户失效。

2. 主节点挂掉，从新选举主节点。
   选举不同步，会造成双主节点，也就是“脑裂”问题，引入写冲突。

作者认为以上两个问题，外包给软件解决是最好的，比如zookeeper。应用程序依赖zookeeper的动态目录即可。而zookeeper的原理则是另外个大课题了。

4. 分片解决的问题

• 面对海量的数据或非常高的查询压力，任意个从节点返回的速度是瓶颈
  减少单个节点的数据量，全表扫描的时间减少了，返回速度的下限也减少了

• 提高可扩展性
  可以把数据扩展到不同的磁盘，查询负载也分布到更多的处理器上

• 定制化查询
  关键词的范围查询，在应用层路由到指定分片上，查询速度快。

4.1 分片和复制的关系

分片的思想非常简单 —— 把数据分散。

4.2. 分片后如何保证主从复制

• 在应用层做一个逻辑视图，路由到不同的节点，该路由是唯一的。所以可以视为主库被分片，每个分片又有独立的复制。
  

4.3. 复制和分片结合

附上书上摘录的图，回想起ES就支持结合操作

4. 4 分片和复制的附加价值

ES在部署的时候，可以指定分片和复制数。业务实现上，把ES作为搜索引擎，允许一段区间的数据不一致性。具体就是把实时记录存入MySQL，定期全量更新ES，全量更新的过程依旧使用旧版本提供对外访问的接口。ES的分片就不用关系动态扩容的问题，这样子就拥有其附加价值：

• 每个节点的数据量少，提高读性能
• 每个节点的主分片可以提供负载均衡的查询能力
• 每个节点都能拥有不同的分片
• 如果节点崩溃，可以从不同节点获取到节点的副本进行恢复