分布式处理

一、ZooKeeper的背景 1.1 认识ZooKeeper ZooKeeper---译名为“动物园管理员”。动物园里当然有好多的动物，游客可以根据动物园提供的向导图到不同的场馆观赏各种类型的动物，而不是像走在原始丛林里，心惊胆颤的被动 物所观赏。为了让各种不同的动物呆在它们应该呆的地方，而不是相互串门，或是相互厮杀，就需要动物园管理员按照动物的各种习性加以分类和管理，这样我们才能更加放心安全的观赏动物。 回到企业级应用系统中，随着信息化水平的不断提高，企业级系统变得越来越庞大臃肿，性能急剧下降，客户抱怨频频。拆分系统是目前我们可选择的解决系统可伸缩性和性能问题的唯一行之有效的方法。但是拆分系统同时也带来了系统的复杂性——各子系统不是孤立存在的，它们彼此之间需要协作和交互，这就是我们常说的分布式系统0。各个子系统就好比动物园里的动物，为了使各个子系统能正常为用户提供统一的服务，必须需要一种机制来进行协调——这就是ZooKeeper（动物园管理员）。 1.2 为什么使用ZooKeeper 我们知道要写一个分布式应用是非常困难的，主要原因就是局部故障。一个消息通过网络在两个节点之间传递时，网络如果发生故障，发送方并不知道接收方是否接收到了这个消息。他可能在网络故障迁就收到了此消息，也坑没有收到，又或者可能接收方的进程死了。发送方了解情况的唯一方法就是再次连接发送方，并向他进行询问

ZooKeeper是 Hadoop Ecosystem中非常重要的组件，它的主要功能是为分布式系统提供一致性协调(Coordination)服务，与之对应的Google的类似服务叫Chubby。今天这篇文章分为三个部分来介绍ZooKeeper，第一部分介绍ZooKeeper的基本原理，第二部分介绍ZooKeeper提供的Client API的使用，第三部分介绍一些ZooKeeper典型的应用场景。 ZooKeeper基本原理 1. 数据模型 如上图所示，ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每个ZNode都可以通过其路径唯一标识，比如上图中第三层的第一个ZNode, 它的路径是/app1/c1。在每个ZNode上可存储少量数据(默认是1M, 可以通过配置修改, 通常不建议在ZNode上存储大量的数据)，这个特性非常有用，在后面的典型应用场景中会介绍到。另外，每个ZNode上还存储了其Acl信息，这里需要注意，虽说ZNode的树形结构跟Unix文件系统很类似，但是其Acl与Unix文件系统是完全不同的，每个ZNode的Acl的独立的，子结点不会继承父结点的，关于ZooKeeper中的Acl可以参考之前写过的一篇文章《 说说Zookeeper中的ACL 》。 2.重要概念 2.1 ZNode 前文已介绍了ZNode

简单阐述一下自己对分布式事物的理解，如有错误欢迎指正： 刚性事物：即ACID这里不做过多解释，有不明白的同学建议快速掌握。 柔性事物：简单来说为运行过程不一致但最终保持一致。 一、产生原因： 　　分布式(微服务)系统中之间的跨库访问(例：商城项目中的会员数据库，订单数据库，支付数据库等、、、)与同一项目多数据源不同，使用于分布式系统后类似SOA接口之间调用时产生。 二、解决原理： 1）、CAP原理(即：一致性，可用性，分区容错性) 一致性：当系统对一个数据进行写操作时成功后，在查询则必须是改动后的值，当写操作失败也就必须查不多新值，在单机项目中又叫原子性。 　　 可用性：服务可用性，就是说所有的读写请求在一定时间内要得到响应，不能一直等待下去。 　　 分区容错性：指在分布式、微服务系统中，当 部分服务宕机后，其他核心服务能够不受影响能够继续提供服务。 2）、BAS理论： 　 采用CAP演化而来，是对CAP中一致性和可用性权衡的结果，核心思想是：即使无法做到强一致性，但每个业务根据自身的特点，采用适当的方式来使系统达到最终一 　　致 性。主要有以下状态： 　　 基本可用：在分布式系统出现故障时，允许损失部分可用性，保证核心可用，例如：一个服务正常响应时间为：2秒之内，在访问量大时可采用可对部分用户进行降级处理 　　 软状态：允许系统存在中间状态，并且该状态不会允许系统整体可用性

