「架构师训练营」第 6 周总结

发布于: 22 小时前

分布式数据库

数据分片

大数据量增长到一定程度,超过了服务器能够承受的情况或造成数据的写入查询效率低效,从而考虑根据一定规则,将数据分布到不同的服务器存储。

硬编码实现数据分片

使用代码将分片key映射成服务器编号。

映射表外部存储

查询外部数据存储获取服务器编号。比硬编码灵活。

实践中运用并不多,多一次数据查询,也增加了程序复杂度。

分布式数据库中间件

应用程序像访问普通数据库一样访问数据库中间件。中间件分片等路由对应用程序透明。

Mycat原理

Mycat来源于Amoeba。

SQL解析模块负责解析SQL,找到是否存在分片字段。

SQL路由模块根据分片字段计算路由到哪个服务器。

集群的伸缩

实践中,Cobar 服务器利用 MySQL 的数据同步功能进行数据迁移。迁移是以 Schema 为单位。在 Cobar 集群初始化时,为每一个 MySQL 实例创建多个 Schema。

在扩容的时候,从每个服务器中迁移部分 Schema 到新服务器。因为迁移是以 Schema 为单位,所以迁移过程可以使用 MySQL 同步机制。

CAP原理

一致性: 每次读取的数据都应该是最近写入的数据或者返回一个错误,而不是过期数据。也就是说,数据是一致的。

可用性:每次请求都应该得到一个响应,而不是返回一个错误或者失去响应。(不过这个响应不需要保证数据是最近写入的)。

分区耐受性:即使因为网络原因,部分服务器节点之间消息丢失或者延迟了,系统依然是可操作的。

对于一个分布式系统而言,网络失效一定会发生,也就是说,分区耐受性是必须要保证到的,那么在可用性和一致性上就必须二选一。

CAP原理与数据一致性的冲突。要么选择可用但数据不一致,要么选择数据一致但不可用。

数据最终一致。

根据时间戳排序解决冲突。

投票解决冲突。

HBase架构

应用程序通过HMaster根据key路由到具体的HRegionServer,HRegionServer写入HFile。HFile通过Hadoop的HDFS文件系统进行文件的复制备份。

HMaster通过Zookeeper选举出来。

一致性较高。但当HRegionServer失效,key转移较慢,造成一定程度不可用。

访问过程:

ACID与BASE

ACID(关系型数据库)

  • 原子性(Atomicity) - 事务要么全部完成,要么全部取消。如果事务崩溃,状态回到事务之前(事务回滚)。

  • 隔离性(Isolation) - 如果两个事务T1、T2同时运行,事务T1和T2最终的结果是相同的,不管T1、T2谁先结束,隔离性主要依靠锁实现。

  • 持久性(Durability)- 一旦事务提交,不管发生什么(崩溃或出错),数据要保存在数据库中。

  • 一致性(Consistency) - 只有合法的数据(依照关系约束和函数约束)才能写入数据库。

BASE

  • 基本可用(Basically Available)系统在出现不可预知故障时,允许损失部分可用性,如响应时间上的损失或功能上的损失。

  • 弱状态(Soft state)软状态,指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在演示。

  • 最终一致性(Eventually consistent)指系统中所有的数据副本,在经过一段时间的同步后,最终能达到一个一致的状态。因此最终一致性的本质是需要系统保证数据能够达到一致,而不需要实时保证系统数据的强一致性。

Zookeeper

选master

集群管理

用户头像

guoguo 👻

关注

还未添加个人签名 2017.11.30 加入

还未添加个人简介

评论

发布
暂无评论
「架构师训练营」第 6 周总结