架构师训练营总结 -6

用户头像
River Tree
关注
发布于: 2020 年 07 月 15 日

日期

0711

总结开始

1. 一致性HASH

啥是一致性HASH?

为了解决分布式缓存集群中,当集群服务器扩容时,数据访问不一致的问题。(为何不一致?传统的余数hash,加机器会导致除数变化,产生整个数据访问不一致,会导致缓存雪崩)

如何实现?

先建立一个2^32大的一个环,将服务器的节点的若干个虚拟节点的hash值放到环上,然后将要计算的key的值的hash值也放到环上,沿着环顺时针查找,离它最近的服务器的节点就是

2. 数据分片

啥是数据分片?

当数据量过大,超过单库单张表的存储能力或者写入能力时,将一张表拆分成若干片,写入到多个服务器,降低单个服务器上该表的存储能力和写入能力

分片的实现方式?

2.1 硬编码方式

应用层根据分区键来判断分片位置

2.2 映射表方式

在映射表中记录分区键与服务器的映射关系

2.3 分布式数据库中间件(常用的中间件是Mycat)



MyCat分布式数据库中间件的核心模块是SQL解析模块、SQL路由模块、结果集合并模块

2.3.1 SQL解析模块:将SQL脚本解析为语法树,取出分库键的数据

2.3.2 SQL路由模块:将分区键按路由规则判断(余数哈希),判断该键值的数据落在哪个库(注意,这里是哪个库而不是哪个服务器,对后续的增加新服务器时数据迁移动作有帮助)

2.3.3 结果合并模块:SQL查询的数据可能来自于在不同的库上,将多个库返回的数据合并成一个结果集

2.3.4 扩增服务器时,如何保证数据迁移后数据访问与原来一致?

目前mycat分片是采用的余数哈希的规则,当增加服务器节点时除数改变,如果要保持数据访问一致性,需要将原有分片中的数据进行大规模的迁移,复杂且风险大。

解决方案:采用预先分库的方案,事先将数据按需分成多个库,比如有三台主机预先分12个库,每台主机上存放4个库。当新增服务器节点时,只需要将部分库整体迁移到新的服务器,形成每台主机3个库的效果,对整体库进行迁移比将库中的部分数据迁移要简单的多。迁移完成后,将路由配置文件中库与主机的映射关系,切换到新服务器修改即可。



当数据迁移时,应用同时在访问数据库,此时不迁移到新库,同步的速度大于应用写入的速度,当数据迁移完成后,切换到新的服务器上。

3. CAP原理

C:Consistency 一致性,每次读取的数据应该是最近一次写入的数据或者错误,而不是过期的数据

A:Availability 可用性,每次请求都应该得到一个响应,而不是返回一个错误或者无响应,不过这个响应不要求是最近一次写入的

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

如何理解CAP原理:

CAP中的P相关的问题(网络分区失效)是一定会发生的,所以P是一定要保证的,但是可用性和一致性是互斥的关系,是无法同时满足的。

当网络分区失效发生时,要么取消操作,保证一致性,但是系统就不可用了;要么继续写入数据,但是数据的一致性无法保证。

当网络分区失效(网络不可用时)发生时,如果选择了一致性,系统就可能返回一个错误码或者超时,系统不可用。如果选择了可用性,系统总是可以返回一个数据,但是不能保证数据是最新的。

CAP原理,准确的说法是,在分布式系统必须满足分区耐受性的前提下,可用性和一致性无法同时满足。



目前大部分分布式系统保证的是AP同时保证最终一致性,最终一致性一般有以下几种方案来解决一致性冲突:

最终一致写冲突:记录时间戳,当数据在不同节点间扩散时,按照时间先后顺序覆盖最新的结果。

客户端冲突解决:比如在不同的节点上操作购物车,可以采用合并的方法,数据扩散时将所有节点的数据合并在一起。

投票解决冲突(Cassandra):写数据时,向所有节点写数据,等待多数节点写入成功。当读取数据时,以返回相同数据的节点数多的为准。

4. HBASE架构

总结结束



发布于: 2020 年 07 月 15 日 阅读数: 21
用户头像

River Tree

关注

还未添加个人签名 2019.02.25 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营总结 -6