分布式处理

一、前言 　　 在大数据系统中，分布式系统已经成为一个无法避免的组件，如zookeeper已经成为了工业届的标准。所以对于大数据的研究，也必须要研究分布式系统的特点。 二、集中式系统 　　由一台或多台计算机组成的中心节点，数据集中存储在这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统的所有功能均由其集中处理。其部署简单，不用考虑多个节点间的分布式协作问题。 三、分布式系统 　　分布式系统是一个由硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。其拥有如下特点 　　 3.1 分布性 　　分布式系统中的多台计算机都会在空间中随意分布，同时，机器的分布情况也会随时变动。 　 　3.2 对等性 　　分布式系统中的计算机没有主/从之分，既没有控制整个系统的主机，也没有被控制的从机，组成分布式系统的所有计算机节点都是对等的， 副本 指的是分布式系统对数据和服务提供的一种冗余方式，为了对外提供高可用的服务，我们往往会对数据和服务进行副本处理。 数据副本 是指在不同的节点上持久化同一份数据，当某一个节点上存储的数据丢失时，可以从副本上读取到该数据，这是解决分布式系统数据丢失问题最为有效的手段。 服务副本 是只多个节点提供同样的服务，每个节点都有能力接受来自外部的请求并进行相应的处理。 　 　3.3 并发性 　　同一分布式系统中的多个节点

　　　 我的探索历程 　　 这一部分，与分布式不大相关，记录的是我是如何在分布式学习这条道路上摸索的，不感兴趣的读者请直接跳到下一章 。 　 　 过去的一年，我在分布式 学习 这条道路上苦苦徘徊，始终没有找到一个好的学习方法，一个能激励我持续学习的方法。 　　当然，我也在不停的反思，最先发现的问题是学习不系统，东看看，西看看，看过就忘。于是写了一篇文章《 带着问题学习分布式系统 》提出了一些问题，然后写了两篇文章来回带自己提出的问题。回过头看，其实这两篇文章都是基于分布式存储的。 　　然后接下来，又是一段时间的迷茫，不知道要学习啥（也是在学习Paxos的时候遇到了阻碍），偶然看到了关于SMART的一些文章，发现原来自己的学习一点都不SAMRT，所以坚持不下去。于是又写了一篇文章《 带着SMART原则重新出发 》，希望给自己设定SMART的目标，结果被博友打脸“一点都不smart”，而且也被结果打脸了，确实没有让我“重新出发”。 　　我也曾经在网上搜索，“如何学习分布式系统“，但并没有找到理想的、或者说适合我的学习方法。网上的答案，都是说，看这些论文，看这些系统的实现。。。或者很多大学的课程，都是罗列出一堆术语：概念、协议、组件。而我觉得，逐个去了解这些术语似乎很无聊，因为不知道为什么要这个协议，或者说这些协议、组件是如何组合起来的。 　　在没有得到适合自己的方案之后，我自己思考

　　很长一段时间，对分布式系统都比较感兴趣，也听说过、了解过其中一些相关的知识点，但都比较零碎。一直想系统的学习一下，但是一拖再拖，写下本文，也是希望能督促自己。 写在前面 　　听过很多道理，却依然过不好这一生。 　　看过很多关于学习的技巧、方法，却没应用到自己的学习中。 　　随着年纪变大，记忆力越来越差，整块的时间也越来越少，于是，越来越希望能够更高效的学习。学习是一种习惯也是一种能力，这种能力在上学期间养成是最好的，毕竟那个时候绝大部分时间都在学习。但很遗憾，我没有养成适合自己的、好的学习习惯。工作之后，除了在日常工作中用到的知识技术，很难通过自学掌握新的知识（偏向于专业知识，即技术）。而互联网行业的分支、知识点又是如此之多，于是会出现这样的情况，遇到一个新的知识，觉得很厉害很感兴趣，看两天，但很快就忘记了。另外，对于一些比较庞杂的技术，又无从下手，也很难坚持下去。 　　根本的问题在于学习不系统，没有把一个个的知识点连接起来，本来这些新的知识就很少在工作中实践，如果又是一个个的信息孤岛，很快就会被遗忘。另一个问题，没有良好的规划，今天看看这里，明天看看哪里，纠结于细枝末节，忘了从整体上把握。 　　幸好，差不多半年前开始意识到了这个问题，开始看书，看别人的博客，开始思考如何充分利用好有限的时间。自己也实践了一些想法，比如写博客，坚持写博客。也有很多没做好

