OS and File System

根据Dell（因为我们的硬件采用dell的方案）关于hadoop调优的相关说明，改变几个Linux的默认设置，Hadoop的性能能够增长大概15%。

open file descriptors and files

文件描述符是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开，文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。

在Linux系列的操作系统上，由于Linux的设计思想便是把一切设备都视作文件。因此，文件描述符为在该系列平台上进行设备相关的编程实际上提供了一个统一的方法。

在CentOS中通过下面的命令查看：

cat /proc/sys/fs/file-max
800000

也可以通过查看文件中的内容来查看，其中的fs.file-max定义了最大的打开文件描述符数量：

cat /etc/sysctl.conf
fs.file-max = 800000
net.core.rmem_default = 12697600
net.core.wmem_default = 12697600
net.core.rmem_max = 873800000
net.core.wmem_max = 655360000
net.ipv4.tcp_rmem = 8192 262144 4096000
net.ipv4.tcp_wmem = 4096 262144 4096000
net.ipv4.tcp_max_orphans = 300000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.ip_local_port_range = 1025 65535
net.ipv4.tcp_max_syn_backlog = 100000
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp.keepalive_time = 1200
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 1500
net.core.somaxconn=32768
vm.swappiness=0

CentOS下可以通过下面的命令来增加最大打开文件描述符数量，在集群中的每台机器上执行：

# su – (hdfs & Hadoop users)
# ulimit –S 4096
# ulimit –H 32832

也可以通过修改/etc/sysctl.conf文件中的fs.file-max来达到目的。

由于这部分的数值远远大于文档中所列出的数字，此部分没有做优化。

File System

Linux的发行版本对于文件系统有着不同的初始设置。经过测试不同的Linux File Systems，发现EXT4格式要比EXT3更好。EXT4中的新特性，比如多块延迟分配，相比于EXT3要提高很大一部分的性能。在EXT3中，当一个文件被创建或数据被添加到一个已经存在的文件时，会直接调用文件block allocator，每个block一次；而EXT4则不同，它会做一个缓冲，以便以后能够最优化地将数据连续地放入硬盘。连续的文件能够很容易地被机械硬盘读写以能够提高存储IO的整体性能。

默认情况下，Linux会把文件访问的时间atime作记录，这在绝大多数场合下都是没有必要的，尤其是IO负载比较高的Hadoop集群下，可以尝试使用noatime和nodiratime。

在Hadoop中，很多中间文件（比如map输出的中间文件）都只会在Hadoop job运行过程中存活，job执行完成就会被删除了，根本没有必要存在访问时间戳。

通过命令cat /etc/fstab来查看当前的设置：

UUID=5d75c681-1101-46c2-9428-3e48310765ce                 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
LABEL=SWAP-sda3         swap                    swap    defaults        0 0

可以看到当前并没有使用EXT4格式以及noatime。

注意，修改完设置后需要重新挂载文件系统，不需要重启。

mount -o remount /

另外一个对于dataNodes的优化点就是通过改变文件系统的保留块大小。Linux文件系统中为了保证root能够登录到操作系统中，需要保留一定的磁盘空间，默认这个值设置为5%。但是当前磁盘空间都是TB级别的，因此保留5%就会造成一大部分空间的浪费，对于1TB来说就是50G。

通过下面的命令来列出当前的保留磁盘空间。

tune2fs –l /dev/sdaX

下面的命令可以将保留磁盘空间的容量设置成1%:

tune2fs –m 1 /dev/sdaX

Network

两个网络相关的参数可以影响Hadoop的性能。net.core.somaxconn Linux内核设置能够支持NameNode和JobTracker的大量爆发性的HTTP请求。

net.core.somaxconn是listen()的默认参数,挂起请求的最大数量.默认是128.对繁忙的服务器,增加该值有助于网络性能，当前已经被调整到32768。

这个参数同样可以通过编辑/etc/sysctl.conf文件来改变，其中有一行：

net.core.somaxconn=32768

设置txqueuelen到4096及以上能够更好地适应在Hadoop集群中的突发流量， txqueuelen代表用来传输数据的缓冲区的储存长度，通过下面的命令可以对该参数进行设置为4096：

sudo ifconfig eth# txqueuelen 4096

其他的一系列在/etc/sysctl.conf中的配置，可以对网络产生影响：

net.core.rmem_default = 12697600
net.core.wmem_default = 12697600
net.core.rmem_max = 873800000
net.core.wmem_max = 655360000
net.ipv4.tcp_rmem = 8192 262144 4096000
net.ipv4.tcp_wmem = 4096 262144 4096000
net.ipv4.tcp_max_orphans = 300000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.ip_local_port_range = 1025 65535
net.ipv4.tcp_max_syn_backlog = 100000
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp.keepalive_time = 1200
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 1500

上述设置需要重新启动整个集群系统。

Transparent Huge Page

Linux的特性Transparent HugePages在大部分的应用中都提高了整体性能，包括Hadoop的工作负载。但是，其中的一项被称为Compaction的子特性会导致Hadoop工作负载的问题，在设置了Compaction的Hadoop benchmark测试中，结果会存在25%的浮动，而关闭Compaction后浮动消失。

当进行内存碎片整理时，Compaction会提高CPU资源利用率，这能够帮助优化Transparent HugePages，但是偷取了CPU资源，却影响了hadoop中正在运行的task性能。

通过以下命令可以查看是否启用compaction：

cat /sys/kernel/mm/redhat_transparent_hugepages/defrag

以及以下命令来禁用Compaction：

echo never > /sys/kernel/mm/redhat_transparent_hugepages/defrag

这个特定暂时没有进行修改，因为CentOS中没找到在哪儿设置。

Linux kernal swappiness parameter

任何进程只要涉及到换页向磁盘写文件都会降低hadoop的性能，Linux内核进程vm.swappiness会检查无用的内存分页并将它们交换到磁盘上。默认的值是60，可以设置为0——100。对于Hadoop来说，设置成0是一个好主意，这并没有将这个特性关闭，Linux仍然进行换页操作，但是由于这个进程在仍然还有一大部分空闲内存时仍然会进行换页，将它设置成0可以尽可能地减少内存和磁盘的延迟。

