分布式理论

QuantumBroken

于 2021-09-25 17:01:12 发布

阅读量199

点赞数

分类专栏：分布式基础文章标签：数据库 big data

本文链接：https://blog.csdn.net/aajjw/article/details/119851671

版权

分布式基础专栏收录该内容

7 篇文章 0 订阅

订阅专栏

分布式系统

集中式

一台或多台计算机组成中心节点，数据集中存储在这个中心节点中，整个系统的所有业务集中部署在这个中心节点中，系统所有动能均由其集中处理。

什么是分布式系统

在分布式系统概念和设计一书中定义：分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此间仅通过消息传递进行通信和协调的系统

特性

分布性：每一台计算机分布在不同的地方
对等性：分布式系统中的计算机没有主/从之分，组成分布式系统的所有节点都是对等的。
并发性：同一个分布式系统的多个节点，可能会并发地操作一些共享的资源，诸如数据库或分布式存储。
缺乏全局时钟：既然各个计算机之间是依赖于交换信息来进行相互通信，很难定义两件事件的先后顺序，缺乏全局时钟控制序列
故障总会发生：组成分布式的计算机，都有可能在某一时刻突然间崩掉。分的计算机越多，可能崩掉一个的几率就越大。如果再考虑到设计程序时的异常故障，也会加大故障的概率。

为什么需要分布式

单机处理能力的瓶颈以及性价比
为了通过隔离(isolation)实现安全性，部分节点失效不影响整体服务
为了通过复制(replication)实现容错，部分节点错误不影响整体服务

难点

并发问题
处理部分节点失败
难以实现性能潜力

模型

节点

节点是分布式系统中完整的不可分割的整体。一个节点往往是一个操作系统中的进程，但是如果一个进程是由若干个相对独立的部分构成，则是多个节点。

通信

节点与节点之间完全独立，相互隔离，节点间通过不可靠的网络进行通信。

存储

节点可以将数据存储在本机的磁盘上。存储和读取数据的节点的称为有状态节点，反之为无状态节点。

问题

节点故障。分布式系统节点众多，出现故障的概率就会增加，相反整体不可用的概率会减少。
通信异常。分布式系统与单机多核系统的显著不同在于通信的不可靠。
1. 网络分区是通信异常的一个特例，常见于不同机房间的通讯中断
2. 超时：三态：成功、失败和超时
  1. 请求方应对超时的办法就是重发
  2. 接收方应对重发的办法是幂等
3. 网络通信的可靠性。TCP 协议保证了 TCP 协议栈之间的可靠的传输，但无法保证两个上层应用之间的可靠通信。

数据一致性

数据在多份副本中存储时，各副本中的数据是一致的。

数据一致性模型或者分级的意义。

分级

强一致性

任何时刻任何用户或节点都可以读到最近一次成功更新的副本数据。
对程序员更加友好，使得程序员可以像一份数据一样使用。
但是对于系统来说很难实现（设计复杂度，系统的效率与CAP约束等）。
一种实现的方式是给数据增加版本号。

弱一致性

单调一致性

任何时刻，任何用户一旦读到某个数据在某次更新后的值，这个用户不会再读到比这个值更旧的值。
单调一致性是弱于强一致性却非常实用的一种一致性级别。因为通常来说，用户只关心从己方视角观察到的一致性，而不会关注其他用户的一致性情况。

会话一致性

任何用户在某一次会话内一旦读到某个数据在某次更新后的值，这个用户在这次会话过程中不会再读到比这个值更旧的值。
话一致性通过引入会话的概念，在单调一致性的基础上进一步放松约束，会话一致性只保证单个用户单次会话内数据的单调修改，对于不同用户间的一致性和同一用户不同会话间的一致性没有保障。

最终一致性

在一段时间后，节点间的数据会最终达到一致状态。

指标

性能指标

系统吞吐能力：系统每秒处理的数据量
系统响应延迟：系统完成某一功能需要的时间
系统的的并发能力：QPS或者TPS

可用性/可靠性

通常使用系统停服务的时间与正常服务的时间的比例来衡量

扩展性

系统的可扩展性(scalability)指分布式系统通过扩展集群机器规模提高系统性能（吞吐、延迟、
并发）、存储容量、计算能力的特性。
可扩展性是分布式系统的特有性质。分布式系统的设计初衷就是利用集群多机的能力处理单机无法解决的问题。好的分布式系统总在追求“线性扩展性”，也就是使得系统的某一指标可以随着集群中的机器数量线性增长。

