traitApp extends DelayedInit
简单来说，App特质可以快速将一个objects变成一个可执行程序，它内部实现了main的方法。注意：真正的功能实现使用DelayedInit来实现，这意味着object的fields在main方法执行前不会被初始化。这个类一般用于多线程应用等实现。
示例如下
|
1 2 3 |
object Main extends App { Console.println("Hello World: " + (args mkString ", ")) } |
这里Main继承了App特质中的main方法，args返回了当前命令行参数的数组。 Continue reading
原文地址：https://code.google.com/p/mysql-master-ha/wiki/Architecture
其他整理过的MHA文档: mysql-master-ha Overview
香打同学的mysql-master-HA other solutions
当master崩溃后，MHA以下面的方式恢复其他的slave。
图：恢复的步骤
Continue reading
要创建一个JobServer项目，需要下面的流程。
1. 在build.sbt中加入jobserver和spark core的package
|
1 2 3 4 5 |
resolvers += "Job Server Bintray" at "http://dl.bintray.com/spark-jobserver/maven" libraryDependencies += "spark.jobserver" % "job-server-api" % "0.4.0" % "provided" libraryDependencies += "org.apache.spark" % "spark-core_2.10" % "1.1.0" |
MHA是一个日本大牛故障切换工具（项目主页：http://code.google.com/p/mysql-master-ha/），本文为项目wiki中Overview这篇文章（Overview）。 Continue reading
续上一篇Spark as a Service之jobServer部署使用开发者模式来测试，本文正式部署并使用jobserver，当前版本有很多BUG和不完善的地方，期待后续的版本修复。
Continue reading
spark-jobserver提供了一个用于提交和管理Apache Spark作业(job)、jar文件和作业上下文（SparkContext）的RESTful接口。该项目位于git（https://github.com/ooyala/spark-jobserver），当前为0.4版本。
“Spark as a Service”: 简单的面向job和context管理的REST接口
通过长期运行的job context支持亚秒级低延时作业(job)
可以通过结束context来停止运行的作业(job)
分割jar上传步骤以提高job的启动
异步和同步的job API，其中同步API对低延时作业非常有效
支持Standalone Spark和Mesos
Job和jar信息通过一个可插拔的DAO接口来持久化
命名RDD以缓存，并可以通过该名称获取RDD。这样可以提高作业间RDD的共享和重用
Continue reading
Spark在YARN中有yarn-cluster和yarn-client两种运行模式: Continue reading
ZooKeeper是一个用于分布式应用程序的分布式开源协调服务。它使用一组简单的操作原语，使得分布式应用可以实现更高层次的服务——如同步、配置维护、群组和命名管理等。ZK具有高性能、高可用（复制）、有序等特征。请参考上一篇译文zookeeper：一个用于分布式应用的分布式协调服务。本文简单介绍一下开发中经常使用的方法（文档：ZooKeeper API）。 Continue reading
ZooKeeper是一个用于分布式应用程序的分布式开源协调服务。它使用一组简单的操作原语，使得分布式应用可以实现更高层次的服务——如同步、配置维护、群组和命名管理等。它以易于编程为基本设计理念，并使用了一个类似于文件系统目录结构风格的数据模型。ZooKeeper服务运行于Java环境中并可以在Java和C中使用。
众所周知，协调服务很难达到正确，尤其会出现竞争条件或死锁等问题。ZooKeeper设计初衷是为了缓解分布式应用从设计到实现中协调服务的问题。 Continue reading
YARN中的资源管理器（Resource Manager）负责整个系统的资源管理和调度，并内部维护了各个应用程序的ApplictionMaster信息，NodeManager信息，资源使用信息等。在2.4版本之后，Hadoop Common同样提供了HA的功能，解决了这样一个基础服务的可靠性和容错性问题。其架构如下：
RM HA与NN HA有诸多相同之处（NameNode HA配置详解 ）：
(1). Active/Standby架构，同一时间只有一个RM处于活动状态（如上图所示）。
(2). 依赖zooKeeper实现。手动切换使用yarn rmadmin命令（类似hdfs haadmin命令)，而自动故障转移使用ZKFailoverController。但不同的是，zkfc只作为RM中一个线程而非独立的守护进程来启动。
(3). 当存在多个RM时，客户端使用的yarn-site.xml需要指定RM的列表。 客户端, ApplicationMasters (AMs)和NodeManagers (NMs) 会以轮训的方式寻找活动状态的RM，也就是说AM
s和NMs需要自己提供容错机制。如果当前活动状态的RM挂掉了，那么会继续使用轮训的方式找到新的RM。这种逻辑的实现需要在yarn.client.failover-proxy-provider中指定使用的类：org.apache.hadoop.yarn.client.RMFailoverProxyProvider
此外，新的RM可以恢复之前RM的状态（详见ResourceManger Restart )。当启动RM Restart，重启后的RM就加载之前活动RM的状态信息并继续之前RM的操作，这样应用程序定期执行检查点操作，就可以避免工作内容的丢失。在Active/standby的RM中，活动RM的状态数据需要active和standby都能访问，使用共享文件系统方法（FileSystemRMStateStore ）或者zooKeeper方法（ZKRMStateStore）。后者在同一时间只允许一个RM有写入权限。 Continue reading