分布式处理

Hystrix是用于处理分布式里的延迟和容错得开源库，在写时会不可避免得出现一些异常，或失败，而Hystrix就是在此依赖出现问题得情况下，不会导致整体得服务失败，从而避免级联故障得发生，提高分布式的弹性。 断路器其实就是个开关的装置，通过断路器的监控，向调用方返回一个符合预期的，可处理的备选响应，而不是在长时间等待或者向调用方抛出一个五福处理的异常，从而保证了调用方的线路不会呗长时间，不必要的占用，因此就避免的故障在分布式的蔓延，乃至雪崩 来源： https://www.cnblogs.com/Dyz-yazhou/p/11519464.html

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

对于我们新手入门学习hadoop大数据存储的朋友来说，首先了解一下云计算和云计算技术是有必要的。下面先是介绍云计算和云计算技术的： 云计算，是一种基于互联网的计算方式，通过这种方式，共享的软硬件资源和信息可以按需求提供给计算机和其他设备，主要是基于互联网的相关服务地增加、使用和交付模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。云是网络、互联网的一种比喻说法。过去在图中往往用云来表示电信网，后来也用来表示互联网和底层基础设施的抽象。狭义云计算指IT基础设施的交付和使用模式，指通过网络以按需、易扩展的方式获得所需资源；广义云计算指服务地交付和使用模式，指通过网络以按需、易扩展的方式获得所需服务。这种服务可以是IT和软件、互联网相关，也可是其他服务。它意味着计算也可作为一种商品通过互联网进行流通。 什么是云计算 ？ 什么是云计算技术 ？ 在世界上云计算已经大面流行，有很流行的 Google Drive、SkyDrive、Dropbox 、亚马逊云服务等等。在国内 百度云 存储、360云存储都是比较流行的。 我们就应该会想到大数据存储，目前开源市场上最流行的应该是hadoop分布式存储，已经有大部分互联网公司已经开始使用，例如百度、360、阿里巴巴，其中一部分公司已经把hadoop作为他们的核心产品例如英特尔、IBM并为部分工作提供过大数据的解决方案

Zookeeper简介 产生背景 当今是个分布式、集群、云计算等名词满天飞的时代。造成这种局面的一个重要因素就是，单一机器的处理能力已经不能满足我们的需求，不得不采用由多台机器组成的服务集群。 服务集群对外提供服务的过程中，可以分解处理压力，在一定程度上打破性能瓶颈，并提高服务的可用性（不会因为一台机器宕机而造成服务不可用）。 假设有三台机器，每台机器跑同样的一个应用程序。然后我们将这三台机器通过网络将其连接起来，构成一个系统来为用户提供服务，对用户来说这个系统的架构是透明的，他感觉不到这个系统是一个什么样的架构。那么我们就可以把这种系统称作一个分布式系统。 那么，问题来了： （1）程序的运行往往依赖很多配置文件，比如数据库地址、黑名单控制、服务地址列表等，而且有些配置信息需要频繁地进行动态变更，这时候怎么保证所有机器共享的配置信息保持一致？ （2）如果有一台机器挂掉了，其他机器如何感知到这一变化并接管任务？如果用户激增，需要增加机器来缓解压力，如何做到不重启集群而完成机器的添加？ （3）用户数量增加或者减少，会出现有的机器资源使用率繁忙，有的却空闲，如何让每台机器感知到其他机器的负载状态从而实现负载均衡？ （4）在一台机器上要多个进程或者多个线程操作同一资源比较简单，因为可以有大量的状态信息或者日志信息提供保证，比如两个A和B进程同时写一个文件，加锁就可以实现

一.简介 Zookeeper 是Google 的 Chubby一个开源的实现，是 Hadoop 的分布式协调服务。 它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。 为什么使用Zookeeper ： 大部分分布式应用需要一个主控、协调器或控制器来管理物理分布的子进程（如资源、任务分配等） 目前，大部分应用需要开发私有的协调程序，缺乏一个通用的机制 协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器 ZooKeeper：提供通用的分布式锁服务，用以协调分布式应用 ZooKeeper能帮我们做什么？ Hadoop2.0,使用Zookeeper的事件处理确保整个集群只有一个活跃的NameNode,存储配置信息等。 HBase,使用Zookeeper的事件处理确保整个集群只有一个HMaster,察觉HRegionServer联机和宕机,存储访问控制列表等。 二.分布式锁 分布式锁，这个主要得益于ZooKeeper为我们保证了数据的强一致性。锁服务可以分为两类，一个是保持独占，另一个是控制时序。 所谓保持独占 ，就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把zk上的一个znode看作是一把锁，通过 create znode的方式来实现。所有客户端都去创建 /distribute_lock 节点

公众号原文： Zookeeper 分布式协调服务介绍 博客原文： Zookeeper 分布式协调服务介绍 分布式系统 分布式系统的简单定义：分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。 分布式系统的特征： 分布性：系统中的计算机在空间上随意分布和随时变动 对等性：系统中的计算机是对等的，没有主从之分 并发性：并发性操作是非常常见的行为 缺乏全局时钟：系统中的计算机具有明显的分布性，且缺乏一个全局的时钟序列控制，所以很难比较两个事件的先后 故障总是会发生：任何在设计阶段考虑到的异常情况，一定会在系统实际运行中发生，并且还会遇到很多在设计时未考虑到的异常故障 随着分布式架构的出现，越来越多的分布式应用会面临数据一致性问题。 选择Zookeeper Zookeeper是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、master选举、分布式锁和分布式队列等功能。 Zookeeper致力于提供一个高性能、高可用，具有严格的顺序访问控制能力的分布式协调服务；其主要的设计目标是简单的数据模型、可以构建集群、顺序访问、高性能。Zookeeper已经成为很多大型分布式项目譬如Hadoop、HBase、Storm、Solr等中的核心组件，用于分布式协调。

