分布式系分发展概览

整体的发展历程：

推动数据库技术大发展的一个重要功能就在于，通信技术领域和计算机科学领域的量大领域的碰撞催生出的互联网行业，在互联网中各种各样的创新业务不断涌现，百花齐放，企业数据量也呈现出了爆发式的增长，读写性能要求也越来越高。围绕解决数据存储和访问的各种问题，出现了各种各样的技术。

单体数据库时代

主从架构(可靠性)

解决单体数据库不具备高可用和容灾能力。就出现了主从结构

依靠binglog来保持主从数据的同步，实现了数据的实时被封。在这基础之上，引入高可用组件，比如zookeeper，实现master的主动故障切换，就有了一主多从的架构：

这里主要的技术点：

1. 主从如何实现数据一致(binglog只是可以实现主从复制的基础，binglog并不能保证主从数据的一致)
2. 如何发现master故障了。(心跳？mysql没有心跳健康检查机制的。引入外部组件来作，那mysql怎么响应心跳包来证明自己还活着？用select 1， select 1能够正常返回正的能说明master还是很健康的么？)
3. 主从延迟怎么解决？有主从延迟，那么主备切换就可能是有损的。到底是可靠性优先还是可用性优先？(RTO和RPO的)

单体数据库中的写入瓶颈

分库分表

分库分表的核心逻辑就是：需要一个协调者，来作路由。根据这个协调逻辑部署的位置分为两种方案：

1. 以一个客户端的方式运行在应用服务中
2. 独立的代理

这种方式的问题很明显：

1. 数据库链接爆炸问题。
2. 分库分表的能力是比较有限的。

这里的主要技术点：

1. 路由规则(分片策略)。分片策略主流的有hash分片、range分片。还有一些比如list分片等，但实际使用场景比较少。但是在分库分表中，基本都只能实现hash分片。
2. 分库分表对复杂全局查询支持代价大。比如join、分页等
3. 分库分表对分布式事务支持弱，代价比较大。

单元化+单体数据库

思路就是将数据按照水平切分，每个单元管理一部分数据，且没个单元从数据到服务都自闭环掉了。

技术点：

1. 一个公司的数据千千万，按照什么维度去切分到单元内？
2. 跨单元访问怎么办？
3. 跨单元写入的事务问题。ps：蚂蚁的LDC为什么没有跨LDC访问的事务问题？(蚂蚁的LDC是这种架构么？)

微服务

它的思路就是将业务数据按照业务领域垂直拆分，每个微服务有自己的应用服务器和独立管理的数据，多个微服务之间的依赖通过rpc通信，变成了面向服务的依赖，最终完成整个业务。

ps：不管是单元化还是微服务，列到这里，都是从解决数据库瓶颈的探索方案。但是反过来：单元化、微服务都是为了解决数据写入瓶颈的，那就太片面了。

分布式关系数据库

两个发展思路造就了两个不同的架构

1. 从单体数据库出发，叠加的分布式能力。这种主要就是在基于代理的分库分表中间间上，继续发力，为其加上分布式功能，对外提供统一的关系型数据库服务。
2. 从分布式系统的角度出发，叠加关系型数据库的特性，比如事务。

相比于分不分表中间件，主要的技术点：

1. 全局时钟
2. 统一的事务管理器，维护一个全局的活动事务列表。

天生的分布式数据库
在google的分布式三驾马：

• gfs：解决分布式文件系统问题
• bigtable：分布式kv存储
• MapReduce：在分布式文件系统和分布式kv存储之上，如何做分布式计算和分析的问题。

这三驾马车的发布，基本上算是大数据时代的开始。在这基础之上，出现了各种各样的分布式产品，但是这部分产品更多的解决的都是系分领域的问题，比如Redis几乎都快成为了分布式缓存的代名词了。这部分产品有个好听的名字Nosql，但是问题是Nosql产品中，都没能支持关系型数据库的事务(redis的事务更多的是噱头，看起来更多的是个批量操作)。
强调一下，这里说的事务：它是一个并发控制单元，用户定义的操作序列。这些操作要么都做、要么都不做、是一个不可分割的工作单位。其目的就是让系统始终处于一个完整且正确的状态。
再次基础上，为其提供事务能力，构建分布式关系型数据库。这就是所谓的NewSql。
对newSql基本又是谷歌搞事情：

• F1
• Spanner

包括国货之光TiDB也是参考了Spanner的设计的。分布式关系型数据库使用的技术就非常的多，而且不同产品采用的架构是不一样的。对于分布式系统，架构风格可分为两种：

1. P2P。比如ElasticSearch
2. 分层架构。比如国货之光TiDB。

在分布式数据库中，不管是啥架构，一定会使用的量大技术：

1. 数据复制协议：paxos/raft
2. 原子性协议：2pc

一图说明这两个协议在分布式数据库中的作用：

在newsql中，就有很多有意思的技术了(很多不是在newsql中才有的，但是在newsql中同样的技术面临更多的挑战)

• 分片策略。除了hash分片。newsql更多的是支持动态range分片。这样能够以更小的粒度去调度数据 ，更加灵活，而newsql的中的众多优化都是依赖于这个数据调度能力的
  • hash分片：hash分片是对业务属性经过了hash计算的，所以已经抹去了业务特性了，所以更容易做到数据的均匀分布。但是正是由于抹去了数据特性，不太容易解决数据热点问题
  • range分片暴露了业务熟悉，且更容易实现分片调度。只是注意如果使用自增主键作为分区键，要注意尾部热点问题。