一致性

分布式系统为了提高可用性，总是不可避免的使用副本的机制，从而引发副本一致性的问题。
根据具体的业务需求的不同，分布式系统总是提供某种一致性模型，并基于此模型提供具体的服务。
越是强的一致的性模型，对于用户使用来说使用起来越简单。例如通常我们总是希望某次更新后可以立刻读到最新的修改，如果成功更新后的数据依旧有可能不一致读到旧数据，那么用户就需要在写入数据时加入序列号等信息，并在读取数据时首先自行实现过滤去重后再使用数据

数据的分布方式

Hash方式

类似Hash表的方式将数据分散到不同的节点上
问题
- 数据倾斜
  - 更好key，更好的hash函数
  - 1
- 扩展性
  - 2倍扩展

数据范围

一致性Hash

hash环
- 一致性哈希的优点在于可以任意动态添加、删除节点，每次添加、删除一个节点仅影响一致性哈希环上相邻的节点
- 数据倾斜-》虚节点
- 扩容？

数据副本与数据分布

按机器
按数据段

数据副本协议

中心化副本协议

中心化副本控制协议的基本思路是由一个中心节点协调副本数据的更新、维护副本之间的一致性。
中心化副本控制协议的优点是协议相对较为简单，所有的副本相关的控制交由中心节点完成。
中心化副本控制协议的缺点是系统的可用性依赖于中心化节点，当中心节点异常或与中心节点通信中断时，系统将失去某些服务（通常至少失去更新服务），所以中心化副本控制协议的缺点正是存在一定的停服务时间。

primary-secondary 协议或者 primary-backup 协议

其中有且仅有一个副本作为 primary 副本，负责维护数据的更新、并发控制、协调副本的一致性。

数据更新基本流程

数据更新都由 primary 节点协调完成。
外部节点将更新操作发给 primary 节点
primary 节点进行并发控制即确定并发更新操作的先后顺序
primary 节点将更新操作发送给 secondary 节点
primary 根据 secondary 节点的完成情况决定更新是否成功并将结果返回外部节点

数据读取方式

如果只需要最终一致性，则读取任何副本都可以满足需求。
如果需要会话一致性，则可以为副本设置版本号，每次更新后递增版本号，用户读取副本时验证版本号，从而
保证用户读到的数据在会话范围内单调递增。
强一致性
- 只读primary上的数据，按数据段分布在不同的机器上，每台机器都提供了读写服务，这样其实相当于主备模式，主写主读，再做数据段拆分。
- primary 控制节点 secondary 节点的可用性，即是否可读。基本不可行呀！以数据节点或数据段为维度标记节点可用性，每次更新数据都会标记节点可用性，每次查询都需要查一次节点可用性，节点可用性数据存在哪里也是问题，单点存又会有单点问题，分布式存又回来了。
- Quorum机制

primary 副本的确定

数据同步

需要同步的场景
- 网络分化导致
- 新增副本
- 在某些协议下， secondary 上的数据有可能是脏数据，需要被丢弃。所谓脏数据是由于primary 副本没有进行某一更新操作，而 secondary 副本上反而进行的多余的修改操作，从而造成secondary 副本数据错误。
同步的方法
- 部分同步
- 全量同步
- 操作日志，记录的每次修改过程，体积大，恢复慢，顺序严格
  - 回放操作日志，redo日志。
  - 脏数据，最好不要有脏数据，如果有，一是直接丢弃，二是undo日志
- 快照，记录的是某个时点的结果
  - 体积小，恢复快，无顺序
  - 但是primary 副本需要支持快照(snapshot)功能

去中心化副本控制协议

Lease（租约）机制

背景

一个中心服务器节点存储、维护着系统的元数据。
其他的节点通过访问中心服务器节点读取、修改其上的元数据。
其他的节点上cache元数据信息，从而减少对中心服务器节点的访问，提高性能。
要求各个节点上 cache 的数据始终与中心服务器上的数据一致， cache中的数据不能是旧的脏数据。
系统要能最大可能的处理节点宕机、网络中断等异常，最大程度的提高系统的可用性。

原理模型