这个参数仍然可以通过编辑/etc/sysctl.conf来进行修改。

当前集群已经设置：

vm.swappiness=0

参考两个PPT

http://www.slideshare.net/cnbailey/memory-efficient-java
http://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf

原文： 沐剑

Java程序员在编码过程中通常不需要考虑内存问题，JVM经过高度优化的GC机制大部分情况下都能够很好地处理堆(Heap)的清理问题。以至于许多Java程序员认为，我只需要关心何时创建对象，而回收对象，就交给GC来做吧！甚至有人说，如果在编程过程中频繁考虑内存问题，是一种退化，这些事情应该交给编译器，交给虚拟机来解决。

这话其实也没有太大问题，的确，大部分场景下关心内存、GC的问题，显得有点“杞人忧天”了，高老爷说过：

过早优化是万恶之源。

但另一方面，什么才是“过早优化”？

If we could do things right for the first time, why not?

事实上JVM的内存模型(  JMM )理应是Java程序员的基础知识，处理过几次JVM线上内存问题之后就会很明显感受到，很多系统问题，都是内存问题。

对JVM内存结构感兴趣的同学可以看下  浅析Java虚拟机结构与机制 这篇文章，本文就不再赘述了，本文也并不关注具体的GC算法，相关的文章汗牛充栋，随时可查。

另外，不要指望GC优化的这些技巧，可以对应用性能有成倍的提高，特别是对I/O密集型的应用，或是实际落在YoungGC上的优化，可能效果只是帮你减少那么一点YoungGC的频率。

但我认为，优秀程序员的价值，不在于其所掌握的几招屠龙之术，而是在细节中见真著，就像前面说的，如果我们可以一次把事情做对，并且做好，在允许的范围内尽可能追求卓越，为什么不去做呢？

一、GC分代的基本假设

大部分GC算法，都将堆内存做分代(Generation)处理，但是为什么要分代呢，又为什么不叫内存分区、分段，而要用面向时间、年龄的“代”来表示不同的内存区域？

GC分代的基本假设是：

绝大部分对象的生命周期都非常短暂，存活时间短。

而这些短命的对象，恰恰是GC算法需要首先关注的。所以在大部分的GC中，YoungGC（也称作MinorGC）占了绝大部分，对于负载不高的应用，可能跑了数个月都不会发生FullGC。

基于这个前提，在编码过程中，我们应该尽可能地缩短对象的生命周期。在过去，分配对象是一个比较重的操作，所以有些程序员会尽可能地减少new对象的次数，尝试减小堆的分配开销，减少内存碎片。

但是，短命对象的创建在JVM中比我们想象的性能更好，所以，不要吝啬new关键字，大胆地去new吧。

当然前提是不做无谓的创建，对象创建的速率越高，那么GC也会越快被触发。

结论：

分配小对象的开销分享小，不要吝啬去创建。

GC最喜欢这种小而短命的对象。

让对象的生命周期尽可能短，例如在方法体内创建，使其能尽快地在YoungGC中被回收，不会晋升(romote)到年老代(Old Generation)。

二、对象分配的优化

基于大部分对象都是小而短命，并且不存在多线程的数据竞争。这些小对象的分配，会优先在线程私有的 TLAB 中分配，TLAB中创建的对象，不存在锁甚至是CAS的开销。

TLAB占用的空间在Eden Generation。

当对象比较大，TLAB的空间不足以放下，而JVM又认为当前线程占用的TLAB剩余空间还足够时，就会直接在Eden Generation上分配，此时是存在并发竞争的，所以会有CAS的开销，但也还好。

当对象大到Eden Generation放不下时，JVM只能尝试去Old Generation分配，这种情况需要尽可能避免，因为一旦在Old Generation分配，这个对象就只能被Old Generation的GC或是FullGC回收了。

三、不可变对象的好处

GC算法在扫描存活对象时通常需要从ROOT节点开始，扫描所有存活对象的引用，构建出对象图。

不可变对象对GC的优化，主要体现在Old Generation中。

可以想象一下，如果存在Old Generation的对象引用了Young Generation的对象，那么在每次YoungGC的过程中，就必须考虑到这种情况。

Hotspot JVM为了提高YoungGC的性能，避免每次YoungGC都扫描Old Generation中的对象引用，采用了 卡表(Card Table) 的方式。

简单来说，当Old Generation中的对象发生对Young Generation中的对象产生新的引用关系或释放引用时，都会在卡表中响应的标记上标记为脏(dirty)，而YoungGC时，只需要扫描这些dirty的项就可以了。

可变对象对其它对象的引用关系可能会频繁变化，并且有可能在运行过程中持有越来越多的引用，特别是容器。这些都会导致对应的卡表项被频繁标记为dirty。

而不可变对象的引用关系非常稳定，在扫描卡表时就不会扫到它们对应的项了。

注意，这里的不可变对象，不是指仅仅自身引用不可变的 final对象，而是真正的Immutable Objects。

四、引用置为null的传说

早期的很多Java资料中都会提到在方法体中将一个变量置为null能够优化GC的性能，类似下面的代码：

List<String> list = new ArrayList<String>();
// some code
list = null; // help GC

事实上这种做法对GC的帮助微乎其微，有时候反而会导致代码混乱。

我记得几年前撒迦在HLL VM小组中详细论述过这个问题，原帖我没找到，结论基本就是：

在一个非常大的方法体内，对一个较大的对象，将其引用置为null，某种程度上可以帮助GC。

大部分情况下，这种行为都没有任何好处。

所以，还是早点放弃这种“优化”方式吧。

GC比我们想象的更聪明。

五、手动档的GC

在很多Java资料上都有下面两个奇技淫巧：

通过 Thread.yield()让出CPU资源给其它线程。

通过 System.gc()触发GC。

事实上JVM从不保证这两件事，而 System.gc()在JVM启动参数中如果允许显式GC，则会触发FullGC，对于响应敏感的应用来说，几乎等同于自杀。

So，让我们牢记两点：

Never use  Thread.yield()。

Never use  System.gc()。除非你真的需要回收Native Memory。

第二点有个Native Memory的例外，如果你在以下场景：

• 使用了NIO或者NIO框架（Mina/Netty）