课程介绍 微服务架构的技术体系、社区目前已经越来越成熟。在最初系统架构的搭建，或者当现有架构已到达瓶颈需要进行架构演进时，很多架构师、运维工程师会考虑是否需要搭建微服务架构体系。虽然很多文章都说微服务架构是复杂的、会带来很多分布式的问题，但只要我们了解这些问题，并找到解法，就会有种拨开云雾的感觉。 微服务架构也不是完美的，世上没有完美的架构，微服务架构也是随着业务、团队成长而不断演进的。最开始可能就几个、十几个微服务，每个服务是分库的，通过 API Gateway 并行进行服务数据合并、转发。随着业务扩大、不断地加入搜索引擎、缓存技术、分布式消息队列、数据存储层的数据复制、分区、分表等。 本课程会一一解开微服务架构下分布式场景的问题，以及通过对于一些分布式技术的原理、模型和算法的介绍，来帮助想要实施微服务架构的工程师们知其然并知其所以然。并且，本课程通过对分布式问题的体系化梳理，结合一些方案的对比选型，可以让工程师们一览微服务的知识图谱。 注：为了方便初学者理解微服务实践，以及掌握怎样在微服务中使用 DDD（Domain-Driven Design）思想，在本课程第 05 课中讲解了 Demo 示例，该示例是基于 Spring Boot、Spring Cloud Eureka 技术写的，Microservice 代码详见这里，Gateway 代码详见这里。 专家推荐

