分布式处理

　Zookeeper是hadoop的一个子项目，虽然源自hadoop，但是我发现zookeeper脱离hadoop的范畴开发分布式框架的运用越来越多。今天我想谈谈zookeeper，本文不谈如何使用zookeeper，而是zookeeper到底有哪些实际的运用，哪些类型的应用能发挥zookeeper的优势，最后谈谈zookeeper对分布式网站架构能产生怎样的作用。 　　Zookeeper是针对大型分布式系统的高可靠的协调系统。由这个定义我们知道zookeeper是个协调系统，作用的对象是分布式系统。为什么分布式系统需要一个协调系统了？理由如下： 　　开发分布式系统是件很困难的事情，其中的困难主要体现在分布式系统的“部分失败”。“部分失败”是指信息在网络的两个节点之间传送时候，如果网络出了故障，发送者无法知道接收者是否收到了这个信息，而且这种故障的原因很复杂，接收者可能在出现网络错误之前已经收到了信息，也可能没有收到，又或接收者的进程死掉了。发送者能够获得真实情况的唯一办法就是重新连接到接收者，询问接收者错误的原因，这就是分布式系统开发里的“部分失败”问题。 　　Zookeeper就是解决分布式系统“部分失败”的框架。Zookeeper不是让分布式系统避免“部分失败”问题，而是让分布式系统当碰到部分失败时候，可以正确的处理此类的问题，让分布式系统能正常的运行。 　

简介 　　Apache Thrift是Facebook开源的跨语言的RPC通信框架，目前已经捐献给Apache基金会管理，由于其跨语言特性和出色的性能，在很多互联网公司得到应用，有能力的公司甚至会基于thrift研发一套分布式服务框架，增加诸如服务注册、服务发现等功能。 　　RPC即Remote Procedure Call，翻译为远程过程调用。任何RPC协议的实现终极目标都是让使用者在调用远程方法的时候就像是调用本地方法一样简单，从而提高使用远程服务的效率。 　　现代互联网架构多数基于SOA思想而搭建，即面向服务化的架构。服务提供方称为Provider，服务的使用方称为Consumer，有时也把服务提供方称为Server端，使用方称为Client端，即典型的CS模型。这里的远程调用，主要指跨进程的调用，Provider和Consumer可能是同一机器的不同进程，也可能在不同的机器，通过网络相互通信，大部分情况下两者会部署在不同的物理机器上，这种情况下由于网络通信的开销就会对RPC框架的性能要求极高。 下面分别从服务端和客户端的视角来介绍Thrift在RPC中的应用。 服务端(Server) 服务端需要发布一个服务给别人使用，首先要约定好服务的接口，包括以下几个部分： 服务的名称 服务使用时的参数 返回结果 Thrift自己规定了一套接口定义语言（IDL）来描述服务，用后缀为

1、ZooKeeper介绍与核心概念 1.1 简介 ZooKeeper最为主要的使用场景，是作为分布式系统的分布式协同服务。在学习zookeeper之前，先要对分布式系统的概念有所了解，否则你将完全不知道zookeeper在分布式系统中起到了什么作用，解决了什么问题。 1.2分布式系统面临的问题 我们将分布式系统定义为：分布式系统指的是同时跨越多个物理主机，将一个完整的系统划分为多个独立运行的子系统，这些子系统之间互相协作构成一个完整的系统功能。类比一下，分布式系统就是将一个完整的任务细分为多个子任务，一群人分别完成一个子任务，最终完成整个任务。人多力量大，每个服务器的算力是有限的，但是通过分布式系统，由n个服务器组成起来的集群，算力是可以无限扩张的。 说起分布式就要谈谈集群，两者很相似，都是通过网络协同多台主机服务器节点完成整体的功能。 但不同点在于： 集群中的每个服务器节点都完成的是同一个功能，比如mysql数据库集群、redis集群； 而分布式系统则是各个服务器节点所负责的是不同的子系统（任务或者说功能），比如电商系统的分布式系统会分为订单系统、支付系统、数据库系统、缓存系统等等。 所谓分布式集群系统，就是将一个完整的系统进行拆分多个子系统，每个子系统都进行集群部署，各系统集群之间互相协作，就能构成一个分布式集群系统。 优点显而易见，人多干活快，并且互为备份。但是缺点也很明显

