分布式部署

为什么需要Zookeeper Zookeeper是一个典型的分布式数据一致性的解决方案， 分布式应用程序可以基于它实现诸如 数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列 等功能。 在解决分布式数据一致性上，Zookeeper已经成为了目前唯一一个比较成熟的方案。 Zookeeper致力于提供一个高性能、高可用，且具有严格的顺序访问控制能力的分布式协调服务。 设计目标 简单的数据结构 冗余，可以构建集群 有序访问 高性能 系统角色 Zookeeper没有沿用传统的Master/Slave模式，使用了Leader、Follwer、Obserfver三种角色。 Zookeeper Atomic Broadcast Zookeeper原子消息广播协议 ZAB的核心定义了那些会改变Zookeeper服务器数据状态的事务请求的处理方式： 所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而余下的其他服务器则成为Follower服务器。 Leader将一个服务请求转换成一个Proposal，然后将这个Proposal分发给集群中其他的Follwer，然后等待Follower处理Proposal的反馈，当超过一定比例的Follower服务器发出正确的反馈后，Leader会发出Commit消息

本文引用自 http://www.cnblogs.com/sunddenly/p/4033574.html 引言 　　Hadoop 集群当中 N 多的配置信息如何做到全局一致并且单点修改迅速响应到整个集群？ --- 配置管理 　　Hadoop 集群中的 namonode 和 resourcemanager 的单点故障怎么解决？ --- 集群的主节点的单点故障 分布式协调技术 　　在给大家介绍ZooKeeper之前先来给大家介绍一种技术——分布式协调技术。那么什么是分布式协调技术？那么我来告诉大家，其实分布式协调技术 主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成"脏数据"的后果。这时，有人可能会说这个简单，写一个调 度算法就轻松解决了。说这句话的人，可能对分布式系统不是很了解，所以才会出现这种误解。如果这些进程全部是跑在一台机上的话，相对来说确实就好办了，问 题就在于他是在一个分布式的环境下，这时问题又来了，那什么是分布式呢？这个一两句话我也说不清楚，但我给大家画了一张图希望能帮助大家理解这方面的内 容，如果觉得不对尽可拍砖，来咱们看一下这张图，如图1.1所示。 　　给大家分析一下这张图，在这图中有三台机器，每台机器各跑一个应用程序。然后我们将这三台机器通过网络将其连接起来，构成一个系统来为用户提供服务，对用户来说这个系统的架构是透明的

分布式与集群的区别（Distributed vs Cluster） 分布式：一个业务分拆多个子业务，部署在不同的服务器上。 集群：同一个业务，部署在多个服务器上。 — 分布式与集群的区别是什么？ - 知乎用户的回答 - 知乎 来源： https://www.cnblogs.com/lshare/p/11334215.html

现在先抛出问题，假设有一个主数据中心在北京M，然后有成都A，上海B两个地方数据中心，现在的问题是，假设成都上海各自的数据中心有记录变更，需要先同步到主数据中心，主数据中心更新完成之后，在把最新的数据分发到上海，成都的地方数据中心A，地方数据中心更新数据，保持和主数据中心一致性（数据库结构完全一致）。数据更新的消息是通过一台中心的MQ进行转发。 先把问题简单化处理，假设A增加一条记录Message_A，发送到M，B增加一条记录 MESSAGE_B发送到M，都是通过MQ服务器进行转发，那么M系统接收到条消息，增加两条数据，那么M在把增加的消息群发给A，B，A和B找到自己缺失的数据，更新数据库。这样就完成了一个数据的同步。 从正常情况下来看，都没有问题，逻辑完全合理，但是请考虑以下三个问题 1 如何保证A->M的消息，M一定接收到了，同样，如何保证M->A的消息，M一定接收到了 2 如果数据需要一致性更新，比如A发送了三条消息给M，M要么全部保存，要么全部不保存，不能够只保存其中的几条记录。我们假设更新的数据是一条条发送的。 3 假设同时A发送了多条更新请求，如何保证顺序性要求？ 这两个问题就是分布式环境下数据一致性的问题 对于第一个问题，比较好解决，我们先看看一个tcp/ip协议链接建立的过程 我们的思路可以从这个上面出发，在简化一下，就一个请求，一个应答。 简单的通信模型是这样的 A

作业的必要性以及存在的问题 1. 为什么需要作业？ 作业即定时任务。一般来说，系统可使用消息传递代替部分使用作业的场景。两者确有相似之处。可互相替换的场景，如队列表。将待处理的数据放入队列表，然后使用频率极短的定时任务拉取队列表的数据并处理。这种情况使用消息中间件的推送模式可更好的处理实时性数据。而且基于数据库的消息存储吞吐量远远小于基于文件的顺序追加消息存储。 (点击放大图像) 但在某些场景下则不能互换： a) 时间驱动 OR 事件驱动：内部系统一般可以通过事件来驱动，但涉及到外部系统，则只能使用时间驱动。如：抓取外部系统价格。每小时抓取，由于是外部系统，不能像内部系统一样发送事件触发事件。 b) 批量处理 OR 逐条处理：批量处理堆积的数据更加高效，在不需要实时性的情况下比消息中间件更有优势。而且有的业务逻辑只能批量处理，如：电商公司与快递公司结算，一个月结算一次，并且根据送货的数量有提成。比如，当月送货超过1000则额外给快递公司多1%的快递费。 c) 非实时性 OR 实时性：虽然消息中间件可以做到实时处理数据，但有的情况并不需要。如：VIP用户降级，如果超过1年无购买行为，则自动降级。这类需求没有强烈的时间要求，不需要按照时间精确的降级VIP用户。 d) 系统内部 OR 系统解耦：作业一般封装在系统内部，而消息中间件可用于系统间解耦。 2. 当前常见的作业系统存在哪些问题？