• paxos算法、raft算法。它们本质上都是一个数据复制算法。并不能保证数据的一致性。但是在分布式系统中，在使用paxos/raft算法的时候，都是配合上读写协议，来保证数据的操作一致性
  • CAP和ACID中都说了数据的一致性，但是这两个一致性说的不是一回事。和paxos/raft一起出现的一致性，其实是CAP里的一致性。
  • paxos一个共识算法，raft算法其实是multi-paxos思想下的一个算法协议。在分布式系统中，利用paxos算法干两件事：
    • leader选举：本质上就是利用paxos算法就谁是leader这个数据达成共识。提议发起者是集群中的follower，是存在多个follower同时发起提议的可能性的，那就可能因为都收不到大多数投票而失败。raft解决这个问题就是随机回退重试。
    • 日志复制(业务数据的写入)：就一个业务数据达成共识。提议发起者是leader，是唯一的。不需要paxos算法的准备阶段，也不会出现多个提议者同时发起提议而收不到多数投票的失败。

                    ps：这就是multi-paxos思想中为啥要搞个leader出来

• raft算法复制日志也是两阶段：当收到客户端写入请求的时候。首先是追加日志到本地，然后将日志推给其他Follower(rpc调用)，当收到大多数回复的时候，自己本地应用日志，返回给客户端写入成功，然后并且告诉Follower引用日志条目(有地地方称这个过程为提交)。很明显，从Leader收到客户端请求，落下日志条目后，到最终返回给客户端成功是有时间差的，这个时间差为啥不会读取到脏数据？(复制的是日志，不是数据，日志应用到复制状态机中，才会体现在数据更新上)

     ps：第二阶段，Leader只是自己本地应用了日志后，就返回成功了，岂不是Follower上的数据             会有不一致？(paoxs/raft算法是日志复制算法，不是保证数据一致性的，之所以使用了raft              算法 的分布式系统能够保证数据一致，是因为有读写策略的加持：比如读写都从Leader                  上、WRN(quorum)协议)等

• 2PC只是一个事务原子协议。并不是一个事务的银弹解决方案。依然存在问题：
  • 阻塞问题。
  • 事务管理器的单点问题
  • 事务悬挂问题
  • 数据潜在的不一致问题

         分布式事务模型：XA，在很早以前Innodb就支持了XA分布式事务模型，但是其性能和单机            事务的差距是10倍以上，所以基本上是没人使用的。

        Peculator事务模型，它对2PC做了工程优化，解决了2PC的部分问题，使得生产环境可使             用。国货之光的TiDB就是参考的这个事务模型实现的分布式事务。

• 数据组织方式
  • mysql是B+树
  • NewSQL采用的是LSM树。国货之光的TiDB、蚂蚁之光的OceanBase都是使用了LSM树(喜大普奔，ob开源了：https://www.oceanbase.com/docs/oceanbase-database/oceanbase-database/V3.2.1/system-architecture)。

             为什么抛弃B+树？LSM树真的是树么？

• 快照 vs mvcc
  • 快照和mvcc从概念上并不是同一个东西。
  • 在分布式数据库中，mvcc实现RR隔离界别的主要问题在于：全局的活动事务列表(mysql的快照读，也是基于一个 全局的活动事务列表的，why一定要要？ps：mysql的RC级别能够实现可重复读么？)

• db上云(DaaS)。db上云的挑战
• 部署架构。
  • spanner的目标是全球部署。但我们绝大部分公司都没有google这么叼，没那么多的全球业务。那么意义在哪儿呢？异地多活容灾。
  • 异地多活分为两部分：
    • 应用服务的异地多活，因为应用服务是无状态的，比较容易。
    • 所以重头戏就在有非常中的上线文依赖的数据层的异地多活。

                 异地多活是分布式的专利么?(不使用分布式数据库就搞不了异地多活？ 分布式数据库                    是数据存储领域的技术；异地多活是部署架构，没有本质的联系，只是说在使用传统单                  体数据库，做到异地还是ok的，但是要做到多活就有难度了，所以往往都只实现了缩水                  版：异地容灾)

• 两地三中心五副本：能够做到机房级的容灾；三地三中心五副本(三地五中心七副本)。why？(故障投票机制)。ps：这里的地、中心的区别是啥？(地就是城市，一般要求大于1000km，中心就是机房idc)
• 部署架构是容灾和效率的权衡游戏。两地三中心、三地五中心的挑战在哪里(多地部署距离和效率的权衡、全局时钟)

• OLTP和OLAP的
  • HTAP：大概的意思就是一个产品既能支持OLTP业务场景，又能支持OLAP场景
    • OLAP和OLTP的特点
    • 行列存储说的是什么？有什么特点？为什么说行式存储对cpu cache不友好？(数据的存储结构决定了数据访问的效率)
    • HTAP重点强调的是一个数据库系统，对外提供统一的数据服务。重点是统一的数据服务，这跟一套技术满足所有场景是完全不同的(这种追求银弹解决方案是病)。比如：TiDB，是提供了TiFlash，采用的就是列式存储来满足OLAP场景，不管是OLAP还是OLTP都是通过TiDB提供的统一的数据服务来访问数据，TiDB来搞定高低改用TiFlash还是TiKV，至少我们不用去搭建两套分别服务OLAP和OLTP。

• • Kappa
    • 为什么老说离线是T+1
    • 能不能做到实时同步，how。