分布式协调服务-zookeeper 分布式环境的特点 分布式环境下面临的问题 经典的CAP/BASE理论 CAP BASE 初步认识zookeeper zookeeper是什么 zookeeper能做什么 zookeeper的特性 顺序一致性 原子性 可靠性 实时性 zookeeper安装 单机环境安装 集群环境 分布式环境的特点 分布性 并发性 程序运行过程中，并发性操作是很常见的。比如同一个分布式系统中的多个节点，同时访问一个共享资源。数据库、分布式存储 无序性 进程之间的消息通信，会出现顺序不一致问题 分布式环境下面临的问题 网络通信 网络本身的不可靠性，因此会涉及到一些网络通信问题 网络分区(脑裂) 当网络发生异常导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式架构的所有节点，只有部分节点能够正常通信 三态 在分布式架构里面，除了成功、失败、超时 分布式事务 ACID(原子性、一致性、隔离性、持久性) 冷备或者热备 分布式架构里面，很多的架构思想采用的是：当集群发生故障的时候，集群中的人群会自动“选举”出一个新的领导。 最典型的是： zookeeper / etcd 经典的CAP/BASE理论 CAP C（一致性 Consistency） : 所有节点上的数据，时刻保持一致 可用性（Availability） ：每个请求都能够收到一个响应

1.zookeeper简介 1.1简介 Zookeeper是一个分布式协调服务，换言之，就是为用户的分布式应用程序提供协调服务 - zookeeper是为别的分布式程序服务的 - Zookeeper本身就是一个分布式程序（只要有半数以上节点存活，zk就能正常服务） - Zookeeper所提供的服务涵盖：主从协调、服务器节点动态上下线、统一配置管理、分布式共享锁、统一名称服务 - 虽然说可以提供各种服务，但是zookeeper在底层其实只提供了两个功能（管理数据和监听数据）： 管理(存储，读取)用户程序提交的数据； 并为用户程序提供数据节点监听服务； 1.2 Zookeeper集群的角色： Leader 和 follower Zookeeper在配置文件中并没有指定master和slave，启动之后通过内部的选举机制选举出leader和follower，而且只有一个leader，其他则为follower。zookeeper集群中只要有半数以上节点存活，集群就能提供服务。 2.zookeeper集群机制 半数机制：集群中半数以上机器存活，集群可用。 zookeeper适合装在奇数台机器上！！！ 2.zookeeper安装与配置 2.1zookeeper安装 安装到3台虚拟机上（需要提前安装好JDK） 将zookeeper压缩包上传至/apps/package目录并解压 tar

无论是云计算、大数据还是互联网公司的各种应用，其后台基础设施的主要目标都是构建低成本、高性能、可扩展、易用的分布式存储系统。 大规模分布式存储系统的定义如下：分布式存储系统是大量普通PC服务器通过Internet互联，对外作为一个整体提供存储服务。 几个特点： （1）可扩展：分布式存储系统可以扩展到几百台甚至上千台的集群规模，而且，随着集群规模的增长，系统整体性能表现为线性增长 （2）低成本：自动容错、自动负载均衡机制使其可以构建在普通PC机之上。另外，线性扩展能力也使得增加、减少机器非常方便，可以实现自动运维。 （3）高性能：针对整个集群还是单台服务器，都要求分布式存储系统具备高性能。 （4）易用：分布式存储喜提需要能够提供易用的对外接口，另外，也要求具备完善的监控、运维工具。 分布式存储数据需求比较复杂，大体可以分为三类： （1）非结构化数据 （2）结构化数据 （3）半结构化数据 不同的分布式存储系统适合处理不同类型的数据，将分布式存储系统分为四类： （1）分布式文件系统：互联网应用需要存储大量的图片，视频等非结构化数据对象，这类数据以对象的形式组织，对象之间没有关联，这样的数据一般称为Blob数据（Binary Large Object二进制大对象） 分布式文件系统存储三种类型的数据：Blob对象，定长块，大文件 （2）分布式键值系统：存储关系检点的半结构化数据

Redis数据量日益增大，使用的公司越来越多，不仅用于做缓存，同时趋向于存储这一块，这样必促使集群的发展，各个公司也在收集适合自己的集群方案，目前行业用的比较多的是下面几种集群架构，大部分都是采用分片技术，保证单实例内存增大带来的一系列问题，下面所列出的codis方案目前正在不断测试过程中，测试过程没有展示出来，主要从以下几点出发。 测试架构 和性能 ： 　　1、keepalived+haproxy故障测试 　　2、Zookeeper集群节点测试 　　3、Codis-proxy集群节点测试 　　4、Codis-server集群节点测试 　　5、脚本写入大量测试数据并模拟数据迁移 　　6、性能测试 下面具体介绍codis和其他几大集群方案 集群方案： 　　1、 主从高可用（该方案就是单实例形式，只是为了保证数据的安全，对于用户数据少，业务的前期可以采用，目前我司缓存架构就是采用该方案） 　　2、 客户端分片（典型代表：Jedis。自主写分片算法，代码掌握在自己手中，可控性强，但是需要专业的开发运维人员维护，技术要求和维护成本高） 　　3、代理分片（典型代表：Twemproxy，redis集群没有正式推出之前官网推荐的方案，也是目前使用最多的） 　　4、 Redis cluster（3版本推出的集群方案，历时四年之多的开发） 　　5、 Codis集群（豌豆荚15年开源的解决方案