在回收僵尸进程之前，如果父进程退出了，则僵尸进程变为“孤儿进程”，进而被init进程接管、回收。

僵尸进程的状态为EXIT_ZOMBIE，缩写Z，ps命令也会打印僵尸进程，但无法使用kill杀死。

为什么需要僵尸进程（保留task_struct）？

之所以保留task_struct，是因为task_struct里面保存了进程的pid、退出码、以及一些统计信息，父进程很可能会关心这些信息。比如$?变量就保存了最近一个退出的前台进程的退出码，这个退出码就来自于僵尸进程的task_struct结构。

为什么要处理僵尸进程

僵尸进程的task_struct中保存了进程的pid、退出码等。尤其是pid，如果僵尸进程过多，最终耗尽了pid，那么将无法创建新的进程。

如何处理僵尸进程？

父进程可以通过wait系列的系统调用（如wait4、waitpid等，以下用wait指代）来等待某个或某些子进程的退出，并获取它的退出信息，然后顺便回收子进程的“尸体”（如task_struct），然后子进程转入EXIT_DEAD状态（X），等待被操作系统彻底回收。

子进程退出后，父进程未调用wait回收尸体前，子进程将保持僵尸状态。

方案1：父进程调用wait

很自然的，如果父进程主动调用wait，也就消灭了僵尸进程。

但wait调用是阻塞的，如果调用wait时子进程还没有退出，将阻塞住父进程，影响性能。

方案2：kill父进程（产生“孤儿进程”）

如果父进程回收僵尸进程前就退出了，则僵尸进程变为“孤儿进程”。通常会将“孤儿进程”委托给init进程（pid等于1），init进程将在一个死循环中等待其子进程（包括这些僵尸进程）的退出事件，并调用wait回收子进程的尸体。

因此，找到僵尸进程的父进程，kill掉，也是一个没有办法时的办法。

方案3：通过信号机制异步回收

编写程序时，子进程退出前向父进程发送SIGCHLD信号，父进程收到SIGCHLD信号后（通过signal(SIGCHLD, sig_child)绑定信号处理器），调用wait回收子进程的尸体。

与方案1相比，方案3不需要阻塞父进程，是最理想的方式。

为什么会出现少数僵尸进程一直不被回收

在实际工作中，总会碰到少数僵尸进程一直不被回收。

显然，如果父进程没有绑定SIGCHLD信号处理函数调用wait或waitpid等待子进程结束，那么僵尸进程就会一直存在。如果这时候父进程结束了，那么init进程会自动接手这个子进程，还是能被清除掉的。但是，如果父进程是一个循环，不会结束，那么子进程就会一直保持僵尸状态，这就是系统中为什么有时候会有很多的僵尸进程。

参考：

• 研究经典面试题：孤儿进程和僵尸进程

源码版本：Apache Hadoop 2.6.0

三个资源等级

在Yarn中，资源也被称为分布式缓存，根据可见性分为三个等级：

• PUBLIC：节点上所有用户共享。
• PRIVATE：节点上同一用户的所有app共享。
• APPLICATION：节点上同一app的所有container共享。

各资源的存储结构如下：

可以看到，目录结构对应了资源的可见性。

所有资源最终为contaienr所用，container在自己的${containerId}/目录下通过软链访问各等级的资源。

过程

PUBLIC资源由ResourceLocalizationService下的PublicLocalizer下载；PRIVATE、APPLICATION资源也经过ResourceLocalizationService服务，但最终由各container独立的ContainerLocalizer下载。

假设PUBLIC、PRIVATE资源已下载，现在用户启动一个新app，下载APPLICATION资源的过程如下：

1. ResourceLocalizationService服务收到INIT_APPLICATION_RESUOURCE事件。
2. 为每个资源创建LocalResourceTracker。
3. LocalResourceTracker创建LocalizedResource状态机，以跟踪资源的生命周期。
4. 如果需要下载，则LocalizedResource状态机向ResourceLocalizationService发送事件通知下载，转到DOWNLOADING状态。
5. ResourceLocalizationService发现不是PUBLIC资源，为每个container创建LocalizerRunner线程。
6. LocalizerRunner线程创建ContainerLocalizer客户端下载资源。

值得庆幸的是，尽管状态机模型设计复杂，但一旦设计（最好能证明）完成，就自然的解决了很多分布式和并发上的一致性问题，因此，对Yarn源码的学习不会像HDFS一样冗长枯燥，往往顺着状态机看几个关键流程即可。

源码版本：Apache Hadoop 2.6.0

一、RM上的过程：准备Container

1. 收到AM的心跳请求，立即响应。
2. 根据资源和负载选择NM（两种资源策略？？？）。
3. 创建RMContainer状态机，NEW状态。
4. 发送START事件，转到ALLOCATED状态（表示该container已被分配，但未通知AM）。
5. 在下一次AM心跳响应中返回已分配的container（即，异步分配）。
6. 发送ACQUIRED事件，转到ACQUIRED状态（表示该container已通知AM）。

二、AM上的过程：拿到Container，通知NM启动

1. 收到心跳响应中的已分配container。
2. 通知NM启动该container。

三、NM上的过程：实际启动Container

NM上的Container、资源等也有类似状态转换过程，以下描述忽略。

1. NM收到AM的启动指令。
2. 创建Container状态机、初始化资源等（资源也通过状态机管理）。
3. ContainerLaucher服务收到LAUNCH_CONTAINER事件。
4. 将待运行container所需的环境变量、运行命令等写入launch_container.sh脚本。
5. 启动ContainerMonitor，监控container的内存资源（超过配额就kill。CPU配合通过cgroup控制。）。
6. 将启动launch_container.sh脚本的命令写入container_executor.sh脚本（防止变量展开、特殊符号转义等）。
7. 启动container_executor.sh脚本。
8. 在NM->RM的心跳请求中异步汇报已启动的container。

四、回到RM：首尾

1. 收到NM心跳中的汇报。
2. 向RMContainer状态机发送LAUNCHED事件，转到RUNNING状态。

源码版本：Apache Hadoop 2.6.0

总览

Yarn采用了基于事件驱动的并发模型：

• 所有状态机都实现了EventHandler接口，很多服务（类名通常带有Service后缀）也实现了该接口，它们都是事件处理器。
• 需要异步处理的事件由中央异步调度器（类名通常带有Dispatcher后缀）统一接收/派发，需要同步处理的事件直接交给相应的事件处理器。

示意图（简化为只有事件处理器）：

某些事件处理器不仅处理事件，也会向中央异步调度器发送事件。

事件处理器EventHandler

事件处理器就像一个简单的函数，只有一个handle()方法，传入的是一个封装好的事件Event：

1
2
3
4
5
6
7
8
9
10
11
12
13

/**
 * Interface for handling events of type T
 *
 * @param <T> parameterized event of type T
 */
@SuppressWarnings("rawtypes")
@Public
@Evolving
public interface EventHandler<T extends Event> {
  void handle(T event);
}

这里仅给出一个例子：

ApplicationMasterLauncher实现了EventHandler接口，用于处理AM的启动、清理事件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public class ApplicationMasterLauncher extends AbstractService implements
    EventHandler<AMLauncherEvent> {
  ...
  @Override
  public synchronized void  handle(AMLauncherEvent appEvent) {
    AMLauncherEventType event = appEvent.getType();
    RMAppAttempt application = appEvent.getAppAttempt();
    switch (event) {
    case LAUNCH:
      launch(application);
      break;
    case CLEANUP:
      cleanup(application);
    default:
      break;
    }
  }
  ...
}

中央异步调度器AsyncDispatcher

Dispatcher接口定义了基本的事件派发行为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

/**
 * Event Dispatcher interface. It dispatches events to registered 
 * event handlers based on event types.
 * 
 */
@SuppressWarnings("rawtypes")
@Public
@Evolving
public interface Dispatcher {
  // Configuration to make sure dispatcher crashes but doesn't do system-exit in
  // case of errors. By default, it should be false, so that tests are not
  // affected. For all daemons it should be explicitly set to true so that
  // daemons can crash instead of hanging around.
  public static final String DISPATCHER_EXIT_ON_ERROR_KEY =
      "yarn.dispatcher.exit-on-error";
  public static final boolean DEFAULT_DISPATCHER_EXIT_ON_ERROR = false;
  EventHandler getEventHandler();
  void register(Class<? extends Enum> eventType, EventHandler handler);
}

register()方法负责注册事件处理器，getEventHandler()方法获得事件处理器以派发事件。

AsyncDispatcher实现了Dispatcher接口，通过队列扩展出了异步派发事件的行为（同时，它也是一个服务），通常被称为“中央异步调度器”，是一个典型的生产者-消费者模型：

1
2
3

public class AsyncDispatcher extends AbstractService implements Dispatcher {
  ...
}

注册事件处理器

AsyncDispatcher#register()方法将二元组<eventType, eventHandler>注册到AsyncDispatcher#eventDispatchers中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

@SuppressWarnings("unchecked")
@Override
public void register(Class<? extends Enum> eventType,
    EventHandler handler) {
  /* check to see if we have a listener registered */
  EventHandler<Event> registeredHandler = (EventHandler<Event>)
  eventDispatchers.get(eventType);
  LOG.info("Registering " + eventType + " for " + handler.getClass());
  if (registeredHandler == null) {
    eventDispatchers.put(eventType, handler);
  } else if (!(registeredHandler instanceof MultiListenerHandler)){
    /* for multiple listeners of an event add the multiple listener handler */
    MultiListenerHandler multiHandler = new MultiListenerHandler();
    multiHandler.addHandler(registeredHandler);
    multiHandler.addHandler(handler);
    eventDispatchers.put(eventType, multiHandler);
  } else {
    /* already a multilistener, just add to it */
    MultiListenerHandler multiHandler
    = (MultiListenerHandler) registeredHandler;
    multiHandler.addHandler(handler);
  }
}

Yarn的事件类型EventType都是枚举类型，而eventDispatchers是一个“事件类型->事件处理器”的Map：

1

protected final Map<Class<? extends Enum>, EventHandler> eventDispatchers;

注册方法支持注册事件类型到事件处理器的映射，比较简单，不表。

如前面提到的ApplicationMasterLauncher，其注册的事件类型是AMLauncherEventType：

1
2
3

applicationMasterLauncher = createAMLauncher();
rmDispatcher.register(AMLauncherEventType.class,
    applicationMasterLauncher);

处理事件

AsyncDispatcher#getEventHandler()是异步派发的关键：

1
2
3
4
5
6
7

@Override
public EventHandler getEventHandler() {
  if (handlerInstance == null) {
    handlerInstance = new GenericEventHandler();
  }
  return handlerInstance;
}

它看起来很简单，直接返回事件处理器AsyncDispatcher#handlerInstance，外界将所有类型的事件都交给它。例如：

1
2
3

rmNode.context.getDispatcher().getEventHandler().handle(
  new NodesListManagerEvent(
      NodesListManagerEventType.NODE_USABLE, rmNode));

显然，AsyncDispatcher#handlerInstance对事件的处理就是“接收事件，放入中央异步调度器”。

那么，AsyncDispatcher#handlerInstance.handle()如何接收各种类型的事件呢？

AsyncDispatcher#handlerInstance被延迟初始化为一个GenericEventHandler实例。GenericEventHandler是一个特别的事件处理器，它只负责接收事件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

class GenericEventHandler implements EventHandler<Event> {
  public void handle(Event event) {
    if (blockNewEvents) {
      return;
    }
    drained = false;
    /* all this method does is enqueue all the events onto the queue */
    int qSize = eventQueue.size();
    if (qSize !=0 && qSize %1000 == 0) {
      LOG.info("Size of event-queue is " + qSize);
    }
    int remCapacity = eventQueue.remainingCapacity();
    if (remCapacity < 1000) {
      LOG.warn("Very low remaining capacity in the event-queue: "
          + remCapacity);
    }
    try {
      eventQueue.put(event);
    } catch (InterruptedException e) {
      if (!stopped) {
        LOG.warn("AsyncDispatcher thread interrupted", e);
      }
      throw new YarnRuntimeException(e);
    }
  };
}

非重点：

• blockNewEvents是一个开关，在AsyncDispatcher关闭过程中被置为true，新来的事件会被GenericEventHandler丢弃。
• drained指示队列是否排空，队列空时被置为true。
• 9-17行用于打印队列的状态。

整个GenericEventHandler#handle()的核心在19行：将事件放入事件队列AsyncDispatcher#eventQueue中。

AsyncDispatcher#eventQueue是一个BlockingQueue：

1

private final BlockingQueue<Event> eventQueue;

BlockingQueue是一个线程安全的阻塞队列，常用于生产者-消费者模型中。

因此，调用AsyncDispatcher#getEventHandler()#handle()方法的线程相当于生产者，生产一个事件后能够立即返回。

那么，AsyncDispatcher#eventQueue中的事件何时处理呢？

AsyncDispatcher#eventQueue.take()方法从队列中获得一个事件，其仅在AsyncDispatcher#createThread()方法中被调用：

AsyncDispatcher#createThread()创建一个线程，来异步的处理事件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

Runnable createThread() {
  return new Runnable() {
    @Override
    public void run() {
      while (!stopped && !Thread.currentThread().isInterrupted()) {
        drained = eventQueue.isEmpty();
        // blockNewEvents is only set when dispatcher is draining to stop,
        // adding this check is to avoid the overhead of acquiring the lock
        // and calling notify every time in the normal run of the loop.
        if (blockNewEvents) {
          synchronized (waitForDrained) {
            if (drained) {
              waitForDrained.notify();
            }
          }
        }
        Event event;
        try {
          event = eventQueue.take();
        } catch(InterruptedException ie) {
          if (!stopped) {
            LOG.warn("AsyncDispatcher thread interrupted", ie);
          }
          return;
        }
        if (event != null) {
          dispatch(event);
        }
      }
    }
  };
}

该线程是典型的长服务线程：主体是一个循环，持续提供服务。19行从AsyncDispatcher#eventQueue中取出一个事件。27行调用AsyncDispatcher#dispatch()，将事件event派发给对应的事件处理器EventHandler处理：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

