在Spring Cloud项目中，前后端分离目前很常见，在调试时，会遇到两种情况的跨域：

1. 前端页面通过不同域名或IP访问微服务的后台，例如前端人员会在本地起HttpServer 直连后台开发本地起的服务，此时，如果不加任何配置，前端页面的请求会被浏览器跨域限制拦截，所以，业务服务常常会添加如下代码设置全局跨域：

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

@Bean
public CorsFilter corsFilter() {
    logger.debug("CORS限制打开");
    CorsConfiguration config = new CorsConfiguration();
    # 仅在开发环境设置为*
    config.addAllowedOrigin("*");
    config.addAllowedHeader("*");
    config.addAllowedMethod("*");
    config.setAllowCredentials(true);
    UrlBasedCorsConfigurationSource configSource = new UrlBasedCorsConfigurationSource();
    configSource.registerCorsConfiguration("/**", config);
    return new CorsFilter(configSource);
}

2. 前端页面通过不同域名或IP访问SpringCloud Gateway，例如前端人员在本地起HttpServer直连服务器的Gateway进行调试。此时，同样会遇到跨域。需要在Gateway的配置文件中增加：

   1 2 3 4 5 6 7 8 9 10

   spring: cloud: gateway: globalcors: cors-configurations: # 仅在开发环境设置为* '[/**]': allowedOrigins: "*" allowedHeaders: "*" allowedMethods: "*"

那么，此时直连微服务和网关的跨域问题都解决了，是不是很完美？

No~ 问题来了，前端仍然会报错：“不允许有多个’Access-Control-Allow-Origin’ CORS头”。

1
2

Access to XMLHttpRequest at 'http://192.168.2.137:8088/api/two' from origin 'http://localhost:3200' has been blocked by CORS policy: 
The 'Access-Control-Allow-Origin' header contains multiple values '*, http://localhost:3200', but only one is allowed.

仔细查看返回的响应头，里面包含了两份Access-Control-Allow-Origin头。

我们用客户端版的PostMan做一个模拟，在请求里设置头：Origin : * ，查看返回结果的头:

不能用Chrome插件版，由于浏览器的限制，插件版设置Origin的Header是无效的

发现问题了：

Vary 和 Access-Control-Allow-Origin 两个头重复了两次，其中浏览器对后者有唯一性限制！

分析

1. Spring Cloud Gateway是基于SpringWebFlux的，所有web请求首先是交给DispatcherHandler进行处理的，将HTTP请求交给具体注册的handler去处理。

我们知道Spring Cloud Gateway进行请求转发，是在配置文件里配置路由信息，一般都是用url predicates模式，对应的就是RoutePredicateHandlerMapping 。所以，DispatcherHandler会把请求交给 RoutePredicateHandlerMapping.

2. 那么，接下来看下 RoutePredicateHandlerMapping.getHandler(ServerWebExchange exchange) 方法，默认提供者是其父类 AbstractHandlerMapping ：

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

@Override
public Mono<Object> getHandler(ServerWebExchange exchange) {
return getHandlerInternal(exchange).map(handler -> {
if (logger.isDebugEnabled()) {
logger.debug(exchange.getLogPrefix() + "Mapped to " + handler);
}
ServerHttpRequest request = exchange.getRequest();
// 可以看到是在这一行就进行CORS判断，两个条件：
// 1. 是否配置了CORS，如果不配的话，默认是返回false的
// 2. 或者当前请求是OPTIONS请求，且头里包含ORIGIN和ACCESS_CONTROL_REQUEST_METHOD
if (hasCorsConfigurationSource(handler) || CorsUtils.isPreFlightRequest(request)) {
CorsConfiguration config = (this.corsConfigurationSource != null ? this.corsConfigurationSource.getCorsConfiguration(exchange) : null);
CorsConfiguration handlerConfig = getCorsConfiguration(handler, exchange);
config = (config != null ? config.combine(handlerConfig) : handlerConfig);
//此处交给DefaultCorsProcessor去处理了
if (!this.corsProcessor.process(config, exchange) || CorsUtils.isPreFlightRequest(request)) {
return REQUEST_HANDLED_HANDLER;
}
}
return handler;
});
}

注：

网上有些关于修改Gateway的CORS设定的方式，是跟前面SpringBoot一样，实现一个CorsWebFilter的Bean，靠写代码提供 CorsConfiguration ，而不是修改Gateway的配置文件。其实本质，都是将配置交给corsProcessor去处理，殊途同归。但靠配置解决永远比hard code来的优雅。

该方法把Gateway里定义的所有的 GlobalFilter 加载进来，作为handler返回，但在返回前，先进行CORS校验，获取配置后，交给corsProcessor去处理，即DefaultCorsProcessor类

3. 看下DefaultCorsProcessor的process方法：

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
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99

@Override
public boolean process(@Nullable CorsConfiguration config, ServerWebExchange exchange) {

    ServerHttpRequest request = exchange.getRequest();
    ServerHttpResponse response = exchange.getResponse();
    HttpHeaders responseHeaders = response.getHeaders();

    List<String> varyHeaders = responseHeaders.get(HttpHeaders.VARY);
    if (varyHeaders == null) {
        // 第一次进来时，肯定是空，所以加了一次VERY的头，包含ORIGIN, ACCESS_CONTROL_REQUEST_METHOD和ACCESS_CONTROL_REQUEST_HEADERS
        responseHeaders.addAll(HttpHeaders.VARY, VARY_HEADERS);
    }
    else {
        for (String header : VARY_HEADERS) {
            if (!varyHeaders.contains(header)) {
                responseHeaders.add(HttpHeaders.VARY, header);
            }
        }
    }

    if (!CorsUtils.isCorsRequest(request)) {
        return true;
    }

    if (responseHeaders.getFirst(HttpHeaders.ACCESS_CONTROL_ALLOW_ORIGIN) != null) {
        logger.trace("Skip: response already contains \"Access-Control-Allow-Origin\"");
        return true;
    }

    boolean preFlightRequest = CorsUtils.isPreFlightRequest(request);
    if (config == null) {
        if (preFlightRequest) {
            rejectRequest(response);
            return false;
        }
        else {
            return true;
        }
    }

    return handleInternal(exchange, config, preFlightRequest);
}

// 在这个类里进行实际的CORS校验和处理
protected boolean handleInternal(ServerWebExchange exchange,
                                 CorsConfiguration config, boolean preFlightRequest) {

    ServerHttpRequest request = exchange.getRequest();
    ServerHttpResponse response = exchange.getResponse();
    HttpHeaders responseHeaders = response.getHeaders();

    String requestOrigin = request.getHeaders().getOrigin();
    String allowOrigin = checkOrigin(config, requestOrigin);
    if (allowOrigin == null) {
        logger.debug("Reject: '" + requestOrigin + "' origin is not allowed");
        rejectRequest(response);
        return false;
    }

    HttpMethod requestMethod = getMethodToUse(request, preFlightRequest);
    List<HttpMethod> allowMethods = checkMethods(config, requestMethod);
    if (allowMethods == null) {
        logger.debug("Reject: HTTP '" + requestMethod + "' is not allowed");
        rejectRequest(response);
        return false;
    }

    List<String> requestHeaders = getHeadersToUse(request, preFlightRequest);
    List<String> allowHeaders = checkHeaders(config, requestHeaders);
    if (preFlightRequest && allowHeaders == null) {
        logger.debug("Reject: headers '" + requestHeaders + "' are not allowed");
        rejectRequest(response);
        return false;
    }
    //此处添加了AccessControllAllowOrigin的头
    responseHeaders.setAccessControlAllowOrigin(allowOrigin);

    if (preFlightRequest) {
        responseHeaders.setAccessControlAllowMethods(allowMethods);
    }

    if (preFlightRequest && !allowHeaders.isEmpty()) {
        responseHeaders.setAccessControlAllowHeaders(allowHeaders);
    }

    if (!CollectionUtils.isEmpty(config.getExposedHeaders())) {
        responseHeaders.setAccessControlExposeHeaders(config.getExposedHeaders());
    }

    if (Boolean.TRUE.equals(config.getAllowCredentials())) {
        responseHeaders.setAccessControlAllowCredentials(true);
    }

    if (preFlightRequest && config.getMaxAge() != null) {
        responseHeaders.setAccessControlMaxAge(config.getMaxAge());
    }

    return true;
}

可以看到，在DefaultCorsProcessor 中，根据我们在appliation.yml 中的配置，给Response添加了 Vary 和 Access-Control-Allow-Origin 的头。

4. 再接下来就是进入各个GlobalFilter进行处理了，其中NettyRoutingFilter 是负责实际将请求转发给后台微服务，并获取Response的，重点看下代码中filter的处理结果的部分：

其中以下几种header会被过滤掉的：

很明显，在图里的第3步中，如果后台服务返回的header里有 Vary 和 Access-Control-Allow-Origin ，这时由于是putAll，没有做任何去重就加进去了，必然会重复，看看DEBUG结果验证一下：

验证了前面的发现。

解决

解决的方案有两种：

1. 利用 DedupeResponseHeader 配置：

1
2
3
4
5
6
7
8
9
10
11

spring:
    cloud:
        gateway:
          globalcors:
            cors-configurations:
              '[/**]':
                allowedOrigins: "*"
                allowedHeaders: "*"
                allowedMethods: "*"
          default-filters:
        - DedupeResponseHeader=Vary Access-Control-Allow-Origin Access-Control-Allow-Credentials, RETAIN_FIRST

DedupeResponseHeader 加上以后会启用DedupeResponseHeaderGatewayFilterFactory 在其中，dedupe方法可以按照给定策略处理值

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

private void dedupe(HttpHeaders headers, String name, Strategy strategy) {
List<String> values = headers.get(name);
if (values == null || values.size() <= 1) {
return;
}
switch (strategy) {
// 只保留第一个
case RETAIN_FIRST:
headers.set(name, values.get(0));
break;
// 保留最后一个        
case RETAIN_LAST:
headers.set(name, values.get(values.size() - 1));
break;
// 去除值相同的
case RETAIN_UNIQUE:
headers.put(name, values.stream().distinct().collect(Collectors.toList()));
break;
default:
break;
}
}

• 如果请求中设置的Origin的值与我们自己设置的是同一个，例如生产环境设置的都是自己的域名xxx.com或者开发测试环境设置的都是*（浏览器中是无法设置Origin的值，设置了也不起作用，浏览器默认是当前访问地址），那么可以选用RETAIN_UNIQUE策略，去重后返回到前端。
• 如果请求中设置的Oringin的值与我们自己设置的不是同一个，RETAIN_UNIQUE策略就无法生效，比如 ”*“ 和 ”xxx.com“是两个不一样的Origin,最终还是会返回两个Access-Control-Allow-Origin 的头。此时，看代码里，response的header里，先加入的是我们自己配置的Access-Control-Allow-Origin的值，所以，我们可以将策略设置为RETAIN_FIRST ，只保留我们自己设置的。

大多数情况下，我们想要返回的是我们自己设置的规则，所以直接使用RETAIN_FIRST 即可。实际上，DedupeResponseHeader 可以针对所有头，做重复的处理。

2. 手动写一个 CorsResponseHeaderFilter 的 GlobalFilter 去修改Response中的头。

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

@Component
public class CorsResponseHeaderFilter implements GlobalFilter, Ordered {

    private static final Logger logger = LoggerFactory.getLogger(CorsResponseHeaderFilter.class);

    private static final String ANY = "*";

    @Override
    public int getOrder() {
        // 指定此过滤器位于NettyWriteResponseFilter之后
        // 即待处理完响应体后接着处理响应头
        return NettyWriteResponseFilter.WRITE_RESPONSE_FILTER_ORDER + 1;
    }

    @Override
    @SuppressWarnings("serial")
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        return chain.filter(exchange).then(Mono.fromRunnable(() -> {
            exchange.getResponse().getHeaders().entrySet().stream()
                    .filter(kv -> (kv.getValue() != null && kv.getValue().size() > 1))
                    .filter(kv -> (kv.getKey().equals(HttpHeaders.ACCESS_CONTROL_ALLOW_ORIGIN)
                            || kv.getKey().equals(HttpHeaders.ACCESS_CONTROL_ALLOW_CREDENTIALS)
                            || kv.getKey().equals(HttpHeaders.VARY)))
                    .forEach(kv ->
                    {
                        // Vary只需要去重即可
                        if(kv.getKey().equals(HttpHeaders.VARY))
                            kv.setValue(kv.getValue().stream().distinct().collect(Collectors.toList()));
                        else{
                            List<String> value = new ArrayList<>();
                            if(kv.getValue().contains(ANY)){  //如果包含*，则取*
                                value.add(ANY);
                                kv.setValue(value);
                            }else{
                                value.add(kv.getValue().get(0)); // 否则默认取第一个
                                kv.setValue(value);
                            }
                        }
                    });
        }));
    }
}

此处有两个地方要注意：

1. 根据下图可以看到，在取得返回值后，Filter的Order 值越大，越先处理Response，而真正将Response返回到前端的，是 NettyWriteResponseFilter, 我们要想在它之前修改Response，则Order 的值必须比NettyWriteResponseFilter.WRITE_RESPONSE_FILTER_ORDER 大。

2. 修改后置filter时，网上有些文字使用的是 Mono.defer去做的，这种做法，会从此filter开始，重新执行一遍它后面的其他filter，一般我们会添加一些认证或鉴权的 GlobalFilter ，就需要在这些filter里用ServerWebExchangeUtils.isAlreadyRouted(exchange) 方法去判断是否重复执行，否则可能会执行二次重复操作，所以建议使用fromRunnable 避免这种情况。

SkyWalking 是观察性分析平台和应用性能管理系统（APM, Application Performance Management)，由个人开发者 吴晟 于2015年开源，2017年加入Apache孵化器。

它提供分布式跟踪、服务网格遥测分析、度量聚合和可视化的功能，支持Java、.Net、PHP、NodeJs、Golang、LUA语言探针，以及Envoy+Istio构建的Service Mesh，支持OpenTracing规范。

SkyWalking设计原则

• 保持可监控性

• 拓扑、指标和跟踪于一体

• 轻量级