中心服务器在向各节点发送数据时同时向节点颁发一个 lease。lease中通常是一个明确的过期时间点。
在 lease 的有效期内，中心服务器保证不会修改对应数据的值。
中心服务器在修改数据时，首先阻塞所有新的读请求，并等待之前为该数据发出的所有lease 超时过期，然后修改数据的值。

优缺点及问题

优秀的容错能力。
- 网络异常，颁发者单向通信即可，之后不依赖网络通信。
- 宕机恢复，无数据存储只需等一个lease周期即可。有数据存储在原节点重启则直接恢复。
缺点
- 依赖时钟，将颁发者的有效期设置的比接受者大，大过时钟误差即可。
- 单点问题。zk中怎样处理的？？？
有效期：一般是10秒

Quorum

背景

更新操作（write）是一系列顺序的过程，
通过其他机制确定更新操作的顺序（例如 primary-secondary 架构中由 primary 决定顺序）
每个更新操作记为 wi，i 为更新操作单调递增的序号
每个 wi执行成功后副本数据都发生变化，称为不同的数据版本，记作 vi。
一共有n个副本

WARO

Write-all-read-one。更新时写所有的副本，只有在所有的副本上更新成功，才认为更新成功，从而保证所有的副本一致，这样在读取数据时可以读任一副本上的数据。

可用性：更新服务可用性低。读取服务的可用性高。

假设有一种 magic 的机制，当某次更新操作 wi一旦在所有 N 个副本上都成功，此时全局都能知道这个信息，此后读取操作将指定读取数据版本为 vi的数据，称在所有 N 个副本上都成功的更新操作为“成功提交的更新操作”，称对应的数据为“成功提交的数据”。在 WARO 中，如果某次更新操作 wi在某个副本上失败，此时该副本的最新的数据只有 vi-1，由于不满足在所有 N 个副本上都成功，则 wi 不是一个“成功提交的更新操作”，此时，虽然其他 N-1 个副本上最新的数据是 vi，但 vi不是一个“成功提交的数据”，最新的成功提交的数据只是 vi-1 。

在工程实践中，这种 magic 的机制往往较难实现或效率较低。通常实现这种 magic 机制的方式就是将版本号信息存放到某个或某组元数据服务器上。假如更新操作非常频繁，那么记录更新成功的版本号 vi的操作将成为一个关键操作，容易成为瓶颈。另外，为了实现强一致性，在读取数据的前必须首先读取元数据中的版本号，在大压力下也容易因为元数据服务器的性能造成瓶颈。

Quorum

Quorum是读写服务的折中。

W+R>N
W：当写操作在W个副本上成功，则成功
R：读取R个副本一定会读到最新的版本

仅靠Quorum无法实现强一致性，因为无法知道最新的版本。

不引入其他机制。则需要W超过半数，我们读取超过半数的版本才是最新的版本，最差需要读取N个副本，同时在读取过程中，若存在数据更新，则可能会导致无法判断最新的版本。
因此需要引入其他机制判断副本状态，如结合primary-secondary，使用primary读取最新已提交的数据。

primary+Quorum

primary更新时，只需要更新W个成功，即可认为成功。
读取时，看数据一致性级别。
- 强一致性：
  - 只读primary
- 会话一致性：版本号
- 弱一致性：任意副本读
选主：通常情况下，选择新的 primary 的工作是由某一中心节点完成的，在引入quorum 机制后，常用的 primary 选择方式与读取数据的方式类似，即中心节点读取 R 个副本，选择R 个副本中版本号最高的副本作为新的 primary。新 primary 与至少 W 个副本完成数据同步后作为新的 primary 提供读写服务。首先， R 个副本中版本号最高的副本一定蕴含了最新的成功提交的数据。再者，虽然不能确定最高版本号的数是一个成功提交的数据，但新的 primary 在随后与 secondary 同步数据，使得该版本的副本个数达到 W，从而使得该版本的数据成为成功提交的数据。

Paxos

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ux5bPy7R-1629610268745)(C:\Users\DY\AppData\Roaming\Typora\typora-user-images\image-20210808173857433.png)]

概念

节点
- Proposer：提案者发起题案Proposal
- Acceptor: 决策者，可以批准提案或者拒绝提案
- Learner: 最终决策的学习者，从Proposers/Acceptors学习最新达成一致的提案（Value）。
提案：Proposal，提案包括Proposal ID和Value，如果多数决策者批准了提案，则提案通过。
过程
- Prepare：
  - Proposer向Acceptors发出Prepare请求，
  - Acceptors针对收到的Prepare请求进行Promise承诺。