@SuppressWarnings("unchecked")
protected void dispatch(Event event) {
  //all events go thru this loop
  if (LOG.isDebugEnabled()) {
    LOG.debug("Dispatching the event " + event.getClass().getName() + "."
        + event.toString());
  }
  Class<? extends Enum> type = event.getType().getDeclaringClass();
  try{
    EventHandler handler = eventDispatchers.get(type);
    if(handler != null) {
      handler.handle(event);
    } else {
      throw new Exception("No handler for registered for " + type);
    }
  } catch (Throwable t) {
    //TODO Maybe log the state of the queue
    LOG.fatal("Error in dispatcher thread", t);
    // If serviceStop is called, we should exit this thread gracefully.
    if (exitOnDispatchException
        && (ShutdownHookManager.get().isShutdownInProgress()) == false
        && stopped == false) {
      LOG.info("Exiting, bbye..");
      System.exit(-1);
    }
  }
}

12行根据事件类型，从AsyncDispatcher#eventDispatchers中取得对应的事件处理器handler。14行执行handler.handle()处理事件。

我们已经知道，AsyncDispatcher#createThread()创建的线程（启动后）相当于消费者，多线程各自同步处理事件。那么，这个长服务线程什么时候启动的呢？

AsyncDispatcher#createThread()仅在AsyncDispatcher#serviceStart()中被调用：

AsyncDispatcher#serviceStart()在服务启动时调用，通过AsyncDispatcher#createThread()方法创建事件处理器线程eventHandlingThread，并启动：

1
2
3
4
5
6
7
8

@Override
protected void serviceStart() throws Exception {
  //start all the components
  super.serviceStart();
  eventHandlingThread = new Thread(createThread());
  eventHandlingThread.setName("AsyncDispatcher event handler");
  eventHandlingThread.start();
}

小问题

结合AsyncDispatcher#createThread()方法可知，AsyncDispatcher中仅有一个消费者线程，且该消费者线程在循环中同步处理事件。

我不太理解这样的设计：如果实际观测得知短时间内产生的事件不多，没必要并发消费，那么确实不需要多消费者；但如果事件过多，或某事件的处理十分耗时，同步处理会让系统的吞吐量瞬间掉下去。

20180307：

现在理解了一部分设计考虑：在设计事件处理器时，不应该在事件处理逻辑中包含耗时操作，而应该让事件处理器仅完成基本的事件处理逻辑。如果需要耗时的操作，则交给其他线程异步完成，有必要的话，在完成后再发送事件进行下一步转换。例如kill app的过程，对应下述状态转换：

RUNNING -> KILLING -> FINISHED

要kill一个app，并不会让RMApp由RUNNING状态直接转到FINISHED状态，而要在中间保持一个KILLING状态——保持KILLING状态的期间，由其他线程完成耗时的kill逻辑，完成后发送相关事件，让RMApp转换到最终的FINISHED状态。

但如果事件过多，那么单纯的事件处理逻辑也能够把一个cpu打满，此处的同步处理依旧是一个重要的性能瓶颈。具体多大才能打满呢？得好好估计一回了，暂且放下。

状态机

关于Yarn中状态机的内容不多讲，App、AppAttempt、Container、Node等许多实体的使用和管理都依赖于状态机，状态机也是事件处理器。事件会触发状态机的状态转换，即，状态机对事件的处理是“执行状态转换”（隐含了“根据开始状态和事件选择状态转换”的过程）。事件可以交由中央一步调度器异步处理，也可以直接交由事件处理器处理。

以RMNodeImpl为例讲解。

RMNodeImpl被RM用来追踪NodeManager的状态。
实现了EventHandler接口，是个事件处理器：

1
2
3

public class RMNodeImpl implements RMNode, EventHandler<RMNodeEvent> {
  ...
}

注册状态转换

状态转换由成员变量stateMachine管理，成员变量stateMachineFactory用来注册状态转换（addTransition()）并生成状态机：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

...
private static final StateMachineFactory<RMNodeImpl,
                                         NodeState,
                                         RMNodeEventType,
                                         RMNodeEvent> stateMachineFactory 
               = new StateMachineFactory<RMNodeImpl,
                                         NodeState,
                                         RMNodeEventType,
                                         RMNodeEvent>(NodeState.NEW)
   //Transitions from NEW state
   .addTransition(NodeState.NEW, NodeState.RUNNING, 
       RMNodeEventType.STARTED, new AddNodeTransition())
   .addTransition(NodeState.NEW, NodeState.NEW,
       RMNodeEventType.RESOURCE_UPDATE, 
       new UpdateNodeResourceWhenUnusableTransition())
   //Transitions from RUNNING state
   .addTransition(NodeState.RUNNING,
       EnumSet.of(NodeState.RUNNING, NodeState.UNHEALTHY),
       RMNodeEventType.STATUS_UPDATE, new StatusUpdateWhenHealthyTransition())
   .addTransition(NodeState.RUNNING, NodeState.DECOMMISSIONED,
       RMNodeEventType.DECOMMISSION,
       new DeactivateNodeTransition(NodeState.DECOMMISSIONED))
   .addTransition(NodeState.RUNNING, NodeState.LOST,
       RMNodeEventType.EXPIRE,
       new DeactivateNodeTransition(NodeState.LOST))
   .addTransition(NodeState.RUNNING, NodeState.REBOOTED,
       RMNodeEventType.REBOOTING,
       new DeactivateNodeTransition(NodeState.REBOOTED))
   ...
...
private final StateMachine<NodeState, RMNodeEventType,
                           RMNodeEvent> stateMachine;
...

以下将持有stateMachine的事件处理器直接称为“状态机”。

Transition定义了“从一个状态转换到另一个状态”的行为，由转换操作、开始状态、事件类型、事件组成：

1
2
3
4
5

private interface Transition<OPERAND, STATE extends Enum<STATE>,
        EVENTTYPE extends Enum<EVENTTYPE>, EVENT> {
  STATE doTransition(OPERAND operand, STATE oldState,
                     EVENT event, EVENTTYPE eventType);
}

同时，该状态机涉及的事件类型在ResourceManager#serviceInit()方法中完成注册。

可视化

为方便可视化，Yarn源码中实现了一个状态机可视化工具，可参照Generate state graph from the State Machine Definition快速得到所需的状态机图片，或参照yarn状态机可视化一次性得到所有状态机图片。RMNode状态机如下：

执行状态转换

一个状态机涉及的状态转换非常多，但往往只涉及一种事件类型（两种及以上的比较少）。RMNodeImpl是一个事件处理器，其处理工作就是执行状态转换。但该如何根据一种事件类型，决定要采用哪个状态转换呢？
最简单的思路是写一堆if语句，或者switch大法好。实际上，对于单纯的事件处理器（各事件之前是独立、平行的），一般也是swtich简单了事，如前面提过的ApplicationMasterLauncher：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public class ApplicationMasterLauncher extends AbstractService implements
    EventHandler<AMLauncherEvent> {
  ...
  @Override
  public synchronized void  handle(AMLauncherEvent appEvent) {
    AMLauncherEventType event = appEvent.getType();
    RMAppAttempt application = appEvent.getAppAttempt();
    switch (event) {
    case LAUNCH:
      launch(application);
      break;
    case CLEANUP:
      cleanup(application);
    default:
      break;
    }
  }
  ...
}

但对于状态机，由于我们已经在状态机中保存了全部的状态转换，stateMachineFactory创建的stateMachine就可以自动根据当前状态、事件类型选择合适的事件处理器，于是RMNodeImpl等状态机的事件处理器变得异常简单：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public void handle(RMNodeEvent event) {
  LOG.debug("Processing " + event.getNodeId() + " of type " + event.getType());
  try {
    writeLock.lock();
    NodeState oldState = getState();
    try {
       stateMachine.doTransition(event.getType(), event);
    } catch (InvalidStateTransitonException e) {
      LOG.error("Can't handle this event at current state", e);
      LOG.error("Invalid event " + event.getType() + 
          " on Node  " + this.nodeId);
    }
    if (oldState != getState()) {
      LOG.info(nodeId + " Node Transitioned from " + oldState + " to "
               + getState());
    }
  }
  
  finally {
    writeLock.unlock();
  }
}

状态转换需要修改状态机的状态，为避免竞态条件，首先要获得写锁；7行让stateMachine自行选择Transition并进行状态转换。

总结

要阅读Yarn的源码，必须了解这种基于事件驱动的并发模型（事件处理器+中央异步调度器）和状态机。Yarn中，状态机被实现为事件处理器是很自然的，部分服务也被实现为事件处理器，如ApplicationMasterLauncher等。通常，事件处理器的行为类似于消息队列的消费者，而中央异步调度器类似于消息队列。

还有几点需要注意：

• RM上不只有一个中央异步调度器，要注意区分。NM同理。
• 对于状态机，并不是直接将<事件类型, 状态机>注册到中央异步调度器，而是注册<事件类型, 事件派发器>。事件派发器负责将事件派发给一个状态机实例。
• 对于状态机的状态转换事件，大部分场景下是交由中央异步调度器派发的，但某些场景下也会直接交由状态机实例。
• Yarn中的源码并不是由一个人，在短时间内完成的。其中有各种引用中央异步调度器的方式，有些是将其作为成员变量，有些从rmContext中获得，有些甚至直接将handlerInstance作为成员变量。这给阅读源码带来了很大麻烦，需要查证各dispatcher分别引用了哪一个中央异步调度器。猴子研究源码时整理过一部分，后面找机会分享出来。

HDFS的使用场景满足一个假设——“route table变化频率低”。这很容易理解，HDFS很少承接在线业务，离线业务的使用模式相对稳定，那么各子集群容量的增长速度也相对稳定。本文基于上述假设，参考Tair，简要介绍一种基于ConfigServer的轻量级服务端挂载方案。

HDFS 3.0引入了Router Based Federation方案。该方案最先被引入Yarn，能够及时进行负载均衡，更适合route table变化频率高的场景，用在目前的HDFS上有点“大材小用”。不过使用统一方案的诱惑太大了。。。

方案

需求case：增加新路由。

定义一个逻辑上的ConfigServer，负责维护路由表。NN与ConfigServer保持心跳，请求中携带负载信息，响应中携带最新的路由表，带有版本号v1。

客户端启动时从ConfigServer同步最新的路由表，带有版本号v2。访问过程如下：

1. 按照路由表的信息与NN握手，如果路由表显示NN异常，停止访问。
2. 如果v1 < v2，证明NN更新延迟，回退重试；如果重试多次仍然失败（说明NN活但路由表更新异常），则报告ConfigServer NN异常，停止访问。
3. 如果v1 > v2，证明NN上的路由信息已更新，则客户端重新从ConfigServer同步路由表，然后回到1。
4. 否则（v1 == v2），证明路由信息一致，正常访问。

实际上，不需要单独的握手过程，可以将版本号携带在每一次访问请求中。

如果现在添加一个NN3，为NN3添加多个路由，然后ConfigServer的路由表版本号增大为v3，则直到客户端与NN3都同步到路由表v3后，才能正常访问NN3。

路由删除同理，但路由修改涉及FastCopy修改和元数据管理，暂不讨论。

优缺点

优点：

• 主要的failover处理还在客户端，对服务端的影响较小。
• 尽管ConfigServer逻辑上是单点，但负载很轻、状态简单，且更改不频繁，容易配套实现HA方案。就算ConfigServer短时间不可用，v1 == v2的客户端也可以继续访问NN。
• 如果NN处理请求的同时，收到更新的路由表，可采取保守策略处理并发冲突，因为这一行为不频繁（如，对diff路由加写锁，暂时拒绝对diff路径的访问）。

缺点：

• 一致性问题：引入新组件，更难保证一致性。
• DOS问题：路由表更新时，还是需要一段时间的拒绝服务（DOS）。如果DOS机制设计不合理，很容易降低集群吞吐。

优化点

• DOS问题：如果简单以挂载点为单位，则DOS时间长，可设计forward机制，重定向已经迁移成功的部分子路径。
• 负载均衡：利用ConfigServer收集的负载信息，实现自动的负载均衡（需要改进FastCopy，涉及NN、DN的修改，如何操作？？？）。
• 延迟：ConfigServer与NN间采用Pull模型（NN向ConfigServer发送心跳）。考虑到路由修改通常希望尽快通知NN，可改为Push模型。
• 独享DN：允许NN拥有独享的DN，只需要修改FastCopy的逻辑，就可以在大集群内部支持小集群。
• 版本号：以版本号管理整张route table的粒度太大，可以细化到每条路由，也更容易实现路由的添加、修改、删除（但管理起来会更困难，暂不深入）。

参考：

• 淘宝开源 Key/Value 结构数据存储系统 Tair 技术剖析

• 水平拆分nn，使集群能容纳更多的元信息
• 负载均衡

基本原理

整体思路是一个挂载表，指明哪些路径实际指向哪个nn（或ns）。

挂载表配置在客户端，如果客户端发现路径shcema是viewfs，就按照挂载表将请求定向到实际的nn。

架构如下：

dn通过BlockPoolManager将请求路由到各ns对应的BPOfferService上；再通过BPOfferService与具体的ns（如上图NN-1）通信（与具体的nn的则是BPServiceActor）。

优缺点（简要版）

HDFS 2.x Federation使用了客户端挂载的方案，核心的优缺点也在客户端挂载上。

优点：

• 负载在客户端，对nn完全没有影响
• 实现简单

坏处：

• 维护成本高，每次修改挂载表，都必须手动同步配置文件
• 人工维护负载均衡，不能随业务变化

缺点（详细版）

1. 挂载表的缺点：挂载点的访问含义不明：
   • 由于HDFS客户端原有的机制，一个DFSClient只对应一个nameservice，所以一次路径处理不能转为多个nameservice的多次RPC。
   • 对于跨挂载点的读操作，只根据挂载配置返回假结果
   • 对于跨挂载点的写操作（rename等）操作，会抛出异常
2. 客户端挂载的缺点：客户端挂载维护成本高，一旦修改了挂载表，必须及时更新所有客户端的配置文件，否则用老的挂载逻辑写nn，后果可能非常严重。
3. 基于配置的负载均衡的缺点：如果负载发生变化，人工修改延迟较高。
4. 目前实现的缺点：目前的挂载功能非常弱：
   • 如果一个路径声明了挂载，那么其同级目录都需要进行挂载
   • 如果一个路径声明了挂载，那么其子路径不能再声明挂载