• 使用了DirectByteBuffer分配字节缓冲区

• 使用了MappedByteBuffer做内存映射

由于Native Memory只能通过FullGC（或是CMS GC）回收，所以除非你非常清楚这时真的有必要，否则不要轻易调用 System.gc()，且行且珍惜。

另外为了防止某些框架中的 System.gc调用（例如NIO框架、Java RMI），建议在启动参数中加上 -XX:+DisableExplicitGC来禁用显式GC。

这个参数有个巨大的坑，如果你禁用了 System.gc()，那么上面的3种场景下的内存就无法回收，可能造成OOM，如果你使用了CMS GC，那么可以用这个参数替代： -XX:+ExplicitGCInvokesConcurrent。

关于 System.gc()，可以参考毕玄的几篇文章：

• CMS GC会不会回收Direct ByteBuffer的内存

• 说说在Java启动参数上我犯的错

• java.lang.OutOfMemoryError:Map failed

六、指定容器初始化大小

Java容器的一个特点就是可以动态扩展，所以通常我们都不会去考虑初始大小的设置，不够了反正会自动扩容呗。

但是扩容不意味着没有代价，甚至是很高的代价。

例如一些基于数组的数据结构，例如 StringBuilder、 StringBuffer、 ArrayList、 HashMap等等，在扩容的时候都需要做ArrayCopy，对于不断增长的结构来说，经过若干次扩容，会存在大量无用的老数组，而回收这些数组的压力，全都会加在GC身上。

这些容器的构造函数中通常都有一个可以指定大小的参数，如果对于某些大小可以预估的容器，建议加上这个参数。

可是因为容器的扩容并不是等到容器满了才扩容，而是有一定的比例，例如 HashMap的扩容阈值和负载因子(loadFactor)相关。

Google Guava框架对于容器的初始容量提供了非常便捷的工具方法，例如：

Lists.newArrayListWithCapacity(initialArraySize);

Lists.newArrayListWithExpectedSize(estimatedSize);

Sets.newHashSetWithExpectedSize(expectedSize);

Maps.newHashMapWithExpectedSize(expectedSize);

这样我们只要传入预估的大小即可，容量的计算就交给Guava来做吧。

反例：

如果采用默认无参构造函数，创建一个ArrayList，不断增加元素直到OOM，那么在此过程中会导致：

• 多次数组扩容，重新分配更大空间的数组
• 多次数组拷贝
• 内存碎片

七、对象池

为了减少对象分配开销，提高性能，可能有人会采取对象池的方式来缓存对象集合，作为复用的手段。

但是对象池中的对象由于在运行期长期存活，大部分会晋升到Old Generation，因此无法通过YoungGC回收。

并且通常……没有什么效果。

对于对象本身：

如果对象很小，那么分配的开销本来就小，对象池只会增加代码复杂度。

如果对象比较大，那么晋升到Old Generation后，对GC的压力就更大了。

从线程安全的角度考虑，通常池都是会被并发访问的，那么你就需要处理好同步的问题，这又是一个大坑，并且同步带来的开销，未必比你重新创建一个对象小。

对于对象池，唯一合适的场景就是当池中的每个对象的创建开销很大时，缓存复用才有意义，例如每次new都会创建一个连接，或是依赖一次RPC。

比如说：

• 线程池
• 数据库连接池
• TCP连接池

即使你真的需要实现一个对象池，也请使用成熟的开源框架，例如Apache Commons Pool。

另外，使用JDK的 ThreadPoolExecutor作为线程池，不要重复造轮子，除非当你看过AQS的源码后认为你可以写得比Doug Lea更好。

八、对象作用域

尽可能缩小对象的作用域，即生命周期。

如果可以在方法内声明的局部变量，就不要声明为实例变量。

除非你的对象是单例的或不变的，否则尽可能少地声明static变量。

九、各类引用

java.lang.ref.Reference有几个子类，用于处理和GC相关的引用。JVM的引用类型简单来说有几种：

• Strong Reference，最常见的引用
• Weak Reference，当没有指向它的强引用时会被GC回收
• Soft Reference，只当临近OOM时才会被GC回收
• Phantom Reference，主要用于识别对象被GC的时机，通常用于做一些清理工作

当你需要实现一个缓存时，可以考虑优先使用 WeakHashMap，而不是 HashMap，当然，更好的选择是使用框架，例如Guava Cache。

最后，再次提醒，以上的这些未必可以对代码有多少性能上的提升，但是熟悉这些方法，是为了帮助我们写出更卓越的代码，和GC更好地合作。

代码质量和整洁度成正比

有意义的命名,原则:

名副其实(用注解来补充的命名不是名副其实);

避免误导，避免使用与本意相悖的词汇；

做有意义的区分：Variable永远不要出现在变量中，Table永远不要出现在表中，废话是冗余的；

使用读得出来的名称；

使用可搜索的名称（单字母和数字常量很难搜索,exception的e也不好搜索）；

单字母名称仅用于短方法的本地变量，名称长度应与其作用域大小相对应；

避免使用编码；

不必使用m_成员前缀来表明是成员变量；

接口的I前缀不如实现的imp后缀；

避免思维映射：不应当让读者把你的名称理解为他们熟知的内容；

类名和对象名应该是名词或名词短语，不应该是动词；

方法名应该是动词或动词短语；

每个概念对应一个词；

别用双关语：同一单词用于不同目的；同一术语用于不同概念；

使用解决方案领域名词；

使用领域术语；

添加有意义的语境；

一言以蔽之：取名最难的地方在于需要良好的描述技巧和工有的文化背景。

函数

第一原则是函数要短小；第二条原则还是更短小。

一个函数只做一件事，并做好这件事（判断是不是做了一件事：看能不能再拆分一个函数出来）；

每个函数一个抽象级；

Switch语句：放于接口中，继承类则隐藏该部分，实现函数短小；

函数命名使用描述性的名称；

函数参数

最理想的是0参数，尽量少用3个参数以上的;多于的话,要考虑封装成类;

使用异常代替错误返回码;

抽离try catch块，将try中的逻辑封装成函数；

注释

注释存在的时间越久，就离其描述的代码越远，越累越变得全然错误，原因在于，程序员不能坚持维护注释