根据阿里云《分布式文件存储系统技术及实现》整理而成。 1 分布式存储的客观需求 存储容量大 考虑对1PB数据进行排序，输入输出都需要1PB，算上中间临时数据，总共需要3-4PB。考虑多用户使用，则集群需要的总的存储空间大于100PB。 高吞吐量，如1PB数据排序需要在2小时内完成，每秒需要几十GB 数据可靠性，在数据规模增长时，降低数据丢失 服务高可用，99.95%意味着每年每年只有4-5小时不可用 高效运维，将日常硬件处理做成流程化，对监控报警要有完善支持 低成本，保证数据安全，正确服务稳定前提下，降低成本，才是分布式存储的核心竞争力 2 小概率事件对分布式系统挑战 单机系统下很少发生的事件，在大规模分布式系统中就会经常发生。 可能发生的小概率问题有： 1 磁盘错误 单机下运行稳定，集群下可能出现频繁。要考虑如何发现慢节点自动规避，发现机器宕机自动绕过。 2 Raid卡故障 发生在高可用节点上的事件。Raid卡是带有电池的缓存块，写入速度很快，能够在断电时保存数据。利用raid卡先缓存数据，之后再写入磁盘中。 3 网络故障 网络架构是一种树形结构，通过顶层交换机连接下层交换机，交换机下连接多台机器。 当上连交换机节点出错时，一部分主机将与其他主机分离，无法发挥作用。 可以将关键角色分布在不同的交换机下，将数据存储多份，某些机器失效时还可以访问到数据。 4 电源故障

Paxos协议/算法是分布式系统中比较重要的协议，它有多重要呢？ <分布式系统的事务处理> ： Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法，那就是Paxos，其它的算法都是残次品。 <大规模分布式存储系统> ： 理解了这两个分布式协议之后(Paxos/2PC)，学习其他分布式协议会变得相当容易。 学习Paxos算法有两部分：a) 算法的原理/证明；b) 算法的理解/运作。 理解这个算法的运作过程其实基本就可以用于工程实践。而且理解这个过程相对来说也容易得多。 网上我觉得讲Paxos讲的好的属于这篇： paxos图解 及 Paxos算法详解 ，我这里就结合 wiki上的实例 进一步阐述。一些paxos基础通过这里提到的两篇文章，以及wiki上的内容基本可以理解。 算法内容 Paxos在原作者的《Paxos Made Simple》中内容是比较精简的： Phase 1 (a) A proposer selects a proposal number n and sends a prepare request with number n to a majority of acceptors. (b) If an acceptor receives a prepare request with number n greater than

实现分布式锁目前有三种流行方案，分别为基于数据库、Redis、Zookeeper的方案，其中前两种方案网络上有很多资料可以参考，本文不做展开。我们来看下使用Zookeeper如何实现分布式锁。 什么是Zookeeper? Zookeeper(业界简称zk)是一种提供配置管理、分布式协同以及命名的中心化服务，这些提供的功能都是分布式系统中非常底层且必不可少的基本功能，但是如果自己实现这些功能而且要达到高吞吐、低延迟同时还要保持一致性和可用性，实际上非常困难。因此zookeeper提供了这些功能，开发者在zookeeper之上构建自己的各种分布式系统。 虽然zookeeper的实现比较复杂，但是它提供的模型抽象却是非常简单的。Zookeeper提供一个多层级的节点命名空间(节点称为znode)，每个节点都用一个以斜杠(/)分隔的路径表示，而且每个节点都有父节点(根节点除外)，非常类似于文件系统。例如，/foo/doo这个表示一个znode，它的父节点为/foo，父父节点为/，而/为根节点没有父节点。与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行。Zookeeper为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得Zookeeper不能用于存放大量的数据，每个节点的存放数据上限为1M。 而为了保证高可用

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 随着币价的一直下跌，有传言说，比特币价格此次崩盘，只是大 BOSS 吴忌寒为加速淘汰老旧矿机而祭出的绝招。 无论这个阴谋论真假与否，在整个区块链行业的凛冽寒冬中，价格的涨跌已经左右了太多的人头脑之中的理智。可是，众人之中，究竟有几个人真正理解了区块链技术的密码学机制与分布式计算？究竟有几个人还会关心区块链在技术上的创新？ 尘归尘，土归土。可能只有巨大的泡沫消散之后，区块链才能通过技术创新显示出真正的影响力。让区块链回归技术与应用的本质，这也是我们一直以来的定位。然而，传播这样的内容和话题，离不开货真价实的技术干货，以及有感染力的人物和故事。 我们今天的内容就来自于这样一个女生： 她是工业与系统工程专业出身，做过顶级投行高盛的分析师，做过著名风投 a16z 的合伙人——这都是许多人梦寐以求的工作。但是，功成名就的路上，她却发现编程才是自己想要的生活。 笨办法学会编程？她没学会。如何用 HTML/CSS 做一个网页？她开始上瘾了。所以，没有选择斯坦福、MIT 的编程学位，她更喜欢 Hack Reactor 的全栈动手实践。先学 JavaScript、React，后面的想法是机器学习、计算机视觉……这个女生就是 Preethi Kasireddy。 接触区块链之后，金融从业背景和全栈编程能力让 Preethi

