解决持久化数据太大,单个节点的硬盘无法存储的问题;解决运算量太大,单个节点的内存、CPU无法处理的问题
2017-06-06 15:11
357 查看
需要学习的技术很多,要自学新知识也不是一件容易的事,选择一个自己比较感兴趣的会是一个比较好的开端,于是,打算学一学分布式系统。
带着问题,有目的的学习,先了解整体架构,在深入感兴趣的细节,这是我的计划。
首先得有问题,如果每日重复相同的工作,也不主动去学习,很难发现新的问题。不怕自己无知,就怕不知道自己无知,只有不断的学习,才会发现更多未知的知识领域!
分布式要解决什么问题呢?解决持久化数据太大,单个节点的硬盘无法存储的问题;解决运算量太大,单个节点的内存、CPU无法处理的问题。解决这些问题,有两种思路:scale up,scale out。前者就是提升单个节点的能力,更大的磁盘,更快的CPU,定制的软硬件,然而这意味着更高的价格,而且再怎么scaleup 也是有上限的。后者就是把存储、计算任务分担到普通的机器上,通过动态增加节点来应对数据量的增长,但缺点是多个节点的管理、任务的调度比较麻烦,这也是分布式系统研究和解决的问题。只有当数据量达到单机无法存储、处理的情况下才考虑分布式,不然都是自找麻烦。
状态的维护比计算要难很多,所谓状态就是需要持久化的数据。因此主要考虑分布式存储,况且即使是分布式计算,为了节省带宽需要尽量保证data locality,也是需要分布式存储。
现在有一堆数据,可能是结构化或者半结构化,需要将数据分片(segment、fragment、shard),形成一个个的数据子集,存储到一组物理节点上,物理节点之间通过网络通信。那么需要考虑两个问题:
第一:数据如何划分;
第二:数据的可靠性、可用性问题
(1)如果某个物理节点宕机,如何将该物理节点负责的数据尽快的转移到其他物理节点;
(2)如果新增了物理节点,怎么从其他节点迁移数据到新节点;
(3)对于可修改的数据(即不是只能追加的数据),比如数据库数据,如果某节点数据量变大,怎么将部分数据迁移到其他负载较小的节点,及达到动态均衡的效果。
(4)元数据的管理问题:当数据分布在各个节点,那么当用户使用的时候需要知道具体的数据在哪一个节点上。因此,系统需要维护数据的元数据:即每一个数据所在的位置、状态等信息。当用户需要具体的数据时,先查询元数据,然后再去具体的节点上查询。当数据在节点之间迁移的时候,也需要更新元数据。元数据的管理节点这里称之为meta server。元数据的管理也带来了新的挑战:
(4.1)如何抽取数据的特征(特征是分片的依据,也是用户查询数据时的key),或者支持用户自定义数据特征;
(4.2)如何保证meta server的高性能和高可用,是单点还是复制集
(5)分片的粒度,即数据子集的大小,也是数据迁移的基本单位。粒度过粗,不利于数据均衡;粒度过细,管理、迁移成本又会比较大。
为了避免单点故障,可行的办法就是数据冗余(复制集),即将同一份数据放在不同的物理节点,甚至是不同的数据中心。如果数据是一次写,多次读那很好办,随便从哪个副本读取都行。但对于很多分布式存储系统,比如数据库,数据是持续变化的,有读有写。那么复制集会带来什么样的挑战呢,需要如何权衡呢,假设有三个副本:
(1)三个副本的地位,大家都是平等的还是有主(primary、master)有次(secondary、slave),如果是平等的,那么每个节点都可以接收写操作;如果不平等,可以一个节点负责所有的写操作,所有节点都提供读操作,
(2)在平等的情况下,怎么保证写入操作不冲突,保证各个节点的数据是一致的,怎么保证能读取到最新的数据
(3)不平等的情况下
(3.1)写节点怎么将变更的数据同步到其他节点,同步还是异步;
(3.2)非写节点能否提供读数据,如果能够允许,会不会读取到过时的数据。
(3.3)主节点是怎么产生的,当主节点宕机的时候,怎么选择出新的主节点。是有统一的复制集管理中心(记录谁主谁次,各自的状态),还是复制集自己选举出一个主节点?
(4)不管复制集内部的节点是平等的,还是有集中式节点的,只要有多个数据副本,就需要考虑数据的一致性可用性问题。按照CAP理论,只能同时满足一致性 可用性 分区容错性之间的二者,不同的分布式系统需要权衡。
分片 副本 一致性哈希 幂等 CAP paxos raft NWR lease 两阶段提交协议 三阶段提交协议 拜占庭问题
目前收集到的学习资料如下:
刘杰的《分布式系统原理介绍》
Distributed systems for fun and profit
CMU课程:http://www.cs.cmu.edu/~dga/15-440/S14/syllabus.html
MIT课程:http://nil.csail.mit.edu/6.824/2016/schedule.html
前面两个是基础整体介绍,最后一个是MIT的课程,网上评价很高,也有很多人在学习。
对于一门新技术,不要上来就开干,思考新技术解决了什么问题、已有的技术能否替代、适用场景与缺陷。对于自己(程序员),想想为什么要学、是深度还是广度知识、该技术在自己的技能树中的位置。
对于学习,需要长期目标与短期目标相结合。长期目标很重要,但需要分解成一个个小目标,否则很容易在停顿、重拾之间打转,也很容易分心到其他杂事,也就坚持不下去了。
本文地址:http://www.cnblogs.com/xybaby/p/6930977.html
带着问题,有目的的学习,先了解整体架构,在深入感兴趣的细节,这是我的计划。
首先得有问题,如果每日重复相同的工作,也不主动去学习,很难发现新的问题。不怕自己无知,就怕不知道自己无知,只有不断的学习,才会发现更多未知的知识领域!
带着问题出发
回到顶部分布式要解决什么问题呢?解决持久化数据太大,单个节点的硬盘无法存储的问题;解决运算量太大,单个节点的内存、CPU无法处理的问题。解决这些问题,有两种思路:scale up,scale out。前者就是提升单个节点的能力,更大的磁盘,更快的CPU,定制的软硬件,然而这意味着更高的价格,而且再怎么scaleup 也是有上限的。后者就是把存储、计算任务分担到普通的机器上,通过动态增加节点来应对数据量的增长,但缺点是多个节点的管理、任务的调度比较麻烦,这也是分布式系统研究和解决的问题。只有当数据量达到单机无法存储、处理的情况下才考虑分布式,不然都是自找麻烦。
状态的维护比计算要难很多,所谓状态就是需要持久化的数据。因此主要考虑分布式存储,况且即使是分布式计算,为了节省带宽需要尽量保证data locality,也是需要分布式存储。
现在有一堆数据,可能是结构化或者半结构化,需要将数据分片(segment、fragment、shard),形成一个个的数据子集,存储到一组物理节点上,物理节点之间通过网络通信。那么需要考虑两个问题:
第一:数据如何划分;
第二:数据的可靠性、可用性问题
数据分片
数据分片是指将数据子集尽可能均衡的划分到各个物理节点上。那么会有哪些挑战呢?(1)如果某个物理节点宕机,如何将该物理节点负责的数据尽快的转移到其他物理节点;
(2)如果新增了物理节点,怎么从其他节点迁移数据到新节点;
(3)对于可修改的数据(即不是只能追加的数据),比如数据库数据,如果某节点数据量变大,怎么将部分数据迁移到其他负载较小的节点,及达到动态均衡的效果。
(4)元数据的管理问题:当数据分布在各个节点,那么当用户使用的时候需要知道具体的数据在哪一个节点上。因此,系统需要维护数据的元数据:即每一个数据所在的位置、状态等信息。当用户需要具体的数据时,先查询元数据,然后再去具体的节点上查询。当数据在节点之间迁移的时候,也需要更新元数据。元数据的管理节点这里称之为meta server。元数据的管理也带来了新的挑战:
(4.1)如何抽取数据的特征(特征是分片的依据,也是用户查询数据时的key),或者支持用户自定义数据特征;
(4.2)如何保证meta server的高性能和高可用,是单点还是复制集
(5)分片的粒度,即数据子集的大小,也是数据迁移的基本单位。粒度过粗,不利于数据均衡;粒度过细,管理、迁移成本又会比较大。
数据冗余
前面提到,分布式系统中的节点都是普通的节点,因此有一定的概率会出现物理故障,比如断电、网络不可用,这些故障导致数据的暂时不可用;另外一些故障更严重,会导致数据的丢失,比如磁盘损坏。即使单个节点的故障是小概率,当集群中的节点数目很多是,故障就成为了一个大概率事件。因此,保证数据的高可用和可靠性是分布式系统必须解决的问题。为了避免单点故障,可行的办法就是数据冗余(复制集),即将同一份数据放在不同的物理节点,甚至是不同的数据中心。如果数据是一次写,多次读那很好办,随便从哪个副本读取都行。但对于很多分布式存储系统,比如数据库,数据是持续变化的,有读有写。那么复制集会带来什么样的挑战呢,需要如何权衡呢,假设有三个副本:
(1)三个副本的地位,大家都是平等的还是有主(primary、master)有次(secondary、slave),如果是平等的,那么每个节点都可以接收写操作;如果不平等,可以一个节点负责所有的写操作,所有节点都提供读操作,
(2)在平等的情况下,怎么保证写入操作不冲突,保证各个节点的数据是一致的,怎么保证能读取到最新的数据
(3)不平等的情况下
(3.1)写节点怎么将变更的数据同步到其他节点,同步还是异步;
(3.2)非写节点能否提供读数据,如果能够允许,会不会读取到过时的数据。
(3.3)主节点是怎么产生的,当主节点宕机的时候,怎么选择出新的主节点。是有统一的复制集管理中心(记录谁主谁次,各自的状态),还是复制集自己选举出一个主节点?
(4)不管复制集内部的节点是平等的,还是有集中式节点的,只要有多个数据副本,就需要考虑数据的一致性可用性问题。按照CAP理论,只能同时满足一致性 可用性 分区容错性之间的二者,不同的分布式系统需要权衡。
其他
分布式系统有自己的术语或者概念。在当前的这个时间点,我对其中的一些有了解,或者使用过;另外一些只是听说过,不甚了解;当然,还有更多的是不知道的,是需要在后续的学习中去发现、去掌握的。分片 副本 一致性哈希 幂等 CAP paxos raft NWR lease 两阶段提交协议 三阶段提交协议 拜占庭问题
目前收集到的学习资料如下:
刘杰的《分布式系统原理介绍》
Distributed systems for fun and profit
CMU课程:http://www.cs.cmu.edu/~dga/15-440/S14/syllabus.html
MIT课程:http://nil.csail.mit.edu/6.824/2016/schedule.html
前面两个是基础整体介绍,最后一个是MIT的课程,网上评价很高,也有很多人在学习。
总结:
回到顶部对于一门新技术,不要上来就开干,思考新技术解决了什么问题、已有的技术能否替代、适用场景与缺陷。对于自己(程序员),想想为什么要学、是深度还是广度知识、该技术在自己的技能树中的位置。
对于学习,需要长期目标与短期目标相结合。长期目标很重要,但需要分解成一个个小目标,否则很容易在停顿、重拾之间打转,也很容易分心到其他杂事,也就坚持不下去了。
本文地址:http://www.cnblogs.com/xybaby/p/6930977.html
相关文章推荐
- win7-tensorflow查看当前运算器件及无法正常切换CPU/GPU运算器件问题解决方案
- SQLSERVER 占了500多M内存,原来的程序无法一次查询出50多W数据了,记录下这个问题的解决过程。
- 数据持久化的本质 - 数据保存成文件,存储到程序的沙盒中 -在应用程序结束时,将内存中的数据以文件的形式搬到(保存到)硬盘中
- 共享一文件夹提示"服务器存储空间不足,无法处理此命令"的问题解决方法
- SenchaTouch2中list组件无法绑定存储或者绑定后仍旧无法显示数据问题解决
- SenchaTouch2中list组件无法绑定存储或者绑定后仍旧无法显示数据问题解决
- "服务器存储空间不足,无法处理此命令"问题解决方法
- 解决“从用户数据存储中检索信息时出错。未找到平台。”问题
- 解决w3wp.exe占用CPU和内存问题 [转]
- PL/SQL Developer中,存储过程无法调试的问题解决办法
- 用Unlocker软件解决WinXP中U盘或移动硬盘无法弹出的问题
- 利用DhtmlXtree实现展现,修改,添加,删除,移动功能一棵树上实现,iframe的单个滑动条显示,包含在iframe中树节点中文内容过长问题解决
- 解决“从用户数据存储中检索信息时出错。未找到平台。”问题。
- 如何解决Remoting无法传输存储过程参数的问题
- 解决服务器w3wp.exe进程占用cpu和内存过多问题
- 基于Converter解决Struts无法处理日期类型的问题
- access 如何解决组合框无法满足大量数据的选择问题?
- 解决w3wp.exe CPU 内存占用问题
- access 如何解决组合框无法满足大量数据的选择问题?
- 网站无法连接sql sever数据库的一些问题处理,解决自己定义的数据库用户名,无法关联数据库和无法登陆数据库