一、基本简介 镜像服务（glance）使用户能够发现，注册和检索虚拟机镜像。 它提供了一个REST API，使您可以查询虚拟机镜像元数据并检索实际镜像。 您可以将通过镜像服务提供的虚拟机映像存储在各种位置，从简单的文件系统到对象存储系统（如OpenStack对象存储）。   为了简单起见，本指南描述了将Image服务配置为使用文件后端，该后端上载并存储在托管Image服务的控制节点上的目录中。 OpenStack Image服务是基础架构即服务（IaaS）的核心。 它接受磁盘或服务器映像的API请求，以及来自最终用户或OpenStack Compute组件的元数据定义。 它还支持在各种存储库类型（包括OpenStack对象存储）上存储磁盘或服务器映像。 OpenStack镜像服务包括以下组件： glance-api 接受镜像API调用以进行镜像发现，检索和存储。 glance-registry 存储，处理和检索有关镜像的元数据。 元数据包括例如大小和类型等项目。 Database 存储镜像元数据，您可以根据自己的喜好选择数据库。 大多数部署使用MySQL或SQLite。 Storage repository for image files（镜像文件的存储库） 支持各种存储库类型，包括常规文件系统（或安装在glance-api控制节点上的任何文件系统），Object Storage

场景描述: 　　小型电商网站，下单，生产有一定业务含义的唯一订单编号。 思路分析: 　　如果单台服务器已无法撑起并发量，怎么办？集群？ 　　 分布式锁的用途:　 　 　　 　　在分布式环境下协同共享资源的使用。 分布式锁的特点: 　　1.排他性: 只有一个线程能获取到。 　　2.阻塞性: 其他未抢到的线程阻塞，直到锁释放出来，在抢。 　　3.可重入性:线程获得锁后，后续是否可重复获取该锁。 我们掌握的计算机技术中，有哪些能提供排他性？ 　　1. 文件系统 　　2. 数据库: 主键 唯一约束 for update 　　3. 缓存redis: setnx 　　4. zookeeper: 类似文件系统 常用的分布式锁实现技术 　　1. 基于数据库实现分布式锁 　　　　性能较差。容易出现单点故障。 　　　　锁没有失效时间，容易死锁。 　　2. 基于缓存实现分布式锁 　　　　实现复杂 　　　　存在死锁 　　3. 基于zookeeper实现分布式锁 　　　　实现相对简单 　　　　可靠性高 　　　　性能较好　　 基于zookeeper实现分布式锁 　　方式一: 　　　 1.去获取锁创建节点 　　　2.获取锁成功,执行业务并且释放锁,等待唤醒。 　　　3. 获取锁失败,注册节点的watcher,阻塞等待,直到上一个成功获取锁释放到锁，才会取消watcher，尝试抢锁。 　　特性: 　　

1. 分布式锁 假设3个线程访问一个文件资源，对这个文件更新或读取操作，可以通过synchronized或lock进行线程同步，解决多线程情况下并发问题。 但是在分布式架构，都会是多模块独立部署不同机器，多进程情况下，怎么弄？ 比如3个系统，订单，发货，结算都要去操作同一个文件 分布式锁 1.通过数据库的方式解决 create table lock（ id methodname 唯一约束 ） 插入一条lock记录或得锁，删除这条lock这条记录，释放锁 1.1 弊端，删除失败，其他的进程都获取不到这个锁了 1.2 不是可重入锁，需要改造 2. 通过zookeeper 2.1 以树形结构存储数据 locks下面插入节点，零时有序节点 2.2 优势 有一个watch会监控节点，一个节点失效，会被删除，会启用用下一个节点 3. 基于redis 3.1 命令setnx，只会在key不存在的情况下为可以设置值，并且返回0或1，存在返回1，谁先设置这个值，谁先获取这个锁 来源： https://www.cnblogs.com/james0/p/9280457.html

分布式CAP理论 来自wiki: 在 理论计算机科学 中， CAP定理 （CAP theorem），又被称作 布鲁尔定理 （Brewer's theorem），它指出对于一个 分布式计算系统 来说，不可能同时满足以下三点：[ 1] [ 2] 一致性（ C onsistency） （等同于所有节点访问同一份最新的数据副本） 可用性 （ A vailability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据） 分区容错性 （ P artition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择[ 3] 。） 根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项[ 4] 。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。 来自 : 2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后，麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP。之后

　　Spark大数据平台有使用一段时间了，但大部分都是用于实验而搭建起来用的，搭建过Spark完全分布式，也搭建过用于测试的伪分布式。现在是写一遍随笔，记录一下曾经搭建过的环境，免得以后自己忘记了。也给和初学者以及曾经挖过坑的人用作参考。 　　Hive on Spark是Hive跑在Spark上，用的是Spark执行引擎，而不是默认的MapReduce。 　　可以查阅官网的资源 Hive on Spark: Getting Started 。 一 、安装基础环境 1.1 Java1.8环境搭建 　　 1) 下载jdk1.8并解压： # tar -zxvf jdk-8u201-linux-i586.tar.gz -C /usr/local 　　 2) 添加Java环境变量，在/etc/profile中添加： export JAVA_HOME=/usr/local/jdk1.8.0_201 export PATH=$PATH:$JAVA_HOME/bin export JRE_HOME=$JAVA_HOME/jre export CLASSPATH=.:$JAVA_HOME/lib:$JRE_HOME/lib 　　 3) 保存后刷新环境变量： # source /etc/profile 　　 4) 检查Java是否配置成功，成功配置会有如下图所示。 # java -version 1