大数据学习第七天

目录

Zookeeper介绍与重点划分

  Zookeeper介绍

  重点划分

集群与分布式介绍

        集群

        分布式

        总结

CAP原则

        取舍策略

        CA without P 

        CP without A

         APwithout C

        BASE理论

        Basically Available（BA：基本可用）

        Soft state（S：软状态）

        Eventually consistent（E：最终一致性）         

        总结

数据的一致性

        定义

        模型

         强一致性

        弱一致性

        最终一致性

---

Zookeeper介绍与重点划分

  Zookeeper介绍

        Zookeeper是 Apache(阿帕奇)软件基金会的一个软件项目。它是一个为分布式应用提供一致性服务的软件，分布式应用程序可以基于Zookeeper实现数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。 Zookeeper现在是一个独立的顶级项目，而它曾经是Hadoop下的一个子项目。

  重点划分

        学习Zookeeper驻点要掌握Paxos算法，理清Zookeeper是如何实现自己集群内数据一致性 和 主要节点如何选主；

        理解Zookeeper在大数据中扮演的角色，以及Zookeeper如何帮助大数据其他组件完成选主。

集群与分布式介绍

        集群

        将一个任务部署在多个服务器，每个服务器都能独立完成该任务。例如：饭店后厨有三个厨师，他们每个人都会洗菜、切菜和炒菜，即使饭店同时来了很多客人也能轻松应对，这就是集群

        分布式

        将一个任务拆分成若干个子任务，由若干个服务器分别完成这些子任务，每个服务器只能完成某个特定的子任务。例如：饭店后厨有三个厨师，洗菜、切菜和炒菜三个子任务分别由每个人独立完成，一个人洗菜，一个人切菜，一个人炒菜，这就是分布式。

        从概念上就可以看出两者最主要的区别就是分布式是将一种业务拆分成多个子业务部署在多台服务器上，进而对外提供服务；而集群就是将多台服务器组合在一起提供同一种服务。

        集群强调在多台服务器位置集中，并且容易统一管理；而分布式没有具体要求，不论放置在哪个位置，只要通过网络连接起来就行

        集群是一种物理形态，即多台服务器在一起提供一种服务；而分布式是一种工作方式，即一个程序或业务分解到多台服务器分别完成。

        总结

        集群 是通过 提高单位时间 内 执行的任务数 来提升效率， 分布式 是以 缩短单个任务 的 执行时间 来提升效率。

CAP原则

        CAP 原则又称 CAP 定理，指的是在一个分布式系统中，

Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）

，三者不可得兼。

        取舍策略

        CAP的三个特征只能满足其中两个，那么取舍策略就有三种：

        CA without P 

        如果不要求 P（不允许分区），则 C（强一致性）和 A（可用性）是可以保证的。但放弃 P 的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。

        CP without A

        如果不要求 A （可用），相当于每个请求都需要在服务器之间保持强一致，而 P （分区）会导致同步时间无限延长（也就是等待数据同步完才能正常访问服务）

        一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成 CP 的系统其实不少，最典型的就是分布式数据库。

        对于分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。

         APwithout C

        要高可用并允许分区，则需放弃一致性。一旦产生分区，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。

        典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

        总而言之，没有最好的策略，好的系统应该是根据业务场景来进行架构设计的，只有适合的才是最好的。

        BASE理论

        BASE理论全称是：

 Basically Available（基本可用），Soft state（软状态），和 Eventually consistent（最终一致性）三个短语的缩写，来自ebay 的架构师提出。

        BASE理论是对CAP中一致性和可用性权衡的结果，其来源对于大型互联网分布式实践的总结，是基于CAP定理逐步演化而来的，核心思想是：.

        既然无法做到强一致性（Strong consistency ），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency ）。

        Basically Available（BA：基本可用）

        基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性、服务限流、服务降级、服务熔断……）。需要注意的是，基本可用绝不等价于系统不可用。

        响应时间上的损失：正常情况下搜索引擎需要在 0.5 秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了 1~2 秒。

        功能上的损失：：购物网站在购物高峰（如双十一）时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面。

        Soft state（S：软状态）

        软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本数据同步的延时就是软状态的体现。

        必须大于二分之一的服务器同时写入

        相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。

        Eventually consistent（E：最终一致性）         

        系统不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制方案设计等等因素。

        总结

        总的来说，BASE 理论面向的是大型高可用可扩展的分布式系统，和传统事务的 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间是不一致的。

数据的一致性

        定义

        一些分布式系统通过复制数据来提高系统的可靠性和容错性，并且将数据的不同的副本存放在不同的机器

        在数据有多份副本的情况下，如果网络、服务器或者软件出现故障，会导致部分副本写入成功，部分副本写入失败。这就造成各个副本之间的数据不一致，数据内容冲突。

        模型

         强一致性

        要求无论更新操作实在哪一个副本执行，之后所有的读操作都要能获得最新的数据。

        弱一致性

        用户读到某一操作对系统特定数据的更新需要一段时间，我们称这段时间为“不一致性窗口”。

        最终一致性

        是弱一致性的一种特例，保证用户最终能够读取到某操作对系统特定数据的更新。

        从客户端来看，有可能暂时获取的不是最新的数据，但是最终还是能访问到最新的

        从服务端来看，数据存储并复制到整个系统超过半数的节点，以保证数据最终一致

        今天就先写这些，关于Paxos算法，我还要在整理一下