5. HDFS Federation物理上没有合并集群的缺点：如果要跨ns修改挂载逻辑，则需使用DistCp将数据从一个ns拷贝到另一个ns。实际上两个ns通常共享所有dn，拷贝造成了极大的浪费。
6. 引入viewfs的缺点：HDFS路径的scheme需要变为viewfs，而viewfs和其他scheme互不兼容。例如，将fs.defaultFS的配置从hdfs://ns1/变为viewfs://ns/，则hdfs:///test会因未指定ns抛出异常。

解决方案

1. 挂载表的缺点：将元信息整体或部分抽象到单独的角色中，以彻底抛弃挂载方案，用网络成本换scalability。如抽离FSDirectory或BlockManager。
2. 客户端挂载的缺点：服务端挂载，参考Tair ConfigServer、HDFS 3.x的Router-Based Federation。
3. 基于配置的负载均衡的缺点：自动负载均衡，但由于问题1、5，很难解决。
4. 目前实现的缺点：仿照IP协议的路由表。
   • 如果一个路径声明了挂载，那么其同级目录都需要进行挂载：非挂载目录路由到default ns匹配。
   • 如果一个路径声明了挂载，那么其子路径不能再声明挂载：路由解析时进行最长匹配匹配。
5. HDFS Federation物理上没有合并集群的缺点：FastCopy可以部分解决，或者一些“破坏性”的方案（仅用于Federation，直接修改元信息和block）。
6. 引入viewfs的缺点：统一schema后不再变化，否则无解？？？

参考：

• HDFS Federation在美团点评的应用与改进

版本：截止至2.x。

管道中的IO流

• in：上游节点到当前节点的输入流，当前节点通过in接收上游节点的packet。
• replyOut：：当前节点到上游节点的输出流，当前节点通过replyOut向上游节点发送ack。
• mirrorOut：当前节点到下游节点的输出流，当前节点通过mirrorOut向下游节点镜像发送packet。
• mirrorIn：下游节点到当前节点的输入流，当前节点通过mirrorIn接收下游节点的镜像ack。

管道中的关键线程

除了客户端，管道中的每一个dn都有两个关键线程：

1. DataXceiver线程：dn上管道流的主线程，负责接收上游的packet，并继续向下游节点管道写。（BlockReceiver#receivePacket()）。
2. PacketResponder线程：负责接收下游节点的ack，并继续向上游管道响应。

作为管道的发起者，也是管道的起点，需要主动写入数据，有三个关键线程：

1. 用户写数据的线程：用户以chunk为粒度向缓冲区写数据，写满一个packet后放入dataQueue。
2. DataStreamer线程：客户端上管道流的主线程，负责将packet从dataQueue移动到ackQueue，并向下游节点管道写packet。
3. PacketResponder线程：负责接收下游节点的ack，并移除ackQueue中的packet。

结合上图，DataXceiver线程、DataStreamer线程维护in->mirrorOut方向的packet数据流，PacketResponder线程维护mirrorIn->replyOut方向的ack数据流。

管道的整体过程

管道的生命周期分为三个阶段：

1. 管道建立：以管道的方式向下游发送管道建立的请求，从下游接收管道建立的响应。
2. 管道写：当客户端收到管道建立成功的ack时，才利用刚刚建立的管道开始管道写数据块的内容。
3. 管道关闭：以管道的方式向下游发送管道关闭的请求，从下游接收管道关闭的响应。

三个过程都是管道式的。

优缺点

• 优点：如果考虑上客户端，那么管道写的优点是网络负载比较均衡。
• 缺点：慢节点会成为带宽瓶颈，且整体上延迟更高。

如何优化延迟

管道写的方式通常称为pipeline：

为了优化管道写的延迟问题，业界还提出了多种写方案：

超步写

如果还使用管道写，可以支持超步写。

传统的管道写方案相当于TCP中的停-等协议，可仿照TCP，维护滑动窗口支持超步写，快速重传等方案同样适用。

星型写

如果网络资源充足，可以改用星型写。

如果在星型写中发生了失败，既可以选择管道写最保守的方案，中断整个写重试，也可以使用更激进的方式，如其中2个DN写成功就继续向成功节点写，而失败的节点可以在后台重试（当然，如果不低于minRep可以暂时忽略）。

显然，上述方案对于慢节点的优化效果非常显著。

Y型写

如果期望网络资源与延迟平衡，可改用Y型写。

装箱与拆箱的过程时自动进行的，因此称为“自动装箱”、“自动拆箱”，属于编译期的语法糖。

以基本类型int与包装类型Integer为例讨论。既然是编译期的语法糖，那么直接分析编译出来的字节码即可，可以使用jad工具（估计内部封装了javap一类的工具）。

装箱的实现

1
2
3

public static void main(String[] args) {
  Integer boxing = 1;
}

jad解析class文件，发现根据字节码反编译为Integer.valueOf(int)方法：

1
2
3
4
5
6
7

public static void main(String args[]) {
  Integer boxing = Integer.valueOf(1);
  //    0    0:iconst_1        
  //    1    1:invokestatic    #2   <Method Integer Integer.valueOf(int)>
  //    2    4:astore_1        
  //    3    5:return          
}

这是一个静态工厂方法，内部最终调用了Integer类的构造器Integer.<init>(init)：

1
2
3
4
5

public static Integer valueOf(int i) {
    if (i >= IntegerCache.low && i <= IntegerCache.high)
        return IntegerCache.cache[i + (-IntegerCache.low)];
    return new Integer(i);
}

特别的，Integer类默认缓存-128~127的包装对象（上界可通过java.lang.Integer.IntegerCache.high参数配置，最小127）。因此，缓存范围内的包装对象来自缓存的常量池，相同value包装对象的引用相等；缓存范围外的包装对象的引用均不相等。

拆箱的实现

1
2
3

public static void main(String[] args) {
  int unboxing = new Integer("2");
}

拆箱的时候编译为Integer.intValue()方法：

1
2
3
4
5
6
7
8
9
10

public static void main(String args[]) {
  int unboxing = (new Integer("2")).intValue();
  //    0    0:new             #2   <Class Integer>
  //    1    3:dup             
  //    2    4:ldc1            #3   <String "2">
  //    3    6:invokespecial   #4   <Method void Integer(String)>
  //    4    9:invokevirtual   #5   <Method int Integer.intValue()>
  //    5   12:istore_1        
  //    6   13:return          
}

该方法直接返回内部值Integer#value:

1
2
3

public int intValue() {
    return value;
}

自动装箱与自动拆箱的陷阱

陷阱主要出现在包装类型与基本类型混用的场景中。

以“==”为例：

• 如果两个操作数都是基本类型，则使用基本类型的比较。
• 如果一个操作数是基本类型，另一个是包装类型，则拆箱为基本类型再比较：如果包装对象为null，抛出NullPointerException。（想想看，如果装箱为包装类型，显然无法发现null）
• 如果两个操作数都是包装类型，则比较二者的引用是否相等：如果二者内部值相等，但在缓存范围外，则必然不等。

因此，如果要比较包装类型是否相等，最好显示的使用equals方法。

另外，如果是算术运算、除“==”外的逻辑运算、位运算等，则统一拆箱为基本类型再运算；有抛出NullPointerException的危险。

JDK版本：oracle java 1.8.0_102

不同语言、同一语言不同库的线程池实现有差别，不要拘泥于Java这一种，没事看看work stealing等方式也挺有意思的。

三句话拿下线程池

线程池内部是一个生产者-消费者模型：

• 用户是生产者。提交任务（task）相当于生产产品。
• 线程池中的线程（worker）是消费者，执行任务相当于消费产品。

详见源码|从串行线程封闭到对象池、线程池。

线程池的种类

可通过Executors中的静态工厂方法创建不同特点的线程池，包括：

• FixedThreadPool：维持固定nThreads个线程的线程池；使用无界的异步阻塞队列LinkedBlockingQueue作为任务队列。
• CachedThreadPool：维持最少0、最多Integer.MAX_VALUE个线程的线程池，限制线程可缓存60s，超时销毁；使用无界的同步队列SynchronousQueue作为任务队列。
• SingleThreadExecutor：维持固定1个线程的FixedThreadPool。
• ScheduledThreadPool：维持固定corePoolSize个线程的线程池；使用无界的延迟队列DelayedWorkQueue作为任务队列。
• SingleThreadScheduledExecutor：维持固定1个线程的ScheduledThreadPool。
• WorkStealingPool：并行度为parallelism的ForkJoinPool，暂不讨论。

忽略WorkStealingPool，则其他线程池底层都使用了ThreadPoolExecutor，只是参数不同。

应用场景

线程池就像水管，任务是水。

• 如果期望水管出水的速度固定，就使用FixedThreadPool。
• 如果期望水管出水的速度可以在水流大时增大，水流小时变小，就使用CachedThreadPool。
• 如果期望水管出水速度恒定为1，就使用SingleThreadExecutor。
• 如果期望水管延迟出水（延迟可控，或周期性），就使用ScheduledThreadPool。

ThreadPoolExecutor各参数的意义

• corePoolSize：线程池维持的最小线程数（ScheduledThreadPool的该参数设计有误），懒初始化。
• maximumPoolSize：线程池维持的最大线程数。
• keepAliveTime，unit：如果线程池中的线程数大于corePoolSize小于等于maximumPoolSize，则选择闲置时间超过keepAliveTime（单位为unit）的线程销毁，直到无线程可销毁或线程数等于corePoolSize。
• workQueue：应该被称为taskQueue，维护提交到线程池的task。如果设置为无界队列，则线程数量将维持为corePoolSize；否则，当队列满时，尝试增加线程数直到maximumPoolSize或队列不满。
• threadFactory：任务以Runnable、Callable的形式提交，生产线程时使用threadFactory的工厂方法。默认Executors.defaultThreadFactory()。
• handler：如果workQueue是有界的，那么当workQueue满时，使用handler处理无法提交的新任务。默认Executors.defaultHandler，workQueue满时抛出RejectedExecutionException。

观察corePoolSize、maximumPoolSize、workQueue三者的关系可知：

• 如果使用有界线程池，则最好搭配有界队列，否则maximumPoolSize参数无效。
• 相对的，CachedThreadPool被设计为一种maximumPoolSize无效的缓冲池，同时，因此，必须使用无界的同步队列，让“入队”直接变成“执行”。

线程池大小的估算

最简化公式

• CPU 密集型应用：线程池大小设置为 N + 1
• IO 密集型应用：线程池大小设置为 2N

公式的意义在于避免陷入极端情况。其中，计算密集型任务假设“等待时间/计算时间”等于0，IO密集型任务假设“等待时间/计算时间”等于1。

为什么要有+1呢？

这是因为，就算是计算密集型任务，也可能存在缺页等问题（需要了解虚拟内存和物理内存的分配），产生“隐式”的IO。多一个额外的线程能确保CPU时钟周期不会被浪费，又不至于增加太多线程调度成本。

严格公式：

假设每个线程的“等待时间 / 计算时间”大小相等，显然，“计算时间 / (计算时间 + 等待时间)”也相等。对1个线程而言，只有计算时间占用了逻辑CPU，假设这个线程一直运行在同1个逻辑CPU上，显然，该逻辑CPU的CPU利用率即等于“计算时间 / (计算时间 + 等待时间)”。

对于多个线程的情况是一样的，则有公式：

1

逻辑CPU数 * CPU利用率 / 线程数 = 计算时间 / (计算时间 + 等待时间)

倒腾倒腾，得到：

1

线程数 = (1 + 等待时间/计算时间) * 逻辑CPU数 * CPU利用率

• “1 + 等待时间/计算时间” 只与任务本身有关。
• 逻辑CPU数可通过cat /proc/cpuinfo | grep -c processor得到。
• 标准的CPU利用率要通过实际监控得到，但在估算线程池大小时，应看做“期望得到的CPU利用率”，即可分配给该任务的CPU比例。如果只打算分配一半CPU给任务的话，就是0.5。

如果估算得到的线程数比较多，那么还要适当提高可分配的CPU比例，因为线程切换的成本随线程数增加而增加。如果竞争较激烈，则可以适当降低可分配的CPU比例，因为竞争通常也会导致线程阻塞，使CPU空闲。

final类

final类表示该类是完整（可理解为最终版本）的，禁止扩展。final标记会写入class文件的类定义中，在编译期检查，如果发现上游extends了一个final类后，则编译失败，从语法上保证不能extends一个final类。

final类经常用于不可变类的构造中：如果不使用final修饰，且有对子类可见的可变成员变量，则extends该“不可变类”后，子类就变成了可变类。考虑到多态的存在，这种“歧义”非常危险。详见：实现不可变类时如何禁止子类化？。

例：String类、Interger类等：

1

public final class String

final方法

与final类的语义相似，final方法表示该方法是完整的，禁止重写。final标记会写入class文件的成员方法定义中，在编译期检查，如果发现继承链上游有函数签名相同的final方法（重写），则编译失败，从语法上保证不能重写一个final方法；同时，在编译期完成对final方法的解析（静态绑定）。

例：com.sun.org.apache.bcel.internal.classfile.Signature中的dump方法：

1
2
3
4
5

public final void dump(DataOutputStream file) throws IOException
{
  super.dump(file);
  file.writeShort(signature_index);
}

final变量

final成员变量

final成员变量体现了最直观的final语义：final成员变量表示该成员变量只读（在第一次赋值后就不能再修改）。final标记会写入class文件的成员变量定义中，在编译器和运行期都会进行检查，如果发现第二次修改就编译失败或抛出异常。

如果想实现不可变类，通常建议尽量使用final修饰每一个成员变量（延迟初始化等会违背这一建议）。

如果final成员变量的初始化被收集到该类的构造方法中，则final成员变量初始化之前的变量通常具有内存可见性，但这一性质并不容易应用，不建议利用。详见：一文解决内存屏障。

例：Integer#value：

1
2
3
4
5

private final int value;
public Integer(int value) {
    this.value = value;
}

显式的用构造方法初始化final成员变量。

常量

如果在成员变量声明时完成初始化（第一次赋值），则该成员变量被JVM视作常量。

对于编译期能确定初始值的常量（如final int a = 1;），通常能通过常量折叠、常量传播等技术，在编译期完成常量的优化和解析。

例：Integer.SIZE和Integer.BYTES：

1
2
3

@Native public static final int SIZE = 32;
public static final int BYTES = SIZE / Byte.SIZE;

final局部变量