• 可插拔

• 便于部署

• 与其他系统的可交互性

SkyWalking架构

SkyWalking总体的架构示意图如下：

SkyWalking 在逻辑上可以分为四个组件：

• Probes

  收集数据并转换为SkyWalking要求的格式，发送给后台。宏观的看，Probe包含三种形式：

  • 语言级的原生Agent

    这种Agent跟随目标系统一起运行，就像其代码的一部分，例如SkyWalking的Java Agent，用-javaagent 命令行参数去操纵（修改和注入）执行时的代码。其他方式的Agent，使用目标语言库所提供的hook或拦截等机制。

  • Service Mesh probe

    Service Mesh probe从sidecar、service mesh中servie的control panel或proxy获取数据。

  • 第三方工具库

    直接接收外部数据，用第三方库所提供的工具，将该数据转化为SKyWalking的格式发送到后端

• Platform backend

  SkyWalking的后台，又称为OAP(Observability Analysis Platform)，将数据进行聚合、分析以及UI的页面流程控制

• Storage

  SkyWalking的数据持久层，目前已支持像ElasticSearch、MySql、TiDB、H2等常见的各种持久化库

• UI

  用于展示数据

另外，SkyWalking也提供了CLI 可以用命令行进行操作和查询。

SpringCloud中SkyWalking的使用

1. 配置数据库

SkyWalking默认启用了H2的数据库，在生产级，更适合的显然是ElasticSearch（当然，H2下我也遇到了入库时报 Agent 生成的traceId 长度超过200的错误）。

方便起见，直接用 ES的Docker 镜像启用ES集群，本文选用7.9.2的镜像文件。

1
2
3
4
5

$sudo docker pull elasticsearch:7.9.2
# 此处为方便后续容器使用ES，为其创建一个网络
$sudo docker network create esnw
# 仅启动一个单节点做演示
$sudo docker run -d --name elasticsearch --net esnw -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" elasticsearch:7.9.2

注：

Docker启动的ES，默认cluster_name是 docker-cluster, 如有需要，可以提前改好，后续需指定

2. 配置并启用OAP后台及UI

2.1 下载包

SkyWalking在下载页面 http://skywalking.apache.org/downloads/ 提供了最新版本的整合包，包含了Agent、 OAP 和 UI 三个组件，但是，在Dockerhub上是将OAP（https://hub.docker.com/r/apache/skywalking-oap-server） 和UI（https://hub.docker.com/r/apache/skywalking-ui）是拆分开来了的。

注：

由于ES6和7 API的变动，OAP的分别为6和7单独打了一个包，x.y.z-es6是支持ES6的，x.y.z-es7是支持ES7的，由于我们的数据库选用的是ES7，所以要下的是es7最新的包

1
2

$sudo docker pull apache/skywalking-oap-server:8.1.0-es7
$sudo docker pull apache/skywalking-ui:8.1.0

2.2 配置

OAP 的配置集中在 config/application.yml 中，比较重要的配置有如下几个

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

cluster:
  # 配置SkyWalking的集群方式，默认是单节点，支持zk、k8s、consul、etcd和nacos
  selector: ${SW_CLUSTER:standalone}
core:
  selector: ${SW_CORE:default}
  default:
    # 对外暴露Http接口的地址以及端口12800
    restHost: ${SW_CORE_REST_HOST:0.0.0.0}
    restPort: ${SW_CORE_REST_PORT:12800}
    # 对外暴露gRPC接口的地址及端口11800
    gRPCHost: ${SW_CORE_GRPC_HOST:0.0.0.0}
    gRPCPort: ${SW_CORE_GRPC_PORT:11800}
storage:
  # 默认的数据库是H2
  selector: ${SW_STORAGE:H2}
  elasticsearch7:
    # 对应ES的cluser_name，即前面提到的docker-cluster
    nameSpace: ${SW_NAMESPACE:"docker-cluster"}
    clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:localhost:9200}
    protocol: ${SW_STORAGE_ES_HTTP_PROTOCOL:"http"}

此处，我们只需要将SW_STORAGE的默认值从H2 改为elasticsearch7 即可，如果之前改过ES的cluster_name，此处要将SW_NAMESPACE的默认值做对应修改。

Docker的配置，也可直接通过在启动时指定变量值进行改动。

2.3 启动

如果是整合包，则解压后，直接进入bin目录用startup脚本即可同时启动OAP和UI服务。

Docker启动：

1
2
3
4

# 启动OAP
$sudo docker run --name oap --network esnw --restart always -d -p 11800:11800 -p12800:12800 -e SW_STORAGE=elasticsearch7 -e
# 启动UI
$docker run --name oap-ui --network esnw --restart always -d -p 8080:8080 -e SW_OAP_ADDRESS=oap:12800 apache/skywalking-ui:8.1.0

注:

SkyWalking的UI有个坑，不支持反向代理，具体可参见 github issue #2675

3. 配置并启用Agent

SkyWalking对于Java项目十分友好，默认提供的Agent就是Java的，使用JavaAgent进行字节码注入实现拦截。SkyWalking是遵循OpenTracing 规范的，下图是OpenTracing 中定义的数据结构。

其中，

• SpanContext：负责上线文信息保持和传递
• Trace: 一次调用的完整记录
  • Span: 一次调用中的某个节点/步骤，类似于一层堆栈信息，Trace是由多个Span组成，Span本身也是可以嵌套自身的数据结构
    • Tag: 节点/步骤中的关键信息
    • Log: 节点/步骤中的日志，例如抛出的异常栈
  • Baggage: 主要用于运行时跨Span或跨实例的上下文传递

3.1 配置

从前面下载页下载的整合包里，把整个 agent 目录拷到项目文件里，或者单独放在某个位置。

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

activations
bootstrap-plugins
# 配置文件存放目录
config
# agent运行时生成的日志保存在此目录
logs
# 可选用的插件，默认不启用
optional-plugins
# 可选用的reporter插件，默认不启用
optional-reporter-plugins
# 默认启用的插件放于此目录
plugins
# 拦截探针实现
skywalking-agent.jar

暂时没有需要修改的配置，就不去更改配置文件了。

optional-plugins 里的插件默认是不启用的，如果要启用，需要将其移动到plugins目录。

在optional-plugins里，有几个可选插件是值得我们注意的：

• apm-spring-annotation-plugin-8.1.0.jar

  该插件可追踪Spring上下文中被@Bean , @Service ，@Component和@Repository 注解的方法，该插件一旦启用，会产生大量的span，从而消耗更多的资源，所以默认是把它放到了可选插件中。

• apm-spring-cloud-gateway-2.1.x-plugin-8.1.0.jar

  该插件将从SpringCloudGateway产生的span与后续相同链路的span合并到一起进行追踪，如果没有这个插件，一个REST请求，如/api/hello，经过SC Gateway到达服务a时，将会在UI上展示两个跟踪记录而非一条（服务a也必须启用skywalking agent）。该插件依赖spring-webflux-5.x-plugin。但该插件应该只对Spring Cloud Gateway启用。

• apm-trace-ignore-plugin-8.1.0.jar

  该插件可以自定义过滤掉一些路径，不被追踪。使用时，需要把/agent/optional-plugins/apm-trace-ignore-plugin/apm-trace-ignore-plugin.config 拷贝到/agent/config目录，然后修改其内容增加想要过滤掉的路径，例如：

  1	trace.ignore_path=/your/path/1/**,/your/path/2/**

• apm-customize-enhance-plugin-8.1.0.jar

  该插件可以通过指定增强文件来实现方法级的精细拦截及span生成的定义，而不用写代码。具体参见：这里

为方便测试，我们将apm-spring-annotation-plugin-8.1.0.jar和apm-spring-cloud-gateway-2.1.x-plugin-8.1.0.jar 拷入 plugins 目录启用。

3.2 启动

在启动SC项目文件时，增加JVM参数：

1

-javaagent:<absolute_path>\agent\skywalking-agent.jar -Dskywalking.agent.service_name=<service_name> -Dskywalking.collector.backend_service=<oap_address>:11800

其中，Java Agent 默认采用的gRPC调用，所以端口默认为11800。

启动时，Agent会根据jar包所在位置自动寻找config目录下的agent.config文件读取配置。

至此，SkyWalking的初步整合已经完毕，可以向SpringCloud Gateway发送一个请求到具体的微服务，等待几秒后，可在UI 的拓扑图页面中看到整个微服务的拓扑，在追踪页面中看到查找到刚才所发请求的整个链路调用过程以及所消耗的时间以及具体的log等。

在使用Akka kafka consumer前， 先了解下几个核心API：

• ConsumerSetting Consumer的配置信息；
• ConsumerRecord Kafka消息的封装类，包含消息的K、V，以及该消息所属的topic, partition, offset, timestamp等；
• ConsumerMessage 是ConsumerRecord的进一步充血模型，提供了自动commit以及修改offset信息的API；
• Subscription 该Consumer的订阅信息，有AutoSubscription和ManualSubscription两个子接口，分别用于自动从Topic读取Partition以及手动绑定Partition；

Akka Kafka中，Consumer一般是作为流的Source，在akka.kafka.javadsl.Consumer中提供了常用的几种Source。主要包含两大类：

1. Offset存储及读取机制独立于Kafka以外，需自行实现commit逻辑，命名为plainxxxSource；2. Offset存储及读取机制依赖于Kafka的所提供的API，通过调用Akka已封装的`ConsumerMessage`进行offset的commit，命名为committableXXXSource

详情可以参见最后的目录。

使用

依赖

1
2
3
4

<dependency>
    <groupId>com.typesafe.akka</groupId>
    <artifactId>akka-stream-kafka_2.12</artifactId>
</dependency>

配置

所有的Consumer都需要传入配置类ConsumerSetting，需要提供如下信息：

• Kafka消息key和value的反序列化器
• Kafka集群的地址信息
• consumer的GroupId，注意：offset是按组进行commit的
• Kafka Consumer的调优参数

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

public static ConsumerSettings getConsumerSettings(
        Deserializer keyDeserializer,
        Deserializer valDeserializer,
        Config config,
        String groupId){
    Deserializer<String> keySerializer = new StringDeserializer();
    Deserializer<byte[]> valSerializer = new ByteArrayDeserializer();

    return ConsumerSettings.create(config, keyDeserializer, valDeserializer)
            .withGroupId(groupId) // if not defined here, config must contains "group.id"
            .withProperty(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
}

数据处理服务定义

我们用相同的一段代码，来代表整个Flow中的数据转换过程。

1
2
3
4
5
6
7
8

static class DummyBusinessLogic {
    public CompletionStage<Integer> work(ConsumerRecord<String, byte[]> record){
        return CompletableFuture.supplyAsync(() -> {
            System.out.println("Partition["+record.partition()+"] got:"+new String(record.value()));
            return record.partition();
        });
    }
}

Offset管理独立于Kafka以外

此类API命名规则都是plainXXXSource，对外都emit出ConsumerRecord，Offset维护在外部的存储里，可以先读取再处理或提供读取的方法给API由其调用获得最新的Offset。Commit也是手动进行，但是可以通过修改auto-commit参数（该值默认是false），由Kafka自行进行Offset的Commit。Kafka的自动Commit是阈值和周期性的Commit，哪个先触发就直接commit，比较适合量大且允许消息重复递交的场景。
我们先实现一个简单的外部存储类，用以演示

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

// A dummy storage to store offset externally
static class ExternalOffsetStorage {
    private Map<TopicPartition, Long> partitionOffsetMap = new HashMap<>();

    public ExternalOffsetStorage(String topic, int partitonNum) {
        for(int i=0;i<partitonNum;i++){
            partitionOffsetMap.put(new TopicPartition(topic, i), new Long(0));
        }
    }

    // User CompletionStage is to warn that read the offset may cost some time
    /*public CompletionStage<Long> getLatestOffset(){
        return CompletableFuture.completedFuture(offset.get());
    }*/
    public Long getLatestOffset(TopicPartition partition){
        return partitionOffsetMap.get(partition);
    }

    public CompletionStage<Done> commitOffset(TopicPartition partition){
        return CompletableFuture.supplyAsync(() -> {
            partitionOffsetMap.put(partition, getLatestOffset(partition)+1);
            return Done.done();
        });
    }

    public CompletionStage<Done> commitOffset(int partition){
        return CompletableFuture.supplyAsync(() -> {
            for(TopicPartition p: partitionOffsetMap.keySet()){
                if(p.partition() == partition)
                    partitionOffsetMap.put(p, partitionOffsetMap.get(p)+1);
            }
            return Done.done();
        });
    }

    public Map<TopicPartition, Long> getPartitionOffsetMap() {
        return partitionOffsetMap;
    }

    public CompletionStage<Map<TopicPartition, Object>> getOffsetsOnAssign(Set<TopicPartition> topicPartitions){
        return CompletableFuture.supplyAsync(()->{
            Map<TopicPartition, Object> result = new HashMap<>();
            topicPartitions.forEach(partition -> result.put(partition, partitionOffsetMap.get(partition)));
            return result;
        });
    }
}

不分Partition处理

不分Partition处理的API，是最简单的Consumer.plainSource,它接受两个参数：

• ConsumerSetting 配置参数
• Subscription Kafka的partition信息，可以是AutoSubscription或ManualSubscription。
  • AutoSubscription用Subscriptions.topics("topic")来指定
  • ManualSubscription则需要显式提供每一个TopicPartition及其对应的offset。如果只有一个partition，可以直接Subscriptions.assignmentWithOffset(new TopicPartition("topic", /*partition: */ 0), currentOffset)。如果是多个partition，则传入一个Map，TopicPartition作为key，Offset的值为value。
    由于commit的时机和逻辑都是自己提供的，所以比较适合去实现exact-once-delivery。

    1 2 3 4 5 6 7

    Consumer.plainSource( consumerSettings, Subscriptions.assignmentWithOffset(offsetStorage.getPartitionOffsetMap())) //Subscriptions.topics(topic)) .mapAsync(partitionNum, record -> logic.work(record).thenApply(partition->offsetStorage.commitOffset(partition))) .to(Sink.ignore()) .run(materializer);

分Partition处理

