第 6 周 - 总结

发布于: 20 小时前

分布式数据库

众所周知,传统数据库即便是“主 - 主”复制,依旧无法做到多库同时写入,而且磁盘IO是所有设备中读写最慢的设备,如果所有的业务都由一个数据库负责写入,压力可想而知。

业务分库

解决数据写入压力的办法就是将分布式系统按照业务领域进行拆分,业务各自建立自己的数据库,不同业务通过远程调用互联通信,也就是所谓的业务垂直拆分。

分表

然而分库并不能解决大表的问题,需要继续将大表按照某一维度进行数据分片,每个数据段分别存储在不同的schema中,每个schema存放在不同的数据库中,来分担数据压力。通常对表的操作交由像Mycat这样的中间件进行数据的访问路由。

CAP 原理

CAP中的C指的是一致性,A指的是可用性,P指的是分区容忍性,且任何系统都只能在C、A、P中选择三者中的两个,也就是不存在同时满足一致性、可用性、分区容忍性的系统。

  • CP : 当系统选择一致性、分区容忍组合时,一旦数据发生分区,操作没法立即同步到数据,只好回滚操作,系统处于不可用(牺牲了可用性)。

  • AP: 当系统选择可用性、分区容忍性时,当网络发生故障产生数据分区,系统操作为了达到系统可用,必须对外响应操作处于某软状态中,此时系统牺牲了一致性。

  • CA: 要达到一致性和可用性,此时数据是不容许产生分区的,这就好比单机模式中的本地事务。

总结:在分布式系统中,网络不可用是无法避免的问题,因此分布式系统应该容忍分区,而有C和A中作出选择,也就是CP或AP。

ACID与BASE

  • 严格的ACID

  • 原子性(Atomicity)

  • 事务要嘛全部成功,要嘛全部取消,如果事务奔溃,状态回到事务之前。

  • 隔离性(Isolation)

  • 隔离级别

  • 读未提交

  • 读已提交

  • 可重复读

  • 事务内,数据只存在一个版本,不会随外部事务的提交而变更。

  • 串行读

  • 冲突时锁定,等先拿到锁的事务提交或回滚方可读写数据。

  • 持久性(Durability)

  • 持久性是指一个事务一旦被提交,它对数据库中数据的改变就是永久性的,接下来即使数据库发生故障也不应该对其有任何影响

  • 一致性(Consistency)

  • 事务前后数据的完整性必须保持一致

  • BASE

  • Basically Available(基本可用)

允许损失部份可用性,如响应时间上的缺失或功能上的损失。

  • Soft State(弱状态)软状态

不同于原子性,允许数据存在中间状态,并认为中间状态不会响应系统的整体可用性,允许数据副本之间同步存在延时。

  • Eventually consistent (最终一致性)

系统保证数据能够最终一致,而不需要系统保证数据实时的强一致性。

分布式协调 Zookeeper

树型目录数据存储结构+数据变更事件监听

  • 打铁还在自身硬,ZK选主

作为协调者,ZK自身通过选主算法选出LEADER

  • 分布式一致性算法角色:

  • Proposer

  • Acceptor

  • Leaner

用户头像

Dawn

关注

还未添加个人签名 2018.07.04 加入

还未添加个人简介

评论

发布
暂无评论
第6周-总结