final局部变量也表示该局部变量只读，但与final成员变量不同，final局部变量只是java中的语法糖，局部变量上的final修饰并不会写入class文件，更无法出现在运行期。如果局部变量被final修饰，则编译器在编译时会检查该变量是否有可能发生第二次修改，有可能就编译失败；否则，消除final修饰。

例：

java.lang.OutOfMemoryError:Java heap space

这是最常见的OOM原因。

堆中主要存放各种对象实例，还有常量池等结构。当JVM发现堆中没有足够的空间分配给新对象时，抛出该异常。具体来讲，在刚发现空间不足时，会先进行一次Full GC，如果GC后还是空间不足，再抛出异常。

引起空间不足的原因主要有：

• 业务高峰，创建对象过多
• 内存泄露
• 内存碎片严重，无法分配给大对象

java.lang.OutOfMemoryError:Metaspace

方法区主要存储类的元信息，实现在元数据区。当JVM发现元数据区没有足够的空间分配给加载的类时，抛出该异常。

引起元数据区空间不足的原因主要有：

• 加载的类太多，常见于Tomcat等容器中

但是元数据区被实现在堆外，主要受到进程本身的内存限制，这种实现下很难溢出。

java.lang.OutOfMemoryError:Permgen space

jdk7中，方法区被实现在永久代中，错误原因同上。

永久代非常小，而且不会被回收，很容易溢出，因此，jdk8彻底废除了永久代，将方法区实现在元数据区。

java.lang.OutOfMemoryError:Unable to create new native thread

以Linux系统为例，JVM创建的线程与操作系统中的线程一一对应，受到以下限制：

• 进程和操作系统的内存资源限制。其中，一个JVM线程至少要占用OS的线程栈+JVM的虚拟机栈 = 8MB + 1MB = 9MB（当然JVM实现可以选择不使用这1MB的JVM虚拟机栈）。
• 进程和操作系统的线程数限制。
• Linux中的线程被实现为轻量级进程，因此，还受到pid数量的限制。

当无法在操作系统中继续创建线程时，抛出上述异常。

解决办法从原因中找：

• 内存资源：调小OS的线程栈、JVM的虚拟机栈。
• 线程数：增大线程数限制。
• pid：增大pid范围。

其他异常

java.lang.OutOfMemoryError:GC overhead limit exceeded

默认配置下，如果GC花费了98%的时间，回收的内存都不足2%的话，抛出该异常。

java.lang.OutOfMemoryError:Out of swap space

如果JVM申请的内存大于可用物理内存，操作系统会将内存中的数据交换到磁盘上去（交换区）。如果交换区空间不足，抛出该异常。

参考:

• Java内存溢出(OOM)异常完全指南

解释类加载与初始化

首先，区分类加载classloading与类生命周期中的加载loading阶段：

类加载classloading通常不单单指类的加载loading阶段，而指类从加载loading到初始化initialization阶段的这一段时间内的行为。

那么，什么情况下需要开始加载loading呢？JVM规范中并没有强制约束，取决于虚拟机的具体实现。但是对于初始化initialization阶段，JVM规范则严格规定了有且只有5种情况必须立即对类进行“初始化”（因此，加载、验证、准备、解析自然需要在此之前开始）。

因此，面试中常考的“类加载时机”严格来说指“类的初始化时机”。用于演示类加载顺序的静态语句块、静态变量赋值等操作也是在初始化时机完成的。

类的完整生命周期如下：

什么时候初始化

4种常见场景：

1. 当虚拟机启动时，用户需要指定一个要执行的主类MainClass（即包含psvm方法的那个类），虚拟机会先初始化这个主类。
2. 遇到new、getstatic、putstatic或invokestatic这4条字节码指令时。生成这4条指令的典型Java代码场景是：
   1. 使用new关键字实例化对象。
   2. 读取或设置一个类的静态字段——被final修饰、已在编译期把结果放入常量池的静态字段除外。
   3. 调用一个类的静态方法。
3. 当初始化一个类的时候，如果发现其父类还没有初始化，则需要先触发其父类的初始化。
4. 使用java.lang.reflect包的方法对类进行反射调用时。

除此之外，比较常用的另一个场景是调用Class.forName()方法时，可指定initialize参数为true，最后通过JNI加载类并初始化。

1种不常见场景：

1. 当使用JDK 1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。

对于这5种场景，虚拟机规范中使用了一个很强烈的限定语：“有且只有”。

这5种场景中的行为称为对一个类进行主动引用。除此之外，所有引用类的方式都不会触发初始化，称为被动引用。

我们不需要去关注被动引用。被动引用仅仅指那些看上去向主动引用，实际上却不是的情况，如：