TBase 是腾讯数据平台团队在开源的 PostgreSQL 基础上研发的企业级分布式 HTAP 数据库管理系统： 具备高性能可扩展的分布式事务能力，支持 RC 和 RR 两种隔离级别； 通过安全、管理、审计三权分立体系，提供全方位的数据安全保证机制； 支持高性能分区表，可使得数据检索效率成倍提升； SQL 方面兼容 2003 标准、PostgreSQL 语法和常用 Oracle 函数&数据类型、窗口函数等； 提供大小商户数据分离、冷热数据分离等高效的数据治理能力 TBase 架构： 集群中有三种节点类型，各自承担不同的功能，通过网络连接成为一个系统。这三种节点类型分别是： Coordinator：协调节点，对外提供接口，负责数据的分发和查询规划，多个节点位置对等，每个节点都提供相同的数据库视图，CN 存储系统的全局元数据。 Datanode：处理存储本节点相关的元数据，每个节点还存储数据的一个分片。在功能上，DN 节点负责完成执行协调节点分发的执行请求。 GTM: 全局事务管理器(Global transaction manager.)，负责管理集群事务信息，同时管理集群的全局对象，比如序列，除此之外 GTM 上不提供其他的功能。 TBase 功能介绍： 分布式事务全局一致性能力：通过拥有自主专利的分布式事务一致性技术，包括两阶段提交(Two Phase Commit

Eureka、Consul、Zookeeper的基本原理与比较。 前言 在云计算和容器化技术发展火热的当下，对于微服务架构，服务注册与发现组件是必不可少的。在传统的服务架构中，服务的规模处于运维人员的可控范围内。当部署服务的多个节点时，一般使用静态配置的方式实现服务信息的设定。在微服务应用中，服务实例的数量和网络地址都是动态变化的，这对系统运维提出了巨大的挑战。因此，动态的服务注册与发现就显得尤为重要。 解决的问题 在一个分布式系统中，服务注册与发现组件主要解决两个问题：服务注册和服务发现。 服务注册：服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port，以及暴露服务自身状态以及访问协议等信息。 服务发现：服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。 除此之外，服务注册与发现需要关注监控服务实例运行状态、负载均衡等问题。 监控：微服务应用中，服务处于动态变化的情况，需要一定机制处理无效的服务实例。一般来讲，服务实例与注册中心在注册后通过心跳的方式维系联系，一旦心跳缺少，对应的服务实例会被注册中心剔除。 负载均衡：同一服务可能同时存在多个实例，需要正确处理对该服务的负载均衡。 CAP CAP原则，指的是在一个分布式系统中，Consistency(一致性)

什么是Nagios? Nagios是一款开源的网络及服务的监控工具，功能强大，灵活性强，需要注意的是，其服务端只能在linux上面安装。 Nagios可以进行分布式监控。 这里主要解释一下什么叫分布式？什么是集群？什么是分布式计算? 分布式：不同的业务模块部署在不同的服务器上或者同一个业务模块分拆多个子业务，部署在不同的服务器上，解决高并发的问题。 集群：同一个业务部署在多台机器上，提高系统可用性。 所谓分布式计算是一门计算机科学，它研究如何把一个需要非常巨大的计算能力才能解决的问题分成许多小的部分，然后把这些部分分配给许多计算机进行处理，最后把这些计算结果综合起来得到最终的结果。 打个比方，一个任务由5个子任务组成，暂且五个子任务都是独立的，异步的。一个子任务如果需要1个小时完成，那么我只需要将5个子任务分配到5个机器上，那么就是一小时完成了这个任务，这就是分布式，解决的是高并发。 那么集群，就是将一群机器集合起来，完成一个任务。如果一个任务的机器跨了，可以通过其他机器替代，讲究的是可用性。 在网上看到，现在讲的各种云计算，说白了就是集群和分布式的一些应用。 分布式是指将不同的业务分布在不同的地方。 而集群指的是将几台服务器集中在一起，实现同一业务。分布式中的每一个节点，都可以做集群。 而集群并不一定就是分布式的。（也可以是分布式，比如你布置多个集群咯！） 举个例子：

1、Zookeeper 的由来 在Hadoop生态系统中，许多项目的Logo都采用了动物，比如 Hadoop 和 Hive 采用了大象的形象，HBase 采用了海豚的形象，而从字面上来看 ZooKeeper 表示动物园管理员，所以大家可以理解为 ZooKeeper就是对这些动物（项目组件）进行一些管理工作的。 对于单机环境多线程的竞态资源协调方法，我们一般通过线程锁来协调对共享数据的访问以保证状态的一致性。 但是分布式环境如何进行协调呢？于是，Google创造了Chubby，而ZooKeeper则是对于Chubby的一个开源实现。 ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务，它提供了一项基本服务：分布式锁服务。由于ZooKeeper的开源特性，后来我们的开发者在分布式锁的基础上，摸索了出了其他的使用方法：配置维护、组服务、分布式消息队列、分布式通知/协调等。它被设计为易于编程，使用文件系统目录树作为数据模型。 2、ZooKeeper集群模式典型架构 2.1 角色 Zookeeper服务自身组成一个集群(2n+1个服务允许n>=1个失效)。Zookeeper集群是一个基于主从复制的高可用集群，每个服务器承担如下三种角色中的一种 Leader 一个Zookeeper集群同一时间只会有一个实际工作的Leader

GlusterFS概述 GlusterFS（Gluster File System）是一个开源的分布式文件系统，主要由Z RESEARCH公司负责开发、是Scale-Out存储解决方案Gluster的核心，它是一个开源的分布式文件系统，在存储方面具有强大的横向扩展能力，通过扩展不同的节点可以支持数PB存储容量和处理数干台客户端。GlusterFS借助TCP/IP或InfiniBand RDMA网络将物理分布的存储资源聚集在一起，使用单一全局命名空间来管理数据。GlusterFS基于可堆叠的用户空间及无元的设计，可为各种不同的数据负载提供优异的性能。 GlusterFS主要由存储服务器（Block Server）、客户端及NFS/Samba存储网关（可选，根据需要选择使用）组成，GlusteFS架构中最大的设计特点是没有元数据服务器组件，这有助于提升整个系统的性能、可靠性和稳定性。 GlusterFS主要特征如下： 扩展性和高性能 高可用性 全局统一命名空间 弹性哈希算法 弹性卷算法 基于标准协议 GlusterFS的卷类型： GlusterFS支持七种卷，分布式卷、条带卷、复制卷、分布式条带卷、分布式复制卷、条带复制卷和分布式条带复制卷，这七种卷可以满足不同应用对高性能、高可用的需求。 1.分布式卷 分布式卷是GlusterFS的默认卷，在创建卷时，默认选项是创建分布式卷

http://www.cnblogs.com/edisonchou/ 《大型网站技术架构》读书笔记之六：永无止境之网站的伸缩性架构 此篇已收录至 《大型网站技术架构》读书笔记系列目录 贴，点击访问该目录可获取更多内容。 首先，所谓网站的伸缩性，指 不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力 。在整个互联网行业的发展渐进演化中，最重要的技术就是 服务器集群 ，通过不断地向集群中添加服务器来增强整个集群的处理能力。 一、网站架构的伸缩性设计 1.1 不同功能进行物理分离实现伸缩 　　（1）纵向分离：将业务处理流程上得不同部分分离部署，实现系统的伸缩性； 　　（2）横向分离：将不同的业务模块分离部署，实现系统的伸缩性； 1.2 单一功通过集群规模实现伸缩 　　使用服务器集群，即将相同服务部署在多台服务器上构成一个集群整体对外提供服务。具体来说，集群伸缩性又分为应用服务器集群伸缩性和数据服务器集群伸缩性。这两种集群对于数据状态管理的不同，技术实现也有很大的区别。 　It is said that 当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车 。 二、应用服务器集群的伸缩性设计 2.1 应用服务器那点必须知道的事儿 　　（1）应用服务器应该被设计成 无状态 的，即应用服务器不存储请求上下文信息；构建集群后