- Accept：
  - Proposer收到多数Acceptors承诺的Promise后，向Acceptors发出Propose请求，
  - Acceptors针对收到的Propose请求进行Accept处理。
- Learn：Proposer在收到多数Acceptors的Accept之后，标志着本次Accept成功，决议形成，将形成的决议发送给所有Learners。
详细设计
- Proposers
  - set（value）
    - 客户端调用的设置value的方法，value可以是一个复杂对象，如（key：value）这种。
    - 生成全局唯一且递增的Proposal ID，向Acceptors发出Prepare请求
    - 如果返回的Proposal ID大于本id，则失败，发起返回的Proposal ID+1的提案
    - 收到多数Acceptors承诺的Promise后，向Acceptors发出Propose请求
- Acceptors
  - var maxAcceptedProposalId
  - prepare（id）
    - maxAcceptedProposalId=Max（id，maxAcceptedProposalId）
    - return (maxAcceptedProposalId, value)
  - accept（id，value）
    - if id>=maxAcceptedProposalId
      - 接收这个value
    - else
      - retrun maxAcceptedProposalId+value

为了保证 proposal_Id 能够保持递增且唯一，有两种实现方法：

RoundNumber + ServerId：因为算法可能需要多次循环才可以最终选定 value，因此每个 Server 都必须持久化保存它所见过的最大的轮次数，这样保证 id 递增，再连接 ServerId 保证唯一性。RoundNumber需要持久化保存，以保证宕机后也能快速恢复
TimeStamp + ServerId：使用系统TimeStamp + ServerId也可以保证递增性和唯一性，但是需要注意保证系统时间的一致

协议推导

Paxos协议的目标是：在一次 Paxos 算法实例过程中只批准一个 Value

协议推导是因为我们的目标在工程上不易直接实现，直到我们找到在工程易于实现的充分不必要条件。

在一次 Paxos 算法实例过程中只批准一个 Value
一旦一个 value 获得超过半数的 Acceptor 批准，之后 Paxos 协议只能批准这个 value
一旦一个 value获得超过半数的 Acceptor 批准，之后任何 Acceptor只能批准这个 value
一旦一个 value v 获得超过半数的 Acceptor 批准，之后 Proposer 提议的 value 只能是 v
Proposer提议一个 value v 前，要么之前没有任何一个 value 被批准，要么存在一个大小为 N/2+1 的 Acceptor集合，这个集合内的各个 Acceptor 批准过的轮数最大的 value 是 v。

P1 . 一个Acceptor必须通过(accept)它收到的第一个提案。

P2.如果具有value值v的提案被选定(chosen)了，那么所有比它编号更高的被选定的提案的value值也必须是v。

P2a. 如果具有value值v的提案被选定(chosen)了，那么所有比它编号更高的被acceptor通过的提案的value值也必须是v

P2b.如果具有value值v的提案被选定，那么所有比它编号更高的被proposer提出的提案的value值也必须是v

一个提案被acceptor通过之前肯定要由某个proposer提出，因此P2b就隐含了P2a，进而隐含了P2。

P2c.对于任意的n和v，如果编号为n和value值为v的提案被提出，那么肯定存在一个由半数以上的acceptor组成的集合S，可以满足条件a)或者b)中的一个：

a)S中不存在任何的acceptor通过过编号小于n的提案

b)v是S中所有acceptor通过的编号小于n的具有最大编号的提案的value值。

概念:

每个Proposer都可以提案
提案包括id和value
id即是proposal_Id,round_num全局唯一且单调递增
value就是命令

过程

Proposer向Acceptors发出Prepare请求，
Acceptors针对收到的Prepare请求进行Promise承诺。
Accept：
- Proposer收到多数Acceptors承诺的Promise后，向Acceptors发出Propose请求，
- Acceptors针对收到的Propose请求进行Accept处理。

Acceptors

var lastPrepareProposalId=null
var lastAcceptedProposalId=null
var lastValue=null
prepare（id）
- lastPrepareProposalId = max(id, lastPrepareProposalId)
- return (lastPrepareProposalId, lastAcceptedProposalId, value)
- if lastPrepareProposalId>id
  - return (lastPrepareProposalId, lastAcceptedProposalId, value)