注释不能美化糟糕的代码；

唯一真正好的注释是不去写注释；

注释可以用于放大某种不合理的事物的重要性；

坏注释：

喃喃自语：如果决定要写注释就要写好注释；

误导性注释

错误注释

日志式注释：记录代码的修改——冗长的记录只会让模块变得凌乱不堪，删掉

能用函数或变量时就别用注释

归属和署名不必放在代码中，代码管理工具是这些信息的归属地

直接把代码注释掉是讨厌的做法

HTML注释不要存在于代码中；

非本地注释：注释内容与被注释代码脱离上下文关系；

短函数的函数头注释不如起个好的函数名字；

格式

代码格式关乎沟通，沟通是专业开发者的头等大事

纵向格式

尽可能用200行，不超过500行的代码文件

变量应该尽可能靠近其使用位置；

实体变量在类顶部声明；

相关函数：调用者放在被调用方法的上部；

概念相关：概念相关性强的代码放在一起；

横向格式

代码行尽量短小

方法名和左括号不必加空格，参数一一隔开；

对象和数据结构

对象把数据藏于抽象之后，暴露操作数据的函数；数据结构暴露数据；

对象和数据结构的二分原理：

过程式代码(使用数据结构)在于不改变既有数据结构的前提下增加新函数,面向对象的代码便于在不改变既有函数的前提下增加新类.

反之,过程式代码难以添加新的数据结构,因此必须修改所有函数.面向对象代码难以新函数,因为要修改所有类.

数据传送对象:DTO,只有公共变量,没有函数

错误处理

使用异常而非返回码

别返回null值,别传递null值

边界

使用第三方代码

类

类要短小：单一全责原则

内聚

系统

将系统的构造和使用分开

迭代

通过迭代设计达到整洁的目的

转载自：http://www.douban.com/group/topic/11765014/

CAP 理论在搞分布式的程序员中已经是路人皆知了。但是 CAP 理论就好比是相对论，虽然所有的人都知道，但是却没有多少人真正理解。 
要真正理解 CAP 理论必须要读懂它的形式化描述。 形式化描述中最重要的莫过于对 Consistency, Availability, Partition-tolerance 的准确定义。 

Consistency (一致性) 实际上等同于系统领域的 before-or-after atomicity 这个术语，或者等同于 linearizable (可串行化) 这个术语。具体来说，系统中对一个数据的读和写虽然包含多个子步骤并且会持续一段时间才能执行完，但是在调用者看来，读操作和写操作都必须是单个的即时完成的操作，不存在重叠。对一个写操作，如果系统返回了成功，那么之后到达的读请求都必须读到这个新的数据；如果系统返回失败，那么所有的读，无论是之后发起的，还是和写同时发起的，都不能读到这个数据。 

要说清楚 Availability 和 Partition-tolerance 必须要定义好系统的故障模型。在形式化证明中，系统包含多个节点，每个节点可以接收读和写的请求，返回成功或失败，对读还要返回一个数据。和调用者之间的连接是不会中断的，系统的节点也不会失效，唯一的故障就是报文的丢失。 Partition-tolerance 指系统中会任意的丢失报文(这和“最终会有一个报文会到达”是相对的)。 Availability 是指所有的读和写都必须要能终止。 

注： “Availability 是指所有的读和写都必须要能终止” 这句话听上去很奇怪，为什么不是“Availability 是指所有的写和读都必须成功”？ 要回答这个问题，我们可以仔细思考下“什么是成功”。“成功”必须要相对于某个参照而言，这里的参照就是 Consistency。 

CAP 理论说在一个系统中对某个数据不存在一个算法同时满足 Consistency, Availability, Partition-tolerance 。 注意，这里边最重要和最容易被人忽视的是限定词“对某个数据不存在一个算法”。这就是说在一个系统中，可以对某些数据做到 CP, 对另一些数据做到 AP，就算是对同一个数据，调用者可以指定不同的算法，某些算法可以做到 CP，某些算法可以做到 AP。 

要做到 CP， 系统可以把这个数据只放在一个节点上，其他节点收到请求后向这个节点读或写数据，并返回结果。很显然，串行化是保证的。但是如果报文可以任意丢失的话，接受请求的节点就可能永远不返回结果。 

要做到 CA， 一个现实的例子就是单点的数据库。你可能会疑惑“数据库也不是 100% 可用的呀？” 要回答这个疑惑，注意上面说的故障模型和 availability 的定义就可以了。 

要做到 AP， 系统只要每次对写都返回成功，对读都返回固定的某个值就可以了。 

如果我们到这里就觉得已近掌握好 CAP 理论了，那么就相当于刚把橘子剥开，就把它扔了。 

CAP 理论更重要的一个结果是， 在 Partial Synchronous System (半同步系统) 中，一个弱化的 CAP 是能达到的: 

* 对所有的数据访问，总返回一个结果 
* 如果期间没有报文丢失，那么返回一个满足 consistency 要求的结果。 

这里的半同步系统指每个节点存在一个时钟，这些时钟不需要同步，但是按照相同的速率流逝。更通俗的来说，就是一个能够实现超时机制的系统。 

举个例子，系统可以把这个数据只放在一个节点上，其他节点收到请求后向这个节点读或写数据，并设置一个定时器，如果超时前得到结果，那么返回这个结果，否则返回失败。 

更进一步的，也是最重要的，实现一个满足最终一致性 (Eventually Consistency) 和 AP 的系统是可行的。 现实中的一个例子是 Cassandra 系统。

(End)

-------------------------------------------------

网上的另一篇文章：

http://blog.csdn.net/zhaoyp1985/article/details/7880547 CAP理论  (提到A CAP Solution)

 转自：http://shift-alt-ctrl.iteye.com/blog/1930345

前言: kafka是一个轻量级的/分布式的/具备replication能力的日志采集组件,通常被集成到应用系统中,收集"用户行为日志"等,并可以使用各种消费终端(consumer)将消息转存到HDFS等其他结构化数据存储系统中.因为日志消息通常为文本数据,尺寸较小,且对实时性以及数据可靠性要求不严格,但是需要日志存储端具备较高的数据吞吐能力,这种"宽松"的设计要求,非常适合使用kafka. 

