分布式

、下载scala2.11.5版本，下载地址为： http://www.scala-lang.org/download/2.11.5.html 2、安装和配置scala： 第一步：上传scala安装包 并解压 第二步 配置SCALA_HOME环境变量到bash_profile 第三步 source 使配置环境变量生效： 第四步 验证scala： 3、下载spark 1.2.0，具体下载地址： http://spark.apache.org/downloads.html 4、安装和配置spark： 第一步 解压spark： 第二步 配置SPARK_HOME环境变量： 第三步 使用source生效： 进入spark的conf目录： 第四步 修改slaves文件，首先打开该文件： slaves修改后： 第五步 配置spark-env.sh 首先把spark-env.sh.template拷贝到spark-env.sh： 然后 打开“spark-env.sh”文件： spark-env.sh文件修改后： 5、启动spark伪分布式帮查看信息： 第一步 先保证hadoop集群或者伪分布式启动成功，使用jps看下进程信息： 如果没有启动，进入hadoop的sbin目录执行 ./start-all.sh 第二步 启动spark： 进入spark的sbin目录下执行“start-all.sh”：

分布式设计与开发中有些疑难问题必须借助一些算法才能解决，比如分布式环境一致性问题，感觉以下分布式算法是必须了解的（随着学习深入有待添加）： Paxos算法 一致性Hash算法 Paxos算法 1）问题描述 分布式中有这么一个疑难问题，客户端向一个分布式集群的服务端发出一系列更新数据的消息，由于分布式集群中的各个服务端节点是互为同步数据的，所以运行完客户端这系列消息指令后各服务端节点的数据应该是一致的，但由于网络或其他原因，各个服务端节点接收到消息的序列可能不一致，最后导致各节点的数据不一致。举一个实例来说明这个问题，下面是客户端与服务端的结构图： 当client1、client2、client3分别发出消息指令A、B、C时，Server1~4由于网络问题，接收到的消息序列就可能各不相同，这样就可能由于消息序列的不同导致Server1~4上的数据不一致。对于这么一个问题，在分布式环境中很难通过像单机里处理同步问题那么简单，而Paxos算法就是一种处理类似于以上数据不一致问题的方案。 2）算法本身 算法本身我就不进行完整的描述和推导，网上有大量的资料做了这个事情，但我学习以后感觉莱斯利·兰伯特（Leslie Lamport，paxos算法的奠基人，此人现在在微软研究院）的 Paxos Made Simple 是学习paxos最好的文档

（一）spark 相关安装部署、开发环境 1、 Spark 伪分布式 & 全分布式 安装指南 http://my.oschina.net/leejun2005/blog/394928 2、 Apache Spark探秘：三种分布式部署方式比较 http://dongxicheng.org/framework-on-yarn/apache-spark-comparing-three-deploying-ways/ 3、idea上运行local的spark sql hive http://dataknocker.github.io/2014/10/11/idea%E4%B8%8A%E8%BF%90%E8%A1%8Clocal%E7%9A%84spark-sql-hive/ 4、Apache Spark学习：利用Scala语言开发Spark应用程序 http://dongxicheng.org/framework-on-yarn/spark-scala-writing-application/ 5、 如何在CDH5上运行Spark应用（Scala、Java、Python） http://blog.javachen.com/2015/02/04/how-to-run-a-simple-apache-spark-app-in-cdh-5/ 6、Spark集群安装和使用 http://blog

以下操作在 Hadoop 分布式集群基础上进行。 一。分布式环境搭建 下载： http://www.apache.org/dyn/closer.cgi/hbase/ ， hbase-0.98.0-hadoop2-bin.tar.gz 。 1. 在 master 主控机安装 HBase 1 ）解压 SHELL$ tar -zxvf hbase-0.98.0-hadoop2-bin.tar.gz SHELL$ mv hbase-0.98.0-hadoop2 ~/hbase0.98.0hadoop2 2 ）配置环境变量 （ 1 ）修改 /etc/profile 文件 SHELL$ sudo gedit /etc/profile （2）验证 3 ）修改 %HBASE%/conf/hbase-env.sh 4 ）修改 $HBASE_HOME/conf/hbase-site.xml <?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="configuration.xsl"?> <configuration> <property> <!-- hbase的master主机名和端口 --> <name>hbase.master</name> <value>hdfs://192.168.1.240:60000</value> <

来源： 伯乐在线 - HollisChuang 链接：http://blog.jobbole.com/95632/ 随着大型网站的各种高并发访问、海量数据处理等场景越来越多，如何实现网站的高可用、易伸缩、可扩展、安全等目标就显得越来越重要。 为了解决这样一系列问题，大型网站的架构也在不断发展。提高大型网站的高可用架构，不得不提的就是分布式。在《分布式系统的一致性探讨》一文中主要介绍了分布式系统中存在的一致性问题。本文将简单介绍如何有效的解决分布式的一致性问题，其中包括什么是 分布式事务，二阶段提交和三阶段提交 。 分布式一致性回顾 在分布式系统中，为了保证数据的高可用，通常，我们会将数据保留多个副本(replica)，这些副本会放置在不同的物理的机器上。为了对用户提供正确的增\删\改\差等语义，我们需要保证这些放置在不同物理机器上的副本是一致的。 为了解决这种分布式一致性问题，前人在性能和数据一致性的反反复复权衡过程中总结了许多典型的协议和算法。其中比较著名的有 二阶提交协议 （Two Phase Commitment Protocol）、 三阶提交协议 （Two Phase Commitment Protocol）和 Paxos算法 。 分布式事务 分布式事务是指会涉及到操作多个数据库的事务。其实就是将对同一库事务的概念扩大到了对多个库的事务