API中含Partitioned字样的，均是分Partition处理的API，即每一个Partition会对应一个新的子Source。这一类中，是Consumer.plainPartitionedSource和Consumer.plainPartitionedManualOffsetSource。
与plainSource不同的点是：

• 只接受AutoSubscription
• 原Source并不直接emit ConsumerRecord，而是派生出三个子Source，从它获得的是一个Pair<TopicPartition, Source>封装类，包含了为每一个partition提供了一个Source对象。
• Consumer.plainPartitionedManualOffsetSource在Consumer.plainPartitionedSource基础上，增加了一个函数参数，要求传入一个Function，根据提供的包含TopicPartition信息的Set，返回对应的每个Partition的Offset信息，封装在一个Map里，key是TopicPartition, value是offset值。

下面例子里，用flatMapMerge将原Source派生的Source合并（即Pair::second返回值）后，交由同一段Flow处理。

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

if(!manualAssignOffset)
    Consumer.plainPartitionedSource(
            consumerSettings,
            Subscriptions.topics(topic))
            // merge ConsumerRecord from different partition Source
            .flatMapMerge(partitionNum, Pair::second)
            // use same logic flow to handle ConsumerRecord
            .mapAsync(partitionNum, record -> logic.work(record).thenApply(partition->offsetStorage.commitOffset(partition)))
            .to(Sink.ignore())
            .run(materializer);
else
    Consumer.plainPartitionedManualOffsetSource(
            consumerSettings,
            Subscriptions.topics(topic),
            offsetStorage::getOffsetsOnAssign)
            //.mapAsync(partitionNum, logic::workWithPartitions)
            .flatMapMerge(partitionNum, Pair::second)
            .mapAsync(partitionNum, record -> logic.work(record).thenApply(partition->offsetStorage.commitOffset(partition)))
            .to(Sink.ignore())
            .run(materializer);

Offset管理依赖Kafka

Kafka的JAVA API，提供了将offset保存在zookeeper上的功能，在新版的Kafka，更是为了避免zookeeper的性能问题，在其内部创建一个叫__consumer_offsets的topic来存储offset。由offsets.storage参数定义。

基本使用

该API能够自由控制何时将offsetcommit到Kafka去。比较适合用于at-least-once递交的场景，即消息可能会被多次递交，以保证至少会有一次成功，但相应的，如果发生错误，该错误也会发生多次。

1
2
3
4
5
6
7
8

// single commit
Consumer.committableSource(consumerSettings, Subscriptions.topics(topic))
                // asynchronously finish logic work and fetch the offset to commit
                .mapAsync(1, msg-> logic.work(msg.record()).thenApply(partition -> msg.committableOffset()))
                // commit offset
                .mapAsync(1, offset->offset.commitJavadsl())
                .to(Sink.ignore())
                .run(materializer);

这里用了mapAsync异步并行来处理消息，并行数位设为1，保证处理消息的顺序（Kafka单个partition是保序的，但是对于同一个topic的多个partition之间是无序的）。
运行一下Producer，然后可以用JMX查看该Topic的offset数在上升。

该API每处理一个消息就会commit一次，这种方式相当慢。推荐的方式是用batch批量commit，用牺牲发生错误时的重复投递来换取性能。

批量Commit

自动批处理

Akka提供了Committer.sink方法来实现自动批量Commit。在使用这个sink前，需要先在配置文件中定义或者代码里直接指定以下两个参数：

• max-batch 每次commit的最大消息数，即超过该数即会触发一次commit
• max-interval 两次commit之间的最大间隔

这两个参数调的越大，Kafka对于commit的load越小，消耗时间越少，但相应的，如果发生错误，重新处理的消息数肯定也是对应增加的。调的越小，则commit越频繁，会带来commit性能瓶颈。这个属于Kafka批量commit的老问题了，与Akka本身是无关的，应视不同场景进行相应参数优化。
修改application.conf，在akka.kafka.consumer区块中添加

1
2
3
4
5
6
7

akka.kafka.consumer {
    ...
    # Maximum number of messages in a single commit batch
    max-batch = 1000
    # Maximum interval between commits in milliseconds
    max-interval = 10000
}

批量commit代码如下：

1
2
3
4
5
6
7

// batch commit
Consumer.committableSource(consumerSettings, Subscriptions.topics(topic))
        .mapAsync(1, msg-> logic.work(msg.record())
                .<ConsumerMessage.Committable>thenApply(partition -> msg.committableOffset())
        )
        .to(Committer.sink(CommitterSettings.create(config)))
        .run(materializer);

PS: .<ConsumerMessage.Committable>这里是做类型强转，将msg.committableOffset返回的CommittableOffset转成其实现接口Committable。

手动批处理

另一种方式，是手动的将消息用Akka Stream的batchAPI聚合后做批量commit。

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

// manual batch commit
Consumer.committableSource(consumerSettings, Subscriptions.topics(topic))
        .mapAsync(1, msg-> logic.work(msg.record())
                .thenApply(partition -> msg.committableOffset())
        )
        .batch(
                20,
                ConsumerMessage::createCommittableOffsetBatch,
                ConsumerMessage.CommittableOffsetBatch::updated
        )
        .mapAsync(3, batch->batch.commitJavadsl())
        .to(Sink.ignore())
        .run(materializer);

注意：
用这种方式时，只有当下游consumer处理速度比上游的producer处理速度要慢时，batch才会触发（背压），否则会按正常commit处理。
测试时，需要把producer中的控制发送速率的.throttle()注掉，同时调高发送消息数，这样才能看到效果。

按时间聚合批处理

以上都是适合于消息速率比较高的场景，有些场景下，消息的速率非常低，可能24小时内没有任何消息抵达。此时，需考虑打开kafka的批量commit刷新参数（akka.kafka.consumer.commit-refresh-interval），否则在Kafka的存储中，offset会过期。同时，对于这种速率较低的topic，最好使用按时间进行聚合后进行批处理的groupWithinAPI。

1
2
3
4
5
6
7
8
9
10

// time-based aggregation
Consumer.committableSource(consumerSettings, Subscriptions.topics(topic))
        .mapAsync(1, msg-> logic.work(msg.record())
                .thenApply(partition -> msg.committableOffset())
        )
        .groupedWithin(5, Duration.ofSeconds(60))
        .map(ConsumerMessage::createCommittableOffsetBatch)
        .mapAsync(3, batch->batch.commitJavadsl())
        .to(Sink.ignore())
        .run(materializer);

groupedWithinAPI，接受两个参数，第一个是控制多少个消息触发聚合，第二个是控制时间窗口。如果窗口内接受消息数超过第一个参数，则立刻聚合，如果未超过，到窗口时间到期时也会触发。

测试时，第一个先把Producer的最大消息数改为4，然后不要启用速率控制。看到offset并不是立刻就commit掉。然后把Producer的最大消息数改为10，每1秒发送一个，可以看到当超过5时，立刻触发commit。

分Partition处理

TODO: 流的聚合

其他

有时，我们想在offset里添加自定义的metadata，此时，可以调用Consumer.commitWithMetadataSourceAPI，用法还是比较简单，具体请参考官方文档。但需要注意的是，由于kafka可以周期性commit（akka.kafka.consumer.commit-refresh-interval参数），第一个offset可能并不会包含新的metadata信息。

每个Partition一个独立的Source

at-least-once投递

at-most-once投递

单独commit

Consumer.atMostOnceSource

批量commit

附录

Consumer API

在用Akka去对接Kafka之前，有必要先简单了解下Akka Stream，它是基于Reactive Stream(Akka是其创立成员之一)的。Akka Stream中，将流的拓扑处理逻辑命名为Graph，拓扑中每个操作命名为Operator。
它将流式处理抽象为几个核心API：

• Source : 有且仅有一个Output的operator，对应数据的来源，将数据反序列化后发送给下游逻辑。
• Sink : 有且仅有一个Input的operator，对应最终数据的去向，常用于结果存储。
• Flow : 有且仅有一个Input和Output的operator，用于定义数据的处理逻辑。
• RunnableGraph : 一个对接了Source和Sink，并且已经准备好run()的Flow。一般用source.to(sink)或source.runWith(sink, materializer)构成一个RunnableGraph，可通过via(flow)添加其他flow。
• Materializer : 这个SPI(Service Provider Interface)是根据前面定义的graph进行资源申请，生成相应Actor类，然后进行执行的。这篇博文从源码级对它的原理进行了阐述，写的相当透彻，就不再重复了。

Akka Kafka核心API

• Router 路由器，消息由外部发送到路由器，再由路由器通过路由算法转发给具体的执行者，相当于消息的中转站。
• Routee 路由目标，最早处理消息的地方。

在Akka中，提供了两种做路由的方式：

• 直接使用akka.routing.Router类
• 使用内置的Router Actor

直接使用Router类

直接使用akka.routing.Router类的原理其实与上一章的最简单的例子是一样的，只不过akka的Router类比我们实现的更复杂、更强大。创建Router类时需提供两个参数：

• 路由规则
  akka为Router类提供了以下几种内置的路由算法类：

  • akka.routing.RoundRobinRoutingLogic
  • akka.routing.RandomRoutingLogic
  • akka.routing.SmallestMailboxRoutingLogic
  • akka.routing.BroadcastRoutingLogic
  • akka.routing.ScatterGatherFirstCompletedRoutingLogic
  • akka.routing.TailChoppingRoutingLogic
  • akka.routing.ConsistentHashingRoutingLogic
    具体算法介绍请参见文章最后的表格

• 路由目标的序列
  该序列支持通过调用router.addRoutee和router.removeRoutee进行动态变化，但需要注意的是，akka.routing.Router类时一个immutable的线程安全类，即不可改变，这里的改变其实是将原来的router内的的routee队列增加/去掉指定routee后copy一份生成一个新的Router

  1	def removeRoutee(routee: Routee): Router = copy(routees = routees.filterNot(_ == routee))

依赖

1
2
3
4

<dependency>
    <groupId>com.typesafe.akka</groupId>
    <artifactId>akka-cluster-tools_2.12</artifactId>
</dependency>

配置文件application.conf

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

akka {
  actor {
    provider = "cluster"
  }
  remote {
    netty.tcp {
      hostname = "127.0.0.1"
      port = 0
    }
    artery {
      enabled = off
      canonical.hostname = "127.0.0.1"
      canonical.port = 0
    }
  }

  cluster {
    seed-nodes = [
      "akka.tcp://ClusterSystem@127.0.0.1:2551"
    ]
  }
}

实际做事的SlaveActor

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

public class SlaveActor extends AbstractActor {

    LoggingAdapter log = Logging.getLogger(getContext().system(), this);
    
    @Override
    public Receive createReceive() {
        return receiveBuilder()
                .match(String.class, word-> log.info("Node {} receives: {}", getSelf().path().toSerializationFormat(), word))
                .build();
    }

    public static void main(String[] args) {
        Config config =
                ConfigFactory.parseString("akka.cluster.roles = [slave]")
                        .withFallback(ConfigFactory.load());

        ActorSystem system = ActorSystem.create("ClusterSystem", config);
        system.actorOf(Props.create(SlaveActor.class), "slaveActor");
    }
}

包含路由的MasterActor

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

public class MasterActor extends AbstractActor {

    LoggingAdapter log = Logging.getLogger(getContext().system(), this);

    private Router router = new Router(new RoundRobinRoutingLogic(), new ArrayList<>());
    private Cluster cluster = Cluster.get(getContext().system());
    boolean isReady = false;
    private static final String SLAVE_PATH = "/user/slaveActor";

    @Override
    public void preStart() throws Exception {
        cluster.subscribe(self(), ClusterEvent.MemberEvent.class, ClusterEvent.ReachabilityEvent.class);
    }

    @Override
    public Receive createReceive() {
        return receiveBuilder()
                .match(String.class, msg->{
                    log.info("Master got: {}", msg);
                    if(!isReady)
                        log.warning("Is not ready yet!");
                    else {
                        log.info("Routee size: {}", router.routees().length());
                        router.route(msg, getSender());
                    }
                })
                .match(ClusterEvent.MemberUp.class, mUp->{
                    if(mUp.member().hasRole("slave")) {
                        Address address = mUp.member().address();
                        String path = address + SLAVE_PATH;
                        ActorSelection selection = getContext().actorSelection(path);
                        router = router.addRoutee(selection);
                        isReady=true;
                        log.info("New routee is added!");
                    }
                })
                .match(ClusterEvent.MemberRemoved.class, mRemoved->{
                    router = router.removeRoutee(getContext().actorSelection(mRemoved.member().address()+SLAVE_PATH));
                    log.info("Routee is removed");
                })
                .match(ClusterEvent.UnreachableMember.class, mRemoved-> {
                    router = router.removeRoutee(getContext().actorSelection(mRemoved.member().address() + SLAVE_PATH));
                    log.info("Routee is removed");
                })
                .build();
    }

    public static void main(String[] args) {
        int port = 2551;

        // Override the configuration of the port
        Config config =
                ConfigFactory.parseString(
                        "akka.remote.netty.tcp.port=" + port + "\n" +
                                "akka.remote.artery.canonical.port=" + port)
                        .withFallback(
                                ConfigFactory.parseString("akka.cluster.roles = [master]"))
                        .withFallback(ConfigFactory.load());

        ActorSystem system = ActorSystem.create("ClusterSystem", config);
        ClusterHttpManagement.get(system);
        AkkaManagement.get(system).start();
        system.actorOf(Props.create(MasterActor.class), "masterActor");
    }
}

这里将MasterActor监听了集群的MemberUp事件，通过判断事件中包含的role判断是否是SlaveActor加入集群。如果是，则将该SlaveActor加到Router中。同时，如果SlaveActor退出或变成Unreachable状态，则从Router中删除。

向MasterActor请求的客户端

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

public class Client
{
    public static void main( String[] args ) throws InterruptedException {
        Config config = ConfigFactory.load();
        ActorSystem system = ActorSystem.create("ClusterSystem", config);
        ActorSelection toFind = system.actorSelection("akka.tcp://ClusterSystem@127.0.0.1:2551/user/masterActor");
        int counter = 0;
        while(true){
            toFind.tell("hello "+counter++, ActorRef.noSender());
            System.out.println("Finish telling");
            Thread.sleep(2000);
        }
    }
}