一.入门

     1.1 简介

    Kafka是一个"分布式的"/"可分区的(partitioned)"/"基于备份的(replicated)"/"基于commit-log存储"的服务. 它提供了类似于JMS的特性,但是在设计实现上完全不同,此外它并不是JMS规范的实现.

    kafka消息是根据Topic进行归类,发送消息者成为Producer,消息接收者成为Consumer;此外kafka集群有多个kafka实例组成,每个实例(server)称为broker.

    无论是kafka集群,还是producer和consumer都依赖于zookeeper来保证系统可用性以及保存一些meta信息.

 

(摘自官网) 

    其中client与server的通讯,都是基于TCP,而且消息协议非常轻量级.

     Topics/logs

    一个Topic可以认为是一类消息,每个topic将被分成多个partition(区),每个partition在存储层面是append log文件.任何发布到此partition的消息都会直接追加到log文件的尾部,每条消息在文件中的位置称为offset(偏移量),offset为一个long型数字,它唯一的标记一条消息.kafka并没有提供其他额外的索引机制来存储offset,因为在kafka中几乎不允许对消息进行"随机读-写",一旦消息写入log日志之后,将不能被修改.

(摘自官网) 

    kafka和JMS实现(activeMQ)不同的是:即使消息被消费,消息仍然不会被立即删除.日志文件将会根据broker中的配置要求,保留一定的时间之后删除;比如log文件保留2天,那么两天后,文件会被清除,无论其中的消息是否被消费.kafka通过这种简单的手段,来释放磁盘空间.此外,kafka的性能并不会因为日志文件的太多而低下,所以即使保留较多的log文件,也不不会有问题.

    对于consumer而言,它需要保存消费消息的offset,对于offset的保存和使用,有consumer来控制;当consumer正常消费消息时,offset将会"线性"的向前驱动,即消息将依次顺序被消费.事实上consumer可以使用任意顺序消费消息,它只需要将offset重置为任意值..(offset将会保存在zookeeper中,参见下文)

    kafka集群几乎不需要维护任何consumer和producer状态信息,这些信息有zookeeper保存;因此producer和consumer的客户端实现非常轻量级,它们可以随意离开,而不会对集群造成额外的影响.

    partitions的设计目的有多个.最根本原因是kafka基于文件存储.通过分区,可以将日志内容分散到多个server上,来避免文件尺寸达到单机磁盘的上限,每个partiton都会被当前server(kafka实例)保存;可以将一个topic切分多任意多个partitions(备注:基于sharding),来消息保存/消费的效率.此外越多的partitions意味着可以容纳更多的consumer,有效提升并发消费的能力.(具体原理参见下文).

     Distribution

    一个Topic的多个partitions,被分布在kafka集群中的多个server上;每个server(kafka实例)负责partitions中消息的读写操作;此外kafka还可以配置每个partition需要备份的个数(replicas),每个partition将会被备份到多台机器上,以提高可用性.[replicas特性在0.8V才支持]

    基于replicated方案,那么就意味着需要对多个备份进行调度;一个partition可以在多个server上备份,那么其中一个server作为此partiton的leader;leader负责此partition所有的读写操作,如果leader失效,那么将会有其他follower来接管(成为新的leader);follower只是单调的和leader跟进,同步消息即可..由此可见作为leader的server承载了全部的请求压力,因此从集群的整体考虑,有多少个partitions就意味着有多少个"leader",kafka会将"leader"均衡的分散在每个实例上,来确保整体的性能稳定.[备注:kafka中将leader角色权限下放到partition这个层级]

 

kafka-cluster 

     Producers

    Producer将消息发布到指定的Topic中,同时Producer也能决定将此消息发送到哪个partition;如果一个Topic有多个partitions时,你需要选择partition是算法,比如基于"round-robin"方式或者通过其他的一些算法等.无论如何选择partition路由算法,我们最直接的目的就是希望消息能够均匀的发送给每个partition,这样可以让consumer消费的消息量也能"均衡".

     Consumers

    本质上kafka只支持Topic.每个consumer属于一个consumer group;反过来说,每个group中可以有多个consumer.对于Topic中的一条特定的消息,只会被订阅此Topic的每个group中的一个consumer消费,此消息不会发送给一个group的多个consumer;那么一个group中所有的consumer将会交错的消费整个Topic.

    如果所有的consumer都具有相同的group,这种情况和JMS queue模式很像;消息将会在consumers之间负载均衡.

    如果所有的consumer都具有不同的group,那这就是"发布-订阅";消息将会广播给所有的消费者.

(摘自官网) 

    在kafka中,一个partition中的消息只会被group中的一个consumer消费(同一时刻);每个group中consumer消息消费互相独立;我们可以认为一个group是一个"订阅"者,一个Topic中的每个partions,只会被一个"订阅者"中的一个consumer消费,不过一个consumer可以同时消费多个partitions中的消息.kafka只能保证一个partition中的消息被某个consumer消费时是顺序的.事实上,从Topic角度来说,当有多个partitions时,消息仍不是全局有序的.

    通常情况下,一个group中会包含多个consumer,这样不仅可以提高topic中消息的并发消费能力,而且还能提高"故障容错"性,如果group中的某个consumer失效,那么其消费的partitions将会有其他consumer自动接管.

    kafka的设计原理决定,对于一个topic,同一个group中不能有多于partitions个数的consumer同时消费,否则将意味着某些consumer将无法得到消息.

     Guarantees

    1) 发送到partitions中的消息将会按照它接收的顺序追加到日志中,无论一个partition由多少个log文件构成,那么它发送给consumer的顺序是一定的.

    2) 对于消费者而言,它们消费消息的顺序和日志中消息顺序一致.

    3) 如果Topic的"replication factor"为N,那么允许N-1个kafka实例失效.只要有一个replication存活,那么此partition的读写操作都不会中断.

    1.2 Use cases

     Messaging

    和一些常规的消息系统相比,kafka仍然是个不错的选择;它具备partitons/replication和容错,可以使kafka具有良好的扩展性和性能优势.不过到目前为止,我们应该很清楚认识到,kafka并没有提供JMS中的"事务性""消息传输担保(消息确认机制)""消息分组"等企业级特性;kafka只能使用作为"常规"的消息系统,在一定程度上,尚未确保消息的发送与接收绝对可靠(比如,消息重发,消息发送丢失等)

     Websit activity tracking

    kafka可以作为"网站活性跟踪"的最佳工具;可以将网页/用户操作等信息发送到kafka中.并实时监控,或者离线统计分析等.

     Log Aggregation

    kafka的特性决定它非常适合作为"日志收集中心";application可以将操作日志"批量""异步"的发送到kafka集群中,而不是保存在本地或者DB中;kafka可以批量提交消息/压缩消息等,这对producer端而言,几乎感觉不到性能的开支.此时consumer端可以使hadoop等其他系统化的存储和分析系统.