##2.1 网站架构模式## 为了解决大型网站面临的高并发访问，海量数据处理，高可靠运行等一系列问题与挑战，大型互联网公司在实践中提出了许多解决方案，以实现网站高性能，高可用，易伸缩，可扩展，安全等各种技术架构目标。这些解决方案又被更多网站重复使用，从而逐渐形成大型网站架构模式。 ###2.1.1 分层### 分层是企业应用系统中最常见的一种架构模式，将系统在 横向维度 上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。 分层结构在计算机世界中无处不在， 网络的7层通信协议 是一种分层结构；计算机硬件，操作系统，应用软件也可以看作是一种分层结构。在大型网站中也采用分层结构，将网站软件系统分为 应用层 ， 服务层 ， 数据层 ，如下： 应用层 ：负责具体业务和视图展示，如网站首页及搜索输入和结果展示； 服务层 ：为应用层提供服务支持，如用户管理服务，购物车服务等； 数据层 ：提供数据存储访问服务，如数据库，缓存，文件，搜索引擎等； 通过分层，可以更好地将一个庞大的软件系统切分成不同的部分，便于分工合作开发和维护；各层之间具有一定的独立性，只要维持调用接口不变，各层可以根据具体问题独立演化发展而不需要其他层必须做出相应调整。 但是分层架构也有一些挑战，就是 必须合理规划层次边界和接口 ，在开发过程中，严格遵循分层架构的约束

 介绍常见的分布式一致性协议 一．CAP/BASE 1. CAP理论  CAP理论又称之为布鲁尔定理（Brewer’S theorem），认为在设计一个大规模可扩放的网络服务时候不能同时兼容：一致性（consistency）、可用性（Availability）、分区容错（Partition-tolerance）。  一致性：在分布式系统中的所有数据备份，在同一时刻是否有同样的值。（等同于所有节点访问同一份最新的数据副本）  可用性：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。  分区容忍性：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择  CAP理论容易理解，网上也有关于该理论的说明，包括模型的简易证明；弱条件下模型的成立等。  参考资料： http://www.cnblogs.com/mmjx/archive/2011/12/19/2290540.html http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html 2. BASE理论  BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写

