分布式处理

1.1. 分布式系统基础知识 一个 tomcat 打天下的时代，不能说完全淘汰了，在一个管理系统，小型项目中还经常使用，这并不过分，出于成本的考虑，这反而值得提倡。 1.1.1. 分布式系统是什么 分布式系统：一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统 这是分布式系统，在不同的硬件，不同的软件，不同的网络，不同的计算机上，仅仅通过消息来进行通讯与协调 这是他的特点，更细致的看这些特点又可以有：分布性、对等性、并发性、缺乏全局时钟、 故障随时会发生。 1.1.1.1. 分布性 既然是分布式系统，最显著的特点肯定就是分布性，从简单来看，如果我们做的是个电商项目，整个项目会分成不同的功能，专业点就不同的微服务，比如用户微服务，产品微服务，订单微服务，这些服务部署在不同的 tomcat 中，不同的服务器中，甚至不同的集群中，整个架构都是分布在不同的地方的，在空间上是随意的，而且随时会增加，删除服务器节点，这是第一个特性 1.1.1.2. 对等性 对等性是分布式设计的一个目标，还是以电商网站为例，来说明下什么是对等性，要完成一个分布式的系统架构，肯定不是简单的把一个大的单一系统拆分成一个个微服务，然后部署在不同的服务器集群就够了，其中拆分完成的每一个微服务都有可能发现问题，而导致整个电商网站出现功能的丢失。 比如订单服务，为了防止订单服务出现问题

HDFS 简单介绍 HDFS 的英文全称是Hadoop Distributed File System，顾名思义，就是 Hadoop 分布式文件系统，是根据 Google 的 GFS 的论文，由 Doug Cutting 使用 Java 开发的开源项目。 HDFS 本身是 H adoop 项目的一部分，为 Hadoop 提供了底层的数据存储，以供上层的各种实际应用使用（如 Map/Reduce ）。 HDFS 是典型的 Master/Slave 集群架构，由一个 NameNode 和多个 DataNode 组成， NameNode 只能是一个，扮演着 Master 的角色，负责对具体存储块的元数据进行保存，如某个存储块具体保存在哪个 DataNode 上； DataNode 可以为多个，扮演着 Slave 的角色，负责对具体的存储块进行保存，一个相同的存储块根据配置可以保存到多个 DataNode 上，以保持数据的高可用性。客户端与 HDFS 交互时，典型的，会先询问 NameNode 具体的存储块在哪个 DataNode 上，然后客户端会直接联系相应的 DataNode ，来获取或写入数据。各个 DataNode 会定时发送心跳至 NameNode ，以便 NameNode 了解 DataNode 的可用状态及存储状态，这样可以保证某一个 DataNode 挂掉，

一、首先了解下集群、分布式和微服务之间的异同： 1、集群： 集群的意思就是将一个应用程序，部署到多台服务器上面，然后在这些服务器的前面通过负载均衡服务器来择优选择哪一台服务器去执行；集群的优点就是当其中的一个服务器宕机了，其他服务器可以接上继续工作；将应用程序部署在多台服务器时，也提供了数据的吞吐量。 2、分布式： 可以将分布式理解为，将某一个应用程序，拆分成多个模块来部署，各个模块负责不同的功能；分布式的优点是细化了应用程序的功能模块，同时也减轻了一个完整的应用程序部署在一台服务器上的负担，用了分布式拆分后，就相当于把一个应用程序的多个功能分配到多台服务器上去处理了。 3、微服务： 微服务是架构设计方式，分布式是系统部署方式， SOA架构强调的是异构系统之间的通信和解耦合，而微服务架构强调的是系统按业务边界做细粒度的拆分和部署。 微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。 微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想。 二、分布式要解决什么问题呢？ 解决持久化数据太大，单个节点的硬盘无法存储的问题；解决运算量太大，单个节点的内存、CPU无法处理的问题。解决这些问题，有两种思路：scale up，scale

“数据不能丢，服务不能停”，可以说这句话道出了用户对数据库的核心能力的要求。然而，传统的商业数据库必须依赖高可靠的硬件才能实现数据可靠性和服务可用性。OceanBase作为一款成熟的企业级分布式数据库，基于普通PC服务器，就能够做到传统高端硬件环境下的数据可靠性和服务可用性，而且还能做得更好！跟我们一起看看OceanBase的技术秘诀吧！ Part1 前言 说到数据可靠性和服务可用性，在数据库领域真是老生常谈的话题，可以说从数据库诞生之日起就如影随形。如果要用一句话来概括数据库对数据可靠性和服务可用性的要求，可以借用OceanBase数据库创始人阳振坤老师的一句话：“数据不能丢，服务不能停”。可以说，这句话也道出了用户对数据库的一个核心能力要求：除了功能完善、使用方便之外，还要绝对安全、足够健壮。可以说，为了满足这两个看似简单的要求，在数据库领域诞生了大量的技术和论文，也让无数人绞尽了脑汁。 在传统的商业数据库产品（如Oracle、DB2）中，虽然也有一些行之有效的软件技术（如Redo Log、主从热备技术等）用来提高数据可靠性和服务可用性，但整体来说对硬件的稳定性有很强的依赖。而传统的企业级服务器（如IBM 的Mainframe、AS400、Power等）和EMC、IBM等厂商的高端存储产品，能够很好的保证硬件的稳定性，因此也就成为了Oracle为代表的传统数据库产品的理想平台