二. 设计原理

    kafka的设计初衷是希望做为一个统一的信息收集平台,能够实时的收集反馈信息,并需要能够支撑较大的数据量,且具备良好的容错能力.

     1.Persistence

    kafka使用文件存储消息(append only log),这就直接决定kafka在性能上严重依赖文件系统的本身特性.且无论任何OS下,对文件系统本身的优化是非常艰难的.文件缓存/直接内存映射等是常用的手段.因为kafka是对日志文件进行append操作,因此磁盘检索的开支是较小的;同时为了减少磁盘写入的次数,broker会将消息暂时buffer起来,当消息的个数(或尺寸)达到一定阀值时,再flush到磁盘,这样减少了磁盘IO调用的次数.对于kafka而言,较高性能的磁盘,将会带来更加直接的性能提升.

     2.Efficiency

    需要考虑的影响性能点很多,除磁盘IO之外,我们还需要考虑网络IO,这直接关系到kafka的吞吐量问题.kafka并没有提供太多高超的技巧;对于producer端,可以将消息buffer起来,当消息的条数达到一定阀值时,批量发送给broker;对于consumer端也是一样,批量fetch多条消息.不过消息量的大小可以通过配置文件来指定.对于kafka broker端,似乎有个sendfile系统调用可以潜在的提升网络IO的性能:将文件的数据映射到系统内存中,socket直接读取相应的内存区域即可,而无需进程再次copy和交换(这里涉及到"磁盘IO数据"/"内核内存"/"进程内存"/"网络缓冲区",多者之间的数据copy).

    其实对于producer/consumer/broker三者而言,CPU的开支应该都不大,因此启用消息压缩机制是一个良好的策略;压缩需要消耗少量的CPU资源,不过对于kafka而言,网络IO更应该需要考虑.可以将任何在网络上传输的消息都经过压缩.kafka支持gzip/snappy等多种压缩方式.

     3. Producer

     Load balancing

    kafka集群中的任何一个broker,都可以向producer提供metadata信息,这些metadata中包含"集群中存活的servers列表"/"partitions leader列表"等信息(请参看zookeeper中的节点信息). 当producer获取到metadata信心之后, producer将会和Topic下所有partition leader保持socket连接;消息由producer直接通过socket发送到broker,中间不会经过任何"路由层".事实上,消息被路由到哪个partition上,有producer客户端决定.比如可以采用"random""key-hash""轮询"等,如果一个topic中有多个partitions,那么在producer端实现"消息均衡分发"是必要的.在producer端的配置文件中,开发者可以指定partition路由的方式.

     Asynchronous send

    将多条消息暂且在客户端buffer起来,并将他们批量发送到broker;小数据IO太多,会拖慢整体的网络延迟,批量延迟发送事实上提升了网络效率;不过这也有一定的隐患,比如当producer失效时,那些尚未发送的消息将会丢失.

     4.Consumer

    consumer端向broker发送"fetch"请求,并告知其获取消息的offset;此后consumer将会获得一定条数的消息;consumer端也可以重置offset来重新消费消息.[备注:offset,消息偏移量,integer值,broker可以根据offset来决定消息的起始位置]

    在JMS实现中,Topic模型基于push方式,即broker将消息推送给consumer端.不过在kafka中,采用了pull方式,即consumer在和broker建立连接之后,主动去pull(或者说fetch)消息;这中模式有些优点,首先consumer端可以根据自己的消费能力适时的去fetch消息并处理,且可以控制消息消费的进度(offset);此外,消费者可以良好的控制消息消费的数量,batch fetch.

    其他JMS实现,消息消费的位置是有prodiver保留,以便避免重复发送消息或者将没有消费成功的消息重发等,同时还要控制消息的状态.这就要求JMS broker需要太多额外的工作.在kafka中,partition中的消息只有一个consumer在消费,且不存在消息状态的控制,也没有复杂的消息确认机制,可见kafka broker端是相当轻量级的.当消息被consumer接收之后,consumer可以在本地保存最后消息的offset,并间歇性的向zookeeper注册offset.由此可见,consumer客户端也很轻量级.

    这就意味着,kafka中consumer负责维护消息的消费记录,而broker则不关心这些,这种设计不仅提高了consumer端的灵活性,也适度的减轻了broker端设计的复杂度;这是和众多JMS prodiver的区别.此外,kafka中消息ACK的设计也和JMS有很大不同,kafka中的消息时批量(通常以消息的条数或者chunk的尺寸为单位)发送给consumer,当消息消费成功后,向zookeeper提交消息的offset,而不会向broker交付ACK.或许你已经意识到,这种"宽松"的设计,将会有"丢失"消息/"消息重发"的危险.

     5.Message Delivery Semantics

    对于JMS实现,消息传输担保非常直接:有且只有一次(exactly once).在kafka中稍有不同,对于consumer而言:

    1) at most once: 最多一次,这个和JMS中"非持久化"消息类似.发送一次,无论成败,将不会重发.

    2) at least once: 消息至少发送一次,如果消息未能接受成功,可能会重发,直到接收成功.

    3) exactly once: 消息只会发送一次.

    at most once: 消费者fetch消息,然后保存offset,然后处理消息;当client保存offset之后,但是在消息处理过程中consumer进程失效(crash),导致部分消息未能继续处理.那么此后可能其他consumer会接管,但是因为offset已经提前保存,那么新的consumer将不能fetch到offset之前的消息(尽管它们尚没有被处理),这就是"at most once".

    at least once: 消费者fetch消息,然后处理消息,然后保存offset.如果消息处理成功之后,但是在保存offset阶段zookeeper异常或者consumer失效,导致保存offset操作未能执行成功,这就导致接下来再次fetch时可能获得上次已经处理过的消息,这就是"at least once".

    exactly once: kafka中并没有严格的去实现(基于2阶段提交,事务),我们认为这种策略在kafka中是没有必要的.

    因为"消息消费"和"保存offset"这两个操作的先后时机不同,导致了上述3种情况,通常情况下"at-least-once"是我们搜选.(相比at most once而言,重复接收数据总比丢失数据要好).

     6. Replication

    kafka中,replication策略是基于partition,而不是topic;kafka将每个partition数据复制到多个server上,任何一个partition有一个leader和多个follower(可以没有);备份的个数可以通过broker配置文件来设定.leader处理所有的read-write请求,follower需要和leader保持同步.Follower就像一个"consumer",消费消息并保存在本地日志中;leader负责跟踪所有的follower状态,如果follower"落后"太多或者失效,leader将会把它从replicas同步列表中删除.当所有的follower都将一条消息保存成功,此消息才被认为是"committed",那么此时consumer才能消费它,这种同步策略,就要求follower和leader之间必须具有良好的网络环境.即使只有一个replicas实例存活,仍然可以保证消息的正常发送和接收,只要zookeeper集群存活即可.(备注:不同于其他分布式存储,比如hbase需要"多数派"存活才行)

    kafka判定一个follower存活与否的条件有2个:1) follower需要和zookeeper保持良好的链接 2) 它必须能够及时的跟进leader,不能落后太多.如果同时满足上述2个条件,那么leader就认为此follower是"活跃的".如果一个follower失效(server失效)或者落后太多,leader将会把它从同步列表中移除[备注:如果此replicas落后太多,它将会继续从leader中fetch数据,直到足够up-to-date,然后再次加入到同步列表中;kafka不会更换replicas宿主!因为"同步列表"中replicas需要足够快,这样才能保证producer发布消息时接受到ACK的延迟较小].

    当leader失效时,需在followers中选取出新的leader,可能此时follower落后于leader,因此需要选择一个"up-to-date"的follower.kafka中leader选举并没有采用"投票多数派"的算法,因为这种算法对于"网络稳定性"/"投票参与者数量"等条件有较高的要求,而且kafka集群的设计,还需要容忍N-1个replicas失效.对于kafka而言,每个partition中所有的replicas信息都可以在zookeeper中获得,那么选举leader将是一件非常简单的事情.选择follower时需要兼顾一个问题,就是新leader server上所已经承载的partition leader的个数,如果一个server上有过多的partition leader,意味着此server将承受着更多的IO压力.在选举新leader,需要考虑到"负载均衡",partition leader较少的broker将会更有可能成为新的leader.

    在整几个集群中,只要有一个replicas存活,那么此partition都可以继续接受读写操作.

     7.Log

    如果一个topic的名称为"my_topic",它有2个partitions,那么日志将会保存在my_topic_0和my_topic_1两个目录中;日志文件中保存了一序列"log entries"(日志条目),每个log entry格式为"4个字节的数字N表示消息的长度" + "N个字节的消息内容";每个日志都有一个offset来唯一的标记一条消息,offset的值为8个字节的数字,表示此消息在此partition中所处的起始位置..每个partition在物理存储层面,有多个log file组成(称为segment).segment file的命名为"最小offset".kafka.例如"00000000000.kafka";其中"最小offset"表示此segment中起始消息的offset.