- if lastPrepareProposalId<=id
  - lastPrepareProposalId=id
  - return (lastPrepareProposalId, lastAcceptedProposalId, value)
accept（id，value）
- if id>=maxAcceptedProposalId
  - value
- else
  - retrun maxAcceptedProposalId+value

Proposer

生成id
(lastPrepareProposalId, lastAcceptedProposalId, value) = prepare（id）
if

CAP

CAP的前提

CAP 本身基于状态，基于瞬态，是一个描述性的理论，它并不解决工程问题。
CAP 舍弃很多现实世界的现实问题。比如网络的时长，比如节点内部的处理速度不一致，比如节点间存储方式和速度的不一致。

CPA

如果在一个不稳定（消息要么乱序要么丢了）的网络环境里（分布式异步模型），想始终保持数据一致是不可能的。在分布式系统里，需要妥协。
C：Consistency，一致性就是客户端是否能拿到最新数据
- 所有节点访问时都是同一份最新的数据副本，使用读来检查写入的情况
- 这里的一致性和事务的一致性有所不同，这里只关注是否能读到最新写入的数据
A：Availability，可用性就是允许客户端拿不到最新数据
- 每次请求都能获取到非错的响应，但是不保证获取的数据为最新数据
- 这里关注的是两个点，一个是有限的时间即用户需要的时间，一个是返回结果但不一定是最新的
P：Partition tolerance，分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障
对于一致性表述？？？
CAP不是boolean而是范围，CP系统不是放弃了A而是降低了A。比如ZK只有master失效的很短的时间内才不能响应请求。
CAP在一个大的分布式系统下的每个部分可以有不同的权衡，比如商品信息可以AP，而支付CP。
CAP的权衡
- 分布式系统必选P，因为CA的系统，要保证C必须禁止写入，也就不能实现A了，所以就成了单点的系统了。
- 互联网的典型场景下，需要很强的可用性，可以牺牲一定的一致性，比如客户访问淘宝主页，可能看到的不是最新的商品，但是一定要快。
- 支付场景下的账户操作，对于一致性一定要高，否则转入转出后，用户需要立刻查到账户的变动

BASE

base是什么

基于 CAP 定理，对一致性和可用性权衡的结果，是对大型互联网分布式实践的总结。
既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
BA：Basically Available，基本可用。CAP中Availability说的时再有限时间内拿到返回结果。Basically Available正常情况下可以做到，异常时可能会导致返回时间变长或者功能缺失的结果。
S：Soft state，软状态。软状态指的是允许系统中数据存在中间状态即多个数据副本间的数据延时，认为不影响系统的可用性。
E：Eventually consistent，最终一致性。

分布式事务

事务

事务是由一系列的对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元，狭义上的事务特指数据库事务。
四个特征
- 原子性
- 一致性
- 隔离性
- 持久性

2PC

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qfDqM8LX-1629610268748)(C:\Users\DY\AppData\Roaming\Typora\typora-user-images\image-20210822000441117.png)]

优点
原理简单
缺点
- 同步阻塞
  在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，即当参与者占有公共资源时，其他节点访问公共资源会处于阻塞状态
- 单点问题
  若协调器出现问题，那么整个二阶段提交流程将无法运转，若协调者是在阶段二中出现问题时，那么其他参与者将会一直处于锁定事务资源的状态中，而无法继续完成事务操作
- 数据不一致
  在阶段二中，执行事务提交的时候，当协调者向所有的参与者发送Commit请求之后，发生了局部网络异常或者是协调者在尚未发送完Commit请求之前自身发生了崩溃，导致最终只有部分参与者收到了Commit请求，于是会出现数据不一致的现象。
- 太过保守
  在进行事务提交询问的过程中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，此时协调者只能依靠自身的超时机制来判断是否需要中断事务，这样的策略过于保守，即没有完善的容错机制，任意一个结点的失败都会导致整个事务的失败。

3PC

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HjHz1NAj-1629610268749)(C:\Users\DY\AppData\Roaming\Typora\typora-user-images\image-20210822001137760.png)]

对比2PC的改进
- 降低参与者的阻塞范围，单点故障后可以继续达成一致
问题
- 并没有彻底解决数据不一致的问题，在pre-commmit阶段中，协调者参与者接受到preCommit后分区，会提交事务，而其他节点不会提交。