1、业务服务器是一主多从，负载均衡。 2、对于客户端的请求，负载均衡的模式是NAT(Netwotk Address Translation)，网络地址转换模式，和linux中LVS的NAT道理一样。客户端只向Master进程发请求，Master根据负载均衡算法，找出哪个Slave负责，发给对应的Slave，Slave处理完之后，在回给Master，Master再回给客户端，客户端感觉不到Slave的存在。 3、考虑下面的场景，一主多从，每个Slave服务器都从下面收到大量的告警和实时数据，如果这些告警和实时数据都汇总到Master，再由Master发给客户端，显然Master这里存在瓶颈。怎么解决这个问题？ 使用IP隧道（IP Tunneling）模式，和linux中LVS的IP隧道道理类似。只不过这里没有请求的过程。在客户端提供sdk，进行封装，sdk会向Master请求所有的Slave，Master报告所有的Slave，sdk分别去连接这些Slave，这个时候，每个Slave都与客户端有一个连接，Slave通过这个连接直接将告警或者实时数据上报给sdk，客户端从sdk回调，得到数据。 转载于:https://www.cnblogs.com/nzbbody/p/4542248.html 来源： https://blog.csdn.net/weixin_30468137

首先我们来认识一下HDFS， HDFS（Hadoop Distributed File System ）Hadoop分布式文件系统。它其实是将一个大文件分成若干块保存在不同服务器的多个节点中。通过联网让用户感觉像是在本地一样查看文件，为了降低文件丢失造成的错误，它会为每个小文件复制多个副本（默认为三个），以此来实现多机器上的多用户分享文件和存储空间。 Hadoop主要包含三个模块： HDFS模块：HDFS负责大数据的存储，通过将大文件分块后进行分布式存储方式，突破了服务器硬盘大小的限制，解决了单台机器无法存储大文件的问题，HDFS是个相对独立的模块，可以为YARN提供服务，也可以为HBase等其他模块提供服务。 YARN模块：YARN是一个通用的资源协同和任务调度框架，是为了解决Hadoop中MapReduce里NameNode负载太大和其他问题而创建的一个框架。YARN是个通用框架，不止可以运行MapReduce，还可以运行Spark、Storm等其他计算框架。 MapReduce模块：MapReduce是一个计算框架，它给出了一种数据处理的方式，即通过Map阶段、Reduce阶段来分布式地流式处理数据。它只适用于大数据的离线处理，对实时性要求很高的应用不适用。多相关信息可以参考博客： 初识HDFS（10分钟了解HDFS、NameNode和DataNode） 。

为什么需要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所示。 　　给大家分析一下这张图，在这图中有三台机器，每台机器各跑一个应用程序。然后我们将这三台机器通过网络将其连接起来，构成一个系统来为用户提供服务，对用户来说这个系统的架构是透明的

一、分布式锁 　　分布式锁是在分布式场景下一种常见技术，通常通过基于redis和zookeeper来实现，本文主要介绍redis分布式锁和zookeeper分布式锁的实现方案和对比： 　　（1）基于redis的普通实现 　　这个方案的加锁主要实现是基于redis的”SET key 随机值 NX PX 过期时间（毫秒）”指令，NX代表只有key不存在时才设置成功，PX代表在过期时间后会自动释放。 　　这个方案的释放锁是通过lua脚本删除key的方式，判断value一样则删除key。 　　使用随机值的原因是如果某个获取到锁的客户端阻塞了很长时间，导致了它获取到的锁已经自动释放，此时可能有其他客户端已经获取到了锁，如果直接删除是有问题的，所以要通过随机值加上lua脚本去判断如果value相等时再删除。 　　这个方案存在一个问题就是，如果采用redis单实例可能会存在单点故障问题，但如果采用普通主从方式，如果主节点挂了key还没来得及同步到从节点，此时从节点被切换到了主节点，由于没有同步到数据别人就会拿到锁。 　　（2）redis的RedLock算法 　　这个方案是redis官方推荐的分布式锁的解决方案，假设有5个redis master实例，然后执行如下步骤去获取一把锁： 　　1）获取当前时间戳，单位是毫秒 　　2）跟上面类似，轮流尝试在每个master节点上创建锁，过期时间较短

分布式文件系统 分布式文件系统：当数据集的大小超过一台独立物理计算机的存储能力时，就有必要对它进行分区（partition）并存储到若干台单独的计算机上。管理网络中夸多台计算机存储的文件系统。这种系统构架于网络之上，肯定会引入网络编程的复杂性，因此它比普通的磁盘文件系统更为复杂。 我们首先来简单的说明一下这个分布式，我们都知道现在要存储的数据量越来越大，但是一台电脑的存储能力是有限的，尽管我们可以通过提高某台电脑的存储能力来解决这个问题，但是这是无法根本解决这个问题，所以我们通过很多很多台廉价的电脑来分布式存储这些数据。简单说就是把要存的文件分割成一份一份存到许多台电脑上。 Google File System： 是由google开发并设计的一个面向大规模数据处理的一个分布式文件系统。 为了满足Google迅速增长的数据处理需求，Google设计并实现了Google文件系统。它是有几百甚至几千台普通的廉价设备组装的存储机器。以下是一些设计思路。 1）我们知道有这么多机器，那么这些设备中的某些机器出现故障是很常见的事情，所以在GFS要集成持续的监控、错误侦测、灾难冗 余以及自动恢复的机制。 2）我们要存的数据大小是很大，所以要是按照以往的存储文件块大小，那么就要管理数亿个KB大小的小文件，这是很不合理的，所以在这个系统里面他们定义一个文件块的大小是64M。 3