(摘自官网) 

    其中每个partiton中所持有的segments列表信息会存储在zookeeper中.

    当segment文件尺寸达到一定阀值时(可以通过配置文件设定,默认1G),将会创建一个新的文件;当buffer中消息的条数达到阀值时将会触发日志信息flush到日志文件中,同时如果"距离最近一次flush的时间差"达到阀值时,也会触发flush到日志文件.如果broker失效,极有可能会丢失那些尚未flush到文件的消息.因为server意外失效,仍然会导致log文件格式的破坏(文件尾部),那么就要求当server启东是需要检测最后一个segment的文件结构是否合法并进行必要的修复.

    获取消息时,需要指定offset和最大chunk尺寸,offset用来表示消息的起始位置,chunk size用来表示最大获取消息的总长度(间接的表示消息的条数).根据offset,可以找到此消息所在segment文件,然后根据segment的最小offset取差值,得到它在file中的相对位置,直接读取输出即可.

    日志文件的删除策略非常简单:启动一个后台线程定期扫描log file列表,把保存时间超过阀值的文件直接删除(根据文件的创建时间).为了避免删除文件时仍然有read操作(consumer消费),采取copy-on-write方式.

     8.Distribution

    kafka使用zookeeper来存储一些meta信息,并使用了zookeeper watch机制来发现meta信息的变更并作出相应的动作(比如consumer失效,触发负载均衡等)

     1) Broker node registry: 当一个kafka broker启动后,首先会向zookeeper注册自己的节点信息(临时znode),同时当broker和zookeeper断开连接时,此znode也会被删除.

    格式: /broker/ids/[0...N]   -->host:port;其中[0..N]表示broker id,每个broker的配置文件中都需要指定一个数字类型的id(全局不可重复),znode的值为此broker的host:port信息.

     2) Broker Topic Registry: 当一个broker启动时,会向zookeeper注册自己持有的topic和partitions信息,仍然是一个临时znode.

    格式: /broker/topics/[topic]/[0...N]  其中[0..N]表示partition索引号.

     3) Consumer and Consumer group: 每个consumer客户端被创建时,会向zookeeper注册自己的信息;此作用主要是为了"负载均衡".

    一个group中的多个consumer可以交错的消费一个topic的所有partitions;简而言之,保证此topic的所有partitions都能被此group所消费,且消费时为了性能考虑,让partition相对均衡的分散到每个consumer上.

     4) Consumer id Registry: 每个consumer都有一个唯一的ID(host:uuid,可以通过配置文件指定,也可以由系统生成),此id用来标记消费者信息.

    格式: /consumers/[group_id]/ids/[consumer_id]

    仍然是一个临时的znode,此节点的值为{"topic_name":#streams...},即表示此consumer目前所消费的topic + partitions列表.

     5) Consumer offset Tracking: 用来跟踪每个consumer目前所消费的partition中最大的offset.

    格式: /consumers/[group_id]/offsets/[topic]/[broker_id-partition_id]   -->offset_value

    此znode为持久节点,可以看出offset跟group_id有关,以表明当group中一个消费者失效,其他consumer可以继续消费.

     6) Partition Owner registry: 用来标记partition正在被哪个consumer消费.临时znode

    格式: /consumers/[group_id]/owners/[topic]/[broker_id-partition_id]   -->consumer_node_id

    此节点表达了"一个partition"只能被group下一个consumer消费,同时当group下某个consumer失效,那么将会触发负载均衡(即:让partitions在多个consumer间均衡消费,接管那些"游离"的partitions)

    当consumer启动时,所触发的操作:

    A) 首先进行"Consumer id Registry";

    B) 然后在"Consumer id Registry"节点下注册一个watch用来监听当前group中其他consumer的"leave"和"join";只要此znode path下节点列表变更,都会触发此group下consumer的负载均衡.(比如一个consumer失效,那么其他consumer接管partitions).

    C) 在"Broker id registry"节点下,注册一个watch用来监听broker的存活情况;如果broker列表变更,将会触发所有的groups下的consumer重新balance.

     Consumer均衡算法

    当一个group中,有consumer加入或者离开时,会触发partitions均衡.均衡的最终目的,是提升topic的并发消费能力.

     1) 假如topic1,具有如下partitions: P0,P1,P2,P3

     2) 加入group中,有如下consumer: C0,C1

     3) 首先根据partition索引号对partitions排序: P0,P1,P2,P3

     4) 根据consumer.id排序: C0,C1

     5) 计算倍数: M = [P0,P1,P2,P3].size / [C0,C1].size,本例值M=2(向上取整)

     6) 然后依次分配partitions: C0 = [P0,P1],C1=[P2,P3],即Ci = [P(i * M),P((i + 1) * M -1)]

     总结: 

    1) Producer端使用zookeeper用来"发现"broker列表,以及和Topic下每个partition leader建立socket连接并发送消息.

    2) Broker端使用zookeeper用来注册broker信息,已经监测partition leader存活性.

    3) Consumer端使用zookeeper用来注册consumer信息,其中包括consumer消费的partition列表等,同时也用来发现broker列表,并和partition leader建立socket连接,并获取消息.