分别启动四个窗口: 一个masterActor节点，两个slaveActor节点，一个Client，可以看到两个slaveActor轮流打印Client传递进去的消息。这时，把其中一个slaveActor关闭，可以看到Client发送的所有消息将被剩下那个slaveActor打印出来。

使用Router Actor

除了我们自己在Actor里调用akka.routing.Router类外，Akka还提供了根据配置直接生成一个内置的RouterActor。路由逻辑在remoting和cluster两个模块中都有，如果要启用remoting中的路由，则需要引入remoting的依赖，在cluster环境下并不推荐直接去用remoting中的路由，而是用cluster模块中的cluster aware router。

RouterActor有两种类型：

• Pool
  Router自动创建Routee作为自己的子Actor，然后部署到远程节点上。当Routee被终止时，会自动从Router的路由表中删除，除非使用动态路由（指定resizer），否则Router不会重新创建新的Routee，当所有的Routee都停止时，Router也自动停止。
• Group
  Routee actor是在Router actor以外单独创建好了,Router用ActoSelection向指定的Actor Path发送消息，但默认并不监控Routee。

Router actor可以通过程序配置或文件配置。如果是通过文件配置时，必须要在代码中使用FromConfig或RemoteRouterConfig(将Routee部署到远程节点去)去显式的读取相关配置，否则即便在配置文件中定义了路由相关配置，akka也不会去使用。
Router actor在转发消息时不会更改消息的sender，而routee actor在回复消息时，消息直接返回到原始的发送者，不再经过router actor。

无论哪种类型，有一块是相同配置：

1
2
3
4
5

cluster {
  enabled = on
  allow-local-routees = off
  use-roles = [slave]
}

enabled 是否启用cluster aware router
allow-local-routees 能否在本地，即router所在的节点创建和查找routee
use-roles 使用指定的角色来缩小routee的查找范围，如果routee的配置与这里的不同，则router是找不到该routee的。

Pool

我们在上面例子的基础上，把自己new的Router换成akka内置的RouterActor。改动主要有以下几个：

• 在配置文件中指定路由相关信息
• 在MasterActor中，读取路由配置，创建router及相关的routees

1. 配置文件中actor部分增加：

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

   actor { provider = "cluster" deployment { /masterActor/poolRouter { router = round-robin-pool nr-of-instance = 5 cluster { enabled = on allow-local-routees = on use-roles = [master] } } default { cluster { max-nr-of-instances-per-node = 5 } } } }

由于我们的Router是在masterActor下创建的RouterActor，取名为poolRouter，所以其路径显然是akka.tcp://ClusterSystem@127.0.0.1:2551/user/masterActor/poolRouter，masterActor启动时读取的是这个配置文件，所以deployment部分对应的就是masterActor及其子Actor，所以这里只需要填入相对路径就好了。注意，由于Routee是由masterActor创建出来的，所以use-role必须是与masterActor保持一致，否则会找不到Routee!
- router 指定预设的路由器
- nr-of-instance routee的个数

注意,有两个参数非常关键：

• actor.deployment.default.cluster.max-nr-of-instances-per-node 它是配置Router在每个节点上部署的最大Actor数，默认是1。虽然上面我们指定了routee数目为5，但是如果只起一个节点，你会发现永远是
  1个routee在打印结果。
• max-total-nr-of-instances 定义router所能创建的routee的总数，默认是10000。通常来说足够用了。

2. 修改MasterActor。注释掉的部分是直接使用代码而不用配置文件手动创建Router的，有兴趣的可以自己试下。

   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

   public class MasterActor extends AbstractActor { LoggingAdapter log = Logging.getLogger(getContext().system(), this); private ActorRef router; @Override public void preStart() throws Exception { router = getContext().actorOf(FromConfig.getInstance().props(Props.create(SlaveActor.class)), "poolRouter"); /*int totalInstances = 1000; int maxInstancePerNode = 5, routeeNumbers=5; boolean allowLocalRoutees = true; String role = "master"; ClusterRouterPoolSettings settings = new ClusterRouterPoolSettings(totalInstances, maxInstancePerNode, allowLocalRoutees, role); ClusterRouterPool routerPool = new ClusterRouterPool(new RoundRobinPool(routeeNumbers), settings); router = getContext().actorOf(routerPool.props(Props.create(SlaveActor.class)), "poolRouter");*/ } @Override public Receive createReceive() { return receiveBuilder() .match(String.class, msg->{ log.info("Master got: {}", msg); router.tell(msg, getSender()); }) .build(); } }

