分布式处理

很多学员都在反馈，说zk很难学，学的不是很明白，在这里，我继续带着大家详解一遍Zookeeper 首先zk是什么呢首先肯定是一个个分布式服务框架，是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用 中经常遇到的一些数据管理问题，如：统一命名服务、集群管理、分布式应用配置项的管理 等。 第二：Zookeeper是一个数据库 第三：Zookeeper是一个拥有一件系统特点的数据库 第四：Zookeeper是一个解决了数据一致性问题的分布式数据库 第五：Zookeeper是一个具有发布和订阅功能的分布式数据库 (watch) 这样说同学们应该都是认同的吧，没有异议的吧 那么这个一致性又是什么呢 一致性分为强一致性，弱一致性， 最终一致性 有些同学不是很懂哈，那就接着看下面的内容 强制要求步骤2读取的时候，一定要读取的是2，不能读取到的是1，那么要求数据库之间同步异常迅速或者在步骤2上加锁以等待数据同步完成，那么这种叫强一致性； 允许步骤2读取的时候，可以读取的是1，那么这种叫弱一致性，其实就是不需要要一致； 允许步骤2读取的时候，可以先读到 1，过一段时间再读到2，那么这种叫最终一致性，就是可以等待一段时间才一致； 一个集群需要对外部提供强一致性，所以只要集群内部某一台服务器的数据发生了改变，那么就需要等待集群内其他服务器的数据同步完成后才能正常的对外提供服务。

前言 相信大家对 ZooKeeper 应该不算陌生。但是你真的了解 ZooKeeper 是个什么东西吗？如果别人/面试官让你给他讲讲 ZooKeeper 是个什么东西，你能回答到什么地步呢？ 我本人曾经使用过 ZooKeeper 作为 Dubbo 的注册中心，另外在搭建 solr 集群的时候，我使用到了 ZooKeeper 作为 solr 集群的管理工具。前几天，总结项目经验的时候，我突然问自己 ZooKeeper 到底是个什么东西？想了半天，脑海中只是简单的能浮现出几句话：“①Zookeeper 可以被用作注册中心。 ②Zookeeper 是 Hadoop 生态系统的一员；③构建 Zookeeper 集群的时候，使用的服务器最好是奇数台。” 可见，我对于 Zookeeper 的理解仅仅是停留在了表面。 所以， 通过本文，希望带大家稍微详细的了解一下 ZooKeeper 。如果没有学过 ZooKeeper ，那么本文将会是你进入 ZooKeeper 大门的垫脚砖。如果你已经接触过 ZooKeeper ，那么本文将带你回顾一下 ZooKeeper 的一些基础概念。 最后， 本文只涉及 ZooKeeper 的一些概念，并不涉及 ZooKeeper 的使用以及 ZooKeeper 集群的搭建。 网上有介绍 ZooKeeper 的使用以及搭建 ZooKeeper 集群的文章

Hadoop分布式文件系统即Hadoop Distributed FileSystem。 当数据集的大小超过一台独立的物理计算机的存储能力时，就有必要对它进行分区（Partition）并存储到若干台单独的计算机上，管理网络中跨越多台计算机存储的文件系统成为分布式文件系统（Distributed FileSystem）。 该系统架构与网络之上，势必引入网络编程的复杂性，因此分布式文件系统比普通磁盘文件系统更为复杂。例如：使文件系统能够容忍节点故障且不丢数据便是一个极大的挑战。 Hadoop有一个成为HDFS的分布式文件系统，即Hadoop Distributed FileSystem。在非正式的文档或旧的文档中也叫着做DFS。HDFS是Hadoop的旗舰级文件系统，它实际上是一个综合性的文件系统的抽象。例如还可以集成其他文 件系统如Amazon S3或本地文件系统。 HDFS以流式数据访问模式来存储超大文件，运行在商用硬件集群上，特点如下： 1、超大文件存储 “超大文件”在这里指具有即便MB、几百GB、几百TB大小的文件，目前已经有了存储PB级别数据的Hadoop集群。（全球最大的Hadoop集群在雅虎，有大约25，000个节点，主要用于支持广告系统与网页搜索。） 2、流式数据访问 HDFS的构建思路是一次写入，多次读取是最高效的访问模式。数据集通常由数据源生成或从数据源复制而来

