Hexo

从实际案例聊聊Java应用的GC优化

2018-04-05T16:01:44.000Z

当Java程序性能达不到既定目标，且其他优化手段都已经穷尽时，通常需要调整垃圾回收器来进一步提高性能，称为GC优化。但GC算法复杂，影响GC性能的参数众多，且参数调整又依赖于应用各自的特点，这些因素很大程度上增加了GC优化的难度。即便如此，GC调优也不是无章可循，仍然有一些通用的思考方法。本篇会介绍这些通用的GC优化策略和相关实践案例，主要包括如下内容：

优化前准备: 简单回顾JVM相关知识、介绍GC优化的一些通用策略。
优化方法: 介绍调优的一般流程：明确优化目标→优化→跟踪优化结果。
优化案例: 简述笔者所在团队遇到的GC问题以及优化方案。

一、优化前的准备

GC优化需知

为了更好地理解本篇所介绍的内容，你需要了解如下内容。

GC相关基础知识，包括但不限于：
a) GC工作原理。
b) 理解新生代、老年代、晋升等术语含义。
c) 可以看懂GC日志。
GC优化不能解决一切性能问题，它是最后的调优手段。

如果对第一点中提及的知识点不是很熟悉，可以先阅读小结-JVM基础回顾；如果已经很熟悉，可以跳过该节直接往下阅读。

JVM基础回顾

JVM内存结构

简单介绍一下JVM内存结构和常见的垃圾回收器。

当代主流虚拟机（Hotspot VM）的垃圾回收都采用“分代回收”的算法。“分代回收”是基于这样一个事实：对象的生命周期不同，所以针对不同生命周期的对象可以采取不同的回收方式，以便提高回收效率。

Hotspot VM将内存划分为不同的物理区，就是“分代”思想的体现。如图所示，JVM内存主要由新生代、老年代、永久代构成。

① 新生代（Young Generation）：大多数对象在新生代中被创建，其中很多对象的生命周期很短。每次新生代的垃圾回收（又称Minor GC）后只有少量对象存活，所以选用复制算法，只需要少量的复制成本就可以完成回收。

新生代内又分三个区：一个Eden区，两个Survivor区（一般而言），大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到两个Survivor区（中的一个）。当这个Survivor区满时，此区的存活且不满足“晋升”条件的对象将被复制到另外一个Survivor区。对象每经历一次Minor GC，年龄加1，达到“晋升年龄阈值”后，被放到老年代，这个过程也称为“晋升”。显然，“晋升年龄阈值”的大小直接影响着对象在新生代中的停留时间，在Serial和ParNew GC两种回收器中，“晋升年龄阈值”通过参数MaxTenuringThreshold设定，默认值为15。

② 老年代（Old Generation）：在新生代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代，该区域中对象存活率高。老年代的垃圾回收（又称Major GC）通常使用“标记-清理”或“标记-整理”算法。整堆包括新生代和老年代的垃圾回收称为Full GC（HotSpot VM里，除了CMS之外，其它能收集老年代的GC都会同时收集整个GC堆，包括新生代）。

③ 永久代（Perm Generation）：主要存放元数据，例如Class、Method的元信息，与垃圾回收要回收的Java对象关系不大。相对于新生代和年老代来说，该区域的划分对垃圾回收影响比较小。

常见垃圾回收器

不同的垃圾回收器，适用于不同的场景。常用的垃圾回收器：

串行（Serial）回收器是单线程的一个回收器，简单、易实现、效率高。
并行（ParNew）回收器是Serial的多线程版，可以充分的利用CPU资源，减少回收的时间。
吞吐量优先（Parallel Scavenge）回收器，侧重于吞吐量的控制。
并发标记清除（CMS，Concurrent Mark Sweep）回收器是一种以获取最短回收停顿时间为目标的回收器，该回收器是基于“标记-清除”算法实现的。

GC日志

每一种回收器的日志格式都是由其自身的实现决定的，换而言之，每种回收器的日志格式都可以不一样。但虚拟机设计者为了方便用户阅读，将各个回收器的日志都维持一定的共性。JavaGC日志中简单介绍了这些共性。

参数基本策略

各分区的大小对GC的性能影响很大。如何将各分区调整到合适的大小，分析活跃数据的大小是很好的切入点。

活跃数据的大小是指，应用程序稳定运行时长期存活对象在堆中占用的空间大小，也就是Full GC后堆中老年代占用空间的大小。可以通过GC日志中Full GC之后老年代数据大小得出，比较准确的方法是在程序稳定后，多次获取GC数据，通过取平均值的方式计算活跃数据的大小。活跃数据和各分区之间的比例关系如下（见参考文献1）：

空间	倍数
总大小	3-4 倍活跃数据的大小
新生代	1-1.5 活跃数据的大小
老年代	2-3 倍活跃数据的大小
永久代	1.2-1.5 倍Full GC后的永久代空间占用

例如，根据GC日志获得老年代的活跃数据大小为300M，那么各分区大小可以设为：

总堆：1200MB = 300MB × 4
新生代：450MB = 300MB × 1.5
老年代： 750MB = 1200MB - 450MB*

这部分设置仅仅是堆大小的初始值，后面的优化中，可能会调整这些值，具体情况取决于应用程序的特性和需求。

二、优化步骤

GC优化一般步骤可以概括为：确定目标、优化参数、验收结果。

确定目标

明确应用程序的系统需求是性能优化的基础，系统的需求是指应用程序运行时某方面的要求，譬如：

高可用，可用性达到几个9。
低延迟，请求必须多少毫秒内完成响应。
高吞吐，每秒完成多少次事务。

明确系统需求之所以重要，是因为上述性能指标间可能冲突。比如通常情况下，缩小延迟的代价是降低吞吐量或者消耗更多的内存或者两者同时发生。

由于笔者所在团队主要关注高可用和低延迟两项指标，所以接下来分析，如何量化GC时间和频率对于响应时间和可用性的影响。通过这个量化指标，可以计算出当前GC情况对服务的影响，也能评估出GC优化后对响应时间的收益，这两点对于低延迟服务很重要。

举例：假设单位时间T内发生一次持续25ms的GC，接口平均响应时间为50ms，且请求均匀到达，根据下图所示：

那么有(50ms+25ms)/T比例的请求会受GC影响，其中GC前的50ms内到达的请求都会增加25ms，GC期间的25ms内到达的请求，会增加0-25ms不等，如果时间T内发生N次GC，受GC影响请求占比=(接口响应时间+GC时间)×N/T 。可见无论降低单次GC时间还是降低GC次数N都可以有效减少GC对响应时间的影响。

优化

通过收集GC信息，结合系统需求，确定优化方案，例如选用合适的GC回收器、重新设置内存比例、调整JVM参数等。

进行调整后，将不同的优化方案分别应用到多台机器上，然后比较这些机器上GC的性能差异，有针对性的做出选择，再通过不断的试验和观察，找到最合适的参数。

验收优化结果

将修改应用到所有服务器，判断优化结果是否符合预期，总结相关经验。

接下来，我们通过三个案例来实践以上的优化流程和基本原则（本文中三个案例使用的垃圾回收器均为ParNew+CMS，CMS失败时Serial Old替补)。

三、GC优化案例

案例一 Major GC和Minor GC频繁

确定目标

服务情况：Minor GC每分钟100次，Major GC每4分钟一次，单次Minor GC耗时25ms，单次Major GC耗时200ms，接口响应时间50ms。

由于这个服务要求低延时高可用，结合上文中提到的GC对服务响应时间的影响，计算可知由于Minor GC的发生，12.5%的请求响应时间会增加，其中8.3%的请求响应时间会增加25ms，可见当前GC情况对响应时间影响较大。

（50ms+25ms）× 100次/60000ms = 12.5%，50ms × 100次/60000ms = 8.3% 。

优化目标：降低TP99、TP90时间。

优化

首先优化Minor GC频繁问题。通常情况下，由于新生代空间较小，Eden区很快被填满，就会导致频繁Minor GC，因此可以通过增大新生代空间来降低Minor GC的频率。例如在相同的内存分配率的前提下，新生代中的Eden区增加一倍，Minor GC的次数就会减少一半。

这时很多人有这样的疑问，扩容Eden区虽然可以减少Minor GC的次数，但会增加单次Minor GC时间么？根据上面公式，如果单次Minor GC时间也增加，很难保证最后的优化效果。我们结合下面情况来分析，单次Minor GC时间主要受哪些因素影响？是否和新生代大小存在线性关系？
首先，单次Minor GC时间由以下两部分组成：T1（扫描新生代）和 T2（复制存活对象到Survivor区）如下图。（注：这里为了简化问题，我们认为T1只扫描新生代判断对象是否存活的时间，其实该阶段还需要扫描部分老年代，后面案例中有详细描述。）

扩容前：新生代容量为R ，假设对象A的存活时间为750ms，Minor GC间隔500ms，那么本次Minor GC时间= T1（扫描新生代R）+T2（复制对象A到S）。
扩容后：新生代容量为2R ，对象A的生命周期为750ms，那么Minor GC间隔增加为1000ms，此时Minor GC对象A已不再存活，不需要把它复制到Survivor区，那么本次GC时间 = 2 × T1（扫描新生代R），没有T2复制时间。

可见，扩容后，Minor GC时增加了T1（扫描时间），但省去T2（复制对象）的时间，更重要的是对于虚拟机来说，复制对象的成本要远高于扫描成本，所以，单次Minor GC时间更多取决于GC后存活对象的数量，而非Eden区的大小。因此如果堆中短期对象很多，那么扩容新生代，单次Minor GC时间不会显著增加。下面需要确认下服务中对象的生命周期分布情况：

通过上图GC日志中两处红色框标记内容可知：

new threshold = 2（动态年龄判断，对象的晋升年龄阈值为2），对象仅经历2次Minor GC后就晋升到老年代，这样老年代会迅速被填满，直接导致了频繁的Major GC。
Major GC后老年代使用空间为300M+，意味着此时绝大多数(86% = 2G/2.3G)的对象已经不再存活，也就是说生命周期长的对象占比很小。

由此可见，服务中存在大量短期临时对象，扩容新生代空间后，Minor GC频率降低，对象在新生代得到充分回收，只有生命周期长的对象才进入老年代。这样老年代增速变慢，Major GC频率自然也会降低。

优化结果

通过扩容新生代为为原来的三倍，单次Minor GC时间增加小于5ms，频率下降了60%，服务响应时间TP90，TP99都下降了10ms+，服务可用性得到提升。

调整前：

调整后：

小结

如何选择各分区大小应该依赖应用程序中对象生命周期的分布情况：如果应用存在大量的短期对象，应该选择较大的年轻代；如果存在相对较多的持久对象，老年代应该适当增大。

优化结果

经过增加CMSScavengeBeforeRemark参数，单次执行时间>200ms的GC停顿消失，从监控上观察，GCtime和业务波动保持一致，不再有明显的毛刺。

小结

通过案例分析了解到，由于跨代引用的存在，CMS在Remark阶段必须扫描整个堆，同时为了避免扫描时新生代有很多对象，增加了可中断的预清理阶段用来等待Minor GC的发生。只是该阶段有时间限制，如果超时等不到Minor GC，Remark时新生代仍然有很多对象，我们的调优策略是，通过参数强制Remark前进行一次Minor GC，从而降低Remark阶段的时间。

案例三发生Stop-The-World的GC

确定目标

GC日志如下图（在GC日志中，Full GC是用来说明这次垃圾回收的停顿类型，代表STW类型的GC，并不特指老年代GC），根据GC日志可知本次Full GC耗时1.23s。这个在线服务同样要求低时延高可用。本次优化目标是降低单次STW回收停顿时间，提高可用性。

优化

首先，什么时候可能会触发STW的Full GC呢？

Perm空间不足；
CMS GC时出现promotion failed和concurrent mode failure（concurrent mode failure发生的原因一般是CMS正在进行，但是由于老年代空间不足，需要尽快回收老年代里面的不再被使用的对象，这时停止所有的线程，同时终止CMS，直接进行Serial Old GC）；
统计得到的Young GC晋升到老年代的平均大小大于老年代的剩余空间；
主动触发Full GC（执行jmap -histo:live [pid]）来避免碎片问题。

然后，我们来逐一分析一下：

排除原因2：如果是原因2中两种情况，日志中会有特殊标识，目前没有。
排除原因3：根据GC日志，当时老年代使用量仅为20%，也不存在大于2G的大对象产生。
排除原因4：因为当时没有相关命令执行。
锁定原因1：根据日志发现Full GC后，Perm区变大了，推断是由于永久代空间不足容量扩展导致的。

找到原因后解决方法有两种：

通过把-XX:PermSize参数和-XX:MaxPermSize设置成一样，强制虚拟机在启动的时候就把永久代的容量固定下来，避免运行时自动扩容。
CMS默认情况下不会回收Perm区，通过参数CMSPermGenSweepingEnabled、CMSClassUnloadingEnabled ，可以让CMS在Perm区容量不足时对其回收。

由于该服务没有生成大量动态类，回收Perm区收益不大，所以我们采用方案1，启动时将Perm区大小固定，避免进行动态扩容。

优化结果

调整参数后，服务不再有Perm区扩容导致的STW GC发生。

小结

对于性能要求很高的服务，建议将MaxPermSize和MinPermSize设置成一致（JDK8开始，Perm区完全消失，转而使用元空间。而元空间是直接存在内存中，不在JVM中），Xms和Xmx也设置为相同，这样可以减少内存自动扩容和收缩带来的性能损失。虚拟机启动的时候就会把参数中所设定的内存全部化为私有，即使扩容前有一部分内存不会被用户代码用到，这部分内存在虚拟机中被标识为虚拟内存，也不会交给其他进程使用。

四、总结

结合上述GC优化案例做个总结：

首先再次声明，在进行GC优化之前，需要确认项目的架构和代码等已经没有优化空间。我们不能指望一个系统架构有缺陷或者代码层次优化没有穷尽的应用，通过GC优化令其性能达到一个质的飞跃。
其次，通过上述分析，可以看出虚拟机内部已有很多优化来保证应用的稳定运行，所以不要为了调优而调优，不当的调优可能适得其反。
最后，GC优化是一个系统而复杂的工作，没有万能的调优策略可以满足所有的性能指标。GC优化必须建立在我们深入理解各种垃圾回收器的基础上，才能有事半功倍的效果。

本文中案例均来北京业务安全中心（也称风控）对接服务的实践经验。同时感谢风控的小伙伴们，是他们专业负责的审阅，才让这篇文章更加完善。对于本文中涉及到的内容，欢迎大家指正和补充。

深入分析CAS

2018-04-05T15:51:55.000Z

CAS，Compare And Swap，即比较并交换。Doug lea大神在同步组件中大量使用CAS技术鬼斧神工地实现了Java多线程的并发操作。整个AQS同步组件、Atomic原子类操作等等都是以CAS实现的，甚至ConcurrentHashMap在1.8的版本中也调整为了CAS+Synchronized。可以说CAS是整个JUC的基石。

CAS分析

在CAS中有三个参数：内存值V、旧的预期值A、要更新的值B，当且仅当内存值V的值等于旧的预期值A时才会将内存值V的值修改为B，否则什么都不干。其伪代码如下：

if(this.value == A){
 this.value = B
 return true;
}else{
 return false;
}

JUC下的atomic类都是通过CAS来实现的，下面就以AtomicInteger为例来阐述CAS的实现。如下：

private static final Unsafe unsafe = Unsafe.getUnsafe();
private static final long valueOffset;

static {
 try {
 valueOffset = unsafe.objectFieldOffset
 (AtomicInteger.class.getDeclaredField("value"));
 } catch (Exception ex) { throw new Error(ex); }
}

private volatile int value;

Unsafe是CAS的核心类，Java无法直接访问底层操作系统，而是通过本地（native）方法来访问。不过尽管如此，JVM还是开了一个后门：Unsafe，它提供了硬件级别的原子操作。

valueOffset为变量值在内存中的偏移地址，unsafe就是通过偏移地址来得到数据的原值的。

value当前值，使用volatile修饰，保证多线程环境下看见的是同一个。

我们就以AtomicInteger的addAndGet()方法来做说明，先看源代码：

public final int addAndGet(int delta) {
 return unsafe.getAndAddInt(this, valueOffset, delta) + delta;
}

public final int getAndAddInt(Object var1, long var2, int var4) {
 int var5;
 do {
 var5 = this.getIntVolatile(var1, var2);
 } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

 return var5;
}

内部调用unsafe的getAndAddInt方法，在getAndAddInt方法中主要是看compareAndSwapInt方法：

1	public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);

该方法为本地方法，有四个参数，分别代表：对象、对象的地址、预期值、修改值（有位伙伴告诉我他面试的时候就问到这四个变量是啥意思…+_+）。该方法的实现这里就不做详细介绍了，有兴趣的伙伴可以看看openjdk的源码。

CAS可以保证一次的读-改-写操作是原子操作，在单处理器上该操作容易实现，但是在多处理器上实现就有点儿复杂了。

CPU提供了两种方法来实现多处理器的原子操作：总线加锁或者缓存加锁。

总线加锁：总线加锁就是就是使用处理器提供的一个LOCK#信号，当一个处理器在总线上输出此信号时，其他处理器的请求将被阻塞住,那么该处理器可以独占使用共享内存。但是这种处理方式显得有点儿霸道，不厚道，他把CPU和内存之间的通信锁住了，在锁定期间，其他处理器都不能其他内存地址的数据，其开销有点儿大。所以就有了缓存加锁。

缓存加锁：其实针对于上面那种情况我们只需要保证在同一时刻对某个内存地址的操作是原子性的即可。缓存加锁就是缓存在内存区域的数据如果在加锁期间，当它执行锁操作写回内存时，处理器不在输出LOCK#信号，而是修改内部的内存地址，利用缓存一致性协议来保证原子性。缓存一致性机制可以保证同一个内存区域的数据仅能被一个处理器修改，也就是说当CPU1修改缓存行中的i时使用缓存锁定，那么CPU2就不能同时缓存了i的缓存行。

CAS缺陷

CAS虽然高效地解决了原子操作，但是还是存在一些缺陷的，主要表现在三个方法：循环时间太长、只能保证一个共享变量原子操作、ABA问题。

循环时间太长

如果CAS一直不成功呢？这种情况绝对有可能发生，如果自旋CAS长时间地不成功，则会给CPU带来非常大的开销。在JUC中有些地方就限制了CAS自旋的次数，例如BlockingQueue的SynchronousQueue。

只能保证一个共享变量原子操作

看了CAS的实现就知道这只能针对一个共享变量，如果是多个共享变量就只能使用锁了，当然如果你有办法把多个变量整成一个变量，利用CAS也不错。例如读写锁中state的高地位

ABA问题

CAS需要检查操作值有没有发生改变，如果没有发生改变则更新。但是存在这样一种情况：如果一个值原来是A，变成了B，然后又变成了A，那么在CAS检查的时候会发现没有改变，但是实质上它已经发生了改变，这就是所谓的ABA问题。对于ABA问题其解决方案是加上版本号，即在每个变量都加上一个版本号，每次改变时加1，即A —> B —> A，变成1A —> 2B —> 3A。

用一个例子来阐述ABA问题所带来的影响。

有如下链表

假如我们想要把B替换为A，也就是compareAndSet(this,A,B)。线程1执行B替换A操作，线程2主要执行如下动作，A 、B出栈，然后C、A入栈，最终该链表如下：

完成后线程1发现仍然是A，那么compareAndSet(this,A,B)成功，但是这时会存在一个问题就是B.next = null,compareAndSet(this,A,B)后，会导致C丢失，改栈仅有一个B元素，平白无故把C给丢失了。

CAS的ABA隐患问题，解决方案则是版本号，Java提供了AtomicStampedReference来解决。AtomicStampedReference通过包装[E,Integer]的元组来对对象标记版本戳stamp，从而避免ABA问题。对于上面的案例应该线程1会失败。

AtomicStampedReference的compareAndSet()方法定义如下：

public boolean compareAndSet(V   expectedReference,
 V   newReference,
 int expectedStamp,
 int newStamp) {
 Pair current = pair;
 return
 expectedReference == current.reference &&
 expectedStamp == current.stamp &&
 ((newReference == current.reference &&
 newStamp == current.stamp) ||
 casPair(current, Pair.of(newReference, newStamp)));
}

compareAndSet有四个参数，分别表示：预期引用、更新后的引用、预期标志、更新后的标志。源码部门很好理解预期的引用 == 当前引用，预期的标识 == 当前标识，如果更新后的引用和标志和当前的引用和标志相等则直接返回true，否则通过Pair生成一个新的pair对象与当前pair CAS替换。Pair为AtomicStampedReference的内部类，主要用于记录引用和版本戳信息（标识），定义如下：

private static class Pair {
 final T reference;
 final int stamp;
 private Pair(T reference, int stamp) {
 this.reference = reference;
 this.stamp = stamp;
 }
 static  Pair of(T reference, int stamp) {
 return new Pair(reference, stamp);
 }
}

private volatile Pair pair;

Pair记录着对象的引用和版本戳，版本戳为int型，保持自增。同时Pair是一个不可变对象，其所有属性全部定义为final，对外提供一个of方法，该方法返回一个新建的Pari对象。pair对象定义为volatile，保证多线程环境下的可见性。在AtomicStampedReference中，大多方法都是通过调用Pair的of方法来产生一个新的Pair对象，然后赋值给变量pair。如set方法：

public void set(V newReference, int newStamp) {
 Pair current = pair;
 if (newReference != current.reference || newStamp != current.stamp)
 this.pair = Pair.of(newReference, newStamp);
}

下面我们将通过一个例子可以可以看到AtomicStampedReference和AtomicInteger的区别。我们定义两个线程，线程1负责将100 —> 110 —> 100，线程2执行 100 —>120，看两者之间的区别。

public class Test {
 private static AtomicInteger atomicInteger = new AtomicInteger(100);
 private static AtomicStampedReference atomicStampedReference = new AtomicStampedReference(100,1);

 public static void main(String[] args) throws InterruptedException {

 //AtomicInteger
 Thread at1 = new Thread(new Runnable() {
 @Override
 public void run() {
 atomicInteger.compareAndSet(100,110);
 atomicInteger.compareAndSet(110,100);
 }
 });

 Thread at2 = new Thread(new Runnable() {
 @Override
 public void run() {
 try {
 TimeUnit.SECONDS.sleep(2);      // at1,执行完
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 System.out.println("AtomicInteger:" + atomicInteger.compareAndSet(100,120));
 }
 });

 at1.start();
 at2.start();

 at1.join();
 at2.join();

 //AtomicStampedReference

 Thread tsf1 = new Thread(new Runnable() {
 @Override
 public void run() {
 try {
 //让 tsf2先获取stamp，导致预期时间戳不一致
 TimeUnit.SECONDS.sleep(2);
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 // 预期引用：100，更新后的引用：110，预期标识getStamp() 更新后的标识getStamp() + 1
 atomicStampedReference.compareAndSet(100,110,atomicStampedReference.getStamp(),atomicStampedReference.getStamp() + 1);
 atomicStampedReference.compareAndSet(110,100,atomicStampedReference.getStamp(),atomicStampedReference.getStamp() + 1);
 }
 });

 Thread tsf2 = new Thread(new Runnable() {
 @Override
 public void run() {
 int stamp = atomicStampedReference.getStamp();

 try {
 TimeUnit.SECONDS.sleep(2);      //线程tsf1执行完
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 System.out.println("AtomicStampedReference:" +atomicStampedReference.compareAndSet(100,120,stamp,stamp + 1));
 }
 });

 tsf1.start();
 tsf2.start();
 }

}

运行结果：

运行结果充分展示了AtomicInteger的ABA问题和AtomicStampedReference解决ABA问题。

深入分析volatile

2018-04-05T15:37:15.000Z

volatile这个关键字可能很多朋友都听说过，或许也都用过。在Java 5之前，它是一个备受争议的关键字，因为在程序中使用它往往会导致出人意料的结果。在Java 5之后，volatile关键字才得以重获生机。
volatile关键字虽然从字面上理解起来比较简单，但是要用好不是一件容易的事情。由于volatile关键字是与Java的内存模型有关的，因此在讲述volatile关键之前，我们先来了解一下与内存模型相关的概念和知识，然后分析了volatile关键字的实现原理，最后给出了几个使用volatile关键字的场景。

一.内存模型的相关概念

　　大家都知道，计算机在执行程序时，每条指令都是在CPU中执行的，而执行指令过程中，势必涉及到数据的读取和写入。由于程序运行过程中的临时数据是存放在主存（物理内存）当中的，这时就存在一个问题，由于CPU执行速度很快，而从内存读取数据和向内存写入数据的过程跟CPU执行指令的速度比起来要慢的多，因此如果任何时候对数据的操作都要通过和内存的交互来进行，会大大降低指令执行的速度。因此在CPU里面就有了高速缓存。

　　也就是，当程序在运行过程中，会将运算需要的数据从主存复制一份到CPU的高速缓存当中，那么CPU进行计算时就可以直接从它的高速缓存读取数据和向其中写入数据，当运算结束之后，再将高速缓存中的数据刷新到主存当中。举个简单的例子，比如下面的这段代码：

i = i+1;

　　当线程执行这个语句时，会先从主存当中读取i的值，然后复制一份到高速缓存当中，然后CPU执行指令对i进行加1操作，然后将数据写入高速缓存，最后将高速缓存中i最新的值刷新到主存当中。

　　这个代码在单线程中运行是没有任何问题的，但是在多线程中运行就会有问题了。在多核CPU中，每条线程可能运行于不同的CPU中，因此每个线程运行时有自己的高速缓存（对单核CPU来说，其实也会出现这种问题，只不过是以线程调度的形式来分别执行的）。本文我们以多核CPU为例。

　　比如同时有2个线程执行这段代码，假如初始时i的值为0，那么我们希望两个线程执行完之后i的值变为2。但是事实会是这样吗？

　　可能存在下面一种情况：初始时，两个线程分别读取i的值存入各自所在的CPU的高速缓存当中，然后线程1进行加1操作，然后把i的最新值1写入到内存。此时线程2的高速缓存当中i的值还是0，进行加1操作之后，i的值为1，然后线程2把i的值写入内存。

　　最终结果i的值是1，而不是2。这就是著名的缓存一致性问题。通常称这种被多个线程访问的变量为共享变量。

　　也就是说，如果一个变量在多个CPU中都存在缓存（一般在多线程编程时才会出现），那么就可能存在缓存不一致的问题。

　　为了解决缓存不一致性问题，通常来说有以下2种解决方法：

　　1）通过在总线加LOCK#锁的方式

　　2）通过缓存一致性协议

　　这2种方式都是硬件层面上提供的方式。

　　在早期的CPU当中，是通过在总线上加LOCK#锁的形式来解决缓存不一致的问题。因为CPU和其他部件进行通信都是通过总线来进行的，如果对总线加LOCK#锁的话，也就是说阻塞了其他CPU对其他部件访问（如内存），从而使得只能有一个CPU能使用这个变量的内存。比如上面例子中如果一个线程在执行 i = i +1，如果在执行这段代码的过程中，在总线上发出了LCOK#锁的信号，那么只有等待这段代码完全执行完毕之后，其他CPU才能从变量i所在的内存读取变量，然后进行相应的操作。这样就解决了缓存不一致的问题。

　　但是上面的方式会有一个问题，由于在锁住总线期间，其他CPU无法访问内存，导致效率低下。

　　所以就出现了缓存一致性协议。最出名的就是Intel 的MESI协议，MESI协议保证了每个缓存中使用的共享变量的副本是一致的。它核心的思想是：当CPU写数据时，如果发现操作的变量是共享变量，即在其他CPU中也存在该变量的副本，会发出信号通知其他CPU将该变量的缓存行置为无效状态，因此当其他CPU需要读取这个变量时，发现自己缓存中缓存该变量的缓存行是无效的，那么它就会从内存重新读取。

二.并发编程中的三个概念

　　在并发编程中，我们通常会遇到以下三个问题：原子性问题，可见性问题，有序性问题。我们先看具体看一下这三个概念：

1.原子性

　　原子性：即一个操作或者多个操作要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。

　　一个很经典的例子就是银行账户转账问题：

　　比如从账户A向账户B转1000元，那么必然包括2个操作：从账户A减去1000元，往账户B加上1000元。

　　试想一下，如果这2个操作不具备原子性，会造成什么样的后果。假如从账户A减去1000元之后，操作突然中止。然后又从B取出了500元，取出500元之后，再执行往账户B加上1000元的操作。这样就会导致账户A虽然减去了1000元，但是账户B没有收到这个转过来的1000元。

　　所以这2个操作必须要具备原子性才能保证不出现一些意外的问题。

　　同样地反映到并发编程中会出现什么结果呢？

　　举个最简单的例子，大家想一下假如为一个32位的变量赋值过程不具备原子性的话，会发生什么后果？
　　

i = 9;

　　假若一个线程执行到这个语句时，我暂且假设为一个32位的变量赋值包括两个过程：为低16位赋值，为高16位赋值。

　　那么就可能发生一种情况：当将低16位数值写入之后，突然被中断，而此时又有一个线程去读取i的值，那么读取到的就是错误的数据。

2.可见性

　　可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

　　举个简单的例子，看下面这段代码：

//线程1执行的代码

int i =0;

i =10;

//线程2执行的代码

j = i;

　　假若执行线程1的是CPU1，执行线程2的是CPU2。由上面的分析可知，当线程1执行 i =10这句时，会先把i的初始值加载到CPU1的高速缓存中，然后赋值为10，那么在CPU1的高速缓存当中i的值变为10了，却没有立即写入到主存当中。

　　此时线程2执行 j = i，它会先去主存读取i的值并加载到CPU2的缓存当中，注意此时内存当中i的值还是0，那么就会使得j的值为0，而不是10.

　　这就是可见性问题，线程1对变量i修改了之后，线程2没有立即看到线程1修改的值。

3.有序性

　　有序性：即程序执行的顺序按照代码的先后顺序执行。举个简单的例子，看下面这段代码：

int i =0;              

boolean flag =false;

i =1;              //语句1  

flag = true;         //语句2

　　上面代码定义了一个int型变量，定义了一个boolean类型变量，然后分别对两个变量进行赋值操作。从代码顺序上看，语句1是在语句2前面的，那么JVM在真正执行这段代码的时候会保证语句1一定会在语句2前面执行吗？不一定，为什么呢？这里可能会发生指令重排序（Instruction Reorder）。

　　下面解释一下什么是指令重排序，一般来说，处理器为了提高程序运行效率，可能会对输入代码进行优化，它不保证程序中各个语句的执行先后顺序同代码中的顺序一致，但是它会保证程序最终执行结果和代码顺序执行的结果是一致的。

　　比如上面的代码中，语句1和语句2谁先执行对最终的程序结果并没有影响，那么就有可能在执行过程中，语句2先执行而语句1后执行。

　　但是要注意，虽然处理器会对指令进行重排序，但是它会保证程序最终结果会和代码顺序执行结果相同，那么它靠什么保证的呢？再看下面一个例子：

int a =10;   //语句1

int r =2;  //语句2

a = a +3;   //语句3

r = a*a;   //语句4

　　这段代码有4个语句，那么可能的一个执行顺序是：

　　那么可不可能是这个执行顺序呢：语句2 语句1 语句4 语句3

　　不可能，因为处理器在进行重排序时是会考虑指令之间的数据依赖性，如果一个指令Instruction 2必须用到Instruction 1的结果，那么处理器会保证Instruction 1会在Instruction 2之前执行。

　　虽然重排序不会影响单个线程内程序执行的结果，但是多线程呢？下面看一个例子：

//线程1

context = loadContext();  //语句1

inited =true;          //语句2

//线程2

while(!inited ){

sleep()

}

doSomethingwithconfig(context);

上面代码中，由于语句1和语句2没有数据依赖性，因此可能会被重排序。假如发生了重排序，在线程1执行过程中先执行语句2，而此是线程2会以为初始化工作已经完成，那么就会跳出while循环，去执行doSomethingwithconfig(context)方法，而此时context并没有被初始化，就会导致程序出错。
从上面可以看出，指令重排序不会影响单个线程的执行，但是会影响到线程并发执行的正确性。也就是说，要想并发程序正确地执行，必须要保证原子性、可见性以及有序性。只要有一个没有被保证，就有可能会导致程序运行不正确。

三.Java内存模型

　　在前面谈到了一些关于内存模型以及并发编程中可能会出现的一些问题。下面我们来看一下Java内存模型，研究一下Java内存模型为我们提供了哪些保证以及在java中提供了哪些方法和机制来让我们在进行多线程编程时能够保证程序执行的正确性。

　　在Java虚拟机规范中试图定义一种Java内存模型（Java Memory Model，JMM）来屏蔽各个硬件平台和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果。那么Java内存模型规定了哪些东西呢，它定义了程序中变量的访问规则，往大一点说是定义了程序执行的次序。注意，为了获得较好的执行性能，Java内存模型并没有限制执行引擎使用处理器的寄存器或者高速缓存来提升指令执行速度，也没有限制编译器对指令进行重排序。也就是说，在java内存模型中，也会存在缓存一致性问题和指令重排序的问题。

　　Java内存模型规定所有的变量都是存在主存当中（类似于前面说的物理内存），每个线程都有自己的工作内存（类似于前面的高速缓存）。线程对变量的所有操作都必须在工作内存中进行，而不能直接对主存进行操作。并且每个线程不能访问其他线程的工作内存。

　　举个简单的例子：在java中，执行下面这个语句：

i  =10;

　　执行线程必须先在自己的工作线程中对变量i所在的缓存行进行赋值操作，然后再写入主存当中。而不是直接将数值10写入主存当中。

　　那么Java语言本身对原子性、可见性以及有序性提供了哪些保证呢？

1.原子性

　　在Java中，对基本数据类型的变量的读取和赋值操作是原子性操作，即这些操作是不可被中断的，要么执行，要么不执行。

　　上面一句话虽然看起来简单，但是理解起来并不是那么容易。看下面一个例子i：

　　请分析以下哪些操作是原子性操作：


x =10;     //语句1

y = x;       //语句2

x++;       //语句3

x = x +1;  //语句4

　　咋一看，有些朋友可能会说上面的4个语句中的操作都是原子性操作。其实只有语句1是原子性操作，其他三个语句都不是原子性操作。

　　语句1是直接将数值10赋值给x，也就是说线程执行这个语句的会直接将数值10写入到工作内存中。

　　语句2实际上包含2个操作，它先要去读取x的值，再将x的值写入工作内存，虽然读取x的值以及将x的值写入工作内存这2个操作都是原子性操作，但是合起来就不是原子性操作了。

　　同样的，x++和 x = x+1包括3个操作：读取x的值，进行加1操作，写入新的值。

　　所以上面4个语句只有语句1的操作具备原子性。

　　也就是说，只有简单的读取、赋值（而且必须是将数字赋值给某个变量，变量之间的相互赋值不是原子操作）才是原子操作。

　　不过这里有一点需要注意：在32位平台下，对64位数据的读取和赋值是需要通过两个操作来完成的，不能保证其原子性。但是好像在最新的JDK中，JVM已经保证对64位数据的读取和赋值也是原子性操作了。

　　从上面可以看出，Java内存模型只保证了基本读取和赋值是原子性操作，如果要实现更大范围操作的原子性，可以通过synchronized和Lock来实现。由于synchronized和Lock能够保证任一时刻只有一个线程执行该代码块，那么自然就不存在原子性问题了，从而保证了原子性。

2.可见性

　　对于可见性，Java提供了volatile关键字来保证可见性。

　　当一个共享变量被volatile修饰时，它会保证修改的值会立即被更新到主存，当有其他线程需要读取时，它会去内存中读取新值。

　　而普通的共享变量不能保证可见性，因为普通共享变量被修改之后，什么时候被写入主存是不确定的，当其他线程去读取时，此时内存中可能还是原来的旧值，因此无法保证可见性。

　　另外，通过synchronized和Lock也能够保证可见性，synchronized和Lock能保证同一时刻只有一个线程获取锁然后执行同步代码，并且在释放锁之前会将对变量的修改刷新到主存当中。因此可以保证可见性。

3.有序性

　　在Java内存模型中，允许编译器和处理器对指令进行重排序，但是重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性。

　　在Java里面，可以通过volatile关键字来保证一定的“有序性”（具体原理在下一节讲述）。另外可以通过synchronized和Lock来保证有序性，很显然，synchronized和Lock保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性。

　　另外，Java内存模型具备一些先天的“有序性”，即不需要通过任何手段就能够得到保证的有序性，这个通常也称为 happens-before 原则。如果两个操作的执行次序无法从happens-before原则推导出来，那么它们就不能保证它们的有序性，虚拟机可以随意地对它们进行重排序。

　　下面就来具体介绍下happens-before原则（先行发生原则）：

程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作
锁定规则：一个unLock操作先行发生于后面对同一个锁额lock操作
volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作
传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C
线程启动规则：Thread对象的start()方法先行发生于此线程的每个一个动作
线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生
线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行
对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始

　　这8条原则摘自《深入理解Java虚拟机》。

　　这8条规则中，前4条规则是比较重要的，后4条规则都是显而易见的。

　　下面我们来解释一下前4条规则：

　　对于程序次序规则来说，我的理解就是一段程序代码的执行在单个线程中看起来是有序的。注意，虽然这条规则中提到“书写在前面的操作先行发生于书写在后面的操作”，这个应该是程序看起来执行的顺序是按照代码顺序执行的，因为虚拟机可能会对程序代码进行指令重排序。虽然进行重排序，但是最终执行的结果是与程序顺序执行的结果一致的，它只会对不存在数据依赖性的指令进行重排序。因此，在单个线程中，程序执行看起来是有序执行的，这一点要注意理解。事实上，这个规则是用来保证程序在单线程中执行结果的正确性，但无法保证程序在多线程中执行的正确性。

　　第二条规则也比较容易理解，也就是说无论在单线程中还是多线程中，同一个锁如果出于被锁定的状态，那么必须先对锁进行了释放操作，后面才能继续进行lock操作。

　　第三条规则是一条比较重要的规则，也是后文将要重点讲述的内容。直观地解释就是，如果一个线程先去写一个变量，然后一个线程去进行读取，那么写入操作肯定会先行发生于读操作。

　　第四条规则实际上就是体现happens-before原则具备传递性。

四.深入剖析volatile关键字

　　在前面讲述了很多东西，其实都是为讲述volatile关键字作铺垫，那么接下来我们就进入主题。

1.volatile关键字的两层语义

　　一旦一个共享变量（类的成员变量、类的静态成员变量）被volatile修饰之后，那么就具备了两层语义：

　　1）保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。

　　2）禁止进行指令重排序。

　　先看一段代码，假如线程1先执行，线程2后执行：


//线程1

boolean stop =false;

while(!stop){

doSomething();

}

//线程2

stop =true;

　　这段代码是很典型的一段代码，很多人在中断线程时可能都会采用这种标记办法。但是事实上，这段代码会完全运行正确么？即一定会将线程中断么？不一定，也许在大多数时候，这个代码能够把线程中断，但是也有可能会导致无法中断线程（虽然这个可能性很小，但是只要一旦发生这种情况就会造成死循环了）。

　　下面解释一下这段代码为何有可能导致无法中断线程。在前面已经解释过，每个线程在运行过程中都有自己的工作内存，那么线程1在运行的时候，会将stop变量的值拷贝一份放在自己的工作内存当中。

　　那么当线程2更改了stop变量的值之后，但是还没来得及写入主存当中，线程2转去做其他事情了，那么线程1由于不知道线程2对stop变量的更改，因此还会一直循环下去。

　　但是用volatile修饰之后就变得不一样了：

　　第一：使用volatile关键字会强制将修改的值立即写入主存；

　　第二：使用volatile关键字的话，当线程2进行修改时，会导致线程1的工作内存中缓存变量stop的缓存行无效（反映到硬件层的话，就是CPU的L1或者L2缓存中对应的缓存行无效）；

　　第三：由于线程1的工作内存中缓存变量stop的缓存行无效，所以线程1再次读取变量stop的值时会去主存读取。

　　那么在线程2修改stop值时（当然这里包括2个操作，修改线程2工作内存中的值，然后将修改后的值写入内存），会使得线程1的工作内存中缓存变量stop的缓存行无效，然后线程1读取时，发现自己的缓存行无效，它会等待缓存行对应的主存地址被更新之后，然后去对应的主存读取最新的值。

　　那么线程1读取到的就是最新的正确的值。

2.volatile保证原子性吗？

　　从上面知道volatile关键字保证了操作的可见性，但是volatile能保证对变量的操作是原子性吗？

下面看一个例子：


public class Test {
 public volatile int inc = 0;
  
 public void increase() {
 inc++;
 }
  
 public static void main(String[] args) {
 final Test test = new Test();
 for(int i=0;i
 new Thread(){
 public void run() {
 for(int j=0;j
 test.increase();
 };
 }.start();
 }
  
 while(Thread.activeCount()>1)  //保证前面的线程都执行完
 Thread.yield();
 System.out.println(test.inc);
 }
}

　　大家想一下这段程序的输出结果是多少？也许有些朋友认为是10000。但是事实上运行它会发现每次运行结果都不一致，都是一个小于10000的数字。

　　可能有的朋友就会有疑问，不对啊，上面是对变量inc进行自增操作，由于volatile保证了可见性，那么在每个线程中对inc自增完之后，在其他线程中都能看到修改后的值啊，所以有10个线程分别进行了1000次操作，那么最终inc的值应该是1000*10=10000。

　　这里面就有一个误区了，volatile关键字能保证可见性没有错，但是上面的程序错在没能保证原子性。可见性只能保证每次读取的是最新的值，但是volatile没办法保证对变量的操作的原子性。

　　在前面已经提到过，自增操作是不具备原子性的，它包括读取变量的原始值、进行加1操作、写入工作内存。那么就是说自增操作的三个子操作可能会分割开执行，就有可能导致下面这种情况出现：

　　假如某个时刻变量inc的值为10，

　　线程1对变量进行自增操作，线程1先读取了变量inc的原始值，然后线程1被阻塞了；

　　然后线程2对变量进行自增操作，线程2也去读取变量inc的原始值，由于线程1只是对变量inc进行读取操作，而没有对变量进行修改操作，所以不会导致线程2的工作内存中缓存变量inc的缓存行无效，所以线程2会直接去主存读取inc的值，发现inc的值时10，然后进行加1操作，并把11写入工作内存，最后写入主存。

　　然后线程1接着进行加1操作，由于已经读取了inc的值，注意此时在线程1的工作内存中inc的值仍然为10，所以线程1对inc进行加1操作后inc的值为11，然后将11写入工作内存，最后写入主存。

　　那么两个线程分别进行了一次自增操作后，inc只增加了1。

　　解释到这里，可能有朋友会有疑问，不对啊，前面不是保证一个变量在修改volatile变量时，会让缓存行无效吗？然后其他线程去读就会读到新的值，对，这个没错。这个就是上面的happens-before规则中的volatile变量规则，但是要注意，线程1对变量进行读取操作之后，被阻塞了的话，并没有对inc值进行修改。然后虽然volatile能保证线程2对变量inc的值读取是从内存中读取的，但是线程1没有进行修改，所以线程2根本就不会看到修改的值。

　　根源就在这里，自增操作不是原子性操作，而且volatile也无法保证对变量的任何操作都是原子性的。

　　把上面的代码改成以下任何一种都可以达到效果：

　　采用synchronized：


public class Test { public  int inc = 0; public synchronized void increase() {
 inc++;
 } public static void main(String[] args) { final Test test = new Test(); for(int i=0;i){ new Thread(){ public void run() { for(int j=0;j)
 test.increase();
 };
 }.start();
 } while(Thread.activeCount()>1)  //保证前面的线程都执行完
 Thread.yield();
 System.out.println(test.inc);
 }
}

　　采用Lock：


public class Test { public  int inc = 0;
 Lock lock = new ReentrantLock(); 
 public  void increase() {
 lock.lock(); try {
 inc++;
 } finally{
 lock.unlock();
 }
 } public static void main(String[] args) { final Test test = new Test(); for(int i=0;i){ new Thread(){ public void run() { for(int j=0;j)
 test.increase();
 };
 }.start();
 } while(Thread.activeCount()>1)  //保证前面的线程都执行完
 Thread.yield();
 System.out.println(test.inc);
 }
}

　　采用AtomicInteger：

public class Test {
 public  AtomicInteger inc = new AtomicInteger();
  
 public  void increase() {
 inc.getAndIncrement();
 }
  
 public static void main(String[] args) {
 final Test test = new Test();
 for(int i=0;i10;i++){
 new Thread(){
 public void run() {
 for(int j=0;j1000;j++)
 test.increase();
 };
 }.start();
 }
  
 while(Thread.activeCount()>1)  //保证前面的线程都执行完
 Thread.yield();
 System.out.println(test.inc);
 }
}

　　在java 1.5的java.util.concurrent.atomic包下提供了一些原子操作类，即对基本数据类型的自增（加1操作），自减（减1操作）、以及加法操作（加一个数），减法操作（减一个数）进行了封装，保证这些操作是原子性操作。atomic是利用CAS来实现原子性操作的（Compare And Swap），CAS实际上是利用处理器提供的CMPXCHG指令实现的，而处理器执行CMPXCHG指令是一个原子性操作。

3.volatile能保证有序性吗？

　　在前面提到volatile关键字能禁止指令重排序，所以volatile能在一定程度上保证有序性。

　　volatile关键字禁止指令重排序有两层意思：

　　1）当程序执行到volatile变量的读操作或者写操作时，在其前面的操作的更改肯定全部已经进行，且结果已经对后面的操作可见；在其后面的操作肯定还没有进行；

　　2）在进行指令优化时，不能将在对volatile变量访问的语句放在其后面执行，也不能把volatile变量后面的语句放到其前面执行。

　　可能上面说的比较绕，举个简单的例子：


//x、y为非volatile变量
//flag为volatile变量
  
x = 2;        //语句1
y = 0;        //语句2
flag = true;  //语句3
x = 4;         //语句4
y = -1;       //语句5

　　由于flag变量为volatile变量，那么在进行指令重排序的过程的时候，不会将语句3放到语句1、语句2前面，也不会讲语句3放到语句4、语句5后面。但是要注意语句1和语句2的顺序、语句4和语句5的顺序是不作任何保证的。

　　并且volatile关键字能保证，执行到语句3时，语句1和语句2必定是执行完毕了的，且语句1和语句2的执行结果对语句3、语句4、语句5是可见的。

　　那么我们回到前面举的一个例子：

/线程1:
context = loadContext();   //语句1
inited = true;             //语句2
  
//线程2:
while(!inited ){
 sleep()
}
doSomethingwithconfig(context);

　　前面举这个例子的时候，提到有可能语句2会在语句1之前执行，那么久可能导致context还没被初始化，而线程2中就使用未初始化的context去进行操作，导致程序出错。

　　这里如果用volatile关键字对inited变量进行修饰，就不会出现这种问题了，因为当执行到语句2时，必定能保证context已经初始化完毕。

4.volatile的原理和实现机制

　　前面讲述了源于volatile关键字的一些使用，下面我们来探讨一下volatile到底如何保证可见性和禁止指令重排序的。

　　下面这段话摘自《深入理解Java虚拟机》：

　　“观察加入volatile关键字和没有加入volatile关键字时所生成的汇编代码发现，加入volatile关键字时，会多出一个lock前缀指令”

　　lock前缀指令实际上相当于一个内存屏障（也成内存栅栏），内存屏障会提供3个功能：

　　1）它确保指令重排序时不会把其后面的指令排到内存屏障之前的位置，也不会把前面的指令排到内存屏障的后面；即在执行到内存屏障这句指令时，在它前面的操作已经全部完成；

　　2）它会强制将对缓存的修改操作立即写入主存；

　　3）如果是写操作，它会导致其他CPU中对应的缓存行无效。

五.使用volatile关键字的场景

　　synchronized关键字是防止多个线程同时执行一段代码，那么就会很影响程序执行效率，而volatile关键字在某些情况下性能要优于synchronized，但是要注意volatile关键字是无法替代synchronized关键字的，因为volatile关键字无法保证操作的原子性。通常来说，使用volatile必须具备以下2个条件：

　　1）对变量的写操作不依赖于当前值

　　2）该变量没有包含在具有其他变量的不变式中

　　实际上，这些条件表明，可以被写入 volatile 变量的这些有效值独立于任何程序的状态，包括变量的当前状态。

　　事实上，我的理解就是上面的2个条件需要保证操作是原子性操作，才能保证使用volatile关键字的程序在并发时能够正确执行。

　　下面列举几个Java中使用volatile的几个场景。

1.状态标记量

volatile boolean flag = false;
  
while(!flag){
 doSomething();
}
  
public void setFlag() {
 flag = true;
}

volatile boolean inited = false;
//线程1:
context = loadContext(); 
inited = true; 
  
//线程2:
while(!inited ){
sleep()
}
doSomethingwithconfig(context);

2.double check

class Singleton{
 private volatile static Singleton instance = null; 
 private Singleton() { 
 }
  
 public static Singleton getInstance() {
 if(instance==null) {
 synchronized (Singleton.class) {
 if(instance==null)
 instance = new Singleton();
 }
 }
 return instance;
 }
}

　　至于为何需要这么写请参考：

　　《Java 中的双重检查（Double-Check）》http://blog.csdn.net/dl88250/article/details/5439024

　　和http://www.iteye.com/topic/652440

　　参考资料：

　　《Java编程思想》

　　《深入理解Java虚拟机》

　　http://jiangzhengjun.iteye.com/blog/652532

　　http://blog.sina.com.cn/s/blog_7bee8dd50101fu8n.html

　　http://ifeve.com/volatile/

　　http://blog.csdn.net/ccit0519/article/details/11241403

　　http://blog.csdn.net/ns_code/article/details/17101369

　　http://www.cnblogs.com/kevinwu/archive/2012/05/02/2479464.html

　　http://www.cppblog.com/elva/archive/2011/01/21/139019.html

　　http://ifeve.com/volatile-array-visiblity/

　　http://www.bdqn.cn/news/201312/12579.shtml

　　http://exploer.blog.51cto.com/7123589/1193399

　　http://www.cnblogs.com/Mainz/p/3556430.html

深入分析synchronized

2018-04-05T15:28:06.000Z

记得刚刚开始学习Java的时候，一遇到多线程情况就是synchronized，相对于当时的我们来说synchronized是这么的神奇而又强大，那个时候我们赋予它一个名字“同步”，也成为了我们解决多线程情况的百试不爽的良药。但是，随着我们学习的进行我们知道synchronized是一个重量级锁，相对于Lock，它会显得那么笨重，以至于我们认为它不是那么的高效而慢慢摒弃它。
诚然，随着Javs SE 1.6对synchronized进行的各种优化后，synchronized并不会显得那么重了。下面跟随LZ一起来探索synchronized的实现机制、Java是如何对它进行了优化、锁优化机制、锁的存储结构和升级过程；

实现原理

synchronized可以保证方法或者代码块在运行时，同一时刻只有一个方法可以进入到临界区，同时它还可以保证共享变量的内存可见性

Java中每一个对象都可以作为锁，这是synchronized实现同步的基础：

普通同步方法，锁是当前实例对象
静态同步方法，锁是当前类的class对象
同步方法块，锁是括号里面的对象
当一个线程访问同步代码块时，它首先是需要得到锁才能执行同步代码，当退出或者抛出异常时必须要释放锁，那么它是如何来实现这个机制的呢？我们先看一段简单的代码：


public class SynchronizedTest {
 public synchronized void test1(){

 }

 public void test2(){
 synchronized (this){

 }
 }
}

利用javap工具查看生成的class文件信息来分析Synchronize的实现

从上面可以看出，同步代码块是使用monitorenter和monitorexit指令实现的，同步方法（在这看不出来需要看JVM底层实现）依靠的是方法修饰符上的ACC_SYNCHRONIZED实现。
同步代码块：monitorenter指令插入到同步代码块的开始位置，monitorexit指令插入到同步代码块的结束位置，JVM需要保证每一个monitorenter都有一个monitorexit与之相对应。任何对象都有一个monitor与之相关联，当且一个monitor被持有之后，他将处于锁定状态。线程执行到monitorenter指令时，将会尝试获取对象所对应的monitor所有权，即尝试获取对象的锁；
同步方法：synchronized方法则会被翻译成普通的方法调用和返回指令如:invokevirtual、areturn指令，在VM字节码层面并没有任何特别的指令来实现被synchronized修饰的方法，而是在Class文件的方法表中将该方法的access_flags字段中的synchronized标志位置1，表示该方法是同步方法并使用调用该方法的对象或该方法所属的Class在JVM的内部对象表示Klass做为锁对象。(摘自：http://www.cnblogs.com/javaminer/p/3889023.html)

下面我们来继续分析，但是在深入之前我们需要了解两个重要的概念：Java对象头，Monitor。

Java对象头、monitor

Java对象头和monitor是实现synchronized的基础！下面就这两个概念来做详细介绍。

Java对象头
synchronized用的锁是存在Java对象头里的，那么什么是Java对象头呢？Hotspot虚拟机的对象头主要包括两部分数据：Mark Word（标记字段）、Klass Pointer（类型指针）。其中Klass Point是是对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例，Mark Word用于存储对象自身的运行时数据，它是实现轻量级锁和偏向锁的关键，所以下面将重点阐述
Mark Word。
Mark Word用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等等。Java对象头一般占有两个机器码（在32位虚拟机中，1个机器码等于4字节，也就是32bit），但是如果对象是数组类型，则需要三个机器码，因为JVM虚拟机可以通过Java对象的元数据信息确定Java对象的大小，但是无法从数组的元数据来确认数组的大小，所以用一块来记录数组长度。下图是Java对象头的存储结构（32位虚拟机）：

对象头信息是与对象自身定义的数据无关的额外存储成本，但是考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据，它会根据对象的状态复用自己的存储空间，也就是说，Mark Word会随着程序的运行发生变化，变化状态如下（32位虚拟机）：

简单介绍了Java对象头，我们下面再看Monitor。

Monitor

什么是Monitor？我们可以把它理解为一个同步工具，也可以描述为一种同步机制，它通常被描述为一个对象。
与一切皆对象一样，所有的Java对象是天生的Monitor，每一个Java对象都有成为Monitor的潜质，因为在Java的设计中，每一个Java对象自打娘胎里出来就带了一把看不见的锁，它叫做内部锁或者Monitor锁。
Monitor 是线程私有的数据结构，每一个线程都有一个可用monitor record列表，同时还有一个全局的可用列表。每一个被锁住的对象都会和一个monitor关联（对象头的MarkWord中的LockWord指向monitor的起始地址），同时monitor中有一个Owner字段存放拥有该锁的线程的唯一标识，表示该锁被这个线程占用。其结构如下：

Owner：初始时为NULL表示当前没有任何线程拥有该monitor record，当线程成功拥有该锁后保存线程唯一标识，当锁被释放时又设置为NULL；
EntryQ:关联一个系统互斥锁（semaphore），阻塞所有试图锁住monitor record失败的线程。
RcThis:表示blocked或waiting在该monitor record上的所有线程的个数。
Nest:用来实现重入锁的计数。
HashCode:保存从对象头拷贝过来的HashCode值（可能还包含GC age）。
Candidate:用来避免不必要的阻塞或等待线程唤醒，因为每一次只有一个线程能够成功拥有锁，如果每次前一个释放锁的线程唤醒所有正在阻塞或等待的线程，会引起不必要的上下文切换（从阻塞到就绪然后因为竞争锁失败又被阻塞）从而导致性能严重下降。Candidate只有两种可能的值0表示没有需要唤醒的线程1表示要唤醒一个继任线程来竞争锁。
摘自：Java中synchronized的实现原理与应用
我们知道synchronized是重量级锁，效率不怎么滴，同时这个观念也一直存在我们脑海里，不过在jdk 1.6中对synchronize的实现进行了各种优化，使得它显得不是那么重了，那么JVM采用了那些优化手段呢？

锁优化

jdk1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。
锁主要存在四中状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。

自旋锁
线程的阻塞和唤醒需要CPU从用户态转为核心态，频繁的阻塞和唤醒对CPU来说是一件负担很重的工作，势必会给系统的并发性能带来很大的压力。同时我们发现在许多应用上面，对象锁的锁状态只会持续很短一段时间，为了这一段很短的时间频繁地阻塞和唤醒线程是非常不值得的。所以引入自旋锁。
何谓自旋锁？
所谓自旋锁，就是让该线程等待一段时间，不会被立即挂起，看持有锁的线程是否会很快释放锁。怎么等待呢？执行一段无意义的循环即可（自旋）。
自旋等待不能替代阻塞，先不说对处理器数量的要求（多核，貌似现在没有单核的处理器了），虽然它可以避免线程切换带来的开销，但是它占用了处理器的时间。如果持有锁的线程很快就释放了锁，那么自旋的效率就非常好，反之，自旋的线程就会白白消耗掉处理的资源，它不会做任何有意义的工作，典型的占着茅坑不拉屎，这样反而会带来性能上的浪费。所以说，自旋等待的时间（自旋的次数）必须要有一个限度，如果自旋超过了定义的时间仍然没有获取到锁，则应该被挂起。
自旋锁在JDK 1.4.2中引入，默认关闭，但是可以使用-XX:+UseSpinning开开启，在JDK1.6中默认开启。同时自旋的默认次数为10次，可以通过参数-XX:PreBlockSpin来调整；
如果通过参数-XX:preBlockSpin来调整自旋锁的自旋次数，会带来诸多不便。假如我将参数调整为10，但是系统很多线程都是等你刚刚退出的时候就释放了锁（假如你多自旋一两次就可以获取锁），你是不是很尴尬。于是JDK1.6引入自适应的自旋锁，让虚拟机会变得越来越聪明。

适应自旋锁
JDK 1.6引入了更加聪明的自旋锁，即自适应自旋锁。所谓自适应就意味着自旋的次数不再是固定的，它是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。它怎么做呢？线程如果自旋成功了，那么下次自旋的次数会更加多，因为虚拟机认为既然上次成功了，那么此次自旋也很有可能会再次成功，那么它就会允许自旋等待持续的次数更多。反之，如果对于某个锁，很少有自旋能够成功的，那么在以后要或者这个锁的时候自旋的次数会减少甚至省略掉自旋过程，以免浪费处理器资源。
有了自适应自旋锁，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测会越来越准确，虚拟机会变得越来越聪明。

锁消除
为了保证数据的完整性，我们在进行操作时需要对这部分操作进行同步控制，但是在有些情况下，JVM检测到不可能存在共享数据竞争，这是JVM会对这些同步锁进行锁消除。锁消除的依据是逃逸分析的数据支持。
如果不存在竞争，为什么还需要加锁呢？所以锁消除可以节省毫无意义的请求锁的时间。变量是否逃逸，对于虚拟机来说需要使用数据流分析来确定，但是对于我们程序员来说这还不清楚么？我们会在明明知道不存在数据竞争的代码块前加上同步吗？但是有时候程序并不是我们所想的那样？我们虽然没有显示使用锁，但是我们在使用一些JDK的内置API时，如StringBuffer、Vector、HashTable等，这个时候会存在隐形的加锁操作。比如StringBuffer的append()方法，Vector的add()方法：

public void vectorTest(){
 Vector vector = new Vector();
 for(int i = 0 ; i 
 vector.add(i + "");
 }

 System.out.println(vector);
 }

在运行这段代码时，JVM可以明显检测到变量vector没有逃逸出方法vectorTest()之外，所以JVM可以大胆地将vector内部的加锁操作消除。

锁粗化
我们知道在使用同步锁的时候，需要让同步块的作用范围尽可能小—仅在共享数据的实际作用域中才进行同步，这样做的目的是为了使需要同步的操作数量尽可能缩小，如果存在锁竞争，那么等待锁的线程也能尽快拿到锁。
在大多数的情况下，上述观点是正确的，LZ也一直坚持着这个观点。但是如果一系列的连续加锁解锁操作，可能会导致不必要的性能损耗，所以引入锁粗话的概念。
锁粗话概念比较好理解，就是将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁。如上面实例：vector每次add的时候都需要加锁操作，JVM检测到对同一个对象（vector）连续加锁、解锁操作，会合并一个更大范围的加锁、解锁操作，即加锁解锁操作会移到for循环之外。

轻量级锁
引入轻量级锁的主要目的是在多没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。当关闭偏向锁功能或者多个线程竞争偏向锁导致偏向锁升级为轻量级锁，则会尝试获取轻量级锁，其步骤如下：

获取锁

1) 判断当前对象是否处于无锁状态（hashcode、0、01），若是，则JVM首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝（官方把这份拷贝加了一个Displaced前缀，即Displaced Mark Word）；否则执行步骤（3）；
2) JVM利用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指正，如果成功表示竞争到锁，则将锁标志位变成00（表示此对象处于轻量级锁状态），执行同步操作；如果失败则执行步骤（3）；
3) 判断当前对象的Mark Word是否指向当前线程的栈帧，如果是则表示当前线程已经持有当前对象的锁，则直接执行同步代码块；否则只能说明该锁对象已经被其他线程抢占了，这时轻量级锁需要膨胀为重量级锁，锁标志位变成10，后面等待的线程将会进入阻塞状态；

释放锁
轻量级锁的释放也是通过CAS操作来进行的，主要步骤如下：

1）取出在获取轻量级锁保存在Displaced Mark Word中的数据；
2）用CAS操作将取出的数据替换当前对象的Mark Word中，如果成功，则说明释放锁成功，否则执行（3）；
3）如果CAS操作替换失败，说明有其他线程尝试获取该锁，则需要在释放锁的同时需要唤醒被挂起的线程。
对于轻量级锁，其性能提升的依据是“对于绝大部分的锁，在整个生命周期内都是不会存在竞争的”，如果打破这个依据则除了互斥的开销外，还有额外的CAS操作，因此在有多线程竞争的情况下，轻量级锁比重量级锁更慢；

下图是轻量级锁的获取和释放过程

偏向锁
引入偏向锁主要目的是：为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径。上面提到了轻量级锁的加锁解锁操作是需要依赖多次CAS原子指令的。那么偏向锁是如何来减少不必要的CAS操作呢？我们可以查看Mark work的结构就明白了。只需要检查是否为偏向锁、锁标识为以及ThreadID即可，处理流程如下：
获取锁

检测Mark Word是否为可偏向状态，即是否为偏向锁1，锁标识位为01；
若为可偏向状态，则测试线程ID是否为当前线程ID，如果是，则执行步骤（5），否则执行步骤（3）；
如果线程ID不为当前线程ID，则通过CAS操作竞争锁，竞争成功，则将Mark Word的线程ID替换为当前线程ID，否则执行线程（4）；
通过CAS竞争锁失败，证明当前存在多线程竞争情况，当到达全局安全点，获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码块；
执行同步代码块

释放锁
偏向锁的释放采用了一种只有竞争才会释放锁的机制，线程是不会主动去释放偏向锁，需要等待其他线程来竞争。偏向锁的撤销需要等待全局安全点（这个时间点是上没有正在执行的代码）。其步骤如下：

暂停拥有偏向锁的线程，判断锁对象石是否还处于被锁定状态；
撤销偏向苏，恢复到无锁状态（01）或者轻量级锁的状态；
下图是偏向锁的获取和释放流程

重量级锁
重量级锁通过对象内部的监视器（monitor）实现，其中monitor的本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之间的切换需要从用户态到内核态的切换，切换成本非常高。

Kafka设计解析（八）- Kafka Exactly Once语义与事务机制原理

2018-04-04T13:46:54.000Z

本文介绍了Kafka实现事务性的几个阶段——正好一次语义与原子操作。之后详细分析了Kafka事务机制的实现原理，并介绍了Kafka如何处理事务相关的异常情况，如Transaction Coordinator宕机。最后介绍了Kafka的事务机制与PostgreSQL的MVCC以及Zookeeper的原子广播实现事务的异同

写在前面的话

本文所有Kafka原理性的描述除特殊说明外均基于Kafka 1.0.0版本。

为什么要提供事务机制

Kafka事务机制的实现主要是为了支持

Exactly Once即正好一次语义
操作的原子性
有状态操作的可恢复性

Exactly Once

《Kafka背景及架构介绍》一文中有说明Kafka在0.11.0.0之前的版本中只支持At Least Once和At Most Once语义，尚不支持Exactly Once语义。

但是在很多要求严格的场景下，如使用Kafka处理交易数据，Exactly Once语义是必须的。我们可以通过让下游系统具有幂等性来配合Kafka的At Least Once语义来间接实现Exactly Once。但是：

该方案要求下游系统支持幂等操作，限制了Kafka的适用场景
实现门槛相对较高，需要用户对Kafka的工作机制非常了解
对于Kafka Stream而言，Kafka本身即是自己的下游系统，但Kafka在0.11.0.0版本之前不具有幂等发送能力

因此，Kafka本身对Exactly Once语义的支持就非常必要。

操作原子性

操作的原子性是指，多个操作要么全部成功要么全部失败，不存在部分成功部分失败的可能。

实现原子性操作的意义在于：

操作结果更可控，有助于提升数据一致性
便于故障恢复。因为操作是原子的，从故障中恢复时只需要重试该操作（如果原操作失败）或者直接跳过该操作（如果原操作成功），而不需要记录中间状态，更不需要针对中间状态作特殊处理

实现事务机制的几个阶段

幂等性发送

上文提到，实现Exactly Once的一种方法是让下游系统具有幂等处理特性，而在Kafka Stream中，Kafka Producer本身就是“下游”系统，因此如果能让Producer具有幂等处理特性，那就可以让Kafka Stream在一定程度上支持Exactly once语义。

为了实现Producer的幂等语义，Kafka引入了Producer ID（即PID）和Sequence Number。每个新的Producer在初始化的时候会被分配一个唯一的PID，该PID对用户完全透明而不会暴露给用户。

对于每个PID，该Producer发送数据的每个都对应一个从0开始单调递增的Sequence Number。

类似地，Broker端也会为每个维护一个序号，并且每次Commit一条消息时将其对应序号递增。对于接收的每条消息，如果其序号比Broker维护的序号（即最后一次Commit的消息的序号）大一，则Broker会接受它，否则将其丢弃：

如果消息序号比Broker维护的序号大一以上，说明中间有数据尚未写入，也即乱序，此时Broker拒绝该消息，Producer抛出InvalidSequenceNumber
如果消息序号小于等于Broker维护的序号，说明该消息已被保存，即为重复消息，Broker直接丢弃该消息，Producer抛出DuplicateSequenceNumber

上述设计解决了0.11.0.0之前版本中的两个问题：

Broker保存消息后，发送ACK前宕机，Producer认为消息未发送成功并重试，造成数据重复
前一条消息发送失败，后一条消息发送成功，前一条消息重试后成功，造成数据乱序

事务性保证

上述幂等设计只能保证单个Producer对于同一个的Exactly Once语义。

另外，它并不能保证写操作的原子性——即多个写操作，要么全部被Commit要么全部不被Commit。

更不能保证多个读写操作的的原子性。尤其对于Kafka Stream应用而言，典型的操作即是从某个Topic消费数据，经过一系列转换后写回另一个Topic，保证从源Topic的读取与向目标Topic的写入的原子性有助于从故障中恢复。

事务保证可使得应用程序将生产数据和消费数据当作一个原子单元来处理，要么全部成功，要么全部失败，即使该生产或消费跨多个。

另外，有状态的应用也可以保证重启后从断点处继续处理，也即事务恢复。

为了实现这种效果，应用程序必须提供一个稳定的（重启后不变）唯一的ID，也即Transaction ID。Transactin ID与PID可能一一对应。区别在于Transaction ID由用户提供，而PID是内部的实现对用户透明。

另外，为了保证新的Producer启动后，旧的具有相同Transaction ID的Producer即失效，每次Producer通过Transaction ID拿到PID的同时，还会获取一个单调递增的epoch。由于旧的Producer的epoch比新Producer的epoch小，Kafka可以很容易识别出该Producer是老的Producer并拒绝其请求。

有了Transaction ID后，Kafka可保证：

跨Session的数据幂等发送。当具有相同Transaction ID的新的Producer实例被创建且工作时，旧的且拥有相同Transaction ID的Producer将不再工作。
跨Session的事务恢复。如果某个应用实例宕机，新的实例可以保证任何未完成的旧的事务要么Commit要么Abort，使得新实例从一个正常状态开始工作。

需要注意的是，上述的事务保证是从Producer的角度去考虑的。从Consumer的角度来看，该保证会相对弱一些。尤其是不能保证所有被某事务Commit过的所有消息都被一起消费，因为：

对于压缩的Topic而言，同一事务的某些消息可能被其它版本覆盖
事务包含的消息可能分布在多个Segment中（即使在同一个Partition内），当老的Segment被删除时，该事务的部分数据可能会丢失
Consumer在一个事务内可能通过seek方法访问任意Offset的消息，从而可能丢失部分消息
Consumer可能并不需要消费某一事务内的所有Partition，因此它将永远不会读取组成该事务的所有消息

事务机制原理

事务性消息传递

这一节所说的事务主要指原子性，也即Producer将多条消息作为一个事务批量发送，要么全部成功要么全部失败。

为了实现这一点，Kafka 0.11.0.0引入了一个服务器端的模块，名为Transaction Coordinator，用于管理Producer发送的消息的事务性。

该Transaction Coordinator维护Transaction Log，该log存于一个内部的Topic内。由于Topic数据具有持久性，因此事务的状态也具有持久性。

Producer并不直接读写Transaction Log，它与Transaction Coordinator通信，然后由Transaction Coordinator将该事务的状态插入相应的Transaction Log。

Transaction Log的设计与Offset Log用于保存Consumer的Offset类似。

事务中Offset的提交

许多基于Kafka的应用，尤其是Kafka Stream应用中同时包含Consumer和Producer，前者负责从Kafka中获取消息，后者负责将处理完的数据写回Kafka的其它Topic中。

为了实现该场景下的事务的原子性，Kafka需要保证对Consumer Offset的Commit与Producer对发送消息的Commit包含在同一个事务中。否则，如果在二者Commit中间发生异常，根据二者Commit的顺序可能会造成数据丢失和数据重复：

如果先Commit Producer发送数据的事务再Commit Consumer的Offset，即At Least Once语义，可能造成数据重复。
如果先Commit Consumer的Offset，再Commit Producer数据发送事务，即At Most Once语义，可能造成数据丢失。

用于事务特性的控制型消息

为了区分写入Partition的消息被Commit还是Abort，Kafka引入了一种特殊类型的消息，即Control Message。该类消息的Value内不包含任何应用相关的数据，并且不会暴露给应用程序。它只用于Broker与Client间的内部通信。

对于Producer端事务，Kafka以Control Message的形式引入一系列的Transaction Marker。Consumer即可通过该标记判定对应的消息被Commit了还是Abort了，然后结合该Consumer配置的隔离级别决定是否应该将该消息返回给应用程序。

事务处理样例代码

Producer producer = new KafkaProducer(props);

// 初始化事务，包括结束该Transaction ID对应的未完成的事务（如果有）

// 保证新的事务在一个正确的状态下启动

producer.initTransactions();

// 开始事务

producer.beginTransaction();

// 消费数据

ConsumerRecords records = consumer.poll(100);

try{

 // 发送数据

 producer.send(new ProducerRecord("Topic", "Key", "Value"));

 // 发送消费数据的Offset，将上述数据消费与数据发送纳入同一个Transaction内

 producer.sendOffsetsToTransaction(offsets, "group1");

 // 数据发送及Offset发送均成功的情况下，提交事务

 producer.commitTransaction();

} catch (ProducerFencedException | OutOfOrderSequenceException | AuthorizationException e) {

 // 数据发送或者Offset发送出现异常时，终止事务

 producer.abortTransaction();

} finally {

 // 关闭Producer和Consumer

 producer.close();

 consumer.close();

}

完整事务过程

找到Transaction Coordinator

由于Transaction Coordinator是分配PID和管理事务的核心，因此Producer要做的第一件事情就是通过向任意一个Broker发送FindCoordinator请求找到Transaction Coordinator的位置。

注意：只有应用程序为Producer配置了Transaction ID时才可使用事务特性，也才需要这一步。另外，由于事务性要求Producer开启幂等特性，因此通过将transactional.id设置为非空从而开启事务特性的同时也需要通过将enable.idempotence设置为true来开启幂等特性。

获取PID

找到Transaction Coordinator后，具有幂等特性的Producer必须发起InitPidRequest请求以获取PID。

注意：只要开启了幂等特性即必须执行该操作，而无须考虑该Producer是否开启了事务特性。

如果事务特性被开启
InitPidRequest会发送给Transaction Coordinator。如果Transaction Coordinator是第一次收到包含有该Transaction ID的InitPidRequest请求，它将会把该存入Transaction Log，如上图中步骤2.1所示。这样可保证该对应关系被持久化，从而保证即使Transaction Coordinator宕机该对应关系也不会丢失。

除了返回PID外，InitPidRequest还会执行如下任务：

增加该PID对应的epoch。具有相同PID但epoch小于该epoch的其它Producer（如果有）新开启的事务将被拒绝。
恢复（Commit或Abort）之前的Producer未完成的事务（如果有）。

注意：InitPidRequest的处理过程是同步阻塞的。一旦该调用正确返回，Producer即可开始新的事务。

另外，如果事务特性未开启，InitPidRequest可发送至任意Broker，并且会得到一个全新的唯一的PID。该Producer将只能使用幂等特性以及单一Session内的事务特性，而不能使用跨Session的事务特性。

开启事务

Kafka从0.11.0.0版本开始，提供beginTransaction()方法用于开启一个事务。调用该方法后，Producer本地会记录已经开启了事务，但Transaction Coordinator只有在Producer发送第一条消息后才认为事务已经开启。

Consume-Transform-Produce

这一阶段，包含了整个事务的数据处理过程，并且包含了多种请求。

AddPartitionsToTxnRequest
一个Producer可能会给多个发送数据，给一个新的发送数据前，它需要先向Transaction Coordinator发送AddPartitionsToTxnRequest。

Transaction Coordinator会将该存于Transaction Log内，并将其状态置为BEGIN，如上图中步骤4.1所示。有了该信息后，我们才可以在后续步骤中为每个Topic, Partition>设置COMMIT或者ABORT标记（如上图中步骤5.2所示）。

另外，如果该为该事务中第一个，Transaction Coordinator还会启动对该事务的计时（每个事务都有自己的超时时间）。

ProduceRequest
Producer通过一个或多个ProduceRequest发送一系列消息。除了应用数据外，该请求还包含了PID，epoch，和Sequence Number。该过程如上图中步骤4.2所示。

AddOffsetsToTxnRequest
为了提供事务性，Producer新增了sendOffsetsToTransaction方法，该方法将多组消息的发送和消费放入同一批处理内。

该方法先判断在当前事务中该方法是否已经被调用并传入了相同的Group ID。若是，直接跳到下一步；若不是，则向Transaction Coordinator发送AddOffsetsToTxnRequests请求，Transaction Coordinator将对应的所有存于Transaction Log中，并将其状态记为BEGIN，如上图中步骤4.3所示。该方法会阻塞直到收到响应。

TxnOffsetCommitRequest
作为sendOffsetsToTransaction方法的一部分，在处理完AddOffsetsToTxnRequest后，Producer也会发送TxnOffsetCommit请求给Consumer Coordinator从而将本事务包含的与读操作相关的各的Offset持久化到内部的__consumer_offsets中，如上图步骤4.4所示。

在此过程中，Consumer Coordinator会通过PID和对应的epoch来验证是否应该允许该Producer的该请求。

这里需要注意：

写入__consumer_offsets的Offset信息在当前事务Commit前对外是不可见的。也即在当前事务被Commit前，可认为该Offset尚未Commit，也即对应的消息尚未被完成处理。
Consumer Coordinator并不会立即更新缓存中相应的Offset，因为此时这些更新操作尚未被COMMIT或ABORT。

Commit或Abort事务

一旦上述数据写入操作完成，应用程序必须调用KafkaProducer的commitTransaction方法或者abortTransaction方法以结束当前事务。

EndTxnRequest
commitTransaction方法使得Producer写入的数据对下游Consumer可见。abortTransaction方法通过Transaction Marker将Producer写入的数据标记为Aborted状态。下游的Consumer如果将isolation.level设置为READ_COMMITTED，则它读到被Abort的消息后直接将其丢弃而不会返回给客户程序，也即被Abort的消息对应用程序不可见。

无论是Commit还是Abort，Producer都会发送EndTxnRequest请求给Transaction Coordinator，并通过标志位标识是应该Commit还是Abort。

收到该请求后，Transaction Coordinator会进行如下操作

将PREPARE_COMMIT或PREPARE_ABORT消息写入Transaction Log，如上图中步骤5.1所示
通过WriteTxnMarker请求以Transaction Marker的形式将COMMIT或ABORT信息写入用户数据日志以及Offset Log中，如上图中步骤5.2所示
最后将COMPLETE_COMMIT或COMPLETE_ABORT信息写入Transaction Log中，如上图中步骤5.3所示

补充说明：对于commitTransaction方法，它会在发送EndTxnRequest之前先调用flush方法以确保所有发送出去的数据都得到相应的ACK。对于abortTransaction方法，在发送EndTxnRequest之前直接将当前Buffer中的事务性消息（如果有）全部丢弃，但必须等待所有被发送但尚未收到ACK的消息发送完成。

上述第二步是实现将一组读操作与写操作作为一个事务处理的关键。因为Producer写入的数据Topic以及记录Comsumer Offset的Topic会被写入相同的Transactin Marker，所以这一组读操作与写操作要么全部COMMIT要么全部ABORT。

WriteTxnMarkerRequest
上面提到的WriteTxnMarkerRequest由Transaction Coordinator发送给当前事务涉及到的每个的Leader。收到该请求后，对应的Leader会将对应的COMMIT(PID)或者ABORT(PID)控制信息写入日志，如上图中步骤5.2所示。

该控制消息向Broker以及Consumer表明对应PID的消息被Commit了还是被Abort了。

这里要注意，如果事务也涉及到__consumer_offsets，即该事务中有消费数据的操作且将该消费的Offset存于__consumer_offsets中，Transaction Coordinator也需要向该内部Topic的各Partition的Leader发送WriteTxnMarkerRequest从而写入COMMIT(PID)或COMMIT(PID)控制信息。

写入最终的COMPLETE_COMMIT或COMPLETE_ABORT消息
写完所有的Transaction Marker后，Transaction Coordinator会将最终的COMPLETE_COMMIT或COMPLETE_ABORT消息写入Transaction Log中以标明该事务结束，如上图中步骤5.3所示。

此时，Transaction Log中所有关于该事务的消息全部可以移除。当然，由于Kafka内数据是Append Only的，不可直接更新和删除，这里说的移除只是将其标记为null从而在Log Compact时不再保留。

另外，COMPLETE_COMMIT或COMPLETE_ABORT的写入并不需要得到所有Rreplica的ACK，因为如果该消息丢失，可以根据事务协议重发。

补充说明，如果参与该事务的某些在被写入Transaction Marker前不可用，它对READ_COMMITTED的Consumer不可见，但不影响其它可用的COMMIT或ABORT。在该恢复可用后，Transaction Coordinator会重新根据PREPARE_COMMIT或PREPARE_ABORT向该发送Transaction Marker。

总结

PID与Sequence Number的引入实现了写操作的幂等性
写操作的幂等性结合At Least Once语义实现了单一Session内的Exactly Once语义
Transaction Marker与PID提供了识别消息是否应该被读取的能力，从而实现了事务的隔离性
Offset的更新标记了消息是否被读取，从而将对读操作的事务处理转换成了对写（Offset）操作的事务处理
Kafka事务的本质是，将一组写操作（如果有）对应的消息与一组读操作（如果有）对应的Offset的更新进行同样的标记（即Transaction Marker）来实现事务中涉及的所有读写操作同时对外可见或同时对外不可见
Kafka只提供对Kafka本身的读写操作的事务性，不提供包含外部系统的事务性

异常处理

Exception处理

InvalidProducerEpoch
这是一种Fatal Error，它说明当前Producer是一个过期的实例，有Transaction ID相同但epoch更新的Producer实例被创建并使用。此时Producer会停止并抛出Exception。

InvalidPidMapping
Transaction Coordinator没有与该Transaction ID对应的PID。此时Producer会通过包含有Transaction ID的InitPidRequest请求创建一个新的PID。

NotCorrdinatorForGTransactionalId
该Transaction Coordinator不负责该当前事务。Producer会通过FindCoordinatorRequest请求重新寻找对应的Transaction Coordinator。

InvalidTxnRequest
违反了事务协议。正确的Client实现不应该出现这种Exception。如果该异常发生了，用户需要检查自己的客户端实现是否有问题。

CoordinatorNotAvailable
Transaction Coordinator仍在初始化中。Producer只需要重试即可。

DuplicateSequenceNumber
发送的消息的序号低于Broker预期。该异常说明该消息已经被成功处理过，Producer可以直接忽略该异常并处理下一条消息

InvalidSequenceNumber
这是一个Fatal Error，它说明发送的消息中的序号大于Broker预期。此时有两种可能

数据乱序。比如前面的消息发送失败后重试期间，新的消息被接收。正常情况下不应该出现该问题，因为当幂等发送启用时，max.inflight.requests.per.connection被强制设置为1，而acks被强制设置为all。故前面消息重试期间，后续消息不会被发送，也即不会发生乱序。并且只有ISR中所有Replica都ACK，Producer才会认为消息已经被发送，也即不存在Broker端数据丢失问题。
服务器由于日志被Truncate而造成数据丢失。此时应该停止Producer并将此Fatal Error报告给用户。

InvalidTransactionTimeout
InitPidRequest调用出现的Fatal Error。它表明Producer传入的timeout时间不在可接受范围内，应该停止Producer并报告给用户。

处理`Transaction Coordinator`失败

写`PREPARE_COMMIT/PREPARE_ABORT`前失败

Producer通过FindCoordinatorRequest找到新的Transaction Coordinator，并通过EndTxnRequest请求发起COMMIT或ABORT流程，新的Transaction Coordinator继续处理EndTxnRequest请求——写PREPARE_COMMIT或PREPARE_ABORT，写Transaction Marker，写COMPLETE_COMMIT或COMPLETE_ABORT。

写完`PREPARE_COMMIT/PREPARE_ABORT`后失败

此时旧的Transaction Coordinator可能已经成功写入部分Transaction Marker。新的Transaction Coordinator会重复这些操作，所以部分Partition中可能会存在重复的COMMIT或ABORT，但只要该Producer在此期间没有发起新的事务，这些重复的Transaction Marker就不是问题。

写完`COMPLETE_COMMIT/ABORT`后失败

旧的Transaction Coordinator可能已经写完了COMPLETE_COMMIT或COMPLETE_ABORT但在返回EndTxnRequest之前失败。该场景下，新的Transaction Coordinator会直接给Producer返回成功。

事务过期机制

事务超时

transaction.timeout.ms

终止过期事务

当Producer失败时，Transaction Coordinator必须能够主动的让某些进行中的事务过期。否则没有Producer的参与，Transaction Coordinator无法判断这些事务应该如何处理，这会造成：

如果这种进行中事务太多，会造成Transaction Coordinator需要维护大量的事务状态，大量占用内存
Transaction Log内也会存在大量数据，造成新的Transaction Coordinator启动缓慢
READ_COMMITTED的Consumer需要缓存大量的消息，造成不必要的内存浪费甚至是OOM
如果多个Transaction ID不同的Producer交叉写同一个Partition，当一个Producer的事务状态不更新时，READ_COMMITTED的Consumer为了保证顺序消费而被阻塞

为了避免上述问题，Transaction Coordinator会周期性遍历内存中的事务状态Map，并执行如下操作

如果状态是BEGIN并且其最后更新时间与当前时间差大于transaction.remove.expired.transaction.cleanup.interval.ms（默认值为1小时），则主动将其终止：1）未避免原Producer临时恢复与当前终止流程冲突，增加该Producer对应的PID的epoch，并确保将该更新的信息写入Transaction Log；2）以更新后的epoch回滚事务，从而使得该事务相关的所有Broker都更新其缓存的该PID的epoch从而拒绝旧Producer的写操作
如果状态是PREPARE_COMMIT，完成后续的COMMIT流程————向各写入Transaction Marker，在Transaction Log内写入COMPLETE_COMMIT
如果状态是PREPARE_ABORT，完成后续ABORT流程

终止`Transaction ID`

某Transaction ID的Producer可能很长时间不再发送数据，Transaction Coordinator没必要再保存该Transaction ID与PID等的映射，否则可能会造成大量的资源浪费。因此需要有一个机制探测不再活跃的Transaction ID并将其信息删除。

Transaction Coordinator会周期性遍历内存中的Transaction ID与PID映射，如果某Transaction ID没有对应的正在进行中的事务并且它对应的最后一个事务的结束时间与当前时间差大于transactional.id.expiration.ms（默认值是7天），则将其从内存中删除并在Transaction Log中将其对应的日志的值设置为null从而使得Log Compact可将其记录删除。

与其它系统事务机制对比

PostgreSQL MVCC

Kafka的事务机制与《MVCC PostgreSQL实现事务和多版本并发控制的精华》一文中介绍的PostgreSQL通过MVCC实现事务的机制非常类似，对于事务的回滚，并不需要删除已写入的数据，都是将写入数据的事务标记为Rollback/Abort从而在读数据时过滤该数据。

两阶段提交

Kafka的事务机制与《分布式事务（一）两阶段提交及JTA》一文中所介绍的两阶段提交机制看似相似，都分PREPARE阶段和最终COMMIT阶段，但又有很大不同。

Kafka事务机制中，PREPARE时即要指明是PREPARE_COMMIT还是PREPARE_ABORT，并且只须在Transaction Log中标记即可，无须其它组件参与。而两阶段提交的PREPARE需要发送给所有的分布式事务参与方，并且事务参与方需要尽可能准备好，并根据准备情况返回Prepared或Non-Prepared状态给事务管理器。
Kafka事务中，一但发起PREPARE_COMMIT或PREPARE_ABORT，则确定该事务最终的结果应该是被COMMIT或ABORT。而分布式事务中，PREPARE后由各事务参与方返回状态，只有所有参与方均返回Prepared状态才会真正执行COMMIT，否则执行ROLLBACK
Kafka事务机制中，某几个Partition在COMMIT或ABORT过程中变为不可用，只影响该Partition不影响其它Partition。两阶段提交中，若唯一收到COMMIT命令参与者Crash，其它事务参与方无法判断事务状态从而使得整个事务阻塞
Kafka事务机制引入事务超时机制，有效避免了挂起的事务影响其它事务的问题
Kafka事务机制中存在多个Transaction Coordinator实例，而分布式事务中只有一个事务管理器

Zookeeper

Zookeeper的原子广播协议与两阶段提交以及Kafka事务机制有相似之处，但又有各自的特点

Kafka事务可COMMIT也可ABORT。而Zookeeper原子广播协议只有COMMIT没有ABORT。当然，Zookeeper不COMMIT某消息也即等效于ABORT该消息的更新。
Kafka存在多个Transaction Coordinator实例，扩展性较好。而Zookeeper写操作只能在Leader节点进行，所以其写性能远低于读性能。
Kafka事务是COMMIT还是ABORT完全取决于Producer即客户端。而Zookeeper原子广播协议中某条消息是否被COMMIT取决于是否有一大半FOLLOWER ACK该消息。

Kafka系列文章

Kafka消费者重新实现的细节

2018-04-04T11:20:41.000Z

上一章分析的消费者高级API使用ConsumerGroup的语义管理多个消费者，但是在消费者或者Partition发生变化时都需要rebalance，它的实现对ZooKeeper依赖比较严重，
由Kafka内置实现了失败检测和Rebalance(ZKRebalancerListener)，但是它存在羊群效应和脑裂的问题，客户端代码实现低级API也不能解决这个问题。如果将失败探测和Rebalance的逻辑放到一个高可用的中心Coordinator，这两个问题即可解决。同时还可大大减少Zookeeper的负载，有利于Kafka Broker的扩展(Broker也会作为协调节点的角色存在)。

协调节点在前面分析Consumer的Offset(fetchOffsets和commitOffsets)分析过GroupCoordinator的处理逻辑。不过新消费者KafkaConsumer有自己的协调者ConsumerCoordinator。高级API使用ZookeeperConsumerConnector，其中的offset相关fetch和commit API，以及数据抓取线程对于新消费者都需要重新实现，ConsumerCoordinator作为新消费者KafkaConsumer的一部分用java代码重新实现了这些API。服务端的GroupCoordinator对新旧API都适用的。

ConsumerCoordinator是KafkaConsumer的一个成员变量，所以每个消费者都要自己的ConsumerCoordinator，消费者的ConsumerCoordintor只是和服务端的GroupCoordinator通信的介质，下文中提到的协调者一般指的是服务端的GroupCoordinator。每个KafkaServer都有一个GroupCoordinator实例，服务端的GroupCoordinator管理消费组成员和offset，它可以管理多个消费组（因为Broker本身即使存储一个topic的消息，也可以被不同的消费组订阅）。注意：组成员的状态管理（比如GroupMetadata）是在服务端的GroupCoordinator完成的，而不是由消费组的ConsumerCoordinator完成（因为消费者只能看到自己的，无法看到和自己同组的其他成员）。

消费组管理协议

在同一个消费组里多个consumer实例需要进行平衡操作。消费组会注册感兴趣的topics。这个消费组中的所有消费者会互相协调，每个消费者会互相拥有独一的partition集合。即同一个partition只会分配给消费组中的一个消费者。一个消费者可以有多个partition。当消费组成功平衡后，所有注册的topics的每个partition都会被唯一的消费者拥有(每个partition都会被分配给消费者去消费)。每个Broker节点会被选举为一部分消费组的协调节点，消费组的协调节点负责在组成员变化，或者注册的topics的partition变化时进行协调。协调节点同时负责在平衡操作时，将partition的所有权配置信息(partition分配给哪个消费者)在所有consumers之间进行交流。

Consumer消费者的工作过程：

1.在启动时或者协调节点故障转移时，消费者发送ConsumerMetadataRequest给bootstrap brokers列表中的任意一个brokers。在ConsumerMetadataResponse中，它接收消费者对应的消费组所属的协调节点的位置信息。
2.消费者连接协调节点，并发送HeartbeatRequest。如果返回的HeartbeatResponse中返回IllegalGeneration错误码，说明协调节点已经在初始化平衡。消费者就会停止抓取数据，提交offsets，发送JoinGroupRequest给协调节点。在JoinGroupResponse，它接收消费者应该拥有的topic-partitions列表以及当前消费组的新的generation编号。这个时候消费组管理已经完成，消费者就可以开始抓取数据，并为它拥有的partitions提交offsets。
3.如果HeartbeatResponse没有错误返回，消费者会从它上次拥有的partitions列表继续抓取数据，这个过程是不会被中断的。

Co-ordinator协调节点的工作过程：

1.在稳定状态下，协调节点通过故障检测协议跟踪每个消费组中每个消费者的健康状况。
2.在选举和启动时，协调节点读取它管理的消费组列表，以及从ZK中读取每个消费组的成员信息。如果之前没有成员信息，它不会做任何动作。只有在同一个消费组的第一个消费者注册进来时，协调节点才开始工作(即开始加载消费组的消费者成员信息)。
3.当协调节点完全加载完它所负责的消费组列表的所有组成员之前，它会在以下几种请求的响应中返回CoordinatorStartupNotComplete错误码：HeartbeatRequest，OffsetCommitRequest，JoinGroupRequest。这样消费者就会过段时间重试(直到完全加载，没有错误码返回为止)。
4.在选举或启动时，协调节点会对消费组中的所有消费者进行故障检测。根据故障检测协议被协调节点标记为Dead的消费者会从消费组中移除，这个时候协调节点会为Dead的消费者所属的消费组触发一个平衡操作(消费者Dead之后，这个消费者拥有的partition需要平衡给其他消费者)。
5.当HeartbeatResponse返回IllegalGeneration错误码，就会触发平衡操作。一旦所有存活的消费者通过JoinGroupRequests重新注册到协调节点，协调节点会将最新的partition所有权信息在JoinGroupResponse的每个消费者之间通信(同步)，然后就完成了平衡操作。
6.协调节点会跟踪任何一个消费者已经注册的topics的topic-partition的变更。如果它检测到某个topic新增的partition，就会触发平衡操作。当创建一个新的topics也会触发平衡操作，因为消费者可以在topic被创建之前就注册它感兴趣的topics。

从上面两者的工作过程，我们大致知道了协调节点负责管理消费组中的消费者。而消费者会和协调节点通信。如果协调节点发生故障转移，则消费者需要寻找新的协调节点。如果协调节点检测到消费者发生了故障，则协调节点负责平衡操作。

故障检测协议

消费者在加入到消费组时，发送给协调者的JoinGroupRequest设置了session timeout。当消费者成功加入到消费组后，在消费者和协调者都会开始故障检测流程。消费者启动周期性的心跳(发送HeartbeatRequest)，每隔session.timeout.ms/heartbeat.frequency发送给协调者并等待响应。

session.timeout 会话超时的最大时间，超过这个时间，消费者和协调者都会认为对方挂掉了
heartbeart.frequency 心跳频率，时间除于次数表示每一次心跳的时间间隔，间隔越短越容易发生rebalance

如果协调者在session.timeout没有收到消费者的心跳请求，它会标记消费者为死亡状态。同样如果消费者在session.timeout内没有收到心跳响应，它会假设协调者挂掉了，消费者会启动重新发现协调者的流程(每个协调者只管理一部分消费者，一个消费者只被一个协调者管理，协调者是brokers中的一个)。

heartbeat.frequency(心跳频率)是消费者端的配置，它决定了消费者发送一次心跳给协调者的时间间隔。这个值是rebalance延迟的最低临界值，因为协调者是根据心跳响应通知消费者，进行rebalance操作的。(为什么心跳频率和rebalance有关，因为心跳和session.timeout有关，超时后会触发rebalance)。所以如果session.timeout.ms设置的非常大时，也要将心跳频率设置为相对有意义的比较大的值。当然也不能将心跳频率设置的太高(结果是心跳时间间隔很短)，导致brokers的负载太重了。

1.在接收到ConsumerMetadataResponse或JoinGroupResponse后，消费者周期性地发送HeartbeatRequest给协调者。
2.协调者在收到HeartbeatRequesst时，首先检查generation id，消费者编号和消费组。如果消费者指定了一个无效或过期的generation id，协调者会发送带有IllegalGeneration错误码的HeartbeatResponse给消费者。
3.如果协调者在session timeout没有收到消费者的心跳请求，标记消费者挂掉，并触发消费组的rebalance流程。
4.如果消费者在session timeout没有收到协调者的心跳响应，认为协调者失败，并触发重新发现协调者的流程。

当协调者发生故障时，消费者发现新的协调者的顺序可能发生在新的协调者完成故障处理(包括从zk中加载消费组元数据等)之前或之后。如果在完成故障处理之后才发现新的协调者，新的协调者就会像之前一样接收消费者的心跳请求。而如果是在之前，新的协调者则会拒绝消费者的心跳请求，会导致消费者重新发现协调者，并重新连接协调者。如果消费者太晚连接新的协调者，协调者可能会标记消费者挂掉了，消费者再次加入时，会认为这是一个新的消费者，并触发rebalance。

消费者发现新的协调者(co-ordinator re-discovery)，包括两个步骤，首先确定新的协调者，然后消费者连接协调者。如果新的协调者确定了，并且消费者成功连接上新协调者，这样消费者发送的心跳请求就会被新的协调者正常接收。但是如果新协调者已经确定，而消费者并没有连接上新的协调者，消费者发送的心跳请求并不会被接收：因为连接都还没有建立!

状态图

消费者状态机

Down：消费者进程挂掉了。
Start up & discover co-ordinator：在这个状态时，消费者为所属的组发现协调者。消费者一旦发现协调者后就会发送JoinGroupRequest(没有consumer id信息，表示消费组)。如果同一组中的其他消费者指定了和当前消费者存在冲突的partition分配策略。当前消费者就可能接收到InconsistentPartitioningStrategy错误码的响应。如果策略名称不被Brokers识别，会收到UnknownPartitioningStrategy错误码。这种情况消费者无法加入到消费组。
Part of a group：如果收到的JoinGroupResponse没有错误码，有consumer id以及为整个组生成的generation id。消费者就会成为组的一个成员。这个状态下，消费者会发送HeartbeatRequest，根据心跳响应结果的错误码，它可以继续在当前状态，或者移动到Stopped Consumption或者Rediscover co-ordinator的状态。
Re-discover co-ordinator：这个状态下，消费者并没有停止消费，但是会发送GroupCoordinator来尝试重新发现协调者，并且等待响应，直到收到没有错误码的响应(响应结果中会返回新发现的协调者)。
Stopped consumption：消费者停止消费消息，然后提交offset，直到重新加入消费组中才会继续开始消费消息。

协调者状态机

Down：协调者进程挂掉了
Catch up：协调者被选举出来了，但还还没有开始提供服务
Ready：新选举出来的协调者已经完成加载它所负责的消费组的组元数据
Prepare for rebalance：协调者发送IllegalGeneration的心跳响应给组中的所有消费者，并等待消费者发送JoinGroupRequest
Rebalancing：协调者当前generation中收到消费者的JoinGroupRequest，然后增加group的generation id，并且为请求的消费者分配consumer ids(下面说到分配过程)，以及完成partition的分配(将partiton分配给消费者)
Steady：协调者接受每个消费组的所有消费者发送的OffsetCommitRequest和心跳信息。

Consumer id的分配

1.消费者启动后，从协调者接收到的第一次JoinGroupResponse中有consumer id。从这里开始，消费者的每次心跳以及提交offset请求都必须要包含这个consumer id(作为一种标识，比如员工入职后分配了胸卡，你以后上班就都要佩戴胸卡了)。如果协调者收到的HeartbeatRequest和OffsetCommitRequest其中的consumer id和组中的任何一个consumer ids都不同，协调者就会在对应的响应信息中发送带有UnknownConsumer错误码的响应给发起请求的消费者。
2.协调者在成功rebalance时，会为消费者分配一个consumer id，返回在JoinGroupResponse中返回给消费者。消费者可以选择在接下来的JoinGroupRequest中包含这个id，直到消费者被关闭或者挂掉了。带上id的好处是可以降低rebalance操作的延迟，当rebalance触发时，协调者会等待在上一个generation id的所有消费者发送JoinGroupRequest。协调者定位一个消费者是通过它的consumer id。如果消费者选择不带consumer id的JoinGroupRequest，协调者只能等待完全的session timeout才能继续剩下的rebalance操作。这是因为没有办法将不带consumer id的JoinGroupRequest和一个不存在的consumer id的消费者映射起来(请求中没有带consumer id就没办法确定consumer id是否存在，因为无法比较)。而如果(每个)消费者发送的JoinGroupRequest带了consumer id，协调者就能立即确定这个消费者是不是存在，并且能在所有已知的消费者都发送JoinGroupRequest后，完成本次rebalance操作(而不需要等待session timeout才最终完成)。
3.协调者会在接收到一个消费组中所有存在的消费者发送了一个JoinGroupRequest之后开始分配consumer id。它会为JoinGroupRequest中没有consumer id的每个消费者分配新的group-uuid。前提是这样的消费者是刚刚启动的或者没有选择发送之前分配给它的consumer id。
4.如果消费者发送的JoinGroupRequest带了consumer id，但是不匹配当前组成员的ids，协调者会在JoinGroupResponse中返回UnknownConsumer错误码，避免这个消费者加入到不认识的消费组中。这也不会触发组中其他消费者的rebalance操作。

协议格式

对于每个消费组，协调者会存储以下信息：
1) 对每个存在的topic，可以有多个消费组订阅同一个topic(对应消息系统中的广播)
2) 对每个消费组，元数据如下：

消费组订阅的topics列表
Group配置信息，包括session timeout等
组中每个消费者的元数据。消费者元数据包括主机名，consumer id
每个正在消费的topic partition的当前offsets
Partition的ownership元数据，包括consumer到分配给消费者的partitions映射

其他故障场景

协调者故障或者到连接协调者失败

1.协调者发生故障时，控制器会为受到影响的消费组子集选举出新的leader/协调者。作为成为offset-topic-partitions的leader，协调者从zookeeper中读取它负责的每个消费组的元数据。每个消费组的元数据包括了group的consumer ids，generation id，订阅的topics列表。在协调者从zk中读取所有的元数据之前，发送给消费者的心跳响应带有CoordinatorStartupNotComplete错误码。在这段时间如果消费者发送JoinGroupRequest是不合法的，此时返回消费者的错误码是IllegalProtocolState。
2。Broker发送UpdateMetadataRequest给Controller，它在接收到更新的group metadata之前，如果消费者发送了ConsumerMetadataRequest给这个Broker，响应结果会返回协调者过期的信息。这种情况下，消费者发送的心跳和offset提交就会收到错误为NotCoordinatorForGroup的响应结果。所以消费者应该退回重来，即重新发送ConsumerMetadataRequest(确保在update group metadata之后)。

订阅的topics的partition变化

1.消费组对应的协调者负责检测订阅的topics的partitions数量的变化，一旦partitions数量发生变化。
2.协调者标记消费组准备rebalance，此时如果消费者有心跳，返回IllegalGeneration错误码(因为即将新一轮的平衡)，同时消费者会停止抓取数据(平衡要开始了，大家不要拿数据)，并提交offset(先保存下状态)，然后发送JoinGroupRequest给协调者。
3.协调者等待这个组中所有的消费者都给它发送了JoinGroupRequest(大家都签到后才能开始哈)，然后会在zk中增加group的generation id(通知zk现在进入了一个新纪元)，计算新的partition分配(为每个人都重新分口粮)，最后在JoinGroupResponse中返回更新的partition分配信息，以及新的generation id(通知消费者完成了)。注意即使组成员没有变化，generation也会增加，即每次发生rebalance都会增加generation id(类似zk的epoch)。
4.消费者收到JoinGroupResponse，它会在本地存储generation id和自己的consumer id，然后为返回的重新分配到的partitions开始抓取数据。在这之后消费者发送给协调者的请求会使用这个新的generation id以及consumer id，这两个id都是上一次的JoinGroupResponse的返回信息。

在rebalance时的offset提交

上面我们看到消费组开始rebalance时，消费者会停止抓取数据，提交offset。其中提交offsets是为了保存状态信息。

1.如果消费者收到IllegalGeneration错误码(表示当前组正在rebalance)，它会在发送JoinGroupRequest给协调者之前停止抓取数据，并提交已经存在的offsets(发送JoinGroupRequest是rebalance的一部分工作，而停止抓取则是前提条件)。
2.协调者会检查OffsetCommitRequest中的generation id，如果请求中的generation id比协调者的值要高就会被拒绝。
3.协调者不允许消费者发送的OffsetCommitRequest中的generation ids比zk中当前组的generation id要旧。在rebalance时该约束没有问题，因为在所有消费者发送JoinGroupRequest之前，协调者不会增加zk中group的generation id。当协调者增加了generation id之后，在还没有发送JoinGroupResoponse之前，协调者并不期望收到OffsetCommitRequest(在当前最新的generation id里，因为还没有返回响应，组中任何消费者都不会发送最新generation的offset commit请求)。所以消费者发送的每个OffsetCommitRequest应该总是和协调者的当前generation id是匹配的。
4.当消费者遇到软件问题而失败，比如在协调者进行rebalance时，消费者发生了长时间的GC停顿，如果消费者停顿时间超过session timeout，协调者在session timeout时间内就不会收到消费者发送的JoinGroupRequest请求，会标记消费者挂掉。

在rebalance时的heartbeats

1.消费者每隔session.timeout.ms/heartbeat.frequency时间就周期性地发送心跳给协调者。如果消费者在心跳响应中收到IllegalGeneration错误码，它会停止抓取，然后提交offset，并向协调者发送JoinGroupRequest。在消费者收到JoinGroupResponse之前，它不会再向协调者发送任何的心跳请求。
2.设置更高的心跳频率可以确保更低延迟的rebalance操作(因为时间间隔变小，而rebalance是根据这个间隔而触发的)，因为协调者只有在HeartbeatResponse时才有可能触发消费者的rebalance操作(收到心跳响应后加入组就正式开始rebalance)。
3.当协调者收到消费者发送的JoinGroupRequest，在返回JoinGroupResponse给消费者之前，协调者会暂停对这个消费者的故障检测。当协调者把JoinGroupResponse发送出去时，就重新启动心跳计时器，如果在又一次的session timeout时间内没有收到这个消费者的心跳请求会标记这个消费者为Dead(即从JoinGroupResponse发送出去开始计时，在session timeout收到心跳请求才认为消费者正常)。协调者在rebalance时依赖于心跳而停止故障检测是由broker的socket server设计而决定的(协调者也是一个broker)。kafka只允许broker针对每个客户端一次只能读取或者处理一个未完成的请求(这是保证有序处理的简单做法)。这是为了防止对同一个客户端，消费者和broker同时处理心跳请求和join group请求。根据JoinGroupRequest来标记失败，防止协调者在rebalance操作时就将消费者标记为Dead。注意如果消费者在rebalance时遇到软件的问题而停顿，并不会阻碍rebalance操作的完成。如果消费者在发送JoinGroupRequest之前发生停顿，协调者会标记它Dead，然后完成rebalance操作，在新的generation中只包括其他的消费者(失联的那个消费者当然不会被包括在本次generation中了) 。如果消费者在发送JoinGroupRequest之后发生停顿，协调者在假设rebalance操作成功完成的情况下(这里generation包括了消费者)仍然会向它发送JoinGroupResponse，并且重新开始心跳计时器。如果消费者在session timeout之前就恢复了，它会和往常一样消费。如果在session timeout之后还处于停顿状态，它就会被协调者标记为Dead，然后又触发了一次rebalance操作。
4.协调者只在JoinGroupRequest中返回新的generation id和consumer id。一旦消费者接收到JoinGroupResponse，消费者在下一次发送HeartbeatRequest时附带上新的generation id和consumer id发送给协调者。

在rebalance时的协调者故障

rebalance操作会有多个阶段：

1.协调者收到rebalance的通知-可能在zk监视到topic/partition发生变化，新消费者注册，或者旧消费者挂掉。
2.协调者初始化rebalance操作，通过发送带有IllegalGeneration错误码的心跳响应给消费者(消费者发送了心跳请求)。
3.消费者发送JoinGroupRequest请求给协调者(在接收到心跳响应之后)。
4.协调者增加了zk中消费组的generation id，并在zk中写入新的partition ownership信息。
5.协调者发送JoinGroupResponse给消费者。

协调者可能在上面任何一个步骤失败，下面讨论了在每个步骤如果协调者失败了是怎么处理的。

1.协调者在步骤1失败：协调者在收到通知后，但是还没有机会做出反应就失败了，新的协调者为了完成故障处理需要有能力检测什么时候需要rebalance操作。(新)协调者会从zk中读取消费组的元数据，包括消费组订阅的topics列表以及之前的partition ownership。如果topics的数量或者订阅topics的partitions数量和之前的partition ownership决策(分配partition是一种决策)有出入，新的协调者就会认为需要为这个消费组开始进行一次rebalance操作。同样如果消费者连接到新的协调者和zk中group generation的元数据不同，协调者也会为这个消费组开始一次rebalance操作。
2.协调者在步骤2失败，它会发送带有错误码的HeartbeatResponse给一些消费者，但不是全部(挂掉之后当然无法在发送了)。和步骤1的失败类似，协调者会在失效备援(failover)后检测rebalance的需要并开始又一次rebalance操作(失败的协调者发生在它自己的rebalance时，而新的协调者接管后，也需要检测什么时候需要rebalance，所以它的rebalance叫做又一次)。如果是因为一个消费者的失败而开始一次rebalance，但是消费者在协调者failover处理完成之前就恢复为正常状态，协调者不会又开始一次rebalance(如果消费者在session timeout后仍然没有恢复，协调者认为消费者dead，就又开始一次rebalance)。然而，如果只要有任意一个消费者向协调者发送一个JoinGroupRequest，协调者就会为整个消费组开始一次rebalance操作。
3.协调者在步骤3失败，它可能只会接收到消费组中部分consumers的JoinGroupRequest。在失效备援后，协调者可能会收到所有存活的消费者的HeartbeatRequest或者部分消费者的JoinGroupRequest。和步骤1类似，也会触发消费组的rebalance。
4.协调者在步骤4失败，它可能会在写入新的generation id和消费组成员到zk中后失败。generation id和成员信息是作为一个原子的zk写入操作。在失效备援后，消费者会发送旧的generation id的HeartbeatRequests给协调者。协调者比较消费者的心跳请求中的generation和zk不一致，就会返回错误码为IllegalGeneration的响应，让消费者重新发送JoinGroupRequest。所以在HeartbeatRequest和OffsetCommitRequest中附带generation id和consumer id是值得的。
5.协调者在步骤5失败，它可能会在发送JoinGroupResponse给消费组中的部分消费者后失败了。已经接收到JoinGroupResponse的消费者在要发送心跳或者提交offsets时会检测到失败的协调者。这时它会发现新的协调者，并向它以新的generation发送心跳。(新的协调者在这个时候会向消费者发送没有错误码的HeartbeatResponse。对于没有收到JoinGroupResponse的消费者也会发现新的协调者，并且向它发送JoinGroupRequest。这也同样会触发协调者为消费组触发rebalance操作。

慢的消费者

消费速度慢的消费者会被协调者从消费组中移除，比如协调者在session timeout时间内没有收到慢的消费者的心跳请求。典型的场景是如果消费者的消息处理速度比session timeout还要慢，会导致poll调用的时间间隔超过session timeout。由于心跳请求只会在poll调用时才会发送，这会导致协调者标记比较慢的消费者为Dead。协调者处理慢消费者的步骤：

1.如果协调者在session timeout没有收到心跳请求，它标记消费者dead，并且中断到消费者的socket连接。
2.同时协调者会将带有IllegalGeneration错误码的HeartbeatResponse发送给组中其他的消费组，并触发rebalance。
3.如果在协调者接收到其他任意一个消费者的HeartbeatRequest请求之前，慢的消费者先发送了HeartbeatRequest协调者会取消rebalance的尝试，并且返回没有错误码的HeartbeatResponse给慢的消费者(说明由慢状态渐渐好转了)
4.如果不是这种情况(其他消费者先发送心跳)，协调者继续rebalance，也向慢消费者发送IllegalGeneration错误码。
5.由于协调者只会等待存活的消费者的JoinGroupRequest，所以在它接收到其他消费者的join请求后，它说rebalance可以结束了。如果这时慢的消费者恰巧也发送了JoinGroupRequest(突然不慢了)，协调者会在当前generation里包括这个慢的消费者，如果除了这个慢的消费者外，协调者还没有发送一个JoinGroupResponse(是其他消费者都还没发送，还是什么情况?)。
6.如果协调者已经发送了JoinGroupResponse(向其他存活的消费者，而不是这个慢的消费者，因为慢的消费者才刚发送请求)，它会让这一轮的rebalance完成，然后又会紧接着触发下一次的rebalance(慢的消费者在这一轮上轮不上，得等到下一轮)。
7.如果当前这一轮的rebalance时间花的太长了，慢的消费者的JoinGroupResponse就会超时(因为慢的消费者只能等到其他消费者都接收完JoinGroupResponse之后，在第一轮rebalance结束之后，才会发送JoinGroupResponse给慢的消费者，而第一轮的rebalance耗费太长了，慢的消费者在session timeout内没有收到协调者发送的JoinGroupResponse而超时)，消费者会认为协调者发生故障，就会重新发现协调者，并向新的协调者发送JoinGroupRequest。

Offsets和消费者位置

消费者可以定时自动地提交offset，或者手动控制什么时候提交offset。使用commitSync手动提交commitOffset，会阻塞调用线程，直到offsets成功被提交，或者在提交过程中发生错误。使用commitAsync则是非阻塞方式，会在成功提交或者失败时，触发OffsetCommitCallback回调函数的执行。

消费者组和主题订阅

当消费组发生自动重新分配(为partition分配consumer)时，消费者会通过ConsumerRebalanceListener被通知到。这样消费者就可以在监听器开始工作时做一些必要的应用程序处理逻辑，比如清除状态，手动提交offset。同时消费组也可以通过assign(List)，将指定的partitions分配给消费者，这种方式需要关闭动态的partition分配。

新消费者示例

生产者向topic推送消息，消费者订阅topic，一旦topic有消息，消费者就会去拉数据。生产者的一条消息用ProducerRecord表示，消费者的批量消息是ConsumerRecords。生产消息时会指定消息的Key和Value，所以ConsumerRecord也有key和value(还有partition，offset其他属性)。

示例1：最简单的客户端消息消费

KafkaConsumer consumer = new KafkaConsumer<>(props);
consumer.subscribe(Collections.singletonList(this.topic));
ConsumerRecords records = consumer.poll(1000);
for (ConsumerRecord record : records) {
 System.out.println("Received message: (" + record.key() + 
 ", " + record.value() + ") at offset " + record.offset());
}

自动提交offset

利用Kafka的消费组提供的语义，可以管理Consumer的负载均衡和故障处理(offset存储在kafka，并自动提交offset)。Broker使用心跳的方式自动检测消费组中失败的消费者进程，消费者会定时地向集群发送ping(心跳)表示自己存活。只要消费者能够做这件事情(ping)，就说明它是存活的，它就会保留对分配给它的partition的消费的权利。如果消费者超过sessionTimeOut没有发送心跳就会被认为死亡，它的partitions就会分配给其他的线程。

示例2：自动提交offset，获取ConsumerRecord的offset

// 配置信息
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("group.id", "test");
props.put("enable.auto.commit", "true");
props.put("auto.commit.interval.ms", "1000");
props.put("session.timeout.ms", "30000");

// 创建消费者实例, 并且订阅topic
KafkaConsumer consumer = new KafkaConsumer(props);
consumer.subscribe(Arrays.asList("foo", "bar"));

// 消费者消费消息
while (true) {
 ConsumerRecords records = consumer.poll(100);
 for (ConsumerRecord record : records)
 System.out.printf("offset = %d, key = %s, value = %s", record.offset(), record.key(), record.value());
}

手动管理offset

当消息的消费和其他处理逻辑耦合在一起时，只有处理逻辑完成后，才能认为这条消息被成功消费。在下面的示例中，我们消费了一批记录，并且在内存中暂时保存，当有足够的记录时插入到数据库中。如果像前面的示例允许自动提交offset，当消费者获取出消息时就认为消费了一批消息，而我们的处理逻辑在放到内存后，在插入数据库之前如果失败了，就会导致这批消息并没有保存到数据库中，却被消费掉了(丢失)。为了防止这种问题的出现，我们只有在对应的消息插入到数据库之后，才执行一次手动提交offset的工作。通过这种方式，我们可以精确地控制什么时候消息被认为成功地消费了。但是这却引起了另外的一个潜在的问题：在插入到数据库之后，在提交offset之前，客户端应用程序挂掉了，这样应用程序下次启动时，因为offset没有更新，消费者线程会从上次提交的offset开始继续消费消息，就会插入重复的数据(最近的一批)到数据库中。所以这种方式，对于kafka而言，只能保证消息”至少发送一次”，但不能保证”正好一次”(交给了客户端自己实现)。

1.commit offset=10
2.fetch from offset=10，get 5 msgs，offset=16
3.insert 5 msgs into db
4.client failed
5.still fetch from offset=10，get 5 msgs，offset=16
6.insert duplicated 5 msgs into db
7.commit offset=16
8.next time，fetch from offset=16

示例3：客户端手动管理offset的提交

props.put("enable.auto.commit", "false");  // 设置autoCommit为false

int commitInterval = 200;
List> buffer = new ArrayList>();
while (true) {
 ConsumerRecords records = consumer.poll(100);
 for (ConsumerRecord record : records) {
 buffer.add(record);
 if (buffer.size() >= commitInterval) {
 insertIntoDb(buffer);
 consumer.commitSync();
 buffer.clear();
 }
 }
}

订阅指定的partition

前面的示例我们订阅了感兴趣的topics，然后kafka会帮我们在这些topics公平地共享partitions。这种简单的负载均衡方式，能让客户端程序的多个实例(多个消费者进程)一起完成所有记录的处理工作。使用指定partition的方式，消费者只会分配到指定的partition，如果消费者挂掉后，并不会有负载均衡的工作，会将这个消费者的partitions分配给其他的消费者线程实例(相当于静态分配)。但是有几种场景是有意义的：

如果消费者逻辑维护了和这个Partition相关的一些本地状态(比如本地的KV存储)，就应该只从它维护的本地磁盘对应的partition获取记录
消费者线程本身就是HA的，如果它失败了，会重启(比如使用集群管理框架，就像YARN，Mesos，或者作为流处理框架的一部分)。这种情况也不需要kafka检测失败以及重新分配partition(因为失败后重启，还会消费之前所属的partition)。

在动态分配partition的场景下，消费者的加入和删除，都会导致partition的重新分配给其他的消费者。而静态分配partition下，如果消费者挂掉后，分配给这个消费者的partition并不会负载给其他消费者。静态分配partition的模式，消费者不是订阅主题，而是订阅指定的partition(当然partition也是由topic组成的)：

String topic = "foo";
TopicPartition partition0 = new TopicPartition(topic, 0);
TopicPartition partition1 = new TopicPartition(topic, 1);
consumer.assign(partition0);
consumer.assign(partition1);

consumer所指定的消费组仍然会用来提交offset(partition的offset是面向消费组的，而不是针对每个消费者，虽然partition是分配给消费者处理的，但如果offset记录在消费者上，当所属的消费者挂掉后，这个offset就会丢失掉了，所以应该记录在消费组上)。现在因为消费者固定分配了指定的partitions，只有指定了新的partitions，消费者的partitions集合才会变化，但仍然没有失败检测。注意：不可能为一个消费者实例同时混合订阅指定的partition(没有负载均衡)和订阅topic(有负载均衡)两种逻辑。

下面的示例consumer订阅了指定的topic和partitions，消费者在关闭之前会消费这些partitions到最近可用的消息。使用静态partition分配，就意味着自动放弃了消费组的管理功能。不过仍然要指定group.id来使用kafka的offset管理，但并不需要指定sessionTimeOut。因为只有使用group management时，在session超时后才会完成自动故障转移。

示例4：消费者订阅指定的partitions

Properties props = new Properties();
props.put("metadata.broker.list", "localhost:9092");
props.put("group.id", "test");
props.put("enable.auto.commit", "true");
props.put("auto.commit.interval.ms", "10000");
KafkaConsumer consumer = new KafkaConsumer(props);

// subscribe to some partitions of topic foo
TopicPartition partition0 = new TopicPartition("foo", 0);
TopicPartition partition1 = new TopicPartition("foo", 1);
TopicPartition[] partitions = new TopicPartition[2];
partitions[0] = partition0;
partitions[1] = partition1;
consumer.subscribe(partitions);

// find the last committed offsets for partitions 0,1 of topic foo
Map lastCommittedOffsets = consumer.committed(partition0, partition1);
// seek to the last committed offsets to avoid duplicates
consumer.seek(lastCommittedOffsets);

// find the offsets of the latest available messages to know where to stop consumption
Map latestAvailableOffsets = 
 consumer.offsetsBeforeTime(-2, partition0, partition1);
boolean isRunning = true;
Map consumedOffsets = new HashMap();
while(isRunning) {
 Map records = consumer.poll(100, TimeUnit.MILLISECONDS);
 Map lastConsumedOffsets = process(records);
 consumedOffsets.putAll(lastConsumedOffsets);
 for(TopicPartition partition : partitions) {
 if(consumedOffsets.get(partition) >= latestAvailableOffsets.get(partition))
 isRunning = false;
 else
 isRunning = true;
 }
}
consumer.commit();
consumer.close();

存储offset到kafka之外

消费者客户端应用程序并不一定要求将kafka作为内置的offset存储。可以将offset存储在自己选择的其他存储系统中。常见的用法是应用程序将offset和消费的结果以原子性/事务的方式存储在同一个系统中，当然原子性并不一定是需要的。但是选择这种方式，可以确保消费的”完全原子性”，能够保证”正好一次”的语义，这比kafka默认提供的”至少一次”语义要强壮。

如果消费结果要保存到关系型数据库中，同时存储offset到数据库中，可以在一次事务中同时提交结果和offset。这种情况下，记录被消费，并成功存储，offset被更新表示事务成功。而事务失败时，结果不会存储，offset也不会被更新。
如果结果保存到本次存储，最好也将offset也一起保存到本地。

由于每条记录都有自己的offset，为了管理你自己的offset，需要做下面的几个工作：

配置enable.auto.commit=false，关闭自动提交offset
用每个ConsumerRecord的offset来保存你自己的position信息
在重启时，恢复consumer的position，调用seek(TopicPartition，long)

如果partition的分配也采用手动静态分配的方式，上面的步骤会简单很多。如果是自动分配partition，在partition变化时有一些额外的工作需要做。调用subscribe(List，ConsumerRebalanceListener)中的Listener就完成了这个额外的工作。当partitions从消费者去掉，消费者会在Listener的onPartitionRevoked()为这些partition提交offset(最后一次机会了)。当partitions分配给一个消费者，消费者会查找这些新的partition的offset(就比如上面被去掉的partition)，然后初始化(这是一个新创建的)消费者到查找出来的那个offset位置。这是在监听器的onPartitionsAssigned方法中。

ConsumerRebalanceListener另一个通用做法是在移动partition到其他消费者时，刷新应用程序为partitions维护的任何缓存。因为缓存是根据partition的数据构建的，一旦partition迁移到其他消费者实例，原先的缓存在当前应用程序就失效了，所以需要刷新。

示例5：消费者订阅指定的partitions，并且使用外部存储offset

Properties props = new Properties();
props.put("metadata.broker.list", "localhost:9092");
KafkaConsumer consumer = new KafkaConsumer(props);

// subscribe to some partitions of topic foo
TopicPartition partition0 = new TopicPartition("foo", 0);
TopicPartition partition1 = new TopicPartition("foo", 1);
TopicPartition[] partitions = new TopicPartition[2];
partitions[0] = partition0;
partitions[1] = partition1;
consumer.subscribe(partitions);

// seek to the last committed offsets to avoid duplicates
Map lastCommittedOffsets = getLastCommittedOffsetsFromCustomStore();
consumer.seek(lastCommittedOffsets); 

// find the offsets of the latest available messages to know where to stop consumption
Map latestAvailableOffsets = 
 consumer.offsetsBeforeTime(-2, partition0, partition1);
boolean isRunning = true;
Map consumedOffsets = new HashMap();
while(isRunning) {
 Map records = consumer.poll(100, TimeUnit.MILLISECONDS);
 Map lastConsumedOffsets = process(records);
 consumedOffsets.putAll(lastConsumedOffsets);
 // commit offsets for partitions 0,1 for topic foo to custom store
 commitOffsetsToCustomStore(consumedOffsets);
 for(TopicPartition partition : partitions) {
 if(consumedOffsets.get(partition) >= latestAvailableOffsets.get(partition))
 isRunning = false;
 else isRunning = true;
 } 
} 
commitOffsetsToCustomStore(consumedOffsets); 
consumer.close();

控制消费者的position

在大多数情况下，消费者消费记录只是简单地从一开始到结束，并且定时地提交它的位置(不管是自动的还是手动的)。不过新的API也允许消费者手动控制它的位置，消费者可以在一个partition钟随意地往前或者往后移动位置。这就意味着消费者可以重新消费旧的记录(多次读取相同的记录)，或者直接跳到最近的记录，忽略掉中间的记录。

消费者可能落后太多，并不尝试抓取所有落后的记录，而是直接跳到最近的记录。对时间敏感的记录，这种处理方式也是有意义的。
对于需要维护本地状态的系统，消费者在启动时会初始化它的位置，无论本地状态保存的是什么。而且如果本地状态数据被破坏
(比如磁盘损坏)，本地状态可以通过重新消费所有的数据，在新的机器上重建状态信息(假设kafka保存了足够的历史数据)。

kafka允许通过seek(TopicPartition，long)指定新的位置，或者seekToBeginning，seekToEnd定位到最早或最近的offset。下面的示例假设offsets保存在kafka中，并使用commit方法手动提交offset，如果消息消费失败，会重置consumer的offsets。注意seek重置offsets只对当前消费者起作用，它并不会触发consumer的rebalance，或者影响其他消费者的fetchOffsets。

示例6：消息消费失败时，重置offset

int commitInterval = 100;
int numRecords = 0;
boolean isRunning = true;
Map consumedOffsets = new HashMap();
while(isRunning) {
 Map records = consumer.poll(100, TimeUnit.MILLISECONDS);
 try {
 Map lastConsumedOffsets = process(records);
 consumedOffsets.putAll(lastConsumedOffsets);
 numRecords += records.size();
 // commit offsets for all partitions of topics foo, bar synchronously, owned by this consumer instance
 if(numRecords % commitInterval == 0) consumer.commit();
 } catch(Exception e) {
 try {
 // rewind consumer's offsets for failed partitions
 // assume failedPartitions() returns the list of partitions for which the processing of the last batch of messages failed
 List failedPartitions = failedPartitions(); 
 Map offsetsToRewindTo = new HashMap();
 for(TopicPartition failedPartition : failedPartitions) {
 // rewind to the last consumed offset for the failed partition. Since process() failed for this partition, the consumed offset
 // should still be pointing to the last successfully processed offset and hence is the right offset to rewind consumption to.
 offsetsToRewindTo.put(failedPartition, consumedOffsets.get(failedPartition));
 }
 // seek to new offsets only for partitions that failed the last process()
 consumer.seek(offsetsToRewindTo);
 } catch(Exception e) {  break; } // rewind failed
 }
}
consumer.close();

上面的process方法假设接收一批消息，返回每个partition最近处理过的消息的offset(consumedOffset，不是nextOffset)。在消费一批数据之后，将consumedOffsets保存在内存中。当有异常发生时，循环failedPartitions的每个partition，从内存中获取出partition对应的consumedOffset，让消费者实例重新seek(参数可以是多个Partition到offset的映射)。

private Map process(Map records) {
 Map processedOffsets = new HashMap();
 for(Entry recordMetadata : records.entrySet()) {
 List recordsPerTopic = recordMetadata.getValue().records();
 for(int i = 0;i 
 ConsumerRecord record = recordsPerTopic.get(i);
 // process record
 processedOffsets.put(record.partition(), record.offset()); 
 }
 }
 return processedOffsets; 
}

示例7：对整个消费组倒回offsets

如果使用了kafka的group management(消费组管理功能具有consuers的自动负载均衡以及故障处理能力)，为每个消费者实例系统级地倒回offsets的准确位置是在ConsumerRebalanceListener回调函数里。在consumer发生rebalance时，并且在消费消息之前，当consumer被分配到新的partitions集合后，会触发onPartitionAssigned回调函数的执行。在这里为consuer提供全新的倒回offset功能才是正确的。如果你能预知在当前的消费组管理中会一直重置consumer的offset，建议你总是配置consumer使用ConsumerRebalanceListener，并使用一个标志位用来判断是否启用offset的倒回逻辑功能。

倒回offset函数的作用是，在成功地消费了消息并且提交了offset之后，你发现了消息处理逻辑中存在的问题。这时你希望对整个消费组进行offset倒回，这还只是作为对处理逻辑修复的回滚操作的一部分工作。(消息处理逻辑存在问题，需要对已经消费的消息使用新的处理逻辑重新消费，所以需要回滚offset)这种情况下，你会为每个消费者实例开启倒回offset的配置标志位。并且依次滚动重启每个消费者实例。(消费逻辑存在问题，在修改消费者客户端代码后，必须要重启消费者进程才能以最新的逻辑消费消息)每次重启都会触发rebalance，最终所有的消费者实例都会对它们拥有的partitions倒回offsets。

KafkaConsumer consumer = new KafkaConsumer(props,
 new ConsumerRebalanceListener() {
 boolean rewindOffsets = true;  // should be retrieved from external application config
 public void onPartitionsAssigned(Consumer consumer, TopicPartition...partitions) {
 Map latestCommittedOffsets = consumer.committed(partitions);
 if(rewindOffsets)
 Map newOffsets = rewindOffsets(latestCommittedOffsets, 100);
 consumer.seek(newOffsets);
 }
 public void onPartitionsRevoked(Consumer consumer, TopicPartition...partitions) {
 consumer.commit();
 }
 // this API rewinds every partition back by numberOfMessagesToRewindBackTo messages
 private Map rewindOffsets(Map currentOffsets,
 long numberOfMessagesToRewindBackTo) {
 Map newOffsets = new HashMap();
 for(Map.Entry offset : currentOffsets.entrySet()) 
 newOffsets.put(offset.getKey(), offset.getValue() - numberOfMessagesToRewindBackTo);
 return newOffsets;
 }
});
consumer.subscribe("foo", "bar");
//...同上调用了process消费消息,并保存到consumedOffsets内存中
consumer.close();

示例8：使用外部offset存储倒回offsets

由于将offset保存在外部存储系统中，消费者要倒回offset时，需要从自定义存储中读取offset提供给消费者。同样onPartitionAssigned回调函数也是将自定义存储的offsets提供给消费者的正确的地方。同时客户端代码还需要提供保存消费者的offsets到自定义存储系统中的方法(有读取就有存储)。因为onPartitionsRevoked会在消费者停止抓取数据之后，并partition的所有权更改之前调用。所以这里是为消费者拥有的partitions提交offsets的正确位置。

KafkaConsumer consumer = new KafkaConsumer(props,
 new ConsumerRebalanceListener() {
 // 从自定义存储中读取offset,让consumer重置offset
 public void onPartitionsAssigned(Consumer consumer, TopicPartition...partitions) {
 Map lastCommittedOffsets = getLastCommittedOffsets(partitions);
 consumer.seek(lastCommittedOffsets);
 }
 // 提交offset,保存offset带外部存储中
 public void onPartitionsRevoked(Consumer consumer, TopicPartition...partitions) {
 Map offsets = getLastConsumedOffsets(partitions);
 commitOffsetsToCustomStore(offsets); 
 }
 // following APIs should be implemented by the user for custom offset management
 private Map getLastCommittedOffsets(TopicPartition... partitions) {return null;}
 private Map getLastConsumedOffsets(TopicPartition... partitions) {return null;}
 private void commitOffsetsToCustomStore(Map offsets) {}
});
Map consumedOffsets = new HashMap();
while(isRunning) {
 Map records = consumer.poll(100, TimeUnit.MILLISECONDS);
 Map lastConsumedOffsets = process(records);
 consumedOffsets.putAll(lastConsumedOffsets);
 numRecords += records.size();
 // commit offsets for all partitions of topics foo, bar synchronously, owned by this consumer instance
 if(numRecords % commitInterval == 0) commitOffsetsToCustomStore(consumedOffsets);
}
consumer.close();

消费流控制

如果一个消费者要抓取多个分配的partitions，它会尝试同时消费所有partitions的消息，即这些partitions的优先级是相同的。但是在有些情况下，消费者要首先专注于对一部分partitions开足马力抓取数据，对其他partitions的抓取只有在优先级比较高的那些partitions只有很少数据，或者没有数据可以消费时(比较空闲的状态)，才去消费那些优先级比较低的partitions。典型的应用是流处理，比如处理器从两个topics抓取数据，并且在这两个流上运用join操作算子。当其中一个topic落后于另外一个流的消息太多，处理器应该要暂停抓取领先的流，而去抓取落后的流，让它赶上来(才能一起join)。另外一个场景是在消费者启动的时候，由于历史数据太多了，一时半会儿赶不上。而应用程序对于某些topics通常只需要得到最近的数据。所以对于这些topics会优先考虑抓取数据，而其他topics则会暂停(让出资源给优先级高的优先抓取，而资源共享会拖慢整体速度)。kafka支持动态的消息获取控制，pause会暂停获取某个partition的消息，而resume则恢复获取(在未来的某个时刻调用poll时)。

多线程处理

kafka的消费者(KafkaConsumer对象)并不是线程安全的。客户端代码需要自己确保多线程的访问是同步的。未同步的访问会抛出ConcurrentModificationException(比如对Map访问的同时又修改了Map也会报这个错)。唯一例外的是wakeup方法(是线程安全的)：它可以被外部线程用来安全地中断一个进行中的操作。对于阻塞在wakeup方法上的线程会抛出WakeupException。可以被另外的线程用来作为关闭consumer的钩子。

public class KafkaConsumerRunner implements Runnable {
 private final AtomicBoolean closed = new AtomicBoolean(false);
 private final KafkaConsumer consumer;

 public void run() {
 try {
 consumer.subscribe("topic");
 while (!closed.get()) {
 ConsumerRecords records = consumer.poll(10000);
 // 处理新的记录
 }
 } catch (WakeupException e) {
 if (!closed.get()) throw e; //如果关闭了忽略异常
 } finally {
 consumer.close();
 }
 }
 // 关闭钩子,可以在另一个线程中调用
 public void shutdown() {
 closed.set(true);
 consumer.wakeup();
 }
}

我们故意避免为了消息处理而实现特殊的线程模型(即Handle new records部分)，有多种方式实现多线程的消息处理。

1) 一个线程一个消费者

每个线程都有自己的消费者实例，消息消费逻辑和消息处理逻辑都在消费者线程中完成。这种方式的利弊：

优点：很容易实现，执行很快，因为没有线程之间的交互和协调。
优点：对于每个partition要保证顺序处理比较容易实现。每个线程只需要按照顺序处理它接收到的消息即可。
缺点：更多的消费者意味着集群的TCP连接也很多。不过kafka处理连接是很高效的，所以这个代价并不是很大。
缺点：多个消费者意味着发送更多的请求给服务器，每一批发送的数据变少(发送更多批)，就会降低I/O吞吐量。
缺点：所有进程之间的线程数量会被partitions的数量所限制。

2) 解耦消费和处理逻辑

另一种方式是有一个或多个消费者线程用来消费消息，并将消费结果ConsumerRecords转移一个阻塞队列中，
它会被消息处理线程池消费，消息处理线程顾名思义就是处理消息的线程。这种方式的利弊：

优点：可以相互独立地扩展消费者数量和处理器数量。可以只用一个消费者线程服务于多个处理线程，避免partitions的限制。
缺点：在处理器线程之间保证消息处理的顺序是比较困难的。因为线程之间是独立的，线程之间的顺序是无法保证的。所以即使是比较早的数据块也有可能比靠后面的数据块更晚被处理到。如果要求消息的处理是无序的，当然是没有问题的。
缺点：手动提交offset变得困难，因为它需要所有的线程协调起来确保这个partition的消息已经被处理完毕。

解决上面的缺点有多种方式。比如每个处理线程都可以有自己的队列，消费者可以对TopicPartition的hash结果放入不同处理线程的队列中，这样也可以确保消息被顺序地消费，并且简化提交offset的逻辑。

Kafka设计解析（六）- Kafka高性能架构之道

2018-04-04T10:34:10.000Z

本文从宏观架构层面和微观实现层面分析了Kafka如何实现高性能。包含Kafka如何利用Partition实现并行处理和提供水平扩展能力，如何通过ISR实现可用性和数据一致性的动态平衡，如何使用NIO和Linux的sendfile实现零拷贝以及如何通过顺序读写和数据压缩实现磁盘的高效利用。

摘要

上一篇文章《Kafka设计解析（五）- Kafka性能测试方法及Benchmark报告》从测试角度说明了Kafka的性能。本文从宏观架构层面和具体实现层面分析了Kafka如何实现高性能。

宏观架构层面

利用Partition实现并行处理

Partition提供并行处理的能力

Kafka是一个Pub-Sub的消息系统，无论是发布还是订阅，都须指定Topic。如《Kafka设计解析（一）- Kafka背景及架构介绍》一文所述，Topic只是一个逻辑的概念。每个Topic都包含一个或多个Partition，不同Partition可位于不同节点。同时Partition在物理上对应一个本地文件夹，每个Partition包含一个或多个Segment，每个Segment包含一个数据文件和一个与之对应的索引文件。在逻辑上，可以把一个Partition当作一个非常长的数组，可通过这个“数组”的索引（offset）去访问其数据。

一方面，由于不同Partition可位于不同机器，因此可以充分利用集群优势，实现机器间的并行处理。另一方面，由于Partition在物理上对应一个文件夹，即使多个Partition位于同一个节点，也可通过配置让同一节点上的不同Partition置于不同的disk drive上，从而实现磁盘间的并行处理，充分发挥多磁盘的优势。

利用多磁盘的具体方法是，将不同磁盘mount到不同目录，然后在server.properties中，将log.dirs设置为多目录（用逗号分隔）。Kafka会自动将所有Partition尽可能均匀分配到不同目录也即不同目录（也即不同disk）上。

注：虽然物理上最小单位是Segment，但Kafka并不提供同一Partition内不同Segment间的并行处理。因为对于写而言，每次只会写Partition内的一个Segment，而对于读而言，也只会顺序读取同一Partition内的不同Segment。

Partition是最小并发粒度

如同《Kafka设计解析（四）- Kafka Consumer设计解析》一文所述，多Consumer消费同一个Topic时，同一条消息只会被同一Consumer Group内的一个Consumer所消费。而数据并非按消息为单位分配，而是以Partition为单位分配，也即同一个Partition的数据只会被一个Consumer所消费（在不考虑Rebalance的前提下）。

如果Consumer的个数多于Partition的个数，那么会有部分Consumer无法消费该Topic的任何数据，也即当Consumer个数超过Partition后，增加Consumer并不能增加并行度。

简而言之，Partition个数决定了可能的最大并行度。如下图所示，由于Topic 2只包含3个Partition，故group2中的Consumer 3、Consumer 4、Consumer 5 可分别消费1个Partition的数据，而Consumer 6消费不到Topic 2的任何数据。

以Spark消费Kafka数据为例，如果所消费的Topic的Partition数为N，则有效的Spark最大并行度也为N。即使将Spark的Executor数设置为N+M，最多也只有N个Executor可同时处理该Topic的数据。

ISR实现可用性与数据一致性的动态平衡

CAP理论

CAP理论是指，分布式系统中，一致性、可用性和分区容忍性最多只能同时满足两个。

一致性

通过某个节点的写操作结果对后面通过其它节点的读操作可见
如果更新数据后，并发访问情况下后续读操作可立即感知该更新，称为强一致性
如果允许之后部分或者全部感知不到该更新，称为弱一致性
若在之后的一段时间（通常该时间不固定）后，一定可以感知到该更新，称为最终一致性

可用性

任何一个没有发生故障的节点必须在有限的时间内返回合理的结果

分区容忍性

部分节点宕机或者无法与其它节点通信时，各分区间还可保持分布式系统的功能

一般而言，都要求保证分区容忍性。所以在CAP理论下，更多的是需要在可用性和一致性之间做权衡。

常用数据复制及一致性方案

Master-Slave

RDBMS的读写分离即为典型的Master-Slave方案
同步复制可保证强一致性但会影响可用性
异步复制可提供高可用性但会降低一致性

WNR

主要用于去中心化的分布式系统中。DynamoDB与Cassandra即采用此方案或其变种
N代表总副本数，W代表每次写操作要保证的最少写成功的副本数，R代表每次读至少要读取的副本数
当W+R>N时，可保证每次读取的数据至少有一个副本拥有最新的数据
多个写操作的顺序难以保证，可能导致多副本间的写操作顺序不一致。Dynamo通过向量时钟保证最终一致性

Paxos及其变种

Google的Chubby，Zookeeper的原子广播协议（Zab），RAFT等

基于ISR的数据复制方案
如《 Kafka High Availability（上）》一文所述，Kafka的数据复制是以Partition为单位的。而多个备份间的数据复制，通过Follower向Leader拉取数据完成。从一这点来讲，Kafka的数据复制方案接近于上文所讲的Master-Slave方案。不同的是，Kafka既不是完全的同步复制，也不是完全的异步复制，而是基于ISR的动态复制方案。

ISR，也即In-sync Replica。每个Partition的Leader都会维护这样一个列表，该列表中，包含了所有与之同步的Replica（包含Leader自己）。每次数据写入时，只有ISR中的所有Replica都复制完，Leader才会将其置为Commit，它才能被Consumer所消费。

这种方案，与同步复制非常接近。但不同的是，这个ISR是由Leader动态维护的。如果Follower不能紧“跟上”Leader，它将被Leader从ISR中移除，待它又重新“跟上”Leader后，会被Leader再次加加ISR中。每次改变ISR后，Leader都会将最新的ISR持久化到Zookeeper中。

至于如何判断某个Follower是否“跟上”Leader，不同版本的Kafka的策略稍微有些区别。

对于0.8.*版本，如果Follower在replica.lag.time.max.ms时间内未向Leader发送Fetch请求（也即数据复制请求），则Leader会将其从ISR中移除。如果某Follower持续向Leader发送Fetch请求，但是它与Leader的数据差距在replica.lag.max.messages以上，也会被Leader从ISR中移除。
从0.9.0.0版本开始，replica.lag.max.messages被移除，故Leader不再考虑Follower落后的消息条数。另外，Leader不仅会判断Follower是否在replica.lag.time.max.ms时间内向其发送Fetch请求，同时还会考虑Follower是否在该时间内与之保持同步。
0.10. 版本的策略与0.9.版一致

对于0.8.版本的replica.lag.max.messages参数，很多读者曾留言提问，既然只有ISR中的所有Replica复制完后的消息才被认为Commit，那为何会出现Follower与Leader差距过大的情况。原因在于，Leader并不需要等到前一条消息被Commit才接收后一条消息。事实上，Leader可以按顺序接收大量消息，最新的一条消息的Offset被记为High Wartermark。而只有被ISR中所有Follower都复制过去的消息才会被Commit，Consumer只能消费被Commit的消息。由于Follower的复制是严格按顺序的，所以被Commit的消息之前的消息肯定也已经被Commit过。换句话说，High Watermark标记的是Leader所保存的最新消息的offset，而Commit Offset标记的是最新的可被消费的（已同步到ISR中的Follower）消息。而Leader对数据的接收与Follower对数据的复制是异步进行的，因此会出现Commit Offset与High Watermark存在一定差距的情况。0.8.版本中replica.lag.max.messages限定了Leader允许的该差距的最大值。

Kafka基于ISR的数据复制方案原理如下图所示。

如上图所示，在第一步中，Leader A总共收到3条消息，故其high watermark为3，但由于ISR中的Follower只同步了第1条消息（m1），故只有m1被Commit，也即只有m1可被Consumer消费。此时Follower B与Leader A的差距是1，而Follower C与Leader A的差距是2，均未超过默认的replica.lag.max.messages，故得以保留在ISR中。在第二步中，由于旧的Leader A宕机，新的Leader B在replica.lag.time.max.ms时间内未收到来自A的Fetch请求，故将A从ISR中移除，此时ISR={B，C}。同时，由于此时新的Leader B中只有2条消息，并未包含m3（m3从未被任何Leader所Commit），所以m3无法被Consumer消费。第四步中，Follower A恢复正常，它先将宕机前未Commit的所有消息全部删除，然后从最后Commit过的消息的下一条消息开始追赶新的Leader B，直到它“赶上”新的Leader，才被重新加入新的ISR中。

使用ISR方案的原因

由于Leader可移除不能及时与之同步的Follower，故与同步复制相比可避免最慢的Follower拖慢整体速度，也即ISR提高了系统可用性。
ISR中的所有Follower都包含了所有Commit过的消息，而只有Commit过的消息才会被Consumer消费，故从Consumer的角度而言，ISR中的所有Replica都始终处于同步状态，从而与异步复制方案相比提高了数据一致性。
ISR可动态调整，极限情况下，可以只包含Leader，极大提高了可容忍的宕机的Follower的数量。与Majority Quorum方案相比，容忍相同个数的节点失败，所要求的总节点数少了近一半。

ISR相关配置说明

Broker的min.insync.replicas参数指定了Broker所要求的ISR最小长度，默认值为1。也即极限情况下ISR可以只包含Leader。但此时如果Leader宕机，则该Partition不可用，可用性得不到保证。
只有被ISR中所有Replica同步的消息才被Commit，但Producer发布数据时，Leader并不需要ISR中的所有Replica同步该数据才确认收到数据。Producer可以通过acks参数指定最少需要多少个Replica确认收到该消息才视为该消息发送成功。acks的默认值是1，即Leader收到该消息后立即告诉Producer收到该消息，此时如果在ISR中的消息复制完该消息前Leader宕机，那该条消息会丢失。而如果将该值设置为0，则Producer发送完数据后，立即认为该数据发送成功，不作任何等待，而实际上该数据可能发送失败，并且Producer的Retry机制将不生效。更推荐的做法是，将acks设置为all或者-1，此时只有ISR中的所有Replica都收到该数据（也即该消息被Commit），Leader才会告诉Producer该消息发送成功，从而保证不会有未知的数据丢失。

具体实现层面

高效使用磁盘

顺序写磁盘

根据《一些场景下顺序写磁盘快于随机写内存》所述，将写磁盘的过程变为顺序写，可极大提高对磁盘的利用率。

Kafka的整个设计中，Partition相当于一个非常长的数组，而Broker接收到的所有消息顺序写入这个大数组中。同时Consumer通过Offset顺序消费这些数据，并且不删除已经消费的数据，从而避免了随机写磁盘的过程。

由于磁盘有限，不可能保存所有数据，实际上作为消息系统Kafka也没必要保存所有数据，需要删除旧的数据。而这个删除过程，并非通过使用“读-写”模式去修改文件，而是将Partition分为多个Segment，每个Segment对应一个物理文件，通过删除整个文件的方式去删除Partition内的数据。这种方式清除旧数据的方式，也避免了对文件的随机写操作。

通过如下代码可知，Kafka删除Segment的方式，是直接删除Segment对应的整个log文件和整个index文件而非删除文件中的部分内容。



/**

 * Delete this log segment from the filesystem.

 *

 * @throws KafkaStorageException if the delete fails.

 */

def delete() {

 val deletedLog = log.delete()

 val deletedIndex = index.delete()

 val deletedTimeIndex = timeIndex.delete()

 if(!deletedLog && log.file.exists)

 throw new KafkaStorageException("Delete of log " + log.file.getName + " failed.")

 if(!deletedIndex && index.file.exists)

 throw new KafkaStorageException("Delete of index " + index.file.getName + " failed.")

 if(!deletedTimeIndex && timeIndex.file.exists)

 throw new KafkaStorageException("Delete of time index " + timeIndex.file.getName + " failed.")

}

充分利用Page Cache

使用Page Cache的好处如下

I/O Scheduler会将连续的小块写组装成大块的物理写从而提高性能
I/O Scheduler会尝试将一些写操作重新按顺序排好，从而减少磁盘头的移动时间
充分利用所有空闲内存（非JVM内存）。如果使用应用层Cache（即JVM堆内存），会增加GC负担
读操作可直接在Page Cache内进行。如果消费和生产速度相当，甚至不需要通过物理磁盘（直接通过Page Cache）交换数据
如果进程重启，JVM内的Cache会失效，但Page Cache仍然可用

Broker收到数据后，写磁盘时只是将数据写入Page Cache，并不保证数据一定完全写入磁盘。从这一点看，可能会造成机器宕机时，Page Cache内的数据未写入磁盘从而造成数据丢失。但是这种丢失只发生在机器断电等造成操作系统不工作的场景，而这种场景完全可以由Kafka层面的Replication机制去解决。如果为了保证这种情况下数据不丢失而强制将Page Cache中的数据Flush到磁盘，反而会降低性能。也正因如此，Kafka虽然提供了flush.messages和flush.ms两个参数将Page Cache中的数据强制Flush到磁盘，但是Kafka并不建议使用。

如果数据消费速度与生产速度相当，甚至不需要通过物理磁盘交换数据，而是直接通过Page Cache交换数据。同时，Follower从Leader Fetch数据时，也可通过Page Cache完成。下图为某Partition的Leader节点的网络/磁盘读写信息。

从上图可以看到，该Broker每秒通过网络从Producer接收约35MB数据，虽然有Follower从该Broker Fetch数据，但是该Broker基本无读磁盘。这是因为该Broker直接从Page Cache中将数据取出返回给了Follower。

支持多Disk Drive

Broker的log.dirs配置项，允许配置多个文件夹。如果机器上有多个Disk Drive，可将不同的Disk挂载到不同的目录，然后将这些目录都配置到log.dirs里。Kafka会尽可能将不同的Partition分配到不同的目录，也即不同的Disk上，从而充分利用了多Disk的优势。

零拷贝

Kafka中存在大量的网络数据持久化到磁盘（Producer到Broker）和磁盘文件通过网络发送（Broker到Consumer）的过程。这一过程的性能直接影响Kafka的整体吞吐量。

传统模式下的四次拷贝与四次上下文切换

以将磁盘文件通过网络发送为例。传统模式下，一般使用如下伪代码所示的方法先将文件数据读入内存，然后通过Socket将内存中的数据发送出去。

1
2
3

buffer = File.read

Socket.send(buffer)

这一过程实际上发生了四次数据拷贝。首先通过系统调用将文件数据读入到内核态Buffer（DMA拷贝），然后应用程序将内存态Buffer数据读入到用户态Buffer（CPU拷贝），接着用户程序通过Socket发送数据时将用户态Buffer数据拷贝到内核态Buffer（CPU拷贝），最后通过DMA拷贝将数据拷贝到NIC Buffer。同时，还伴随着四次上下文切换，如下图所示。

sendfile和transferTo实现零拷贝

Linux 2.4+内核通过sendfile系统调用，提供了零拷贝。数据通过DMA拷贝到内核态Buffer后，直接通过DMA拷贝到NIC Buffer，无需CPU拷贝。这也是零拷贝这一说法的来源。除了减少数据拷贝外，因为整个读文件-网络发送由一个sendfile调用完成，整个过程只有两次上下文切换，因此大大提高了性能。零拷贝过程如下图所示。

从具体实现来看，Kafka的数据传输通过TransportLayer来完成，其子类PlaintextTransportLayer通过Java NIO的FileChannel的transferTo和transferFrom方法实现零拷贝，如下所示。

@Override

public long transferFrom(FileChannel fileChannel, long position, long count) throws IOException {

 return fileChannel.transferTo(position, count, socketChannel);

}

注： transferTo和transferFrom并不保证一定能使用零拷贝。实际上是否能使用零拷贝与操作系统相关，如果操作系统提供sendfile这样的零拷贝系统调用，则这两个方法会通过这样的系统调用充分利用零拷贝的优势，否则并不能通过这两个方法本身实现零拷贝。

减少网络开销

批处理

批处理是一种常用的用于提高I/O性能的方式。对Kafka而言，批处理既减少了网络传输的Overhead，又提高了写磁盘的效率。

Kafka 0.8.1及以前的Producer区分同步Producer和异步Producer。同步Producer的send方法主要分两种形式。一种是接受一个KeyedMessage作为参数，一次发送一条消息。另一种是接受一批KeyedMessage作为参数，一次性发送多条消息。而对于异步发送而言，无论是使用哪个send方法，实现上都不会立即将消息发送给Broker，而是先存到内部的队列中，直到消息条数达到阈值或者达到指定的Timeout才真正的将消息发送出去，从而实现了消息的批量发送。

Kafka 0.8.2开始支持新的Producer API，将同步Producer和异步Producer结合。虽然从send接口来看，一次只能发送一个ProducerRecord，而不能像之前版本的send方法一样接受消息列表，但是send方法并非立即将消息发送出去，而是通过batch.size和linger.ms控制实际发送频率，从而实现批量发送。

由于每次网络传输，除了传输消息本身以外，还要传输非常多的网络协议本身的一些内容（称为Overhead），所以将多条消息合并到一起传输，可有效减少网络传输的Overhead，进而提高了传输效率。

从零拷贝章节的图中可以看到，虽然Broker持续从网络接收数据，但是写磁盘并非每秒都在发生，而是间隔一段时间写一次磁盘，并且每次写磁盘的数据量都非常大（最高达到718MB/S）。

数据压缩降低网络负载

Kafka从0.7开始，即支持将数据压缩后再传输给Broker。除了可以将每条消息单独压缩然后传输外，Kafka还支持在批量发送时，将整个Batch的消息一起压缩后传输。数据压缩的一个基本原理是，重复数据越多压缩效果越好。因此将整个Batch的数据一起压缩能更大幅度减小数据量，从而更大程度提高网络传输效率。

Broker接收消息后，并不直接解压缩，而是直接将消息以压缩后的形式持久化到磁盘。Consumer Fetch到数据后再解压缩。因此Kafka的压缩不仅减少了Producer到Broker的网络传输负载，同时也降低了Broker磁盘操作的负载，也降低了Consumer与Broker间的网络传输量，从而极大得提高了传输效率，提高了吞吐量。

高效的序列化方式

Kafka消息的Key和Payload（或者说Value）的类型可自定义，只需同时提供相应的序列化器和反序列化器即可。因此用户可以通过使用快速且紧凑的序列化-反序列化方式（如Avro，Protocal Buffer）来减少实际网络传输和磁盘存储的数据规模，从而提高吞吐率。这里要注意，如果使用的序列化方法太慢，即使压缩比非常高，最终的效率也不一定高。

Kafka controller架构分析

2018-04-04T09:42:52.000Z

kafka在0.8版本前没有提供Partition的Replication机制，一旦Broker宕机，其上的所有Partition就都无法提供服务，而Partition又没有备份数据，数据的可用性就大大降低了。所以0.8后提供了Replication机制来保证Broker的failover。由于Partition有多个副本，为了保证多个副本之间的数据同步，有多种方案：

1.所有副本之间是无中心结构的，可同时读写数据，需要保证多个副本之间数据的同步
2.在所有副本中选择一个Leader，生产者和消费者只和Leader副本交互，其他follower副本从Leader同步数据
Replication

数据同步

1.所有副本之间是无中心结构的，可同时读写数据，需要保证多个副本之间数据的同步
2.在所有副本中选择一个Leader，生产者和消费者只和Leader副本交互，其他follower副本从Leader同步数据

第一种方案看起来可以对客户端请求进行负载均衡，但是由于要在多个副本之间互相同步数据，数据的一致性和有序性难以保证。而第二种方案看起来客户端连接的节点会少点，而且其他副本同步数据可能没有那么及时，但是在正常情况下，客户端只需要和Leader一个副本通信即可，而其他follower只需要和Leader同步数据。假设有一个Partition有5个副本，4个follower只需要各自和leader建立一条链路通信，而对于第一种方案，5个副本之间要两两通信，确保Partition的每个副本的数据都是一致的。所以第一种方案虽然提供了客户端的负载均衡，但是对于服务端的设计带来比较大的复杂性，而第二种方案虽然限制了客户端只能连接Partition的Leader Replica，但这种简洁的设计使得服务端更加健壮。

同步策略

存在Replication的目的是为了在Leader发生故障时，follower副本能够代替Leader副本继续工作，即新的Leader必须拥有原来的Leader提交过的所有消息，那么在任何时刻follower要保证和Leader比起来总是最新的，或者说follower要和leader的数据始终保持同步。

有两种策略保证副本和leader是同步的，primary-backup replication和quorum-based replication。这两种模式下都会选举一个副本作为leader，其他的副本都作为follower。所有的写请求都会经过leader，然后leader会将写传播给follower（kafka因为使用pull模式，所以是follower从leader拉取数据，不过总的来说，目的都是将leader的数据同步给所有的follower）。

使用基于quorum的复制方式（也叫做Majority Vote，少数服从多数），leader需要等待副本集合中大多数的写操作完成（大多数的概念是指一半以上）。如果一些副本当掉了，副本组的大小也不会发生变化，这就会导致写操作无法写到失败的副本上，就无法满足半数以上的限制条件。这种模式下，假设有2N+1个副本，在提交之前要确保有N+1个副本复制完消息，为了保证正确选出新的Leader，失败的副本数不能超过N个。因为在剩下的任意N+1个Replica里，至少有一个Replica包含有最新的所有消息。这种策略的缺点是：为了保证Leader选举的正常进行，它所能容忍的失败的follower个数比较少，如果要容忍N个follower挂掉，必须要有2N+1个以上的副本。

使用主备模式复制，leader会等待组（所有的副本组成的集合）中所有副本写成功后才返回应答给客户端。如果其中一个副本当掉了，leader会将它从组中删除掉，并继续向剩余的副本写数据。一个失败的副本在恢复之后如果能赶上Leader，leader就会允许它重新加入组中。kafka中这个组的概念就是Leader副本的ISR集合。这个ISR里的所有副本都跟上了Leader，只有ISR里的成员才有被选为Leader的可能。这种模式下对于N+1个副本，一个Partition能在保证不丢失已经提交的消息的前提下容忍N个副本的失败（只要有一个副本没有失败，其他失败了都没有关系）。比较Majority Vote和ISR，为了容忍N个副本的失败，两者在提交前需要等待的副本数量是一样的（ISR中有N+1个副本才可以容忍N个副本失败，而Majority Vote副本总数=2N+1，N+1个副本成功，才能容忍N个副本失败，所以需要等待的副本都是N+1个。这里的等待一般是将请求发送到N+1个副本后，要等待这些副本应答后才表示成功提交），但是ISR需要的总的副本数几乎是Majority Vote的一半（假设ISR中所有副本都能跟上Leader，则一共也之后N+1个副本，而Majority Vote则需要2N+1个副本）。

leader选举

Leader选举本质上是一个分布式锁，有两种方式实现基于ZooKeeper的分布式锁：

1.节点名称唯一性：多个客户端创建一个节点，只有成功创建节点的客户端才能获得锁
2.临时顺序节点：所有客户端在某个目录下创建自己的临时顺序节点，只有序号最小的才获得锁

Majority Vote的选举策略和ZooKeeper中的Zab选举是类似的，实际上ZooKeeper内部本身就实现了少数服从多数的选举策略。kafka中对于Partition的leader副本的选举采用了第一种方法：为Partition分配副本，指定一个ZNode临时节点，第一个成功创建节点的副本就是Leader节点，其他副本会在这个ZNode节点上注册Watcher监听器，一旦Leader宕机，对应的临时节点就会被自动删除，这时注册在该节点上的所有Follower都会收到监听器事件，它们都会尝试创建该节点，只有创建成功的那个follower才会成为Leader（ZooKeeper保证对于一个节点只有一个客户端能创建成功），其他follower继续重新注册监听事件。

副本放置策略

kafka将一个逻辑意义的topic分成多个物理意义上的partition，每个partition是这个topic的一部分消息，将partition分布在多个brokers上，可以达到负载均衡的目的。除了Partition的分配，每个Partition都有Replcias，所以也要考虑Replica的分配策略，因为不能把一个Partition的所有Replicas都放在同一台机器上。一般我们希望将所有的Partition能够均匀地分布在集群中所有的Brokers上。Kafka分配Replica的算法如下：

将所有存活的N个Brokers和待分配的Partition排序
将第i个Partition分配到第(i mod n)个Broker上，这个Partition的第一个Replica存在于这个分配的Broker上，并且会作为partition的优先副本
将第i个Partition的第j个Replica分配到第((i + j) mod n)个Broker上

假设集群一共有4个brokers，一个topic有4个partition，每个Partition有3个副本。下图是每个Broker上的副本分配情况。

Follower failure

如果Follower Replica失败超过一定时间后，Leader会将这个失败的follower从ISR中移除（follower没有发送fetch请求）。由于ISR保存的是所有全部赶得上Leader的follower replicas，失败的follower肯定是赶不上了。虽然ISR现在少了一个，但是并不会引起的数据的丢失，ISR中剩余的replicas会继续同步数据（只要ISR中有一个follower，就不会丢失数据，实际上leader replica也是在ISR中的，所以即使所有的follower都挂掉了，只要leader没有问题，也不会出现问题的）。

当失败的follower恢复时，它首先将自己的日志截断到上次checkpointed时刻的HW（checkpoint是每个broker节点都有的）。因为checkpoint记录的是所有Partition的hw offset。当follower失败时，checkpoint中关于这个Partition的HW就不会再更新了。而这个时候存储的HW信息和follower partition replica的offset并不一定是一致的。比如这个follower获取消息比较快，但是ISR中有其他follower复制消息比较慢，这样Leader并不会很快地更新HW，这个快的follower的hw也不会更新（leader广播hw给follower）。这种情况下，这个follower日志的offset是比hw要大的。所以在它恢复之后，要将比hw多的部分截掉，然后继续从leader拉取消息（跟平时一样）。实际上，ISR中的每个follower日志的offset一定是比hw大的。因为只有ISR中所有follower都复制完消息，leader才会增加hw，而每个Replica复制消息后，都会增加自己的offset。也就是说有可能有些follower复制完了，而有另外一些follower还没有复制完，那么hw是不会增加的。

Kafka的Replica实现到目前0.9版本为止，分别经历了三个阶段：

阶段	主要做法	优缺点
1	zookeeper，很多监听器	脑裂，羊群效应，ZK集群负载过重
2	one brain，zk queue	将Replcia改变的状态事件用ZK队列实现
3	state machine，controller, direct rpc	直接RPC更快，状态机统一处理

zk path & listeners

下表汇总了zk中和partition相关的节点，对于不同版本，路径可能不同，不过要存储的信息都是类似的：

zookeeper path	type and creator	value
v1
/brokers/ids/[broker_id]–>host:port	临时节点,admin	所有存活的Brokers的信息
/brokers/topics/[topic]/[partition_id]/replicas–>{broker_id …}	admin	每个Partition当前分配的Replicas(AR)
brokers/topics/[topic]/[partition_id]/leader–>broker_id	临时节点,leader	这个partition的当前leader副本
/brokers/topics/[topic]/[partition_id]/ISR–>{broker_id, …}	leader	保持和leader同步的replica编号
v2
/brokers/topics/[topic]/[partition_id]/leaderAndISR–> {leader:broker_id,ISR:{broker1..}}	controller,leader	Partition的Leader和ISR
v3
/brokers/topics/[topic]–>{part1: [broker1, broker2]…}	admin	topic中所有Partition的AR
/brokers/topics/[topic]/[partition_id]/state–> {leader:broker_id,ISR:{broker1..}}	controller,leader	Partition的状态信息类似leaderAndISR
/controller –> {brokerid}	controller	当前集群的controller节点
common
/admin/partitions_reassigned/[topic]/[partition_id]–>{broker_id …}	admin	重新分配partition
/admin/partitions_add/[topic]/[partition_id]–>{broker_id …}	admin	新添加partition对应的AR
/admin/partitions_remove/[topic]/[partition_id]	admin	删除topic中已经存在的partition

在v2版本中，Partition重新分配的监听器只注册在leader的Broker上，而Leader和State变化的监听器注册在所有Broker上。一个Partition的多个Replica会分布在多个Broker上，只有在Leader Replica的Broker上才注册Partition-Reassigned监听器。而Leader和State变化对于Partition的所有副本都要能够感知，所以一个Partition所有Replica分布的Broker都要注册Leader-change和State-change监听器。

Broker,Partition和Replica的事件流

Partition的Replica存储在Broker上，并且和ZooKeeper互相交互，主要完成这些工作：

1.Broker启动读取ZK中Partition的所有AR
2.每个Replica判断Leader是否存在，不存在则进入选举阶段，存在则使自己成为Follower
3.每个Replica都会在leader上注册监听器，当Leader发生变化时，所有Replica会开始选举Leader
4.选举Leader时，最先创建leader节点的Replica成为Leader，其他Replica再次成为Follower

v1版本对于每个replica变化都会触发replicaStateChange调用。

v1版本中，由于各种事件严重依赖ZooKeeper，存在着以下问题：

脑裂：虽然ZooKeeper能保证注册到节点上的所有监听器都会按顺序被触发，但并不能保证同一个时刻所有副本看到的状态是一样的，可能造成不同副本的响应不一致
羊群效应：如果宕机的那个Broker的Partition数量很多，会造成多个Watch被触发，引起集群内大量的调整
每个副本都要在ZK的Partition上注册Watcher，当集群内Partition数量很多时，会造成ZooKeeper负载过重

v2版本不再为replicas注册Replica变化的事件，而是放到broker级别的状态变化事件。而且v2的startReplica和v1的replicaStateChange功能是相似的，都是完成replicas发生变化时判断是否需要选举或成为follower。

所有的brokers只对状态变化事件进行响应，而且状态变化事件也只由Leader决定，状态变化是通过onPartitionsReassigned写到zk的/brokers/state/[broker_id]的请求事件队列触发的，而这个事件只注册在Partition的Leader Replica上。也就是说follower状态的改变只基于partition的Leader发送请求时才会发生，如果leader没有对某个follower说要改变状态，则follower是不会有任何事件发生的，这种方式类似于事件驱动的模式（引入了一个中间的状态机）。而第一版中任何一个replica改变，都有可能导致所有其他follower都要做出相应（直接触发）。

注意：replicas的状态变化通过队列的形式并不会立即被触发，而leader变化事件要能立即被触发，所以要给这个事件单独注册Leader-Change监听器，而不能统一都放在State-Change监听器里，否则的话，leader变化事件可能会淹没在replicas的状态变化事件里，而没有被及时地处理（Leade变化这个事件是大BOSS发话，要立即执行，replicas的状态变化是其他领导发话，要进行排期依次处理）。

在这两个版本中，Partition都有一个commitQ队列用来缓存生产请求，并且每个Partition都有一个commit线程负责将消息写到Leader的本地日志中，并等待ISR中所有副本复制。Follower会向Leader抓取数据来保持和Leader的消息同步。

在Follower向Leader抓取数据时，要根据Follower的抓取进度判断是否应该把它加入ISR或从从ISR中移除：

maybe_change_ISR() {
 // 如果follower太慢会被leader从ISR中移除,确保leader可以顺利提交消息尽管isr的副本数变少了
 find the smallest leo (leo_min) of every replica in ISR
 if ( leader.leo - leo_min > MAX_BYTES_LAG || 
 the replica with leo_min hasn't updated leo for more than MAX_TIME_LAG)
 newISR = ISR - replica with leo_min
  
 //如果follower赶上了leader,加入到ISR中
 for each replica r not in ISR
 if ( r.leo - leo_min 
 newISR = ISR + r
  
 update the LeaderAndISR path in ZK with newISR
 if (update in ZK successful) {
 leader.partition.ISR = new ISR
 }
}

Controller要解决的问题

Replication的v3版本采用Controller实现，相比v2版本的主要不同点是：

Leader的变化从监听器改为由Controller管理
控制器负责检测Broker的失败，并为每个受影响的Partition选举新的Leader
控制器会将每个Leader的变化事件发送给受影响的每个Broker
控制器和Broker之间的通信采用直接的RPC，而不是通过ZK队列

虽然因为引入了Controller，需要实现Controller的failover。但它的优点有：

因为Leader管理被更加集中地管理，比较容易调试问题
Leader变化针对ZK的读写可以批量操作，减少在failover过程中端到端的延迟
更少的ZooKeeper监听器
使用直接RPC协议相比队列实现的ZK，能够更加高效地在节点之间通信

从整个集群的所有Brokers中选举出一个Controller，它主要负责：

Partition的Leader变化事件
新创建或删除一个topic
重新分配Partition
管理分区的状态机和副本的状态机

当控制器完成决策之后（决定了Partition新的Leader和ISR），它会将这个决策持久化到ZK中（将LeaderAndISR写入到ZK节点），并且向所有受到影响的Brokers通过直接RPC的形式直接发送新的决策（发送LeaderAndISRRequest）。这些决策（持久化到ZK中的数据）是真理之源，它们会被客户端用来路由请求（客户端只跟决策信息里的Leader交互），并且每个Broker启动的时候会用来恢复它的状态（Partition分配到Broker上，说明Broker现在拥有了分配到的Partition）。当Broker启动之后，它会接收控制器通过直接RPC的形式发送过来的最新的决策。

每个KafkaServer中都会创建一个KafkaController对象，但是集群中只允许存在一个Leader Controller，这是通过ZooKeeper选举出来的：第一个成功创建zk节点的那个Controller会成为Leader，其他的Controller会一直存在，但是并不会发挥作用。只有当原先的Controller挂掉后，才会选举出新的Controller。集群中所有Brokers选举一个Controller和Partition中所有Replicas选举一个Leader是类似的。有点类似于Hadoop-1.x中的SecondaryNameNode：同时启动NameNode和SecondaryNameNode，当NameNode挂掉后，SecondaryNameNode会代替成为NameNode角色。在系统运行过程中，SecondaryNameNode要同步NameNode的数据，这样在NameNode发生故障时，SecondaryNameNode切换为NameNode时数据并不会丢失或落后太多。Hadoop-2.x的HA使用了ZKFailoverController有两个Master：Active和Standby，工作原理和SNN是类似的，只不过Active Master将信息写入共享存储，Standby从共享存储中读取信息，保持与Active Master的同步，从而减少故障时的切换时间。不过KafkaController的failover机制并不会在系统运行过程中将其他所有Controller实例的数据和Leader同步，而是在Leader发生故障时重新选举，并且重新恢复数据。

原先在没有Controller时，Leader或者Replica的变化都是通过监听器完成的，现在引入Controller之后，不仅要处理Broker的failover，也要处理Controller的failover。Broker和Controller的failover也是通过注册在ZK上的Watcher监听器完成的，所有的Brokers监听一个Controller，Controller也监听所有的Controller，两者互相关注。

Broker Failover：on_broker_change

Broker失败，Controller注册在/brokers/ids的Watcher会触发调用onBrokerFailure。失败的Broker上的Replica可能是某个Partition的Leader也可能是某个Partition的follower。如果是Partition的Leader，那么Controller要确保有其他Broker成为这个Partition的Leader，如果是Partition的Follower，虽然不需要重新选举Leader，但是有可能Partition的ISR会变化。所以Controller首先会读取ZK中的ISR/AR选举新的Leader和ISR，然后把这个信息先保存到ZK中，最后把包含了新Leader和ISR的LeaderAndISR指令发送给受到影响的Brokers。收到指令的Broker如果Controller命令它成为某个Partition的Leader，那么原先为Follower副本的Replica就会becomeLeader。下面举个例子说明这个过程：

Partition1有三个副本：Replica1，Replica2，Replica3。其中Replica1是Leader，ISR=[1,2,3]
Replica1所在的Broker1挂掉了（现在Partition没有了Leader），Controller触发onBrokerFailure
Controller读取ZK的leaderAndISR，选举出新的leader和ISR。Leader=Replica2，ISR=[2,3]
Controller将最新的leaderAndISR写到ZK中（leader=Replica2，ISR=[2,3]）
Controller将最新的leaderAndISR构造成LeaderAndISRRequest发送给Broker2，Broker3
Replica2所在的Broker2收到指令，因为最新的leader指示Replica2是Leader，所以Replica2成为Partition1的Leader
Replica3所在的Broker3收到指令，Replica3仍然是follower，并且在ISR中，becomeFollower

Broker失败后Controller端的处理步骤如下：

从ZK中读取现存的brokers
broker宕机，会引起partition的Leader或ISR变化，获取在在这个broker上的partitions：set_p
对set_p的每个Partition P
3.1 从ZK的leaderAndISR节点读取P的当前ISR
3.2 决定P的新Leader和新ISR（优先级分别是ISR中存活的broker，AR中任意存活的作为Leader）
3.3 将P最新的leader，ISR，epoch回写到ZK的leaderAndISR节点
将set_p中每个Partition的LeaderAndISR指令（包括最新的leaderAndISR数据）发送给受到影响的brokers

最后一步采用发送指令的方式实际上是一种RPC请求，之前的版本中采用的是在ZK的leader节点注册监听器来监控leader的变化，不过我们已经看到了这种方式会使得ZK的负载过重，而使用RPC的方式可以在不依赖ZK的情况下同样可以处理leader的变化。

如何决定P的新Leader和新ISR？

假设AR=[1,2,3,4,5]，ISR=[1,2,3]，但是存活的Brokers=[2,3,5]。选择Leader的方式是ISR中目前存活的Brokers，比如目前存活的Broker是[2,3,4]，所以ISR中的副本1是不能作为Leader的，也不会再作为ISR了。Leader的选举是选举目前还存活的[2,3]中的一个，ISR的选举是选举在ISR中当前仍然存活的Broker=[2,3]。所以最后Leader=2，ISR=[2,3]。

假设AR=[1,2,3,4,5]，ISR=[1,2,3]，但是存活的Brokers=[4,6,7]。因为ISR中没有一个Broker在当前处于存活状态，所以只能退而求其次从AR中选择，幸运的是AR中的4目前是存活的，所以Leader=4，ISR=[4]。由于4不再ISR中，所以这种情况有可能会造成数据丢失，因为只有选举处于ISR中的，才不会丢失数据，但是现在ISR中的没有一个存活，所以也只好选择有可能丢失的Broekr，总比找不到任何的Broker要好吧。

什么叫做受到影响的brokers？

Partition有多个Replicas，Replica是分布在Broker上的物理表示，所以一个Broker上受到影响的Replica的Partition肯定还有其他副本分布在其他Broker上，所有含有宕机Broker的Partition的节点都是受到影响的brokers。假如Broker1上有三个Partition，这些Partition有些是Leader（p1）有些则是Follower（p2，p3），如果是Leader，则受影响的brokers要负责选出这个Replica对应的Partition的新Leader；如果是follower，也有可能影响了Partition的ISR，所以Leader要负责更新ISR。

创建或删除topics：on_topic_change

新创建一个topic，会同时指定Partition的个数，每个Partition都有AR信息写到ZK中
为新创建的set_p 每个Partition P初始化leader：
2.1 选择AR中的一个存活的Broker作为新Leader，ISR=AR
2.2 将新Leader和ISR写到ZK的leaderAndISR节点
发送LeaderAndISRCommand给受到影响的brokers
如果是删除一个topic，则发送StopReplicaCommand给受影响的brokers

Controller会在/brokers/topics上注册Watcher，所以有新topic创建/删除时，Controller会通过Watch得到新创建/删除的Topic的Partition/Replica分配。对于新创建的Topic，分配给Partition的AR中所有的Replica都还没有数据，可认为它们都是同步的，也即都在ISR中（ISR=AR），任意一个Replica都可作为Leader。

创建或删除topic的过程和onBrokerFailure类似都要经过三个步骤：1) 选举Leader和ISR；2) 将leaderAndISR写到ZK中；3) 将最新leaderAndISR的LeaderAndISR指令发送给受到影响的Brokers。这是因为brokerChange导致Partition的Leader或者ISR发生变化，而新创建topic时，根本就没有Leader和ISR，所以两者都需要为Partition选择Leader和ISR。

Broker处理Controller发送的Command**

on_LeaderAndISRCommand

读取命令中的set_P
对每个partition P
2.1 如果P在本地不存在，调用startReplica()创建一个新的Replia
2.2 指令要求这个Broker成为P的新Leader，调用becomeLeader
2.3 指令要求这个Broker作为Leader l的follower，调用becomeFollower
如果指令中有INIT标记，则删除不在set_p中的所有本地partitions

对于新创建的Partition，由于Replica都还没有在Broker上被创建，所以有可能指令中Partition的本地文件不存在，就需要新创建一个Replica。而如果是Broker失败发送过来的LeaderAndISRCommand，则一般受到影响接收LeaderAndISRCommand指定的Broker是有存在Replica的，那么指令里就会要求这个Broker上的副本要么成为Leader，要么成为Follower。比如上面A的图例中，Broker1宕机，其上的p1副本是Leader，现在集群中p1没有leader了，因此指令就会要求broker2的p1副本由原先的follower要转变为Leader了。

becomeLeader指的是当前接收LeaderAndISRCommand指令的Broker，原先是一个follower，现在要转变为Leader。由于作为Follower期间，它会从Leader抓取数据，而现在Leader不在了，所以首先要停止抓取数据线程。follower转变为Leader之后，要负责读写数据，所以要启动提交线程负责将消息存储到本地日志文件中。

becomeLeader(r: Replica, command) {
 stop the ReplicaFetcherThread to the old leader
 //after this, no more messages from the old leader can be appended to r
 r.partition.ISR = command.ISR
 r.isLeader = true //enables reads/writes to this partition on this broker
 start a commit thread on r
}

注意有可能新leader的HW会比之前的leader的HW要落后，这是因为新leader有可能是ISR，也有可能是AR中的replica。而原先作为Follower的replica，它的HW只会在向Leader发送抓取请求时，Leader在抓取响应中除了返回消息也会附带自己的HW给follower，Follower收到消息和HW后，才会更新自己的replica的HW，这中间有一定的时间间隔会导致Follower的HW会比Leader的HW要低。因此Follower在转变为Leader之后，它的HW是有可能比老的Leader的HW要低的。如果在leader角色转变之后，一个消费者客户端请求的offset可能比新的Leader的HW要大（因为消费者最多只消费到Leader的HW位置，但是消费者并不关心Leader到底有没有变化，所以如果旧的Leader的HW=10，那么客户端就可以消费到offset=10这个位置，而Leader发生转变后，HW可能降低为9，而这个时候客户端继续发送offset=10，就有可能比Leader的HW要大了！）。这种情况下，如果消费者要消费Leader的HW到LEO之间的数据，Broker会返回空的集合，而如果消费者请求的offset比LEO还要大，就会抛出OffsetOutofRangeException（LEO表示的是日志的最新位置，HW比LEO要小，客户端只能消费到HW位置，更不可能消费到LEO了）。

对于要转变为Follower的replica，原先如果是Leader的话，则要停止提交线程，由于当前Replica的leader可能会发生变化，所以在开始时要停止抓取线程，在最后要新创建到Replica最新leader的抓取线程，这中间还要截断日志到Replica的HW位置。

becomeFollower(r: Replica) {
 stop the ReplicaFetcherThread to the old leader 
 r.isLeader = false 
  //disables reads/writes to this partition on this broker
 stop the commit thread, if any
 truncate the log to r.hw
 start a new ReplicaFetcherThread to the current leader of r, from offset r.leo
}

startReplica表示启动一个Replica，如果不存在Partition目录，则创建。并启动Replica的HW checkpoint线程，我们已经知道了Follower的HW是通过发送抓取请求，接收应答中包含了Leader的HW，设置为Follower Replica的HW（而Leader的HW又是由ISR提交来决定的，所以说ISR决定了HW能够增加，而Follower的HW则来自于Leader的HW）。

startReplica(r: Replica) {
 create the partition directory locally, if not present
 start the HW checkpoint thread for r
}

下表是Broker收到LeaderAndISR指令后的动作，角色变化，以及线程的变化：

action	state transition	thread
startReplica	new replica	start HW checkpoint
becomeFollower	leader to follower	stop commit thread,start fetch thread
becoleLeader	follower to leader	stop fetch thread,start commit thread

on_StopReplicaCommand

Replica既然可以start，也可以被stop掉，即通过StopReplicaCommand指令要求Broker停止掉Replica。

从指令中读取partitions集合
对每个partition P的每个Replica ，调用stopReplica
2.1 停止和r关联的抓取线程（当然针对的是Follower Replica）
2.2 停止r的HW checkpoint线程
2.3 删除partition目录

Controller Failover：on_controller_failover

由于Controller是从Brokers中选举出来的，所以Controller所在的节点也会作为Partition的存储节点的。当Controller挂掉后，Controller本身作为Broker也会触发新的Controller调用on_broker_change。但是在还没有选举出新的Controller之前，挂掉的Broker的on_broker_change不会被新的Controller调用（因为根本就没有可用的Controller）。所以对于挂掉的Controller节点，最紧迫的任务是首先选举出新的Controller，然后再由新的Controller触发挂掉的那个Controller的on_broker_change。

还有一点Broker失败和Controller失败是不同的：Broker的failover是在Controller端处理的，因为我们知道Broker挂掉了，Controller负责在挂掉Controller和受影响的Broker之间更新数据（将新的leaderAndISR发送给受影响的Broker）。而Controller的failover则是在Broker处理的（成功创建Controller的那一个Broker）。实际上理解起来也很简单，任何角色A会在ZK上注册节点信息，并有另外的角色B负责监听，当角色A挂掉后，会由节点的监听器B处理A的failover。

因为Controller是集群中各种事件状态变化的中央控制器，比如Controller负责将LeaderAndISRCommand/StopReplicaCommand指令发送给集群中的brokers。因为Controller存在的作用就是负责处理某个Broker的事件变化，转换为请求，发送给其他的Broker，而Broker之间是不需要直接通信的。因此如果Controller这个大脑发生故障了，那么就等于各个Broker之间无法通信了。举个例子公司中开发某个项目并不需要所有人都围坐在一起从方案到需求到设计，通常在不同阶段有不同的人开不同的会议，不过每个会议都要求有一个项目组长（Controller）参与。在需求会议，项目组长收集需求人员的需求（源事件），项目组长整理需求后，在设计会议上，他会召集开发人员进行设计评审并分配不同的任务给不同的开发人员（由Controller分配任务给不同的Broker），可是有一天项目组长请假了，需求人员和开发人员就不知道如何通信了，因为他们之间的媒介无法连接了。那么怎么办呢，可以引入一个共享存储ZooKeeper：Controller将状态改变的事件都存储在ZooKeeper上确保数据不会丢失，这样即使Controller挂掉了，在新的Controller掌权之后，也能够从ZooKeeper中读取出所有事件，这种方式跟v2版本的Replica设计中ZK的state change队列（存储的是每个broker的state change requests）是类似的。但是真的需要为此再引入ZKQueue吗？实际上只要Controller节点保存的数据是无状态的，那么切换新的Controller之后能够恢复之前的集群状态信息就无需引入ZK队列。

创建/controller->当前broker_id的ZK节点，如果不成功则返回，表示竞选失败
读取ZK中每个Partition的leaderAndISR节点数据
对每个Partition都发送LeaderAndISRCommand（带上INIT标记位）给相关的Brokers
触发调用on_broker_change()
对没有leader的Partition，调用init_leaders(set_p)，这里跟创建topic时类似
调用on_partitions_reassigned()重新分配Partition
调用on_partitions_add()创建Partition
调用on_partitons_remove()删除Partition

第一步创建/controller节点，监听了这个节点的所有brokers都想要创建，但是只有一个Broker节点才能创建成功。on_controller_failover表示之前的Controller已经挂掉了，要在监听的broker并且成功创建/controller的节点处理旧的controller的failover（故障转移处理）。Controller挂掉时，它之前创建的/controller会被自动删除掉（并不在这个方法里处理，而是由ZK在controller进程挂掉时自动删除），所以就让其他一直默默潜水的brokers有机会成为新的Controller。

Broker Startup：on_broker_startup

由于broker不管是启动还是发生故障，都会操作ZK中的/brokers/ids节点，而Controller牢牢地监控了这个节点的变化情况。当Broker刚启动时（这里指的是failover中的startup，如果说启动一个全新的broker，它上面是没有Replica的，而failover是之前存在Replica，发生故障后恢复过来的startup上面仍然有Replica的），为了让它所拥有的Replica能够正常提供服务，需要startReplica，同时其上的每个Replica要么成为Leader，要么成为Follower。

在on_broker_change里，Controller会将失败Broker上的Partition的指令发送给受影响的brokers（肯定不能发送给失败的Broker了），收到指令的brokers会对自己所拥有的Replica判断是否成为Leader或者Followr。而on_broker_start则是Controller直接处理刚刚启动的Broker。即on_broker_start是通过监听器直接处理，而on_broker_change是通过Controller发送命令给brokers处理，对于Broker而言都是针对Partition的Replica在Leader和Follower之间进行角色转换操作。

读取ZK中topic路径下每个topic所有Partition的AR（和partition路径的AR功能类似）
读取ZK中分配给当前启动的Broker的每个Partition的leader和ISR（leaderAndISR）
对分配给当前Broker的每个Replica
3.1 start replica
3.2 这个Broker是这个Partition的leader，becomeLeader
3.3 这个Broker是这个Partition的follower，becomeFollower
删除不再分配给当前Broker的本地Partitions

最后一步Broker在启动的时候需要删除不属于自己的partitions。这种场景可能是在这个broker当掉的时候，属于这个broker的topic被删除后又立马被重新创建。在删除topic的时候，所有broker都应该把这个topic的所有partition都删除掉，但是如果broker挂掉了，是无法进行任何操作的。在重新创建topic的时候，也不会将partition分配给当掉的broker，而只是分配partition给其他存活的broker。所以当掉的broker恢复正常后，应该把在删除topic时候的那些partition都删除掉。尽管又重新创建了topic，但是当掉broker上的partition是不能作为新创建的topic的partitions的，因为在当掉期间ZK中根本就不会记录属于当掉broker的partition分配信息。

讨论

broker失败期间端到端的延迟

broker关闭(关闭socket server后，需要关闭请求处理器和log)
controller上的broker监听器被触发
controller负责leadership变更，将新leader和isr发布到zk（每个受影响的partition都写一次zk）
通过写到ZKQueue中通知每个broker leadership变化(每个broker写一次关于leader变化事件的zk)
新leader等待isr中的follower成功连接上(Kafka RPC)
follower首先截断日志，然后开始从leader抓取数据

端到端的延迟指的是从Producer提交消息到这条消息被Consumer/Follower消费到的时间间隔。最耗时的是步骤三：对每个partition都要将新的leaderAndISR写一次zk。假设在broker发生故障时需要为10K个partition改变leader，每次zk写花费4ms，则总共会花费40s。不过可以使用zk中的multi()将所有Partition的写操作用批处理就只需要一次写。

步骤四中：controller会将最新的leadershipi变化事件通知给每个broker。在Replica的版本2中对于state change事件则采用队列的形式，对于leader的变化事件是通过监听器的方式通知注册在leader的所有broker节点。现在由于leader的管理交给了Controller，所以可以使用直接RPC代替监听器和队列。

ZKQueue vs 直接RPC

通过ZK完成Controller和brokers的通信是非常低效的，因为每次通信都需要2次ZK写（每个写操作花费2个RPC），一次监听器的触发（写之后数据改变触发监听器调用），一次ZK读（监听器要获取最新的写操作结果），所以对于一次通信就花费了6次RPC（2*2+1+1=6，RPC指的是在不同节点之间的通信，controller和brokers是在不同节点上，需要通过RPC通信才能读写数据）。

如果controler和所有的brokers之间为了能够直接通信，在Broker端实现一个admin RPC，那么每次通信只需要一个RPC。使用RPC意味着当一个broker当掉后，它可能会丢失一些来自Controller的命令，所以在broker启动时它需要读取zk中保存的状态信息来恢复自己的状态。

如何处理多个leader?

存在这样一种情况：有多个broker同时声称自己是某个partition的leader副本。比如broker A是partition的初始Leader，partition的ISR是{A,B,C}。然后broker A因为GC失去它在ZK中的注册信息。这时controller会认为broker A当掉了，并将partition的leader分配给了broker B，设置新的ISR为{B,C}，并写到ZK中（每次partition的leader发生变化，epoch也会增加）。在broker B成为leader的同时，broker A从GC中恢复过来，但是还没有收到controller发送的leadershipi变化指令。现在broker A和B都认为自己是leader，如果我们允许broker A和B能同时提交消息那就非常不幸了，因为所有副本之间的数据同步就会不一致了。不过当前的设计中实际上是不会允许出现这种情况的：当broker B成为leader之后，broker A是无法再提交任何新的消息的。

假设允许存在两个leader，生产者会同时往这两个leader写数据，但是能不能提交消息就类似于两阶段提交协议了：kafka的leader要能够提交一个消息的保证是ISR中的所有副本都复制成功。对于broker A为了保证能投提交消息m，它需要ISR中的每个副本（A,B,C）都要接收到消息m，而这个时候broker A仍然认为ISR是{A,B,C}，（这是broker A的一份本地拷贝，虽然这个时候ZK中的ISR已经被broker B改变了），但是ISR中的broker B是不会再接收到消息m的。因为在broker B成为Leader的时候，它会首先关掉到之前旧的broker A的数据抓取线程（broker B之前是follower，会向leader抓取数据，只有follower抓取数据，leader才能判断消息是否能提交），因为broker B的抓取线程被关闭了，broker A可能会认为B无法赶上Leader，既然因为B受到影响不能提交消息m，broker A干脆就想要把B从ISR中移除，这个时候broker A要将自己认为的最新的ISR写到ZK中。不过不幸的是broker A并不能完成这个操作：因为在写ZK的时候broker A会发现自己的epoch版本和ZK中的当前值并不匹配（broker B在选举为Leader之后会写到ZK中，并将epoch增加1，任何新的写操作的epoch都不能比当前epoch小），直到这个时刻，broker A才意识到它已经不再是partition的leader了（举个例子：一个团伙中大领导A突然消失了一段时间，众人在这段时间里选举出了新的领导B，并且向所有的成员都发话了，只有B的指令是管用的。在A回来时，没有人告诉他B已经成功上位，A还傻傻地认为自己还是最高BOSS，不过当他要发布指令的时候，发现每个人的指令只接受B的了，这时A才意识到MD自己已经被踢出局了）。

broker故障客户端如何路由

controller首先将受影响的partitions的新leader写到zk的leaderAndISR节点，然后才会向brokers发送leader改变的命令，brokers收到命令后会对leader改变的事件作出响应。由于客户端请求会使用leaderAndISR的数据来连接leader所在的节点，客户端的请求被路由到新leader所在的broker节点，但如果那个broker还没有准备好成为leader，就存在一个时间窗口对于客户端而言是不可用的。HBase只在regionserver响应了打开或关闭region的命令之后才更新元数据（这个元数据也用来响应客户端的请求，即客户端可以读取哪些region），而kafka这里则是controller先更新元数据（写入leaderAndISR）后才发送命令给broker，因此可能元数据已经更新，但是broker还没收到命令，或者收到命令后还没准备好成为leader。

所以可能你会认为不要让controller先更新leaderAndISR节点，而是发送指令给brokers，每个broker在收到指令并处理完成后才，让每个broker来更新这个节点的数据。不过这里让controller来更新leaderAndISR节点是有原因的：我们是依赖ZK的leaderAndISR节点来保持controller和partition的leader的同步。当controller选举出新的leader之后，它并不希望ISR（新leader的ISR）被当前的leader（旧的leader）改变。否则的话（假设ISR可以被旧leader改变），新选举出来的leader在接管正式成为leader之前可能会被当前leader从ISR中剔除出去。通过立即将新leader发布到leaderAndISR节点，controller能够防止当前leader更新ISR（选举新的leader在写到ZK时，epoch增加，而如果当前leader想要更新ISR比如将新选举的leader从ISR中剔除掉，因为epoch不匹配，所以当前leader就不再有机会更新ISR了）。

一种方式是使用额外的ZK路径比如ExternalView来路由客户端请求解决这种短暂的不可用窗口。controller只会在broker响应leader改变的指令之后才更新ExternalView。对所有的partitions使用一个ExternalView或者每个partition都使用一个ExternalView各有利弊。前者对ZK有更少的负载，但是可能会强制客户端触发不必要的重新平衡。

正常情况下，leadership改变的指令会很快地被执行，所以在转换的这段时间里，我们可以依赖于客户端的重试机制，相对而言客户端的代价更小。即使broker成为新的leader花费了太长的时间，controller也会得到超时通知并触发一条告警信息通知admin。

leadership改变时，offset超过HW

通常情况下，follower的HW总是落后于leader的HW。所以在leader变化时，消费者发送的offset中可能会落在新leader的HW和LEO之间（因为消费者的消费进度依赖于Leader的HW，旧Leader的HW比较高，而原先的follower作为新Leader，它的HW还是落后于旧Leader，所以消费者的offset虽然比旧Leader的HW低，但是有可能比新Leader的HW要大）。如果没有发生leader变化，服务端会返回OffsetOutOfRangeException给客户端。但这种情况下如果请求的offset介于HW和LEO之间，服务端会返回空消息集给消费者。

小结

当前的KafkaController实现是多线程的控制器，并且模拟了状态机，它维护的状态有：

在每个节点上维护所有partitions的Replicas
所有partitions的Leaders

引起状态改变的输入事件有：

注册在ZooKeeper上的监听器
1) BrokerChangeListener（Broker挂掉）
2) DeleteTopicListener（删除Topic）
3) TopicChangeListener（更改Topic）
4) AddPartitionsListener（为Topic新增加Partition）
5) PartitionReassignedListener（Admin）
6) PreferredReplicaElectionListener（Admin）
7) ReassignedPartitionsIsrChangeListener
到brokers的连接通道（controller被关闭）
内部的调度任务（prefered leader选举）

Ref

https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Controller+Internals

Kafka controller 设计分析

2018-04-04T08:30:34.000Z

本文主要参考社区0.11版本Controller的重设计方案，试图给大家梳理一下Kafka controller这个组件在设计上的一些重要思考。众所周知，Kafka中有个关键组件叫controller，负责管理和协调Kafka集群。网上关于controller的源码分析也有很多，本文就不再大段地列出代码重复做这件事情了。实际上，对于controller的代码我一直觉得写的非常混乱，各种调用关系十分复杂，想要完整地理解它的工作原理确实不易。好在我们就是普通的使用者，大致了解controller的工作原理即可。下面我就带各位简要了解一下当前Kafka controller的原理架构以及社区为什么要在大改controller的设计。

Controller是做什么的

　　“负责管理和协调Kafka集群”的说法实在没有什么营养，上点干货吧——具体来说Controller目前主要提供多达10种的Kafka服务功能的实现，它们分别是：

UpdateMetadataRequest：更新元数据请求。topic分区状态经常会发生变更(比如leader重新选举了或副本集合变化了等)。由于当前clients只能与分区的leader broker进行交互，那么一旦发生变更，controller会将最新的元数据广播给所有存活的broker。具体方式就是给所有broker发送UpdateMetadataRequest请求
CreateTopics: 创建topic请求。当前不管是通过API方式、脚本方式抑或是CreateTopics请求方式来创建topic，做法几乎都是在Zookeeper的/brokers/topics下创建znode来触发创建逻辑，而controller会监听该path下的变更来执行真正的“创建topic”逻辑
DeleteTopics：删除topic请求。和CreateTopics类似，也是通过创建Zookeeper下的/admin/delete_topics/节点来触发删除topic，controller执行真正的逻辑
分区重分配：即kafka-reassign-partitions脚本做的事情。同样是与Zookeeper结合使用，脚本写入/admin/reassign_partitions节点来触发，controller负责按照方案分配分区
Preferred leader分配：preferred leader选举当前有两种触发方式：1. 自动触发(auto.leader.rebalance.enable = true)；2. kafka-preferred-replica-election脚本触发。两者“玩法”相同，向Zookeeper的/admin/preferred_replica_election写数据，controller提取数据执行preferred leader分配
分区扩展：即增加topic分区数。标准做法也是通过kafka-reassign-partitions脚本完成，不过用户可直接往Zookeeper中写数据来实现，比如直接把新增分区的副本集合写入到/brokers/topics/下，然后controller会为你自动地选出leader并增加分区
集群扩展：新增broker时Zookeeper中/brokers/ids下会新增znode，controller自动完成服务发现的工作
broker崩溃：同样地，controller通过Zookeeper可实时侦测broker状态。一旦有broker挂掉了，controller可立即感知并为受影响分区选举新的leader
ControlledShutdown：broker除了崩溃，还能“优雅”地退出。broker一旦自行终止，controller会接收到一个ControlledShudownRequest请求，然后controller会妥善处理该请求并执行各种收尾工作
Controller leader选举：controller必然要提供自己的leader选举以防这个全局唯一的组件崩溃宕机导致服务中断。这个功能也是通过Zookeeper的帮助实现的

Controller当前设计

　　当前controller启动时会为集群中所有broker创建一个各自的连接。这么说吧，假设你的集群中有100台broker，那么controller启动时会创建100个Socket连接(也包括与它自己的连接！)。当前新版本的Kafka统一使用了NetworkClient类来建模底层的网络连接(有兴趣研究源码的可以去看下这个类，它主要依赖于Java NIO的Selector)。Controller会为每个连接都创建一个对应的请求发送线程，专门负责给对应的broker发送请求。也就是说，如果还是那100台broker，那么controller启动时还会创建100个RequestSendThread线程。当前的设计中Controller只能给broker发送三类请求，它们是：

UpdateMetadataRequest：更新元数据
LeaderAndIsrRequest：创建分区、副本以及完成必要的leader和/或follower角色的工作
StopReplicaRequest：停止副本请求，还可能删除分区副本

　　Controller通常都是发送请求给broker的，只有上面谈到的controller 10大功能中的ControlledShutdownRequest请求是例外：这个请求是待关闭的broker通过RPC发送给controller的，即它的方向是反的。另外这个请求还有一个特别之处就是其他所有功能或是请求都是通过Zookeeper间接与controller交互的，只有它是直接与controller进行交互的。

Controller组成

构成controller的组件太多了，多到我已经不想用文字表达了，直接上图吧：

其中比较重要的组件包括：

ControllerContext：可以说是controller的缓存。当前controller为人诟病的原因之一就是用了大量的同步机制来保护这个东西。ControllerContext的构成如下图所示：

缓存内容十分丰富，这也是controller可以协调管理整个cluster的基础。

TopicDeletionManager：负责删除topic的组件
**Selector：controller提供的各种功能的leader选举器
**Listener：controller注册的各种Zookeeper监听器。想要让controller无所不能，必然要注册各种”触角” 才能实时感知各种变化

Controller当前问题

　　不谦虚地说，我混迹社区也有些日子了。在里面碰到过很多关于controller的bug。社区对于这些bug有个很共性的特点，那就是没有什么人愿意(敢去)改这部分代码，因为它实在是太复杂了。具体的问题包括：

1. 需要在多线程间共享状态

　　编写正确的多线程程序一直是Java开发者的痛点。在Controller的实现类KafkaController中创建了很多线程，比如之前提到的RequestSendThread线程，另外ZkClient也会创建单独的线程来处理zookeeper回调，这还不算TopicDeletionManager创建的线程和其他IO线程等。几乎所有这些线程都需要访问ControllerContext(RequestSendThread只操作它们专属的请求队列，不会访问ControllerContext)，因此必要的多线程同步机制是一定需要的。当前是使用controllerLock锁来实现的，因此可以说没有并行度可言。

2. 代码组织混乱

　　看过源代码的人相信对这一点深有体会。KafkaController、PartitionStateMachine和ReplicaStateMachine每个都是500+行的大类且彼此混调的现象明显，比如KafkaController的stopOldReplicasOfReassignedPartition方法调用ReplicaStateMachine的handleStateChanges方法，而后者又会调用KafkaController的remoteReplicaFromIsr方法。类似的情况还发生在KafkaController和ControllerChannelManager之间。

3. 管理类请求与数据类请求未分离

　　当前broker对入站请求类型不做任何优先级处理，不论是PRODUCE请求、FETCH请求还是Controller类的请求。这就可能造成一个问题：即clients发送的数据类请求积压导致controller推迟了管理类请求的处理。设想这样的场景，假设controller向broker广播了leader发生变更。于是新leader开始接收clients端请求，而同时老leader所在的broker由于出现了数据类请求的积压使得它一直忙于处理这些请求而无法处理controller发来的LeaderAndIsrRequest请求，因此这是就会出现“双主”的情况——也就是所谓的脑裂。此时倘若client发送的一个PRODUCE请求未指定acks=-1，那么因为日志水位截断的缘故这个请求包含的消息就可能“丢失”了。现在社区中关于controller丢失数据的bug大多是因为这个原因造成的。

4. Controller同步写Zookeeper且是一个分区一个分区地写

　　当前controller操作Zookeeper是通过ZkClient来完成的。ZkClient目前是同步写入Zookeeper，而同步通常意味着性能不高。更为严重的是，controller是一个分区一个分区进行写入的，对于分区数很多的集群来说，这无疑是个巨大的性能瓶颈。如果用户仔细查看源代码，可以发现PartitionStateMachine的electLeaderForPartition就是一个分区一个分区地选举的。

5. Controller按照一个分区一个分区的发送请求

　　Controller当前发送请求都是按照分区级别发送的，即一个分区一个分区地发送。没有任何batch或并行可言，效率很低。

6. Controller给broker的请求无版本号信息

这里的版本号类似于new consumer的generation，总之是要有一种机制告诉controller broker的版本信息。因为有些情况下broker会处理本已过期或失效的请求导致broker状态不一致。举个例子，如果一个broker正常关闭过程中“宕机”了，那么重启之后这个broker就有可能处理之前controller发送过来的StopReplicaRequest，导致某些副本被置成offline从而无法使用。而这肯定不是我们希望看到的结果，对吧？

7. ZkClient阻碍状态管理

Contoller目前是使用了ZkClient这个开源工具，它可以自动重建会话并使用特有的线程顺序处理所有的Zookeeper监听消息。因为是顺序处理，它就有可能无法及时响应最新的状态变更导致Kafka集群状态的不一致。

Controller改进方案

1. 单线程事件模型

和new consumer类似，controller摒弃多线程的模型，采用单线程的事件队列模型。这样简化了设计同时也避免了复杂的同步机制。各位在最新的trunk分支上已然可以看到这种变化：增加了ControllerEventManager类以及对应的ControllerEventThread线程类专门负责处理ControllerEvent。目前总共有9种controller event，它们分别是：

Idle
ControllerChange
BrokerChange
TopicChange
TopicDeletion
PartitionReassignment
AutoLeaderBalance
ManualLeaderBalance
ControlledShutdown
IsrChange

我们基本上可以从名字就能判断出它们分别代表了什么事件。

2. 使用Zookeeper的async API

　　将所有同步操作Zookeeper的地方都改成异步调用+回调的方式。实际上Apache Zookeeper客户端执行请求的方式有三种：同步、异步和batch。通常以batch性能最好，但Kafka社区目前还是倾向于用async替换sync。毕竟实现起来相对简单同时性能上也能得到不少提升。

3. 重构状态管理

可能摒弃之前状态机的方式，采用和GroupCoordinator类似的方式，让controller保存所有的状态并且负责状态的流转以及状态流转过程中的逻辑。当然，具体的实现还要再结合0.11最终代码才能确定。

4. 对请求排定优先级

　　对管理类请求和数据类请求区分优先级。比如使用优先级队列替换现有的BlockingQueue——社区应该已经实现了这个功能，开发了一个叫PrioritizationAwareBlockingQueue的类来做这件事情，后续大家可以看下这个类的源代码

5. 为controller发送的请求匹配broker版本信息

为broker设定版本号(generation id)。如果controller发送过来的请求中包含的generation与broker自己的generation不匹配，那么broker会拒绝该请求。

6. 抛弃ZkClient，使用原生Zookeeper client

ZkClient是同步顺序处理ZK事件的，而原生Zookeeper client支持async方式。另外使用原生API还能够在接收到状态变更通知时便马上开始处理，而ZkClient的特定线程则必须要在队列中顺序处理到这条变更消息时才能处理。

结语

以上就是关于Kafka controller的一些讨论，包括了它当前的组件构成、设计问题以及对应的改进方案。有很多地方可能理解的还不是透彻，期待着在Kafka 0.11正式版本中可以看到全新的controller组件

Spark 内存管理之UnifiedMemoryManager

2018-04-04T08:19:35.000Z

Spark的内存使用，大体上可以分为两类：Execution内存和Storage内存。在Spark 1.5版本之前，内存管理使用的是StaticMemoryManager，该内存管理模型最大的特点就是，可以为Execution内存区与Storage内存区配置一个静态的boundary，这种方式实现起来比较简单，但是存在一些问题：

没有一个合理的默认值能够适应不同计算场景下的Workload
内存调优困难，需要对Spark内部原理非常熟悉才能做好
对不需要Cache的Application的计算场景，只能使用很少一部分内存

为了克服上述提到的问题，尽量提高Spark计算的通用性，降低内存调优难度，减少OOM导致的失败问题，从Spark 1.6版本开始，新增了UnifiedMemoryManager（统一内存管理）内存管理模型的实现。UnifiedMemoryManager依赖的一些组件类及其关系，如下类图所示：

从上图可以看出，最直接最核心的就是StorageMemoryPool 和ExecutionMemoryPool，它们实现了动态内存池（Memory Pool）的功能，能够动态调整Storage内存区与Execution内存区之间的Soft boundary，使内存管理更加灵活。下面我们从内存布局和内存控制两个方面，来分析UnifiedMemoryManager内存管理模型。

内存布局

UnifiedMemoryManager是MemoryManager的一种实现，是基于StaticMemoryManager的改进。这种模型也是将某个执行Task的Executor JVM内存划分为两类内存区域：

Storage内存区
Storage内存，用来缓存Task数据、在Spark集群中传输（Propagation）内部数据。
Execution内存区
Execution内存，用于满足Shuffle、Join、Sort、Aggregation计算过程中对内存的需求。

这种新的内存管理模型，在Storage内存区与Execution内存区之间抽象出一个Soft boundary，能够满足当某一个内存区中内存用量不足的时候，可以从另一个内存区中借用。我们可以理解为，上面Storage内存和Execution堆内存是受Spark管理的，而且每一个内存区是可以动态伸缩的。这样的好处是，当某一个内存区内存使用量达到初始分配值，如果不能够动态伸缩，不能在两类内存区之间进行动态调整（Borrow），或者如果某个Task计算的数据量很大超过限制，就会出现OOM异常导致Task执行失败。应该说，在一定程度上，UnifiedMemoryManager内存管理模型降低了发生OOM的概率。

我们知道，在Spark Application提交以后，最终会在Worker上启动独立的Executor JVM，Task就运行在Executor里面。在一个Executor JVM内部，基于UnifiedMemoryManager这种内存管理模型，堆内存的布局如下图所示：

上图中，systemMemory是Executor JVM的全部堆内存，在全部堆内存基础上reservedMemory是预留内存，默认300M，则用于Spark计算使用堆内存大小默认是：

| maxHeapMemory = (systemMemory - reservedMemory) * 0.6 |

受Spark管理的堆内存，使用去除预留内存后的、剩余内存的百分比，可以通过参数spark.memory.fraction来配置，默认值是0.6。Executor JVM堆内存，去除预留的reservedMemory内存，默认剩下堆内存的60%用于execution和storage这两类堆内存，默认情况下，Execution和Storage内存区各占50%，这个也可以通过参数spark.memory.storageFraction来配置，默认值是0.5。比如，在所有参数使用默认值的情况下，我们的Executor JVM内存为指定为2G，那么Unified Memory大小为(1024 2 – 300) 0.6 = 1048MB，其中，Execution和Storage内存区大小分别为1048 * 0.5 = 524MB。

另外，还有一个用来保证Spark Application能够计算的最小Executor JVM内存大小限制，即为minSystemMemory = reservedMemory 1.5 = 300 1.5 = 450MB，我们假设Executor JVM配置了这个默认最小限制值450MB，则受Spark管理的堆内存大小为(450 – 300) 0.6 = 90MB，其中Execution和Storage内存大小分别为90 0.5 = 45MB，这种情况对一些小内存用量的Spark计算也能够很好的支持。

上面，我们详细说明了受Spark管理的堆内存（OnHeap Memory）的布局，UnifiedMemoryManager也能够对非堆内存（OffHeap Memory）进行管理。Spark堆内存和非堆内存的布局，如下图所示：

通过上图可以看到，非堆内存（OffHeap Memory）默认大小配置值为0，表示不使用非堆内存，可以通过参数spark.memory.offHeap.size来设置非堆内存的大小。无论是对堆内存，还是对非堆内存，都分为Execution内存和Storage内存两部分，他们的分配大小比例通过参数spark.memory.storageFraction来控制，默认是0.5。

内存控制

通过上面，我们了解了UnifiedMemoryManager这种内存管理模型的内存布局状况。接下来，我们看一下，通过UnifiedMemoryManager的API，如何对内存进行控制（分配/回收）。内存的控制，也对应于Execution内存与Storage内存，分别有一个StorageMemoryPool 和ExecutionMemoryPool，在实现类UnifiedMemoryManager中可以看到通过这两个MemoryPool实现来控制内存大小的伸缩（Increment/Decrement）。

获取当前堆上的最大可用Storage内存，如下maxOnHeapStorageMemory方法所示：

1 2	override def maxOnHeapStorageMemory: Long = synchronized { maxHeapMemory - onHeapExecutionMemoryPool.memoryUsed }

可以看到，maxHeapMemory表示堆上可用的Execution内存与Storage内存总量之和，减去Execution内存中已经被占用的内存，剩余的都是堆上的最大可用Storage内存。

在UnifiedMemoryManager中，两类最核心的操作，就是申请/释放Storage内存、申请/释放Execution内存，分别说明如下：

申请Storage内存

申请Storage内存的逻辑，实现代码如下所示：

 override def acquireStorageMemory( blockId: BlockId,
numBytes: Long,
memoryMode: MemoryMode): Boolean = synchronized { // 为blockId申请numBytes字节大小的内存
assertInvariants()
assert(numBytes >= 0)
val (executionPool, storagePool, maxMemory) = memoryMode match { // 根据memoryMode值，返回对应的StorageMemoryPool与ExecutionMemoryPool
case MemoryMode.ON_HEAP => (
onHeapExecutionMemoryPool,
onHeapStorageMemoryPool,
maxOnHeapStorageMemory)
case MemoryMode.OFF_HEAP => (
offHeapExecutionMemoryPool,
offHeapStorageMemoryPool,
maxOffHeapMemory)
}
if (numBytes > maxMemory) { // 如果申请的内存大于最大的Storage内存量（对应上面方法maxOnHeapStorageMemory()返回的内存大小），申请失败
// Fail fast if the block simply won't fit
logInfo(s"Will not store $blockId as the required space ($numBytes bytes) exceeds our " +
s"memory limit ($maxMemory bytes)")
return false
}
if (numBytes > storagePool.memoryFree) { // 如果Storage内存块中没有足够可用内存给blockId使用，则计算当前Storage内存区缺少多少内存，然后从Execution内存区中借用
// There is not enough free memory in the storage pool, so try to borrow free memory from
// the execution pool.
val memoryBorrowedFromExecution = Math.min(executionPool.memoryFree, numBytes)
executionPool.decrementPoolSize(memoryBorrowedFromExecution) // Execution内存区减掉借用内存量
storagePool.incrementPoolSize(memoryBorrowedFromExecution) // Storage内存区增加借用内存量
}
storagePool.acquireMemory(blockId, numBytes) // 如果Storage内存区可以为blockId分配内存，直接成功分配；否则，如果从Execution内存区中借用的内存能够满足blockId，则分配成功，不能满足则分配失败。
}

如果Storage内存区可用内存满足申请大小，则直接成功分配内存；如果Storage内存区可用内存大于0且小于申请的内存大小，则需要从Execution内存区借用满足分配大小的内存，如果借用成功，则直接成功分配内存，否则分配失败；如果申请的内存超过了Storage内存区的最大内存量，则分配失败。

另外，UnifiedMemoryManager.acquireUnrollMemory()方法提供了对Unroll内存的申请，Unroll内存就是Storage内存：

 override def acquireUnrollMemory( blockId: BlockId,
numBytes: Long,
memoryMode: MemoryMode): Boolean = synchronized {
acquireStorageMemory(blockId, numBytes, memoryMode)
}

Unroll内存，被用来在Storage内存中Unroll（展开）指定的Block数据。

释放Storage内存

释放Storage内存比较简单，只需要更新Storage内存计量变量即可，如下所示：

def releaseMemory(size: Long): Unit = lock.synchronized { if (size > _memoryUsed) {
logWarning(s"Attempted to release $size bytes of storage " +
s"memory when we only have ${_memoryUsed} bytes")
_memoryUsed = 0
} else {
_memoryUsed -= size
}
}

申请Execution内存

申请Execution内存，相对复杂一些，调用acquireExecutionMemory()方法可能会阻塞，直到Execution内存区有可用内存为止。UnifiedMemoryManager的acquireExecutionMemory()方法实现如下所示：

 override private[memory] def acquireExecutionMemory( numBytes: Long,
taskAttemptId: Long,
memoryMode: MemoryMode): Long = synchronized {
... ...
executionPool.acquireMemory(
numBytes, taskAttemptId, maybeGrowExecutionPool, computeMaxExecutionPoolSize)
}

上面代码，调用了ExecutionMemoryPool的acquireMemory()方法，该方法的参数需要2个函数（maybeGrowExecutionPool函数用来控制如何增加Execution内存区对应Pool的大小，computeMaxExecutionPoolSize函数用来获取当前Execution内存区对应Pool的大小）。ExecutionMemoryPool的acquireMemory()方法签名，如下所示：

private[memory] def acquireMemory( numBytes: Long,
taskAttemptId: Long,
maybeGrowPool: Long => Unit = (additionalSpaceNeeded: Long) => Unit,
computeMaxPoolSize: () => Long = () => poolSize): Long = lock.synchronized {

在UnifiedMemoryManager内部，实现了如何动态增加Execution内存区对应Pool大小的函数，即为maybeGrowExecutionPool函数，代码如下所示：

def maybeGrowExecutionPool(extraMemoryNeeded: Long): Unit = { if (extraMemoryNeeded > 0) {
// There is not enough free memory in the execution pool, so try to reclaim memory from
// storage. We can reclaim any free memory from the storage pool. If the storage pool
// has grown to become larger than `storageRegionSize`, we can evict blocks and reclaim
// the memory that storage has borrowed from execution.
val memoryReclaimableFromStorage = math.max( storagePool.memoryFree, storagePool.poolSize - storageRegionSize) 
if (memoryReclaimableFromStorage > 0) { // 这里memoryReclaimableFromStorage大于0，说明当前Storage内存区有可用内存，可以Shrink该Pool的内存，作为Execution内存区的可用内存使用
// Only reclaim as much space as is necessary and available:
val spaceToReclaim = storagePool.freeSpaceToShrinkPool( math.min(extraMemoryNeeded, memoryReclaimableFromStorage)) // 对Storage内存区进行Shrink操作，如果可用内存大于请求内存extraMemoryNeeded，则直接将Storage内存区内存Shrink大小为extraMemoryNeeded，否则Shrink大小为Storage内存区的全部可用内存大小
storagePool.decrementPoolSize(spaceToReclaim) // Storage内存区减掉借用内存量
executionPool.incrementPoolSize(spaceToReclaim) // Execution内存区增加借用内存量
}
}
}

需要说明的是，上面的storagePool.poolSize的大小可能大于Storage内存区初始最大内存大小，主要是通过借用Execution内存区的内存导致的。这里，storagePool.freeSpaceToShrinkPool()方法会Shrink掉Storage内存区可用内存，我们可以看下StorageMemoryPool中如何Shrink Storage内存，方法如下所示：

def freeSpaceToShrinkPool(spaceToFree: Long): Long = lock.synchronized { val spaceFreedByReleasingUnusedMemory = math.min(spaceToFree, memoryFree)
val remainingSpaceToFree = spaceToFree - spaceFreedByReleasingUnusedMemory // Storage内存区需要释放remainingSpaceToFree大小的内存
if (remainingSpaceToFree > 0) { // 大于0表示当前Storage内存区已经无可用内存，需要通过清理Storage内存区的block来实现Shrink操作
// If reclaiming free memory did not adequately shrink the pool, begin evicting blocks:
val spaceFreedByEviction = memoryStore.evictBlocksToFreeSpace(None, remainingSpaceToFree, memoryMode) // 通过清理Storage内存区的block释放的内存大小
// When a block is released, BlockManager.dropFromMemory() calls releaseMemory(), so we do
// not need to decrement _memoryUsed here. However, we do need to decrement the pool size.
spaceFreedByReleasingUnusedMemory + spaceFreedByEviction
} else { // remainingSpaceToFree Unit = (additionalSpaceNeeded: Long) => Unit,
computeMaxPoolSize: () => Long = () => poolSize): Long = lock.synchronized {
assert(numBytes > 0, s"invalid number of bytes requested: $numBytes")
if (!memoryForTask.contains(taskAttemptId)) { // ExecutionMemoryPool内部维护了一个HashMap
memoryForTask(taskAttemptId) = 0L
// This will later cause waiting tasks to wake up and check numTasks again
lock.notifyAll()
}
while (true) {
val numActiveTasks = memoryForTask.keys.size // 当前活跃的Task数量
val curMem = memoryForTask(taskAttemptId) // 当前Task使用的内存量
maybeGrowPool(numBytes - memoryFree) // 如果需要，通过Shrink Storage内存区对应的Pool内存来增加Execution内存区内存大小
val maxPoolSize = computeMaxPoolSize() // 计算当前Execution内存区对应Pool的大小
val maxMemoryPerTask = maxPoolSize / numActiveTasks // 计算1/N：将当前Execution内存区对应Pool的大小，平均分配给所有活跃的Task，得到每个Task能够获取到的最大内存大小
val minMemoryPerTask = poolSize / (2 * numActiveTasks) // 计算1/2N：每个Task能够获取到的最小内存大小
val maxToGrant = math.min(numBytes, math.max(0, maxMemoryPerTask - curMem)) // 允许当前Task获取到最大内存（范围：0 
val toGrant = math.min(maxToGrant, memoryFree) // 计算能分配给当前Task的内存大小
// 如果当前Task无法获取到1 / (2 * numActiveTasks)的内存，并且能分配给当前Task的内存大小无法满足申请的内存量，则阻塞等待其他Task释放内存后在lock上通知
if (toGrant 
logInfo(s"TID $taskAttemptId waiting for at least 1/2N of $poolName pool to be free")
lock.wait() // 在ExecutionMemoryPool.releaseMemory()方法中会通知其他申请内存并在lock上wait的Task，内存已经释放
} else {
memoryForTask(taskAttemptId) += toGrant // 当前Task获取到内存，需要登记到memoryForTask表中
return toGrant
}
}
0L // Never reached
}

释放Execution内存

相对应的，ExecutionMemoryPool.releaseMemory()方法实现了对Execution内存的释放操作，方法实现代码如下所示：

def releaseMemory(numBytes: Long, taskAttemptId: Long): Unit = lock.synchronized { val curMem = memoryForTask.getOrElse(taskAttemptId, 0L)
var memoryToFree = if (curMem // 计算释放内存大小
logWarning( s"Internal error: release called on $numBytes bytes but task only has $curMem bytes " +
s"of memory from the $poolName pool")
curMem
} else {
numBytes
}
if (memoryForTask.contains(taskAttemptId)) { // Task执行完成，从内部维护的memoryForTask中移除
memoryForTask(taskAttemptId) -= memoryToFree
if (memoryForTask(taskAttemptId) 0) {
memoryForTask.remove(taskAttemptId)
}
}
lock.notifyAll() // 通知调用acquireMemory()方法申请内存的Task内存已经释放
}

总结

需要注意的，每个Executor JVM中只存在一个UnifiedMemoryManager实例，该对象统一控制该JVM内对Storage和Execution内存的申请和释放操作。

通过上面的分析，UnifiedMemoryManager可以看做一个统一的内存管理控制器，底层通过StorageMemoryPool 与ExecutionMemoryPool提供的申请内存、释放内存的功能，实现最基本的bookkeeping功能。再向底层，实际操作Block及其Java对象等数据的功能，都是在MemoryStore中进行的，MemoryStore被用来在内存中存储数据，主要包括block、反序列化的Java对象数组、序列化的ByteBuffer，同时它提供了存取内存中各种格式数据的操作。关于MemoryStore的基本结构和原理，我们后续会单独分析。

Spark RPC通信层设计原理分析

2018-04-04T08:08:40.000Z

Spark将RPC通信层设计的非常巧妙，融合了各种设计/架构模式，将一个分布式集群系统的通信层细节完全屏蔽，这样在上层的计算框架的设计中能够获得很好的灵活性。同时，如果上层想要增加各种新的特性，或者对来自不同企业或组织的程序员贡献的特性，也能够很容易地增加进来，可以避开复杂的通信层而将注意力集中在上层计算框架的处理和优化上，入手难度非常小。另外，对上层计算框架中的各个核心组件的开发、功能增强，以及Bug修复等都会变得更加容易

Spark RPC层设计概览

Spark RPC层是基于优秀的网络通信框架Netty设计开发的，同时获得了Netty所具有的网络通信的可靠性和高效性。我们先把Spark中与RPC相关的一些类的关系梳理一下，为了能够更直观地表达RPC的设计，我们先从类的设计来看，如下图所示

通过上图，可以清晰地将RPC设计分离出来，能够对RPC层有一个整体的印象。了解Spark RPC层的几个核心的概念（我们通过Spark源码中对应的类名来标识），能够更好地理解设计

RpcEndpoint

RpcEndpoint定义了RPC通信过程中的通信端对象，除了具有管理一个RpcEndpoint生命周期的操作（constructor -> onStart -> receive* -> onStop），并给出了通信过程中一个RpcEndpoint所具有的基于事件驱动的行为（连接、断开、网络异常），实际上对于Spark框架来说主要是接收消息并处理，具体可以看对应特质RpcEndpoint的代码定义，如下所示

private[spark] trait RpcEndpoint {

 /**
 * The [[RpcEnv]] that this [[RpcEndpoint]] is registered to.
 */
 val rpcEnv: RpcEnv

 /**
 * The [[RpcEndpointRef]] of this [[RpcEndpoint]]. `self` will become valid when `onStart` is
 * called. And `self` will become `null` when `onStop` is called.
 *
 * Note: Because before `onStart`, [[RpcEndpoint]] has not yet been registered and there is not
 * valid [[RpcEndpointRef]] for it. So don't call `self` before `onStart` is called.
 */
 final def self: RpcEndpointRef = {
 require(rpcEnv != null, "rpcEnv has not been initialized")
 rpcEnv.endpointRef(this)
 }

 /**
 * Process messages from `RpcEndpointRef.send` or `RpcCallContext.reply`. If receiving a
 * unmatched message, `SparkException` will be thrown and sent to `onError`.
 */
 def receive: PartialFunction[Any, Unit] = {
 case _ => throw new SparkException(self + " does not implement 'receive'")
 }

 /**
 * Process messages from `RpcEndpointRef.ask`. If receiving a unmatched message,
 * `SparkException` will be thrown and sent to `onError`.
 */
 def receiveAndReply(context: RpcCallContext): PartialFunction[Any, Unit] = {
 case _ => context.sendFailure(new SparkException(self + " won't reply anything"))
 }

 /**
 * Invoked when any exception is thrown during handling messages.
 */
 def onError(cause: Throwable): Unit = {
 // By default, throw e and let RpcEnv handle it
 throw cause
 }

 /**
 * Invoked when `remoteAddress` is connected to the current node.
 */
 def onConnected(remoteAddress: RpcAddress): Unit = {
 // By default, do nothing.
 }

 /**
 * Invoked when `remoteAddress` is lost.
 */
 def onDisconnected(remoteAddress: RpcAddress): Unit = {
 // By default, do nothing.
 }

 /**
 * Invoked when some network error happens in the connection between the current node and
 * `remoteAddress`.
 */
 def onNetworkError(cause: Throwable, remoteAddress: RpcAddress): Unit = {
 // By default, do nothing.
 }

 /**
 * Invoked before [[RpcEndpoint]] starts to handle any message.
 */
 def onStart(): Unit = {
 // By default, do nothing.
 }

 /**
 * Invoked when [[RpcEndpoint]] is stopping. `self` will be `null` in this method and you cannot
 * use it to send or ask messages.
 */
 def onStop(): Unit = {
 // By default, do nothing.
 }

通过上面的receive方法，接收由RpcEndpointRef.send方法发送的消息，该类消息不需要进行响应消息（Reply），而只是在RpcEndpoint端进行处理。通过receiveAndReply方法，接收由RpcEndpointRef.ask发送的消息，RpcEndpoint端处理完消息后，需要给调用RpcEndpointRef.ask的通信端响应消息（Reply）

RpcEndpointRef

RpcEndpointRef是一个对RpcEndpoint的远程引用对象，通过它可以向远程的RpcEndpoint端发送消息以进行通信。RpcEndpointRef特质的定义，代码如下所示：

private[spark] abstract class RpcEndpointRef(conf: SparkConf)
 extends Serializable with Logging {

 private[this] val maxRetries = RpcUtils.numRetries(conf)
 private[this] val retryWaitMs = RpcUtils.retryWaitMs(conf)
 private[this] val defaultAskTimeout = RpcUtils.askRpcTimeout(conf)

 /**
 * return the address for the [[RpcEndpointRef]]
 */
 def address: RpcAddress

 def name: String

 /**
 * Sends a one-way asynchronous message. Fire-and-forget semantics.
 */
 def send(message: Any): Unit

 /**
 * Send a message to the corresponding [[RpcEndpoint.receiveAndReply)]] and return a [[Future]] to
 * receive the reply within the specified timeout.
 *
 * This method only sends the message once and never retries.
 */
 def ask[T: ClassTag](message: Any, timeout: RpcTimeout): Future[T]

 /**
 * Send a message to the corresponding [[RpcEndpoint.receiveAndReply)]] and return a [[Future]] to
 * receive the reply within a default timeout.
 *
 * This method only sends the message once and never retries.
 */
 def ask[T: ClassTag](message: Any): Future[T] = ask(message, defaultAskTimeout)

 /**
 * Send a message to the corresponding [[RpcEndpoint.receiveAndReply]] and get its result within a
 * default timeout, throw an exception if this fails.
 *
 * Note: this is a blocking action which may cost a lot of time,  so don't call it in a message
 * loop of [[RpcEndpoint]].

 * @param message the message to send
 * @tparam T type of the reply message
 * @return the reply message from the corresponding [[RpcEndpoint]]
 */
 def askSync[T: ClassTag](message: Any): T = askSync(message, defaultAskTimeout)

 /**
 * Send a message to the corresponding [[RpcEndpoint.receiveAndReply]] and get its result within a
 * specified timeout, throw an exception if this fails.
 *
 * Note: this is a blocking action which may cost a lot of time, so don't call it in a message
 * loop of [[RpcEndpoint]].
 *
 * @param message the message to send
 * @param timeout the timeout duration
 * @tparam T type of the reply message
 * @return the reply message from the corresponding [[RpcEndpoint]]
 */
 def askSync[T: ClassTag](message: Any, timeout: RpcTimeout): T = {
 val future = ask[T](message, timeout)
 timeout.awaitResult(future)
 }

}

send方法发送消息后不等待响应，亦即Send-and-forget，Spark中基于Netty实现，实现在NettyRpcEndpointRef中

1
2
3

override def ask[T: ClassTag](message: Any, timeout: RpcTimeout): Future[T] = {
 nettyEnv.ask(new RequestMessage(nettyEnv.address, this, message), timeout)
 }

RpcEnv

一个RpcEnv是一个RPC环境对象，它负责管理RpcEndpoint的注册，以及如何从一个RpcEndpoint获取到一个RpcEndpointRef。RpcEndpoint是一个通信端，例如Spark集群中的Master，或Worker，都是一个RpcEndpoint。但是，如果想要与一个RpcEndpoint端进行通信，一定需要获取到该RpcEndpoint一个RpcEndpointRef，而获取该RpcEndpointRef只能通过一个RpcEnv环境对象来获取。所以说，一个RpcEnv对象才是RPC通信过程中的“指挥官”，在RpcEnv类中，有一个核心的方法：
def setupEndpoint(name: String, endpoint: RpcEndpoint): RpcEndpointRef
通过上面方法，可以注册一个RpcEndpoint到RpcEnv环境对象中，有RpcEnv来管理RpcEndpoint到RpcEndpointRef的绑定关系。在注册RpcEndpoint时，每个RpcEndpoint都需要有一个唯一的名称。
Spark中基于Netty实现通信，所以对应的RpcEnv实现为NettyRpcEnv，上面方法的实现，如下所示：

1
2
3

override def setupEndpoint(name: String, endpoint: RpcEndpoint): RpcEndpointRef = {
 dispatcher.registerRpcEndpoint(name, endpoint)
 }

调用NettyRpcEnv内部的Dispatcher对象注册一个RpcEndpoint

def registerRpcEndpoint(name: String, endpoint: RpcEndpoint): NettyRpcEndpointRef = {
 val addr = RpcEndpointAddress(nettyEnv.address, name)
 val endpointRef = new NettyRpcEndpointRef(nettyEnv.conf, addr, nettyEnv)
 synchronized {
 if (stopped) {
 throw new IllegalStateException("RpcEnv has been stopped")
 }
 if (endpoints.putIfAbsent(name, new EndpointData(name, endpoint, endpointRef)) != null) {
 throw new IllegalArgumentException(s"There is already an RpcEndpoint called $name")
 }
 val data = endpoints.get(name)
 endpointRefs.put(data.endpoint, data.ref)
 receivers.offer(data)  // for the OnStart message
 }
 endpointRef
 }

一个RpcEndpoint只能注册一次（根据RpcEndpoint的名称来检查唯一性），这样在Dispatcher内部注册并维护RpcEndpoint与RpcEndpointRef的绑定关系，通过如下两个内部结构：

private val endpoints: ConcurrentMap[String, EndpointData] =
 new ConcurrentHashMap[String, EndpointData]
 private val endpointRefs: ConcurrentMap[RpcEndpoint, RpcEndpointRef] =
 new ConcurrentHashMap[RpcEndpoint, RpcEndpointRef]

可以看到，一个命名唯一的RpcEndpoint在Dispatcher中对应一个EndpointData来维护其信息，该数据结构定义，如下所示:

private class EndpointData(
 val name: String,
 val endpoint: RpcEndpoint,
val ref: NettyRpcEndpointRef) {
 val inbox = new Inbox(ref, endpoint)
 }

这里，每一个命名唯一的RpcEndpoint对应一个线程安全的Inbox，所有发送给一个RpcEndpoint的消息，都由对应的Inbox将对应的消息路由给RpcEndpoint进行处理，后面我们会详细分析Inbox

创建NettyRpcEnv环境对象

创建NettyRpcEnv对象，是一个非常重的操作，所以在框架里使用过程中要尽量避免重复创建。创建NettyRpcEnv，会创建很多用来处理底层RPC通信的线程和数据结构。具体的创建过程，如下图所示：

private[rpc] class NettyRpcEnvFactory extends RpcEnvFactory with Logging {

 def create(config: RpcEnvConfig): RpcEnv = {
 val sparkConf = config.conf
 // Use JavaSerializerInstance in multiple threads is safe. However, if we plan to support
 // KryoSerializer in future, we have to use ThreadLocal to store SerializerInstance
 val javaSerializerInstance =
 new JavaSerializer(sparkConf).newInstance().asInstanceOf[JavaSerializerInstance]
 val nettyEnv =
 new NettyRpcEnv(sparkConf, javaSerializerInstance, config.advertiseAddress,
 config.securityManager)
 if (!config.clientMode) {
 val startNettyRpcEnv: Int => (NettyRpcEnv, Int) = { actualPort =>
 nettyEnv.startServer(config.bindAddress, actualPort)
 (nettyEnv, nettyEnv.address.port)
 }
 try {
 Utils.startServiceOnPort(config.port, startNettyRpcEnv, sparkConf, config.name)._1
 } catch {
 case NonFatal(e) =>
 nettyEnv.shutdown()
 throw e
 }
 }
 nettyEnv
 }
}

具体要点，描述如下：

创建一个NettyRpcEnv对象对象，需要通过NettyRpcEnvFactory来创建
Dispatcher负责RPC消息的路由，它能够将消息路由到对应的RpcEndpoint进行处理
NettyStreamManager负责提供文件服务（文件、JAR文件、目录）
NettyRpcHandler负责处理网络IO事件，接收RPC调用请求，并通过Dispatcher派发消息
TransportContext负责管理网路传输上下文信息：创建MessageEncoder、MessageDecoder、TransportClientFactory、TransportServer
TransportServer配置并启动一个RPC Server服务

消息路由过程分析

基于Standalone模式，Spark集群具有Master和一组Worker，Worker与Master之间需要进行通信，我们以此为例，来说明基于Spark PRC层是如何实现消息的路由的。
首先看Master端实现，代码如下所示：

def startRpcEnvAndEndpoint(
 host: String,
 port: Int,
 webUiPort: Int,
 conf: SparkConf): (RpcEnv, Int, Option[Int]) = {
 val securityMgr = new SecurityManager(conf)
 val rpcEnv = RpcEnv.create(SYSTEM_NAME, host, port, conf, securityMgr)
 val masterEndpoint = rpcEnv.setupEndpoint(ENDPOINT_NAME,
 new Master(rpcEnv, rpcEnv.address, webUiPort, securityMgr, conf))
 val portsResponse = masterEndpoint.askSync[BoundPortsResponse](BoundPortsRequest)
 (rpcEnv, portsResponse.webUIPort, portsResponse.restPort)
 }

上面代码中，创建一个RpcEnv对象，通过创建一个NettyRpcEnvFactory对象来完成该RpcEnv对象的创建，实际创建了一个NettyRpcEnv对象。接着，通过setupEndpoint方法注册一个RpcEndpoint，这里Master就是一个RpcEndpoint，返回的masterEndpoint是Master的RpcEndpointRef引用对象。下面，我们看一下，发送一个BoundPortsRequest消息，具体的消息路由过程，如下图所示：

上图中显示本地消息和远程消息派发的流程，最主要的区别是在接收消息时：接收消息走的是Inbox，发送消息走的是Outbox

本地消息路由

发送一个BoundPortsRequest消息，实际走的是本地消息路由，直接放到对应的Inbox中，对应的代码处理逻辑如下所示：

/**
 * Posts a message to a specific endpoint.
 *
 * @param endpointName name of the endpoint.
 * @param message the message to post
 * @param callbackIfStopped callback function if the endpoint is stopped.
 */
private def postMessage(
 endpointName: String,
 message: InboxMessage,
 callbackIfStopped: (Exception) => Unit): Unit = {
 val error = synchronized {
 val data = endpoints.get(endpointName)
 if (stopped) {
 Some(new RpcEnvStoppedException())
 } else if (data == null) {
 Some(new SparkException(s"Could not find $endpointName."))
 } else {
 data.inbox.post(message)
 receivers.offer(data)
 None
 }
 }
 // We don't need to call `onStop` in the `synchronized` block
 error.foreach(callbackIfStopped)
}

上面通过data.inbox派发消息，然后将消息data :EndpointData放入到receivers队列，触发Dispatcher内部的MessageLoop线程去消费，如下所示：

/** Message loop used for dispatching messages. */
 private class MessageLoop extends Runnable {
 override def run(): Unit = {
 try {
 while (true) {
 try {
 val data = receivers.take()
 if (data == PoisonPill) {
 // Put PoisonPill back so that other MessageLoops can see it.
 receivers.offer(PoisonPill)
 return
 }
 data.inbox.process(Dispatcher.this)
 } catch {
 case NonFatal(e) => logError(e.getMessage, e)
 }
 }
 } catch {
 case ie: InterruptedException => // exit
 }
 }
 }

上面的过程在Dispatcher 内部线程池执行。内部线程池如下

private val threadpool: ThreadPoolExecutor = {
 val numThreads = nettyEnv.conf.getInt("spark.rpc.netty.dispatcher.numThreads",
 math.max(2, Runtime.getRuntime.availableProcessors()))
 val pool = ThreadUtils.newDaemonFixedThreadPool(numThreads, "dispatcher-event-loop")
 for (i 
 pool.execute(new MessageLoop)
 }
 pool
 }

这里，又继续调用Inbox的process方法来派发消息到指定的RpcEndpoint。通过上面的序列图，我们可以通过源码分析看到，原始消息被层层封装为一个RpcMessage ，该消息在Inbox的process方法中处理派发逻辑，如下所示：

case RpcMessage(_sender, content, context) =>
 try {
 endpoint.receiveAndReply(context).applyOrElse[Any, Unit](content, { msg =>
 throw new SparkException(s"Unsupported message $message from ${_sender}")
 })
 } catch {
 case NonFatal(e) =>
 context.sendFailure(e)
 // Throw the exception -- this exception will be caught by the safelyCall function.
 // The endpoint's onError function will be called.
 throw e
 }

到这里，消息已经发送给对应的RpcEndpoint的receiveAndReply方法，我们这里实际上是Master实现类，这里的消息解包后为content: BoundPortsRequest，接下来应该看Master的receiveAndReply方法如何处理该本地消息，代码如下所示：

1 2	case BoundPortsRequest => context.reply(BoundPortsResponse(address.port, webUi.boundPort, restServerBoundPort))

可以看出，实际上上面的处理逻辑没有什么处理，只是通过BoundPortsResponse返回了几个Master端的几个端口号数据。

远程消息路由

我们都知道，Worker启动时，会向Master注册，通过该场景我们分析一下远程消息路由的过程。
先看一下Worker端向Master注册过程，如下图所示：

Worker启动时，会首先获取到一个Master的RpcEndpointRef远程引用，通过该引用对象能够与Master进行RPC通信，经过上面消息派发，最终通过Netty的Channel将消息发送到远程Master端。
通过前面说明，我们知道Worker向Master注册的消息RegisterWorker应该最终会被路由到Master对应的Inbox中，然后派发给Master进行处理。下面，我们看一下Master端接收并处理消息的过程，如下图所示：

上图分为两部分：一部分是从远端接收消息RegisterWorker，将接收到的消息放入到Inbox中；另一部分是触发MessageLoop线程处理该消息，进而通过调用Inbox的process方法，继续调用RpcEndpoint（Master）的receiveAndReply方法，处理消息RegisterWorker，如下所示：

case RegisterWorker(
 id, workerHost, workerPort, workerRef, cores, memory, workerWebUiUrl, masterAddress) =>
 logInfo("Registering worker %s:%d with %d cores, %s RAM".format(
 workerHost, workerPort, cores, Utils.megabytesToString(memory)))
 if (state == RecoveryState.STANDBY) {
 workerRef.send(MasterInStandby)
 } else if (idToWorker.contains(id)) {
 workerRef.send(RegisterWorkerFailed("Duplicate worker ID"))
 } else {
 val worker = new WorkerInfo(id, workerHost, workerPort, cores, memory,
 workerRef, workerWebUiUrl)
 if (registerWorker(worker)) {
 persistenceEngine.addWorker(worker)
 workerRef.send(RegisteredWorker(self, masterWebUiUrl, masterAddress))
 schedule()
 } else {
 val workerAddress = worker.endpoint.address
 logWarning("Worker registration failed. Attempted to re-register worker at same " +
 "address: " + workerAddress)
 workerRef.send(RegisterWorkerFailed("Attempted to re-register worker at same address: "
 + workerAddress))
 }
 }

如果Worker注册成功，则Master会通过context对象回复Worker响应

1	context.reply(RegisteredWorker(self, masterWebUiUrl))

这样，如果一切正常，则Worker会收到RegisteredWorker响应消息，从而获取到Master的RpcEndpointRef引用对象，能够通过该引用对象与Master交互。

Spark BlockManager分析

2018-04-04T07:59:48.000Z

BlockManager 是 spark 中至关重要的一个组件，在 spark的的运行过程中到处都有 BlockManager 的身影，只有搞清楚 BlockManager 的原理和机制，你才能更加深入的理解 spark。今天我们来揭开 BlockaManager 的底层原理和设计思路。

整体架构

BlockManager 是一个嵌入在 spark 中的 key-value型分布式存储系统，是为 spark 量身打造的，BlockManager 在一个 spark 应用中作为一个本地缓存运行在所有的节点上，包括所有 driver 和 executor上。 BlockManager 对本地和远程提供一致的 get 和set 数据块接口， BlockManager 本身使用不同的存储方式来存储这些数据，包括 memory, disk, off-heap。

上面是一个整体的架构图， BlockManagerMaster拥有BlockManagerMasterEndpoint 的actor和所有BlockManagerSlaveEndpoint的ref，可以通过这些引用对 slave 下达命令

executor 节点上的BlockManagerMaster 则拥有BlockManagerMasterEndpoint的ref和自身BlockManagerSlaveEndpoint的actor。可以通过 Master的引用注册自己。

在master 和 slave 可以正常的通信之后，就可以根据设计的交互协议进行交互，整个分布式缓存系统也就运转起来了

初始化

我们知道， sparkEnv 启动的时候会启动各个组件， BlockManager 也不例外，也是这个时候启动的
sparkEnv调用create 方法启动。
Spark context启动时候会初始化SparkEnv

1 2	_env = createSparkEnv(_conf, isLocal, listenerBus) SparkEnv.set(_env)

调用如下方法createSparkEnv

private[spark] def createSparkEnv(
 conf: SparkConf,
 isLocal: Boolean,
 listenerBus: LiveListenerBus): SparkEnv = {
 SparkEnv.createDriverEnv(conf, isLocal, listenerBus, SparkContext.numDriverCores(master))
 }

执行SparkEnv.createDriverEnv

private[spark] def createDriverEnv(
 conf: SparkConf,
 isLocal: Boolean,
 listenerBus: LiveListenerBus,
 numCores: Int,
 mockOutputCommitCoordinator: Option[OutputCommitCoordinator] = None): SparkEnv = {
 assert(conf.contains(DRIVER_HOST_ADDRESS),
 s"${DRIVER_HOST_ADDRESS.key} is not set on the driver!")
 assert(conf.contains("spark.driver.port"), "spark.driver.port is not set on the driver!")
 val bindAddress = conf.get(DRIVER_BIND_ADDRESS)
 val advertiseAddress = conf.get(DRIVER_HOST_ADDRESS)
 val port = conf.get("spark.driver.port").toInt
 val ioEncryptionKey = if (conf.get(IO_ENCRYPTION_ENABLED)) {
 Some(CryptoStreamUtils.createKey(conf))
 } else {
 None
 }
 create(
 conf,
 SparkContext.DRIVER_IDENTIFIER,
 bindAddress,
 advertiseAddress,
 port,
 isLocal,
 numCores,
 ioEncryptionKey,
 listenerBus = listenerBus,
 mockOutputCommitCoordinator = mockOutputCommitCoordinator
 )
 }

最终执行create方法，create 方法中初始化blockManagerMaster,blockManager

val blockManagerMaster = new BlockManagerMaster(registerOrLookupEndpoint(
 BlockManagerMaster.DRIVER_ENDPOINT_NAME,
 new BlockManagerMasterEndpoint(rpcEnv, isLocal, conf, listenerBus)),
 conf, isDriver)
  
val blockManager = new BlockManager(executorId, rpcEnv, blockManagerMaster,
 serializerManager, conf, memoryManager, mapOutputTracker, shuffleManager,
 blockTransferService, securityManager, numUsableCores)

启动的时候会根据自己是在 driver 还是 executor 上进行不同的启动过程

def registerOrLookupEndpoint(
 name: String, endpointCreator: => RpcEndpoint):
 RpcEndpointRef = {
 if (isDriver) {
 logInfo("Registering " + name)
 rpcEnv.setupEndpoint(name, endpointCreator)
 } else {
 RpcUtils.makeDriverRef(name, conf, rpcEnv)
 }
 }

sparkEnv 在 master上启动的时候，构造了一个 BlockManagerMasterEndpoint, 然后把这个Endpoint 注册在 rpcEnv中，同时也会启动自己的 BlockManager

sparkEnv 在executor上启动的时候，通过 setupEndpointRef 方法获取到了 BlockManagerMaster的引用 BlockManagerMasterRef，同时也会启动自己的 BlockManager

在 BlockManager 初始化自己的时候，会向 BlockManagerMasterEndpoint 注册自己， BlockManagerMasterEndpoint 发送 registerBlockManager消息， BlockManagerMasterEndpoint 接受到消息，把 BlockManagerSlaveEndpoint 的引用保存在自己的 blockManagerInfo 数据结构中以待后用

在SparkContext初始化时候调用

1	_env.blockManager.initialize(_applicationId)

方法如下：

/**
 * Initializes the BlockManager with the given appId. This is not performed in the constructor as
 * the appId may not be known at BlockManager instantiation time (in particular for the driver,
 * where it is only learned after registration with the TaskScheduler).
 *
 * This method initializes the BlockTransferService and ShuffleClient, registers with the
 * BlockManagerMaster, starts the BlockManagerWorker endpoint, and registers with a local shuffle
 * service if configured.
 */
 def initialize(appId: String): Unit = {
 blockTransferService.init(this)
 shuffleClient.init(appId)

 blockReplicationPolicy = {
 val priorityClass = conf.get(
 "spark.storage.replication.policy", classOf[RandomBlockReplicationPolicy].getName)
 val clazz = Utils.classForName(priorityClass)
 val ret = clazz.newInstance.asInstanceOf[BlockReplicationPolicy]
 logInfo(s"Using $priorityClass for block replication policy")
 ret
 }

 val id =
 BlockManagerId(executorId, blockTransferService.hostName, blockTransferService.port, None)

 val idFromMaster = master.registerBlockManager(
 id,
 maxOnHeapMemory,
 maxOffHeapMemory,
 slaveEndpoint)

 blockManagerId = if (idFromMaster != null) idFromMaster else id

 shuffleServerId = if (externalShuffleServiceEnabled) {
 logInfo(s"external shuffle service port = $externalShuffleServicePort")
 BlockManagerId(executorId, blockTransferService.hostName, externalShuffleServicePort)
 } else {
 blockManagerId
 }

 // Register Executors' configuration with the local shuffle service, if one should exist.
 if (externalShuffleServiceEnabled && !blockManagerId.isDriver) {
 registerWithExternalShuffleServer()
 }

 logInfo(s"Initialized BlockManager: $blockManagerId")
 }

调用master 如下方法

val idFromMaster = master.registerBlockManager(
 id,
 maxOnHeapMemory,
 maxOffHeapMemory,
 slaveEndpoint)

继续往下：

/**
 * Register the BlockManager's id with the driver. The input BlockManagerId does not contain
 * topology information. This information is obtained from the master and we respond with an
 * updated BlockManagerId fleshed out with this information.
 */
 def registerBlockManager(
 blockManagerId: BlockManagerId,
 maxOnHeapMemSize: Long,
 maxOffHeapMemSize: Long,
 slaveEndpoint: RpcEndpointRef): BlockManagerId = {
 logInfo(s"Registering BlockManager $blockManagerId")
 val updatedId = driverEndpoint.askSync[BlockManagerId](
 RegisterBlockManager(blockManagerId, maxOnHeapMemSize, maxOffHeapMemSize, slaveEndpoint))
 logInfo(s"Registered BlockManager $updatedId")
 updatedId
 }

BlockManagerMasterEndpoint接受到消息 RegisterBlockManager

1 2	case RegisterBlockManager(blockManagerId, maxOnHeapMemSize, maxOffHeapMemSize, slaveEndpoint) => context.reply(register(blockManagerId, maxOnHeapMemSize, maxOffHeapMemSize, slaveEndpoint))

/**
 * Returns the BlockManagerId with topology information populated, if available.
 */
 private def register(
 idWithoutTopologyInfo: BlockManagerId,
 maxOnHeapMemSize: Long,
 maxOffHeapMemSize: Long,
 slaveEndpoint: RpcEndpointRef): BlockManagerId = {
 // the dummy id is not expected to contain the topology information.
 // we get that info here and respond back with a more fleshed out block manager id
 val id = BlockManagerId(
 idWithoutTopologyInfo.executorId,
 idWithoutTopologyInfo.host,
 idWithoutTopologyInfo.port,
 topologyMapper.getTopologyForHost(idWithoutTopologyInfo.host))

 val time = System.currentTimeMillis()
 if (!blockManagerInfo.contains(id)) {
 blockManagerIdByExecutor.get(id.executorId) match {
 case Some(oldId) =>
 // A block manager of the same executor already exists, so remove it (assumed dead)
 logError("Got two different block manager registrations on same executor - "
 + s" will replace old one $oldId with new one $id")
 removeExecutor(id.executorId)
 case None =>
 }
 logInfo("Registering block manager %s with %s RAM, %s".format(
 id.hostPort, Utils.bytesToString(maxOnHeapMemSize + maxOffHeapMemSize), id))

 blockManagerIdByExecutor(id.executorId) = id

 blockManagerInfo(id) = new BlockManagerInfo(
 id, System.currentTimeMillis(), maxOnHeapMemSize, maxOffHeapMemSize, slaveEndpoint)
 }
 listenerBus.post(SparkListenerBlockManagerAdded(time, id, maxOnHeapMemSize + maxOffHeapMemSize,
 Some(maxOnHeapMemSize), Some(maxOffHeapMemSize)))
 id
 }

分布式协议

下面的一个表格是 master 和 slave 接受到各种类型的消息，以及接受到消息后，做的处理。

BlockManagerMasterEndpoint 接受的消息

消息	处理
RegisterBlockManager	slave 注册自己的消息，会保存在自己的blockManagerInfo中
UpdateBlockInfo	一个Block的更新消息，BlockId作为一个Block的唯一标识，会保存Block所在的节点和位置关系，以及block 存储级别，大小占用内存和磁盘大小
GetLocationsMultipleBlockIds	获取多个Block所在的位置，位置中会反映Block位于哪个 executor, host 和端口
GetPeers	一个block有可能在多个节点上存在，返回一个节点列表
GetExecutorEndpointRef	根据BlockId,获取所在executorEndpointRef 也就是 BlockManagerSlaveEndpoint的引用
GetMemoryStatus	获取所有节点上的BlockManager的最大内存和剩余内存
GetStorageStatus	获取所有节点上的BlockManager的最大磁盘空间和剩余磁盘空间
GetBlockStatus	获取一个Block的状态信息，位置，占用内存和磁盘大小
GetMatchingBlockIds	获取一个Block的存储级别和所占内存和磁盘大小
RemoveRdd	删除Rdd对应的Block数据
RemoveBroadcast	删除Broadcast对应的Block数据
RemoveBlock	删除一个Block数据，会找到数据所在的slave,然后向slave发送一个删除消息
RemoveExecutor	从BlockManagerInfo中删除一个BlockManager, 并且删除这个 BlockManager上的所有的Blocks
BlockManagerHeartbeat	slave 发送心跳给 master , 证明自己还活着

BlockManagerSlaveEndpoint 接受的消息

消息	处理
RemoveBlock	slave删除自己BlockManager上的一个Block
RemoveRdd	删除Rdd对应的Block数据
RemoveShuffle	删除 shuffleId对应的BlockId的Block
RemoveBroadcast	删除 BroadcastId对应的BlockId的Block
GetBlockStatus	获取一个Block的存储级别和所占内存和磁盘大小

根据以上的协议，相信我们可以很清楚的猜测整个交互的流程，一般过程应该是这样的， slave的 BlockManager 在自己接的上存储一个 Block, 然后把这个 BlockId 汇报到master的BlockManager , 经过 cache, shuffle 或者 Broadcast后，别的节点需要上一步的Block的时候，会到 master 获取数据所在位置，然后去相应节点上去 fetch

存储层

在RDD层面上我们了解到RDD是由不同的partition组成的，我们所进行的transformation和action是在partition上面进行的；而在storage模块内部，RDD又被视为由不同的block组成，对于RDD的存取是以block为单位进行的，本质上partition和block是等价的，只是看待的角度不同。在Spark storage模块中中存取数据的最小单位是block，所有的操作都是以block为单位进行的。

BlockManager对象被创建的时候会创建出MemoryStore和DiskStore对象用以存取block，如果内存中拥有足够的内存，就使用 MemoryStore存储，如果不够，就 spill 到磁盘中，通过 DiskStore进行存储。

DiskStore 有一个DiskBlockManager,DiskBlockManager 主要用来创建并持有逻辑 blocks 与磁盘上的 blocks之间的映射，一个逻辑 block 通过 BlockId 映射到一个磁盘上的文件。在 DiskStore 中会调用 diskManager.getFile 方法，如果子文件夹不存在，会进行创建，文件夹的命名方式为(spark-local-yyyyMMddHHmmss-xxxx, xxxx是一个随机数)，所有的block都会存储在所创建的folder里面。
MemoryStore 相对于DiskStore需要根据block id hash计算出文件路径并将block存放到对应的文件里面，MemoryStore管理block就显得非常简单：MemoryStore内部维护了一个hash map来管理所有的block，以block id为key将block存放到hash map中。而从MemoryStore中取得block则非常简单，只需从hash map中取出block id对应的value即可。

BlockManager 的 PUT 和GET接口

GET操作如果 local 中存在就直接返回，从本地获取一个Block, 会先判断如果是 useMemory，直接从内存中取出，如果是 useDisk，会从磁盘中取出返回，然后根据useMemory判断是否在内存中缓存一下，方便下次获取，如果local 不存在，从其他节点上获取，当然元信息是存在 drive上的，要根据我们上文中提到的 GETlocation 协议获取 Block 所在节点位置，然后到其他节点上获取。
PUT操作操作之前会加锁来避免多线程的问题，存储的时候会根据存储级别，调用对应的是 memoryStore 还是 diskStore，然后在具体存储器上面调用存储接口。如果有 replication 需求，会把数据备份到其他的机器上面

Spark内存管理

2018-04-04T07:27:58.000Z

Spark 作为一个基于内存的分布式计算引擎，其内存管理模块在整个系统中扮演着非常重要的角色。理解 Spark 内存管理的基本原理，有助于更好地开发 Spark 应用程序和进行性能调优。本文旨在梳理出 Spark 内存管理的脉络，抛砖引玉，引出读者对这个话题的深入探讨。本文中阐述的原理基于 Spark 2.1 版本，阅读本文需要读者有一定的 Spark 和 Java 基础，了解 RDD、Shuffle、JVM 等相关概念。

Spark内存管理详解——内存分配

在执行 Spark 的应用程序时，Spark 集群会启动 Driver 和 Executor 两种 JVM 进程，前者为主控进程，负责创建 Spark 上下文，提交 Spark 作业（Job），并将作业转化为计算任务（Task），在各个 Executor 进程间协调任务的调度，后者负责在工作节点上执行具体的计算任务，并将结果返回给 Driver，同时为需要持久化的 RDD 提供存储功能[1]。由于 Driver 的内存管理相对来说较为简单，本文主要对 Executor 的内存管理进行分析，下文中的 Spark 内存均特指 Executor 的内存。

1. 堆内和堆外内存规划

作为一个 JVM 进程，Executor 的内存管理建立在 JVM 的内存管理之上，Spark 对 JVM 的堆内（On-heap）空间进行了更为详细的分配，以充分利用内存。同时，Spark 引入了堆外（Off-heap）内存，使之可以直接在工作节点的系统内存中开辟空间，进一步优化了内存的使用。

图 1 . 堆内和堆外内存示意图

1.1 堆内内存

堆内内存的大小，由 Spark 应用程序启动时的 –executor-memory 或 spark.executor.memory 参数配置。Executor 内运行的并发任务共享 JVM 堆内内存，这些任务在缓存 RDD 数据和广播（Broadcast）数据时占用的内存被规划为存储（Storage）内存，而这些任务在执行 Shuffle 时占用的内存被规划为执行（Execution）内存，剩余的部分不做特殊规划，那些 Spark 内部的对象实例，或者用户定义的 Spark 应用程序中的对象实例，均占用剩余的空间。不同的管理模式下，这三部分占用的空间大小各不相同（下面第 2 小节会进行介绍）。

Spark 对堆内内存的管理是一种逻辑上的”规划式”的管理，因为对象实例占用内存的申请和释放都由 JVM 完成，Spark 只能在申请后和释放前记录这些内存，我们来看其具体流程：

申请内存：

Spark 在代码中 new 一个对象实例
JVM 从堆内内存分配空间，创建对象并返回对象引用
Spark 保存该对象的引用，记录该对象占用的内存

释放内存：

Spark 记录该对象释放的内存，删除该对象的引用
等待 JVM 的垃圾回收机制释放该对象占用的堆内内存

我们知道，JVM 的对象可以以序列化的方式存储，序列化的过程是将对象转换为二进制字节流，本质上可以理解为将非连续空间的链式存储转化为连续空间或块存储，在访问时则需要进行序列化的逆过程——反序列化，将字节流转化为对象，序列化的方式可以节省存储空间，但增加了存储和读取时候的计算开销。

对于 Spark 中序列化的对象，由于是字节流的形式，其占用的内存大小可直接计算，而对于非序列化的对象，其占用的内存是通过周期性地采样近似估算而得，即并不是每次新增的数据项都会计算一次占用的内存大小，这种方法降低了时间开销但是有可能误差较大，导致某一时刻的实际内存有可能远远超出预期[2]。此外，在被 Spark 标记为释放的对象实例，很有可能在实际上并没有被 JVM 回收，导致实际可用的内存小于 Spark 记录的可用内存。所以 Spark 并不能准确记录实际可用的堆内内存，从而也就无法完全避免内存溢出（OOM, Out of Memory）的异常。

虽然不能精准控制堆内内存的申请和释放，但 Spark 通过对存储内存和执行内存各自独立的规划管理，可以决定是否要在存储内存里缓存新的 RDD，以及是否为新的任务分配执行内存，在一定程度上可以提升内存的利用率，减少异常的出现。

1.2 堆外内存

为了进一步优化内存的使用以及提高 Shuffle 时排序的效率，Spark 引入了堆外（Off-heap）内存，使之可以直接在工作节点的系统内存中开辟空间，存储经过序列化的二进制数据。利用 JDK Unsafe API（从 Spark 2.0 开始，在管理堆外的存储内存时不再基于 Tachyon，而是与堆外的执行内存一样，基于 JDK Unsafe API 实现[3]），Spark 可以直接操作系统堆外内存，减少了不必要的内存开销，以及频繁的 GC 扫描和回收，提升了处理性能。堆外内存可以被精确地申请和释放，而且序列化的数据占用的空间可以被精确计算，所以相比堆内内存来说降低了管理的难度，也降低了误差。

在默认情况下堆外内存并不启用，可通过配置 spark.memory.offHeap.enabled 参数启用，并由 spark.memory.offHeap.size 参数设定堆外空间的大小。除了没有 other 空间，堆外内存与堆内内存的划分方式相同，所有运行中的并发任务共享存储内存和执行内存。

1.3 内存管理接口

Spark 为存储内存和执行内存的管理提供了统一的接口——MemoryManager，同一个 Executor 内的任务都调用这个接口的方法来申请或释放内存:

清单 1 . 内存管理接口的主要方法

//申请存储内存
def acquireStorageMemory(blockId: BlockId, numBytes: Long, memoryMode: MemoryMode): Boolean
//申请展开内存
def acquireUnrollMemory(blockId: BlockId, numBytes: Long, memoryMode: MemoryMode): Boolean
//申请执行内存
def acquireExecutionMemory(numBytes: Long, taskAttemptId: Long, memoryMode: MemoryMode): Long
//释放存储内存
def releaseStorageMemory(numBytes: Long, memoryMode: MemoryMode): Unit
//释放执行内存
def releaseExecutionMemory(numBytes: Long, taskAttemptId: Long, memoryMode: MemoryMode): Unit
//释放展开内存
def releaseUnrollMemory(numBytes: Long, memoryMode: MemoryMode): Unit

我们看到，在调用这些方法时都需要指定其内存模式（MemoryMode），这个参数决定了是在堆内还是堆外完成这次操作。

MemoryManager 的具体实现上，Spark 1.6 之后默认为统一管理（Unified Memory Manager）方式，1.6 之前采用的静态管理（Static Memory Manager）方式仍被保留，可通过配置 spark.memory.useLegacyMode 参数启用。两种方式的区别在于对空间分配的方式，下面的第 2 小节会分别对这两种方式进行介绍。

2 . 内存空间分配

2.1 静态内存管理

在 Spark 最初采用的静态内存管理机制下，存储内存、执行内存和其他内存的大小在 Spark 应用程序运行期间均为固定的，但用户可以应用程序启动前进行配置，堆内内存的分配如图 2 所示：

图 2 . 静态内存管理图示——堆内

可以看到，可用的堆内内存的大小需要按照下面的方式计算：

清单 2 . 可用堆内内存空间

1
2

可用的存储内存 = systemMaxMemory * spark.storage.memoryFraction * spark.storage.safetyFraction
可用的执行内存 = systemMaxMemory * spark.shuffle.memoryFraction * spark.shuffle.safetyFraction

其中 systemMaxMemory 取决于当前 JVM 堆内内存的大小，最后可用的执行内存或者存储内存要在此基础上与各自的 memoryFraction 参数和 safetyFraction 参数相乘得出。上述计算公式中的两个 safetyFraction 参数，其意义在于在逻辑上预留出 1-safetyFraction 这么一块保险区域，降低因实际内存超出当前预设范围而导致 OOM 的风险（上文提到，对于非序列化对象的内存采样估算会产生误差）。值得注意的是，这个预留的保险区域仅仅是一种逻辑上的规划，在具体使用时 Spark 并没有区别对待，和”其它内存”一样交给了 JVM 去管理。

堆外的空间分配较为简单，只有存储内存和执行内存，如图 3 所示。可用的执行内存和存储内存占用的空间大小直接由参数 spark.memory.storageFraction 决定，由于堆外内存占用的空间可以被精确计算，所以无需再设定保险区域。

图 3 . 静态内存管理图示——堆外

静态内存管理机制实现起来较为简单，但如果用户不熟悉 Spark 的存储机制，或没有根据具体的数据规模和计算任务或做相应的配置，很容易造成”一半海水，一半火焰”的局面，即存储内存和执行内存中的一方剩余大量的空间，而另一方却早早被占满，不得不淘汰或移出旧的内容以存储新的内容。由于新的内存管理机制的出现，这种方式目前已经很少有开发者使用，出于兼容旧版本的应用程序的目的，Spark 仍然保留了它的实现。

2.2 统一内存管理

Spark 1.6 之后引入的统一内存管理机制，与静态内存管理的区别在于存储内存和执行内存共享同一块空间，可以动态占用对方的空闲区域，如图 4 和图 5 所示

图 4 . 统一内存管理图示——堆内

图 5 . 统一内存管理图示——堆外

其中最重要的优化在于动态占用机制，其规则如下：

设定基本的存储内存和执行内存区域（spark.storage.storageFraction 参数），该设定确定了双方各自拥有的空间的范围
双方的空间都不足时，则存储到硬盘；若己方空间不足而对方空余时，可借用对方的空间;（存储空间不足是指不足以放下一个完整的 Block）
执行内存的空间被对方占用后，可让对方将占用的部分转存到硬盘，然后”归还”借用的空间
存储内存的空间被对方占用后，无法让对方”归还”，因为需要考虑 Shuffle 过程中的很多因素，实现起来较为复杂[4]

图 6 . 动态占用机制图示

凭借统一内存管理机制，Spark 在一定程度上提高了堆内和堆外内存资源的利用率，降低了开发者维护 Spark 内存的难度，但并不意味着开发者可以高枕无忧。譬如，所以如果存储内存的空间太大或者说缓存的数据过多，反而会导致频繁的全量垃圾回收，降低任务执行时的性能，因为缓存的 RDD 数据通常都是长期驻留内存的 [5] 。所以要想充分发挥 Spark 的性能，需要开发者进一步了解存储内存和执行内存各自的管理方式和实现原理。

3. 存储内存管理

3.1 RDD 的持久化机制

弹性分布式数据集（RDD）作为 Spark 最根本的数据抽象，是只读的分区记录（Partition）的集合，只能基于在稳定物理存储中的数据集上创建，或者在其他已有的 RDD 上执行转换（Transformation）操作产生一个新的 RDD。转换后的 RDD 与原始的 RDD 之间产生的依赖关系，构成了血统（Lineage）。凭借血统，Spark 保证了每一个 RDD 都可以被重新恢复。但 RDD 的所有转换都是惰性的，即只有当一个返回结果给 Driver 的行动（Action）发生时，Spark 才会创建任务读取 RDD，然后真正触发转换的执行。
Task 在启动之初读取一个分区时，会先判断这个分区是否已经被持久化，如果没有则需要检查 Checkpoint 或按照血统重新计算。所以如果一个 RDD 上要执行多次行动，可以在第一次行动中使用 persist 或 cache 方法，在内存或磁盘中持久化或缓存这个 RDD，从而在后面的行动时提升计算速度。事实上，cache 方法是使用默认的 MEMORY_ONLY 的存储级别将 RDD 持久化到内存，故缓存是一种特殊的持久化。堆内和堆外存储内存的设计，便可以对缓存 **RDD 时使用的内存做统一的规划和管 理 **（存储内存的其他应用场景，如缓存 broadcast 数据，暂时不在本文的讨论范围之内）。

RDD 的持久化由 Spark 的 Storage 模块 [7] 负责，实现了 RDD 与物理存储的解耦合。Storage 模块负责管理 Spark 在计算过程中产生的数据，将那些在内存或磁盘、在本地或远程存取数据的功能封装了起来。在具体实现时 Driver 端和 Executor 端的 Storage 模块构成了主从式的架构，即 Driver 端的 BlockManager 为 Master，Executor 端的 BlockManager 为 Slave。Storage 模块在逻辑上以 Block 为基本存储单位，RDD 的每个 Partition 经过处理后唯一对应一个 Block（BlockId 的格式为 rdd_RDD-ID_PARTITION-ID ）。Master 负责整个 Spark 应用程序的 Block 的元数据信息的管理和维护，而 Slave 需要将 Block 的更新等状态上报到 Master，同时接收 Master 的命令，例如新增或删除一个 RDD。

图 7 . Storage 模块示意图

在对 RDD 持久化时，Spark 规定了 MEMORY_ONLY、MEMORY_AND_DISK 等 7 种不同的存储级别，而存储级别是以下 5 个变量的组合：

清单 3 . 存储级别

class StorageLevel private(
private var _useDisk: Boolean, //磁盘
private var _useMemory: Boolean, //这里其实是指堆内内存
private var _useOffHeap: Boolean, //堆外内存
private var _deserialized: Boolean, //是否为非序列化
private var _replication: Int = 1 //副本个数
)

通过对数据结构的分析，可以看出存储级别从三个维度定义了 RDD 的 Partition（同时也就是 Block）的存储方式：

存储位置：磁盘／堆内内存／堆外内存。如 MEMORY_AND_DISK 是同时在磁盘和堆内内存上存储，实现了冗余备份。OFF_HEAP 则是只在堆外内存存储，目前选择堆外内存时不能同时存储到其他位置。
存储形式：Block 缓存到存储内存后，是否为非序列化的形式。如 MEMORY_ONLY 是非序列化方式存储，OFF_HEAP 是序列化方式存储。
副本数量：大于 1 时需要远程冗余备份到其他节点。如 DISK_ONLY_2 需要远程备份 1 个副本。

3.2 RDD 缓存的过程

RDD 在缓存到存储内存之前，Partition 中的数据一般以迭代器（Iterator）的数据结构来访问，这是 Scala 语言中一种遍历数据集合的方法。通过 Iterator 可以获取分区中每一条序列化或者非序列化的数据项(Record)，这些 Record 的对象实例在逻辑上占用了 JVM 堆内内存的 other 部分的空间，同一 Partition 的不同 Record 的空间并不连续。

RDD 在缓存到存储内存之后，Partition 被转换成 Block，Record 在堆内或堆外存储内存中占用一块连续的空间。将**Partition由不连续的存储空间转换为连续存储空间的过程，Spark称之为”展开”（Unroll）**。Block 有序列化和非序列化两种存储格式，具体以哪种方式取决于该 RDD 的存储级别。非序列化的 Block 以一种 DeserializedMemoryEntry 的数据结构定义，用一个数组存储所有的对象实例，序列化的 Block 则以 SerializedMemoryEntry的数据结构定义，用字节缓冲区（ByteBuffer）来存储二进制数据。每个 Executor 的 Storage 模块用一个链式 Map 结构（LinkedHashMap）来管理堆内和堆外存储内存中所有的 Block 对象的实例[6]，对这个 LinkedHashMap 新增和删除间接记录了内存的申请和释放。

因为不能保证存储空间可以一次容纳 Iterator 中的所有数据，当前的计算任务在 Unroll 时要向 MemoryManager 申请足够的 Unroll 空间来临时占位，空间不足则 Unroll 失败，空间足够时可以继续进行。对于序列化的 Partition，其所需的 Unroll 空间可以直接累加计算，一次申请。而非序列化的 Partition 则要在遍历 Record 的过程中依次申请，即每读取一条 Record，采样估算其所需的 Unroll 空间并进行申请，空间不足时可以中断，释放已占用的 Unroll 空间。如果最终 Unroll 成功，当前 Partition 所占用的 Unroll 空间被转换为正常的缓存 RDD 的存储空间，如下图 8 所示。

图 8. Spark Unroll 示意图

在图 3 和图 5 中可以看到，在静态内存管理时，Spark 在存储内存中专门划分了一块 Unroll 空间，其大小是固定的，统一内存管理时则没有对 Unroll 空间进行特别区分，当存储空间不足时会根据动态占用机制进行处理。

3.3 淘汰和落盘

由于同一个 Executor 的所有的计算任务共享有限的存储内存空间，当有新的 Block 需要缓存但是剩余空间不足且无法动态占用时，就要对 LinkedHashMap 中的旧 Block 进行淘汰（Eviction），而被淘汰的 Block 如果其存储级别中同时包含存储到磁盘的要求，则要对其进行落盘（Drop），否则直接删除该 Block。

存储内存的淘汰规则为：

被淘汰的旧 Block 要与新 Block 的 MemoryMode 相同，即同属于堆外或堆内内存
新旧 Block 不能属于同一个 RDD，避免循环淘汰
旧 Block 所属 RDD 不能处于被读状态，避免引发一致性问题
遍历 LinkedHashMap 中 Block，按照最近最少使用（LRU）的顺序淘汰，直到满足新 Block 所需的空间。其中 LRU 是 LinkedHashMap 的特性。

落盘的流程则比较简单，如果其存储级别符合_useDisk 为 true 的条件，再根据其_deserialized 判断是否是非序列化的形式，若是则对其进行序列化，最后将数据存储到磁盘，在 Storage 模块中更新其信息。

4. 执行内存管理

4.1 多任务间内存分配

Executor 内运行的任务同样共享执行内存，Spark 用一个 HashMap 结构保存了任务到内存耗费的映射。每个任务可占用的执行内存大小的范围为 1/2N ~ 1/N，其中 N 为当前 Executor 内正在运行的任务的个数。每个任务在启动之时，要向 MemoryManager 请求申请最少为 1/2N 的执行内存，如果不能被满足要求则该任务被阻塞，直到有其他任务释放了足够的执行内存，该任务才可以被唤醒。

4.2 Shuffle 的内存占用

执行内存主要用来存储任务在执行 Shuffle 时占用的内存，Shuffle 是按照一定规则对 RDD 数据重新分区的过程，我们来看 Shuffle 的 Write 和 Read 两阶段对执行内存的使用：

Shuffle Write

若在 map 端选择普通的排序方式，会采用 ExternalSorter 进行外排，在内存中存储数据时主要占用堆内执行空间。
若在 map 端选择 Tungsten 的排序方式，则采用 ShuffleExternalSorter 直接对以序列化形式存储的数据排序，在内存中存储数据时可以占用堆外或堆内执行空间，取决于用户是否开启了堆外内存以及堆外执行内存是否足够。

Shuffle Read

在对 reduce 端的数据进行聚合时，要将数据交给 Aggregator 处理，在内存中存储数据时占用堆内执行空间。
如果需要进行最终结果排序，则要将再次将数据交给 ExternalSorter 处理，占用堆内执行空间。

在 ExternalSorter 和 Aggregator 中，Spark 会使用一种叫 AppendOnlyMap 的哈希表在堆内执行内存中存储数据，但在 Shuffle 过程中所有数据并不能都保存到该哈希表中，当这个哈希表占用的内存会进行周期性地采样估算，当其大到一定程度，无法再从 MemoryManager 申请到新的执行内存时，Spark 就会将其全部内容存储到磁盘文件中，这个过程被称为溢存(Spill)，溢存到磁盘的文件最后会被归并(Merge)。

Shuffle Write 阶段中用到的 Tungsten 是 Databricks 公司提出的对 Spark 优化内存和 CPU 使用的计划[9]，解决了一些 JVM 在性能上的限制和弊端。Spark 会根据 Shuffle 的情况来自动选择是否采用 Tungsten 排序。Tungsten 采用的页式内存管理机制建立在 MemoryManager 之上，即 Tungsten 对执行内存的使用进行了一步的抽象，这样在 Shuffle 过程中无需关心数据具体存储在堆内还是堆外。每个内存页用一个 MemoryBlock 来定义，并用 Object obj 和 long offset 这两个变量统一标识一个内存页在系统内存中的地址。堆内的 MemoryBlock 是以 long 型数组的形式分配的内存，其 obj 的值为是这个数组的对象引用，offset 是 long 型数组的在 JVM 中的初始偏移地址，两者配合使用可以定位这个数组在堆内的绝对地址；堆外的 MemoryBlock 是直接申请到的内存块，其 obj 为 null，offset 是这个内存块在系统内存中的 64 位绝对地址。Spark 用 MemoryBlock 巧妙地将堆内和堆外内存页统一抽象封装，并用页表(pageTable)管理每个 Task 申请到的内存页。

Tungsten 页式管理下的所有内存用 64 位的逻辑地址表示，由页号和页内偏移量组成：

页号：占 13 位，唯一标识一个内存页，Spark 在申请内存页之前要先申请空闲页号。
页内偏移量：占 51 位，是在使用内存页存储数据时，数据在页内的偏移地址。

有了统一的寻址方式，Spark 可以用 64 位逻辑地址的指针定位到堆内或堆外的内存，整个 Shuffle Write 排序的过程只需要对指针进行排序，并且无需反序列化，整个过程非常高效，对于内存访问效率和 CPU 使用效率带来了明显的提升[10]。

Spark 的存储内存和执行内存有着截然不同的管理方式：对于存储内存来说，Spark 用一个 LinkedHashMap 来集中管理所有的 Block，Block 由需要缓存的 RDD 的 Partition 转化而成；而对于执行内存，Spark 用 AppendOnlyMap 来存储 Shuffle 过程中的数据，在 Tungsten 排序中甚至抽象成为页式内存管理，开辟了全新的 JVM 内存管理机制。

结束语

Spark 的内存管理是一套复杂的机制，且 Spark 的版本更新比较快，笔者水平有限，难免有叙述不清、错误的地方，若读者有好的建议和更深的理解，还望不吝赐教。

参考资源

Spark性能优化指南——高级篇

2018-04-04T06:28:52.000Z

继基础篇讲解了每个Spark开发人员都必须熟知的开发调优与资源调优之后，本文作为《Spark性能优化指南》的高级篇，将深入分析数据倾斜调优与shuffle调优，以解决更加棘手的性能问题

数据倾斜调优

调优概述

有的时候，我们可能会遇到大数据计算中一个最棘手的问题——数据倾斜，此时Spark作业的性能会比期望差很多。数据倾斜调优，就是使用各种技术方案解决不同类型的数据倾斜问题，以保证Spark作业的性能。

数据倾斜发生时的现象

绝大多数task执行得都非常快，但个别task执行极慢。比如，总共有1000个task，997个task都在1分钟之内执行完了，但是剩余两三个task却要一两个小时。这种情况很常见。
原本能够正常执行的Spark作业，某天突然报出OOM（内存溢出）异常，观察异常栈，是我们写的业务代码造成的。这种情况比较少见。

数据倾斜发生的原理

数据倾斜的原理很简单：在进行shuffle的时候，必须将各个节点上相同的key拉取到某个节点上的一个task来进行处理，比如按照key进行聚合或join等操作。此时如果某个key对应的数据量特别大的话，就会发生数据倾斜。比如大部分key对应10条数据，但是个别key却对应了100万条数据，那么大部分task可能就只会分配到10条数据，然后1秒钟就运行完了；但是个别task可能分配到了100万数据，要运行一两个小时。因此，整个Spark作业的运行进度是由运行时间最长的那个task决定的。

因此出现数据倾斜的时候，Spark作业看起来会运行得非常缓慢，甚至可能因为某个task处理的数据量过大导致内存溢出。

下图就是一个很清晰的例子：hello这个key，在三个节点上对应了总共7条数据，这些数据都会被拉取到同一个task中进行处理；而world和you这两个key分别才对应1条数据，所以另外两个task只要分别处理1条数据即可。此时第一个task的运行时间可能是另外两个task的7倍，而整个stage的运行速度也由运行最慢的那个task所决定。

如何定位导致数据倾斜的代码

数据倾斜只会发生在shuffle过程中。这里给大家罗列一些常用的并且可能会触发shuffle操作的算子：distinct、groupByKey、reduceByKey、aggregateByKey、join、cogroup、repartition等。出现数据倾斜时，可能就是你的代码中使用了这些算子中的某一个所导致的。

某个task执行特别慢的情况

首先要看的，就是数据倾斜发生在第几个stage中。

如果是用yarn-client模式提交，那么本地是直接可以看到log的，可以在log中找到当前运行到了第几个stage；如果是用yarn-cluster模式提交，则可以通过Spark Web UI来查看当前运行到了第几个stage。此外，无论是使用yarn-client模式还是yarn-cluster模式，我们都可以在Spark Web UI上深入看一下当前这个stage各个task分配的数据量，从而进一步确定是不是task分配的数据不均匀导致了数据倾斜。

比如下图中，倒数第三列显示了每个task的运行时间。明显可以看到，有的task运行特别快，只需要几秒钟就可以运行完；而有的task运行特别慢，需要几分钟才能运行完，此时单从运行时间上看就已经能够确定发生数据倾斜了。此外，倒数第一列显示了每个task处理的数据量，明显可以看到，运行时间特别短的task只需要处理几百KB的数据即可，而运行时间特别长的task需要处理几千KB的数据，处理的数据量差了10倍。此时更加能够确定是发生了数据倾斜。

知道数据倾斜发生在哪一个stage之后，接着我们就需要根据stage划分原理，推算出来发生倾斜的那个stage对应代码中的哪一部分，这部分代码中肯定会有一个shuffle类算子。精准推算stage与代码的对应关系，需要对Spark的源码有深入的理解，这里我们可以介绍一个相对简单实用的推算方法：只要看到Spark代码中出现了一个shuffle类算子或者是Spark SQL的SQL语句中出现了会导致shuffle的语句（比如group by语句），那么就可以判定，以那个地方为界限划分出了前后两个stage。

这里我们就以Spark最基础的入门程序——单词计数来举例，如何用最简单的方法大致推算出一个stage对应的代码。如下示例，在整个代码中，只有一个reduceByKey是会发生shuffle的算子，因此就可以认为，以这个算子为界限，会划分出前后两个stage。

stage0，主要是执行从textFile到map操作，以及执行shuffle write操作。shuffle write操作，我们可以简单理解为对pairs RDD中的数据进行分区操作，每个task处理的数据中，相同的key会写入同一个磁盘文件内。
stage1，主要是执行从reduceByKey到collect操作，stage1的各个task一开始运行，就会首先执行shuffle read操作。执行shuffle read操作的task，会从stage0的各个task所在节点拉取属于自己处理的那些key，然后对同一个key进行全局性的聚合或join等操作，在这里就是对key的value值进行累加。stage1在执行完reduceByKey算子之后，就计算出了最终的wordCounts RDD，然后会执行collect算子，将所有数据拉取到Driver上，供我们遍历和打印输出。

val conf = new SparkConf()
val sc = new SparkContext(conf)

val lines = sc.textFile("hdfs://...")
val words = lines.flatMap(_.split(" "))
val pairs = words.map((_, 1))
val wordCounts = pairs.reduceByKey(_ + _)

wordCounts.collect().foreach(println(_))

通过对单词计数程序的分析，希望能够让大家了解最基本的stage划分的原理，以及stage划分后shuffle操作是如何在两个stage的边界处执行的。然后我们就知道如何快速定位出发生数据倾斜的stage对应代码的哪一个部分了。比如我们在Spark Web UI或者本地log中发现，stage1的某几个task执行得特别慢，判定stage1出现了数据倾斜，那么就可以回到代码中定位出stage1主要包括了reduceByKey这个shuffle类算子，此时基本就可以确定是由educeByKey算子导致的数据倾斜问题。比如某个单词出现了100万次，其他单词才出现10次，那么stage1的某个task就要处理100万数据，整个stage的速度就会被这个task拖慢。

某个task莫名其妙内存溢出的情况

这种情况下去定位出问题的代码就比较容易了。我们建议直接看yarn-client模式下本地log的异常栈，或者是通过YARN查看yarn-cluster模式下的log中的异常栈。一般来说，通过异常栈信息就可以定位到你的代码中哪一行发生了内存溢出。然后在那行代码附近找找，一般也会有shuffle类算子，此时很可能就是这个算子导致了数据倾斜。

但是大家要注意的是，不能单纯靠偶然的内存溢出就判定发生了数据倾斜。因为自己编写的代码的bug，以及偶然出现的数据异常，也可能会导致内存溢出。因此还是要按照上面所讲的方法，通过Spark Web UI查看报错的那个stage的各个task的运行时间以及分配的数据量，才能确定是否是由于数据倾斜才导致了这次内存溢出。

查看导致数据倾斜的key的数据分布情况

知道了数据倾斜发生在哪里之后，通常需要分析一下那个执行了shuffle操作并且导致了数据倾斜的RDD/Hive表，查看一下其中key的分布情况。这主要是为之后选择哪一种技术方案提供依据。针对不同的key分布与不同的shuffle算子组合起来的各种情况，可能需要选择不同的技术方案来解决。

此时根据你执行操作的情况不同，可以有很多种查看key分布的方式：

如果是Spark SQL中的group by、join语句导致的数据倾斜，那么就查询一下SQL中使用的表的key分布情况。
如果是对Spark RDD执行shuffle算子导致的数据倾斜，那么可以在Spark作业中加入查看key分布的代码，比如RDD.countByKey()。然后对统计出来的各个key出现的次数，collect/take到客户端打印一下，就可以看到key的分布情况。

举例来说，对于上面所说的单词计数程序，如果确定了是stage1的reduceByKey算子导致了数据倾斜，那么就应该看看进行reduceByKey操作的RDD中的key分布情况，在这个例子中指的就是pairs RDD。如下示例，我们可以先对pairs采样10%的样本数据，然后使用countByKey算子统计出每个key出现的次数，最后在客户端遍历和打印样本数据中各个key的出现次数。

1
2
3

val sampledPairs = pairs.sample(false, 0.1)
val sampledWordCounts = sampledPairs.countByKey()
sampledWordCounts.foreach(println(_))

数据倾斜的解决方案

解决方案一：使用Hive ETL预处理数据

方案适用场景：导致数据倾斜的是Hive表。如果该Hive表中的数据本身很不均匀（比如某个key对应了100万数据，其他key才对应了10条数据），而且业务场景需要频繁使用Spark对Hive表执行某个分析操作，那么比较适合使用这种技术方案。

方案实现思路：此时可以评估一下，是否可以通过Hive来进行数据预处理（即通过Hive ETL预先对数据按照key进行聚合，或者是预先和其他表进行join），然后在Spark作业中针对的数据源就不是原来的Hive表了，而是预处理后的Hive表。此时由于数据已经预先进行过聚合或join操作了，那么在Spark作业中也就不需要使用原先的shuffle类算子执行这类操作了。

方案实现原理：这种方案从根源上解决了数据倾斜，因为彻底避免了在Spark中执行shuffle类算子，那么肯定就不会有数据倾斜的问题了。但是这里也要提醒一下大家，这种方式属于治标不治本。因为毕竟数据本身就存在分布不均匀的问题，所以Hive ETL中进行group by或者join等shuffle操作时，还是会出现数据倾斜，导致Hive ETL的速度很慢。我们只是把数据倾斜的发生提前到了Hive ETL中，避免Spark程序发生数据倾斜而已。

方案优点：实现起来简单便捷，效果还非常好，完全规避掉了数据倾斜，Spark作业的性能会大幅度提升。

方案缺点：治标不治本，Hive ETL中还是会发生数据倾斜。

方案实践经验：在一些Java系统与Spark结合使用的项目中，会出现Java代码频繁调用Spark作业的场景，而且对Spark作业的执行性能要求很高，就比较适合使用这种方案。将数据倾斜提前到上游的Hive ETL，每天仅执行一次，只有那一次是比较慢的，而之后每次Java调用Spark作业时，执行速度都会很快，能够提供更好的用户体验。

项目实践经验：在美团·点评的交互式用户行为分析系统中使用了这种方案，该系统主要是允许用户通过Java Web系统提交数据分析统计任务，后端通过Java提交Spark作业进行数据分析统计。要求Spark作业速度必须要快，尽量在10分钟以内，否则速度太慢，用户体验会很差。所以我们将有些Spark作业的shuffle操作提前到了Hive ETL中，从而让Spark直接使用预处理的Hive中间表，尽可能地减少Spark的shuffle操作，大幅度提升了性能，将部分作业的性能提升了6倍以上。

解决方案二：过滤少数导致倾斜的key

方案适用场景：如果发现导致倾斜的key就少数几个，而且对计算本身的影响并不大的话，那么很适合使用这种方案。比如99%的key就对应10条数据，但是只有一个key对应了100万数据，从而导致了数据倾斜。

方案实现思路：如果我们判断那少数几个数据量特别多的key，对作业的执行和计算结果不是特别重要的话，那么干脆就直接过滤掉那少数几个key。比如，在Spark SQL中可以使用where子句过滤掉这些key或者在Spark Core中对RDD执行filter算子过滤掉这些key。如果需要每次作业执行时，动态判定哪些key的数据量最多然后再进行过滤，那么可以使用sample算子对RDD进行采样，然后计算出每个key的数量，取数据量最多的key过滤掉即可。

方案实现原理：将导致数据倾斜的key给过滤掉之后，这些key就不会参与计算了，自然不可能产生数据倾斜。

方案优点：实现简单，而且效果也很好，可以完全规避掉数据倾斜。

方案缺点：适用场景不多，大多数情况下，导致倾斜的key还是很多的，并不是只有少数几个。

方案实践经验：在项目中我们也采用过这种方案解决数据倾斜。有一次发现某一天Spark作业在运行的时候突然OOM了，追查之后发现，是Hive表中的某一个key在那天数据异常，导致数据量暴增。因此就采取每次执行前先进行采样，计算出样本中数据量最大的几个key之后，直接在程序中将那些key给过滤掉。

解决方案三：提高shuffle操作的并行度

方案适用场景：如果我们必须要对数据倾斜迎难而上，那么建议优先使用这种方案，因为这是处理数据倾斜最简单的一种方案。

方案实现思路：在对RDD执行shuffle算子时，给shuffle算子传入一个参数，比如reduceByKey(1000)，该参数就设置了这个shuffle算子执行时shuffle read task的数量。对于Spark SQL中的shuffle类语句，比如group by、join等，需要设置一个参数，即spark.sql.shuffle.partitions，该参数代表了shuffle read task的并行度，该值默认是200，对于很多场景来说都有点过小。

方案实现原理：增加shuffle read task的数量，可以让原本分配给一个task的多个key分配给多个task，从而让每个task处理比原来更少的数据。举例来说，如果原本有5个key，每个key对应10条数据，这5个key都是分配给一个task的，那么这个task就要处理50条数据。而增加了shuffle read task以后，每个task就分配到一个key，即每个task就处理10条数据，那么自然每个task的执行时间都会变短了。具体原理如下图所示。

方案优点：实现起来比较简单，可以有效缓解和减轻数据倾斜的影响。

方案缺点：只是缓解了数据倾斜而已，没有彻底根除问题，根据实践经验来看，其效果有限。

方案实践经验：该方案通常无法彻底解决数据倾斜，因为如果出现一些极端情况，比如某个key对应的数据量有100万，那么无论你的task数量增加到多少，这个对应着100万数据的key肯定还是会分配到一个task中去处理，因此注定还是会发生数据倾斜的。所以这种方案只能说是在发现数据倾斜时尝试使用的第一种手段，尝试去用嘴简单的方法缓解数据倾斜而已，或者是和其他方案结合起来使用。

解决方案四：两阶段聚合（局部聚合+全局聚合）

方案适用场景：对RDD执行reduceByKey等聚合类shuffle算子或者在Spark SQL中使用group by语句进行分组聚合时，比较适用这种方案。

方案实现思路：这个方案的核心实现思路就是进行两阶段聚合。第一次是局部聚合，先给每个key都打上一个随机数，比如10以内的随机数，此时原先一样的key就变成不一样的了，比如(hello, 1) (hello, 1) (hello, 1) (hello, 1)，就会变成(1_hello, 1) (1_hello, 1) (2_hello, 1) (2_hello, 1)。接着对打上随机数后的数据，执行reduceByKey等聚合操作，进行局部聚合，那么局部聚合结果，就会变成了(1_hello, 2) (2_hello, 2)。然后将各个key的前缀给去掉，就会变成(hello,2)(hello,2)，再次进行全局聚合操作，就可以得到最终结果了，比如(hello, 4)。

方案实现原理：将原本相同的key通过附加随机前缀的方式，变成多个不同的key，就可以让原本被一个task处理的数据分散到多个task上去做局部聚合，进而解决单个task处理数据量过多的问题。接着去除掉随机前缀，再次进行全局聚合，就可以得到最终的结果。具体原理见下图。

方案优点：对于聚合类的shuffle操作导致的数据倾斜，效果是非常不错的。通常都可以解决掉数据倾斜，或者至少是大幅度缓解数据倾斜，将Spark作业的性能提升数倍以上。

方案缺点：仅仅适用于聚合类的shuffle操作，适用范围相对较窄。如果是join类的shuffle操作，还得用其他的解决方案。

// 第一步，给RDD中的每个key都打上一个随机前缀。
JavaPairRDD randomPrefixRdd = rdd.mapToPair(
 new PairFunction, String, Long>() {
 private static final long serialVersionUID = 1L;
 @Override
 public Tuple2 call(Tuple2 tuple)
 throws Exception {
 Random random = new Random();
 int prefix = random.nextInt(10);
 return new Tuple2(prefix + "_" + tuple._1, tuple._2);
 }
 });

// 第二步，对打上随机前缀的key进行局部聚合。
JavaPairRDD localAggrRdd = randomPrefixRdd.reduceByKey(
 new Function2() {
 private static final long serialVersionUID = 1L;
 @Override
 public Long call(Long v1, Long v2) throws Exception {
 return v1 + v2;
 }
 });

// 第三步，去除RDD中每个key的随机前缀。
JavaPairRDD removedRandomPrefixRdd = localAggrRdd.mapToPair(
 new PairFunction, Long, Long>() {
 private static final long serialVersionUID = 1L;
 @Override
 public Tuple2 call(Tuple2 tuple)
 throws Exception {
 long originalKey = Long.valueOf(tuple._1.split("_")[1]);
 return new Tuple2(originalKey, tuple._2);
 }
 });

// 第四步，对去除了随机前缀的RDD进行全局聚合。
JavaPairRDD globalAggrRdd = removedRandomPrefixRdd.reduceByKey(
 new Function2() {
 private static final long serialVersionUID = 1L;
 @Override
 public Long call(Long v1, Long v2) throws Exception {
 return v1 + v2;
 }
 });

解决方案五：将reduce join转为map join

方案适用场景：在对RDD使用join类操作，或者是在Spark SQL中使用join语句时，而且join操作中的一个RDD或表的数据量比较小（比如几百M或者一两G），比较适用此方案。

方案实现思路：不使用join算子进行连接操作，而使用Broadcast变量与map类算子实现join操作，进而完全规避掉shuffle类的操作，彻底避免数据倾斜的发生和出现。将较小RDD中的数据直接通过collect算子拉取到Driver端的内存中来，然后对其创建一个Broadcast变量；接着对另外一个RDD执行map类算子，在算子函数内，从Broadcast变量中获取较小RDD的全量数据，与当前RDD的每一条数据按照连接key进行比对，如果连接key相同的话，那么就将两个RDD的数据用你需要的方式连接起来。

方案实现原理：普通的join是会走shuffle过程的，而一旦shuffle，就相当于会将相同key的数据拉取到一个shuffle read task中再进行join，此时就是reduce join。但是如果一个RDD是比较小的，则可以采用广播小RDD全量数据+map算子来实现与join同样的效果，也就是map join，此时就不会发生shuffle操作，也就不会发生数据倾斜。具体原理如下图所示。

方案优点：对join操作导致的数据倾斜，效果非常好，因为根本就不会发生shuffle，也就根本不会发生数据倾斜。

方案缺点：适用场景较少，因为这个方案只适用于一个大表和一个小表的情况。毕竟我们需要将小表进行广播，此时会比较消耗内存资源，driver和每个Executor内存中都会驻留一份小RDD的全量数据。如果我们广播出去的RDD数据比较大，比如10G以上，那么就可能发生内存溢出了。因此并不适合两个都是大表的情况。

// 首先将数据量比较小的RDD的数据，collect到Driver中来。
List> rdd1Data = rdd1.collect()
// 然后使用Spark的广播功能，将小RDD的数据转换成广播变量，这样每个Executor就只有一份RDD的数据。
// 可以尽可能节省内存空间，并且减少网络传输性能开销。
final Broadcast>> rdd1DataBroadcast = sc.broadcast(rdd1Data);

// 对另外一个RDD执行map类操作，而不再是join类操作。
JavaPairRDD> joinedRdd = rdd2.mapToPair(
 new PairFunction, String, Tuple2>() {
 private static final long serialVersionUID = 1L;
 @Override
 public Tuple2> call(Tuple2 tuple)
 throws Exception {
 // 在算子函数中，通过广播变量，获取到本地Executor中的rdd1数据。
 List> rdd1Data = rdd1DataBroadcast.value();
 // 可以将rdd1的数据转换为一个Map，便于后面进行join操作。
 Map rdd1DataMap = new HashMap();
 for(Tuple2 data : rdd1Data) {
 rdd1DataMap.put(data._1, data._2);
 }
 // 获取当前RDD数据的key以及value。
 String key = tuple._1;
 String value = tuple._2;
 // 从rdd1数据Map中，根据key获取到可以join到的数据。
 Row rdd1Value = rdd1DataMap.get(key);
 return new Tuple2(key, new Tuple2(value, rdd1Value));
 }
 });

// 这里得提示一下。
// 上面的做法，仅仅适用于rdd1中的key没有重复，全部是唯一的场景。
// 如果rdd1中有多个相同的key，那么就得用flatMap类的操作，在进行join的时候不能用map，而是得遍历rdd1所有数据进行join。
// rdd2中每条数据都可能会返回多条join后的数据。

解决方案六：采样倾斜key并分拆join操作

方案适用场景：两个RDD/Hive表进行join的时候，如果数据量都比较大，无法采用“解决方案五”，那么此时可以看一下两个RDD/Hive表中的key分布情况。如果出现数据倾斜，是因为其中某一个RDD/Hive表中的少数几个key的数据量过大，而另一个RDD/Hive表中的所有key都分布比较均匀，那么采用这个解决方案是比较合适的。

方案实现思路：

对包含少数几个数据量过大的key的那个RDD，通过sample算子采样出一份样本来，然后统计一下每个key的数量，计算出来数据量最大的是哪几个key。
然后将这几个key对应的数据从原来的RDD中拆分出来，形成一个单独的RDD，并给每个key都打上n以内的随机数作为前缀，而不会导致倾斜的大部分key形成另外一个RDD。
接着将需要join的另一个RDD，也过滤出来那几个倾斜key对应的数据并形成一个单独的RDD，将每条数据膨胀成n条数据，这n条数据都按顺序附加一个0~n的前缀，不会导致倾斜的大部分key也形成另外一个RDD。
再将附加了随机前缀的独立RDD与另一个膨胀n倍的独立RDD进行join，此时就可以将原先相同的key打散成n份，分散到多个task中去进行join了。
而另外两个普通的RDD就照常join即可。
最后将两次join的结果使用union算子合并起来即可，就是最终的join结果。

方案实现原理：对于join导致的数据倾斜，如果只是某几个key导致了倾斜，可以将少数几个key分拆成独立RDD，并附加随机前缀打散成n份去进行join，此时这几个key对应的数据就不会集中在少数几个task上，而是分散到多个task进行join了。具体原理见下图。

方案优点：对于join导致的数据倾斜，如果只是某几个key导致了倾斜，采用该方式可以用最有效的方式打散key进行join。而且只需要针对少数倾斜key对应的数据进行扩容n倍，不需要对全量数据进行扩容。避免了占用过多内存。

方案缺点：如果导致倾斜的key特别多的话，比如成千上万个key都导致数据倾斜，那么这种方式也不适合。

// 首先从包含了少数几个导致数据倾斜key的rdd1中，采样10%的样本数据。
JavaPairRDD sampledRDD = rdd1.sample(false, 0.1);

// 对样本数据RDD统计出每个key的出现次数，并按出现次数降序排序。
// 对降序排序后的数据，取出top 1或者top 100的数据，也就是key最多的前n个数据。
// 具体取出多少个数据量最多的key，由大家自己决定，我们这里就取1个作为示范。
JavaPairRDD mappedSampledRDD = sampledRDD.mapToPair(
 new PairFunction, Long, Long>() {
 private static final long serialVersionUID = 1L;
 @Override
 public Tuple2 call(Tuple2 tuple)
 throws Exception {
 return new Tuple2(tuple._1, 1L);
 } 
 });
JavaPairRDD countedSampledRDD = mappedSampledRDD.reduceByKey(
 new Function2() {
 private static final long serialVersionUID = 1L;
 @Override
 public Long call(Long v1, Long v2) throws Exception {
 return v1 + v2;
 }
 });
JavaPairRDD reversedSampledRDD = countedSampledRDD.mapToPair( 
 new PairFunction, Long, Long>() {
 private static final long serialVersionUID = 1L;
 @Override
 public Tuple2 call(Tuple2 tuple)
 throws Exception {
 return new Tuple2(tuple._2, tuple._1);
 }
 });
final Long skewedUserid = reversedSampledRDD.sortByKey(false).take(1).get(0)._2;

// 从rdd1中分拆出导致数据倾斜的key，形成独立的RDD。
JavaPairRDD skewedRDD = rdd1.filter(
 new Function, Boolean>() {
 private static final long serialVersionUID = 1L;
 @Override
 public Boolean call(Tuple2 tuple) throws Exception {
 return tuple._1.equals(skewedUserid);
 }
 });
// 从rdd1中分拆出不导致数据倾斜的普通key，形成独立的RDD。
JavaPairRDD commonRDD = rdd1.filter(
 new Function, Boolean>() {
 private static final long serialVersionUID = 1L;
 @Override
 public Boolean call(Tuple2 tuple) throws Exception {
 return !tuple._1.equals(skewedUserid);
 } 
 });

// rdd2，就是那个所有key的分布相对较为均匀的rdd。
// 这里将rdd2中，前面获取到的key对应的数据，过滤出来，分拆成单独的rdd，并对rdd中的数据使用flatMap算子都扩容100倍。
// 对扩容的每条数据，都打上0～100的前缀。
JavaPairRDD skewedRdd2 = rdd2.filter(
 new Function, Boolean>() {
 private static final long serialVersionUID = 1L;
 @Override
 public Boolean call(Tuple2 tuple) throws Exception {
 return tuple._1.equals(skewedUserid);
 }
 }).flatMapToPair(new PairFlatMapFunction, String, Row>() {
 private static final long serialVersionUID = 1L;
 @Override
 public Iterable> call(
 Tuple2 tuple) throws Exception {
 Random random = new Random();
 List> list = new ArrayList>();
 for(int i = 0; i 
 list.add(new Tuple2(i + "_" + tuple._1, tuple._2));
 }
 return list;
 }

 });

// 将rdd1中分拆出来的导致倾斜的key的独立rdd，每条数据都打上100以内的随机前缀。
// 然后将这个rdd1中分拆出来的独立rdd，与上面rdd2中分拆出来的独立rdd，进行join。
JavaPairRDD> joinedRDD1 = skewedRDD.mapToPair(
 new PairFunction, String, String>() {
 private static final long serialVersionUID = 1L;
 @Override
 public Tuple2 call(Tuple2 tuple)
 throws Exception {
 Random random = new Random();
 int prefix = random.nextInt(100);
 return new Tuple2(prefix + "_" + tuple._1, tuple._2);
 }
 })
 .join(skewedUserid2infoRDD)
 .mapToPair(new PairFunction>, Long, Tuple2>() {
 private static final long serialVersionUID = 1L;
 @Override
 public Tuple2> call(
 Tuple2> tuple)
 throws Exception {
 long key = Long.valueOf(tuple._1.split("_")[1]);
 return new Tuple2>(key, tuple._2);
 }
 });

// 将rdd1中分拆出来的包含普通key的独立rdd，直接与rdd2进行join。
JavaPairRDD> joinedRDD2 = commonRDD.join(rdd2);

// 将倾斜key join后的结果与普通key join后的结果，uinon起来。
// 就是最终的join结果。
JavaPairRDD> joinedRDD = joinedRDD1.union(joinedRDD2);

解决方案七：使用随机前缀和扩容RDD进行join

方案适用场景：如果在进行join操作时，RDD中有大量的key导致数据倾斜，那么进行分拆key也没什么意义，此时就只能使用最后一种方案来解决问题了。

方案实现思路：

该方案的实现思路基本和“解决方案六”类似，首先查看RDD/Hive表中的数据分布情况，找到那个造成数据倾斜的RDD/Hive表，比如有多个key都对应了超过1万条数据。
然后将该RDD的每条数据都打上一个n以内的随机前缀。
同时对另外一个正常的RDD进行扩容，将每条数据都扩容成n条数据，扩容出来的每条数据都依次打上一个0~n的前缀。
最后将两个处理后的RDD进行join即可。

方案实现原理：将原先一样的key通过附加随机前缀变成不一样的key，然后就可以将这些处理后的“不同key”分散到多个task中去处理，而不是让一个task处理大量的相同key。该方案与“解决方案六”的不同之处就在于，上一种方案是尽量只对少数倾斜key对应的数据进行特殊处理，由于处理过程需要扩容RDD，因此上一种方案扩容RDD后对内存的占用并不大；而这一种方案是针对有大量倾斜key的情况，没法将部分key拆分出来进行单独处理，因此只能对整个RDD进行数据扩容，对内存资源要求很高。

方案优点：对join类型的数据倾斜基本都可以处理，而且效果也相对比较显著，性能提升效果非常不错。

方案缺点：该方案更多的是缓解数据倾斜，而不是彻底避免数据倾斜。而且需要对整个RDD进行扩容，对内存资源要求很高。

方案实践经验：曾经开发一个数据需求的时候，发现一个join导致了数据倾斜。优化之前，作业的执行时间大约是60分钟左右；使用该方案优化之后，执行时间缩短到10分钟左右，性能提升了6倍。

// 首先将其中一个key分布相对较为均匀的RDD膨胀100倍。
JavaPairRDD expandedRDD = rdd1.flatMapToPair(
 new PairFlatMapFunction, String, Row>() {
 private static final long serialVersionUID = 1L;
 @Override
 public Iterable> call(Tuple2 tuple)
 throws Exception {
 List> list = new ArrayList>();
 for(int i = 0; i 
 list.add(new Tuple2(0 + "_" + tuple._1, tuple._2));
 }
 return list;
 }
 });

// 其次，将另一个有数据倾斜key的RDD，每条数据都打上100以内的随机前缀。
JavaPairRDD mappedRDD = rdd2.mapToPair(
 new PairFunction, String, String>() {
 private static final long serialVersionUID = 1L;
 @Override
 public Tuple2 call(Tuple2 tuple)
 throws Exception {
 Random random = new Random();
 int prefix = random.nextInt(100);
 return new Tuple2(prefix + "_" + tuple._1, tuple._2);
 }
 });

// 将两个处理后的RDD进行join即可。
JavaPairRDD> joinedRDD = mappedRDD.join(expandedRDD);

解决方案八：多种方案组合使用

在实践中发现，很多情况下，如果只是处理较为简单的数据倾斜场景，那么使用上述方案中的某一种基本就可以解决。但是如果要处理一个较为复杂的数据倾斜场景，那么可能需要将多种方案组合起来使用。比如说，我们针对出现了多个数据倾斜环节的Spark作业，可以先运用解决方案一和二，预处理一部分数据，并过滤一部分数据来缓解；其次可以对某些shuffle操作提升并行度，优化其性能；最后还可以针对不同的聚合或join操作，选择一种方案来优化其性能。大家需要对这些方案的思路和原理都透彻理解之后，在实践中根据各种不同的情况，灵活运用多种方案，来解决自己的数据倾斜问题。

shuffle调优

调优概述

大多数Spark作业的性能主要就是消耗在了shuffle环节，因为该环节包含了大量的磁盘IO、序列化、网络数据传输等操作。因此，如果要让作业的性能更上一层楼，就有必要对shuffle过程进行调优。但是也必须提醒大家的是，影响一个Spark作业性能的因素，主要还是代码开发、资源参数以及数据倾斜，shuffle调优只能在整个Spark的性能调优中占到一小部分而已。因此大家务必把握住调优的基本原则，千万不要舍本逐末。下面我们就给大家详细讲解shuffle的原理，以及相关参数的说明，同时给出各个参数的调优建议。

ShuffleManager发展概述

在Spark的源码中，负责shuffle过程的执行、计算和处理的组件主要就是ShuffleManager，也即shuffle管理器。而随着Spark的版本的发展，ShuffleManager也在不断迭代，变得越来越先进。

在Spark 1.2以前，默认的shuffle计算引擎是HashShuffleManager。该ShuffleManager而HashShuffleManager有着一个非常严重的弊端，就是会产生大量的中间磁盘文件，进而由大量的磁盘IO操作影响了性能。

因此在Spark 1.2以后的版本中，默认的ShuffleManager改成了SortShuffleManager。SortShuffleManager相较于HashShuffleManager来说，有了一定的改进。主要就在于，每个Task在进行shuffle操作时，虽然也会产生较多的临时磁盘文件，但是最后会将所有的临时文件合并（merge）成一个磁盘文件，因此每个Task就只有一个磁盘文件。在下一个stage的shuffle read task拉取自己的数据时，只要根据索引读取每个磁盘文件中的部分数据即可。

下面我们详细分析一下HashShuffleManager和SortShuffleManager的原理。

HashShuffleManager运行原理

未经优化的HashShuffleManager

下图说明了未经优化的HashShuffleManager的原理。这里我们先明确一个假设前提：每个Executor只有1个CPU core，也就是说，无论这个Executor上分配多少个task线程，同一时间都只能执行一个task线程。

我们先从shuffle write开始说起。shuffle write阶段，主要就是在一个stage结束计算之后，为了下一个stage可以执行shuffle类的算子（比如reduceByKey），而将每个task处理的数据按key进行“分类”。所谓“分类”，就是对相同的key执行hash算法，从而将相同key都写入同一个磁盘文件中，而每一个磁盘文件都只属于下游stage的一个task。在将数据写入磁盘之前，会先将数据写入内存缓冲中，当内存缓冲填满之后，才会溢写到磁盘文件中去。

那么每个执行shuffle write的task，要为下一个stage创建多少个磁盘文件呢？很简单，下一个stage的task有多少个，当前stage的每个task就要创建多少份磁盘文件。比如下一个stage总共有100个task，那么当前stage的每个task都要创建100份磁盘文件。如果当前stage有50个task，总共有10个Executor，每个Executor执行5个Task，那么每个Executor上总共就要创建500个磁盘文件，所有Executor上会创建5000个磁盘文件。由此可见，未经优化的shuffle write操作所产生的磁盘文件的数量是极其惊人的。

接着我们来说说shuffle read。shuffle read，通常就是一个stage刚开始时要做的事情。此时该stage的每一个task就需要将上一个stage的计算结果中的所有相同key，从各个节点上通过网络都拉取到自己所在的节点上，然后进行key的聚合或连接等操作。由于shuffle write的过程中，task给下游stage的每个task都创建了一个磁盘文件，因此shuffle read的过程中，每个task只要从上游stage的所有task所在节点上，拉取属于自己的那一个磁盘文件即可。

shuffle read的拉取过程是一边拉取一边进行聚合的。每个shuffle read task都会有一个自己的buffer缓冲，每次都只能拉取与buffer缓冲相同大小的数据，然后通过内存中的一个Map进行聚合等操作。聚合完一批数据后，再拉取下一批数据，并放到buffer缓冲中进行聚合操作。以此类推，直到最后将所有数据到拉取完，并得到最终的结果。

优化后的HashShuffleManager

下图说明了优化后的HashShuffleManager的原理。这里说的优化，是指我们可以设置一个参数，spark.shuffle.consolidateFiles。该参数默认值为false，将其设置为true即可开启优化机制。通常来说，如果我们使用HashShuffleManager，那么都建议开启这个选项。

开启consolidate机制之后，在shuffle write过程中，task就不是为下游stage的每个task创建一个磁盘文件了。此时会出现shuffleFileGroup的概念，每个shuffleFileGroup会对应一批磁盘文件，磁盘文件的数量与下游stage的task数量是相同的。一个Executor上有多少个CPU core，就可以并行执行多少个task。而第一批并行执行的每个task都会创建一个shuffleFileGroup，并将数据写入对应的磁盘文件内。

当Executor的CPU core执行完一批task，接着执行下一批task时，下一批task就会复用之前已有的shuffleFileGroup，包括其中的磁盘文件。也就是说，此时task会将数据写入已有的磁盘文件中，而不会写入新的磁盘文件中。因此，consolidate机制允许不同的task复用同一批磁盘文件，这样就可以有效将多个task的磁盘文件进行一定程度上的合并，从而大幅度减少磁盘文件的数量，进而提升shuffle write的性能。

假设第二个stage有100个task，第一个stage有50个task，总共还是有10个Executor，每个Executor执行5个task。那么原本使用未经优化的HashShuffleManager时，每个Executor会产生500个磁盘文件，所有Executor会产生5000个磁盘文件的。但是此时经过优化之后，每个Executor创建的磁盘文件的数量的计算公式为：CPU core的数量 * 下一个stage的task数量。也就是说，每个Executor此时只会创建100个磁盘文件，所有Executor只会创建1000个磁盘文件。

SortShuffleManager运行原理

SortShuffleManager的运行机制主要分成两种，一种是普通运行机制，另一种是bypass运行机制。当shuffle read task的数量小于等于spark.shuffle.sort.bypassMergeThreshold参数的值时（默认为200），就会启用bypass机制。

普通运行机制

下图说明了普通的SortShuffleManager的原理。在该模式下，数据会先写入一个内存数据结构中，此时根据不同的shuffle算子，可能选用不同的数据结构。如果是reduceByKey这种聚合类的shuffle算子，那么会选用Map数据结构，一边通过Map进行聚合，一边写入内存；如果是join这种普通的shuffle算子，那么会选用Array数据结构，直接写入内存。接着，每写一条数据进入内存数据结构之后，就会判断一下，是否达到了某个临界阈值。如果达到临界阈值的话，那么就会尝试将内存数据结构中的数据溢写到磁盘，然后清空内存数据结构。

在溢写到磁盘文件之前，会先根据key对内存数据结构中已有的数据进行排序。排序过后，会分批将数据写入磁盘文件。默认的batch数量是10000条，也就是说，排序好的数据，会以每批1万条数据的形式分批写入磁盘文件。写入磁盘文件是通过Java的BufferedOutputStream实现的。BufferedOutputStream是Java的缓冲输出流，首先会将数据缓冲在内存中，当内存缓冲满溢之后再一次写入磁盘文件中，这样可以减少磁盘IO次数，提升性能。

一个task将所有数据写入内存数据结构的过程中，会发生多次磁盘溢写操作，也就会产生多个临时文件。最后会将之前所有的临时磁盘文件都进行合并，这就是merge过程，此时会将之前所有临时磁盘文件中的数据读取出来，然后依次写入最终的磁盘文件之中。此外，由于一个task就只对应一个磁盘文件，也就意味着该task为下游stage的task准备的数据都在这一个文件中，因此还会单独写一份索引文件，其中标识了下游各个task的数据在文件中的start offset与end offset。

SortShuffleManager由于有一个磁盘文件merge的过程，因此大大减少了文件数量。比如第一个stage有50个task，总共有10个Executor，每个Executor执行5个task，而第二个stage有100个task。由于每个task最终只有一个磁盘文件，因此此时每个Executor上只有5个磁盘文件，所有Executor只有50个磁盘文件。

bypass运行机制

下图说明了bypass SortShuffleManager的原理。bypass运行机制的触发条件如下：

shuffle map task数量小于spark.shuffle.sort.bypassMergeThreshold参数的值。
不是聚合类的shuffle算子（比如reduceByKey）。

此时task会为每个下游task都创建一个临时磁盘文件，并将数据按key进行hash然后根据key的hash值，将key写入对应的磁盘文件之中。当然，写入磁盘文件时也是先写入内存缓冲，缓冲写满之后再溢写到磁盘文件的。最后，同样会将所有临时磁盘文件都合并成一个磁盘文件，并创建一个单独的索引文件。

该过程的磁盘写机制其实跟未经优化的HashShuffleManager是一模一样的，因为都要创建数量惊人的磁盘文件，只是在最后会做一个磁盘文件的合并而已。因此少量的最终磁盘文件，也让该机制相对未经优化的HashShuffleManager来说，shuffle read的性能会更好。

而该机制与普通SortShuffleManager运行机制的不同在于：第一，磁盘写机制不同；第二，不会进行排序。也就是说，启用该机制的最大好处在于，shuffle write过程中，不需要进行数据的排序操作，也就节省掉了这部分的性能开销。

shuffle相关参数调优

以下是Shffule过程中的一些主要参数，这里详细讲解了各个参数的功能、默认值以及基于实践经验给出的调优建议。

spark.shuffle.file.buffer

默认值：32k
参数说明：该参数用于设置shuffle write task的BufferedOutputStream的buffer缓冲大小。将数据写到磁盘文件之前，会先写入buffer缓冲中，待缓冲写满之后，才会溢写到磁盘。
调优建议：如果作业可用的内存资源较为充足的话，可以适当增加这个参数的大小（比如64k），从而减少shuffle write过程中溢写磁盘文件的次数，也就可以减少磁盘IO次数，进而提升性能。在实践中发现，合理调节该参数，性能会有1%~5%的提升。

spark.reducer.maxSizeInFlight

默认值：48m
参数说明：该参数用于设置shuffle read task的buffer缓冲大小，而这个buffer缓冲决定了每次能够拉取多少数据。
调优建议：如果作业可用的内存资源较为充足的话，可以适当增加这个参数的大小（比如96m），从而减少拉取数据的次数，也就可以减少网络传输的次数，进而提升性能。在实践中发现，合理调节该参数，性能会有1%~5%的提升。

spark.shuffle.io.maxRetries

默认值：3
参数说明：shuffle read task从shuffle write task所在节点拉取属于自己的数据时，如果因为网络异常导致拉取失败，是会自动进行重试的。该参数就代表了可以重试的最大次数。如果在指定次数之内拉取还是没有成功，就可能会导致作业执行失败。
调优建议：对于那些包含了特别耗时的shuffle操作的作业，建议增加重试最大次数（比如60次），以避免由于JVM的full gc或者网络不稳定等因素导致的数据拉取失败。在实践中发现，对于针对超大数据量（数十亿~上百亿）的shuffle过程，调节该参数可以大幅度提升稳定性。

spark.shuffle.io.retryWait

默认值：5s
参数说明：具体解释同上，该参数代表了每次重试拉取数据的等待间隔，默认是5s。
调优建议：建议加大间隔时长（比如60s），以增加shuffle操作的稳定性。

spark.shuffle.memoryFraction

默认值：0.2
参数说明：该参数代表了Executor内存中，分配给shuffle read task进行聚合操作的内存比例，默认是20%。
调优建议：在资源参数调优中讲解过这个参数。如果内存充足，而且很少使用持久化操作，建议调高这个比例，给shuffle read的聚合操作更多内存，以避免由于内存不足导致聚合过程中频繁读写磁盘。在实践中发现，合理调节该参数可以将性能提升10%左右。

spark.shuffle.manager

默认值：sort
参数说明：该参数用于设置ShuffleManager的类型。Spark 1.5以后，有三个可选项：hash、sort和tungsten-sort。HashShuffleManager是Spark 1.2以前的默认选项，但是Spark 1.2以及之后的版本默认都是SortShuffleManager了。tungsten-sort与sort类似，但是使用了tungsten计划中的堆外内存管理机制，内存使用效率更高。
调优建议：由于SortShuffleManager默认会对数据进行排序，因此如果你的业务逻辑中需要该排序机制的话，则使用默认的SortShuffleManager就可以；而如果你的业务逻辑不需要对数据进行排序，那么建议参考后面的几个参数调优，通过bypass机制或优化的HashShuffleManager来避免排序操作，同时提供较好的磁盘读写性能。这里要注意的是，tungsten-sort要慎用，因为之前发现了一些相应的bug。

spark.shuffle.sort.bypassMergeThreshold

默认值：200
参数说明：当ShuffleManager为SortShuffleManager时，如果shuffle read task的数量小于这个阈值（默认是200），则shuffle write过程中不会进行排序操作，而是直接按照未经优化的HashShuffleManager的方式去写数据，但是最后会将每个task产生的所有临时磁盘文件都合并成一个文件，并会创建单独的索引文件。
调优建议：当你使用SortShuffleManager时，如果的确不需要排序操作，那么建议将这个参数调大一些，大于shuffle read task的数量。那么此时就会自动启用bypass机制，map-side就不会进行排序了，减少了排序的性能开销。但是这种方式下，依然会产生大量的磁盘文件，因此shuffle write性能有待提高。

spark.shuffle.consolidateFiles

默认值：false
参数说明：如果使用HashShuffleManager，该参数有效。如果设置为true，那么就会开启consolidate机制，会大幅度合并shuffle write的输出文件，对于shuffle read task数量特别多的情况下，这种方法可以极大地减少磁盘IO开销，提升性能。
调优建议：如果的确不需要SortShuffleManager的排序机制，那么除了使用bypass机制，还可以尝试将spark.shffle.manager参数手动指定为hash，使用HashShuffleManager，同时开启consolidate机制。在实践中尝试过，发现其性能比开启了bypass机制的SortShuffleManager要高出10%~30%。

写在最后的话

本文分别讲解了开发过程中的优化原则、运行前的资源参数设置调优、运行中的数据倾斜的解决方案、为了精益求精的shuffle调优。希望大家能够在阅读本文之后，记住这些性能调优的原则以及方案，在Spark作业开发、测试以及运行的过程中多尝试，只有这样，我们才能开发出更优的Spark作业，不断提升其性能。

Spark性能优化指南——基础篇

2018-04-04T05:56:57.000Z

在大数据计算领域，Spark已经成为了越来越流行、越来越受欢迎的计算平台之一。Spark的功能涵盖了大数据领域的离线批处理、SQL类处理、流式/实时计算、机器学习、图计算等各种不同类型的计算操作，应用范围与前景非常广泛。在美团•大众点评，已经有很多同学在各种项目中尝试使用Spark。大多数同学（包括笔者在内），最初开始尝试使用Spark的原因很简单，主要就是为了让大数据计算作业的执行速度更快、性能更高。

然而，通过Spark开发出高性能的大数据计算作业，并不是那么简单的。如果没有对Spark作业进行合理的调优，Spark作业的执行速度可能会很慢，这样就完全体现不出Spark作为一种快速大数据计算引擎的优势来。因此，想要用好Spark，就必须对其进行合理的性能优化。

Spark的性能调优实际上是由很多部分组成的，不是调节几个参数就可以立竿见影提升作业性能的。我们需要根据不同的业务场景以及数据情况，对Spark作业进行综合性的分析，然后进行多个方面的调节和优化，才能获得最佳性能。

笔者根据之前的Spark作业开发经验以及实践积累，总结出了一套Spark作业的性能优化方案。整套方案主要分为开发调优、资源调优、数据倾斜调优、shuffle调优几个部分。开发调优和资源调优是所有Spark作业都需要注意和遵循的一些基本原则，是高性能Spark作业的基础；数据倾斜调优，主要讲解了一套完整的用来解决Spark作业数据倾斜的解决方案；shuffle调优，面向的是对Spark的原理有较深层次掌握和研究的同学，主要讲解了如何对Spark作业的shuffle运行过程以及细节进行调优。

本文作为Spark性能优化指南的基础篇，主要讲解开发调优以及资源调优。

开发调优

调优概述

Spark性能优化的第一步，就是要在开发Spark作业的过程中注意和应用一些性能优化的基本原则。开发调优，就是要让大家了解以下一些Spark基本开发原则，包括：RDD lineage设计、算子的合理使用、特殊操作的优化等。在开发过程中，时时刻刻都应该注意以上原则，并将这些原则根据具体的业务以及实际的应用场景，灵活地运用到自己的Spark作业中。

原则一：避免创建重复的RDD

通常来说，我们在开发一个Spark作业时，首先是基于某个数据源（比如Hive表或HDFS文件）创建一个初始的RDD；接着对这个RDD执行某个算子操作，然后得到下一个RDD；以此类推，循环往复，直到计算出最终我们需要的结果。在这个过程中，多个RDD会通过不同的算子操作（比如map、reduce等）串起来，这个“RDD串”，就是RDD lineage，也就是“RDD的血缘关系链”。

我们在开发过程中要注意：对于同一份数据，只应该创建一个RDD，不能创建多个RDD来代表同一份数据。

一些Spark初学者在刚开始开发Spark作业时，或者是有经验的工程师在开发RDD lineage极其冗长的Spark作业时，可能会忘了自己之前对于某一份数据已经创建过一个RDD了，从而导致对于同一份数据，创建了多个RDD。这就意味着，我们的Spark作业会进行多次重复计算来创建多个代表相同数据的RDD，进而增加了作业的性能开销。

一个简单的例子

// 需要对名为“hello.txt”的HDFS文件进行一次map操作，再进行一次reduce操作。也就是说，需要对一份数据执行两次算子操作。

// 错误的做法：对于同一份数据执行多次算子操作时，创建多个RDD。
// 这里执行了两次textFile方法，针对同一个HDFS文件，创建了两个RDD出来，然后分别对每个RDD都执行了一个算子操作。
// 这种情况下，Spark需要从HDFS上两次加载hello.txt文件的内容，并创建两个单独的RDD；第二次加载HDFS文件以及创建RDD的性能开销，很明显是白白浪费掉的。
val rdd1 = sc.textFile("hdfs://192.168.0.1:9000/hello.txt")
rdd1.map(...)
val rdd2 = sc.textFile("hdfs://192.168.0.1:9000/hello.txt")
rdd2.reduce(...)

// 正确的用法：对于一份数据执行多次算子操作时，只使用一个RDD。
// 这种写法很明显比上一种写法要好多了，因为我们对于同一份数据只创建了一个RDD，然后对这一个RDD执行了多次算子操作。
// 但是要注意到这里为止优化还没有结束，由于rdd1被执行了两次算子操作，第二次执行reduce操作的时候，还会再次从源头处重新计算一次rdd1的数据，因此还是会有重复计算的性能开销。
// 要彻底解决这个问题，必须结合“原则三：对多次使用的RDD进行持久化”，才能保证一个RDD被多次使用时只被计算一次。
val rdd1 = sc.textFile("hdfs://192.168.0.1:9000/hello.txt")
rdd1.map(...)
rdd1.reduce(...)

原则二：尽可能复用同一个RDD

除了要避免在开发过程中对一份完全相同的数据创建多个RDD之外，在对不同的数据执行算子操作时还要尽可能地复用一个RDD。比如说，有一个RDD的数据格式是key-value类型的，另一个是单value类型的，这两个RDD的value数据是完全一样的。那么此时我们可以只使用key-value类型的那个RDD，因为其中已经包含了另一个的数据。对于类似这种多个RDD的数据有重叠或者包含的情况，我们应该尽量复用一个RDD，这样可以尽可能地减少RDD的数量，从而尽可能减少算子执行的次数。

一个简单的例子

// 错误的做法。

// 有一个格式的RDD，即rdd1。
// 接着由于业务需要，对rdd1执行了一个map操作，创建了一个rdd2，而rdd2中的数据仅仅是rdd1中的value值而已，也就是说，rdd2是rdd1的子集。
JavaPairRDD rdd1 = ...
JavaRDD rdd2 = rdd1.map(...)

// 分别对rdd1和rdd2执行了不同的算子操作。
rdd1.reduceByKey(...)
rdd2.map(...)

// 正确的做法。

// 上面这个case中，其实rdd1和rdd2的区别无非就是数据格式不同而已，rdd2的数据完全就是rdd1的子集而已，却创建了两个rdd，并对两个rdd都执行了一次算子操作。
// 此时会因为对rdd1执行map算子来创建rdd2，而多执行一次算子操作，进而增加性能开销。

// 其实在这种情况下完全可以复用同一个RDD。
// 我们可以使用rdd1，既做reduceByKey操作，也做map操作。
// 在进行第二个map操作时，只使用每个数据的tuple._2，也就是rdd1中的value值，即可。
JavaPairRDD rdd1 = ...
rdd1.reduceByKey(...)
rdd1.map(tuple._2...)

// 第二种方式相较于第一种方式而言，很明显减少了一次rdd2的计算开销。
// 但是到这里为止，优化还没有结束，对rdd1我们还是执行了两次算子操作，rdd1实际上还是会被计算两次。
// 因此还需要配合“原则三：对多次使用的RDD进行持久化”进行使用，才能保证一个RDD被多次使用时只被计算一次。

原则三：对多次使用的RDD进行持久化

当你在Spark代码中多次对一个RDD做了算子操作后，恭喜，你已经实现Spark作业第一步的优化了，也就是尽可能复用RDD。此时就该在这个基础之上，进行第二步优化了，也就是要保证对一个RDD执行多次算子操作时，这个RDD本身仅仅被计算一次。

Spark中对于一个RDD执行多次算子的默认原理是这样的：每次你对一个RDD执行一个算子操作时，都会重新从源头处计算一遍，计算出那个RDD来，然后再对这个RDD执行你的算子操作。这种方式的性能是很差的。

因此对于这种情况，我们的建议是：对多次使用的RDD进行持久化。此时Spark就会根据你的持久化策略，将RDD中的数据保存到内存或者磁盘中。以后每次对这个RDD进行算子操作时，都会直接从内存或磁盘中提取持久化的RDD数据，然后执行算子，而不会从源头处重新计算一遍这个RDD，再执行算子操作。

对多次使用的RDD进行持久化的代码示例

// 如果要对一个RDD进行持久化，只要对这个RDD调用cache()和persist()即可。

// 正确的做法。
// cache()方法表示：使用非序列化的方式将RDD中的数据全部尝试持久化到内存中。
// 此时再对rdd1执行两次算子操作时，只有在第一次执行map算子时，才会将这个rdd1从源头处计算一次。
// 第二次执行reduce算子时，就会直接从内存中提取数据进行计算，不会重复计算一个rdd。
val rdd1 = sc.textFile("hdfs://192.168.0.1:9000/hello.txt").cache()
rdd1.map(...)
rdd1.reduce(...)

// persist()方法表示：手动选择持久化级别，并使用指定的方式进行持久化。
// 比如说，StorageLevel.MEMORY_AND_DISK_SER表示，内存充足时优先持久化到内存中，内存不充足时持久化到磁盘文件中。
// 而且其中的_SER后缀表示，使用序列化的方式来保存RDD数据，此时RDD中的每个partition都会序列化成一个大的字节数组，然后再持久化到内存或磁盘中。
// 序列化的方式可以减少持久化的数据对内存/磁盘的占用量，进而避免内存被持久化数据占用过多，从而发生频繁GC。
val rdd1 = sc.textFile("hdfs://192.168.0.1:9000/hello.txt").persist(StorageLevel.MEMORY_AND_DISK_SER)
rdd1.map(...)
rdd1.reduce(...)

对于persist()方法而言，我们可以根据不同的业务场景选择不同的持久化级别。

Spark的持久化级别

持久化级别	含义解释
MEMORY_ONLY	使用未序列化的Java对象格式，将数据保存在内存中。如果内存不够存放所有的数据，则数据可能就不会进行持久化。那么下次对这个RDD执行算子操作时，那些没有被持久化的数据，需要从源头处重新计算一遍。这是默认的持久化策略，使用cache()方法时，实际就是使用的这种持久化策略。
MEMORY_AND_DISK	使用未序列化的Java对象格式，优先尝试将数据保存在内存中。如果内存不够存放所有的数据，会将数据写入磁盘文件中，下次对这个RDD执行算子时，持久化在磁盘文件中的数据会被读取出来使用。
MEMORY_ONLY_SER	基本含义同MEMORY_ONLY。唯一的区别是，会将RDD中的数据进行序列化，RDD的每个partition会被序列化成一个字节数组。这种方式更加节省内存，从而可以避免持久化的数据占用过多内存导致频繁GC。
MEMORY_AND_DISK_SER	基本含义同MEMORY_AND_DISK。唯一的区别是，会将RDD中的数据进行序列化，RDD的每个partition会被序列化成一个字节数组。这种方式更加节省内存，从而可以避免持久化的数据占用过多内存导致频繁GC。
DISK_ONLY	使用未序列化的Java对象格式，将数据全部写入磁盘文件中。
MEMORY_ONLY_2, MEMORY_AND_DISK_2, 等等.	对于上述任意一种持久化策略，如果加上后缀_2，代表的是将每个持久化的数据，都复制一份副本，并将副本保存到其他节点上。这种基于副本的持久化机制主要用于进行容错。假如某个节点挂掉，节点的内存或磁盘中的持久化数据丢失了，那么后续对RDD计算时还可以使用该数据在其他节点上的副本。如果没有副本的话，就只能将这些数据从源头处重新计算一遍了。

如何选择一种最合适的持久化策略

默认情况下，性能最高的当然是MEMORY_ONLY，但前提是你的内存必须足够足够大，可以绰绰有余地存放下整个RDD的所有数据。因为不进行序列化与反序列化操作，就避免了这部分的性能开销；对这个RDD的后续算子操作，都是基于纯内存中的数据的操作，不需要从磁盘文件中读取数据，性能也很高；而且不需要复制一份数据副本，并远程传送到其他节点上。但是这里必须要注意的是，在实际的生产环境中，恐怕能够直接用这种策略的场景还是有限的，如果RDD中数据比较多时（比如几十亿），直接用这种持久化级别，会导致JVM的OOM内存溢出异常。
如果使用MEMORY_ONLY级别时发生了内存溢出，那么建议尝试使用MEMORY_ONLY_SER级别。该级别会将RDD数据序列化后再保存在内存中，此时每个partition仅仅是一个字节数组而已，大大减少了对象数量，并降低了内存占用。这种级别比MEMORY_ONLY多出来的性能开销，主要就是序列化与反序列化的开销。但是后续算子可以基于纯内存进行操作，因此性能总体还是比较高的。此外，可能发生的问题同上，如果RDD中的数据量过多的话，还是可能会导致OOM内存溢出的异常。
如果纯内存的级别都无法使用，那么建议使用MEMORY_AND_DISK_SER策略，而不是MEMORY_AND_DISK策略。因为既然到了这一步，就说明RDD的数据量很大，内存无法完全放下。序列化后的数据比较少，可以节省内存和磁盘的空间开销。同时该策略会优先尽量尝试将数据缓存在内存中，内存缓存不下才会写入磁盘。
通常不建议使用DISK_ONLY和后缀为_2的级别：因为完全基于磁盘文件进行数据的读写，会导致性能急剧降低，有时还不如重新计算一次所有RDD。后缀为_2的级别，必须将所有数据都复制一份副本，并发送到其他节点上，数据复制以及网络传输会导致较大的性能开销，除非是要求作业的高可用性，否则不建议使用。

原则四：尽量避免使用shuffle类算子

如果有可能的话，要尽量避免使用shuffle类算子。因为Spark作业运行过程中，最消耗性能的地方就是shuffle过程。shuffle过程，简单来说，就是将分布在集群中多个节点上的同一个key，拉取到同一个节点上，进行聚合或join等操作。比如reduceByKey、join等算子，都会触发shuffle操作。

shuffle过程中，各个节点上的相同key都会先写入本地磁盘文件中，然后其他节点需要通过网络传输拉取各个节点上的磁盘文件中的相同key。而且相同key都拉取到同一个节点进行聚合操作时，还有可能会因为一个节点上处理的key过多，导致内存不够存放，进而溢写到磁盘文件中。因此在shuffle过程中，可能会发生大量的磁盘文件读写的IO操作，以及数据的网络传输操作。磁盘IO和网络数据传输也是shuffle性能较差的主要原因。

因此在我们的开发过程中，能避免则尽可能避免使用reduceByKey、join、distinct、repartition等会进行shuffle的算子，尽量使用map类的非shuffle算子。这样的话，没有shuffle操作或者仅有较少shuffle操作的Spark作业，可以大大减少性能开销。

Broadcast与map进行join代码示例

// 传统的join操作会导致shuffle操作。
// 因为两个RDD中，相同的key都需要通过网络拉取到一个节点上，由一个task进行join操作。
val rdd3 = rdd1.join(rdd2)

// Broadcast+map的join操作，不会导致shuffle操作。
// 使用Broadcast将一个数据量较小的RDD作为广播变量。
val rdd2Data = rdd2.collect()
val rdd2DataBroadcast = sc.broadcast(rdd2Data)

// 在rdd1.map算子中，可以从rdd2DataBroadcast中，获取rdd2的所有数据。
// 然后进行遍历，如果发现rdd2中某条数据的key与rdd1的当前数据的key是相同的，那么就判定可以进行join。
// 此时就可以根据自己需要的方式，将rdd1当前数据与rdd2中可以连接的数据，拼接在一起（String或Tuple）。
val rdd3 = rdd1.map(rdd2DataBroadcast...)

// 注意，以上操作，建议仅仅在rdd2的数据量比较少（比如几百M，或者一两G）的情况下使用。
// 因为每个Executor的内存中，都会驻留一份rdd2的全量数据。

原则五：使用map-side预聚合的shuffle操作

如果因为业务需要，一定要使用shuffle操作，无法用map类的算子来替代，那么尽量使用可以map-side预聚合的算子。

所谓的map-side预聚合，说的是在每个节点本地对相同的key进行一次聚合操作，类似于MapReduce中的本地combiner。map-side预聚合之后，每个节点本地就只会有一条相同的key，因为多条相同的key都被聚合起来了。其他节点在拉取所有节点上的相同key时，就会大大减少需要拉取的数据数量，从而也就减少了磁盘IO以及网络传输开销。通常来说，在可能的情况下，建议使用reduceByKey或者aggregateByKey算子来替代掉groupByKey算子。因为reduceByKey和aggregateByKey算子都会使用用户自定义的函数对每个节点本地的相同key进行预聚合。而groupByKey算子是不会进行预聚合的，全量的数据会在集群的各个节点之间分发和传输，性能相对来说比较差。

比如如下两幅图，就是典型的例子，分别基于reduceByKey和groupByKey进行单词计数。其中第一张图是groupByKey的原理图，可以看到，没有进行任何本地聚合时，所有数据都会在集群节点之间传输；第二张图是reduceByKey的原理图，可以看到，每个节点本地的相同key数据，都进行了预聚合，然后才传输到其他节点上进行全局聚合。

原则六：使用高性能的算子

除了shuffle相关的算子有优化原则之外，其他的算子也都有着相应的优化原则。

使用reduceByKey/aggregateByKey替代groupByKey

详情见“原则五：使用map-side预聚合的shuffle操作”。

使用mapPartitions替代普通map

mapPartitions类的算子，一次函数调用会处理一个partition所有的数据，而不是一次函数调用处理一条，性能相对来说会高一些。但是有的时候，使用mapPartitions会出现OOM（内存溢出）的问题。因为单次函数调用就要处理掉一个partition所有的数据，如果内存不够，垃圾回收时是无法回收掉太多对象的，很可能出现OOM异常。所以使用这类操作时要慎重！

使用foreachPartitions替代foreach

原理类似于“使用mapPartitions替代map”，也是一次函数调用处理一个partition的所有数据，而不是一次函数调用处理一条数据。在实践中发现，foreachPartitions类的算子，对性能的提升还是很有帮助的。比如在foreach函数中，将RDD中所有数据写MySQL，那么如果是普通的foreach算子，就会一条数据一条数据地写，每次函数调用可能就会创建一个数据库连接，此时就势必会频繁地创建和销毁数据库连接，性能是非常低下；但是如果用foreachPartitions算子一次性处理一个partition的数据，那么对于每个partition，只要创建一个数据库连接即可，然后执行批量插入操作，此时性能是比较高的。实践中发现，对于1万条左右的数据量写MySQL，性能可以提升30%以上。

使用filter之后进行coalesce操作

通常对一个RDD执行filter算子过滤掉RDD中较多数据后（比如30%以上的数据），建议使用coalesce算子，手动减少RDD的partition数量，将RDD中的数据压缩到更少的partition中去。因为filter之后，RDD的每个partition中都会有很多数据被过滤掉，此时如果照常进行后续的计算，其实每个task处理的partition中的数据量并不是很多，有一点资源浪费，而且此时处理的task越多，可能速度反而越慢。因此用coalesce减少partition数量，将RDD中的数据压缩到更少的partition之后，只要使用更少的task即可处理完所有的partition。在某些场景下，对于性能的提升会有一定的帮助。

使用repartitionAndSortWithinPartitions替代repartition与sort类操作

repartitionAndSortWithinPartitions是Spark官网推荐的一个算子，官方建议，如果需要在repartition重分区之后，还要进行排序，建议直接使用repartitionAndSortWithinPartitions算子。因为该算子可以一边进行重分区的shuffle操作，一边进行排序。shuffle与sort两个操作同时进行，比先shuffle再sort来说，性能可能是要高的。

原则七：广播大变量

有时在开发过程中，会遇到需要在算子函数中使用外部变量的场景（尤其是大变量，比如100M以上的大集合），那么此时就应该使用Spark的广播（Broadcast）功能来提升性能。

在算子函数中使用到外部变量时，默认情况下，Spark会将该变量复制多个副本，通过网络传输到task中，此时每个task都有一个变量副本。如果变量本身比较大的话（比如100M，甚至1G），那么大量的变量副本在网络中传输的性能开销，以及在各个节点的Executor中占用过多内存导致的频繁GC，都会极大地影响性能。

因此对于上述情况，如果使用的外部变量比较大，建议使用Spark的广播功能，对该变量进行广播。广播后的变量，会保证每个Executor的内存中，只驻留一份变量副本，而Executor中的task执行时共享该Executor中的那份变量副本。这样的话，可以大大减少变量副本的数量，从而减少网络传输的性能开销，并减少对Executor内存的占用开销，降低GC的频率。

广播大变量的代码示例

// 以下代码在算子函数中，使用了外部的变量。
// 此时没有做任何特殊操作，每个task都会有一份list1的副本。
val list1 = ...
rdd1.map(list1...)

// 以下代码将list1封装成了Broadcast类型的广播变量。
// 在算子函数中，使用广播变量时，首先会判断当前task所在Executor内存中，是否有变量副本。
// 如果有则直接使用；如果没有则从Driver或者其他Executor节点上远程拉取一份放到本地Executor内存中。
// 每个Executor内存中，就只会驻留一份广播变量副本。
val list1 = ...
val list1Broadcast = sc.broadcast(list1)
rdd1.map(list1Broadcast...)

原则八：使用Kryo优化序列化性能

在Spark中，主要有三个地方涉及到了序列化：

在算子函数中使用到外部变量时，该变量会被序列化后进行网络传输（见“原则七：广播大变量”中的讲解）。
将自定义的类型作为RDD的泛型类型时（比如JavaRDD，Student是自定义类型），所有自定义类型对象，都会进行序列化。因此这种情况下，也要求自定义的类必须实现Serializable接口。
使用可序列化的持久化策略时（比如MEMORY_ONLY_SER），Spark会将RDD中的每个partition都序列化成一个大的字节数组。

对于这三种出现序列化的地方，我们都可以通过使用Kryo序列化类库，来优化序列化和反序列化的性能。Spark默认使用的是Java的序列化机制，也就是ObjectOutputStream/ObjectInputStream API来进行序列化和反序列化。但是Spark同时支持使用Kryo序列化库，Kryo序列化类库的性能比Java序列化类库的性能要高很多。官方介绍，Kryo序列化机制比Java序列化机制，性能高10倍左右。Spark之所以默认没有使用Kryo作为序列化类库，是因为Kryo要求最好要注册所有需要进行序列化的自定义类型，因此对于开发者来说，这种方式比较麻烦。

以下是使用Kryo的代码示例，我们只要设置序列化类，再注册要序列化的自定义类型即可（比如算子函数中使用到的外部变量类型、作为RDD泛型类型的自定义类型等）：

// 创建SparkConf对象。
val conf = new SparkConf().setMaster(...).setAppName(...)
// 设置序列化器为KryoSerializer。
conf.set("spark.serializer", "org.apache.spark.serializer.KryoSerializer")
// 注册要序列化的自定义类型。
conf.registerKryoClasses(Array(classOf[MyClass1], classOf[MyClass2]))

原则九：优化数据结构

Java中，有三种类型比较耗费内存：

对象，每个Java对象都有对象头、引用等额外的信息，因此比较占用内存空间。
字符串，每个字符串内部都有一个字符数组以及长度等额外信息。
集合类型，比如HashMap、LinkedList等，因为集合类型内部通常会使用一些内部类来封装集合元素，比如Map.Entry。

因此Spark官方建议，在Spark编码实现中，特别是对于算子函数中的代码，尽量不要使用上述三种数据结构，尽量使用字符串替代对象，使用原始类型（比如Int、Long）替代字符串，使用数组替代集合类型，这样尽可能地减少内存占用，从而降低GC频率，提升性能。

但是在笔者的编码实践中发现，要做到该原则其实并不容易。因为我们同时要考虑到代码的可维护性，如果一个代码中，完全没有任何对象抽象，全部是字符串拼接的方式，那么对于后续的代码维护和修改，无疑是一场巨大的灾难。同理，如果所有操作都基于数组实现，而不使用HashMap、LinkedList等集合类型，那么对于我们的编码难度以及代码可维护性，也是一个极大的挑战。因此笔者建议，在可能以及合适的情况下，使用占用内存较少的数据结构，但是前提是要保证代码的可维护性。

资源调优

调优概述

在开发完Spark作业之后，就该为作业配置合适的资源了。Spark的资源参数，基本都可以在spark-submit命令中作为参数设置。很多Spark初学者，通常不知道该设置哪些必要的参数，以及如何设置这些参数，最后就只能胡乱设置，甚至压根儿不设置。资源参数设置的不合理，可能会导致没有充分利用集群资源，作业运行会极其缓慢；或者设置的资源过大，队列没有足够的资源来提供，进而导致各种异常。总之，无论是哪种情况，都会导致Spark作业的运行效率低下，甚至根本无法运行。因此我们必须对Spark作业的资源使用原理有一个清晰的认识，并知道在Spark作业运行过程中，有哪些资源参数是可以设置的，以及如何设置合适的参数值。

Spark作业基本运行原理

详细原理见上图。我们使用spark-submit提交一个Spark作业之后，这个作业就会启动一个对应的Driver进程。根据你使用的部署模式（deploy-mode）不同，Driver进程可能在本地启动，也可能在集群中某个工作节点上启动。Driver进程本身会根据我们设置的参数，占有一定数量的内存和CPU core。而Driver进程要做的第一件事情，就是向集群管理器（可以是Spark Standalone集群，也可以是其他的资源管理集群，美团•大众点评使用的是YARN作为资源管理集群）申请运行Spark作业需要使用的资源，这里的资源指的就是Executor进程。YARN集群管理器会根据我们为Spark作业设置的资源参数，在各个工作节点上，启动一定数量的Executor进程，每个Executor进程都占有一定数量的内存和CPU core。

在申请到了作业执行所需的资源之后，Driver进程就会开始调度和执行我们编写的作业代码了。Driver进程会将我们编写的Spark作业代码分拆为多个stage，每个stage执行一部分代码片段，并为每个stage创建一批task，然后将这些task分配到各个Executor进程中执行。task是最小的计算单元，负责执行一模一样的计算逻辑（也就是我们自己编写的某个代码片段），只是每个task处理的数据不同而已。一个stage的所有task都执行完毕之后，会在各个节点本地的磁盘文件中写入计算中间结果，然后Driver就会调度运行下一个stage。下一个stage的task的输入数据就是上一个stage输出的中间结果。如此循环往复，直到将我们自己编写的代码逻辑全部执行完，并且计算完所有的数据，得到我们想要的结果为止。

Spark是根据shuffle类算子来进行stage的划分。如果我们的代码中执行了某个shuffle类算子（比如reduceByKey、join等），那么就会在该算子处，划分出一个stage界限来。可以大致理解为，shuffle算子执行之前的代码会被划分为一个stage，shuffle算子执行以及之后的代码会被划分为下一个stage。因此一个stage刚开始执行的时候，它的每个task可能都会从上一个stage的task所在的节点，去通过网络传输拉取需要自己处理的所有key，然后对拉取到的所有相同的key使用我们自己编写的算子函数执行聚合操作（比如reduceByKey()算子接收的函数）。这个过程就是shuffle。

当我们在代码中执行了cache/persist等持久化操作时，根据我们选择的持久化级别的不同，每个task计算出来的数据也会保存到Executor进程的内存或者所在节点的磁盘文件中。

因此Executor的内存主要分为三块：第一块是让task执行我们自己编写的代码时使用，默认是占Executor总内存的20%；第二块是让task通过shuffle过程拉取了上一个stage的task的输出后，进行聚合等操作时使用，默认也是占Executor总内存的20%；第三块是让RDD持久化时使用，默认占Executor总内存的60%。

task的执行速度是跟每个Executor进程的CPU core数量有直接关系的。一个CPU core同一时间只能执行一个线程。而每个Executor进程上分配到的多个task，都是以每个task一条线程的方式，多线程并发运行的。如果CPU core数量比较充足，而且分配到的task数量比较合理，那么通常来说，可以比较快速和高效地执行完这些task线程。

以上就是Spark作业的基本运行原理的说明，大家可以结合上图来理解。理解作业基本原理，是我们进行资源参数调优的基本前提。

资源参数调优

了解完了Spark作业运行的基本原理之后，对资源相关的参数就容易理解了。所谓的Spark资源参数调优，其实主要就是对Spark运行过程中各个使用资源的地方，通过调节各种参数，来优化资源使用的效率，从而提升Spark作业的执行性能。以下参数就是Spark中主要的资源参数，每个参数都对应着作业运行原理中的某个部分，我们同时也给出了一个调优的参考值。

num-executors

参数说明：该参数用于设置Spark作业总共要用多少个Executor进程来执行。Driver在向YARN集群管理器申请资源时，YARN集群管理器会尽可能按照你的设置来在集群的各个工作节点上，启动相应数量的Executor进程。这个参数非常之重要，如果不设置的话，默认只会给你启动少量的Executor进程，此时你的Spark作业的运行速度是非常慢的。
参数调优建议：每个Spark作业的运行一般设置50~100个左右的Executor进程比较合适，设置太少或太多的Executor进程都不好。设置的太少，无法充分利用集群资源；设置的太多的话，大部分队列可能无法给予充分的资源。

executor-memory

参数说明：该参数用于设置每个Executor进程的内存。Executor内存的大小，很多时候直接决定了Spark作业的性能，而且跟常见的JVM OOM异常，也有直接的关联。
参数调优建议：每个Executor进程的内存设置4G~8G较为合适。但是这只是一个参考值，具体的设置还是得根据不同部门的资源队列来定。可以看看自己团队的资源队列的最大内存限制是多少，num-executors乘以executor-memory，是不能超过队列的最大内存量的。此外，如果你是跟团队里其他人共享这个资源队列，那么申请的内存量最好不要超过资源队列最大总内存的1/3~1/2，避免你自己的Spark作业占用了队列所有的资源，导致别的同学的作业无法运行。

executor-cores

参数说明：该参数用于设置每个Executor进程的CPU core数量。这个参数决定了每个Executor进程并行执行task线程的能力。因为每个CPU core同一时间只能执行一个task线程，因此每个Executor进程的CPU core数量越多，越能够快速地执行完分配给自己的所有task线程。
参数调优建议：Executor的CPU core数量设置为2~4个较为合适。同样得根据不同部门的资源队列来定，可以看看自己的资源队列的最大CPU core限制是多少，再依据设置的Executor数量，来决定每个Executor进程可以分配到几个CPU core。同样建议，如果是跟他人共享这个队列，那么num-executors * executor-cores不要超过队列总CPU core的1/3~1/2左右比较合适，也是避免影响其他同学的作业运行。

driver-memory

参数说明：该参数用于设置Driver进程的内存。
参数调优建议：Driver的内存通常来说不设置，或者设置1G左右应该就够了。唯一需要注意的一点是，如果需要使用collect算子将RDD的数据全部拉取到Driver上进行处理，那么必须确保Driver的内存足够大，否则会出现OOM内存溢出的问题。

spark.default.parallelism

参数说明：该参数用于设置每个stage的默认task数量。这个参数极为重要，如果不设置可能会直接影响你的Spark作业性能。
参数调优建议：Spark作业的默认task数量为500~1000个较为合适。很多同学常犯的一个错误就是不去设置这个参数，那么此时就会导致Spark自己根据底层HDFS的block数量来设置task的数量，默认是一个HDFS block对应一个task。通常来说，Spark默认设置的数量是偏少的（比如就几十个task），如果task数量偏少的话，就会导致你前面设置好的Executor的参数都前功尽弃。试想一下，无论你的Executor进程有多少个，内存和CPU有多大，但是task只有1个或者10个，那么90%的Executor进程可能根本就没有task执行，也就是白白浪费了资源！因此Spark官网建议的设置原则是，设置该参数为num-executors * executor-cores的2~3倍较为合适，比如Executor的总CPU core数量为300个，那么设置1000个task是可以的，此时可以充分地利用Spark集群的资源。

spark.storage.memoryFraction

参数说明：该参数用于设置RDD持久化数据在Executor内存中能占的比例，默认是0.6。也就是说，默认Executor 60%的内存，可以用来保存持久化的RDD数据。根据你选择的不同的持久化策略，如果内存不够时，可能数据就不会持久化，或者数据会写入磁盘。
参数调优建议：如果Spark作业中，有较多的RDD持久化操作，该参数的值可以适当提高一些，保证持久化的数据能够容纳在内存中。避免内存不够缓存所有的数据，导致数据只能写入磁盘中，降低了性能。但是如果Spark作业中的shuffle类操作比较多，而持久化操作比较少，那么这个参数的值适当降低一些比较合适。此外，如果发现作业由于频繁的gc导致运行缓慢（通过spark web ui可以观察到作业的gc耗时），意味着task执行用户代码的内存不够用，那么同样建议调低这个参数的值。

spark.shuffle.memoryFraction

参数说明：该参数用于设置shuffle过程中一个task拉取到上个stage的task的输出后，进行聚合操作时能够使用的Executor内存的比例，默认是0.2。也就是说，Executor默认只有20%的内存用来进行该操作。shuffle操作在进行聚合时，如果发现使用的内存超出了这个20%的限制，那么多余的数据就会溢写到磁盘文件中去，此时就会极大地降低性能。
参数调优建议：如果Spark作业中的RDD持久化操作较少，shuffle操作较多时，建议降低持久化操作的内存占比，提高shuffle操作的内存占比比例，避免shuffle过程中数据过多时内存不够用，必须溢写到磁盘上，降低了性能。此外，如果发现作业由于频繁的gc导致运行缓慢，意味着task执行用户代码的内存不够用，那么同样建议调低这个参数的值。

资源参数的调优，没有一个固定的值，需要同学们根据自己的实际情况（包括Spark作业中的shuffle操作数量、RDD持久化操作数量以及spark web ui中显示的作业gc情况），同时参考本篇文章中给出的原理以及调优建议，合理地设置上述参数。

资源参数参考示例

以下是一份spark-submit命令的示例，大家可以参考一下，并根据自己的实际情况进行调节：

./bin/spark-submit \
 --master yarn-cluster \
 --num-executors 100 \
 --executor-memory 6G \
 --executor-cores 4 \
 --driver-memory 1G \
 --conf spark.default.parallelism=1000 \
 --conf spark.storage.memoryFraction=0.5 \
 --conf spark.shuffle.memoryFraction=0.3 \

写在最后的话

根据实践经验来看，大部分Spark作业经过本次基础篇所讲解的开发调优与资源调优之后，一般都能以较高的性能运行了，足以满足我们的需求。但是在不同的生产环境和项目背景下，可能会遇到其他更加棘手的问题（比如各种数据倾斜），也可能会遇到更高的性能要求。为了应对这些挑战，需要使用更高级的技巧来处理这类问题。在后续的《Spark性能优化指南——高级篇》中，我们会详细讲解数据倾斜调优以及Shuffle调优。

Hexo

从实际案例聊聊Java应用的GC优化

一、优化前的准备

GC优化需知

JVM基础回顾

JVM内存结构

常见垃圾回收器

GC日志

参数基本策略

二、优化步骤

确定目标

优化

验收优化结果

三、GC优化案例

案例一 Major GC和Minor GC频繁

确定目标

优化

优化结果

小结

更多思考

优化结果

小结

更多思考

案例三 发生Stop-The-World的GC

确定目标

优化

优化结果

小结

四、总结

深入分析CAS

CAS分析

CAS缺陷

深入分析volatile

一.内存模型的相关概念

二.并发编程中的三个概念

三.Java内存模型

四.深入剖析volatile关键字

五.使用volatile关键字的场景

深入分析synchronized

实现原理

Java对象头、monitor

Monitor

锁优化

Kafka设计解析（八）- Kafka Exactly Once语义与事务机制原理

写在前面的话

为什么要提供事务机制

Exactly Once

操作原子性

实现事务机制的几个阶段

幂等性发送

事务性保证

事务机制原理

事务性消息传递

事务中Offset的提交

用于事务特性的控制型消息

事务处理样例代码

完整事务过程

找到Transaction Coordinator

获取PID

开启事务

Consume-Transform-Produce

Commit或Abort事务

总结

异常处理

Exception处理

处理Transaction Coordinator失败

写PREPARE_COMMIT/PREPARE_ABORT前失败

写完PREPARE_COMMIT/PREPARE_ABORT后失败

写完COMPLETE_COMMIT/ABORT后失败

事务过期机制

事务超时

终止过期事务

终止Transaction ID

与其它系统事务机制对比

PostgreSQL MVCC

两阶段提交

Zookeeper

Kafka系列文章

Kafka消费者重新实现的细节

消费组管理协议

案例三发生Stop-The-World的GC

处理`Transaction Coordinator`失败

写`PREPARE_COMMIT/PREPARE_ABORT`前失败

写完`PREPARE_COMMIT/PREPARE_ABORT`后失败

写完`COMPLETE_COMMIT/ABORT`后失败

终止`Transaction ID`