在分布式算法领域，有个非常重要的算法叫Paxos, 它的重要性有多高呢，Google的Chubby [1]中提到 all working protocols for asynchronous consensus we have so far encountered have Paxos at their core. 关于Paxos算法的详述在维基百科中有更多介绍，中文版介绍的是choose value的规则[2]，英文版介绍的是Paxos 3 phase commit的流程[3]，中文版不是从英文版翻译而是独立写的，所以非常具有互补性。Paxos算法是由Leslie Lamport提出的，他在Paxos Made Simple[4]中写道 The Paxos algorithm, when presented in plain English, is very simple. 当你研究了很长一段时间Paxos算法还是有点迷糊的时候，看到上面这句话可能会有点沮丧。但是公认的它的算法还是比较繁琐的，尤其是要用程序员严谨的思维将所有细节理清的时候，你的脑袋里更是会充满了问号。Leslie Lamport也是用了长达9年的时间来完善这个算法的理论。 实际上对于一般的开发人员，我们并不需要了解Paxos所有细节及如何实现，只需要知道Paxos是一个分布式选举算法就够了

原文同步至 http://waylau.com/cap-theorem/ 本文介绍了介绍了分布式系统著名的 CAP 理论。什么是 CAP 理论？为什么说 CAP 只能三选二？了解 CAP 对于系统架构又有什么指导意义？本文将一一作答。 什么是 CAP 理论 在计算机科学理论，CAP 定理（也称为 Brewer 定理），是由计算机科学家 Eric Brewer 提出的，即在分布式计算机系统不可能同时提供以下全部三个保证： 一致性（Consistency）：所有节点同一时间看到是相同的数据； 可用性（Availability）：不管是否成功，确保每一个请求都能接收到响应； 分区容错性（Partition tolerance）：系统任意分区后，在网络故障时，仍能操作 为什么说 CAP 只能三选二 下面分别举例说明了为什么说 CAP 只能三选二。 上面的图显示了在一个网络中，N1 和 N2 两个节点。他们都共享数据块 V，其中有一个值 V0 。运行在 N1 的 A 程序可以认为是安全的、无 bug、可预测的和可靠的。运行在 N2 是 B 程序。这个例子中，A 将写入 V 新​值，而 B 从 V 读取值 系统预期执行下面的操作 首先写一个 V 的新​值 V1 然后消息（M）从 N1 更新 V 的拷贝到 N2 现在，从 B 读取将返回 V1 如果网络是分区的，当 N1 到 N2

使用mysql federated 引擎构建 MySQL 分布式数据库访问层 前言：随着应用复杂度的增加，数据库不断细化切分，导致应用程序中数据库应用就得复杂，凌乱。绝大部分程序人员可能都遇到这种情况，应用程序中需要连接多台数据库服务器，进行相应的操作。随着时间积累，太多的数据库服务器的连接逻辑出现在程序之中，这给程序的维护扩展，数据库维护工作带来极大的工作量。 于是一些分布式数据库代理层应运而生，如常见 MySQL 代理层 : mysql proxy : 主要实现读写分离和负载均衡 MySQL Amoeba : 由陈思儒主导开发　功能比较完善，用深入应用的价值，参考网站 http://docs.hexnova.com/amoeba/ HiveDB : HiveDB是一个用来横向切分 mysql 数据库的开源框架，构建一个高性能和可扩展的基于 mysql 的系统，但目前仅支持 Java 客户端。 http://www.hivedb.org/ 我认为mysql proxy, MySQL Amoeba 都是极好的实用价值，应该多深入了解之。 而本文所描述的 federated属于 MySQL的一种特殊引擎，利用它可将本地数据表映射至远程 MySQL 数据表，从而就可以解决应用程序中繁多的跨机器连接数据库问题，拓扑图如下： 如此就可以构造出一个统一的数据访问入口

分布式系列 1. 分布式介绍 1.1 分布式系统介绍 2. 分布式服务体系架构 2.1 基于TCP协议的RPC 2.2 基于HTTP协议的RPC 2.3 服务路由和负载均衡 2.4 服务网关 3. 分布式系统基础设施 3.1 分布式缓存 3.2 持久化存储 3.3 消息系统 3.4 搜索引擎 3.5 CDN系统 3.6 负载均衡系统 3.7 消息推送系统 3.8 自动化运维系统 4. 分布式安全架构 4.1 常见的Web攻击手段 4.2 常用的安全算法 4.3 信息摘要认证 4.4 签名认证 4.5 HTPPS协议 4.6 OAuth协议 5. 系统稳定性 5.1 在线日志分析 5.2 集群监控 5.3 流量控制 5.4 性能优化 5.5 应用故障分析与排查 6. 数据分析 6.1 日志采集 6.2 离线数据分析 6.3 流式数据分析 6.4 数据同步 6.5 数据报表 来源： oschina 链接： https://my.oschina.net/u/2858189/blog/732669

一、环境简介 本教程服务器主机都是CentOS 7(Red Hat 7 亦可)，集群结点分布情况如下表： +---------------+-----------+---------------------------------- |IP |HOSTNAME |备注 +---------------+-----------+---------------------------------- |192.168.6.171 |hdpmmaster |ResourceManager 进程所在机器 +---------------+-----------+---------------------------------- |192.168.6.172 |hdpsmaster |SecondaryNameNode 主机的备机 +---------------+-----------+---------------------------------- |198.168.6.67 |hdpslave67 |datanode +---------------+-----------+---------------------------------- |198.168.6.68 |hdpslave68 |datanode +---------------+-----------+-----