OLTP

分布式TP数据库

• 短的读写操作
• small footprint
• 重复性的小操作

AP

• 超长语句，大部分only-read
• 有很多join
• 探索式的查询

主节点去查询问题：

• 节点不同意操作怎么办
• 消息延迟
• 不相等节点同意怎么办

列表：

• atomic commit protocols 原子化提交方案
• replication 副本
• consistency issues (CAP) CAP理论
• federated database 联邦数据库

atomic commit protocols

当一个多节点事务完成的时候，DBMS需要去告诉节点提交是不是安全的

使用技术：

• two-phase commit 2PC
• three-phase commit (not used)
• paxos
• raft
• ZAB (apache zookeeper)
• viewstamped replication

2PC:二阶段提交

用户将一个提交请求，发送给其中一个节点(coordinator)，协调员给其他节点(participant)发送一个提交请求，参与者同意就发送一个ok返回协调者，协调者发送commit命令，所有参与者ok之后给用户发送success

如果有一个节点告诉说不行，要回滚，协调者会直接通知用户要回滚，自己告诉参与者回滚

优化：

early acknowledgement

当请求被所有参与者都同意的时候，直接给用户发送提交成功，然后再进行commit操作

问题：

如果协调者崩溃了，参与者自己决定怎么办，一般是直接回滚

参与者崩溃了怎么办，协调者就会认为参与者不同意这个事务

PAXOS

共识机制，大部分都同意了，那么不同意的也要同意

propooser 提案者

acceptor 参与者

提案者发现大多数同意了，提案通过，发给参与者，参与者完成之后发给用户成功，对于宕机的就等到他没事时让其强制执行

多个事务：拒接旧的事务，同意新的事务

系统会选择一个单一的leader，为了防止提案人挂了，要轮换提案人

2PC不论有任何东西挂了，都不能提交

paxos只要不是大多数挂了，就能提交

replication 副本

数据不要放到一个节点上

• replica configuration 副本设置
• propagation scheme 数据传播的方案
• propagation timing 数据传播的时机
• update method 更新方案

replica configurations 副本配置

• primary-replica

一个机器是主，另几个机器是备，备用可以only-read，主可以做写操作

• multi-primary

多主，都可以读写操作，但是写操作要有方案处理

K-safety

保持多少副本量

同步给从的方案：

• synchronous 同步方案

强一致性方案，保证用户的数据在从的数据库都有了，才能告诉用户ok了，用户等待时间是比较长的

• asynchronous 异步方案

主库提交完成后直接发送给用户成功，然后给备库发送任务，当然会出现一些数据问题

折中一点，只要日志成功到备库上就告诉成功

propagation timing 数据传播时机

• continuous 持续不断的传播

但是回滚要主备一起回滚

• on commit

提交的时候传给备库，当然会有时间的开销

active & passive

• active-active

传播的日志是逻辑日志，传输的是sql指令

• active-passive

传播的是物理日志，传输的是数据

consistency（linearizablity 线性一致性） availability可用性 partition tolerant 分区容错性

consistency：

两个集群根据网络连接起来，将其同步，越弱的一致性， 数据同步越慢

availbility：

备库挂了，与备库近的用户可以访问其他备库或主库来实现高可用

partition tolerance：

集群机器没挂，网络挂了，就会出现双主库，当网络不中断就能最后确认是什么

传统的数据库当网络分区挂了之后，我们会下线数据库，牺牲了可用性来保证CP

nosql数据库会在重连之后梳理

如果一个数据库想搞不同的数据库在一起，就可以搞(federated databases联邦数据库)，当然不太好做，没有做的比较好的

数据库搞一个中间件给其他的不同数据库，postgreSQL可以连其他数据库

但是不考虑有骗子的情况