RangeYan

kafka在所有broker中选出一个controller，所有Partition的Leader选举都由controller决定。controller会将Leader的改变直接通过RPC的方式（比Zookeeper Queue的方式更高效）通知需为此作出响应的Broker。同时controller也负责增删Topic以及Replica的重新分配。当有broker fari over contr

1. Hadoop 1.x 版本 fsimage和edits合并实现原理 在NameNode运行期间，HDFS的所有更新操作都是直接写到edits中，久而久之edits文件将会变得很大；虽然这对NameNode运行时候是没有什么影响的，但是我们知道当NameNode重启的时候，NameNode先将fsimage里面的所有内容映像到内存中，然后再一条一条地执行edits中的记录，当edits文件

在Hadoop2.0.0之前，NameNode(NN)在HDFS集群中存在单点故障（single point of failure），每一个集群中存在一个NameNode，如果NN所在的机器出现了故障，那么将导致整个集群无法利用，直到NN重启或者在另一台主机上启动NN守护线程。　　主要在两方面影响了HDFS的可用性：　　（1）、在不可预测的情况下，如果NN所在的机器崩溃了，整个集群将无

1. 写流程2.读流程3.副本放置策略4.可靠性策略5.HDFS数据块6.HDFS 不适合小文件存储

HDFS优点：高容错性：数据自动保存多个副本，副本丢失后，自动恢复适合批处理：移动计算而飞数据。数据位置暴露给计算框架适合大数据处理：GB,TB,设置PB级数据。百万规模以上文件数量。10K+节点规模。流式文件访问：一次性写入，多次读取。保证数据一致性。可构建在廉价机器上：通过多副本提高可靠性。提供容错和恢复机制。HDFS缺点：不适合低延迟数据访问场景：比如毫秒

2.X 版本的HDFS 架构图如下:Active Namenode:主Master(只有一个)管理HDFS的命名空间（name space）管理数据块映射信息配置副本策略处理客户端读写请求Standby NameNode：NameNode的热备定期合并fsimage和fsedits，推送给NameNode当Active NameNode出现故

yarn 基本架构Resource ManagerApplication masternode managercontainer history servertimeline server参考资料：1. http://blog.csdn.net/cymvp/article

Yarn的资源调度目前支持内存和CPU两种资源。Yarn支持三种调度方式：FIFO、FAIR和DRF分别是指先来先服务、公平调度和主资源公平调度FIFO：先按照优先级高低调度，如果优先级相同，则按照提交时间先后顺序调度，如果提交时间相同，则按照（队列或者应用程序）名称大小（字符串比较）调度；不支持有子队列的情况。FAIR：按照内存资源使用量比率调度，即按照used_memo

正如ZooKeeper用于分布式系统的协调和促进，Kafka使用ZooKeeper也是基于相同的原因。ZooKeeper用于管理、协调Kafka代理。每个Kafka代理都通过ZooKeeper协调其它Kafka代理。当Kafka系统中新增了代理或者某个代理故障失效时，ZooKeeper服务将通知生产者和消费者。生产者和消费者据此开始与其它代理协调工作。Kafka整体系统架构如图所示。下

一、 设计 kafka设计目标是实现一个高吞吐量的，低延迟的，实时数据处理的统一平台。在设计的时候从以下几个方面做了优化。1. 数据持久化Kafka直接将数据写到了文件系统的日志中,依赖操作系统的page cache 实现read-ahead 和 write-behind。这样做的好处是读和写都是 O(1) 的，并且读操作不会阻塞写操作和其他操作2. 消息传输的

Apache Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一种快速、可扩展的、设计内在就是分布式的，分区的和可复制的提交日志服务。基于zookeeper协调的分布式日志系统(也可以当做MQ系统)，常见可以用于web/nginx日志、访问日志，消息服务等等1. 架构与功能