<script language="javascript">  
function printdiv(printpage)  
{  
var headstr = "<html><head><title></title></head><body>";  
var footstr = "</body>";  
var printData = document.getElementById("dvData").innerHTML; 获得 div 里的所有 html 数据
var oldstr = document.body.innerHTML;  
document.body.innerHTML = headstr+newstr+footstr;  
window.print();  
document.body.innerHTML = oldstr;  
return false;  
}  

现在、将来，用移动设备上网越来越成为主流。但对于开发者们来说，移动web的调试一直是个难题，前期可以使用模拟器来协助调试，但到了真机调试阶段就让人非常头痛。而Weinre就是解决这难题的利器。　

　　Weinre的本意是Web Inspector Remote，它是一种远程调试工具。功能与Firebug、Webkit inspector类似，可以帮助我们即时更改页面元素、样式，调试JS等，下面就简单介绍下如何使用。下面以以Windows系统为例：

　 　一、首先确保你的电脑已经搭建好了java环境。即：安装了jdk。这里就不多说了，在网上搜个jdk，一步步安装及ok。

　　二、 安装及运行Weinre

　　　　1、下载： http://ishare.iask.sina.com.cn/f/23607399.html  ，这里直接下载jar包，下载好之后放在一个文件夹里就行不需任何处理。

　　　　  2、运行cmd，在weinre所在文件夹的 地址栏输入代码：java -jar weinre.jar --httpPort 8081 --boundHost -all-  （如下图）：

　　　　  3、回车后会出现相应信息(注意：在调试过程中不要关闭cmd)：

　　　　 4、打开本地浏览器，（使用webkit内核浏览器(chrome、safari)）访问  http://localhost:8081/，不出意外的话可以看到weinre的基本信息。

　　　　 5、上图中的"debug client user interface"是weinre的Debug客户端，点击进入后可以看到目前还没有被测试的目标网页。

　　三、 添加Debug Target

　　　　为了让需要调试的页面被weinre检测到，需要添加Debug Target，有两种方法：
　　　　 1、Target Script  

           该方法需要在调试的页面中增加一个 js：

<script src="http://192.168.0.106:8081/target/target-script-min.js#anonymous" type="text/javascript"></script>

　　　　添加后在移动设备中访问该页面即可，如果调试的页面比较少可以使用这个方法，如果多的话推荐第二种方法

　　　　 2、Target Bookmarklet
　　　　该方法是将一段js保存到移动设备的书签中，可以在 http://localhost:8081/ 找到这段js：

javascript:(function(e){e.setAttribute("src","http://localhost:8081/target/target-script-min.js#anonymous");document.getElementsByTagName("body")[0].appendChild(e);})(document.createElement("script"));void(0);

　　　　我将这段js保存到名为Debug书签中，然后使用移动设备访问我想要调试的页面，比如说 http://iinterest.net，最后点击Debug书签就OK了。

　 　四、真机调试。

　　 　1、　移动设备须有有 wifi无线连接，且和电脑在同一网段，（确保本机安装了 服务器，可以到网上搜 xampp或 wamp，）把要调试的 页面放在服务器中相应的文件夹中,我安装的是xampp,所以放在htdocs目录下。在手机的页面中打开本页面的地址，如：http://192.168.0.102/index.html 。回到http://localhost:8081页面，点击“debug client user interface:”链接进入weinre的Debug界面，如果成功添加了Debug Target，这里可以看到它。

　　2、接下来我们就可用自己熟悉的方式调试页面了，并且调试结果会实时显示在移动设备上

MAC系统更为简单，不用命令行，直接运行app即可启动weinre，接下来的步骤和windows一样。

参考：http://www.iinterest.net/2012/02/08/debugging-mobile-web-applications-with-the-weinre/