1. 起因

线上有个Flink ETL任务突发Kafka消费延迟告警，之前压测时150并行度就可以满足需求，线上并行度设置为200，但任务延迟还是不断增加。

查看Kafka监控发现有流量突增，与运维同事沟通后确认是由于有一台Broker节点宕机导致，于是修改任务并行度至400加速消费数据，但消费延迟还是没有下降，吞吐只比200并行度时提高了20%且波动很大。

2. 算子性能瓶颈？ GC问题？

此时开始怀疑是任务本身出现了性能瓶颈，查看Flink Dashboard发现部分节点的消费数量非常低，初步怀疑是算子内部计算逻辑的RPC调用耗时增加导致的，经过Arthas线上统计发现：正常节点的耗时在0.6ms左右，而这部分节点的耗时在1.2～20ms之间。

满心欢喜，以为已经定位到问题了，但是查看RPC服务端耗时后确认服务端一切正常。。。

于是开始排查异常节点自身问题，查看Dashboard发现这类节点的GC时长明显高于正常节点，打开GC日志打印后却发现回收内存大小并没有太大差异，通过查看Arthas Dashboard发现这些节点的负载非常高，这就是导致单个节点吞吐下降的真正原因。

工作中经常被IM的消息淹没，而且通常是优先级很低的事情，导致很难专注做事情，长期开勿扰模式又会导致一些事情漏掉。
这里提供一个小脚本，在系统中将勿扰模式(D)和通知中心(N)的快捷键设置好后，脚本会每半小时关闭5分钟勿扰模式来让你进行消息回复。

repeat while true
	ignoring application responses
		tell application "System Events" to keystroke "D" using {command down, shift down, option down, control down}
	end ignoring
	say "DND opened"

                
                  
                  

为了规范内部不同组件代码的重试机制，hadoop对内部重试进行了统一封装，需要进行失败重试时调用RetryProxy.create()来创建一个代理对象：

public static <T> Object create(Class<T> iface, T implementation,
                              RetryPolicy retryPolicy)
                              
public static <T> Object create(Class<T> iface,
      FailoverProxyProvider<T> proxyProvider, RetryPolicy retryPolicy)
      

                
                  
                  

上一篇介绍了RPC客户端的核心实现，这一篇继续来看服务端的实现。服务端的NetServer由Server类及其子类实现，而ServerStub则由RpcInvoker接口及其实现类来实现。

@startuml
    'skinparam linetype ortho
    abstract "Server" as ServerTop #Yellow
    class RPC
    abstract Server {

    }
    ServerTop <|-d- Server
    RPC +-- Server
    interface RpcInvoker #Yellow {
        call(Server server, String protocol, Writable rpcRequest, long receiveTime)
    }
    RPC +-- RpcInvoker
    class WritableRpcEngine
    class ProtobufRpcEngine


    class "Server" as Server1 
    class "Server" as Server2

    WritableRpcEngine +-d- Server1
    ProtobufRpcEngine +-d- Server2

    Server1 .u.|> Server
    Server2 .u.|> Server
    Server1 +-d- WritableRpcInvoker
    Server2 +-d- ProtobufRpcInvoker
    WritableRpcInvoker .u.|> RpcInvoker
    ProtobufRpcInvoker .u|> RpcInvoker

    class WritableRpcInvoker
    class ProtobufRpcInvoker
@enduml

1.RPC常规实现

RPC实现通常包含下图几个部分：

@startuml

[Caller]
[ClientStub]
[NetClient]

                
                  
                  

1.Lambda表达式是什么

Java8中新引入的匿名函数功能，能够将匿名函数作为参数，相比传统的匿名内部类更加简洁。

2.Lambda表达式与匿名内部类有何区别

首先看一个简单的例子：

public class LambdaTest {
    public void fun1() {
        ((Runnable) () -> {

                
                  
                  

通常在使用Spark进行数据处理时，为了高性能的统计某些全局指标我们会使用SparkContext.xxxAccumulator()来创建累加器，然后在具体的算子中进行累加，从而省略了执行特定的统计逻辑。

但是，这里需要考虑一个问题，如果某一个task失败后进行重试会不会因为重复统计导致统计指标不准确呢？

我们需要理解Spark对accumulator的实现后才能确定，下面就以SparkContext.longAccumulator()为例来看看事情的真相。

1.创建LongAccumulator

  /**
   * Create and register a long accumulator, which starts with 0 and accumulates inputs by `add`.
   */

                
                  
                  

1. 核心抽象

Spark是一个分布式计算框架，job的执行过程一定会涉跨节点的方法调用（心跳，任务分发，block管理等），Spark RPC的实现可大致归纳为以下3个接口（抽象类）：

• RpcEnv：接收来自RpcEndpointRef发送的数据，并将数据转发至对应的RpcEndpoint，是整个RPC框架的协调中心
• RpcEndpoint：定义了从连接建立到收到消息时所需要触发功能的接口。RpcEndpoint启动时需要注册到RpcEnv，用于对外暴露服务
• RpcEndpointRef：对一个远程RpcEndpoint的引用，用于调用远程服务
  
阅读全文 »

70. Climbing Stairs

Difficulty: Easy

You are climbing a stair case. It takes n steps to reach to the top.

Each time you can either climb 1 or 2 steps. In how many distinct ways can you climb to the top?

Note: Given n will be a positive integer.

Example 1:

Input: 2

                
                  
                  

最短路径问题即：找出一个点到另一个点的最短路径。这类问题的解法有：

1.动态规划（DP）

以为63. Minimum Path Sum例，遍历方向只有右和下且目的地为最后一个节点，所以任意一个节点最终都能到达目的节点，此时只需要把所有节点遍历，并简单的记录每一个节点的最短路径就可以解决问题：

class Solution {
    public int minPathSum(int[][] grid) {
        for (int i = 0; i < grid.length; i++) {
            for (int j = 0; j < grid[0].length; j++) {