GFS分布式文件系统集群 GlusterFS概述 GlusterFS简介 开源的分布式文件系统 由存储服务器，客户端以及NFS/Samba存储网关组成 无元数据服务器 RDMA:负责数据传输 GlusterFS的特点 扩展性和高性能 高可用性 全局统一的命名空间 弹性卷管理 基于标准协议 GlusterFS术语 Brick ： 存储节点 Volume ： 卷 FUSE ： 内核模块，用户端的交互模块 VFS ： 虚拟端口 Glusterd ： 服务 模块化堆栈架构 模块化、堆栈式的架构 通过对模块的组合，实现负责的功能 GlusterFS工作模式 Application：客户端或应用程序通过GlusterFSync的挂载点访问数据 VFS：linux系统内核通过VFS API收到请求并处理 FUSE ： VFS 将数据递交给FUSE内核文件系统，fuse 文件系统则是将数据通过/dev/fuse设备文件递交给了GlusterFS client端 GlusterFS Client ; 通过网络将数据传递至远端的GlusterFS Server，并且写入到服务器存储设备上 GlusterFS工作原理 GlusterFS工作流程 弹性HASH算法 通过HASH算法得到一个32位的整数 划分为N个连续的子空间，每个空间对应一个Brick 弹性HASH算法的优点

一 什么是 ZooKeeper ZooKeeper 的由来 下面这段内容摘自《从Paxos到Zookeeper 》第四章第一节的某段内容，推荐大家阅读以下： Zookeeper最早起源于雅虎研究院的一个研究小组。在当时，研究人员发现，在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调，但是这些系统往往都存在分布式单点问题。所以， 雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。 关于“ZooKeeper”这个项目的名字，其实也有一段趣闻。在立项初期，考虑到之前内部很多项目都是使用动物的名字来命名的（例如著名的Pig项目),雅虎的工程师希望给这个项目也取一个动物的名字。时任研究院的首席科学家RaghuRamakrishnan开玩笑地说：“在这样下去，我们这儿就变成动物园了！”此话一出，大家纷纷表示就叫动物园管理员吧一一一因为各个以动物命名的分布式组件放在一起， 雅虎的整个分布式系统看上去就像一个大型的动物园了，而Zookeeper正好要用来进行分布式环境的协调一一于是，Zookeeper的名字也就由此诞生了。 1.1 ZooKeeper 概览 ZooKeeper 是一个开源的分布式协调服务，ZooKeeper框架最初是在“Yahoo!"上构建的，用于以简单而稳健的方式访问他们的应用程序。 后来，Apache

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 大型主机时代已经井喷，集中式时代已经无法满足日益健壮复杂的业务和需求，互联网时代的到来，使得由集中式到分布式的革命犹然而生，网络化，微型化发展步伐迫切，分布式的需求越来越能适应需求，一线电商平台迈入分布式时代。 分布式官方定义为：所谓分布式系统顾名思义就是利用多台计算机协同解决单台计算机所不能解决的计算、存储等。 问题一、 将一个单机问题使用分布式解决，首先要解决的就是如何将问题拆解为可以使用多机分布式解决，使得 分布式系统中的每台机器负责原问题的一个子集。 1.特点： 分布性：分布式多台计算机在空间上可随意分布，机器的分布情况可以随时调整 对等性：分布式系统的计算机没有主从之分，没有控制整个系统的主机，也没有被控制的从机，组成分布式系统的所有计算机节点都是对等的，每个节点都是用 副本 的形式来数据冗余的方式保证数据的持久化。 并发性：同一个分布式系统的的多个节点会操作一份共享的资源和数据的分布式存储，如何高效准确的协调控制分布式并发成为了一个难题。 缺乏全局时钟：典型的分布式系统由多台计算机在空间上随意分布的多个进程组成，进程之间通过消息来进行相互通信，很难保证一个次顺问题，比如分布式中的全局唯一ID如何生成等等问题。 2.环境： 通信异常：分布式可以说是多个节点之间依靠不稳定的网络进行通信