07 | 海量数据处理技术回顾:为什么分布式会遇到 CAP 难题?
李智慧
该思维导图由 AI 生成,仅供参考
你好,我是李智慧。
在这个模块的几个案例中,我们都需要处理海量的数据,需要用到海量的存储介质,其实海量数据本质上就是一种磁盘资源敏感的高并发场景。
我们说过,为了应对资源不足的问题,我们常采用水平伸缩,即分布式的方案。数据存储的分布式问题是所有分布式技术中最具挑战性的,因为相对于“无状态”(stateless)的计算逻辑(可执行程序),数据存储是“有状态”(stateful)的。无状态的计算逻辑可以在任何一台服务器执行而结果不会改变,但有状态的数据却意味着数据存储和计算资源的绑定:每一个数据都需要存储在特定的服务器上,如果再增加一台空的服务器,它没有数据,也就无法提供数据访问,无法实现伸缩。
数据存储的“有状态”特性还会带来其他问题:为了保证数据存储的可靠性,数据必须多备份存储,也就是说,同一个数据需要存储在多台服务器上。那么又如何保证多个备份的数据是一致的?
因此,海量数据存储的核心问题包括:如何利用分布式服务器集群实现海量数据的统一存储?如何正确选择服务器写入并读取数据?为了保证数据的高可用性,如何实现数据的多备份存储?数据多备份存储的时候,又如何保证数据的一致性?
为了解决这些问题,在这个模块的案例设计中,我们使用了多个典型的分布式存储技术方案:分布式文件系统 HDFS、分布式 NoSQL 数据库 HBase、分布式关系数据库。下面我们就来回顾这几个典型技术方案。你可以再重新审视一下,我们案例中的技术选型是否恰当,是否有改进的空间。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
海量数据处理技术中的分布式存储面临着CAP难题,即一致性、可用性和分区容错性的平衡问题。文章回顾了几种典型的分布式存储技术方案,包括HDFS、分布式关系数据库和HBase。HDFS作为分布式文件系统,在海量文件数据的存储和访问方面表现突出。分布式关系数据库通过数据分片存储解决了传统关系数据库的存储结构限制,提供了存储大量记录的能力。HBase作为NoSQL数据库,适用于存储非结构化数据。文章还介绍了ZooKeeper的数据一致性特点以及布隆过滤器在重复性检查中的应用。总的来说,这些分布式存储技术方案为海量数据的统一存储和高可用性提供了解决方案,但也带来了CAP难题等挑战,需要在实际应用中进行技术选型和改进。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《李智慧 · 高并发架构实战课》,新⼈⾸单¥59
《李智慧 · 高并发架构实战课》,新⼈⾸单¥59
立即购买
登录 后留言
全部留言(12)
- 最新
- 精选
- 阿卷普通的hash算法是通过数据与机器数取模运算来将数据映射到具体的节点,如果有机器加入和退出,则所有的数据都需要重新映射,这将会导致大量的数据迁移。 一致性hash就是用来解决这个问题的,一致性hash算法可以在加减节点时尽可能的保证现有的映射关系不变,从而减少数据迁移量。 大致的实现思路就是预先设置一个环形节点空间,比如环上预设1万个节点,将机器id通过hash算法对应到这个环上的具体节点,数据通过hash算法对应到环上的一个节点,然后沿着这个节点顺时针寻找离他最近的机器。这样当机器上下线时只会影响环上的部分数据。 但还有一个问题,就是一个机器下线后它负责的数据将全部由环中的下一个机器接管,而且当机器数比较少的时候必然造成大量数据集中到一个节点上面,为了解决这种数据倾斜问题,一致性哈希算法引入了虚拟节点机制,即对每一个服务节点计算多个哈希,每个计算结果位置都放置一个此服务节点,这样可以使数据分布更均匀
作者回复: 非常赞
2022-03-0227 - curry老师,布隆过滤器应该只能保证数据肯定不存在,并不能保证数据一定存在,就算八个比特位都匹配了,但是仍然有几率是其他数据占用的
作者回复: 是的,所以布隆过滤器的使用要看场景,能否接受误差,以及是否对误差有修正方案。 短URL中,如果布隆过滤器错误判定短URL重复,而实际并不重复,后果知识浪费几个短URL而已,完全可以接受。 网盘中,布隆过滤器判断重复后,还要到数据库中查找,不会造成错误。
2022-03-039 - 风华神使一致性哈希的目的是让存储节点数增减时数据少挪一些,比如ceph的crush
作者回复: 赞
2022-03-207 - peter请教老师一个问题: Q1:HBase图例中,Zookeeper是独立于HMaster的集群吗? 如果是独立的集群,zookeeper不了解HMaster的情况,根据什么来选主? 或者,另外一种情况是:Zookeeper和HMaster运行在同样的机器上,一台HMaster所在的机器上就有一个Zookeeper,这样zookeeper才能根据HMaster的情况选主;这种情况下,图例中的zookeeper只是逻辑上的独立集群。
作者回复: ZooKeeper是独立的,通常公司还有其他系统也要使用ZooKeeper,ZK是公司级共用的。 HMaster作为ZK的客户端需要和ZK通信,ZK是了解HMaster的,HMaster也要监听ZK的数据变化
2022-03-022 - Ronnie一致性哈希解决了哈希算法在增加服务节点时,需要更改数据路由算法逻辑的问题
作者回复: 赞
2022-03-03 - 👽一致性hash: 首先先说hash,就是为了把数据均匀分布到每一个节点上。根据数据的hash值,hash值再跟节点数了取余,就得出了节点编号。但是节点如果扩容,所有节点就需要重新将数据初始化。这是我们不愿意看到的。 于是乎,有了一种解决方案。这个节点数我们假设它很长,大部分文档都是在说2点32-1次方,但我觉得其实这个长度是多少其实不重要,但主要是说他很长。与这个长度取余,这个余数就是节点在这个环的位置。 现在,我们的数据进来了。我们把数据也跟这个长度取余,也得到了一个环的下标。但是因为环很长,实际节点数量肯定远远小于这个数量。那就等数据打进来了之后,按照顺时针找一个最近的节点。这时候,如果新增节点,则不需要重新hash取余,重新分布数据。新的数据寻找就近节点的时候会自动打到这个新节点上。 一致性hash的主要原理其实就说完了。 但还有问题,如果节点数量不够多,或者节点hash值分布不均匀,就会造成数据的分布不均匀。可以尝试引入虚拟节点,让虚拟节点分布的更均匀,然后虚拟节点再指向真实节点地址即可。
作者回复: 非常赞
2022-03-03 - 易企秀-郭彦超什么是cap讲了 为什么会有cap好像没讲
作者回复: 嗯,这部分内容文中讲的不明确,但其实是不断提及的,CAP的核心问题是源于数据分布式存储的一致性,多备份、海量数据存储的一致性几乎是无解的。
2022-03-02 - 超大超zookeeper数据以二阶段提交协议进行写入,实现的是最终一致性或顺序一致性。 1. 客户端访问zk进行数据写入时,不论访问到哪台机器都会转发到leader服务器。 2. leader服务器生成提案发送给follower服务器,如果follower可以写入则返回ACK响应,leader收到半数以上的ack响应,则发送commit给follower服务进行写入。 3. 在写入完成后leader向客户端响应写入成功后,可能有部分follower服务器写入失败的情况。 也就是有可能读取到的数据不是最新的, 可能是旧的数据。2022-04-192
- 雪碧心拔凉普通hash算法有一个痛点,即没增加/删除一个节点时,所有实例上的数据都会进行迁移,在数据迁移过程中,所有实例可能都暂时不可用。 一致性hash算法能保证只有附近一个节点需要迁移数据2022-05-17
- 雪碧心拔凉Zab协议能保证读取到的数据一定是正确的吗,如果正好读取的follow节点与其他节点网络分区,那是不是就访问到旧数据了?2022-05-17
收起评论