3. 运行
   其他不变，这次只需要启动Client和MasterActor，SlaveActor在MasterActor中会自动创建出来。看到日志

   1 2 3 4 5 6 7 8 9 10

   [INFO] [11/16/2018 14:19:58.361] [ClusterSystem-akka.actor.default-dispatcher-2] [akka://ClusterSystem/user/masterActor] Master got: hello [INFO] [11/16/2018 14:19:58.361] [ClusterSystem-akka.actor.default-dispatcher-2] [akka://ClusterSystem/user/masterActor/poolRouter/c1] Node akka://ClusterSystem/user/masterActor/poolRouter/c1#-1154482163 receives: hello [INFO] [11/16/2018 14:20:00.362] [ClusterSystem-akka.actor.default-dispatcher-16] [akka://ClusterSystem/user/masterActor] Master got: hello [INFO] [11/16/2018 14:20:00.362] [ClusterSystem-akka.actor.default-dispatcher-16] [akka://ClusterSystem/user/masterActor/poolRouter/c2] Node akka://ClusterSystem/user/masterActor/poolRouter/c2#-50692619 receives: hello [INFO] [11/16/2018 14:20:02.365] [ClusterSystem-akka.actor.default-dispatcher-18] [akka://ClusterSystem/user/masterActor] Master got: hello [INFO] [11/16/2018 14:20:02.365] [ClusterSystem-akka.actor.default-dispatcher-18] [akka://ClusterSystem/user/masterActor/poolRouter/c3] Node akka://ClusterSystem/user/masterActor/poolRouter/c3#1415650532 receives: hello [INFO] [11/16/2018 14:20:04.366] [ClusterSystem-akka.actor.default-dispatcher-3] [akka://ClusterSystem/user/masterActor] Master got: hello [INFO] [11/16/2018 14:20:04.366] [ClusterSystem-akka.actor.default-dispatcher-3] [akka://ClusterSystem/user/masterActor/poolRouter/c4] Node akka://ClusterSystem/user/masterActor/poolRouter/c4#1345851811 receives: hello [INFO] [11/16/2018 14:20:06.368] [ClusterSystem-akka.actor.default-dispatcher-20] [akka://ClusterSystem/user/masterActor] Master got: hello [INFO] [11/16/2018 14:20:06.368] [ClusterSystem-akka.actor.default-dispatcher-20] [akka://ClusterSystem/user/masterActor/poolRouter/c5] Node akka://ClusterSystem/user/masterActor/poolRouter/c5#-1384624865 receives: hello

从c1到c5轮流打印，round-robin负载均衡起作用了。

Group

这种方式下，Routee是在Router外被创建的，一般要求尽量在Router启动前启动好Routee，因为Router在启动过程中会尝试去联络Routee。使用时与Pool型的很像，区别是

• 需要指定routees.path (remote方式下支持完整协议路径，比如akka.tcp://ClusterSystem:2551/user/testActor，但是Cluster模式下不支持，只支持相对路径)
• 不需要指定也没有nr-of-instance参数

GroupActor是根据routees.path所配置的相对路径，去当前cluster的每一个节点上用ActorSelection去查找指定role的Routee（所以use-roles中的配置一定要和slave启动时的role一致），然后直接tell消息过去。由于整个过程是异步的，就意味着GroupActor的消息发送其实根本不关心节点上对应的Routee是否包含Routee或者是否正常启动，只是简单的根据配置去转发而已。
不去检测是否包含Routee，是因为Akka是Peer-to-Peer的设计，天生就要求所有节点对等，在这个约定下，它会认为cluster中所有节点的代码相同，一定会包含Routee。
不去检测是否正常启动，这个则是由于整个通讯都是异步的。
但我个人认为这里还是使用熔断机制来加强的，使用起来会更加方便。

1. 修改配置文件

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

   actor { provider = "cluster" deployment { /masterActor/groupRouter { router = round-robin-group cluster { enabled = on allow-local-routees = on use-roles = [slave] } } } }

use-roles中role加不加引号都可以。

2. 修改MasterActor中Router的名字，与配置文件中保持一致。注释掉的部分是直接使用代码而不用配置文件手动创建Router的，有兴趣的可以自己试下。

   1 2 3 4 5 6

   @Override public void preStart() throws Exception { router = getContext().actorOf(FromConfig.getInstance().props(Props.create(SlaveActor.class)), "groupRouter"); /*List<String> routeesPaths = Arrays.asList("akka/user/slaveActor"); router = getContext().actorOf(new RoundRobinGroup(routeesPaths).props(), "groupRouter");*/ }

3. 运行
   分别在几个不同窗口启动MasterActor、多个SlaveActor后，检查集群是否稳定后，即所有节点均是UP，如果启用了akka-management-cluster-http，向监控地址发送查询请求，如
   127.0.0.1:8558/cluster/members

   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

   { "selfNode": "akka.tcp://ClusterSystem@127.0.0.1:2551", "oldestPerRole": { "master": "akka.tcp://ClusterSystem@127.0.0.1:2551", "dc-default": "akka.tcp://ClusterSystem@127.0.0.1:2551", "slave": "akka.tcp://ClusterSystem@127.0.0.1:4914" }, "leader": "akka.tcp://ClusterSystem@127.0.0.1:2551", "oldest": "akka.tcp://ClusterSystem@127.0.0.1:2551", "unreachable": [], "members": [ { "node": "akka.tcp://ClusterSystem@127.0.0.1:2551", "nodeUid": "-1141014070", "status": "Up", "roles": [ "master", "dc-default" ] }, { "node": "akka.tcp://ClusterSystem@127.0.0.1:4914", "nodeUid": "344021242", "status": "Up", "roles": [ "slave", "dc-default" ] }, { "node": "akka.tcp://ClusterSystem@127.0.0.1:4936", "nodeUid": "678163307", "status": "Up", "roles": [ "slave", "dc-default" ] }, { "node": "akka.tcp://ClusterSystem@127.0.0.1:4957", "nodeUid": "-573369962", "status": "Up", "roles": [ "slave", "dc-default" ] } ] }

然后，启动Client向masterActor发送消息，可以看到均匀的打印出接受的日志，round-robin负载均衡起作用了。再多起几个SlaveActor，会将消息转发到新的actor中去，这就是Group比Pool方式好的地方，可以动态变化。

此时，你可以尝试修改下配置，将slaveActor变成和masterActor一样的role，再运行后，你会发现有消息丢失，以及转发失败的日志出来。

这是因为在上面所有的例子中，为了方便理解，都是使用一个master+若干slave的方式来演示。
然而Akka的设计是Peer-to-Peer的，即所有节点对等，那么，RouterActor就会理所应当地认为在相同role的节点上都存在Routee，由于并没有去检查Routee是否能工作，直接进行了消息转发，而按照上面的写法masterAcotr所在的节点上压根就没起过slaveActor，所以就造成了消息丢失。
将配置中allow-local-routees改为off，这时它就不会把masterActor所在节点加到负载列表中去了。但同样的，你可以去起一个空的ActorSystem，看看有什么后果。

附录：

Akka提供的路由算法：

本章代码地址：https://github.com/EdisonXu/akka-start-demo/tree/master/cluster

集群后台接入

对外

我们知道，目前集群后台的使用方式主要有以下几种：

• 后端直接监听指定协议的网络端口，接受外部请求，处理后按指定协议打包后返回响应。常规用法比如实现RESTful的SpringMVC，使用ProtoclBuffer、thrift等做压缩协议由Netty监听等等。
• 由集群提供客户端API，通过客户端向集群提交请求，可同步/异步的获得结果。
• 消息队列，通过异步的将消息发送到消息队列，集群监听消息队列获取消息后进行处理，最终将结果反馈到其他消息队列。
• 监听流，比如对目录下文件的监听处理，或基于流式消息队列的监听处理等。

Akka提供了以下几个组件以满足这几种不同的调用方式：

• Akka Http监听HTTP端口对外响应。 注意，这不是一个我们常见类似于SpringMVC的web服务框架，更多的是一个类似于HttpClient一样进行HTTP通信的工具集，但是是基于Actor和ActorStream的。
• Cluster Client 是Akka Cluster提供的远程客户端，用以向集群提交请求并获得结果。
• Akka Stream 提供了完整的IO流及流式处理的工具集和API。
• Alpakaa Akka提供的整合Kafka的流式处理API。

对内

集群内部调用，一般有以下几种方式：

• 查找目标，直接调用。由前文可知，Akka Cluster是完全的P2P结构，所以集群种任何一个Actor可以随意去请求任何的其他Actor，只需要简单的指定其ActorPath即可。
• 发布/订阅模式。akka.cluster.pubsub.DistributedPubSubMediator可不使用外部MQ的情况下，直接在集群内部提供点对点或订阅功能。

由于官方的样例中已经提供了比较好的学习代码，本章就不再自己写代码去演示了。
官方在github例子地址：akka-samples
对于Cluster，在akka-sample-cluster-java提供了4个例子:

• simple: 主要演示cluster启动过程中节点的交互过程，对应的是我上一篇文章
• transformation： 最基本的cluster应用，典型的master-worker模式
• stats： 主要演示cluster中路由的应用
• factorial： 主要演示cluster中负载均衡的使用

最简单的例子

通常来讲，使用分布式集群的应用，大概率是并发请求量大，单请求处理较为耗时，可改为并行处理提高响应速度的，而常见的就是master-slave模式，即master接受外部请求、分配任务及返回响应，而真正的处理过程是交给slave去异步做的。所以，在这种集群应用中，不同的节点会分饰不同的角色。

第一个例子：

• 集群分为前端和后端两部分
• frontend维护了n个backend，并定期向backend发送hello[n]的消息，比如hello1,hello2
• backend将字母转换为大写，返回给frontend

由于比较简单，完整的代码我就不贴了，只看几个关键点

前端

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

public class TransformationFrontend extends AbstractActor {

  List<ActorRef> backends = new ArrayList<>();
  int jobCounter = 0;

  @Override
  public Receive createReceive() {
    return receiveBuilder()
      .match(TransformationJob.class, job -> backends.isEmpty(), job -> {
        sender().tell(new JobFailed("Service unavailable, try again later", job),
          sender());
      })
      .match(TransformationJob.class, job -> {
        jobCounter++;
        backends.get(jobCounter % backends.size())
          .forward(job, getContext());
      })
      .matchEquals(BACKEND_REGISTRATION, message -> {
        getContext().watch(sender());
        backends.add(sender());
      })
      .match(Terminated.class, terminated -> {
        backends.remove(terminated.getActor());
      })
      .build();
  }
}

前端维护了一个backend的ActorRef的列表，在收到自定义的BACKEND_REGISTRATION事件后，将消息的发送者，即Backend的actor所对应的ActorRef放到该列表去。
TransformationJob是外部提交的任务，如果列表为空时，会返回JobFailed，否则用简单的负载均衡方法将Job转发给对应的后端(当前已收到的job数量对后端数取余)。
由于只有一个Frontend，并且Actor内部有mailbox队列，所以这里的jobCounter不会出现并发问题。

后端

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

public class TransformationBackend extends AbstractActor {
    
  Cluster cluster = Cluster.get(getContext().system());
  LoggingAdapter log = Logging.getLogger(getContext().system(), this);

  //subscribe to cluster changes, MemberUp
  @Override
  public void preStart() {
    cluster.subscribe(self(), MemberUp.class);
  }

  //re-subscribe when restart
  @Override
  public void postStop() {
    cluster.unsubscribe(self());
  }
    
  @Override
  public Receive createReceive() {
    return receiveBuilder()
      .match(TransformationJob.class, job -> {
        sender().tell(new TransformationResult(self().path().toSerializationFormat(), job.getText().toUpperCase()),
          self());
      })
      .match(CurrentClusterState.class, state -> {
        for (Member member : state.getMembers()) {
          if (member.status().equals(MemberStatus.up())) {
            register(member);
          }
        }
      })
      .match(MemberUp.class, mUp -> {
        register(mUp.member());
      })
      .build();
  }

  void register(Member member) {
    if (member.hasRole("frontend")) {
      log.info("Trying to register myself: {}", self().path().toSerializationFormat());
      getContext().actorSelection(member.address() + "/user/frontend").tell(
              BACKEND_REGISTRATION, self());
    }
  }
}

后端在prestart()时去监听了MemberUp的事件，当收到MemberUp时，通过简单的判断当前Member的角色是frontend就尝试给frontend发送注册消息，把自己的ActorRef加到frontend所维护的列表中。
这里为了体现是哪个后端所做的job，我加上了相关日志，在运行时可以仔细观察以下。
这里有个小问题不妨思考下：如果前端此时并未启动，这个BACKEND_REGISTRATION会怎么样呢？

启动

前端的启动

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

public static void main(String[] args) {
    // Override the configuration of the port when specified as program argument
    final String port = args.length > 0 ? args[0] : "0";
    final Config config = 
      ConfigFactory.parseString(
          "akka.remote.netty.tcp.port=" + port + "\n" +
          "akka.remote.artery.canonical.port=" + port)
      .withFallback(ConfigFactory.parseString("akka.cluster.roles = [frontend]"))
      .withFallback(ConfigFactory.load());

    ActorSystem system = ActorSystem.create("ClusterSystem", config);

    final ActorRef frontend = system.actorOf(
        Props.create(TransformationFrontend.class), "frontend");
    final FiniteDuration interval = Duration.create(2, TimeUnit.SECONDS);
    final Timeout timeout = new Timeout(Duration.create(5, TimeUnit.SECONDS));
    final ExecutionContext ec = system.dispatcher();
    final AtomicInteger counter = new AtomicInteger();
    system.scheduler().schedule(interval, interval, new Runnable() {
      public void run() {
        ask(frontend,
            new TransformationJob("hello-" + counter.incrementAndGet()),
            timeout).onSuccess(new OnSuccess<Object>() {
          public void onSuccess(Object result) {
            System.out.println(result);
          }
        }, ec);
      }

    }, ec);

  }

• 通过akka.cluster.roles来给当前所起的节点进行角色指定。指定的角色信息会带到系统的Member类中去
• 通过定时器，定时给前端actor发送Job

后端的启动我就不贴了，简单的读取application.conf，覆盖端口配置和角色，然后启动ActorSystem去创建actor。

前面的那个问题：“如果前端此时并未启动，这个BACKEND_REGISTRATION会怎么样呢？”
在官方提供的代码中，TransformationApp这个类整合了前后端节点的启动，但是它把后端分配为2551和2552端口，即把两个后端作为了种子节点，而前端作为了普通节点。如果是像它这样放在一起启动倒也没什么，但是如果单独一个个去运行时，就可能会出现前端在等待集群创建，而后端在memberup时，并没有找到前端Actor，导致注册失败。因为除非Cluster发生变化导致重新Gossip改变节点状态，否则MemberUp事件不会再发，这时哪怕前端启动了，其维护的后端列表依然为空。所以，一般情况下，像这种master-slave的用法，最好master就作为种子节点。

可以看到这样去实现master-slave虽然可以，但是依然存在些问题。好在Akka已经提供好了解决方案，就是Router和Routee，我们下章继续。

注意！
如果在配置文件中是否启用artery，actor的地址会有不同，关闭artery时一定要指定协议为akk.tcp!
比如在配置文件中定义种子节点时：

• artery enabled = on
  seed-nodes = [“akka://ClusterSystem@127.0.0.1:2551”]
• artery enabled = off
  seed-nodes = [“akka.tcp://ClusterSystem@127.0.0.1:2551”]
  同时，启用artery在win10上调试还遇到一个问题，它会将logbuffer临时文件写到windows的\Users\<user_name>\AppData\Local\Temp下，正常我们在编辑器里运行调试完毕，会习惯性直接关闭，这时这些临时文件是不会被删除的。结果就是不断的启停后磁盘会被写满。
  解决的方案有两个：
  1. 关闭artery，使用netty tcp；
  2. 通过命令优雅的关闭ActorSystem

集群的监控

Akka对于集群的监控方式有两种：

1. 内置的JMX
2. 对外提供HTTP API

其中内置的JMX将会慢慢被取消掉，而且在使用时还要求每个JVM启动时加上JMX的接口参数，使用不太方便，同时所提供的jmx-client工具在windows下是无法正常使用的，所以不推荐使用。
官方推荐使用对外提供HTTP接口的Akka Management。它是所有其他管理模块核心，其他管理模块都是基于它做的插件。相关关系如下图：

我们要使用的是Cluster Http Management，开启比较简单：

1. 添加依赖

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

<dependency>
            <groupId>com.lightbend.akka.management</groupId>
            <artifactId>akka-management-cluster-http_2.12</artifactId>
            <version>0.19.0</version>
            <exclusions>
                <exclusion>
                    <groupId>com.typesafe.akka</groupId>
                    <artifactId>akka-actor_2.12</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>com.typesafe.akka</groupId>
                    <artifactId>akka-testkit_2.12</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>com.typesafe.akka</groupId>
                    <artifactId>akka-cluster_2.12</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>com.typesafe.akka</groupId>
                    <artifactId>akka-cluster-tools_2.12</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>com.typesafe.akka</groupId>
                    <artifactId>akka-distributed-data_2.12</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>com.typesafe.akka</groupId>
                    <artifactId>akka-cluster-sharding_2.12</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>com.typesafe.akka</groupId>
                    <artifactId>akka-stream_2.12</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

这里之所以把其他的akka包都exclude掉，是因为我使用的akka包是2.5.17，而这个管理包依赖目前对应的这些包版本还是2.5.15，没有更新过来，不过不影响使用。

2. 配置文件中配置监听地址和端口(可选)

   1 2 3 4 5 6 7 8

   management { http { hostname = "127.0.0.1" port = "8558" bind-hostname = "0.0.0.0" bind-port = "8558" } }

这一步是可选的，如果不配置，默认监听的是调用InetAddress.getLocalHost.getHostAddress这段代码返回的IP，未必是127.0.0.1，一般是当前电脑的对外IP。如果使用docker，那么就必须要显式指定一下了。
默认端口是8558.

3. 开启监控

   1 2	ClusterHttpManagement httpManagement = ClusterHttpManagement.get(system); AkkaManagement.get(system).start();

启动后，我们就可以从http://127.0.0.1:8558这个地址获取集群信息并发送集群指令了。

更详细使用请参考官方文档

Akka Cluster将多个JVM连接整合在一起，实现消息地址的透明化和统一化使用管理，集成一体化的消息驱动系统。最终目的是将一个大型程序分割成若干子程序，部署到很多JVM上去实现程序的分布式并行运算（单机也可以起很多节点构成集群）。更重要的是, Akka Cluster集群构建与Actor编程没有直接的联系，集群构建是在ActorSystem层面上，实现了Actor消息地址的透明化，无需考虑目标运行环节是否分布式，可以按照正常的Actor编程模式进行开发。

我们知道，分布式集群是由若干节点组成的，那么节点的发现及状态管理是分布式系统一个比较重要的任务。Akka Cluster中将节点的生命周期划分为：

• joining - 当尝试加入集群时的初始状态
• up - 加入集群后的正常状态
• leaving / exiting - 节点退出集群时的中间状态
• down - 集群无法感知某节点后，将其标记为down
• removed - 从集群中被删除，以后也无法再加入集群

其实当参数akka.cluster.allow-weakly-up-members启用时(默认是启用的)，还有个weakly up，它是用于集群出现分裂时，集群无法收敛，则leader无法将状态置为up的临时状态。这个后面再解释。
图中还有两个特殊的名词：

• fd* - 这个表示akka的错误检测机制Faiulre Detector被触发后，将节点标记为unreachable
• unreachable* - unreachable不是一个真正的节点状态，更多的像是一个flag，用来描述集群无法与该节点进行通讯。当错误检测机制侦测到这个节点又能正常通讯时，会移除这个flag。

市面上大多数产品的分布式管理一般用的是注册中心机制，例如zk、consul或etcd。其实是节点把自己的信息注册到所使用的注册中心里，而master通过接受注册中心的通知得知新节点信息。显然本质上是一种master/slave的架构。这种架构有两个问题：

1. master节点一般是单一的，一旦挂了影响就比较大（所以很多master都采用了HA机制），也就是所谓的系统单点故障；

2. 通常节点的地址发现是要走master去获取的，当系统并发大时，master节点就可能成为性能瓶颈，即单点性能瓶颈。

Akka可能就是考虑这两点，采用了P2P的模式，这样任何一个节点都可以作为”master”，任何的节点都可以用来寻找其他节点地址。那它是怎么做到的呢？答案是Gossip协议和CRDT。

Akka Gossip

基本介绍

Gossip协议

Gossip协议简单来说，就是病毒式的将信息扩散到整个集群，无法确定何时完成完全扩散，但最终是会到达完全扩散状态的（最终一致性），即收敛。具体介绍可以参考我转载的一片文章——P2P 网络核心技术：Gossip 协议，这里就不再重复叙述，着重介绍下Akka是怎么使用Gossip的。

CRDT

P2P的分布式系统中，理论上每个节点都能处理外部的请求，以及向其他节点发送请求。而系统中存在的共享变量，可能在同一时间会被两个不同节点的请求用到，即并发安全问题。一般解决方案是队列或自旋，后者本质上还是一种变相的队列。排队就牵扯到两个问题：

1. “谁先来的”

很多人下意识会觉得用时间戳就可以了嘛，但在分布式集群中，每个节点如果是一台单独的服务器，那么每个节点的时间戳未必相同（比如未开启Ntp）。

2. “同时来的怎么办”

就像git，能merge就merge，不能merge就解决冲突。

CRDT就是用于解决解决分布式事件的先后顺序及merge问题的数据结构的简称，即Conflict-Free Replicated Data Types的缩写，它的作用是保证最终一致性，出处参阅这份论文。白话文 谈谈CRDT 和CRDT介绍这两篇文章讲的通俗易懂，多的就不再重复了。
Akka中节点的状态就是一个特殊的CRDT，使用向量时钟Vector Clock实现方案，关于向量时钟Vector Clock可以参见我转发的这篇文章Vector Clock/Version Clock。

Akka的gossip协议发送的具体内容如下：

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

final case class Gossip(
  members:    immutable.SortedSet[Member], // sorted set of members with their status, sorted by address
  overview:   GossipOverview                       = GossipOverview(),
  version:    VectorClock                          = VectorClock(), // vector clock version
  tombstones: Map[UniqueAddress, Gossip.Timestamp] = Map.empty
)
final case class GossipOverview(
  seen:         Set[UniqueAddress] = Set.empty,
  reachability: Reachability       = Reachability.empty
)
class Reachability private (
  val records:  immutable.IndexedSeq[Reachability.Record],
  val versions: Map[UniqueAddress, Long]
)

• members 存放该节点知道的其他节点
• seen 已经收到本次gossip的节点们，每个节点当接受到一个新的gossip消息时，会把自己放到seen里面，作为响应返回给发送者
• reachability 这个由错误检测机制Faiulre Detector的心跳模块来维护，用来判断节点是否存活。正常情况下records应该是空的，当有节点处于Unreachable时，才会有记录加到records里。
• version 向量时钟，用于冲突检测和处理

种子节点 SeedNode

SeendNode一般是提前配置好的一组节点。它用于接受其他节点（可以是种子节点）的加入集群的请求。不同节点，在Akka Cluster中启动时会有不同的逻辑：

• 如果是种子节点，并且是排序后的种子节点数组中排第一的，它会在一个规定的时间内(默认5秒)去尝试加入已存在的集群，即发送InitJoin消息到其他种子节点。如果未能成功加入，则自己将创建一个新的Cluster。
• 如果是种子节点，但并不是数组中排第一的，则会向其他种子节点发送InitJoin消息，如果失败将不断重试，直到能成功加入第一个返回响应的已加入集群的种子节点对应的Cluster。
• 如果是普通节点，则会向其他种子节点发送InitJoin消息，如果失败将不断重试，直到能成功加入第一个返回响应的已加入集群的种子节点对应的Cluster。

这里有一点值得注意，为什么是加入第一个返回响应的种子节点所在的集群？这个问题后面再解释。

过程详解

下面用一个简单的场景来解释整个交互过程，假定我们有两个节点n1和n2，其中n1是种子节点。我们让n2先启动。

上图中的T0、T1表示时间轴，但只是为了方便将步骤拆解，便于理解。其中T4和T5并没有必然的时间前后关系，这里只是假定T4在前，步骤基本是类似的，T5在前也只是稍有不同。

#T0、T1时刻只是为了表明n2在启动时，如果没有种子节点响应，则会一直等待重试

#T2时刻种子节点自己新建一个集群，由于新集群只有它自己，members和seen是一样的，所以把自己作为集群的leader。

leader

• Gossip协议中没有leader选举过程
• leader只是一个角色，任何节点均可以是leader
• leader的确定非常简单：集群收敛后，当前members队列按IP进行排序，排第一位置的节点就是整个集群的leader
• leader并非一直不变，如果集群有新节点加入或某节点退出，导致发生Gossip过程，收敛后都会重新确定leader
• leader的职责是更新节点在集群中的状态以及将集群的成员移入或移出集群

注意，这里有个地方容易被误解：“n1和n2构成一个集群，不是在T5才收敛吗？怎么在T2就确定leader了？”
其实当第一个种子节点新建cluster时，由于只有它一个，即seen和members里内容一样，它判断当前集群已收敛，就把自己当作leader了。所以才有了T2_2和T4。

#T3时刻是n1响应n2的InitJoin请求，具体交互过程如下：

#T3_0种子节点收到n2的Join消息后，会做两件事：

1. 更新当前Gossip的向量时钟；
2. 清空当前Gossip的seen队列，然后把自己加进去。（后续发起Gossip交互时，会优先选择那些没在seen队列中的成员）

#T4时刻因为作为fd能正常与n2进行心跳，n1作为leader就被通知将n2提升为Up状态

#T5时刻是一个CRDT的对比过程，对比两个Goissp的version，即VectorClock，比较的结果有三种：

• Same: 相同，则进行seen队列合并就可以了
• Before: 本地新，则向对端发送本地的Gossip，本地不变
• After: 对端新，则更新本地的Gossip。如果对端的Gossip的seen里没有包含本地，则将自己添加到seen里发送给对端，以减少一次两者间的Gossip交互。

#T5时刻最后集群达到了收敛

Gossip 收敛

从上面的图里可以看到节点初始化时会把自己加入到members里，回传回去，同时，节点在收到新的Gossip时，会把自己加入到seen里面。那么，在一开始，members和seen中的节点数是不同的。
当Gossip传递的消息被整个集群都消化掉的时候，可以称作当前集群的Gossip收敛。靠以下条件判断Gossip收敛：

• 集群中不存在unreachable的节点，或者unreachable的节点应该均处于down或exiting状态
• 正常节点均处于up或leaving状态，且members里的节点都在seen里，即集群中所有的节点都收到过该Gossip

代码演示

说了那么多文字，Akka Cluster提供了监控ClusterEvent的方法，我们可以用代码来校验下上面的知识。
添加依赖

1
2
3
4
5

<dependency>
    <groupId>com.typesafe.akka</groupId>
    <artifactId>akka-cluster_2.12</artifactId>
    <version>2.5.17</version>
</dependency>

首先编写application.conf配置文件

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

akka {
  actor {
    provider = "cluster"
  }
  remote {
    netty.tcp {
      hostname = "127.0.0.1"
      port = 0
    }
    artery {
      enabled = on
      canonical.hostname = "127.0.0.1"
      canonical.port = 0
    }
  }

  cluster {
    seed-nodes = [
      "akka://ClusterSystem@127.0.0.1:2552",
      "akka://ClusterSystem@127.0.0.1:2551"
    ]
  }
}

然后，编写Actor

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

public class SimpleClusterListener extends AbstractActor {

    LoggingAdapter log = Logging.getLogger(getContext().system(), this);
    Cluster cluster = Cluster.get(getContext().system());

    //subscribe to cluster changes


    @Override
    public void preStart() throws Exception {
        cluster.subscribe(self(), ClusterEvent.initialStateAsEvents(), ClusterEvent.MemberEvent.class, ClusterEvent.UnreachableMember.class);
        log.info("I'm about to start! Code: {} ", getSelf().hashCode());
    }

    @Override
    public void postStop() throws Exception {
        cluster.unsubscribe(self());
    }

    @Override
    public Receive createReceive() {
        return receiveBuilder()
                .match(ClusterEvent.MemberUp.class, mUp->log.info("Member is Up: {}", mUp.member()))
                .match(ClusterEvent.UnreachableMember.class, mUnreachable->log.info("Member detected as unreachable: {}", mUnreachable.member()))
                .match(ClusterEvent.MemberRemoved.class, mRemoved->log.info("Member is Removed: {}", mRemoved.member()))
                .match(ClusterEvent.LeaderChanged.class, msg->log.info("Leader is changed: {}", msg.getLeader()))
                .match(ClusterEvent.RoleLeaderChanged.class, msg->log.info("RoleLeader is changed: {}", msg.getLeader()))
                .match(ClusterEvent.MemberEvent.class, event->{}) //ignore
                .build();
    }
}

最后是启动类

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

public class App 
{
    public static void main( String[] args )
    {
        if(args.length==0)
            startup(new String[] {"2551", "2552", "0"});
        else
            startup(args);
    }

    public static void startup(String[] ports){
        ExecutorService pool = Executors.newFixedThreadPool(ports.length);
        for(String port : ports){
            pool.submit(()->{
            // Using input port to start multiple instances
                Config config = ConfigFactory.parseString(
                        "akka.remote.netty.tcp.port=" + port + "\n" +
                                "akka.remote.artery.canonical.port=" + port)
                        .withFallback(ConfigFactory.load());

                // Create an Akka system
                ActorSystem system = ActorSystem.create("ClusterSystem", config);

                // Create an
                system.actorOf(Props.create(SimpleClusterListener.class), "ClusterListener");
            });
        }
    }
}

这里设置了2552和2551两个种子节点，及一个随机端口启动的普通节点。故意在配置中把2552放到2551前面去。
带参数2551作为端口启动程序，命名为Node1，启动后，可以看到它会不断尝试连接提供的种子节点中排第一的2552

1
2

[WARN] [11/07/2018 17:15:13.823] [ClusterSystem-akka.actor.default-dispatcher-5] [akka://ClusterSystem@127.0.0.1:2551/system/cluster/core/daemon/joinSeedNodeProcess-1] Couldn't join seed nodes after [2] attempts, will try again. seed-nodes=[akka://ClusterSystem@127.0.0.1:2552]
[WARN] [11/07/2018 17:15:18.835] [ClusterSystem-akka.actor.default-dispatcher-10] [akka://ClusterSystem@127.0.0.1:2551/system/cluster/core/daemon/joinSeedNodeProcess-1] Couldn't join seed nodes after [3] attempts, will try again. seed-nodes=[akka://ClusterSystem@127.0.0.1:2552]

这时带参数2552启动程序，命名为Node2，命令行会打印

1
2
3
4
5
6
7
8
9
10

[INFO] [11/07/2018 17:18:21.285] [ClusterSystem-akka.actor.default-dispatcher-10] [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka://ClusterSystem@127.0.0.1:2552] - Node [akka://ClusterSystem@127.0.0.1:2552] is JOINING itself (with roles [dc-default]) and forming new cluster
[INFO] [11/07/2018 17:18:21.288] [ClusterSystem-akka.actor.default-dispatcher-10] [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka://ClusterSystem@127.0.0.1:2552] - Cluster Node [akka://ClusterSystem@127.0.0.1:2552] dc [default] is the new leader
[INFO] [11/07/2018 17:18:21.300] [ClusterSystem-akka.actor.default-dispatcher-10] [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka://ClusterSystem@127.0.0.1:2552] - Leader is moving node [akka://ClusterSystem@127.0.0.1:2552] to [Up]
[INFO] [11/07/2018 17:18:21.308] [ClusterSystem-akka.actor.default-dispatcher-11] [akka://ClusterSystem/user/ClusterListener] Member is Up: Member(address = akka://ClusterSystem@127.0.0.1:2552, status = Up)
[INFO] [11/07/2018 17:18:23.323] [ClusterSystem-akka.actor.default-dispatcher-10] [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka://ClusterSystem@127.0.0.1:2552] - Received InitJoin message from [Actor[akka://ClusterSystem@127.0.0.1:2551/system/cluster/core/daemon/joinSeedNodeProcess-1#1739420295]] to [akka://ClusterSystem@127.0.0.1:2552]
[INFO] [11/07/2018 17:18:23.323] [ClusterSystem-akka.actor.default-dispatcher-10] [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka://ClusterSystem@127.0.0.1:2552] - Sending InitJoinAck message from node [akka://ClusterSystem@127.0.0.1:2552] to [Actor[akka://ClusterSystem@127.0.0.1:2551/system/cluster/core/daemon/joinSeedNodeProcess-1#1739420295]] (version [2.5.17])
[INFO] [11/07/2018 17:18:23.549] [ClusterSystem-akka.actor.default-dispatcher-10] [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka://ClusterSystem@127.0.0.1:2552] - Node [akka://ClusterSystem@127.0.0.1:2551] is JOINING, roles [dc-default]
[INFO] [11/07/2018 17:18:24.236] [ClusterSystem-akka.actor.default-dispatcher-4] [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka://ClusterSystem@127.0.0.1:2552] - Leader is moving node [akka://ClusterSystem@127.0.0.1:2551] to [Up]
[INFO] [11/07/2018 17:18:24.237] [ClusterSystem-akka.actor.default-dispatcher-12] [akka://ClusterSystem/user/ClusterListener] Member is Up: Member(address = akka://ClusterSystem@127.0.0.1:2551, status = Up)
[INFO] [11/07/2018 17:18:25.235] [ClusterSystem-akka.actor.default-dispatcher-11] [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka://ClusterSystem@127.0.0.1:2552] - Cluster Node [akka://ClusterSystem@127.0.0.1:2552] dc [default] is no longer the leader

Node [akka://ClusterSystem@127.0.0.1:2552] is JOINING itself (with roles [dc-default]) and forming new cluster 说明作为排第一的种子节点，它创建了集群并把自己加了进去。
Cluster Node [akka://ClusterSystem@127.0.0.1:2552] dc [default] is the new leader 说明2552变成了leader。
Node [akka://ClusterSystem@127.0.0.1:2551] is JOINING, roles [dc-default] 2551在尝试加入集群
Leader is moving node [akka://ClusterSystem@127.0.0.1:2551] to [Up] 2551成功加入了集群，状态变为Up
Cluster Node [akka://ClusterSystem@127.0.0.1:2552] dc [default] is no longer the leader 集群变化导致新一轮Goissp收敛后，leader重新选取，2551的IP比2552小，被选为新的leader。
可以从Node1的命令行看到证据：

1

[INFO] [11/07/2018 17:18:25.755] [ClusterSystem-akka.actor.default-dispatcher-9] [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka://ClusterSystem@127.0.0.1:2551] - Cluster Node [akka://ClusterSystem@127.0.0.1:2551] dc [default] is the new leader

我们再起一个参数为2900的，命名为Node3，等到正常启动，三个Node状态都为Up。

• 2552是集群的创建者
• 2551是集群的leader

此时，我们把2552重启，会看到2551的命令行中出现Leader is removing unreachable node [akka://ClusterSystem@127.0.0.1:2552]，等2552完全启动时，可以看到Welcome from [akka://ClusterSystem@127.0.0.1:2551]说明2552向2551发送的加入集群的消息，2551给它发送了Welcome消息。2552不再自己创建新的集群。有兴趣的可以在关闭2552的情况下重启node3.

进阶

其实本来这部分应该放在上面，但是一上来讲理论非常不好消化，至少我个人是如此。所以，我宁愿把好理解的交互步骤放前面，把一些知识点穿插在里面，最后再把无法放进去的干巴巴的理论放最后。

Akka对于Gossip的优化

• 如果gossiper(gossip的发送者)和recipient(goissp的接收者)拥有相同版本的Gossip(recipient已包含在seen列表里，并且version也与gossiper的完全一致)，这时Gossip的状态不用再发回给gossiper，减少交互。
• akka使用的是push-pull类型gossip的变种，它每次发送的是一个digest值，而非真正的value，recipient收到后先比较版本，只有当它的版本较低时，才会去向gossiper请求真正的值。
• 默认情况下，集群每1秒进行一次gossip，但如果seen里的节点数少于整个集群1/2，则集群每秒钟会进行3轮gossip，以加速收敛。
• 在未收敛时，gossiper在选择目标节点时是随机的但带有偏向性(biased gossip)。gossiper会选择在当前版本下不在seen里的节点去交换gossip，并且选择的比例系数较高(经验值400个节点下配置为0.8)。该系数会随着轮数增加而减少，以防止单节点同时间收到过多的gossip请求。recipient对于gossip请求也是放到mailbox里的，在mailbox队列较长时，会移除较早的请求。
• 当收敛后，目标节点的选择就完全是随机的了，而且只发送非常小的gossip状态的消息。一旦集群发生变化，就会回到上一条所述的带有偏向性的biased gossip。

Failure Detector机制

• 职责是定期检查集群中节点是否可用
• 是The Phi Accrual Failure Detector的实现，是一种解耦了观察与行为的增量式错误检测器。它不会简单的判断节点是否可用，而是通过收集各种数据计算出phi值，通过与设定好的threshold进行对比，判断是否出现错误。
• 每个节点会根据集群节点的hash有序环确定临近的几个节点进行监控（默认是5个），方便跨机房进行监控，保证集群节点的全覆盖。目标节点每1秒向这些节点发送心跳。
• 只要有一个monitor认为某节点是unreachable状态，那么该节点就会被集群认为是unreachable
• 被标记为unreachable的节点，只有在所有的monitor都认为它是reachable时，它才会被重新认为是reachable，leader会重新改变它的状态

网络分区与集群分区

当网络出现异常，比如一个跨两地机房的集群，机房间的网络断了。这时：

• 原创建集群的种子节点所在的集群，会重新发起biased gossip，直至收敛，确认新的leader，被隔开的那部分节点会被认为是unreachable而最终被踢掉
• 被隔开的那部分节点，会重新发起biased gossip，其中排序在最前面的种子节点会创建一个新的集群，并产生新的leader。原集群中的那部分失联节点会被认为是unreachable而最终被从新集群踢掉
• 两个集群最终都恢复正常能对外提供服务，即原来的一个集群在无人干涉的情况下，分裂成了两个集群
• 当网络恢复后，两个集群会重新发起biased gossip，尝试融合，恢复成一个大集群。

总结

由此可见，从设计上来说，Akka Cluster是完全去中心化，无单点故障和单点性能瓶颈的，具有天然的分布式容错性和可扩容性。

本文参考：
Akka Cluster Specification
Akka的Cluster源码分析
Akka Cluster原理及实战
Akka Cluster Implementation Notes
Akka 源码分析-Cluseter-ActorSystem

Gossip protocol 也叫 Epidemic Protocol （流行病协议），实际上它还有很多别名，比如：“流言算法”、“疫情传播算法”等。

这个协议的作用就像其名字表示的意思一样，非常容易理解，它的方式其实在我们日常生活中也很常见，比如电脑病毒的传播，森林大火，细胞扩散等等。

Gossip protocol 最早是在 1987 年发表在 ACM 上的论文 《Epidemic Algorithms for Replicated Database Maintenance》中被提出。主要用在分布式数据库系统中各个副本节点同步数据之用，这种场景的一个最大特点就是组成的网络的节点都是对等节点，是非结构化网络，这区别与之前介绍的用于结构化网络中的 DHT 算法 Kadmelia。

我们知道，很多知名的 P2P 网络或区块链项目，比如 IPFS，Ethereum 等，都使用了 Kadmelia 算法，而大名鼎鼎的 Bitcoin 则是使用了 Gossip 协议来传播交易和区块信息。

实际上，只要仔细分析一下场景就知道，Ethereum 使用 DHT 算法并不是很合理，因为它使用节点保存整个链数据，不像 IPFS 那样分片保存数据，因此 Ethereum 真正适合的协议应该像 Bitcoin 那样，是 Gossip 协议。

这里先简单介绍一下 Gossip 协议的执行过程：

Gossip 过程是由种子节点发起，当一个种子节点有状态需要更新到网络中的其他节点时，它会随机的选择周围几个节点散播消息，收到消息的节点也会重复该过程，直至最终网络中所有的节点都收到了消息。这个过程可能需要一定的时间，由于不能保证某个时刻所有节点都收到消息，但是理论上最终所有节点都会收到消息，因此它是一个最终一致性协议。

Gossip 演示

现在，我们通过一个具体的实例来深入体会一下 Gossip 传播的完整过程

为了表述清楚，我们先做一些前提设定

1、Gossip 是周期性的散播消息，把周期限定为 1 秒

2、被感染节点随机选择 k 个邻接节点（fan-out）散播消息，这里把 fan-out 设置为 3，每次最多往 3 个节点散播。

3、每次散播消息都选择尚未发送过的节点进行散播

4、收到消息的节点不再往发送节点散播，比如 A -> B，那么 B 进行散播的时候，不再发给 A。

这里一共有 16 个节点，节点 1 为初始被感染节点，通过 Gossip 过程，最终所有节点都被感染：

Gossip 的特点（优势）

1）扩展性

网络可以允许节点的任意增加和减少，新增加的节点的状态最终会与其他节点一致。

2）容错

网络中任何节点的宕机和重启都不会影响 Gossip 消息的传播，Gossip 协议具有天然的分布式系统容错特性。

3）去中心化

Gossip 协议不要求任何中心节点，所有节点都可以是对等的，任何一个节点无需知道整个网络状况，只要网络是连通的，任意一个节点就可以把消息散播到全网。

4）一致性收敛

Gossip 协议中的消息会以一传十、十传百一样的指数级速度在网络中快速传播，因此系统状态的不一致可以在很快的时间内收敛到一致。消息传播速度达到了 logN。

5）简单

Gossip 协议的过程极其简单，实现起来几乎没有太多复杂性。

Márk Jelasity 在它的 《Gossip》一书中对其进行了归纳：

Gossip 的缺陷

分布式网络中，没有一种完美的解决方案，Gossip 协议跟其他协议一样，也有一些不可避免的缺陷，主要是两个：

1）消息的延迟

由于 Gossip 协议中，节点只会随机向少数几个节点发送消息，消息最终是通过多个轮次的散播而到达全网的，因此使用 Gossip 协议会造成不可避免的消息延迟。不适合用在对实时性要求较高的场景下。

2）消息冗余

Gossip 协议规定，节点会定期随机选择周围节点发送消息，而收到消息的节点也会重复该步骤，因此就不可避免的存在消息重复发送给同一节点的情况，造成了消息的冗余，同时也增加了收到消息的节点的处理压力。而且，由于是定期发送，因此，即使收到了消息的节点还会反复收到重复消息，加重了消息的冗余。

Gossip 类型

Gossip 有两种类型：

• Anti-Entropy（反熵）：以固定的概率传播所有的数据
• Rumor-Mongering（谣言传播）：仅传播新到达的数据

Anti-Entropy 是 SI model，节点只有两种状态，Suspective 和 Infective，叫做 simple epidemics。

Rumor-Mongering 是 SIR model，节点有三种状态，Suspective，Infective 和 Removed，叫做 complex epidemics。

其实，Anti-entropy 反熵是一个很奇怪的名词，之所以定义成这样，Jelasity 进行了解释，因为 entropy 是指混乱程度（disorder），而在这种模式下可以消除不同节点中数据的 disorder，因此 Anti-entropy 就是 anti-disorder。换句话说，它可以提高系统中节点之间的 similarity。

在 SI model 下，一个节点会把所有的数据都跟其他节点共享，以便消除节点之间数据的任何不一致，它可以保证最终、完全的一致。

由于在 SI model 下消息会不断反复的交换，因此消息数量是非常庞大的，无限制的（unbounded），这对一个系统来说是一个巨大的开销。

但是在 Rumor Mongering（SIR Model） 模型下，消息可以发送得更频繁，因为消息只包含最新 update，体积更小。而且，一个 Rumor 消息在某个时间点之后会被标记为 removed，并且不再被传播，因此，SIR model 下，系统有一定的概率会不一致。

而由于，SIR Model 下某个时间点之后消息不再传播，因此消息是有限的，系统开销小。

Gossip 中的通信模式

在 Gossip 协议下，网络中两个节点之间有三种通信方式:

• Push: 节点 A 将数据 (key,value,version) 及对应的版本号推送给 B 节点，B 节点更新 A 中比自己新的数据
• Pull：A 仅将数据 key, version 推送给 B，B 将本地比 A 新的数据（Key, value, version）推送给 A，A 更新本地
• Push/Pull：与 Pull 类似，只是多了一步，A 再将本地比 B 新的数据推送给 B，B 则更新本地

如果把两个节点数据同步一次定义为一个周期，则在一个周期内，Push 需通信 1 次，Pull 需 2 次，Push/Pull 则需 3 次。虽然消息数增加了，但从效果上来讲，Push/Pull 最好，理论上一个周期内可以使两个节点完全一致。直观上，Push/Pull 的收敛速度也是最快的。

复杂度分析

对于一个节点数为 N 的网络来说，假设每个 Gossip 周期，新感染的节点都能再感染至少一个新节点，那么 Gossip 协议退化成一个二叉树查找，经过 LogN 个周期之后，感染全网，时间开销是 O(LogN)。由于每个周期，每个节点都会至少发出一次消息，因此，消息复杂度（消息数量 = N * N）是 O(N^2) 。注意，这是 Gossip 理论上最优的收敛速度，但是在实际情况中，最优的收敛速度是很难达到的。

假设某个节点在第 i 个周期被感染的概率为 pi，第 i+1 个周期被感染的概率为 pi+1 ，

1）则 Pull 的方式:

2）Push 方式：

显然 Pull 的收敛速度大于 Push ，而每个节点在每个周期被感染的概率都是固定的 p (0<p<1)，因此 Gossip 算法是基于 p 的平方收敛，也称为概率收敛，这在众多的一致性算法中是非常独特的。

全文完！

研究Akka过程中，发现Akka的node间是Peer-to-Peer的，就意味着任何一个节点都能处理来自外部请求，那就存在一个一致性的问题，即如果集群中两个节点间的通讯断了，但是又都能对外提供服务，这时各自在接受请求造成的状态变化应该如何解决？Akka采用的是Vector Clocks来解决一致性的。这个算法常见于分布式存储上，对于EBA也很常见，所以如果要搞EventSourcing，这个知识可能会被用到。在研究Vector Clocks时发现两篇好文，本文是其中之一，讲的非常白话清晰，算是先讲算法基础概念，后一篇是直接讲算法实现了。另一篇讲简单实现的我就不转了，有兴趣的直接猛击这里跳转。

physical clock

机器上的物理时钟，不同的机器在同一个时间点取到的physical clock不一样，之间会存在一定的误差，NTP可以用来控制这个误差，机器之间的时钟误差可以控制在几十ms以内。两个事件a和b，a在机器M1上physical clock为12点5分0秒6ms发生，b在机器M2上physical clock为12点5分0秒7ms发生，这并不代表a发生在b之前，因为两个机器上取到的physical clock和真实时间(这个时间就是国际标准时间UTC，可以通过原子钟，internet，卫星获得)之间都有误差。比如机器M1的physical clock比真实时间慢10ms，那么事件a实际上是在真实时间12点5分0秒16ms发生的，机器M2的physical clock比真实事件慢5ms，那么事件b的实际上是在真实时间12点5分0秒12ms发生的，显然，事件a发生在事件b之后。

Lamport’s Logical Clock

单机系统容易给发生的所有事件定义一个全局顺序(total order)，但是分布式系统没有全局时钟，很难给所有事件定义一个全局顺序。所以，Lamport定义了一种偏序关系，happens-before，记作 ->

a->b意味着所有的进程都agree事件a发生在事件b之前。

在三种情况下，可以很容易的得到这个关系：

1
2
3
4
5

1. 如果事件a和事件b是同一个进程中的并且事件a发生在事件b前面，那么a->b

2. 如果进程A发送一条消息m给进程B，a代表进程A发送消息m的事件，b代表进程B接收消息m的事件，那么a->b(由于消息的传递需要时间)

3. ->满足传递性，如果a->b AND b->c => a->c

Lamport's Logical Clock算法如下：

1
2
3
4
5
6
7

1. 每个机器本地维护一个logical clock LCi

2. 每个机器本地每发生一个事件设置LCi = LCi + 1，并且把结果作为这个事件的logical clock。

3. 当机器i给机器j发送消息m时，把LCi存在消息里。

4. 当机器j收到消息m时候，LCj = max(LCj, m timestamp)+1，结果值作为收到消息m这个事件的时间戳。

这个算法能够保证a->b，那么a事件的logical clock比b事件的logical clock小。反过来，通过只比较两个事件的logical clock不能得到a和b的先后。

Vector Clock

每个机器维护一个向量VC，也就是Vector Clock，这个向量VC有如下属性：

• VCi[i] 是到目前为止机器i上发生的事件的个数

• VCi[k] 是机器i知道的机器k发生的事件的个数(即机器i对机器j的知识)

每个机器都有一个向量(Vector)，每个向量中的元素都是一个logical clock，所以取名为Vector Clock。

通过如下算法更新Vector Clock

1
2
3

1. 机器i本地发生一个事件时将VCi[i]加1
2. 机器i给机器j发送消息m时，将整个VCi存在消息内
3. 机器j收到消息m时，VCj[k]=max(VCj[k],VCi[k]),同时，VCj[j]+1

可以看出，Vector Clock是一种maintain因果关系(causality)的一种手段，Vector Clock在机器之间传递达到给对方传递自己已有的关于其他机器知识的目的。

Dynamo为什么需要Vector Clock(实际上是Version Clock)

Dynamo是一个分布式Key/Value存储系统，这个Value可以是一行，包含多个列， 为了容错，每个Key/Value保存多副本，通常在不同的机器上，一般是3，后面以3为例。对外是一个最终一致性系统，即客户端A写入一个值返回成功后，在一定的时间内另外一个客户端可能读不到最新的值。通常，成功写入两个副本成功即返回给客户端成功，同时请求会异步的同步到第三个副本。然而，高可用是Dynamo的主要设计目标之一，即使在出现网络分区或者机器宕机时依然可读可写。

假设Key K有三个副本k1,k2,k3分别在M1，M2，M3上。

正常情况
M1处理写请求，M1将请求发往M2，M3，只要有一个返回，即返回客户端成功。

网络分区
如果M1和M2/M3之间网络都不通，k1被更新(持续高可用，依然给客户端返回成功)，随后，其他节点(集群中任意一个节点都可以接客户端请求，并且将请求路由到正确的节点上)路由了写请求给M2(假设其他节点和M1/M3之间网络不通)，k2被更新。这时，k1和k2数据不一样，最后网络恢复，三个副本进行同步时，应该保留哪个版本？如果只保留k2，即采用last write win机制，那么同步后，第一个客户端会发现它写的数据丢了。

这个时候就需要Vector Clock，更确切的说是Version Clock。

为了处理这种场景，Dynamo使用Version Clock来捕获同一个Object的不同版本之间的causality。每个Object的每个版本会有一个相关联的Version Clock, 形如[(serverA,counter),(serverB,counter),…], 通过检查同一个Object不同版本的Version Clock，可以决定是否可以完全丢弃一个版本，仅保留另外一个版本，还是需要将两个版本进行merge。如果Object的版本A的VCA包含的每项(server, counter)在版本B的VCB中都有对应项，并且counter小于等于版本B中对应项的counter(记作VCB descends VCA)，那么这个Object的版本A可以被丢弃，否则需要对两个版本进行merge。

回到刚才的例子，k1被更新，Version Clock(注:此处假设k1/k2/k3三个副本之前一模一样，那么就可以省略之前的Version Clock)为[(M1,1)],k2被更新,Version Clock为[(M2,1)]，随后k1/k2网络通了，他们通过比较两个Version Clock发现两个Version Clock存在冲突，不是descends的关系，那么就两个版本都保留，当客户端来读Key K的时候，两个版本的数据和对应的VC都返回给客户端，由客户端进行冲突合并，客户端进行冲突合并后写入Key K的时候，带着合并后的VC[(M1, 1), [M2, 1]]发到M1/M2，覆盖服务器版本，冲突解决。

可以看出，Vector Clock最初是为了给分布式系统的事件定序发明的，本质上是一种捕获causality的手段，只是他们捕获的是事件的关系。而Version Clock是捕获同一个数据的不同版本之间的causality.

Riak这个系统也使用了Vector Clock来做冲突合并，对Vector Clock的用法可谓比较深入，具体可以看最后两篇参考资料。

参考资料

Dynamo

Scalable and Accurate Causality Tracking for Eventually Consistent Stores

version-vectors-are-not-vector-clocks

Causality Is Expensive

Vector Clocks Revisited

vector-clocks-revisited-part-2-dotted-version-vectors

原文收录在我的 GitHub博客 (https://github.com/jawil/blog) ，喜欢的可以关注最新动态，大家一起多交流学习，共同进步，以学习者的身份写博客，记录点滴。

最近在学习Node.js里面的fs模块，遇到了一个比较诡异的现象，踩到了坑，就是读取当前目录下的一个文件，死活读取不到，由于之前对于Node.js里面的path模块也不太熟悉，也没系统研究过，所以今天就踩了这个坑，记录踩坑的过程，防止以后踩坑和大家也踩坑。

说一下当时的情形：

我纳闷的很半天，我明明就是读取当前目录下的1.findLargest.js，为什么提示找不到这个文件，运行了几遍，死活找不到1.findLargest.js这个文件。

后来才发现是因为运行这个文件不是从当前目录运行了，从图中可以看出，当前的目录是/Users/jawil/Desktop/nodejs/demo/ES6-lottery/syntax/nodejs，而我运行这个脚本的目录是/Users/jawil/Desktop/nodejs/demo/ES6-lottery；这就是问题的所在了。不过为什么运行脚本的位置也会影响这个路径呢，且往下看。

探索

计算机不会欺骗人，一切按照规则执行，说找不到这个文件，那肯定就是真的找不到，至于为什么找不到，那就是因为我们理解有偏差，我最初理解的’./‘是当前执行js文件所在的文件夹的绝对路径，然后Node.js的理解却不是这样的，我们慢慢往下看。

Node.js中的文件路径大概有 __dirname, __filename, process.cwd(), ./ 或者 ../，前三个都是绝对路径，为了便于比较，./ 和 ../ 我们通过 path.resolve('./')来转换为绝对路径。

简单说一下这几个路径的意思:

1
2
3
4

__dirname：    获得当前执行文件所在目录的完整目录名
__filename：   获得当前执行文件的带有完整绝对路径的文件名
process.cwd()：获得当前执行node命令时候的文件夹目录名 
./：           文件所在目录

先看一看我电脑当前的目录结构：

1
2
3
4
5
6
7
8

syntax/
    -nodejs/
        -1.findLargest.js
        -2.path.js
        -3.fs.js
    -regs
        -regx.js
        -test.txt

在 path.js 里面我们写这些代码，看看输出是什么：

1
2
3
4
5

const path = require('path')
console.log('__dirname：', __dirname)
console.log('__filename：', __filename)
console.log('process.cwd()：', process.cwd())
console.log('./：', path.resolve('./'))

在当前目录下也就是nodejs目录运行 node path.js，我们看看输出结果：

1
2
3
4

__dirname：     /Users/jawil/Desktop/nodejs/demo/ES6-lottery/syntax/nodejs
__filename：    /Users/jawil/Desktop/nodejs/demo/ES6-lottery/syntax/nodejs/2.path.js
process.cwd()： /Users/jawil/Desktop/nodejs/demo/ES6-lottery/syntax/nodejs
./：            /Users/jawil/Desktop/nodejs/demo/ES6-lottery/syntax/nodejs

然后在 项目根目录ES6-lottery 目录下运行 node syntax/nodejs/2.path.js，我们再来看看输出结果：

1
2
3
4

__dirname：     /Users/jawil/Desktop/nodejs/demo/ES6-lottery/syntax/nodejs
__filename：    /Users/jawil/Desktop/nodejs/demo/ES6-lottery/syntax/nodejs/2.path.js
process.cwd()： /Users/jawil/Desktop/nodejs/demo/ES6-lottery
./：            /Users/jawil/Desktop/nodejs/demo/ES6-lottery

答案显而易见？我们可以通过上面的例子对比，暂时得出表面的结论：

• __dirname: 总是返回被执行的 js 所在文件夹的绝对路径
• __filename: 总是返回被执行的 js 的绝对路径
• process.cwd(): 总是返回运行 node 命令时所在的文件夹的绝对路径
• ./: 跟 process.cwd() 一样，返回 node 命令时所在的文件夹的绝对路径

但是，我们再来看看这个例子，我们在上面的例子加几句代码，然后：

我们在1.findLargest.js先加这句代码

exports.A = 1;

再来在刚才报错的3.fs.js里面加这两句代码看看：

const test = require(‘./1.findLargest.js’);

console.log(test)

运行node syntax/nodejs/3.fs.js，最后看看结果：

再次疑惑

为什么都是读取./1.findLargest.js文件，一样的路径，为什么require能获取到，而readFile读取不到呢？

于是查了不少资料，看到了一些关于require引入模块的机制，从中学到了不少，也明白了为什么是这样。

我们先了解一下require() 的基本用法：

下面的内容来自require() 源码解读,由阮一峰翻译自《Node使用手册》。

我们从第（2）小条的a部分可以看出：

（2）如果 X 以 "./" 或者 "/" 或者 "../" 开头 　　a. 根据 X 所在的父模块，确定 X 的绝对路径。　　b. 将 X 当成文件，依次查找下面文件，只要其中有一个存在，就返回该文件，不再继续执行。

const test = require('./1.findLargest.js')按照上面规则翻译一遍就是:

1. 根据1.findLargest.js所在的父模块，确定1.findLargest.js的绝对路径为/Users/jawil/Desktop/nodejs/demo/ES6-lottery/syntax/nodejs，关于其中的寻找细节这里不做探讨。

2. 先把1.findLargest.js当成文件，依次查找当前目录下的1.findLargest.js，找到了，就返回该文件，不再继续执行。

根据require的基本规则，对于上面出现的情形也就不足为奇了，更多require的机制和源码解读，请移步：
require() 源码解读。

那么关于 ./ 正确的结论是：
在 require() 中使用是跟 __dirname 的效果相同，不会因为启动脚本的目录不一样而改变，在其他情况下跟 process.cwd() 效果相同，是相对于启动脚本所在目录的路径。

总结：

• __dirname： 获得当前执行文件所在目录的完整目录名
• __filename： 获得当前执行文件的带有完整绝对路径的文件名
• process.cwd()：获得当前执行node命令时候的文件夹目录名
• ./： 不使用require时候，./与process.cwd()一样，使用require时候，与__dirname一样

只有在 require() 时才使用相对路径(./, ../) 的写法，其他地方一律使用绝对路径，如下：

1
2
3
4

// 当前目录下
 path.dirname(__filename) + '/path.js'; 
// 相邻目录下
 path.resolve(__dirname, '../regx/regx.js');

最后看看改过之后的结果，不会报错找不到文件了，不管在哪里执行这个脚本文件，都不会出错了，防止以后踩坑。

所以就萌生了写个nodejs代码去代替人工初始化的想法。

Gitalk安装

总体来说，使用还是比较简单的，具体步骤请参阅官网，这里就不再赘述了。重点讲下配置。
首先，是Github上申请OAuth App的配置

然后，是Gitalk的配置

1
2
3
4
5
6
7
8
9

var gitalk = new Gitalk({
  clientID: 'xxxxxxxxxxxxxx',
  clientSecret: 'xxxxxxxxxxxxxxxx',
  repo: 'GitHub repo',
  owner: 'GitHub repo owner',
  admin: ['GitHub repo owner and collaborators, only these guys can initialize github issues'],
  id: md5(window.location.pathname),      // Ensure uniqueness and length less than 50
  distractionFreeMode: false  // Facebook-like distraction free mode
})

这里，重点有三个地方：

• owenr是Github上的ID。有些人(比如我)，登陆时习惯用邮箱，放这里就不行了。一定得是自己的ID!
• repo，要填的是用来存储评论的Issues所对应的仓库的名字，记住后面不要有.git！
• 配置中的id，是唯一表示当前评论页面的主键。Gitalk用它作为Github Issue的Label，而Github对Label的长度有限制，最多50个字符，所以这里比较好的解决方案是对pathname做MD5，以保证长度和唯一性。
  需要引入md5的js，可以使用JavaScript-MD5.

申请Personal Access Token

GithubAPI对一些接口有调用限制，具体可以查看Rate limiting的解释。对于不同的认证方式，调用限制不同。

Gitalk使用的是Github的OAuth认证，请求时必须要有clientID和clientSecret，这种方式每小时的Rate limiting是60。如果只是发表评论，肯定是够了。
而如果要批量创建所有文章对应的Issue来作为这些文章的评论存储，可能就未必够了。

好在Github提供了另一种认证方式——Personal access token，这种方式每小时的限制高达5000次。所以，第一步就是申请这个token。

从Github的Personal access token页面，点击Generate new token。

创建完成后，获得一个Token。

代码

我用NodeJs写了个简单的批量刷新工具，是基于网站的sitemap的。如果你的网站没有sitemap，可以自行修改。

安装依赖

1
2

npm install sitemapper -S
npm install cheerio -S

NodeJS文件

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
73
74
75
76
77
78
79

var request = require('request');
var Sitemapper = require('sitemapper');
var cheerio = require('cheerio');
var crypto = require('crypto');

// 配置信息
const username = "EdisonXu" //github账号，对应Gitalk配置中的owner
const repo_name = "repo" //用于存储Issue的仓库名，对应Gitalk配置中的repo
const token = "xxxxxxxxxxxxxxxxxxxxxxxxxxx"   //前面申请的personal access token
const sitemap_url = "http://edisonxu.com/sitemap.xml"  // 自己站点的sitemap地址

var base_url = "https://api.github.com/repos/"+ username + "/" + repo_name + "/issues"

var sitemap = new Sitemapper();

sitemap.fetch(sitemap_url)
    .then(function (sites) {
        sites.sites.forEach(function (site, index) {
            if (site.endsWith('404.html')) {
                console.log('跳过404')
                return
            }
            request({
                url: site,
                headers: {
                    'Content-Type': 'application/json;charset=UTF-8'
                }
            }, function (err, resp, bd) {
                if (err || resp.statusCode != 200)
                    return
                const $ = cheerio.load(bd);
                var title = $('title').text();
                var desc = site + "\n\n" + $("meta[name='description']").attr("content");
                var path = site.split(".com")[1]
                var md5 = crypto.createHash('md5');
                var label = md5.update(path).digest('hex')
                var options = {
                    headers: {
                        'Authorization': 'token '+token,
                        'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36',
                        'Accept': 'application/json'
                    },
                    url: base_url+ "?labels="+"Gitalk," + label,
                    method: 'GET'
                }
                // 检查issue是否被初始化过
                request(options, function (error, response, body) {
                    if (error || response.statusCode != 200) {
                        console.log('检查['+site+']对应评论异常')
                        return
                    }
                    var jbody = JSON.parse(body)
                    if(jbody.length>0)
                        return
                    //创建issue
                    var request_body = {"title": title, "labels": ["Gitalk", label], "body": desc}
                    //console.log("创建内容： "+JSON.stringify(request_body));
                    var create_options = {
                        headers: {
                        'Authorization': 'token '+token,
                        'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36',
                        'Accept': 'application/json',
                        'Content-Type': 'application/json;charset=UTF-8'
                        },
                        url: base_url,
                        body: JSON.stringify(request_body),
                        method: 'POST'
                    }
                    request(create_options, function(error, response, body){
                        if (!error && response.statusCode == 201) 
                            console.log("地址: ["+site+"] Gitalk初始化成功")
                    })
                });
            });
        });
    })
    .catch(function (err) {
        console.log(err);
    });

注意
代码里默认将path做了MD5化，如果你的Gitalk配置里没有使用MD5后的值作为ID，这里要相应修改！

Gulp调用

我的博客是Hexo+Gulp，所以我把Gitalk初始化也做到了Gulp里，这样每次写完文章压缩、发布、初始化评论一条龙。用法比较简单：

1
2

var $ = require('gulp-load-plugins')();
gulp.task('init-gitalk', ['deploy'], $.shell.task('node init_gitalk.js'));

最后将init-gitalk的task自己加到你的gulp任务序列去就好了。
由于我博客的配置文件里已经有了username和sitemap地址，另外gitalk配置和上门代码的配置也有部分重复，所以我又添加了读取配置的功能，有需要的自行挑选。

添加依赖

1

npm install js-yaml -S

配置文件中增加

1
2
3
4
5

gitalk:
  githubId: xxx
  repo: xxxxxxxxxx
  owner: xxxxxxxxxxxxx
  token: xxxxxxxxxxxxxx

修改脚本

1
2
3
4
5
6
7
8
9
10
11

var yml = require('js-yaml');
var fs = require('fs');

//读取配置文件
var file = process.cwd()+"\\_config.yml";
var config = yml.safeLoad(fs.readFileSync(file, 'utf8'))

const username = config.gitalk.githubId
const repo_name = config.gitalk.repo
const token = config.gitalk.token
const sitemap_url = config.url+"/"+config.sitemap.path