Hadoop简介 Hadoop由Apache基金会开发的分布式系统基础架构，是利用集群对大量数据进行分布式处理和存储的软件框架。用户可以轻松地在Hadoop集群上开发和运行处理海量数据的应用程序。Hadoop有高可靠，高扩展，高效性，高容错等优点。Hadoop 框架最核心的设计就是HDFS和MapReduce。HDFS为海量的数据提供了存储，MapReduce为海量的数据提供了计算。此外，Hadoop还包括了Hive，Hbase，ZooKeeper，Pig，Avro，Sqoop，Flume，Mahout等项目。 Hadoop的运行模式分为3种： 本地运行模式 ， 伪分布运行模式 ， 完全分布运行模式 。 本地模式（local mode） 这种运行模式在一台单机上运行，没有HDFS分布式文件系统，而是直接读写本地操作系统中的文件系统。在本地运行模式（local mode）中不存在守护进程，所有进程都运行在一个JVM上。单机模式适用于开发阶段运行MapReduce程序，这也是最少使用的一个模式。 伪分布模式 这种运行模式是在单台服务器上模拟Hadoop的完全分布模式，单机上的分布式并不是真正的分布式，而是使用线程模拟的分布式。在这个模式中，所有守护进程(NameNode，DataNode，ResourceManager，NodeManager，SecondaryNameNode

分布式设计与开发中有些疑难问题必须借助一些算法才能解决，比如分布式环境一致性问题，感觉以下分布式算法是必须了解的（随着学习深入有待添加）： Paxos算法 一致性Hash算法 Paxos算法 1）问题描述 分布式中有这么一个疑难问题，客户端向一个分布式集群的服务端发出一系列更新数据的消息，由于分布式集群中的各个服务端节点是互为同步数据的，所以运行完客户端这系列消息指令后各服务端节点的数据应该是一致的，但由于网络或其他原因，各个服务端节点接收到消息的序列可能不一致，最后导致各节点的数据不一致。举一个实例来说明这个问题，下面是客户端与服务端的结构图： 当client1、client2、client3分别发出消息指令A、B、C时，Server1~4由于网络问题，接收到的消息序列就可能各不相同，这样就可能由于消息序列的不同导致Server1~4上的数据不一致。对于这么一个问题，在分布式环境中很难通过像单机里处理同步问题那么简单，而Paxos算法就是一种处理类似于以上数据不一致问题的方案。 2）算法本身 算法本身我就不进行完整的描述和推导，网上有大量的资料做了这个事情，但我学习以后感觉莱斯利·兰伯特（Leslie Lamport，paxos算法的奠基人，此人现在在微软研究院）的 Paxos Made Simple 是学习paxos最好的文档

分布式设计与开发中有些疑难问题必须借助一些 算法 才能解决，比如分布式环境一致性问题，感觉以下分布式算法是必须了解的（随着学习深入有待添加）： Paxos算法 一致性Hash算法 Paxos算法 1）问题描述 分布式中有这么一个疑难问题，客户端向一个分布式集群的服务端发出一系列更新数据的消息，由于分布式集群中的各个服务端节点是互为同步数据的，所以运行完客户端这系列消息指令后各服务端节点的数据应该是一致的，但由于网络或其他原因，各个服务端节点接收到消息的序列可能不一致，最后导致各节点的数据不一致。举一个实例来说明这个问题，下面是客户端与服务端的结构图： 当client1、client2、client3分别发出消息指令A、B、C时，Server1~4由于网络问题，接收到的消息序列就可能各不相同，这样就可能由于消息序列的不同导致Server1~4上的数据不一致。对于这么一个问题，在分布式环境中很难通过像单机里处理同步问题那么简单，而Paxos算法就是一种处理类似于以上数据不一致问题的方案。 2）算法本身 算法本身我就不进行完整的描述和推导，网上有大量的资料做了这个事情，但我学习以后感觉莱斯利·兰伯特（Leslie Lamport，paxos算法的奠基人，此人现在在微软研究院）的 Paxos Made Simple 是学习paxos最好的文档

Git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。1Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。它是一个免费开源的分布式版本控制系统，被用于高速有效地处理大大小小项目中所有文件。Git 是一个免费开源的分布式版本控制系统，被用于高速有效地处理大大小小项目中所有文件。 来源： https://www.cnblogs.com/whx1/p/11575342.html

Hadoop是Apache开源的分布式计算框架，由Java语言实现，支持对海量数据的分布式计算，其框架中最核心设计是HDFS和MapReduce。 Hadoop的优势 1）高可靠性：因为Hadoop假设计算元素和存储会出现故障，因为它维护多个工作数据副本，在出现故障时可以对失败的节点重新分布处理 2）高扩展性：在集群间分配任务数据，可方便的扩展数以千计的节点。 3）高效性：在MapReduce的思想下，Hadoop是并行工作的，以加快任务处理速度。 4）高容错性：自动保存多份副本数据，并且能够自动将失败的任务重新分配。 Hadoop组成 1）Hadoop HDFS：一个高可靠、高吞吐量的分布式文件系统。 2）Hadoop MapReduce：一个分布式的离线并行计算框架。 3）Hadoop YARN：作业调度与集群资源管理的框架。 4）Hadoop Common：支持其他模块的工具模块。 1 Hadoop生态圈重要组件(数据处理过程的视角) 1.1 数据采集 Sqoop—— 结构化数据/数据迁入迁出工具 Flume Kafka—— 分布式日志采集工具 分布式消息队列 针对半结构化或非结构化数据 1.2 数据存储 HDFS—— 基于Hadoop的分布式文件存储系统 HBase—— 基于Hadoop的列式分布式NoSQL数据库 1.3 资源调度 YARN—— 作业调用和集群资源管理框架