一、前言 最近系统上遇到一些问题，我又仔细去思考了一下CAP相关方面的东西，有点感悟想写篇文章，来好好思索下CAP这个东西； 二、先聊聊一聊我遇到的问题? 简单的说说我的场景，MQ推送消息过来以后写入redis，然后多个进程去消费redis中的数据，最后处理完成进入ES。最近更改一些需求，要求必须是只能生成一条明细，我们系统可能推送多次，我们通过缓存是可以判断出最早的一条，但是系统上线以后还是会出现多条，后来经过排查发现原来是MQ时序问题，导致最终生成2条明细，后来我采用使用唯一ID处理这个问题，中间还思考通过ES版本号处理的这种方式，最终还是采用唯一Id处理，这里我们不比较这两种方式好坏。还是要关注我们说主题分布式的思考，我只想通过我这例子来说说CAP到底是处理什么问题的？ 上图基本就是我们处理数据的流程，我省去了很多东西，比如分布式锁、缓存呀等等这些东西。我们单纯就借助这个模型来说说分布式的问题，A、B、C代表进程，我们都是分开部署多个节点在不同的机器上，类似于很多单体Web程序部署多台机器上通过Nginx分发处理请求，我们这些也都可以算是分布式系统，我们只是单纯自己玩，不相互联系而已，以一个不恰当的比喻来说最熟悉的陌生人。那CAP是处理什么问题的，大家可以看下 这篇文章 ，看不懂可以翻译下，当然我就是属于看不懂的，哈哈。摘录下其中比较重要的话，翻译过来以后是:

原文网址：http://geek.csdn.net/news/detail/97879 【 摘要 】本文谈及一些分布式系统的理论和思想，包括 CAP、BASE、NWR 等。并简单分析一些主流数据库分布式方案的利弊，以便我们在开发时更深入全面地进行思考、选择和设计。以下为正文： 在讨论常见架构前，先简单了解下 CAP 理论： CAP是Consistency、Availablity和Partition-tolerance的缩写。分别指： 一致性（Consistency）：每次读操作都能保证返回的是最新数据； 可用性（Availablity）：任何一个没有发生故障的节点，会在合理的时间内返回一个正常的结果； 分区容忍性（Partition-tolerance）：当节点间出现网络分区，照样可以提供服务。 CAP理论指出：CAP三者只能取其二，不可兼得。其实这一点很好理解： 首先，单机系统都只能保证CP； 有两个或以上节点时，当网络分区发生时，集群中两个节点不能互相通信。此时如果保证数据的一致性C，那么必然会有一个节点被标记为不可用的状态，违反了可用性A的要求，只能保证CP； 反之，如果保证可用性A，即两个节点可以继续各自处理请求，那么由于网络不通不能同步数据，必然又会导致数据的不一致，只能保证AP。 一、单实例 单机系统很显然，只能保证CP，牺牲了可用性A。单机版的MySQL、Redis

本文转自： https://www.cnblogs.com/bangerlee/p/5991417.html 本文转自 https://www.cnblogs.com/bangerlee/p/5268485.html 本系列文章将整理到我在GitHub上的《Java面试指南》仓库，更多精彩内容请到我的仓库里查看 https://github.com/h2pl/Java-Tutorial 喜欢的话麻烦点下Star哈 文章首发于我的个人博客： www.how2playlife.com 该系列博文会告诉你什么是分布式系统，这对后端工程师来说是很重要的一门学问，我们会逐步了解分布式理论中的基本概念，常见算法、以及一些较为复杂的分布式原理，同时也需要进一步了解zookeeper的实现，以及CAP、一致性原理等一些常见的分布式理论基础，以便让你更完整地了解分布式理论的基础，为后续学习分布式技术内容做好准备。 如果对本系列文章有什么建议，或者是有什么疑问的话，也可以关注公众号【Java技术江湖】联系作者，欢迎你参与本系列博文的创作和修订。 <!-- more --> 引言 《分布式系统理论进阶 - Paxos》 介绍了一致性协议Paxos，今天我们来学习另外两个常见的一致性协议——Raft和Zab。通过与Paxos对比，了解Raft和Zab的核心思想、加深对一致性协议的认识。 Raft

1 分布式系统模型 1.1 什么是分布式系统，分布式系统的目标 定义： 分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像是单个相关系统。 目标： 使资源可访问 透明性 开放性 可扩展性 1.2 为什么要分布式 经济性 微处理器能提供比大型机更好的性价比 速度 分布式系统能提供比大型机更强的计算能力 固有的分布性 有一些应用包含空间上分离的机器 可靠性 当某台机器崩溃时，整个系统仍能正常工作 可扩展性 计算能力逐步增加 1.3 分布式系统透明性和开放性的含义 透明性 定义： 在用户和应用程序面前呈现为单个计算机系统。 类型： 透明性 说明 访问 隐藏数据表示形式的不同以及资源访问访问的不同 位置 隐藏资源所在位置 迁移 隐藏资源是否移动到另一个位置 重定位 隐藏资源是否在使用过程中移动到另一个位置 复制 隐藏是否对资源进行复制 并发 隐藏资源是否由相互竞争用户共享 故障 隐藏资源的故障和恢复 透明度 将透明性和其他方面的问题结合起来考虑 开放性 不管底层环境如何，能够和其他开放系统进行交互 系统应该符合良好定义的接口 系统应该支持应用的可移植性 系统应该易于互操作 至少使分布式系统独立于底层环境的异构性 1.4 分布式操作系统、网络操作系统和基于中间件的系统 分布式操作系统 配置在分布式系统上的操作系统，能够直接对分布式系统中的各种资源进行动态分配

