架构师训练营第 6 周总结:数据库分片,Hbase 和 ZooKeeper
数据库分片
数据库分片解决了什么问题?
当单个表的体积太大(比如淘宝或者微信的用户表),单个主机的数据库无法承载时,就需要数据分片,将单个表分散到多个主机的数据库进行存储。
数据库分片后,应用程序怎么访问呢?
在程序中硬编码实现数据分片。比如使用用户id字段来分片。id为奇数的分配到服务器1,id为偶数的分配到服务器2。硬编码方式不灵活,后续添加服务器不好维护。
映射表外部存储。新增一个映射表。程序先访问映射表,取得映射到的服务器,然后再访问服务器。映射表方式每次访问需要先访问映射表,然后再访问服务器。增加了访问次数,现实工作中用的不多。
数据库分片带来的问题
需要大量额外的代码,处理逻辑因此变得更加复杂
无法执行多分片的联合查询
无法使用数据库的事务
随着数据的增长,如何增加更多的服务器
为了解决上面这些问题,就出现了分布式数据库中间件。比如知名的数据库中间件是Mycat,其前身是Amoeba/Cobar。
Cobar如何做集群扩容
利用Mysql 的 schema 实现了集群的扩容
NoSQL
CAP原理
CAP原理说的是在分布式系统中,有三个指标。分别是Consistency(一致性)Availability (可用性)Partition tolerance (分区容错性),这三个指标不可能同时做到。
CAP原理与数据存储冲突
Cassandra 分布式解决方案
Cassandra通过投票解决冲突。假设Cassandra集群有三个节点。在写入时尝试写入三个节点,如果有至少2个节点返回成功,那就说明这次写入是成功的。在读取时,尝试从三个节点读取,等待有至少2个节点返回,取两个节点中的最新版本。
Hbase
Hbase的作用
Hbase是一个开源的分布式的非关系的数据库,使用Java开发,它可以在集群上托管非常大的表——数十亿行×数百万列,并对这些大数据表提供随机的,实时读/写访问。Hbase运行在HDFS(Hadoop分布式文件系统)之上。
Hbase的架构
Hbase的架构由ZooKeeper,HMaster,HRegionServer,HRegion,HDFS部分组成。下面分别介绍一下各个部分的作用
ZooKeeper
通过Zoopkeeper来保证集群中只有1个master在运行,如果master异常,会通过竞争机制产生新的master提供服务
通过Zoopkeeper来监控RegionServer的状态,当RegionSevrer有异常的时候,通过回调的形式通知Master RegionServer上下限的信息
通过Zoopkeeper存储元数据的统一入口地址
HMaster
为RegionServer分配Region
维护整个集群的负载均衡
维护集群的元数据信息发现失效的Region,并将失效的Region分配到正常的RegionServer上
当RegionSever失效的时候,协调对应Hlog的拆分
HRegionServer
管理master为其分配的Region
处理来自客户端的读写请求负责和底层HDFS的交互,存储数据到HDFS
负责Region变大以后的拆分
负责Storefile的合并工作
HDFS
HDFS为Hbase提供最终的底层数据存储服务,同时为Hbase提供高可用(Hlog存储在HDFS)的支持
提供元数据和表数据的底层分布式存储服务数据多副本
保证的高可靠和高可用性
Hbase 核心数据结构 Log Structed Merge Tree (LSM树)
贴一张网上找到的Hbase和Cassandra的对比
分布式系统脑裂
在一个分布式系统中,不同服务器获得了互相冲突的数据信息或者执行指令,导致整个集群陷入混乱,数据损坏,这种情况被称为分布式系统脑裂。
ZooKeeper
ZooKeeper 有什么用
根据ZooKeeper官网解释。ZooKeeper是一个集中服务,用于维护配置信息、命名、提供分布式同步和提供组服务。
简单点理解,使用ZooKeeper可以解决分布式系统脑裂的问题。
那么ZooKeeper为什么可以解决分布式系统脑裂的问题呢? 因为ZooKeeper的核心算法算法思想来自于分布式一致性算法Paxos。在Paxos算法的思想上,ZooKeeper开发了ZAB(ZooKeeper Atomic Broadcast 原子广播 )协议来解决布式系统的脑裂问题。
Paxos算法要解决的问题
在常见的分布式系统中,总会发生诸如机器宕机或网络异常(包括消息的延迟、丢失、重复、乱序,还有网络分区)等情况。Paxos算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中,快速且正确地在集群内部对某个数据的值达成一致,并且保证不论发生以上任何异常,都不会破坏整个系统的一致性。
作者:Jeffbond
链接:https://www.jianshu.com/p/d9d067a8a086
ZAB协议介绍
在 ZooKeeper 中,主要依赖 ZAB 协议来实现分布式数据一致性。ZAB协议包括两种基本的模式,分别是 崩溃恢复和消息广播。
崩溃恢复模式:当整个服务框架在启动过程中,或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时,ZAB 协议就会进人恢复模式并选举产生新的Leader服务器。
消息广播模式:当选举产生了新的 Leader 服务器,同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后,ZAB协议就会退出恢复模式,进入消息广播模式。
ZooKeeper 架构
上面的图是ZooKeeper官方提供的架构图。图中的每一个Server代表一个安装了ZooKeeper服务的服务器。组成ZooKeeper服务的服务器会在内存中维护当前服务器的状态,每台服务器之间会保持着通信,并通过ZAB协议来保持数据的一致性。
ZooKeeper集群中的服务器分为三种类型,Leader(领导者),Follower(跟随者),ObServer(观察者)。Leader只有一台,可以为客户端提供读写服务。Follower和ObServer有多台,只能为客户端提供读服务。Follower要参与Leader的选举过程,ObServer不参与选举。ObServer的目的是为了扩展系统,提高系统读取速度。
ZooKeeper API
ZooKeeper本身使用java开发,提供了java clent API,管理员和运维人员也可以通过命令行的方式对ZooKeeper进行管理。
评论 (1 条评论)