• 通过子类引用父类的静态字段，不会导致子类初始化（如何实现？）
• 通过数组定义类引用类，不会触发此类的初始化（JVM为每个数组生成专有的类型，比如数组A[]的类型是[A）
• 引用常量，不会触发此类的初始化（常量在编译阶段会存入调用类的常量池中（常量传播），运行期也就没有直接引用到定义常量的类）

参考:

• Java 中对类的主动引用和被动引用

秋招也快结束了。从今天开始，慢慢整理面试时准备的资料和之前看书做的笔记。部分内容单纯面向面试整理，牺牲深度换取广度，不过已经能够了解很多基本问题了。

过程

1. 初始标记（CMS initial mark）：标记一下GC Roots能直接关联到的对象。需要STW，速度很快。
2. 并发标记（CMS concurrent mark）：进行GC Roots Tracing。不需要STW。会产生浮动垃圾。
3. 重新标记（CMS remark）：找到并发标记期间产生的浮动垃圾。需要STW，停顿时间一般会比初始标记稍长，但远比并发标记短。
4. 并发清除（CMS concurrent sweep）：清除已标记的垃圾。不需要STW。会产生浮动垃圾，只能等下一次GC清理。

重新标记的过程？为什么比并发标记的时间短？

不考虑标记对象年龄等操作，最容易想到的原因是：

• 对象数的区别：“并发标记”过程需要扫描所有对象，标记出不可达的对象（该清除）和可达的对象（不该清除）；“重新标记”只需要扫描在“并发标记”过程中被标记为可达或新创建的对象，检查其是否在“并发标记”过程中被标记为可达之后，由于用户使用变的不可达了
• 并发环境的区别：“并发标记”是与用户线程一起工作的，并发瓶颈较窄（工作线程少+安全检查）；“重新标记”需要stop the world，之后仅有“重新标记”的线程在工作，并发瓶颈宽的多

PS：关于对象数的区别要想清楚，在对象分配后，如果对象有一瞬间不可达，则该对象以后都将不可达，可对其清理。因此，重新标记时不需要检查这部分对象。

并发清除的过程？如何才能让用户边使用，边清除？

还是那句话：

在对象分配后，如果对象有一瞬间不可达，则该对象以后都将不可达，可对其清理。

所以，已经在“并发标记”和“重新标记”过程被标记为不可达的对象，以后都不会再被用户使用，清除这些对象对用户完全无影响。

唯一可能有影响的是整理内存的过程，不过也只需要同步使用对象和整理对象两个动作。

CMS的优点、缺点？

优点：

1. 大部分时间可与用户线程并发工作
2. 低停顿

缺点：

1. 对CPU资源非常敏感。并发标记和并发清理与用户线程一起工作，如果用户线程也是CPU敏感的，那么必然影响用户线程。
2. 无法处理浮动垃圾（Floating Garbage）。并发标记与并发清除过程会产生浮动垃圾，如果CMS之前预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将退化使用Serial Old收集器，重新进行老年代的垃圾收集，这样停顿时间就很长了。可使用XX:CMSInitiatingOccupancyFraction参数设置触发CMS时的老年代空间比例（剩余空间就是预留空间），在JDK1.6中默认为92%。
3. 基于“标记-清除算法”，收集结束时会有大量空间碎片产生，导致明明剩余空间充足，却无法为大对象分配足够的连续内存。可打开-XX：+UseCMSCompactAtFullCollection开关参数（默认打开）在进行Full GC之前整理内存碎片（称为“压缩”）；使用-XX:CMSFullGCsBeforeCompaction参数（默认0）设置多少次不带压缩的Full CG之后才进行一次带压缩的Full GC。内存整理无法并行，还需要STW，需要适当调整内存整理的频率，在GC性能与空间利用率之间平衡。

PS：

• 浮动垃圾：由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处 理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。在这期间用户可能创建新的对象。为了处理这部分浮动垃圾和对象，CMS在并发清理之前，需要预留出足够空间给并发清理期间的用户线程使用。一般会显示使用-XX:CMSInitiatingOccupancyFraction参数设置触发CMS时的老年代空间比例，如果老年代增长不是太快，可以适当提高比例，以减少Full GC的次数。

关于浮动垃圾和内存碎片的问题。HDFS namenode在堆内存达到100G规模时，通常设置75%触发Full GC，不开启压缩，优先考虑STW造成的延迟。

对于大部分人而言，如果综合学习成本和开发效率，能用IDE还是用IDE吧。

vim还是emacs

不要纠结，抓起一个就是干。

基本概念

对于我等vim小白而言，在使用vim之前，务必要清楚“命令模式”（Command mode）、“底线命令模式”（Last line mode）、“输入模式”（Insert mode，也叫做“编辑模式”）三个概念，和两三个常用的“命令”。

首先，保证你处于unix-style的系统（如各种linux发行版，macOS等。windows未实验），输入法处于英文的输入模式。然后，用vim命令打开一个文件：

1

$ vim hello_world.txt

如果文件不存在，vim会帮我们创建文件。

什么都不做。现在我们处于“命令模式”：

命令模式可以直接敲击键盘进行操作，但不能编辑。没内容没法操作，因此，我们先敲击字母“i”，进入“输入模式”：

输入模式的特点是，窗口最下方有“INSERT”字样。输入模式就可以输入内容了，输入“hello world”。字母“i”在命令模式下是一个“命令”，在输入模式下就是个单纯的字母了——敲击“<Enter>”键换到下一行，敲击字母“i”就输入了一个“i”：

接下来，敲击"<Esc>"键（键盘左上角）退出输入模式。退出后，将回到命令模式，就不能编辑了：

看，回到命令模式后，窗口最下方就没有有“INSERT”字样了。

最后，敲击符号“:”（切记，英文符号）进入底线命令模式：

底线命令模式的特点是，窗口最下方有一个“:”。在“:”之后，我们可以输入命令；然而这里的命令与命令模式下的命令有所不同，比如刚才的字母“i”，在这里输入是无效的。我们先敲击“<Esc>”键退出输入模式或底线命令模式，以回到命令模式。然后，再次敲击符号“:”，重新进入底线命令模式。这次，我们输入“wq”，敲击“<Enter>”键——“wq”的意思是“保存并退出”，在这之后，我们保存内容并退出了vim。

实际上，“wq”是连续的两个命令：“w”是保存“write”的缩写，“q”是退出“quit”的缩写，unix-style鼓励我们使用缩写。

让我们验证文件内容：

1
2
3

$ cat hello_world.txt
hello world
i

good job！

快捷键速成手册

vim的简单在于，掌握了三个模式后，剩下的就是查阅各种牛逼的快捷键，然后熟练操作。不过，与其他长篇累牍介绍vim快捷键的文章不同，猴子崇尚“less is more”。

下面列出了猴子最常用的快捷键，可以像猴子一样，把它当做极简版的快捷键手册，直接配置在“.vimrc”（vim的配置文件，在用户目录"~"下）中：

• "开头的行是注释，其他是vim脚本，vim启动时执行“.vimrc”中的全部vim脚本
• 绝大部分是命令模式的命令
• 以“:”开头的是底线命令模式的命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

" 一些特殊的vim脚本，可以在底线命令模式执行，暂时忽略它们
syntax on	" 根据语法渲染
set nu	" 显示行号
" set nu!	" 不显示行号
set colorcolumn=100
set tabstop=4
set expandtab
set autoindent
set paste!
" 极简版速成手册
" 各种移动光标
" vim建议光标移动使用"hjkl"，让手保持在键盘中心。但猴子暂时还是习惯使用方向键
" h 向左移动一次光标
" j 向下移动一次光标
" k 向上移动一次光标
" l 向右移动一次光标
" b 移动光标到上一词首
" 未定义移动光标到下一词尾
" w 移动光标到下一词首
" e 移动光标到下一词尾
" <ctrl> + u 向上滚动10行（行数可配置）
" <ctrl> + d 向下滚动10行
" <ctrl> + f 向下滚动一屏
" <ctrl> + b 向上滚动一屏
" gg 移动光标到文件首
" G 移动光标到文件尾
" 将数字和方向命令组合在一起，vim大法好
" 10k 移动光标到向上10行，10可以是任意正数。自然10j就是光标向下移动10行
" 10h 移动光标到向左10个字符，10l同理
" <ctrl> + o 移动光标到上一位置
" 进入输入模式
" i 在当前位置后插入字符
" I 在当前位置前插入字符
" o 在当前行后插入行
" O 在当前行前插入行
" 复制
" y 复制选中范围（配合后面的可视模式操作）
" yy 复制行
" y10 从当前行开始向下数，共复制11行
" ye 复制到词尾（含词尾），其他组合同理
" 粘贴
" p 在当前位置后插入
" P 在当前位置前插入
" 剪切（复制 + 删除）
" d 剪切选中范围
" dd 剪切行
" d10 从当前行开始向下数，共剪切11行
" de 删除到词尾（含词尾），其他组合同理
" x 剪切选中范围。命令模式至少选中一个字符，因此x更常用于剪切单个的字符，其他范围类操作建议使用d
" 剪切 = 复制 + 删除, 意味着接下来可以进行粘贴
" v 字符可视模式（一种特殊的命令模式）
" V 行可视模式
" <ctrl> + v 列可视模式。进入列可视模式后，可配合I指令进行列编辑
" 可视模式选择“块”后，方便进行可视化的剪切和复制，执行指令或敲击<Esc>键退出可视模式
" 选择“块”时，命令模式下各种光标移动方式仍然有效，使得用户能够高效选择从光标起点（进入可视模式的位置）到光标终点（光标移动后的位置）的块
" r 覆盖，可以简化“先删除再输入”的操作顺序
" u undo
" <ctrl> + r redo
" :w 写入
" :q 退出
" :wq 写入+退出，命令的灵活组合是vim效率所在
" :10 光标移动到第10行（行号从1开始）

just do it!

操作系统：CentOS 6.5（Linux 2.6）。

inode & block

block和inode的意义

理解inode，要从文件储存说起。

文件储存在硬盘上，硬盘的最小存储单位叫做”扇区“（Sector，常见512B），多个扇区组成的一个”块“（block，常见4096B，即连续8个sector组成一个block）。操作系统一次性读取一个块（8个连续8个扇区），以提高磁盘IO效率。因此，块是磁盘读写的最小单位。

同时，块是文件存取的最小单位，多个块组成文件内容。显然，还需要一个结构存储文件元信息（文件的创建者、创建日期、内容大小等），也就引出了索引节点（inode，Index Node）。索引节点用于索引一个文件的所有块。

inode的内容

inode维护文件的元信息。可以用stat <path>命令查看某个文件的inode信息：

1
2
3
4
5
6
7
8

➜  fs_test stat example.txt
  File: "example.txt"
  Size: 4847      	Blocks: 16         IO Block: 4096   普通文件
Device: fd00h/64768d	Inode: 261774      Links: 1
Access: (0664/-rw-rw-r--)  Uid: (  500/    lauo)   Gid: (  500/    lauo)
Access: 2018-03-09 22:55:01.306013501 +0800
Modify: 2018-03-09 22:55:01.307013501 +0800
Change: 2018-03-09 22:55:31.796013501 +0800

除了文件名以外的所有文件信息，都存在inode之中。

至于为什么没有文件名，下面会有详细解释。

inode大小与inode数量上限

inode也会消耗硬盘空间，所以硬盘格式化的时候，操作系统自动将硬盘分成两个区域：一个是数据区（data area），存放block；另一个是inode区（也交inode表，inode table），存放inode。实际上还有其他区，暂时不考虑。

每个inode节点的大小，一般是128B或256B。可以用如下dumpe2fs -h <disk_path>命令查看：

1
2
3

➜  fs_test sudo dumpe2fs -h /dev/sda1 | grep "Inode size"
dumpe2fs 1.41.12 (17-May-2010)
Inode size:	          128

/dev/sda1指挂载的SATA盘。至于SATA盘是什么，猴子暂时木有关心。

inode节点的最大数量，在格式化时就给定。在初始化文件系统时，inode table初始大小为0，然后，操作系统每分配1024B或2048B给data area，就分配inode大小的空间（128B或256B）给inode table，保持2048 : 256 = 8 : 1的分配比例。注意，此处仅仅是保持data area与inode table的分配比例（如8:1），与未来一个inode指向多少block无关。

假定在一块2GB的硬盘中，data area与inode table的分配比例为8 : 1，则inode table占用11.11%的磁盘空间，即227.56MB；inode size 256B，则inode数量的上限为932067。

使用如下df -i命令查看每个硬盘分区的inode数量上限、已用数量、剩余数量等：

1
2
3
4
5

➜  fs_test df -i
Filesystem                   Inodes IUsed  IFree IUse% Mounted on
/dev/mapper/VolGroup-lv_root 912128 33668 878460    4% /
tmpfs                         63627     1  63626    1% /dev/shm
/dev/sda1                    128016    38 127978    1% /boot

既然inode节点的数量存在上限，而每个文件又必须有一个inode，因此有可能发生inode已经用光，但是硬盘还未存满的情况（如每个文件的大小都小于2048B）。这时，就无法在硬盘上创建新文件了。

inode号

Linux系统使用inode号来识别文件，文件名仅仅是文件的别名。

表面上，用户通过文件名打开文件——实际上，系统内部分三步完成这一过程：

1. 找到文件名对应的inode号（内存）。
2. 通过inode号码，获取inode内容（磁盘）。
3. 最后，根据inode内容，找到文件数据存储的所有block，读出数据（磁盘）。

因此，如果只获取文件名与inode号码，是不需要读取磁盘的。

使用ls -i <path>命令查看文件名对应的inode号码：

1
2

➜  fs_test ls -i example.txt
261774 example.txt

inode到block的映射

// TODO: 操作系统讲过，待考证。

文件 & 目录

文件

介绍inode时，已经说明了文件的实现——每个文件都对应一个inode，文件名是文件的别名，inode是文件的本体；操作系统维护文件名到inode的映射。

Linux系统中，一切皆文件，包括后面要解释的目录、硬链接、软链接，包括socket、设备、内存等。理解这一点非常重要。

目录文件

Linux系统中，目录（directory）也是一种文件。打开目录，实际上就是打开目录文件。

目录文件的结构非常简单，就是一系列目录项（dirent）的列表。目录项是一个二元组<文件名, inode号码>。

ls <path>命令只列出目录文件中的所有文件名：

1
2

➜  fs_test ls exp_dir
example_1.txt  ex_dir_1

ls -i <path>命令列出整个目录文件，即文件名和inode号码：

1
2

➜  fs_test ls -i exp_dir
261780 example_1.txt  261781 ex_dir_1

前面ls -i <file>的时候只需要查询文件名到inode的map；而此处ls -i <dir>则多一次读取目录文件的开销。

如果要查看文件的详细信息，就必须根据inode号码，读取inode内容（磁盘）。ls -l <path>命令列出文件的详细信息：

1
2
3
4

➜  fs_test ls -l exp_dir
总用量 12
-rw-rw-r--. 1 msh msh 4847 3月   9 23:15 example_1.txt
drwxrwxr-x. 2 msh msh 4096 3月   9 23:16 ex_dir_1

理解了上面这些知识，就能理解目录的权限：

• 目录文件的读权限（r）和写权限（w）针对目录文件本身
• 由于目录文件内只有文件名和inode号码，如果想读取目录项的inode内容，Linux规定需要用户拥有目录的可执行权限（x）。

硬链 & 软链

硬链接

一般情况下，文件名和inode号码是”一一对应”的。但是，Linux系统允许多个文件名指向同一个inode号码，也就是硬链接（hard link）。

一旦建立硬链，就不再区分则源文件与硬链文件的概念，二者是指向相同inode的“平等的两个文件”（如果以文件名区分）。由于指向相同的inode，硬链接的行为就很好理解了：

• 如果修改文件内容，则通过其他文件名访问的内容也随之修改。
• 如果删除文件，则系统检查是否还有其他文件名指向inode。如果没有，则删除inode与block；否则，仅删除当前文件名到inode的映射。

使用ln <src> <hard_link>命令创建硬链接：

1
2
3
4
5
6

➜  fs_test ln example.txt example_2.txt
➜  fs_test ls -li
总用量 20
261774 -rw-rw-r--. 2 msh msh 4847 3月   9 22:55 example_2.txt
261774 -rw-rw-r--. 2 msh msh 4847 3月   9 22:55 example.txt
261779 drwxrwxr-x. 3 msh msh 4096 3月   9 23:16 exp_dir

第一列是inode号，第3列是指向该inode的文件名的数量，即链接数。可见，example.txt、example_2.txt的inode号都为261774；公有2个文件名指向inode 261774。

顺便说一下，“.“和”..“也是目录，通过硬链分别指向当前目录和父目录。因此，所有目录的链接数必然大于等于2，即当前目录和”.”目录。如上，exp_dir目录的链接数为3。

软链接

硬链使用起来不是那么方便，管理起来也比较麻烦。于是使用另一种更简单的方式实现了软链（soft link，或称符号链接symbolic link）：如果文件A软链指向文件B，则标记文件A为软链文件，并在文件A中记录文件B的路径。

此时，文件A与文件B使用不同的inode。那么，如何通过文件A访问到文件B的内容呢？操作系统会在我们访问文件A时，发现文件A是软链文件，则自动将访问者导向文件B。因此，无论打开哪一个文件，最终读取的都是文件B。

对于读、修改操作，硬链接与软连接实现的效果相同。但删除（包括rename）操作上的表现不同：

• 如果删除文件A，则文件B无影响。
• 如果删除文件B，则文件A依然存在，但访问文件A时会报错”没有那个文件或目录”。

使用ln -s <src> <soft_link>命令创建软链接：

1
2
3
4
5
6
7

➜  fs_test ln -s example.txt example_3.txt
➜  fs_test ls -li
总用量 20
261774 -rw-rw-r--. 2 msh msh 4847 3月   9 22:55 example_2.txt
261782 lrwxrwxrwx. 1 msh msh   11 3月  10 00:05 example_3.txt -> example.txt
261774 -rw-rw-r--. 2 msh msh 4847 3月   9 22:55 example.txt
261779 drwxrwxr-x. 3 msh msh 4096 3月   9 23:16 exp_dir

可见， example_3.txt是软链接文件，指向example.txt，二者的inode号码不同，链接数也没有关系。

参考：

• 理解inode
• 硬盘类型和Linux分区
• linux文件系统—inode及相关概念 inode大小的最佳设置

CAP定理

CAP定理：一个分布式系统最多只能同时满足一致性（Consistence）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

• 一致性：所有节点在同一时间的看到的数据相同。
• 可用性：读、写永远都能成功，即，服务一直可用。
• 分区容错性：即使系统的某个分区遇到严重的故障，系统能继续提供服务。

CAP中的权衡

根据CAP定理，我们无法同时满足一致性、可用性、分区容错性这三个特性。那么，要舍弃哪个呢？

对于多数大型互联网应用的场景，主机众多、部署分散，节点故障、网络故障是常态，必须保证P；应用的目的是提供服务，因此通常也要保证A。既然要保证P和A，就只能不同程度的舍弃C，牺牲一些用户体验。严格来讲，部分应用的A也不必保证100%，因此，主流做法是首要保障P、在A和C之间取舍、重A轻C。

但是，对于金融服务，必须保证C；大规模金融服务几乎必然涉及网络分区，所以也要保证P；为了保证C、P，只能牺牲A（停止服务）。对于某些特殊的金融服务，需要7*24小时提供服务，则改为牺牲部分P（如单节点主从备份，故障切换），保障C、A。

BASE定理

BASE定理是对CAP定理的延伸：即使无法做到强一致性（Strong Consistency），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。CAP中提到的一致性是强一致性，所谓“牺牲一致性”指牺牲强一致性保证弱一致性。

BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。

• 基本可用：出现故障的时候，允许损失部分可用性，即，保证核心可用。

如，电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务

• 软状态：允许系统存在中间状态，而该中间状态不会影响系统整体可用性。

软状态本质上是一种弱一致性，允许的软状态不能违背“基本可用”的要求。如，分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时（某些时刻副本数低于3）。

• 最终一致性：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。

软状态的终极目标是最终一致性。如，分布式存储的副本数最终会达到稳定状态。

ACID和BASE的区别与联系

ACID是事务的四个基本性质，属于传统数据库常用的设计理念，追求强一致性模型，详见事务的ACID和四个隔离级别。BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性（与分区容错性）。

在分布式系统设计的场景中，通常系统组件对一致性的要求不同，对ACID和BASE的取舍也就不同。

本文大部分内容基于TCP 的那些事儿（下）修改而来，部分观点与原文不同，重要地方增加了解释。

TCP的流量控制

RTT算法

根据前文对TCP超时重传机制的介绍，我们知道Timeout的设置对于重传非常重要：

• 设长了，重发就慢，丢了老半天才重发，没有效率，性能差。
• 设短了，会导致可能并没有丢就重发。于是重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发。

而且，这个超时时间在不同的网络环境下不同，必须动态设置。为此，TCP引入了RTT（Round Trip Time，环回时间）：一个数据包从发出去到回来的时间。这样，发送端就大约知道正常传输需要多少时间，据此计算RTO（Retransmission TimeOut，超时重传时间）。 听起来似乎很简单：在发送方发包时记下t0，收到接收方的Ack时记一个t1，于是RTT = t1 – t0。然而，这只是一个采样，不能代表网络环境的普遍情况。

经典算法

RFC793 中定义了一个经典算法：

1. 首先，采样RTT，记下最近几次的RTT值。

2. 然后，使用加权移动平均算法（Weighted Moving Average Method）做平滑，计算SRTT（Smoothed RTT）：

   1	SRTT = ( α * SRTT ) + ((1- α) * RTT) (通常取0.8≤α≤0.9，α越大收敛速度越快)

1. 最后，计算RTO：
   RTO = min [ UBOUND, max [ LBOUND, (β * SRTT) ] ] (通常取1.3≤β≤2.0)

Karn / Partridge 算法

经典算法描述了RTO计算的基本思路，但还有一个重要问题：RTT的采样取“第一次发Seq+收Ack的时间”，还是“重传Seq+收Ack的时间”？

如图：

• 情况（a）中，RTT的采样取“第一次发Seq+收Ack的时间”。假设第一次发的Seq彻底丢包了，则采样到的时间多算了“从第一次发到重传的间隔”。
• 情况（b）中，RTT的采样取“重传Seq+收Ack的时间”。假设是Ack传输的慢，导致恰好刚重传就收到了接收方之前发出的Ack，则采样到的时间少算了“从第一次发到重传的间隔”。

问题的本质是：发送方无法区分收到的Ack对应第一次发的Seq还是重传的Seq（进入网络就都一样了）。针对该问题，Karn / Partridge算法选择回避重传的问题：忽略重传的样本，RTT的采样只取未产生重传的样本。

简单的忽略重传样本也有问题：假设当前的RTO很小，突然发生网络抖动，延时剧增导致要重传所有的包；由于忽略重传样本，RTO不会被更新，于是继续重传使网络更加拥堵；拥堵导致更多的重传，恶性循环直至网络瘫痪。Karn / Partridge算法用了一个取巧的办法：只要一发生重传，就将现有的RTO值翻倍（指数回退策略），待网络恢复后再仿照经典算法逐渐平滑以降低RTO。

该算法已经做到可用，然而网络抖动对性能的影响比较大。

Jacobson / Karels 算法

前面两种算法均使用加权移动平均算法做平滑，这种方法的最大问题是：很难发现RTT值上的较大波动，因为被平滑掉了（1 - a比较小，即最新RTT的权重小）。针对该问题，Jacobson / Karels算法引入了最新采样的RTT值和平滑过的SRTT值的差距做因子，即DevRTT（Deviation RTT，RTT的偏离度），同时考虑SRTT带来的惯性和DevRTT带来的波动：

1
2
3

SRTT = SRTT + α(RTT – SRTT)  —— 计算SRTT
DevRTT = (1-β)*DevRTT + β*(|RTT-SRTT|) —— 计算SRTT和最新RTT的差距（加权移动平均）
RTO= µ * SRTT + ∂ *DevRTT —— 同时考虑SRTT（惯性）与DevRTT（波动）

Linux 2.6采用该算法计算RTO，默认取α = 0.125, β = 0.25, μ = 1, ∂ = 4（玄学调参，你懂的）。

TCP滑动窗口

TCP使用滑动窗口（Sliding Window）做流量控制与乱序重排。乱序重排在TCP的重传机制中已经介绍，下面介绍流量控制。

TCP头里有一个字段叫Window（或Advertised Window），用于接收方通知发送方自己还有多少缓冲区可以接收数据。发送方根据接收方的处理能力来发送数据，不会导致接收方处理不过来，是谓流量控制。暂且把Advertised Window当做滑动窗口，更容易理解滑动窗口如何完成流量控制，后面介绍拥塞控制时再说明二者的区别。

观察TCP协议的发送缓冲区和接收缓冲区：

假设位置序号从左向右增长（常见的读、写缓冲区设计），解释一下：

• 发送方：LastByteAcked指向收到的连续最大Ack的位置；LastByteSent指向已发送的最后一个字节的位置；LastByteWritten指向上层应用已写完的最后一个字节的位置。
• 接收方：LastByteRead指向上层应用已读完的最后一个字节的位置；NextByteExpected指向收到的连续最大Seq的位置；LastByteRcvd指向已收到的最后一个字节的位置。可以看到NextByteExpected与LastByteRcvd中间有些Seq还没有到达，对应空白区。

据此在接收方计算AdvertisedWindow，在发送方计算EffectiveWindow：

• 接收方在Ack中记录自己的AdvertisedWindow = MaxRcvBuffer – (LastByteRcvd - LastByteRead)，随Ack回复到发送方。
• 发送方根据Ack中的AdvertisedWindow值，需保证LastByteSent - LastByteAcked ≤ AdvertisedWindow，则窗口内剩余可发送的数据大小EffectiveWindow = AdvertisedWindow - (LastByteSent - LastByteAcked)，以保证接收方可以处理。

AdvertisedWindow与EffectiveWindow

AdvertisedWindow衡量接收方还能接收的数据量，发送方要根据AdvertisedWindow决定接下来发送的数据量上限，即EffectiveWindow（可能为0）。

AdvertisedWindow的计算

由于乱序问题的存在，LastByteRcvd可能指向Seq(LastByteSent)，而Seq(LastByteAcked + 1)至Seq(LastByteSent - 1)都还在路上，即将到达接收方，最好的情况是不丢包（丢包后会重传），则LastByteRcvd之后、接收缓冲区边界之前的空间就是发送方下一次发送数据的长度上限（重传不属于下一次发送），因此，AdvertisedWindow = MaxRcvBuffer – (LastByteRcvd - LastByteRead)。

EffectiveWindow的计算

LastByteRcvd还可能指向Seq(LastByteAcked)（一个新包都没有收到），显然AdvertisedWindow的公式不变，而Seq(LastByteAcked + 1)至Seq(LastByteSent)都还在路上，未来将到达接收方，进入接收缓冲区，则“还在路上的Seq(LastByteAcked + 1)至Seq(LastByteSent)”不应超过接收缓冲区的剩余空间AdvertisedWindow（目前等于MaxRcvBuffer），这要求的是上一次发送满足LastByteSent - LastByteAcked ≤ AdvertisedWindow，那么LastByteSent之后、接收缓冲区剩余空间边界之前的空间就是发送方窗口内剩余可发送数据的长度上限，因此，EffectiveWindow = AdvertisedWindow - (LastByteSent - LastByteAcked)。

当然，EffectiveWindow最小取0。

示例1

以下是一个发送缓冲区的滑动窗口：

上图分为4个部分：

• #1是已发送已确认的数据，即LastByteAcked之前的区域。
• #2是已发送未确认的数据，即LastByteAcked与LastByteSent之间的区域，大小不超过AdvertisedWindow。
• #3是窗口内未发送的数据，即LastByteSent与窗口右界之间的区域，大小等于EffectiveWindow（可能为0）。
• #4是窗口外未发送的数据，即窗口右界与LastByteWritten之间的区域。

其中，#2 + #3组成了滑动窗口，总大小不超过AdvertisedWindow，二者比例受到接收方的处理速度与网络情况的影响（如果丢包严重或处理速度慢于发送速度，则#2:#3会越来越大）。

示例2

以下是一个AdvertisedWindow的调整过程，EffectiveWindow随之变化：

Zero Window

理解有问题，不要求掌握。

上图，我们可以看到一个处理缓慢的Server（接收端）是怎么把Client（发送端）的发送窗口size给降成0的。对于接收方来说，此时接收缓冲区确实已经满了，因此令发送方的发送窗口size降为0以暂时禁止发送是合理的。那么，等接收方的接收缓冲区再空出来，怎么通知发送方新的window size呢？

针对这个问题，为TCP设计了ZWP技术（Zero Window Probe，零窗通告）：发送方在窗口变成0后，会发ZWP的包给接收方，让接收方来Ack他的Window尺寸；ZWP的重传也遵循指数回退策略，默认重试3次；如果3次后window size还是0，则认为接收方出现异常，发RST重置连接（部分文章写的是重试到window size正常？？？）。

注意：只要有等待的地方都可能出现DDoS攻击，Zero Window也不例外。一些攻击者会在和服务端建好连接发完GET请求后，就把Window设置为0，于是服务端就只能等待进行ZWP；然后攻击者再大量并发发送ZWP，把服务器端的资源耗尽。（客户端等待怎么耗服务端？？？）

TCP的拥塞控制

通信中的拥塞指：

到达通信子网中某一部分的分组数量过多，使得该部分网络来不及处理，以致引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信业务陷入停顿即出现死锁。

为什么要进行拥塞控制？假设网络已经出现拥塞，如果不处理拥塞，那么延时增加，出现更多丢包，触发发送方重传数据，加剧拥塞情况，继续恶性循环直至网络瘫痪。可知，拥塞控制与流量控制的适应场景和目的均不同。

拥塞发生前，可避免流量过快增长拖垮网络；拥塞发生时，唯一的选择就是降低流量。主要使用4种算法完成拥塞控制：

1. 慢启动
2. 拥塞避免
3. 拥塞发生
4. 快速恢复

算法1、2适用于拥塞发生前，算法3适用于拥塞发生时，算法4适用于拥塞解决后（相当于拥塞发生前）。

rwnd与cwnd

在正式介绍上述算法之前，先补充下rwnd（Receiver Window，接收者窗口）与cwnd（Congestion Window，拥塞窗口）的概念：

• rwnd是用于流量控制的窗口大小，即上述流量控制中的AdvertisedWindow，主要取决于接收方的处理速度，由接收方通知发送方被动调整（详细逻辑见上）。
• cwnd是用于拥塞处理的窗口大小，取决于网络状况，由发送方探查网络主动调整。

介绍流量控制时，我们没有考虑cwnd，认为发送方的滑动窗口最大即为rwnd。实际上，需要同时考虑流量控制与拥塞处理，则发送方窗口的大小不超过min{rwnd, cwnd}。下述4种拥塞控制算法只涉及对cwnd的调整，同介绍流量控制时一样，暂且不考虑rwnd，假定滑动窗口最大为cwnd；但读者应明确rwnd、cwnd与发送方窗口大小的关系。

4种拥塞控制算法

慢启动算法

慢启动算法（Slow Start）作用在拥塞产生之前：对于刚刚加入网络的连接，要一点一点的提速，不要妄图一步到位。如下：

1. 连接刚建好，初始化cwnd = 1（当然，通常不会初始化为1，太小），表明可以传一个MSS大小的数据。
2. 每收到一个ACK，cwnd++，线性增长。
3. 每经过一个RTT，cwnd = cwnd * 2，指数增长（主要增长来源）。
4. 还有一个ssthresh（slow start threshold），当cwnd >= ssthresh时，就会进入拥塞避免算法（见后）。

因此，如果网速很快的话，Ack返回快，RTT短，那么，这个慢启动就一点也不慢。下图说明了这个过程：

拥塞避免算法

前面说过，当cwnd >= ssthresh（通常ssthresh = 65535）时，就会进入拥塞避免算法（Congestion Avoidance）：缓慢增长，小心翼翼的找到最优值。如下：

1. 每收到一个Ack，cwnd = cwnd + 1/cwnd，显然，cwnd > 1时无增长。
2. 每经过一个RTT，cwnd++，线性增长（主要增长来源）。

慢启动算法主要呈指数增长，粗犷型，速度快（“慢”是相对于一步到位而言的）；而拥塞避免算法主要呈线性增长，精细型，速度慢，但更容易在不导致拥塞的情况下，找到网络环境的cwnd最优值。

拥塞发生时的算法

慢启动与拥塞避免算法作用在拥塞发生前，采取不同的策略增大cwnd；如果已经发生拥塞，则需要采取策略减小cwnd。那么，TCP如何判断当前网络拥塞了呢？很简单，如果发送方发现有Seq发送失败（表现为“丢包”），就认为网络拥塞了。

丢包后，有两种重传方式，对应不同的网络情况，也就对应着两种拥塞发生时的控制算法：

1. 超时重传。TCP认为这种情况太糟糕，调整力度比较大：
   1. ssthresh = cwnd /2
   2. cwnd = 1，重新进入慢启动过程（网络糟糕，要慢慢调整）
2. 快速重传。TCP认为这种情况通常比RTO超时好一些，主流实现TCP Reno的调整力度更柔和（TCP Tahoe的实现和RTO超时一样暴躁）：
   1. ssthresh = cwnd /2
   2. cwnd = cwnd /2，进入快速恢复算法（网络没那么糟，可以快速调整，见下）

可以看到，不管是哪种重传方式，ssthresh都会变成cwnd的一半，仍然是指数回退，待拥塞消失后再逐渐增长回到新的最优值，总体上在最优值（动态）附近震荡。

回退后，根据不同的网络情况，可以选择不同的恢复算法。慢启动已经介绍过了，下面介绍快速恢复算法。

快速恢复算法

如果触发了快速重传，即发送方收到至少3次相同的Ack，那么TCP认为网络情况不那么糟，也就没必要提心吊胆的，可以适当大胆的恢复。为此设计快速恢复算法（Fast Recovery），下面介绍TCP Reno中的实现。

回顾一下，进入快速恢复之前，cwnd和sshthresh已被更新：

1. ssthresh = cwnd /2
2. cwnd = cwnd /2

然后，进入快速恢复算法：

1. cwnd = ssthresh + 3 * MSS （尝试一步到位）
2. 重传重复Ack对应的Seq
3. 如果再收到该重复Ack，则cwnd++，线性增长（缓慢调整）
4. 如果收到了新Ack，则cwnd = ssthresh ，然后就进入了拥塞避免的算法了（为什么收到新Ack要降低sshthresh？？？）

可暂时忽略的内容：

这种实现也有问题：依赖于3个重复Ack。回忆上文讨论的“重传一个还是重传所有的问题”，3个重复Ack并不代表只丢了一个数据包，很有可能是丢了好多包。显然快速恢复算法选择“重传一个”，而剩下的那些包只能等到RTO超时。于是，超时一个窗口就减半一下，多个超时会超成TCP的传输速度指数级下降；同时，超时重传不会触发快速恢复算法，慢启动很容易加剧超时的情况，进入恶性循环。

示例

下面看一个简单的图示，感受拥塞控制过程中的cwnd变化：

一个有趣的面试题

问：

使用wget的时候，通常刚开始速度慢一些，然后逐渐上升到满速。可能是什么原因导致？

猴子面试时遇到这个问题，懵逼了几秒钟，想到一个CDN pre load的原因，面试官看我懵逼就提醒“可能跟tcp协议有关”，瞬间明白考点：

• wget使用HTTP协议构建，传输层使用TCP协议，而TCP的拥塞控制会从慢启动开始，逐渐试探，增长到一个足够大，又不至导致拥塞的速度。

接下来，还可以补充CDN的原因，但不是主要原因了：

• 很多下载服务都使用了CDN，CDN属于缓存，一定也存在一些pre load策略，显然运行一段时间，缓存命中率才能上升到最高。

参考：

• TCP 的那些事儿（下）
• 网络基础3-传输层

本文介绍TCP的状态机与重传机制，下文讲解流量控制与拥塞控制。

本文大部分内容基于TCP 的那些事儿（上）修改而来，部分观点与原文不同，重要地方增加了解释。

前置知识

一些网络基础

TCP在网络OSI的七层模型中的第四层——Transport层，IP在第三层——Network层，ARP在第二层——Data Link层，在第二层上的数据，我们叫Frame，在第三层上的数据叫Packet，第四层的数据叫Segment。

应用层的数据首先会打到TCP的Segment中，然后TCP的Segment会打到IP的Packet中，然后再打到以太网Ethernet的Frame中，传到对端后，各个层解析自己的协议，然后把数据交给更高层的协议处理。

TCP头格式

在正式讨论之前，先来看一下TCP头的格式：

注意：

• TCP的包是没有IP地址的，那是IP层上的事。但是有源端口和目标端口。
• 一个TCP连接需要四个元组来表示是同一个连接（src_ip, src_port, dst_ip, dst_port）（准确说是五元组，还有一个是协议，但因为这里只是说TCP协议，所以，这里我只说四元组）。
• 注意上图中的四个非常重要的东西：
  • Sequence Number，包的序号Seq，用于解决网络包乱序（reordering）。
  • Acknowledgement Number，Ack用于确认收到Seq（Ack = Seq + 1，表示收到了Seq及Seq之前的数据包，期待Seq + 1），用于解决丢包。
  • Window，又叫Advertised Window，可以近似理解为滑动窗口（Sliding Window）的大小，用于流控。
  • TCP Flag ，区分包的类型，如SYN包、FIN包、RST包等，主要用于操控TCP状态机。

其他字段参考下图：

TCP的状态机

其实，网络传输是没有连接的——TCP所谓的“连接”，其实只不过是在通讯的双方维护一个“连接状态”，让它看上去好像有连接一样。所以，TCP的状态转换非常重要。

下面是简化的“TCP协议状态机” 和 “TCP三次握手建连接 + 传数据 + 四次挥手断连接” 的对照图，两张图本质上都描述了TCP协议状态机，但场景略有不同。这两个图非常重要，一定要记牢。

TCP协议状态机，不区分client、server：

下图是经典的“TCP三次握手建连接 + 传数据 + 四次挥手断连接”，client发起握手，向server传输数据（server不向client传），最后发起挥手：

三次握手与四次挥手

很多人会问，为什么建连接要三次握手，断连接需要四次挥手？

三次握手建连接

主要是要初始化Sequence Number 的初始值。双方需要发送自己的ISN（初始化序列号，Inital Sequence Number）给对方，并收到对方的回复——最简单的方式也是两个一来一回，四次握手，但此处进行了优化，将server端回复的ACK同server端自己的SYN合并在一个报文中发送给client，所以减少为三次。

通信的双方要同步对方ISN——所以叫SYN（全称Synchronize Sequence Numbers）。也就是上图中的 x 和 y。这个号在以后的数据通信中，在client端按发送顺序递增，在server端按递增顺序重新组织，以保证应用层接收到的数据不会因为网络问题乱序。

四次挥手断连接

参照三次握手的过程，其实是双方各自关闭资源进行2次挥手。握手的目的是同步双方的ISN，不是耗时操作，因此可以“将server端回复的ACK同server端自己的SYN合并在一个报文中发送给client”；但挥手要回收大量资源，是耗时操作，因此，不能强制“将server端回复的ACK同server端自己的FIN合并在一个报文中发送给client”，所以通常认为挥手需要四次。

对于挥手，因为TCP是全双工的，client与server都占用各自的资源发送segment（同一通道，同时双向传输seq和ack），所以，双方都需要关闭自己的资源（向对方发送FIN）并确认对方资源已关闭（回复对方Ack）；而双方可以同时主动关闭，也可以由一方主动关闭带动另一方被动关闭。只不过，通常以一方主动另一方被动举例（如图，client主动server被动），所以看上去是所谓的4次挥手。

如果两边同时主动断连接，那么双方都会进入CLOSING状态，然后到达TIME_WAIT状态，最后超时转到CLOSED状态。下图是双方同时主动断连接的示意图（对应TCP状态机中的Simultaneous Close分支）：

握手过程中的其他问题

建连接时SYN超时

server收到client发的SYN并回复Ack(SYN)（此处称为Ack1）后，如果client掉线了（或网络超时），那么server将无法收到client回复的Ack(Ack(SYN))（此处称为Ack2），连接处于一个中间状态（非成功非失败）。

为了解决中间状态的问题，server如果在一定时间内没有收到Ack2，会重发Ack1（不同于数据传输过程中的重传机制）。Linux下，默认重试5次，加上第一次最多共发送6次；重试间隔从1s开始翻倍增长（一种指数回退策略，Exponential Backoff），5次的重试时间分别为1s, 2s, 4s, 8s, 16s，第5次发出后还要等待32s才能判断第5次也超时。所以，至多共发送6次，经过1s + 2s + 4s+ 8s+ 16s + 32s = 2^6 -1 = 63s，TCP才会认为SYN超时断开这个连接。

SYN Flood攻击

可以利用建连接时的SYN超时机制发起SYN Flood攻击——给server发一个SYN就立即下线，于是服务器默认需要占用资源63s才会断开连接。发SYN的速度是很快的，这样，攻击者很容易将server的SYN队列资源耗尽，使server无法处理正常的新连接。

针对该问题，Linux提供了一个tcp_syncookies参数解决这个问题——当SYN队列满了后，TCP会通过源地址端口、目标地址端口和时间戳构造一个特别的Sequence Number发回去，称为SYN Cookie，如果是攻击者则不会有响应，如果是正常连接，则会把这个SYN Cookie发回来，然后server端可以通过SYN Cookie建连接（即使你不在SYN队列中）。至于SYN队列中的连接，则不做处理直至超时关闭。请注意，不要用tcp_syncookies参数来处理正常的大负载连接情况，因为SYN Cookie本质上也破坏了建连接的SYN超时机制，是妥协版的TCP协议。

对于正常的连接请求，有另外三个参数可供选择：

• tcp_synack_retries参数设置SYN超时重试次数
• tcp_max_syn_backlog参数设置最大SYN连接数（SYN队列容量）
• tcp_abort_on_overflow参数使SYN请求处理不过来的时候拒绝连接

ISN的同步

• 首先，不能选择静态的ISN。例如，如果连接建好后始终用1来做ISN，如果client发了30个segment（假设一个字节一个segment）过去，但是网络断了，于是 client重连，又用了1做ISN，但是旧连接的那些segment（称为“迷途的重复分组”）到了，由于区分连接的五元组相同（称该新连接为旧连接的“化身”），server会把它们当做新连接中的segment。
• 然后，从上例还能够得知，需要使ISN随时钟动态增长，以保证新连接的ISN大于旧连接。
• 最后，从安全等角度考虑，也不能使ISN的增长呈现规律性（如简单随时钟正比例增长）。这很容易理解，如果增长规律过于简单，则很容伪造ISN对网络两端发起攻击。

最终，设计了多种ISN增长算法，普遍使ISN随时钟动态增长，并具有一定的随机性。RFC793中描述了一种简单的ISN增长算法：ISN会和一个假的时钟绑在一起，这个时钟会在每4微秒对ISN做加一操作，直到超过2^32，又从0开始。这样，一个ISN的周期大约是4.55（我算的4.77？？?）个小时。定义segment在网络上的最大存活时间为MSL（Maximum Segment Lifetime），网络中存活时间超过MSL的分组将被丢弃。因此，如果使用RFC793中的ISN增长算法，则MSL的值必须小于4.55小时，以保证不会在相邻的连接中重用ISN（TIME_WAIT也有该作用）。同时，这间接限制了网络的大小（当然，4.55小时的MSL已经能构造非常大的网络了）。

MSL应大于IP协议TTL换算的时间，RFC793建议MSL设置为2分钟，Linux遵循伯克利习惯设置为30s。

挥手过程中的其他问题

关于TIME_WAIT

为什么需要TIME_WAIT

在TCP状态机中，从TIME_WAIT状态到CLOSED状态，有一个超时时间 2 MSL。为什么需要TIME_WAIT状态，且超时时间为2 MSL？主要有两个原因：

• 2 * MSL确保有足够的时间让被动方收到了ACK或主动方收到了被动发超时重传的FIN。即，如果被动方没有收到Ack，就会触发被动方重传FIN，发送Ack+接收FIN正好2个MSL，TIME_WAIT状态的连接收到重传的FIN后，重传Ack，再等待2 * MSL时间。
• 确保有足够的时间让“迷途的重复分组”过期丢弃。这只需要1 * MSL即可，超过MSL的分组将被丢弃，否则很容易同新连接的数据混在一起（仅仅依靠ISN是不行的）。

大规模出现TIME_WAIT

一个常见问题是大规模出现TIME_WAIT，通常是在高并发短连接的场景中，会消耗很多资源。

网上大部分文章都是教你打开两个参数，tcp_tw_reuse或tcp_tw_recycle。这两个参数默认都是关闭的，tcp_tw_recycle比tcp_tw_reuse更为激进；要想使用二者，还需要打开tcp_timestamps（默认打开），否则无效。不过，打开这两个参数可能会让TCP连接出现诡异的问题：如上所述，如果不等待超时就重用连接的话，新旧连接的数据可能会混在一起，比如新连接握手期间收到了旧连接的FIN，则新连接会被重置。因此，使用这两个参数时应格外小心。

各参数详细如下：

• tcp_tw_reuse：官方文档上说tcp_tw_reuse加上tcp_timestamps可以保证客户端（仅客户端）在协议角度的安全，但是需要在两端都打开tcp_timestamps。
• tcp_tw_recycle：如果是tcp_tw_recycle被打开了话，会假设对端开启了tcp_timestamps，然后会去比较时间戳，如果时间戳变大了，就可以重用连接（NAT网络有可能建连接失败，出现”connection time out”的错误）。

补充一个参数：

• tcp_max_tw_buckets：控制并发的TIME_WAIT的数量（默认180000），如果超限，系统会把多余的TIME_WAIT连接destory掉，然后在日志里打一个警告（如“time wait bucket table overflow”）。官网文档说这个参数是用来对抗DDoS攻击的，需要根据实际情况考虑。

关于TIME_WAIT的建议

总之，TIME_WAIT出现在主动发起挥手的一方，即，谁发起挥手谁就要牺牲资源维护那些等待从TIME_WAIT转换到CLOSED状态的连接。TIME_WAIT的存在是必要的，因此，与其通过上述参数破协议来逃避TIME_WAIT，不如好好优化业务（如改用长连接等），针对不同业务优化TIME_WAIT问题。

对于HTTP服务器，可以设置HTTP的KeepAlive参数，在应用层重用TCP连接来处理多个HTTP请求（需要浏览器配合），让client端（即浏览器）发起挥手，这样TIME_WAIT只会出现在client端。

示例

下图是我从Wireshark中截了个我在访问coolshell.cn时的有数据传输的图，可以参照理解Seq与Ack是怎么变的（使用Wireshark菜单中的Statistics ->Flow Graph… ）：

可以看到，Seq与Ack的增加和传输的字节数相关。上图中，三次握手后，来了两个Len:1440的包，因此第一个包为Seq(1)，第二个包为Seq(1441)。然后收到第一个Ack(1441)，表示1~1440的数据已经收到了，期待Seq(1441)。另外，可以看到一个包可以同时充当Ack与Seq，在一次传输中携带数据与响应。

如果你用Wireshark抓包程序看3次握手，你会发现ISN总是为0。不是这样的，Wireshark为了显示更友好，使用了Relative Seq——相对序号。你只要在右键菜单中的protocol preference中取消掉就可以看到“Absolute Seq”了。

TCP重传机制

TCP协议通过重传机制保证所有的segment都可以到达对端，通过滑动窗口允许一定程度的乱序和丢包（滑动窗口还具有流量控制等作用，暂不讨论）。注意，此处重传机制特指数据传输阶段，握手、挥手阶段的传输机制与此不同。

TCP是面向字节流的，Seq与Ack的增长均以字节为单位。在最朴素的实现中，为了减少网络传输，接收端只回复最后一个连续包的Ack，并相应移动窗口。比如，发送端发送1,2,3,4,5一共五份数据（假设一份数据一个字节），接收端快速收到了Seq 1, Seq 2，于是回Ack 3，并移动窗口；然后收到了Seq 4，由于在此之前未收到过Seq 3（乱序），如果仍在窗口内，则只填充窗口，但不发送Ack 5，否则丢弃Seq 3（与丢包的效果相似）；假设在窗口内，则等以后收到Seq 3时，发现Seq 4及以前的数据包都收到了，则回Ack 5，并移动窗口。

超时重传机制

当发送方发现等待Seq 3的Ack（即Ack 4）超时后，会认为Seq 3发送“失败”，重传Seq 3。一旦接收方收到Seq 3，会立即回Ack 4。

发送方无法区分是Seq 3丢包、接收方故障、还是Ack 4丢包，本文统一表述为Seq发送“失败”。

这种方式有些问题：假设目前已收到了Seq 4；由于未收到Seq 3，导致发送方重传Seq 3，在收到重传的Seq 3之前，包括新收到的Seq 5和刚才收到的Seq 4都不能回复Ack，很容易引发发送方重传Seq 4、Seq5。接收方之前已经将Seq 4、Seq 5保存到窗口中，此时重传Seq 4、Seq 5明显造成浪费。

也就是说，超时重传机制面临“重传一个还是重传所有”的问题，即：

• 重传一个：仅重传timeout的包（即Seq 3），后续包等超时后再重传。节省资源，但效率略低。
• 重传所有：每次都重传timeout包及之后所有的数据（即Seq 3、4、5）。效率更高（如果带宽未打满），但浪费资源。

可知，两种方法都属于超时重传机制，各有利弊，但二者都需要等待timeout，是基于时间驱动的，性能与timeout的长度密切相关。如果timeout很长（普遍情况），则两种方法的性能都会受到较大影响。

快速重传机制

最理想的方案是：在超时之前，通过某种机制要求发送方尽快重传timeout的包（即Seq 3），如快速重传机制（Fast Retransmit）。这种方案浪费资源（浪费多少取决于“重传一个还是重传所有”，见下），但效率非常高（因为不需要等待timeout了）。

快速重传机制不基于时间驱动，而基于数据驱动：如果包没有连续到达，就Ack最后那个可能被丢了的包；如果发送方连续收到3次相同的Ack，就重传对应的Seq。

比如：假设发送方仍然发送1,2,3,4,5共5份数据；接收方先收到Seq 1，回Ack 2；然后Seq 2因网络原因丢失了，正常收到Seq 3，继续回Ack 2；后面Seq 4和Seq 5都到了，最后一个可能被丢了的包还是Seq 2，继续回Ack 2；现在，发送方已经连续收到4次（大于等于3次）相同的Ack（即Ack 2），知道最大序号的未收到包是Seq 2，于是重传Seq 2，并清空Ack 2的计数器；最后，接收方收到了Seq 2，查看窗口发现Seq 3、4、5都收到了，回Ack 6。示意图如下：

快速重传解决了timeout的问题，但依然面临“重传一个还是重传所有”的问题。对于上面的示例来说，是只重传Seq 2呢还是重传Seq 2、3、4、5呢？

如果只使用快速重传，则必须重传所有：因为发送方并不清楚上述连续的4次Ack 2是因为哪些Seq传回来的。假设发送方发出了Seq 1到Seq 20供20份数据，只有Seq 1、6、10、20到达了接收方，触发重传Ack 2；然后发送方重传Seq 2，接收方收到，回复Ack 3；接下来，发送方与接收方都不会再发送任何数据，两端陷入等待。因此，发送方只能选择“重传所有”，这也是某些TCP协议的实际实现，对于带宽未满时重传效率的提升非常明显。

一个更完美的设计是：将超时重传与快速重传结合起来，触发快速重传时，只重传局部的一小段Seq（局部性原理，甚至只重传一个Seq），其他Seq超时后重传。

参考：

• TCP 的那些事儿（上）
• 大量TIME_WAIT解决办法

• 为什么MySQL等主流数据库选择B+树的索引结构？
• 如何基于索引结构，理解常见的MySQL索引优化思路？

为什么索引无法全部装入内存

索引结构的选择基于这样一个性质：大数据量时，索引无法全部装入内存。

为什么索引无法全部装入内存？假设使用树结构组织索引，简单估算一下：

• 假设单个索引节点12B，1000w个数据行，unique索引，则叶子节点共占约100MB，整棵树最多200MB。
• 假设一行数据占用200B，则数据共占约2G。

假设索引存储在内存中。也就是说，每在物理盘上保存2G的数据，就要占用200MB的内存，索引:数据的占用比约为1/10。1/10的占用比算不算大呢？物理盘比内存廉价的多，以一台内存16G硬盘1T的服务器为例，如果要存满1T的硬盘，至少需要100G的内存，远大于16G。

考虑到一个表上可能有多个索引、联合索引、数据行占用更小等情况，实际的占用比通常大于1/10，某些时候能达到1/3。在基于索引的存储架构中，索引:数据的占用比过高，因此，索引无法全部装入内存。

其他结构的问题

由于无法装入内存，则必然依赖磁盘（或SSD）存储。而内存的读写速度是磁盘的成千上万倍（与具体实现有关），因此，核心问题是“如何减少磁盘读写次数”。

首先不考虑页表机制，假设每次读、写都直接穿透到磁盘，那么：

• 线性结构：读/写平均O(n)次
• 二叉搜索树（BST）：读/写平均O(log2(n))次；如果树不平衡，则最差读/写O(n)次
• 自平衡二叉搜索树（AVL）：在BST的基础上加入了自平衡算法，读/写最大O(log2(n))次
• 红黑树（RBT）：另一种自平衡的查找树，读/写最大O(log2(n))次

BST、AVL、RBT很好的将读写次数从O(n)优化到O(log2(n))；其中，AVL和RBT都比BST多了自平衡的功能，将读写次数降到最大O(log2(n))。

假设使用自增主键，则主键本身是有序的，树结构的读写次数能够优化到树高，树高越低读写次数越少；自平衡保证了树结构的稳定。如果想进一步优化，可以引入B树和B+树。

B树解决了什么问题

很多文章将B树误称为B-（减）树，这可能是对其英文名“B-Tree”的误解（更有甚者，将B树称为二叉树或二叉搜索树）。特别是与B+树一起讲的时候。想当然的认为有B+（加）树就有B-（减）树，实际上B+树的英文名是“B+-Tree”。

如果抛开维护操作，那么B树就像一棵“m叉搜索树”（m是子树的最大个数），时间复杂度为O(logm(n))。然而，B树设计了一种高效简单的维护操作，使B树的深度维持在约log(ceil(m/2))(n)~logm(n)之间，大大降低树高。

再次强调：

不要纠结于时间复杂度，与单纯的算法不同，磁盘IO次数才是更大的影响因素。读者可以推导看看，B树与AVL的时间复杂度是相同的，但由于B树的层数少，磁盘IO次数少，实践中B树的性能要优于AVL等二叉树。

同二叉搜索树类似，每个节点存储了多个key和子树，子树与key按顺序排列。

页表的目的是扩展内存+加速磁盘读写。一个页（Page）通常4K（等于磁盘数据块block的大小，见inode与block的分析），从磁盘读写的角度出发，操作系统每次以页为单位将内容从磁盘加载到内存（以摊分寻道成本），修改页后，再择期将该页写回磁盘。考虑到页表的良好性质，可以使每个节点的大小约等于一个页（使m非常大），这每次加载的一个页就能完整覆盖一个节点，以便选择下一层子树；对子树同理。对于页表来说，AVL（或RBT）相当于1个key+2个子树的B树，由于逻辑上相邻的节点，物理上通常不相邻，因此，读入一个4k页，页面内绝大部分空间都将是无效数据。

假设key、子树节点指针均占用4B，则B树节点最大m * (4 + 4) = 8m B；页面大小4KB。则m = 4 * 1024 / 8 = 512，一个512叉的B树，1000w的数据，深度最大 log(512/2)(10^7) = 3.02 ~= 4。对比二叉树如AVL的深度为log(2)(10^7) = 23.25 ~= 24，相差了5倍以上。震惊！B树索引深度竟然如此！

另外，B树对局部性原理非常友好。如果key比较小（比如上面4B的自增key），则除了页表的加成，缓存还能进一步预读加速。美滋滋~

B+树解决了什么问题

B树的剩余问题

然而，如果要实际应用到数据库的索引中，B树还有一些问题：

1. 未定位数据行
2. 无法处理范围查询

问题1

数据表的记录有多个字段，仅仅定位到主键是不够的，还需要定位到数据行。有3个方案解决：

1. 直接将key对应的数据行（可能对应多行）存储在节点中。
2. 数据行单独存储；节点中增加一个字段，定位key对应数据行的位置。
3. 修改key与子树的判断逻辑，使子树大于等于上一key小于下一key，最终所有访问都将落于叶子节点；叶子节点中直接存储数据行或数据行的位置。

方案1中，数据行通常非常大，存储数据行将减少页面中的子树个数，m减小树高增大。假设数据行占用200B，可忽略组织B树的指针，则新的m = 4 * 1024 / 200 = 20.48 ~= 21，深度最大 log(21/2)(10^7) ~= 7。增加了一倍以上的IO，不考虑。

方案2中，节点增加了一个字段。假设是4B的指针，则新的m = 4 * 1024 / 12 = 341.33 ~= 341，深度最大 log(341/2)(10^7) = 3.14 ~= 4。与3差别不大，可以考虑。

方案3的节点m与深度不变，但时间复杂度变为稳定的O(logm(n))。考虑。

问题2

实际业务中，范围查询的频率非常高，B树只能定位到一个索引位置（可能对应多行），很难处理范围查询。给出2种方案：

1. 不改动：查询的时候先查到左界，再查到右界，然后DFS（或BFS）遍历左界、右界之间的节点。
2. 在“问题1-方案3”的基础上，由于所有数据行都存储在叶子节点，B树的叶子节点本身也是有序的，可以增加一个指针，指向当前叶子节点按主键顺序的下一叶子节点；查询时先查到左界，再查到右界，然后从左界到有界线性遍历。

乍一看感觉方案1比方案2好——时间复杂度和常数项都一样，方案1还不需要改动。但是别忘了局部性原理，不管节点中存储的是数据行还是数据行位置，方案2的好处在于，叶子节点连续存储，对页表和缓存友好。而方案1则面临节点逻辑相邻、物理分离的缺点。

引出B+树

综上，问题1的方案2与问题2的方案1可整合为一种方案（基于B树的索引），问题1的方案3与问题2的方案2可整合为一种（基于B+树的索引）。实际上，数据库、文件系统有些采用了B树，有些采用B+树。

由于某些猴子暂未明白的原因，包括MySQL在内的主流数据库多选择了B+树。即：

主要变动如上所述：

• 修改key与子树的组织逻辑，将索引访问都落到叶子节点
• 按顺序将叶子节点串起来（方便范围查询）

B树和B+树的增、删、查过程

B树的增删过程暂时可参考从B树、B+树、B*树谈到R 树的“6、B树的插入、删除操作”小节，B+树的增删同理。此处暂不赘述。

Mysql索引优化

根据B+树的性质，很容易理解各种常见的MySQL索引优化思路。

暂不考虑不同引擎之间的区别。

优先使用自增key作为主键

前面的分析中，假设用4B的自增key作为索引，则m可达到512，层高仅有3。使用自增的key有两个好处：

1. 自增key一般为int等整数型，key比较紧凑，这样m可以非常大，而且索引占用空间小。最极端的例子，如果使用50B的varchar（包括长度），那么m = 4 * 1024 / 54m = 75.85 ~= 76，深度最大 log(76/2)(10^7) = 4.43 ~= 5，再加上cache缺失、字符串比较的成本，时间成本增加较大。同时，key由4B增长到50B，整棵索引树的空间占用增长也是极为恐怖的（如果二级索引使用主键定位数据行，则空间增长更加严重）。
2. 自增的性质使得新数据行的插入请求必然落到索引树的最右侧，发生节点分裂的频率较低，理想情况下，索引树可以达到“满”的状态。索引树满，一方面层高更低，一方面删除节点时发生节点合并的频率也较低。

优化经历：

猴子曾使用varchar(100)的列做过主键，存储containerId，过了3、4天100G的数据库就满了，DBA小姐姐邮件里委婉表示了对我的鄙视。。。之后增加了自增列作为主键，containerId作为unique的二级索引，时间、空间优化效果相当显著。

最左前缀匹配

索引可以简单如一个列(a)，也可以复杂如多个列(a, b, c, d)，即联合索引。如果是联合索引，那么key也由多个列组成，同时，索引只能用于查找key是否存在（相等），遇到范围查询(>、<、between、like左匹配)等就不能进一步匹配了，后续退化为线性查找。因此，列的排列顺序决定了可命中索引的列数。

如有索引(a, b, c, d)，查询条件a = 1 and b = 2 and c > 3 and d = 4，则会在每个节点依次命中a、b、c，无法命中d。也就是最左前缀匹配原则。

=、in自动优化顺序

不需要考虑=、in等的顺序，mysql会自动优化这些条件的顺序，以匹配尽可能多的索引列。

如有索引(a, b, c, d)，查询条件c > 3 and b = 2 and a = 1 and d < 4与a = 1 and c > 3 and b = 2 and d < 4等顺序都是可以的，MySQL会自动优化为a = 1 and b = 2 and c > 3 and d < 4，依次命中a、b、c。

索引列不能参与计算

有索引列参与计算的查询条件对索引不友好（甚至无法使用索引），如from_unixtime(create_time) = '2014-05-29'。

原因很简单，如何在节点中查找到对应key？如果线性扫描，则每次都需要重新计算，成本太高；如果二分查找，则需要针对from_unixtime方法确定大小关系。

因此，索引列不能参与计算。上述from_unixtime(create_time) = '2014-05-29'语句应该写成create_time = unix_timestamp('2014-05-29')。

能扩展就不要新建索引

如果已有索引(a)，想建立索引(a, b)，尽量选择修改索引(a)为索引(a, b)。

新建索引的成本很容易理解。而基于索引(a)修改为索引(a, b)的话，MySQL可以直接在索引a的B+树上，经过分裂、合并等修改为索引(a, b)。

不需要建立前缀有包含关系的索引

如果已有索引(a, b)，则不需要再建立索引(a)，但是如果有必要，则仍然需考虑建立索引(b)。

选择区分度高的列作索引

很容易理解。如，用性别作索引，那么索引仅能将1000w行数据划分为两部分（如500w男，500w女），索引几乎无效。

区分度的公式是count(distinct <col>) / count(*)，表示字段不重复的比例，比例越大区分度越好。唯一键的区分度是1，而一些状态、性别字段可能在大数据面前的区分度趋近于0。

这个值很难确定，一般需要join的字段要求是0.1以上，即平均1条扫描10条记录。

参考：

• 从B树、B+树、B*树谈到R 树
• MySQL索引原理及慢查询优化

本文随时更新。除勘误外，不另做批注。

概览

• 圆型节点代指目录，方型节点代指文件。
• 图中省去了很多不常用的目录与文件。
• 稍后单独讲/proc目录与/var目录。

Linux将整个文件系统看做一棵树，这棵树的树根叫做根文件系统，用”/“表示。

/usr目录的目录结构与根目录相似，但根目录中的文件多是系统级的文件，而/usr目录中是用户级的文件，一般与具体的系统无关。

重中之重

/proc目录

/proc目录挂载了一个虚拟文件系统，以虚拟文件的形式映射系统与进程在内存中的运行时信息。

系统信息

/proc下的直接子目录通常存储系统信息。猴子常用的只有两个：

/proc/version确定内核版本号和CPU架构（如i686）；/etc/centos-release确定发行版本号（其他发行版类似）。

uname -a与cat /proc/version的作用类似。

进程信息

重点是/proc/<pid>目录映射的进程信息。以rsyslogd进程为例：

补充几点：

• 通过ulimit来查看或修改当前进程的资源限制。
• 软限制可以由进程自己在任何时间修改；硬限制只能使用root权限修改。
• Linux上进程与线程的关系参考浅谈linux线程模型和线程切换。

/var目录

/var目录存放数据文件，如程序数据、日志等；但线上通常只将日志放在/var目录。

系统日志/var/log/messages

通过rsyslog记录系统级日志，配置文件为/etc/rsyslog.conf。重点看/var/log/messages的配置：

1
2
3

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

*.info表示所有服务大于等于info优先级的信息都会记录到/var/log/messages中；
mail.none表示不记录任何mail的信息到/var/log/messages中。

以上配置表示：除安全认证、邮件、定时任务外，输出到stdout、stderr的info及更高级别的日志记录在/var/log/messages中。

OOM kill

猴子利用/var/log/messages定位过一次OOM kill问题。

一个用户经常抱怨自己的app提到Yarn后，container各种exit 137然后重试。假设框架不会自己exit 137玩，那么通常137代表container是因为kill -9退出，于是mentor提示猴子可能因为OOM kill。要验证这个想法，必须找到“相关container被OOM kill的痕迹”。

Linux会监控内存使用情况，当内存不足的时候，OOM killer计算进程的优先级，杀死优先级最高的进程释放内存。而Yarn集群普遍会配置资源超发（Linux系统本身也存在内存超发），当集群资源紧张的时候，大container很容易被OOM kill。

OOM kill的三个步骤“发现内存不足”、“计算优先级”、“选择进程kill”，都会记录在/var/log/messages中，猴子确实在用户给定的时间点附近找到了对应container的OOM kill日志，内存也与container申请的资源相近。

得证。

判断过程中存在一些小问题：

• 猴子根据container被OOM kill的时间点和内存判断是否是目标进程，未严格确定。

个人使用时的建议

对于本文的理解，读者不必关心不同发行版本、内核版本之间的区别。

对，是存在区别的。如：CentOS 6.5可验证得本文即将讲解的目录结构；但CentOS 7.2中，/bin等所谓“系统级目录”都被软链到了/usr/bin等所谓“用户级目录”。其他发行版如Debian可能差别更大。

如果非要追究的话，一般建议将所有用户共享的软件安装到/usr/local目录（结构与/usr目录相似）下，将用户私有的软件安装到用户自己的家目录。

参考：

• Linux根目录下各子目录的作用
• 深入理解linux系统下proc文件系统内容