本文主要记录在分布式系统下优化的常用方法。 找到系统的性能瓶颈 这句话似乎是废话， 但是确实至关重要的。因为， 整个系统的性能瓶颈， 满足木桶效应， 最短的那根木板决定了桶里面能够容纳水的量。类似的， 系统的整体性能或者叫吞吐量， 取决于系统中性能最差的那个模块或者某个部分的代码， 可能是几个接口。 如果我们没有找到正确的性能瓶颈， 盲目的凭借经验或者感觉去定位性能瓶颈点， 很有可能忙乎了好长一阵， 但是没有任何提升， 因为最短板的地方没有任何修复。 定位性能瓶颈的方法 pstack 通常， 可以通过pstack查看正在运行中的进程的callstack， 如果多次都显示在某个位置， 那么很有可能相应的函数有问题， 可以重点分析一下。 借助工具 不同类型的问题有不同的工具， 需要具体问题具体分析。 类型 问题 工具 网络 网络连接 ping， netstat， traceroute， tcpdump 磁盘io 读写性能 iotop, iostat 内存 内存泄漏 valgrind, purify 内存 内存交换 free, top 给系统关键点埋点 有时候我们从工具无法分析出， 那个模块有性能问题， 或者我们刚刚接受一个新系统， 代码还不熟悉， 无法知道各个模块的具体交互量或者数据流量， 可以顺着main函数， 在各个调用函数的开头和结尾处加上性能埋点， 带引出某个函数执行的时间。

前言 最近的这段时间一直在学习Java EE，刚刚完成了从0到1的蜕变，所以顺便整理一下我所了解到的Java EE，给刚入门学习的新人一些头绪，而所谓“启示录”，就是这个意思。 一.Java EE是什么？ Java EE（Java Enterprise Edition）是一种 企业级应用的软件架构，同时是一种思想，一套规范。 二.Java EE的发展史 Java Enterprise Edition的发展不知不觉已经12年了，不知道大家有没留意，一开始，Java Enterprise Edition简称“J2EE”，直到版本5才改名为Java EE，而现在最新的版本则是Java EE 6。 到这里，或许有人会问，为什么会有这么多套Java EE规范？这些版本的差别是什么？ 1.J2EE1.2的出现，主要是将之前各个单独的规范绑定到一起。 2.J2EE1.3，则是继续完善J2EE体系结构。 3.J2EE1.4，主要是加入了一个重要主题：Web Service 4.而Java EE 5，主题则是“简化”，简化之前复杂的J2EE思想，改善开发体验。 三.Java EE到底要解决什么问题？ 1.Java EE解决什么问题？ 从Java EE发展背景看，它与“分布式应用”以及“互联网应用”的关系密不可分，而这两者也正是Java EE要解决的问题！ 其实

1. ElasticSearch ES即为了解决原生Lucene使用的不足，优化Lucene的调用方式，并实现了高可用的分布式集群的搜索方案，其第一个版本于2010年2月出现在GitHub上并迅速成为最受欢迎的项目之一。 首先，ES的索引库管理支持依然是基于Apache Lucene™的开源搜索引擎。 ES也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的 RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。 不过，ES的核心不仅仅在于Lucene，其特点更多的体现为： 分布式的实时文件存储，每个字段都被索引并可被搜索 分布式的实时分析搜索引擎 KB-MB-GB-TB-PB 可以扩展到上百台服务器，处理PB级结构化或非结构化数据 高度集成化的服务，你的应用可以通过简单的 RESTful API、各种语言的客户端甚至命令行与之 交互。 上手Elasticsearch非常容易。它提供了许多合理的缺省值，并对初学者隐藏了复杂的搜索引擎理论。它拥有开瓶即饮的效果（安装即可使用），只需很少的学习既可在生产环境中使用。 1.1 ES的使用者及类似框架 典型使用案例 全球程序员github – 中国码云 ①Github(美国)使用Elasticsearch搜索20TB的数据，包括13亿的文件和1300亿行的代码.