分布式数据一致性协议

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dBeaRiB9-1629610268751)(C:\Users\DY\AppData\Roaming\Typora\typora-user-images\image-20210822002612047.png)]

paxos

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NkPJnS4y-1629610268752)(C:\Users\DY\AppData\Roaming\Typora\typora-user-images\image-20210808173857433.png)]

gossip

Gossip 是一种去中心化的分布式协议，数据通过节点像病毒一样逐个传播。因为是指数级传播，整体传播速度非常快。
- 优点
  - 扩展性：允许节点的任意增加和减少，新增节点的状态最终会与其他节点一致
  - 容错：任意节点的宕机和重启都不会影响 Gossip 消息的传播，具有天然的分布式系统容错特
    性
  - 去中心化：无需中心节点，所有节点都是对等的，任意节点无需知道整个网络状况，只要网络
    连通，任意节点可把消息散播到全网
  - 最终一致性：Gossip 协议实现信息指数级的快速传播，因此在有新信息需要传播时，消息可
    以快速地发送到全局节点，在有限的时间内能够做到所有节点都拥有最新的数据。
- 缺点
  - 消息延迟:节点随机向少数几个节点发送消息，消息最终是通过多个轮次的散播而到达全网；
    不可避免的造成消息延迟。
  - 消息冗余:节点定期随机选择周围节点发送消息，而收到消息的节点也会重复该步骤；不可避
    免的引起同一节点消息多次接收，增加消息处理压力
Gossip 协议由于以上的优缺点，所以适合于 AP 场景的数据一致性处理，常见应用有：P2P 网络通信、
Redis Cluster、Consul。

totem

数据库的演化

传统关系型数据库
- 问题：单机处理瓶颈，单表千万级数据量，或者磁盘，CPU，IO的瓶颈。
- 解决思路：单体->分库分表，都是在关系性数据上进行代理
- 实现：分库分表中间件
  - mycat：大体是服务端代理的模式，使用mysql等数据库做存储，主要实现了分库分表
  - ShardingSphere：
    
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FDOLnGdG-1629610268753)(C:\Users\DY\AppData\Roaming\Typora\typora-user-images\image-20210822010700572.png)]
    
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fkqGOjQ6-1629610268754)(C:\Users\DY\AppData\Roaming\Typora\typora-user-images\image-20210822010755539.png)]
Nosql：Not only Sql，放弃ACID，拥抱分布式，主要解决快速响应和海量数据存储的问题。
newSql：
- 不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性。
TiDB：newSql
- 开源分布式关系型数据库
- 具备水平扩容或者缩容
- 金融级高可用
- 同时支持在线事务处理与在线分析处理HTAP
- 兼容 MySQL 5.7 协议和 MySQL 生态等重要特性
- 技术其他特性
  - 副本间使用raft协议保证一致性
  - MVVC实现隔离级别
- 架构
  - TiDB Server：SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。
  - PD (Placement Driver) Server：整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑”。此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。
  - 存储节点
    - TiKV Server：负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 的 API 在 KV 键值对层面提供对分布式事务的原生支持，默认提供了 SI (Snapshot Isolation) 的隔离级别，这也是 TiDB 在 SQL 层面支持分布式事务的核心。TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 TiKV API 的实际调用。所以，数据都存储在 TiKV 中。另外，TiKV 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。
    - TiFlash：TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。
OLTP和OLAP
- OLTP做事务处理，写入，对应数据库应用
- OLAP做分析处理，查询，对应数据仓库应用
- HTAP同时支持在线事务处理与在线分析处理
  
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-J7cABV2W-1629610268755)(C:\Users\DY\AppData\Roaming\Typora\typora-user-images\image-20210822011637785.png)]

词汇

trade-off：(在需要而又相互对立的两者间的)权衡，协调;常见的就是数据库设计中的三范式和冗余

QuantumBroken

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分布式理论

分布式系统集中式一台或多台计算机组成中心节点，数据集中存储在这个中心节点中，整个系统的所有业务集中部署在这个中心节点中，系统所有动能均由其集中处理。什么是分布式系统在分布式系统概念和设计一书中定义：分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此间仅通过消息传递进行通信和协调的系统特性分布性：每一台计算机分布在不同的地方对等性：分布式系统中的计算机没有主/从之分，组成分布式系统的所有节点都是对等的。并发性：同一个分布式系统的多个节点，可能会并发地操作一些共享的资源，诸如
复制链接

扫一扫