Spring on 小盒子的技术分享

大模型开发全景图（LLM Deployment Landscape）

Fri, 31 Oct 2025 13:25:17 +0000

以下分组依据开源生态图Open Source LLM Development Landscape进行整理，原图及项目集合参考：https://github.com/antgroup/llm-oss-landscape 每个条目后附上官网/项目页链接，便于你点开了解。

也可以直接打开 https://antoss-landscape.my.canva.site/ （点击图标就可以直接跳转）

AI Agent

AI Coding

●Gemini https://ai.google.dev/gemini

●Continue https://www.continue.dev/

●OpenHands https://github.com/All-Hands-AI/OpenHands

●marimo https://marimo.io/

●Codex CLI https://github.com/microsoft/Codex-CLI

●avante.nvim https://github.com/yetone/avante.nvim

●Cline https://github.com/cline/cline

●codename goose https://block.github.io/goose/

Chatbot & Knowledge Management

●Cherry Studio https://github.com/CherryHQ/cherry-studio

●Open WebUI https://openwebui.com/

●Lobe Chat https://github.com/lobehub/lobe-chat

●LibreChat https://github.com/danny-avila/LibreChat

●AstrBot https://github.com/AstrBotDevs/AstrBot

●SiYuan（思源笔记）https://b3log.org/siyuan/

●Docling https://github.com/DS4SD/docling

●Anything LLM https://github.com/Mintplex-Labs/anything-llm

Embodied Agent

●GENESIS https://genesis-embodied-ai.github.io/

●xiaozhi-esp32 https://github.com/78/xiaozhi-esp32

Agent Workflow Platform

●Dify https://dify.ai/

●n8n https://n8n.io/

●RAGFlow https://github.com/infiniflow/ragflow

●Langflow https://www.langflow.org/

●Mastra https://mastra.ai/

●Activepieces https://www.activepieces.com/

●MaxKB https://github.com/1Panel-dev/MaxKB

●FastGPT https://github.com/labring/FastGPT

●Flowise AI https://flowiseai.com/

Agent Tool / Dev Kit / Protocol

●LiteLLM https://docs.litellm.ai/

●Supabase https://supabase.com/

●Vercel https://vercel.com/

●ComfyUI https://github.com/comfyanonymous/ComfyUI

●mem0 https://mem0.ai/

●Browser Use https://github.com/browser-use/browser-use

●Model Context Protocol https://modelcontextprotocol.io/

Agent Framework

●LangGraph https://langchain-ai.github.io/langgraph/

●Pydantic AI https://ai.pydantic.dev/

●LangChain https://www.langchain.com/

●Spring AI https://spring.io/projects/spring-ai

●LlamaIndex https://www.llamaindex.ai/

●Semantic Kernel https://github.com/microsoft/semantic-kernel

●Pipecat https://github.com/pipecat-ai/pipecat

●AutoGen https://github.com/microsoft/autogen

●LiveKit Agents https://livekit.io/agents

Multi-agent Framework

●agno https://github.com/agno-agi/agno

●CAMEL-AI https://github.com/camel-ai/camel

●OpenAI Agents SDK https://platform.openai.com/docs/agents

●ELIZA.OS https://github.com/elizaOS/eliza

●crewAI https://www.crewai.com/

AI Infra

Model Training, Development and Serving

Serving（Inference Deploy）

●Ollama https://ollama.com/

●Xorbits Inference https://github.com/xorbitsai/inference

●ramalama https://github.com/containers/ramalama

●GPUStack https://github.com/GPUStack/GPUStack

Inference Engine

●vLLM https://vllm.ai/

●SGLang https://github.com/sgl-project/sglang

●TensorRT-LLM https://github.com/NVIDIA/TensorRT-LLM

●OpenVINO https://docs.openvino.ai/

●llama.cpp https://github.com/ggml-org/llama.cpp

Training / Fine-tune

●SWIFT（ModelScope Swift）https://github.com/modelscope/ms-swift

●Unsloth https://github.com/unslothai/unsloth

●LLaMA-Factory https://github.com/hiyouga/LLaMA-Factory

●VERL https://github.com/volcengine/verl

●OpenRLHF https://github.com/OpenRLHF/OpenRLHF

Training Platform / Distributed Training

●PyTorch https://pytorch.org/

●PaddlePaddle https://www.paddlepaddle.org.cn/

●Megatron-LM https://github.com/NVIDIA/Megatron-LM

●DeepSpeed https://github.com/microsoft/DeepSpeed

●NVIDIA NeMo https://github.com/NVIDIA-NeMo/NeMo

Distributed Compute

●Ray https://www.ray.io/

●Apache Spark https://spark.apache.org/

●Volcano https://volcano.sh/en/

AI Compiler

●Triton https://github.com/triton-lang/triton

●Modular https://www.modular.com/

AI Kernel Library

●RAPIDS https://rapids.ai/

●TransformerEngine https://github.com/NVIDIA/TransformerEngine

●FlashInfer https://github.com/flashinfer-ai/flashinfer

●MLX https://github.com/ml-explore/mlx

●FlashAttention https://github.com/Dao-AILab/flash-attention

●CUTLASS https://github.com/NVIDIA/cutlass

●DeepEP https://github.com/deepseek-ai/DeepEP

LLMOps

●MLflow https://mlflow.org/

●1Panel https://github.com/1Panel-dev/1Panel

●Langfuse https://langfuse.com/

●Weights & Biases https://github.com/wandb/wandb

●Opik https://github.com/comet-ml/opik

●Phoenix https://github.com/Arize-ai/phoenix

●MLRun https://www.mlrun.org/

●promptfoo https://github.com/promptfoo/promptfoo

●Dagger https://dagger.io/

AI Data

Data Labeling

●Label Studio https://labelstud.io/

●CVAT https://cvat.ai/

●Vespa https://vespa.ai/

App Framework

●Streamlit https://streamlit.io/

●Gradio https://gradio.app/

Data Integration

●Apache Airflow https://airflow.apache.org/

●Airbyte https://airbyte.com/

●Dagster https://dagster.io/

Vector Storage & Search

●Elasticsearch https://www.elastic.co/elasticsearch/

●Milvus https://milvus.io/

●OpenSearch https://opensearch.org/

●Chroma https://www.trychroma.com/

●Weaviate https://weaviate.io/

●Qdrant https://qdrant.tech/

Data Governance

●Apache Iceberg https://iceberg.apache.org/

●Apache Paimon https://paimon.apache.org/

●DataHub https://datahubproject.io/

●Delta Lake https://delta.io/

●OpenMetadata https://open-metadata.org/

●Apache Gravitino https://gravitino.apache.org/

●Apache Hudi https://hudi.apache.org/

跟着 Guava 学 Java 之缓存

Wed, 21 Sep 2022 14:42:09 +0000

本文我们先介绍一些缓存的背景知识，以及内存缓存的流行开源库类实现，最后利用一些例子重点介绍下 Guava Cache 的缓存功能。

背景

什么是缓存

“

在计算中，缓存是一个高速数据存储层，其中存储了数据子集，且通常是短暂性存储，这样日后再次请求该数据时，速度要比访问数据的主存储位置快。通过缓存，可以高效地重用之前检索或计算的数据。

”

本文中所提及的缓存主要是指内存缓存，跟硬件没什么关系（比如三级缓存什么的），主要是应用代码层面和内存交互的这部分。

缓存的特点

第一个特点：贼快（操作内存读写当然快了）

你可能会问了，贼快是多快？嗯，没有对比就没有伤害，我们来看一下不同介质访问数据的时间情况

看到了吧，RAM 的速度大概是 10-100 纳秒，什么概念？ 1 秒钟等于 10 亿纳秒，这速度快到你根本感觉不到。

第二个特点：说没就没

断电立即丢失
超过缓存失效时间

解决什么问题

一般来说，我们利用本地的内存缓存主要可以达到减轻数据库压力、提高系统响应速度和吞吐量的目的。

总之，如果对某些值的计算或检索成本很高，并且多次需要使用该值时，应该考虑使用缓存。

内存缓存库类

在 Java 中一提到缓存，我们首先想到的可以用 ConcurrentHashMap做缓存。

1static ConcurrentHashMap<String,Object> localCache = new ConcurrentHashMap<>();

为什么要用 ConcurrentHashMap 呢？

因为首先它是个 Map，这种 K,V 的数据结构很适合用来读写缓存对象，其次它还是线程安全的，多线程并发不会有线程安全问题。

Java 虽然为我们提供了ConcurrentHashMap 这样合适做缓存的数据结构，但他在功能上却有很多的不足，比如没有回收、驱逐、监听、刷新等功能。一般来说，我们设计一套完整的缓存方案虽然这些功能，用 ConcurrentHashMap意味着这些功能你要自己开发了。

在 Java 的生态中有许多库可以帮助我们省去自己开发的麻烦，人家都封装好了，开箱即用，这里我们列举几个知名和常用的，后面我们重点介绍 Guava 的 cache 模块：

Guava Cache
Spring Cache Spring 提供的一整套的缓存解决方案。虽然它本身并没有提供缓存的实现，但是它提供了一整套的接口和代码规范、配置、注解等，这样它就可以整合各种缓存方案了，比如 Redis、Ehcache，我们也就不用关心操作缓存的细节。
Caffeine（以 GuavaCache 为原型而开发的一个本地缓存框架，相对 GuavaCache, 它有更高的性能与命中率，更强大的功能，更灵活的配置方式）
J2Cache（OSChina 开源的一个两级缓存框架，采用固定的一级 + 二级缓存的模式，从一开始就是为了解决两级缓存一致性的问题）
JetCache（是阿里开源的通用缓存访问框架，它统一了多级缓存的访问方式，封装了类似于 SpringCache 的注解，以及 GuavaCache 类似的 Builder, 来简化项目中使用缓存的难度）

这里多说两句：

Caffeine是当前最优秀的内存缓存框架，不论读还是写的效率都远高于其他缓存，而且在Spring5开始的默认缓存实现就将 Caffeine 代替原来的 Guava。

在项目中，比如你用 SpringBoot 想加本地缓存，我们通常会引入 SpringCache+Caffeine的依赖。使用 SpringCache 注解方法实现缓存。SpringCache 帮我们封装了 Caffeine，通过这种方式集成 Caffeine。

1<dependency>
2 <groupId>org.springframework.boot</groupId>
3 <artifactId>spring-boot-starter-cache</artifactId>
4</dependency>
5<dependency>
6 <groupId>com.github.ben-manes.caffeine</groupId>
7 <artifactId>caffeine</artifactId>
8</dependency>

有朋友说了，你这是一级缓存，我们一般会使用二级缓存，即一级缓存用 caffeine 二级缓存用 Redis(强强联合，很常用的方案)，一级缓存找不到去二级缓存找。

没错，如果你想用 SpringBoot 集成 Caffeine和Redis实现二级缓存，有两种方式：

第一种，直接集成，引入的依赖有变化：

 1
 2 <dependency>
 3 <groupId>org.springframework.boot</groupId>
 4 <artifactId>spring-boot-starter-cache</artifactId>
 5 </dependency>
 6 <dependency>
 7 <groupId>com.github.ben-manes.caffeine</groupId>
 8 <artifactId>caffeine</artifactId>
 9 </dependency>
10 <dependency>
11 <groupId>org.springframework.boot</groupId>
12 <artifactId>spring-boot-starter-data-redis</artifactId>
13 </dependency>

这里顺便说一下 spring-boot-starter-data-redis ，spring-data-redis 和 Redis 的关系如下图，延续了 Spring 的一贯思想，对上层仍然是一层封装，对底层支持各种 Redis 客户端的实现。

第一种方式的集成比较简单，但请注意 spring cache (caffeine) 和 spring-data-redis(redis)，是各管各的（如前面括号里写的），不好意思，一二级缓存之间的逻辑关系需要你自己处理具体来说比如你可以实现 cache 拦截器 CacheInterceptor

这里有一个比较容易混乱的点， spring cache 是支持多个 Provider 的：

Generic
JCache (JSR-107) (EhCache 3, Hazelcast, Infinispan, and others)
EhCache 2.x
Hazelcast
Infinispan
Couchbase
Redis
Caffeine
Simple

意思是我们用 springcache 即可以集成 Caffeine 这种本地缓存，也可以集成 Redis 这种分布式缓存，当然配置肯定不一样。但你要清楚，同时只能集成一个，没有说用 springcache 能同时集成两个的，上面讲的集成二级缓存（caffeine+redis），是指各管各的，springcache 集成 Caffeine，spring-data-redis 集成 redis。

刚才说了第一种集成方式，现在说第二种，即利用 jetCache 做二级缓存的集成，这里依赖有了很大变化：

1 <dependency>
2 <groupId>com.alicp.jetcache</groupId>
3 <artifactId>jetcache-starter-redis-lettuce</artifactId>
4 <version>2.6.3</version>
5</dependency>

只需要这一个依赖，不需要 spring-cache 和 spring-data-redis 了，因为 jetCache 里面已经引入了 caffeine 和 lettuce 的包了。

这并不是说 spring-data-redis 和 spring-cache 不能引入，可以用，如果你有需求，但要注意检查依赖的冲突和重复。

 1jetcache:
 2 statIntervalMinutes: 1
 3 areaInCacheName: false
 4 local:
 5 default:
 6 type: caffeine
 7 keyConvertor: fastjson2
 8 remote:
 9 default:
10 type: redis.lettuce
11 keyConvertor: fastjson2
12 broadcastChannel: projectA
13 keyPrefix: projectA
14 valueEncoder: java
15 valueDecoder: java
16 uri: redis://127.0.0.1:6379/
17 defaultExpireInMillis: 5000

我们从上面的配置中可以看出，很明显这里配置了二级缓存，分别是 local 和 remote，由于 jetCache 支持二级缓存的操作，就不用我们自己写代码实现了，不过值得注意的是，要实现分布式两级缓存的同步因为太重，框架没做得自己实现，关于这个问题可以参考（https://github.com/alibaba/jetcache/issues/205）

Guava 缓存

终于到我们今天的主角 Guava Cache 了，无论你对 Caffeine 和 JetCache 多么感兴趣，请都先克制和忍耐一下，把 Guava 的 cache 看完，毕竟 Caffeine 也是以 Guava 为原型而产生的框架。

这里我们再次强调** Guava Cache 指的本地缓存，即数据存储在当前应用服务器的内存之中，而像 Redis 这样的分布式缓存，数据是存储在应用服务器内存之外的**。

下面我们来具体说说 Guava 的 Cache 怎么用

加载

cache loading , 即缓存的加载或者创建有两种方式：

cacheLoader
callable

我们首先说一下 cacheLoader ，举个例子：

 1 LoadingCache<String, String> cahceBuilder = CacheBuilder
 2 .newBuilder()
 3 .build(new CacheLoader<String, String>() {
 4 @Override
 5 public String load(String key) throws Exception {
 6 return "no " + key + "!";
 7 }
 8
 9 });
10
11 cahceBuilder.put("name", "jack");
12 cahceBuilder.put("id", "123");
13
14 System.out.println(cahceBuilder.get("name"));
15 System.out.println(cahceBuilder.get("id"));
16 System.out.println(cahceBuilder.get("address"));
17 System.out.println(cahceBuilder.getAll(List.of("name","id","address")));

输出：

1jack
2123
3no address!
4{name=jack, id=123, address=no address!}

上面的小例子我们用 cacheBuilder 构造出来的 LoadingCache 来存取类型均为String 的 K,V 缓存。build 方法需要传入一个 CacheLoader 对象，CacheLoader 是一个抽象类，需要重写 load 方法。这个 load 的方法的作用是：如果我们调用 LoadingCache 中的 get 方法，缓存不存在相对应的 key 的数据，那么 CacheLoader 会自动调用 load 方法加载数据进来，至于数据从哪里来是你自己设计的，比如从数据库或者 Redis 等等。

关于最后的 getAll 方法： getAll(Iterable<? extends K>) 方法用来执行批量查询。默认情况下，对每个不在缓存中的键，getAll 方法会单独调用 CacheLoader.load 来加载缓存项。如果批量的加载比多个单独加载更高效，你可以重载 CacheLoader.loadAll 来利用这一点。getAll(Iterable) 的性能也会相应提升。

关于 LoadingCache ，我们看一下它的特点：

“

A semi-persistent mapping from keys to values. Values are automatically loaded by the cache, and are stored in the cache until either evicted or manually invalidated. The common way to build instances is using CacheBuilder. Implementations of this interface are expected to be thread-safe, and can be safely accessed by multiple concurrent threads.

”

一种半持久化的 KV 结构
这些 KV 会一直有效，直到被驱逐或者手动设置为无效
线程安全的

接着我们来看一下 callable ，举个简单例子：

 1 Cache<String, String> cache = CacheBuilder.newBuilder().build();
 2
 3 String name = cache.get("name", new Callable<String>() {
 4 @Override
 5 public String call() throws Exception {
 6
 7 return "jack";
 8 }
 9 });
10 
11 System.out.println(name);
12
13 cache.put("id","123");
14 
15 System.out.println(cache.getIfPresent("id"));
16 System.out.println(cache.getIfPresent("address"));

输出：

1jack
2123
3null

可以看到 Callable 只有在缓存值不存在时，才会调用，值存在则直接返回该值。

总结

LoadingCache 继承了 Cache 接口。LoadingCache 读取一个指定 key 的数据时，如果 key 不存在，LoadingCache 会执行加载数据到缓存。（相当于全局的）
cacheloader 的定义比较宽泛，是针对整个 cache 定义的，可以认为是统一的根据 key 值 load value 的方法。而 callable 的方式较为灵活，允许你在 get 的时候指定。（相当于个体自定义的）

其实无论是 LoadingCache 还是 callable 的方式加载缓存，他们都实现了一个共同的语义，即 “get-if-absent-compute” 获取缓存-如果没有-则计算。注意这个语义是原子的，通过下图看到底层源码，是加了锁的。

Java 中与此相似的原子语义有：ConcurrentHashMap 中的 putIfAbsent 和 computeIfAbsent，注意只是结构相似而已。

缓存回收

从大的方面讲缓存的回收分两种，一种是手动回收，一种是自动回收。手动回收就是你自己调方法干掉它，自动就是根据一定的规则约定，当到达触发条件自动回收。

我们先来看自动这部分。

Guava Cache 提供了三种基本的缓存回收方式：基于容量回收、定时回收和基于引用回收。

基于容量的回收（size-based eviction）

顾名思义根据缓存的容量回收，超过或即将超过最大容量的缓存将被回收，我们可以通过 CacheBuilder 来设置最大容量：

1CacheBuilder.newBuilder().maximumSize(100).build();

这个 size 指的是 cache 中的条目数，不是内存大小或是其他
并不是完全到了指定的 size 系统才开始移除不常用的数据的，而是接近这个 size 的时候系统就会开始做移除的动作
如果一个键值对已经从缓存中被移除了，你再次请求访问的时候，如果 cachebuild 是使用 cacheLoader 方式的，那依然还是会从 cacheloader 中再取一次值，如果这样还没有，就会抛出异常

根据源码注释可以看到，容量回收的算法是LRU（最近最少使用）

还可以根据缓存的“权重” 进行回收，什么意思呢？

每一项缓存所占据的内存空间大小都可能不一样，我们可以把它看作它们有不同的“权重”（weights）, 作为执行清除策略时优化回收的对象。不过感觉基于权重的用的比较少。下面是一个官方的例子：

 1LoadingCache<Key, Graph> graphs = CacheBuilder.newBuilder()
 2 .maximumWeight(100000)
 3 .weigher(new Weigher<Key, Graph>() {
 4 public int weigh(Key k, Graph g) {
 5 return g.vertices().size();
 6 }
 7 })
 8 .build(
 9 new CacheLoader<Key, Graph>() {
10 public Graph load(Key key) { // no checked exception
11 return createExpensiveGraph(key);
12 }
13 });

可以通过自定义一个 weight 函数来设置每项缓存的权重。

定时回收（Timed Eviction）

定时回收，或者说基于存活时间的回收，主要有两个参数：

expireAfterAccess 缓存项在给定时间内没有被读/写访问，则回收。这种缓存的回收顺序和基于大小回收一样。
expireAfterWrite 缓存项在给定时间内没有被写访问（创建或覆盖），则回收。如果认为缓存数据总是在固定时候后变得陈旧不可用，这种回收方式是可取的。

1CacheBuilder.newBuilder().expireAfterAccess(10, TimeUnit.SECONDS).expireAfterWrite(8,TimeUnit.SECONDS);

通过这两个参数的设置可以发现：定时回收周期性地在写操作中执行，偶尔在读操作中执行

我们在测试定时回收的时候不用设置了时间以后在那儿“傻等”，可以利用 Guava 的 Ticker 来模拟时间流逝，举个例子：

 1class FakeTicker extends Ticker {
 2
 3 private final AtomicLong nanos = new AtomicLong();
 4
 5 /** Advances the ticker value by {@code time} in {@code timeUnit}. */
 6 public FakeTicker advance(long time, TimeUnit timeUnit) {
 7 nanos.addAndGet(timeUnit.toNanos(time));
 8 return this;
 9 }
10
11 @Override
12 public long read() {
13 long value = nanos.getAndAdd(0);
14 System.out.println("is called " + value);
15 return value;
16 }
17}
18
19@Test
20public void expireAfterWriteTestWithTicker() throws InterruptedException {
21 FakeTicker t = new FakeTicker();
22
23 // Use ticker to force expire in 20 minute
24 LoadingCache<String, String> cache = CacheBuilder.newBuilder()
25 .expireAfterWrite(20, TimeUnit.MINUTES).ticker(t).build(ldr);
26 cache.getUnchecked("hello");
27 assertEquals(1, cache.size());
28 assertNotNull(cache.getIfPresent("hello"));
29
30 // add 21 minutes
31 t.advance(21, TimeUnit.MINUTES);
32 assertNull(cache.getIfPresent("hello")); 
33
34}

基于引用的回收（Reference-based Eviction）

Guava 允许你通过设置实现在 JVM GC 时回收缓存对象，这种移除方式主要是基于 java 的垃圾回收机制，根据键或者值的引用关系决定移除。

稍微复习一下 Java 的引用类型：

强引用：new 出来的一般对象，只要引用在就不会被回收
软引用：将要发生内存溢出之前回收
弱引用：生存到下一次垃圾收集发生之前
虚引用：目的是对象被收集器回收时收到一个系统通知

其中，软引用 soft reference 可用来实现内存敏感的高速缓存。而弱引用 weak reference 引用的对象是有价值被 cache, 而且很容易被重新构建，且很消耗内存的对象。所以软引用和弱引用被 Guava 利用来处理回收问题。

CacheBuilder.weakKeys() 使用弱引用存储键。当键没有其它（强或软）引用时，缓存项可以被垃圾回收。
CacheBuilder.weakValues()：使用弱引用存储值。当值没有其它（强或软）引用时，缓存项可以被垃圾回收。
CacheBuilder.softValues()：使用软引用存储值。软引用的对象会根据内存需求，以 LRU 的方式进行垃圾收集。

1Cache<String, String> cache = CacheBuilder.newBuilder().weakKeys().weakValues().softValues().build();

实际工作中用引用回收的很少。

上面我们介绍的回收方式，无论是基于容量回收、定时回收还是基于引用回收都是类似于自动回收的方式，下面我们介绍下手动显示回收，即手动回收缓存。

个别清除：Cache.invalidate(key)
批量清除：Cache.invalidateAll(keys)
清除所有缓存项：Cache.invalidateAll()

移除监听器

通过CacheBuilder.removalListener(RemovalListener)，你可以声明一个监听器，以便缓存项被移除时做一些额外操作。缓存项被移除时，RemovalListener会获取移除通知RemovalNotification，其中包含移除原因RemovalCause、键和值。

举个例子：

1 RemovalListener<String, String> myRemovalListener = notification -> {
2 System.out.println(notification.getCause().toString()+ " | [" + notification.getKey() + ":" + notification.getValue() + "] is removed!");
3
4 };
5 Cache<String, String> cache = CacheBuilder.newBuilder().removalListener(myRemovalListener).build();
6 cache.put("name","jack");
7 cache.put("id","123");
8 cache.invalidate("id");

输出：EXPLICIT | [id:123] is removed!

注意：默认情况下，监听器方法是在移除缓存时同步调用的。因为缓存的维护和请求响应通常是同时进行的，代价高昂的监听器方法在同步模式下会拖慢正常的缓存请求。在这种情况下，你可以使用RemovalListeners.asynchronous(RemovalListener, Executor)把监听器装饰为异步操作，比如：

1ExecutorService executor = Executors.newSingleThreadExecutor();
2Cache<Integer, Integer> cache1 = CacheBuilder.newBuilder().expireAfterWrite(2, TimeUnit.SECONDS)
3 .removalListener(RemovalListeners.asynchronous(notification -> {
4 System.out.println(notification.getCause());
5 System.out.println(notification.getKey() + " --> " + notification.getValue());
6 }, executor)).build();

缓存回收的时机

关于这点，只需要知道 Guava cache 缓存不会”自动”执行清理和回收工作，也不会在某个缓存项过期后马上清理，也没有诸如此类的清理机制。相反，它会在写操作时顺带做少量的维护工作，或者偶尔在读操作时做——如果写操作实在太少的话。

这样做的原因在于：如果要自动地持续清理缓存，就必须有一个线程，这个线程会和用户操作竞争共享锁。此外，某些环境下线程创建可能受限制，这样 CacheBuilder 就不可用了。

相反，Guava 把选择权交到我们手里。如果你的缓存是高吞吐的，那就无需担心缓存的维护和清理等工作。如果你的缓存只会偶尔有写操作，而你又不想清理工作阻碍了读操作，那么可以创建自己的维护线程，以固定的时间间隔调用Cache.cleanUp()

ScheduledExecutorService可以帮助你很好地实现这样的定时调度。

刷新

如果对缓存设置过期时间，在高并发下同时执行 get 操作，而此时缓存值已过期了，如果没有保护措施，则会导致大量线程同时调用生成缓存值的方法，比如从数据库读取，对数据库造成压力，这也就是我们常说的“缓存击穿”。

而 Guava cache 则对此种情况有一定控制。当大量线程用相同的 key 获取缓存值时，只会有一个线程进入 load 方法，而其他线程则等待（同步），直到缓存值被生成。这样也就避免了缓存击穿的危险。上述机制其实就是 expireAfterWrite/expireAfterAccess 来控制的，如果你配置了过期策略对应的缓存项在过期后被访问就会走上述流程来加载缓存项。

但这样做会导致大量的请求线程被阻塞。怎么办呢？

Guava cache 的办法是提供一种缓存策略，缓存值定时刷新 refreshAfterWrite ：更新线程调用 load 方法更新该缓存，其他请求线程返回该缓存的旧值。这样对于某个 key 的缓存来说，只会有一个线程被阻塞，用来生成缓存值，而其他的线程都返回旧的缓存值，不会被阻塞。

我们对比一下 refreshAfterWrite 和expireAfterWrite

expireAfterWrite 是允许一个线程进去 load 方法，其他线程阻塞等待。
refreshAfterWrite 是允许一个线程进去 load 方法，其他线程返回旧的值。

那么问题解决了吗？单个 key 并发下，使用 refreshAfterWrite，虽然不会阻塞了，但是如果恰巧多个 key 同时过期，还是会给数据库造成压力，这就是我们所说的“缓存雪崩”。这时就要用到异步刷新，将刷新缓存值的任务交给后台线程，所有的用户请求线程均返回旧的缓存值。方法是覆盖 CacheLoader 的reload方法，使用线程池去异步加载数据

“

只有重写了 reload 方法才有“异步加载”的效果。默认的 reload 方法就是同步去执行 load 方法

”

关于 reload 可以参考官方的例子：

 1//有些键不需要刷新，并且我们希望刷新是异步完成的
 2LoadingCache<Key, Graph> graphs = CacheBuilder.newBuilder()
 3 .maximumSize(1000)
 4 .refreshAfterWrite(1, TimeUnit.MINUTES)
 5 .build(
 6 new CacheLoader<Key, Graph>() {
 7 public Graph load(Key key) { // no checked exception
 8 return getGraphFromDatabase(key);
 9 }
10 
11 public ListenableFuture<Key, Graph> reload(final Key key, Graph prevGraph) {
12 if (neverNeedsRefresh(key)) {
13 return Futures.immediateFuture(prevGraph);
14 }else{
15 // asynchronous!
16 ListenableFutureTask<Key, Graph> task=ListenableFutureTask.create(new Callable<Key, Graph>() {
17 public Graph call() {
18 return getGraphFromDatabase(key);
19 }
20 });
21 executor.execute(task);
22 return task;
23 }
24 }
25 });

最佳实践：refreshTime < expireTime

因为，根据 get 的流程，在 get 的时候，是先判断过期，再判断 refresh（如果 refreshTime > expireTime 意味着永远走不到缓存刷新逻辑。)，即如果过期了会优先调用 load 方法（阻塞其他线程）。

在不过期情况下且过了 refresh 时间才去做 reload （异步加载，同时返回旧值），所以推荐的设置是 refresh < expire，这个设置还可以解决一个场景就是，如果长时间没有访问缓存，可以保证 expire 后可以取到最新的值，而不是因为 refresh 取到旧值。

可选配置

除了上文中已经介绍附带主题提到过的一些配置外，还有一些值得关注的配置：

缓存的并发级别

Guava 提供了设置并发级别的 api，使得缓存支持并发的写入和读取

1CacheBuilder.newBuilder()
2 // 设置并发级别为 cpu 核心数
3 .concurrencyLevel(Runtime.getRuntime().availableProcessors()) 
4 .build();

同 ConcurrentHashMap 类似 Guava cache 的并发也是通过分离锁实现。在一般情况下，将并发级别设置为服务器 cpu 核心数是一个比较不错的选择。

缓存的初始容量设置

我们在构建缓存时可以为缓存设置一个合理大小初始容量，由于 Guava 的缓存使用了分离锁的机制，扩容的代价非常昂贵。所以合理的初始容量能够减少缓存容器的扩容次数。

1CacheBuilder.newBuilder()
2 // 设置初始容量为 100
3 .initialCapacity(100)
4 .build();

统计信息

在构建 Cache 对象时，可以通过 CacheBuilder 的 recordStats 方法开启统计信息的开关。开关开启后 Cache 会自动对缓存的各种操作进行统计，调用 Cache 的 stats 方法可以查看统计后的信息。

CacheStats对象以提供如下统计信息：

hitRate()：缓存命中率；
averageLoadPenalty()：加载新值的平均时间，单位为纳秒；
evictionCount()：缓存项被回收的总数，不包括显式清除。

1 Cache<String, String> cache = CacheBuilder.newBuilder().recordStats().build();
2 cache.put("name", "jack");
3 cache.put("id", "123");
4 cache.invalidate("id");
5
6 System.out.println(cache.getIfPresent("name"));
7 System.out.println(cache.stats());

输出：

1jack
2CacheStats{hitCount=1, missCount=0, loadSuccessCount=0, loadExceptionCount=0, totalLoadTime=0, evictionCount=0}

asMap 视图

asMap 视图提供了缓存的 ConcurrentMap 形式，但 asMap 视图与缓存的交互需要注意：

cache.asMap() 包含当前所有加载到缓存的项。因此相应地，cache.asMap().keySet() 包含当前所有已加载键；
asMap().get(key) 实质上等同于 cache.getIfPresent(key)，而且不会引起缓存项的加载。这和 Map 的语义约定一致。
所有读写操作都会重置相关缓存项的访问时间，包括 Cache.asMap().get(Object) 方法和 Cache.asMap().put(K, V) 方法，但不包括 Cache.asMap().containsKey(Object) 方法，也不包括在 Cache.asMap() 的集合视图上的操作。比如，遍历 Cache.asMap().entrySet() 不会重置缓存项的读取时间。

Caffeine

从功能上看，Guava 已经比较完善了，满足了绝大部分本地缓存的需求。Caffine 除了提供 Guava 已有的功能外，同时还加入了一些扩展功能。

关于 Caffeine 的话题，限于篇幅，我们在以后的文章中再讨论。

总结

本文我们首先介绍了缓存的一些背景知识，了解了缓存的分类，以及内存缓存的一些开源库类，利用一些短小易懂的例子重点介绍了 Guava Cache，包括它的加载、更新、回收、配置、统计等功能。由于篇幅有限，有关常用的 JetCache 、Caffeine，还有一二级缓存的话题，有机会我会在后面的文章中跟大家再细聊。

参考

10分钟了解7个Java11的新功能

Tue, 30 Aug 2022 14:00:32 +0000

概述

我知道很多公司和个人还在用 Java8，我们不妨梳理下当下的情况

目前 Java 最新的 GA（General-Availability） Release 版本是 JDK 18.0.2.1
Java 17 LTS 是最新长期支持版本。根据 Oracle 免费条款JDK 18 和 JDK 17 可在生产环境中免费使用，至少在 2024 年 9 月之前
JDK 18 到 2022 年 9 月它将被 JDK 19 取代

日子总要过，我们也不可能抱着 Java 8 用一辈子，我们来一起看看 Java 11 的一些新玩意儿。

本文算是 Java 11 功能的小教程，没有长篇的文字，都是些短小易懂的代码，让我们沉浸在研究代码的快乐中吧。

1 局部变量类型推断

Java 10 引入了一个新的语言关键字var ，它可以在声明局部变量时选择性地替换类型信息

在 Java 10 之前，我们这样声明变量：

1String text ="Hello World";

现在可以替换String为var. 编译器从变量的赋值中推断出正确的类型

1var text = "Hello World";

注意：声明的变量**var****仍然是静态类型的。不能将不兼容的类型重新分配给此类变量**，比如下面的代码就无法编译通过

1var text = "Hello World";
2text = 123;

当然你还可以final与结合使用var来禁止用另一个值重新分配变量：

1final var text = "Hello World";
2text = "hello"; // Cannot assign a value to final variable 'text'

当编译器无法推断变量的正确类型时，也var不允许使用。以下所有代码示例都会导致编译器错误：

1var a;
2var nothing = null;
3var lambda = () -> System.out.println("Joe!");
4var method = this::someMethod;

**有什么直接的好处？**

比如有一个相当冗长的类型Map<String, List<Integer>>，可以将其简化为单个var关键字，从而避免您输入一坨类型：

1var myList = new ArrayList<Map<String, List<Integer>>>();
2
3for (var current : myList) {
4 // current is infered to type: Map<String, List<Integer>>
5 System.out.println(current);
6}

从 Java 11 开始，var关键字也允许用于 lambda 参数，这使你能够为这些参数添加注释：

1Predicate<String> predicate = (@Nullable var a) -> true;

“

提示：在 Intellij IDEA 中，您可以将鼠标悬停在变量上，同时按住CMD/CTRL以显示变量的推断类型

”

2 Http Client

Java 9 引入了一个新的孵化的HttpClientAPI 来处理 HTTP 请求。从 Java 11 开始，这个 API 现在是最终可用的了，在包java.net 中。让我们探索一下这个 API

newHttpClient 可以同步或异步使用。同步请求会阻塞当前线程，直到响应可用。
BodyHandlers 定义响应主体的预期类型（例如字符串、字节数组或文件）：

1 var request = HttpRequest.newBuilder()
2 .uri(URI.create("http://jsonplaceholder.typicode.com/users"))
3 .GET()
4 .build();
5 var client = HttpClient.newHttpClient();
6 HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
7 System.out.println(response.body());

可以异步执行相同的请求。调用sendAsync不会阻塞当前线程，而是返回一个CompletableFuture来构造异步操作流水线。

1var request = HttpRequest.newBuilder()
2 .uri(URI.create("http://jsonplaceholder.typicode.com/users"))
3 .build();
4var client = HttpClient.newHttpClient();
5client.sendAsync(request, HttpResponse.BodyHandlers.ofString())
6 .thenApply(HttpResponse::body)
7 .thenAccept(System.out::println);

“

自己跑代码的时候注意，因为是异步的，所以你可以让主线程 sleep 一会儿，不然直接运行啥都没有

”

最新的这个 HttpClient 还有一些其他功能就不过多介绍了，如果你使用了 Spring 5 及以上版本，我的建议是可以直接用 WeClient ，那玩意儿谁用谁知道呀。

3 Collection

List等集合已通过新方法进行了扩展。从给定的参数创建一个新的不可变列表。创建列表的不可变副本

1var list = List.of("A", "B", "C");
2var copy = List.copyOf(list);
3System.out.println(list == copy); // true

注意这里 of 方法返回的是不可变类型，我们看下源码：

1 static <E> List<E> of(E e1, E e2, E e3) {
2 return new ImmutableCollections.ListN<>(e1, e2, e3);
3 }

因为list已经是不可变的，所以实际上不需要创建列表实例的副本，因此list和copy是同一个实例。但是，如果你想复制一个可变列表，copy 则返回一个新实例，因此可以保证在改变原始列表时没有副作用

1var list = new ArrayList<String>();
2var copy = List.copyOf(list);
3System.out.println(list == copy); // false

Map 的 of 方法方便我们直接构造：

1var map = Map.of("A", 1, "B", 2);
2System.out.println(map); // {B=2, A=1}

注意这里仍然返回的是不可变类型，关于不可变集合的了解可以参考我之前的一篇文章《跟着 Guava 学 Java 之不可变集合》

如果你修改了不可变集合会抛出 java.lang.UnsupportedOperationException 异常，IDEA 也会有相应的警告给你标明哪里出了问题。

4 Stream

流是在 Java 8 中引入的，现在接收三个新方法。Stream.ofNullable从单个元素构造一个流：

1Stream.ofNullable(null).count() // 0

dropWhile和takeWhile 是确定要从流中放弃哪些元素。

1Stream.of(1, 2, 3, 2, 1)
2 .dropWhile(n -> n < 3)
3 .collect(Collectors.toList()); // [3, 2, 1]
4
5Stream.of(1, 2, 3, 2, 1)
6 .takeWhile(n -> n < 3)
7 .collect(Collectors.toList()); // [1, 2]

takeWhile() 方法使用一个断言作为参数，返回给定 Stream 的子集直到断言语句第一次返回 false。如果第一个值不满足断言条件，将返回一个空的 Stream。
dropWhile 方法和 takeWhile 作用相反的，使用一个断言作为参数，直到断言语句第一次返回 false 才返回给定 Stream 的子集。

所以上面

第一段的意思是放弃取小于 3 的元素，直到遇到第一个不小于 3 的则把后面的全部元素收集起来
第二段的意思就是从第一个元素开始收集元素，直到遇到第一个不小于 3 的元素结束

5 Optional

Optional 还接收到一些非常方便的新方法，例如，您现在可以简单地将 optional 转换为流或提供另一个 optional 作为空 optional 的后备

1Optional.of("foo").orElseThrow(); // foo
2Optional.of("foo").stream().count(); // 1
3Optional.ofNullable(null)
4 .or(() -> Optional.of("fallback"))
5 .get(); // fallback

6 String

最基本的类之一String有一些辅助方法来修剪或检查空格以及流式传输字符串的行：

1" ".isBlank(); // true
2" Foo Bar ".strip(); // "Foo Bar"
3" Foo Bar ".stripTrailing(); // " Foo Bar"
4" Foo Bar ".stripLeading(); // "Foo Bar "
5"Java".repeat(3); // "JavaJavaJava"
6"A\nB\nC".lines().count(); // 3

注意你可能觉得 strip 和 trim 方法一样，一般使用的话差不多，但实际上他们不一样，有所区别：

trim() 可以去除字符串前后的半角空白字符
strip() 可以去除字符串前后的全角和半角空白字符

你可以试试：

 1 String test1="测试、u0020";//半角 unicode
 2 System.out.println(test1.trim().length());//2
 3 System.out.println(test1.strip().length());//2
 4
 5 String test2="测试、u3000";//全角 unicode
 6 System.out.println(test2.trim().length());//3
 7 System.out.println(test2.strip().length());//2
 8
 9 String test3="测试 ";//半角空白字符
10 System.out.println(test3.trim().length());//2
11 System.out.println(test3.strip().length());//2
12
13 String test4="测试 ";//全角空白字符
14 System.out.println(test4.trim().length());//3
15 System.out.println(test4.strip().length());//2
16
17 String test5="测试 ";//两个半角空白字符
18 System.out.println(test5.trim().length());//2
19 System.out.println(test5.strip().length());//2
20

7 InputStream

终于有一个非常实用的方法可以将数据从 inputStream 转到 outputStream 了，不用再自己写了

1var classLoader = ClassLoader.getSystemClassLoader();
2var inputStream = classLoader.getResourceAsStream("myFile.txt");
3var tempFile = File.createTempFile("myFileCopy", "txt");
4try (var outputStream = new FileOutputStream(tempFile)) {
5 inputStream.transferTo(outputStream);
6}

我们看源码的 transferTo 方法

 1 public long transferTo(OutputStream out) throws IOException {
 2 Objects.requireNonNull(out, "out");
 3 long transferred = 0;
 4 byte[] buffer = new byte[DEFAULT_BUFFER_SIZE];
 5 int read;
 6 while ((read = this.read(buffer, 0, DEFAULT_BUFFER_SIZE)) >= 0) {
 7 out.write(buffer, 0, read);
 8 transferred += read;
 9 }
10 return transferred;
11 }
12}

熟悉吗？再也不用写这破玩意儿了。

最后

当然 Java 11 的更新中远远不止上面这些内容，还有很多功能和特性值得大家去探索，比如：

Flow API 的反应式编程
G1: Full Parallel Garbage Collector
ZGC: Scalable Low-Latency Garbage Collector
…

一文弄懂 Spring WebFlux 的来龙去脉

Mon, 29 Aug 2022 10:31:50 +0000

概述

本文将通过对 Reactive 以及相关概念的解释引出 Spring-WebFlux，并通过一些示例向读者解释基于 Spring-WebFlux 如何进行反应式编程实践，同时会讨论相关技术的优缺点及技术原理。

什么是 Reactive

在计算机编程领域，Reactive 一般指的是 Reactive programming。指的是一种面向数据流并传播事件的异步编程范式（asynchronous programming paradigm）

响应式编程最初是为了简化交互式用户界面的创建和实时系统动画的绘制而提出来的一种方法，但它本质上是一种通用的编程范式。

举个例子

“

在 Excel 里，C 单元格上设置函数 Sum(A+B)，当你改变单元格 A 或者单元格 B 的数值时，单元格 C 的值同时也会发生变化。这种行为就是 Reactive

”

下面的例子我们用了 https://projectreactor.io/ 的 reactor 库，通过这个例子找找感觉：

1 FluxProcessor<Integer, Integer> publisher = UnicastProcessor.create();
2 publisher.doOnNext(event -> System.out.println("receive event: " + event)).subscribe();
3 publisher.onNext(1);
4 publisher.onNext(2);
5 
6 // 输出
7 // receive event: 1
8 // receive event: 2

追根溯源，说到 Reactive ，就不得不提到大名鼎鼎的响应式宣言/The Reactive Manifesto（https://www.reactivemanifesto.org），它于 2014 年发表，响应式宣言是一份构建现代云扩展架构的处方。

“

We believe that a coherent approach to systems architecture is needed, and we believe that all necessary aspects are already recognised individually: we want systems that are Responsive, Resilient, Elastic and Message Driven. We call these Reactive Systems.

”

这个框架主要使用消息驱动的方法来构建系统，在形式上可以达到弹性和韧性，最后可以产生响应性的价值。

所谓弹性和韧性，通俗来说就像是橡皮筋，弹性是指橡皮筋可以拉长，而韧性指在拉长后可以缩回原样。

解释下上面的关键词：

响应性 快速/一致的响应时间。假设在有 500 个并发操作时，响应时间为 1s，那么并发操作增长至 5 万时，响应时间也应控制在 1s 左右。快速一致的响应时间才能给予用户信心，是系统设计的追求。
韧性复制/遏制/隔绝/委托。当某个模块出现问题时，需要将这个问题控制在一定范围内，这便需要使用隔绝的技术，避免连锁性问题的发生。或是将出现故障部分的任务委托给其他模块。韧性主要是系统对错误的容忍。
弹性无竞争点或中心瓶颈/分片/扩展。如果没有状态的话，就进行水平扩展，如果存在状态，就使用分片技术，将数据分至不同的机器上。
消息驱动 异步/松耦合/隔绝/地址透明/错误作为消息/背压/无阻塞。消息驱动是实现上述三项的技术支撑。
地址透明有很多方法。例如 DNS 提供的一串人类能读懂的地址，而不是 IP，这是一种不依赖于实现，而依赖于声明的设计。再例如 k8s 每个 service 后会有多个 Pod，依赖一个虚拟的服务而不是某一个真实的实例，从何实现调用 1 个或调用 n 个服务实例对于对调用方无感知，这是为分片或扩展做了准备。
错误作为消息，这在 Java 中是不太常见的，Java 中通常将错误直接作为异常抛出，而在响应式中，错误也是一种消息，和普通消息地位一致，这和 JavaScript 中的 Promise 类似。
背压是指当上游向下游推送数据时，可能下游承受能力不足导致问题，一个经典的比喻是就像用消防水龙头解渴。因此下游需要向上游声明每次只能接受大约多少量的数据，当接受完毕再次向上游申请数据传输。这便转换成是下游向上游申请数据，而不是上游向下游推送数据。
无阻塞是通过 no-blocking IO 提供更高的多线程切换效率。

Reactive Programming

响应式编程是一种声明式编程范型

 1 int a, b, sum;
 2
 3 a = 3;
 4 b = 4;
 5 sum = a + b;
 6
 7 a = 6;
 8 b = 7;
 9
10 System.out.println(sum);

上面是一个命令式编程的例子，先声明两个变量，然后进行赋值，让两个变量相加，得到相加的结果。但接着当修改了最早声明的两个变量的值后，sum 的值不会因此产生变化。

在 Java 9 Flow 中，按相同的思路实现上述处理流程，当初始变量的值变化，最后结果的值也同步发生变化，这就是响应式编程。这相当于声明了一个公式，输出值会随着输入值而同步变化。

 1 SubmissionPublisher<Integer> publisher = new SubmissionPublisher<>();
 2 publisher.subscribe(new Flow.Subscriber<Integer>() {
 3 private Integer sum = 0;
 4 Flow.Subscription subscription = null;
 5
 6 @Override
 7 public void onSubscribe(Flow.Subscription subscription) {
 8
 9 this.subscription = subscription;
10 subscription.request(1);
11 }
12
13 @Override
14 public void onNext(Integer item) {
15 subscription.request(1);
16 sum += item;
17
18 }
19
20 @Override
21 public void onError(Throwable throwable) {
22
23 }
24
25 @Override
26 public void onComplete() {
27 System.out.println(sum);
28 }
29
30 });
31
32 Arrays.asList(3, 4).stream().forEach(publisher::submit);
33 publisher.close();

之前有提及消息驱动，消息驱动（Message-driven）和事件驱动（Event-driven）有什么区别呢。

1）消息驱动有确定的目标，一定会有消息的接受者，而事件驱动是一件事情希望被观察到，观察者是谁无关紧要。消息驱动系统关注消息的接受者，事件驱动系统关注事件源。

2）在一个使用响应式编程实现的响应式系统中，消息擅长于通讯，事件擅长于反应事实。

Reactive Streams

Reactive Streams(https://www.reactive-streams.org) 提供了一套非阻塞背压的异步流处理标准，主要应用在 JVM、JavaScript 和网络协议工作中。通俗来说，它定义了一套响应式编程的标准。

有了标准，各 Reactor 库的厂商就有了规范，不再各自为战，并且对于上层应用开发者来说可以根据自己的需要选择同一个规范下的各种不同实现库。

“

The purpose of Reactive Streams is to provide a standard for asynchronous stream processing with non-blocking backpressure.

”

在 Java 中，有 4 个 Reactive Streams API，在 JUC 的 Flow 类中可以看到：

Publisher 即事件的发生源，它只有一个 subscribe 方法。其中的 Subscriber 就是订阅消息的对象。
Subscriber 作为订阅者，有四个方法。onSubscribe 会在每次接收消息时调用，得到的数据都会经过 onNext 方法。onError 方法会在出现问题时调用，Throwable 即是出现的错误消息。在结束时调用 onComplete 方法。
Subscription 接口用来描述每个订阅的消息。request 方法用来向上游索要指定个数的消息，cancel 方法用于取消上游的数据推送，不再接受消息。
Processor 接口继承了 Subscriber 和 Publisher，它既是消息的发生者也是消息的订阅者。这是发生者和订阅者间的过渡桥梁，负责一些中间转换的处理。

Thinking in Streams

反应式流所带来的编程思维模式的改变是转为以流为中心。这是从以逻辑为中心到以数据为中心的转换，也是命令式到声明式的转换。

传统的命令式编程范式以控制流为核心，通过顺序、分支和循环三种控制结构来完成不同的行为。开发人员在程序中编写的是执行的步骤
以数据为中心侧重的是数据在不同组件的流动。开发人员在程序中编写的是对数据变化的声明式反应。

Reactor 库

Reactor Library 从开始到现在已经历经多代。早期如 java.util.Observable 、 rx.NET 、 Reactive4Java ，后来的 Rxjava 、Akka-Streams以及 Project Reactor。

RxJava 对于开发 Android 应用的同学应该不陌生，比较常用，这种比较著名的库发展了好几个大版本，比如 RxJava1 RxJava2 和 RxJava3
Project Reactor（Spring 母公司 Pivotal 的项目），实现了完全非阻塞，并且基于网络 HTTP/TCP/UDP 等的背压，即数据传输上游为网络层协议时，通过远程调用也可以实现背压。同时，它还实现了 Reactive Streams API 和 Reactive Extensions，以及支持 Java 8 functional API/Completable Future/Stream /Duration 等各新特性。它也是 Spring 官方反应式编程的默认实现。

从 Reactive 宣言、到 Reactive Streams 规范，再到各种 Reactive 库是很自然的一个脉络，但现实的顺序是：

先有了宣言（思想）
然后有了根据思想开发的各种库（实现）
为了各个库之间的统一性、可操作性，大家一起协商出了 Reactive Streams 规范。继而这些已经存在的 Reactive 库便改进自己的 API 设计，向 Reactive Streams 规范靠拢并提供各种转化 API 让用户在原生 API 和 Reactive Streams 接口直接转换。

来看个例子：

 1 List<String> words = Arrays.asList(
 2 "the", "quick", "brown", "fox",
 3 "jumped", "over", "the", "lazy", "dog");
 4 Flux.fromIterable(words)
 5 .flatMap(word -> Flux.fromArray(word.split("")))
 6 .concatWith(Mono.just("s")).distinct().sort()
 7 .zipWith(Flux.range(1, Integer.MAX_VALUE),
 8 (string, count) ->
 9 String.format("%2d. %s", count, string)
10 )
11 .subscribe(System.out::println);

首先定义了一个 words 的数组，然后使用 flatMap 做映射，再将每个词和 s 做连接，得出的结果和另一个等长的序列进行一个 zipWith 操作，最后打印结果。这和 Java 8 Stream 非常类似，但仍存在一些区别：

1） Stream 是 pull-based，下游从上游拉数据的过程，它会有中间操作例如 map 和 reduce，和终止操作例如 collect 等，只有在终止操作时才会真正的拉取数据。Reactive 是 push-based，可以先将整个处理数据量构造完成，然后向其中填充数据，在出口处可以取出转换结果。

2） Stream 只能使用一次，因为它是 pull-based 操作，拉取一次之后源头不能更改。但 Reactive 可以使用多次，因为 push-based 操作像是一个数据加工厂，只要填充数据就可以一直产出。

3） Stream#parallel() 使用 fork-join 并发，就是将每一个大任务一直拆分至指定大小颗粒的小任务，每个小任务可以在不同的线程中执行，这种多线程模型符合了它的多核特性。Reactive 使用 Event loop，用一个单线程不停的做循环，每个循环处理有限的数据直至处理完成。

这里有个网站，一共 12 节，每一节都有讲解和代码示例，是基于 Reactor 3 的，可以用来练习 Reactive Programing :https://tech.io/playgrounds/929/reactive-programming-with-reactor-3/Intro

Backpressure

上面我们提到了 BackPressure，即背压或回压。Backpressure 是一种现象：当数据流从上游生产者向下游消费者传输的过程中，上游生产速度大于下游消费速度，导致下游的 Buffer 溢出，这种现象就叫做 Backpressure。

上游生产数据，生产完成后通过管道将数据传到下游，下游消费数据，当下游消费速度小于上游数据生产速度时，数据在管道中积压会对上游形成一个压力，这就是 BackpressureBackpressure 会出现在有 Buffer 上限的系统中，当出现 Buffer 溢出的时候，就会有 Backpressure，对于 Backpressure，它的应对措施只有一个：丢弃新事件。那么什么是 Buffer 溢出呢？例如我的服务器可以同时处理 2000 个用户请求，那么我就把请求上限设置为 2000，这个 2000 就是我的 Buffer，当超出 2000 的时候，就产生了 Backpressure。

Backpressure 问题在 Flow API 中得到了很好的解决。

Subscriber 会将 Publisher 发布的数据缓存在 Subscription 中，其长度默认为 256，一旦超出这个数据量，publisher 就会降低数据发送速度。通过一个例子了解一下：

 1 public static void backPressureTest() {
 2
 3 SubmissionPublisher<String> publisher = new SubmissionPublisher<>();
 4
 5 Flow.Subscriber<String> subscriber = new Flow.Subscriber<String>() {
 6 private Flow.Subscription subscription;
 7
 8 @Override
 9 public void onSubscribe(Flow.Subscription subscription) {
10 this.subscription = subscription;
11 //向数据发布者请求一个数据
12 this.subscription.request(1);
13 }
14
15 @Override
16 public void onNext(String item) {
17 System.out.println("接收到 publisher 发来的消息了：" + item);
18 try {
19 Thread.sleep(2000);
20 } catch (InterruptedException e) {
21 e.printStackTrace();
22 }
23 this.subscription.request(1);
24 }
25
26 @Override
27 public void onError(Throwable throwable) {
28 //出现异常，就会来到这个方法，此时直接取消订阅即可
29 this.subscription.cancel();
30 }
31
32 @Override
33 public void onComplete() {
34 //发布者的所有数据都被接收，并且发布者已经关闭
35 System.out.println("数据接收完毕");
36 }
37 };
38 publisher.subscribe(subscriber);
39 for (int i = 0; i < 500; i++) {
40 System.out.println("i--------->" + i);
41 publisher.submit("hello:" + i);
42 }
43 //关闭发布者
44 publisher.close();
45 }

这里我们发布 500 条数据，由于 Flow 的缓存大小是 256 ，所以前 256 条数据很快就生产出来进入缓存队列了：

1static final int DEFAULT_BUFFER_SIZE = 256;

由于消费的比较慢（我们手动 Sleep 了 2 秒） this.subscription.request(1) 只能一条一条消费，所以效果就是一条一条消费，消费一条，生产一条。

最好自己在本地跑一下代码，感受一下 backpressure

R2DBC

Reactive 本来不支持 JDBC。最根本的原因是，JDBC 不是 non-blocking 设计。不过这个事情也正在推进和发展过程中，比如 r2dbc ( https://r2dbc.io/) 项目。

R2DBC 是 Reactive Relational Database Connectivity 的首字母缩写词。 R2DBC 是一个 API 规范倡议，它声明了一个响应式 API，由驱动程序供应商实现，并以响应式编程的方式访问他们的关系数据库。

R2DBC基于Reactive Streams反应流规范，它是一个开放的规范，为驱动程序供应商和使用方提供接口（r2dbc-spi），与JDBC的阻塞特性不同，它提供了完全反应式的非阻塞API与 [关系型数据库] 交互。

目前 R2DBC 支持的数据库如下：

cloud-spanner-r2dbc - driver for Google Cloud Spanner.
jasync-sql - R2DBC wrapper for Java & Kotlin Async Database Driver for MySQL and PostgreSQL (written in Kotlin).
oracle-r2dbc - native driver implemented for Oracle.
r2dbc-h2 - native driver implemented for H2 as a test database.
r2dbc-mariadb - native driver implemented for MariaDB.
r2dbc-mssql - native driver implemented for Microsoft SQL Server.
r2dbc-mysql - native driver implemented for MySQL.
r2dbc-postgresql - native driver implemented for PostgreSQL.

很多同学可能会关心事务的事儿，R2DBC 也是支持事务的

什么是 Spring-WebFlux

相信有了前文对 Reactive 的铺垫，了解 Spring-WebFlux 会比较容易了。

Spring 5.0 添加了 Spring-WebFlux 模块将默认的 web 服务器改为 Netty，支持 Reactive 应用，它的特点是：

完全非阻塞式的（non-blocking）
支持 Reactive Stream 背压（Reactive Streams back pressure）
运行在 Netty, Undertow, and Servlet 3.1+ 容器

对比 Spring MVC

Spring MVC 构建于 Servlet API 之上，使用的是同步阻塞式 I/O 模型，什么是同步阻塞式 I/O 模型呢？就是说，每一个请求对应一个线程去处理。

Spring WebFlux 是一个异步非阻塞式 IO 模型，通过少量的容器线程就可以支撑大量的并发访问，所以 Spring WebFlux 可以有效提升系统的吞吐量和伸缩性，特别是在一些 IO 密集型应用中，Spring WebFlux 的优势明显。例如微服务网关 Spring Cloud Gateway 就使用了 WebFlux，这样可以有效提升网管对下游服务的吞吐量。

Spring WebFlux 与 Spring MVC 的关系如下图

可见，Spring WebFlux 并不是为了替代 Spring MVC 的，它与 Spring MVC 一起形成了两套 WEB 框架。两套框架有交集比如对 @Controller 注解的使用，以及均可使用 Tomcat、Jetty、Undertow 作为 Web 容器。

Spring MVC 还是 WebFlux？

针对这个问题，官方认为两者并不是二元对立的，他们可以并排使用，两者一起工作以扩大可用选项的范围。

我们来看看官方给的具体建议：

如果已经有了一个运行良好的 SpringMVC 应用程序，则无需更改。命令式编程是编写、理解和调试代码的最简单方法，我们可以选择最多的库，因为从历史上看，大多数都是阻塞的。
如果是个新应用且决定使用非阻塞 Web 技术栈，那么 WebFlux 是个不错的选择。
对于使用 Java8 Lambda 或者 Kotlin 且要求不那么复杂的小型应用程序或微服务来说，WebFlux 也是一个不错的选择
在微服务架构中，可以混合使用 SpringMVC 和 Spring WebFlux，两个都支持基于注解的编程模型
评估应用程序的一种简单方法是检查其依赖关系。如果要使用阻塞持久性 API（JPA、JDBC）或网络 API，那么 Spring MVC 至少是常见架构的最佳选择
如果有一个调用远程服务的 Spring MVC 应用程序，请尝试响应式WebClient
对于一个大型团队，向非阻塞、函数式和声明式编程转变的学习曲线是陡峭的。在没有全局开关的情况下，想启动 WebFlux，可以先使用 reactive WebClient。此外，从小处着手并衡量收益。我们预计，对于广泛的应用，这种转变是不必要的。

这里最后一点的意思是要仔细通过技术原理（非阻塞 IO、并发性能、吞吐量..）来评估 WebFlux 究竟能为我们带来多少益处，同时评估为了获得这些好处所要付出的学习和改造成本，然后衡量收益，如果收益大值得一试，否则不建议动。

个人认为对于日常用 SpringMVC 开发的业务应用不用换 Spring-WebFlux，因为 SpringMVC 是同步阻塞式模型，对于应用的开发、调试、测试都比较友好，反过来这些点在非阻塞模型的 WebFlux 中就变成了缺点。

为什么要用 WebFlux

为什么要用 WebFlux ？或者换句话说 WebFlux 有什么优点？

首先是吞吐量

随着每个请求的被处理时间越长、并发请求的量级越大，WebFlux 相比 SpringMVC 的整体吞吐量高的越多，平均的请求响应时间越短。如下图所示

吞吐量大了，意味着单位时间内可以处理的请求数变多了，比如原来 1w 个请求 10 秒处理完，现在 10w 个请求也是 10 秒处理完，就代表吞吐上去了。注意，是吞吐上去了，不代表单次请求快了，单次请求的速度和原来一样。

非阻塞

传统阻塞 IO 模型的不足包括

每个连接都需要独立线程处理，当并发数大时，创建线程数多，占用资源
采用阻塞 IO 模型，连接建立后，若当前线程没有数据可读，线程会阻塞在读操作上，造成资源浪费

针对传统阻塞 IO 模型的两个问题，可以采用如下的方案

基于池化思想，避免为每个连接创建线程，连接完成后将业务处理交给线程池处理
基于 IO 复用模型，多个连接共用同一个阻塞对象，不用等待所有的连接。遍历到有新数据可以处理时，操作系统会通知程序，线程跳出阻塞状态，进行业务逻辑处理

Netty 所用的 Reactor 线程模型，就解决了阻塞 IO 的问题，具体来讲，它使用的是主从 Reactor 多线程模型

同时 Netty 自身也很好地利用了 IO 多路复用、epoll 优化、零拷贝等技术，极大程度上优化了 IO 的性能。我们知道 SpringWebFlux 底层也依赖了 Netty ，所以也获得了 Netty 带来的优势。这一点可以概括为应用的弹性或伸缩性。根据实际请求量的大小进行资源的伸缩。

Mono Flux

前提：这里的例子使用的框架是 SpringBoot ，版本为 2.3.12.RELEASE 相应的 Spring 的大版本是 5，JDK 11

我们用两个最简单的例子，演示下用 Spring WebFlux 怎么写 Web 的 controller

当然首先要添加相关依赖

 1<dependency>
 2 <groupId>org.springframework.boot</groupId>
 3 <artifactId>spring-boot-starter-webflux</artifactId>
 4</dependency>
 5
 6@RestController
 7@RequestMapping("/webflux")
 8public class HelloController {
 9
10 @GetMapping("/hello")
11 public Mono<String> hello() {
12 return Mono.just("Hello Spring Webflux");
13 }
14 
15}
16
17> curl http://localhost:8080/webflux/hello
18Hello Spring Webflux

我们再来一个返回对象列表的例子：

 1 @GetMapping("/posts")
 2 public Flux<Post> posts() {
 3
 4 WebClient webClient = WebClient.create();
 5 Flux<Post> postFlux = webClient.get().uri("http://jsonplaceholder.typicode.com/posts").retrieve().bodyToFlux(Post.class);
 6
 7 return postFlux;
 8 }
 9
10@NoArgsConstructor
11@Data
12public class Post {
13
14 private Integer userId;
15 private Integer id;
16 private String title;
17 private String body;
18
19}

浏览器请求 http://localhost:8080/webflux/posts ，得到

解释一下这个例子，WebClient 是 Spring5 以后提供的，可以替代 RestTemplate，我们利用 WebClient 请求 jsonplaceholder 提供的 json 对象数组，将返回的结果映射成为 Post 对象，然后直接将 Post 对象列表返回给客户端。

有关 WebClient 的具体 API 这里先不做过多解释，我们看一下 Mono 和 Flux 这两个陌生的类。在 WebFlux 中他们均能充当响应式编程中发布者的角色，不同的是：

Mono：返回 0 或 1 个元素，即单个对象。
Flux：返回 N 个元素，即 List 列表对象。

此外，在应用启动后，通过 IDEA 的控制台可以明显看到 Server 已经不是 Tomcat 了，而是 Netty

如果你没有看到 Netty 还是 Tomcat 的话，可能是你的pom.xml 中同时包含了以下两个依赖：

1 <dependency>
2 <groupId>org.springframework.boot</groupId>
3 <artifactId>spring-boot-starter-web</artifactId>
4 </dependency>
5
6 <dependency>
7 <groupId>org.springframework.boot</groupId>
8 <artifactId>spring-boot-starter-webflux</artifactId>
9 </dependency>

解决的方案是去掉 spring-boot-starter-web 依赖，这样 Server 就切换到了 Netty。

Stream

既然叫 Reactive Stream 我们就用下面一个例子找一找流的感觉：

 1@GetMapping(value = "/flux", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
 2public Flux<String> flux() {
 3 Flux<String> flux = Flux.fromArray(new String[]{"a", "b", "c", "d"}).map(s -> {
 4 try {
 5 Thread.sleep(1000);
 6 } catch (InterruptedException e) {
 7 e.printStackTrace();
 8 }
 9 return "<letter:" + s + ">";
10 });
11 return flux;
12}

看下效果：

浏览器每隔一秒显示下一条数据，这正是流的效果，是不是有点儿像 WebSocket ？其实并不完全一样。奥妙在这里 text/event-stream，这其实也是服务器向浏览器推送消息的一种方案。感兴趣的同学可以搜索一下 WebSocket 和 SSE 的区别。

请求分发

Spring MVC 的前端控制器是 DispatcherServlet, 而 WebFlux 是 DispatcherHandler，它实现了 WebHandler 接口，主要看 handle 方法

DB

有文章说，WebFlux 还不支持 MySQL ，可能是文章发布的较早，当时 R2DBC 没来得及支持那么多的数据库，只支持了 MongoDB 和 PostgreSQL 等几个。现在这个时间点 R2DBC 支持的数据库就比较多了，也包含了 MySQL（参数上文）

Spring Data R2DBC 可以与 Spring Data JPA 结合使用，其实 R2DBC 与原来的 JPA 使用方式差别不大，使用非常简单。只是 Spring Data JPA 中方法返回的是真实的值，而 R2DBC 中，返回的是数据流Mono，Flux。

更多 R2DBC 的介绍，可以参考 Spring 的官方文档：https://docs.spring.io/spring-data/r2dbc/docs/1.3.2/reference/html/#r2dbc.core

有兴趣的同学可以用 Spring WebFlux + R2DBC+MySQL ，实现一下 CRUD 操作。就是一个从头到尾彻彻底底的响应式非阻塞应用。

WebClient

Spring 5 引入了新的 WebClientAPI，取代了现有的 RestTemplate 客户端。使用 WebClient 您可以使用功能流畅的 API 发出同步或异步 HTTP 请求，该 API 可以直接集成到您现有的 Spring 配置和 WebFlux 反应式框架中。

一个例子：

 1 private static void testWebClient() {
 2
 3 WebClient webClient = WebClient.create();
 4 monoTest(webClient, "http://jsonplaceholder.typicode.com/posts/1");
 5
 6 }
 7 /**
 8 * 从 API 获取单个帖子
 9 */
10 private static void monoTest(WebClient webClient, String uri) {
11 //要注意此时实际上还没有发送任何请求！作为一个反应式 API，在某些尝试读取或等待响应之前，不会实际发送请求。
12 Mono<Post> postMono = webClient.get().uri(uri).retrieve().bodyToMono(Post.class);
13 Post post1 = postMono.blockOptional().get();
14 log.info(post1.getTitle());
15
16 }

上面的是 Mono 的，再来一个 Flux 的（获得 post list 并将 id 求和）：

 1/**
 2 * 获取 post 列表 ，使用 Flux 因为是多值 , 要是获取一个对象比如 `posts/1` 就可以用 Mono
 3 *
 4 * @param webClient
 5 * @param uri
 6 */
 7private static void fluxTest(WebClient webClient, String uri) {
 8 
 9 // retrieve() 方法是获取响应主体并对其进行解码
10 Flux<Post> postFlux = webClient.get().uri(uri).retrieve().bodyToFlux(Post.class);
11 List<Post> posts = postFlux.collectList().block();
12 Integer idSum = posts.stream().mapToInt(post -> post.getId()).reduce(0, (a, b) -> a + b);
13 log.info(idSum);
14}

总结

Reactive Programming 作为观察者模式（Observer）的延伸，不同于传统的命令编程方式（ Imperative programming）同步拉取数据的方式，如迭代器模式（Iterator）。而是采用数据发布者同步或异步地推送到数据流（Data Streams）的方案。

当该数据流（Data Steams）订阅者监听到传播变化时，立即作出响应动作。在实现层面上，Reactive Programming 可结合函数式编程简化面向对象语言语法的臃肿性，屏蔽并发实现的复杂细节，提供数据流的有序操作，从而达到提升代码的可读性，以及减少 Bugs 出现的目的。同时，Reactive Programming 结合背压（Backpressure）的技术解决发布端生成数据的速率高于订阅端消费的问题。

如果说 Spring Cloud 是从【宏观系统层面的开发】角度在实践健壮的高可用系统+系统运维，K8S 在【DEV OPS】层面实践更好的系统运维，Service Mesh 在【基础设施层（infra）】实践健壮的高可用系统+系统运维，那么 WebFlux（包括整个 Reactive Stack 体系的其他成员）就是从【微观项目层面的开发】角度在实践健壮的高可用系统+系统运维。或多或少，它们都从各个维度在朝着“更少的人治”角度去努力。

GitHub 地址

代码示例我放到了 github 上：https://github.com/xiaobox/Spring-WebFlux-Demo

参考

聊聊 Java 的单元测试

Tue, 02 Aug 2022 13:13:24 +0000

单元测试框架

Java 中，JUnit 和 TestNG 是最受欢迎的单元测试框架。

JUnit
TestNG

JUnit

首先是大名鼎鼎的 JUnit ，JUnit 已经成为 Java 应用程序单元测试的事实标准。

JUnit 是一个开源的 Java 语言的单元测试框架，专门针对 Java 设计，使用最广泛。JUnit 目前最新版本是 5

JUnit5 的组成：JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage

JUnit5 建议使用 Java8 及以上版本

JUnit Platform 是在 JVM 上启动测试框架的基础，它定义了TestEngine在平台运行的新测试框架的 API
JUnit Jupiter 它用于编写测试代码的新的编程和扩展模型。它具有所有新的 Junit 注释和TestEngine实现来运行这些注释编写的测试。
JUnit Vintage JUnit4 已经存在了很长时间，并且有许多以 JUnit4 编写的测试。JUnit Jupiter 还需要支持这些测试。为此，开发了 JUnit Vintage 子项目。提供了一个测试引擎，用于在平台上运行基于 JUnit 3 和 JUnit 4 的测试。它要求 JUnit 4.12 或更高版本出现在类路径或模块路径中。从它的名字 Vintage（古老的；古色古香的）中也能有所体会。

简单例子

我们先来个最简单的例子，别看简单，很多人会犯错

1@SpringBootTest
2@RunWith(SpringRunner.class)
3public class JunitTest {
4 @Test
5 public void testJunit(){
6 System.out.println("junit test");
7 }
8}

很简单对吧，如果你用了 SpringBoot 简单到好像没啥说的，其实不然，我们来聊聊：

首先，这段代码使用的是 JUnit 4 还是 JUnit5 ? 你可能会觉得，4 和 5 没啥区别吧，用哪个不一样吗？代码能跑不就行了？

不是的，4 和 5 肯定有区别这个不用我说了。能跑没问题，但如果你不管是 4 还是 5 都认为一样，API 混用，甚至乱用，那这时候测试出现的各种报错，导致你很懵逼，而且不知道为什么，一通乱查也不知所然。

上面这段代码其实是 JUnit 4 版本，我们看一下 import 就一目了然了，然而可能你在开发的时候没太注意这里是 4 还是 5

1import org.junit.Test;
2import org.junit.runner.RunWith;
3import org.springframework.boot.test.context.SpringBootTest;
4import org.springframework.test.context.junit4.SpringRunner;

这里确定了，使用的是 4 的版本，这里有几个要注意的点：

@Test的包是org.junit.Test ，不要搞错了，因为有好几个同名包
需要@RunWith(SpringRunner.class)
测试类和测试方法需要public修饰

我们看下完整的例子：

 1import org.junit.Test;
 2import org.junit.runner.RunWith;
 3import org.springframework.boot.test.context.SpringBootTest;
 4import org.springframework.test.context.junit4.SpringRunner;
 5
 6@SpringBootTest
 7@RunWith(SpringRunner.class)
 8public class JunitTest {
 9 @Test
10 public void testJunit(){
11 System.out.println("junit test ");
12 }
13}

这里强调下环境，springboot2.2.x 之前支持 JUnit 4

上面有一点提到了需要 public 修饰的问题，这不很正常吗，为什么要强调？

那是因为 JUnit 5 不需要了，我们看一下用 JUnit 5 来实现的同样的例子 (SpringBoot 2.2.x 之后支持 JUnit 5)：

 1import org.junit.jupiter.api.Test;
 2import org.springframework.boot.test.context.SpringBootTest;
 3
 4@SpringBootTest
 5class JunitTest {
 6 @Test
 7 void testJunit5(){
 8 System.out.println("junit5");
 9 }
10}

这么简单吗？对，就是这么简单，所以我说 4 和 5 不一样。我们来看区别的地方：

@Test的包是org.junit.jupiter.api.Test
不需要@RunWith(SpringRunner.class)
测试类和测试方法不需要public修饰

我见过很多同学在写测试用例时出现的所谓诡异问题，都是因为他自己都没搞清楚用的是 4 还是 5 的情况下将 4 和 5 混用导致的。

如果你的测试用例是 4 ，可以迁移到 5 了，有关 JUnit 4 迁移到 JUnit5 的话题可以参考这篇文章，通过工具可能节省很多时间：https://blog.jetbrains.com/idea/2020/08/migrating-from-junit-4-to-junit-5/

我们再来看一下 pom 依赖这里，你是不是经常看到有关 test 的依赖是这样写的：

 1<dependency>
 2 <groupId>org.springframework.boot</groupId>
 3 <artifactId>spring-boot-starter-test</artifactId>
 4 <scope>test</scope>
 5 <exclusions>
 6 <exclusion>
 7 <groupId>org.junit.vintage</groupId>
 8 <artifactId>junit-vintage-engine</artifactId>
 9 </exclusion>
10 </exclusions>
11</dependency>

为啥？为什么要排除 junit-vintage-engine ？如果你认真阅读了前文，你应该能猜到为什么了。

JUnit Vintage 是为了兼容 3 和 4 的一个 engine，如果我们的测试代码都用 5 实现，不需要兼容 3 和 4 ，那要它干嘛？当然是干掉呀，哈哈。

但如果你需要兼容，那请不要那么鲁莽。上面的这段 dependency 主要用于 spring-boot-starter-test 的 2.2.x 和 2.3.x 版本中。spring-boot-starter-test 2.4.x 版本中，已经不再包含 junit-vintage-engine 这个依赖项了

常规套路

Annotations	描述
`@BeforeEach`	在方法上注解，在每个测试方法运行之前执行。
`@AfterEach`	在方法上注解，在每个测试方法运行之后执行
`@BeforeAll`	该注解方法会在所有测试方法之前运行，该方法必须是静态的。
`@AfterAll`	该注解方法会在所有测试方法之后运行，该方法必须是静态的。
`@Test`	用于将方法标记为测试方法
`@DisplayName`	用于为测试类或测试方法提供任何自定义显示名称
`@Disable`	用于禁用或忽略测试类或方法
`@Nested`	用于创建嵌套测试类
`@Tag`	用于测试发现或过滤的标签来标记测试方法或类
`@TestFactory`	标记一种方法是动态测试的测试工场

常规套路不说了，比较简单，一看就明白，说几个有意思的。

重复性测试

1 @RepeatedTest(5)
2 void repeatTest(TestInfo testInfo,RepetitionInfo repetitionInfo){
3
4 System.out.println("repeat:" + testInfo.getDisplayName());
5 System.out.println("这是第 "+ repetitionInfo.getCurrentRepetition()+ "次重复");
6
7 }

不用自己写 for 循环了，人家自己带重复的注解，上面两个变量也是自己带的，方便拿到重复信息。

基于参数测试

1@ParameterizedTest
2@ValueSource(strings = {"java", "python", "go"})
3void containsChar(String candidate) {
4 assertTrue(candidate.contains("o"));
5}

如果你的参数少，也不用写循环了，直接写注解里，还挺方便的。

超时测试

1 @Test
2 @Timeout(value = 500, unit = TimeUnit.MILLISECONDS)
3 void failsIfExecutionTimeExceeds500Milliseconds() {
4 // fails if execution time exceeds 500 milliseconds
5 }

可以设置超时的单位和时长

在 assert 中也可以测超时，可以这样写：

 1 // timed out after 5 seconds
 2 @Test
 3 void test_timeout_fail() {
 4 // assertTimeout(Duration.ofSeconds(5), () -> delaySecond(10)); // this will fail
 5
 6 assertTimeout(Duration.ofSeconds(5), () -> delaySecond(1)); // pass
 7 }
 8
 9 void delaySecond(int second) {
10 try {
11 TimeUnit.SECONDS.sleep(second);
12 } catch (InterruptedException e) {
13 e.printStackTrace();
14 }
15 }

并行测试

以上测试用例都是用主线程或者单线程跑的，下面我们玩儿个多线程并行 test

首先你要在你的 classpath 下面建一个文件 junit-platform.properties

接着加两行配置

1junit.jupiter.execution.parallel.enabled=true
2junit.jupiter.execution.parallel.mode.default=concurrent

行了，再跑你的用例就是多线程并行执行的了，当然如果用例本来就设计成单线程的看不出来，那可以使用 Repeat 试一下，比如上面讲过的这个：

1 @RepeatedTest(5)
2 void repeatTest(TestInfo testInfo,RepetitionInfo repetitionInfo){
3
4 System.out.println("repeat:" + testInfo.getDisplayName());
5 System.out.println("这是第 "+ repetitionInfo.getCurrentRepetition()+ "次重复");
6
7 }

上面这个是对一个方法的重复执行并行，有时候我们是想让一个类中的多个方法并行，能不能做到？可以，改下配置就好了

1junit.jupiter.execution.parallel.enabled = true
2junit.jupiter.execution.parallel.mode.default = concurrent
3junit.jupiter.execution.parallel.mode.classes.default = same_thread

如果反过来呢？多个类并行，类中的方法串行 也可以，还是改配置：

1junit.jupiter.execution.parallel.enabled = true
2junit.jupiter.execution.parallel.mode.default = same_thread
3junit.jupiter.execution.parallel.mode.classes.default = concurrent

MockMVC

你测个 service 测个 dao 很简单，把 Bean 注入就可以了，Controller 怎么测？我们要利用下 MockMVC 了

“

MockMvc 实现了对 Http 请求的模拟，能够直接使用网络的形式，转换到 Controller 的调用，这样可以使得测试速度快、不依赖网络环境，而且提供了一套验证的工具，这样可以使得请求的验证统一而且很方便。

”

我们先看一个简单的例子：

 1import org.junit.jupiter.api.*;
 2import org.springframework.beans.factory.annotation.Autowired;
 3import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
 4import org.springframework.boot.test.context.SpringBootTest;
 5import org.springframework.test.web.servlet.MockMvc;
 6import static org.hamcrest.Matchers.containsString;
 7import static org.junit.jupiter.api.Assertions.assertTrue;
 8import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
 9import static org.springframework.test.web.servlet.result.MockMvcResultHandlers.print;
10import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content;
11import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
12
13@SpringBootTest
14@AutoConfigureMockMvc
15class HelloControllerTest {
16
17 @Autowired
18 private MockMvc mockMvc;
19
20 @Autowired
21 private HelloController helloController;
22
23 @Test
24 public void shouldReturnDefaultMessage() throws Exception {
25
26 this.mockMvc.perform(get("/hello"))
27 .andDo(print())
28 .andExpect(status().isOk())
29 .andExpect(content().string(containsString("Hello World")));
30 }
31 }

解释下没见过的注解：

@AutoConfigureMockMvc：用于自动配置 MockMvc, 配置后 MockMvc 类可以直接注入

此外我们利用 @Autowired 注入了一个 MockMvc 的 Bean 实例。我们通过这个例子来模拟请求 /hello 这个 Controller 资源，并且通过判断返回的 content 内容是否包含 Hello World 字符串来决定这个用例的执行是否成功。

注意 imports 部分，我们导入了 MockMvcRequestBuilders 的一些静态方法。整个方法就一行代码，解释一下：

perform : 执行一个请求
andDo : 添加一个结果处理器，表示要对结果做点什么事情，比如此处使用 print()：输出整个响应结果信息
andExpect : 添加执行完成后的断言

我们看下执行结果：

 1MockHttpServletRequest:
 2 HTTP Method = GET
 3 Request URI = /hello
 4 Parameters = {}
 5 Headers = []
 6 Body = null
 7 Session Attrs = {}
 8
 9Handler:
10 Type = com.xiaobox.springbootdemo.controller.HelloController
11 Method = com.xiaobox.springbootdemo.controller.HelloController#hello(String)
12
13Async:
14 Async started = false
15 Async result = null
16
17Resolved Exception:
18 Type = null
19
20ModelAndView:
21 View name = null
22 View = null
23 Model = null
24
25FlashMap:
26 Attributes = null
27
28MockHttpServletResponse:
29 Status = 200
30 Error message = null
31 Headers = [Content-Type:"text/plain;charset=UTF-8", Content-Length:"12"]
32 Content type = text/plain;charset=UTF-8
33 Body = Hello World!
34 Forwarded URL = null
35 Redirected URL = null
36 Cookies = []

我们来看下一个例子

 1
 2@WebMvcTest
 3class HelloControllerTest {
 4
 5 @Autowired
 6 private MockMvc mockMvc;
 7
 8 @Autowired
 9 private HelloController helloController;
10
11 @Test
12 public void shouldReturnDefaultMessage() throws Exception {
13
14 this.mockMvc.perform(get("/hello"))
15 .andDo(print())
16 .andExpect(status().isOk())
17 .andExpect(content().string(containsString("Hello World")));
18 }
19 }

你发现我们只是把 class 头上的注解换成了 @WebMvcTest，其实的没变，是的。但却比上一段代码快 3 倍。为什么？

因为之前的写法会把 Spring 完整的应用上下文全启动了，而 @WebMvcTest 是将测试范围缩小到仅启动 web 层，所以会快。当你只想测试 http 到 controller 这层的时候，可以用 @WebMvcTest 注解。

你甚至还可以告诉框架只启动某一个 controller 这样更快，比如：@WebMvcTest(HomeController.class)

上面是 WebMvcTest 的第一个场景，我们来看第二个场景：也是测 controller ，但 controller 调用的 service 我们也 mock，不走真正 service 代码逻辑。这在有时你的 service 没准备好，或者不方便直接调用时会很有用。

 1@WebMvcTest
 2class HelloControllerTest {
 3
 4 @Autowired
 5 private MockMvc mockMvc;
 6
 7 @Autowired
 8 private HelloController helloController;
 9
10 @Test
11 public void greetingShouldReturnMessageFromService() throws Exception {
12
13 Mockito.when(service.greet()).thenReturn("Hello, Mock");
14 
15 this.mockMvc.perform(get("/greeting")).andDo(print()).andExpect(status().isOk())
16 .andExpect(content().string(containsString("Hello, Mock")));
17 }
18 
19 }

上面的代码我们用到了 Mockito，可能你听过周杰伦一首新歌叫 Mojito ，对，Mockito 的命名就是对 Mojito（一种传统的古巴高球鸡尾酒）的戏称

简单来说 Mockito 是一个 java 做单元测试的 Mock 框架：https://site.mockito.org/

解释下我们上面这行代码 Mockito.when(service.greet()).thenReturn("Hello, Mock");

意为：当调用 service 的 greet 方法的时候，返回值为 “Hello Mock”，其实没真调那个方法，就是 Mock 了一下，直接给了个返回值。用英文说就是：When the x method is called then return y

当然 Mockito 在假造上是很有实力的，它有丰富的 API 供你组合使用，有兴趣可以看一看文档和源码注释。

讲到这儿，一定有同学会问，只测 Controller ，那我就用 Postman 就行了，甚至 curl 都行，为啥要写用例，我不写用例。

哈哈，我相信很多后端同学都没认认真真把用例写完，尤其是 controller 这层的，不装逼，我也是。那我们有必要讨论一下 到底是用 Postman 还是用 MockMVC ？

首先说说 MockMVC 的好处：

可编程，这就给了你无限的自由空间，想怎么折腾随便你，你是上帝
除了写的时候花点时间外，调试的时候速度快，而且可配置，你要想只测 controller，就只启动 controller 的上下文就行了
顺便把测试用例写了，测试同学省心了，给自动化测试提供了基础
间接提高代码质量

其他的我不说，我就说最后一点。我注意到一个现象，很多开发同学拿测试同学当工具人，自己写的代码自己不怎么测试，直接交给测试让他们提 BUG，然后改，BUG 多也不觉得害臊。开发是爽了，由于代码质量差，整个项目的进度都被拖慢了。你可能会说这是软件质量管理的问题，是规则制定的有问题，如果出 BUG 扣钱就没这事儿了。

我要说的是，在软件开发这个领域，很多事情不是刻板的死规则，即便是制定了这样的规则，也不一定有效。更多的时候是整个团队的文化和风气，领导者有责任将整个研发团队的文化和风气带向正轨。什么是正轨？其实我们都知道！我们都知道应该写高质量的代码，bug 少的代码，设计合理的代码，不断重构、不断维护的代码，我们都知道要做好自己的事就会提高整个团队的效率，我们都知道应该写注释、写文档，我们都知道…..

我们都知道，但我们也知道项目时间紧，而且专门有人一遍遍强调 deadLine ，有人关心你的开发进度，关心功能实现了没有，关心老板有没有意见，没有人关心你累不累，关心你几点下的班，关心规划合不合理，关心代码质量高不高，关心与软件真正有关系的一切。所以做一个真正的软件研发团队的 Leader 不容易，遇到好 Leader 是你的福气。

扯多了，我们回头来看 Postman ,Postman 的好处好像也不用我多说了，确实，如果只是简单的做 Controller 连通测试，用 Postman 一点儿问题没有，也比写程序快，但如果你的需求时有正好是 MockMVC 的优点可以覆盖的地方，那么就动动手，写写程序吧。

测试报告

想成一份漂亮的测试报告？后端同学说了，整那花里胡哨的有啥用呢，简单一点儿不好吗？

好，简单点儿当然可以，但 UI 带给我们的价值不就是一图胜千言嘛，让无论是前端、后端、测试同学都能一目了然，减轻大脑处理信息的成本。

来，我们先上成果

怎么样，还挺好看的吧，我们用的是 Allure 来生成了一个 web 页面，这个页面还有一些简单的交互，整体简洁好看、易用。

下面我们说一下 Allure 怎么和 JUnit 集成的

我们仍然使用 SpringBoot 以及 JUnit 5 ，先修改一下 pom.xml 文件，添加依赖

 1 <dependency>
 2 <groupId>org.springframework.boot</groupId>
 3 <artifactId>spring-boot-starter-test</artifactId>
 4 <scope>test</scope>
 5 <exclusions>
 6 <exclusion>
 7 <groupId>org.junit.vintage</groupId>
 8 <artifactId>junit-vintage-engine</artifactId>
 9 </exclusion>
10 </exclusions>
11</dependency>
12 <!--测试报告 allure -->
13 <dependency>
14 <groupId>io.qameta.allure</groupId>
15 <artifactId>allure-junit5</artifactId>
16 <version>2.18.1</version>
17 <scope>test</scope>
18 </dependency>

然而我们添加在 build 中两个 plugin

 1 <plugin>
 2 <artifactId>maven-surefire-plugin</artifactId>
 3 <version>2.21.0</version>
 4 <configuration>
 5 <testFailureIgnore>false</testFailureIgnore>
 6 <argLine>
 7 -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
 8 </argLine>
 9 <systemProperties>
10 <property>
11 <name>junit.jupiter.extensions.autodetection.enabled</name>
12 <value>true</value>
13 </property>
14 </systemProperties>
15 </configuration>
16 <dependencies>
17 <dependency>
18 <groupId>org.junit.platform</groupId>
19 <artifactId>junit-platform-surefire-provider</artifactId>
20 <version>1.2.0</version>
21 </dependency>
22 <dependency>
23 <groupId>org.aspectj</groupId>
24 <artifactId>aspectjweaver</artifactId>
25 <version>${aspectj.version}</version>
26 </dependency>
27 </dependencies>
28
29 </plugin>
30 <plugin>
31 <groupId>io.qameta.allure</groupId>
32 <artifactId>allure-maven</artifactId>
33 <version>2.11.2</version>
34 <configuration>
35 <reportVersion>2.4.1</reportVersion>
36 </configuration>
37 </plugin>

我们用 brew 在本地安装一下 Allure （我是 mac 就用这个装了，如果你是其他环境参考后面说的文档）

1brew install allure

接着我们调整项目中的测试用例，然后执行：

1mvn clean test

接着找到你项目中 surefire-reports 的目录位置

然后执行类似如下命令：

1# 注意路径改成你自己项目的，这里只是示例
2allure serve /home/path/to/project/target/surefire-reports/

显示如下信息会自动跳转到浏览器，打开测试报告页面。

是不是很简单？

有关 Allure 安装和使用说明请参考：https://docs.qameta.io/allure-report

有关 JUnit5 就聊到这儿，日常一般的开发是够用了。更多的细节和功能，绍假设、断言等，请看官方文档，当然备不注它也有错的时候。

TestNG

TestNG is a testing framework inspired from JUnit and NUnit but introducing some new functionalities that make it more powerful and easier to use, such as:

Annotations.
Run your tests in arbitrarily big thread pools with various policies available (all methods in their own thread, one thread per test class, etc…).
Test that your code is multithread safe.
Flexible test configuration.
Support for data-driven testing (with @DataProvider).
Support for parameters.
Powerful execution model (no more TestSuite).
Supported by a variety of tools and plug-ins (Eclipse, IDEA, Maven, etc…).
Embeds BeanShell for further flexibility.
Default JDK functions for runtime and logging (no dependencies).
Dependent methods for application server testing.

上面是 TestNG 的官方介绍，看起来比 JUnit 功能还强大。有了前面 Junit 作为引子，你再看 TestNG，就好理解的多，因为概念上都差不多，只是功能和细节的不同而已。在这里我们不会展开讲 TestNG 了，但是会讨论一下选型的问题。

如果在 JUnit 5 没出来之前，比如 JUnit4 和 3 的时代，我会毫不犹豫地选择 TestNG，为什么？功能强大，好用啊。但是现在 JUnit5 来了，而且推广的势头也很猛，重要的是从功能上也不输 TestNG，那么怎么选呢？

个人觉得：

如果是后端开发，一般还是选 JUnit 5 写单元测试方便简单些，SpringBoot 也内置了 JUnit 开箱即用，从生态和社区上讲即使有坑也好解决些
如果是搞自动化测试的同学，更多的可能还是用 TestNG 方便些，之前很多遗留项目都是用的 TestNG，另外它和自动化测试工具 selenium 的搭配也早已深入人心。从设计理念到 API，都更符合测试同学的思维。

参考

Make Jar, Not War.

Tue, 05 Jul 2022 09:51:29 +0000

大约在 4 年前，关于 java 应用最终打成 jar 包还是 war 包的选择令我比较疑惑。

那时候更多的应用是打成 war 包的，即使我们知道可以打成 jar 包，但之前都是打成 war 包，并且好像打成 jar 包并没有什么特别明显的好处。

但当时令我困惑的是越来越多的实践正在不怎么说明理由的情况下转而打 jar 包，于是我开始思考……

war 包的理由

在某大型 OTA 企业内部，应用仍然打成 war 包, PaaS 平台会自动安装并配置好 tomcat，我知道这对于 web server 的统一配置和运维来说是有好处的。基于 war 背后的一系列 CI/CD 、DevOps 流程都一定有相应的适配，且就算 jar 包有我不知道的某些优势也不可能一夜之间在大型企业内部使用，需要平台和系统做出调整。

SpringBoot 在当时并未像现在这样流行，这并不意味着大家不用它，我的意思是相对新的项目来说，企业内部会有非常多 “老系统” 需要维护，我们不能指望一下子把这些老系统都用新的技术栈替换掉，就像你知道现在 web application 一般是前后端分离开发，但如果接手一个使用 jsp 的老家伙，你还得维护不是？

jar 的时代

时代不同了，说得好像过了几十年的样子，但其实也就几年光阴而已。不过仅仅是这几年的光阴却足以改变一些事情的面貌。

如今，云原生、微服务大行其道，大家好像已经非常适应这种开发模式，没有人纠结要不要用 SpringBoot，只会讨论使用的版本高还是低。更不用说打包的事情，很自然的会使用 jar,虽然这种看起来的 “最佳实践”，在长期开发的过程中会形成 “肌肉记忆”，但我们还是要讨论一下为什么。

方便

可运行 Jar 是打包自包含可运行应用程序的便捷方法。这样，我们可以最大限度地减少依赖关系。可以通过 Spring boot Maven 和 Gradle plugin 来管理依赖。

云原生友好

在自备容器的情况下（docker,k8s), jar 包可以直接作为一个 single application 来管理。

在过去我们使用 war 是为了让多应用共享 web server，现在是容器的天下，在容器内，一般情况只跑一个应用进程。由于只有一个进程，我们就可以轻松地管理它，比如重启（不会影响其他的应用，因为没有其他应用）。

版本控制

利用 git 等版本控制软件，可以控制程序运行所需要的一切（比如配置文件）

易于扩展

例如，将其复制到另一台服务器，然后“ just run it!” 无需安装和/或配置容器

参考

https://medium.com/@satyajit.nalavade/make-jar-not-war-josh-long-d6ce5fbb8a23

灰度发布、蓝绿部署、金丝雀都是啥？

Tue, 19 Apr 2022 07:13:43 +0000

滚动部署

在滚动部署中，应用的新版本逐步替换旧版本。实际的部署发生在一段时间内。在此期间，新旧版本会共存，而不会影响功能和用户体验。这个过程可以更轻易的回滚和旧组件不兼容的任何新组件。

下图显示了该部署模式：旧版本显示为蓝色，新版本显示为绿色，它们部署在集群中的每一台服务器上。

应用程序套件升级是一个滚动部署的典型例子。如果原始应用部署在容器中，升级可以一次处理一个容器。修改每个容器从应用供应商的站点上下载最新的镜像。如果其中的一个应用存在兼容性问题，旧的镜像可以重新创建这个容器。在这种情况下，套件的新旧版本应用可以共存，直到每个应用都更新完毕。

但是滚动升级有一个问题，在开始滚动升级后，流量会直接流向已经启动起来的新版本，但是这个时候，新版本是不一定可用的，比如需要进一步的测试才能确认。那么在滚动升级期间，整个系统就处于非常不稳定的状态，如果发现了问题，也比较难以确定是新版本还是老版本造成的问题。

为了解决这个问题，我们需要为滚动升级实现流量控制能力。

蓝绿发布

蓝绿发布提供了一种零宕机的部署方式。不停老版本，部署新版本进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。始终有两个版本同时在线，有问题可以快速切换。

蓝绿发布的特点：

在部署应用的过程中，应用始终在线。并且新版本上线过程中，不会修改老版本的任何内容，在部署期间老版本状态不受影响。只要老版本的资源不被删除，可以在任何时间回滚到老版本。

以下示意图可描述灰度发布的大致流程：先切分20%的流量到新版本，若表现正常，逐步增加流量占比，继续测试新版本表现。若新版本一直很稳定，那么将所有流量都切分到新版本，并下线老版本。

切分20%的流量到新版本后，新版本出现异常，则快速将流量切回老版本。

蓝绿部署要求在升级过程中，同时运行两套程序，对硬件的要求就是日常所需的二倍，比如日常运行时，需要10台服务器支撑业务，那么使用蓝绿部署，你就需要购置二十台服务器。

为什么还需要蓝绿

有了灰度发布之后，为什么还需要蓝绿发布呢？主要有如下几点考虑：

应用在生产环境全量发布后，发现故障时回滚时间慢。当线上核心应用存在几十上百的服务实例时，应用实例分批滚动回滚，部分业务应用启动时间需要几分钟，导致整个回滚过程的时间可能超过十分钟，甚至几十分钟。
灰度发布期间能发现的问题有限。如数据库慢查问题、死锁问题等，10%流量很难发现，可能只会在100%流量中才容易暴露。
灰度发布成功后，仍然需要进行全量发布，在此过程中仍有较多不确定性，如因一些未预料的异常导致发布失败等。

对于上面几个问题，使用蓝绿发布系统都可以较好地解决：

蓝绿发布期间，流量全部切至新集群时，原稳定集群继续保持在线，若新集群有问题，可通过流量控制秒级切回至原稳定集群，没有应用启动以及其他等待时间。
蓝绿发布期间，新集群规模与原稳定集群规模一致，即使是瞬时大流量也没有问题。
蓝绿发布期间，新集群承载全站流量，容易验证各种场景，如数据库死锁等并发问题。
蓝绿发布新集群验证完成后，已经处于正常服务状态，不会再引入不确定性的变更操作。

金丝雀发布（canary）

在生产环境上引一部分实际流量对一个新版本进行测试，测试新版本的性能和表现，在保证系统整体稳定运行的前提下，尽早发现新版本在实际环境上的问题。

“

为什么叫金丝雀发布呢，是因为金丝雀对矿场中的毒气比较敏感，所以在矿场开工前工人们会放一只金丝雀进去，以验证矿场是否存在毒气，这便是金丝雀发布名称的由来。

”

金丝雀发布的特点：

通过在线上运行的服务中，新加入少量的新版本的服务，然后从这少量的新版本中快速获得反馈，根据反馈决定最后的交付形态。

下图为华为云的金丝雀发布界面：

步骤一：将流量从待部署节点移出，更新该节点服务到待发布状态，将该节点称为金丝雀节点；

步骤二：根据不同策略，将流量引入金丝雀节点。策略可以根据情况指定，比如随机样本策略（随机引入）、狗粮策略（就是内部用户或员工先尝鲜）、分区策略（不同区域用户使用不同版本）、用户特征策略（这种比较复杂，需要根据用户个人资料和特征进行分流，类似于千人千面）；

步骤三：金丝雀节点验证通过后，选取更多的节点称为金丝雀节点，重复步骤一和步骤二，直到所有节点全部更新

金丝雀部署和蓝绿有点像，但是它更加规避风险。你可以阶段性的进行，而不用一次性从蓝色版本切换到绿色版本。

采用金丝雀部署，你可以在生产环境的基础设施中小范围的部署新的应用代码。一旦应用签署发布，只有少数用户被路由到它。最大限度的降低影响。如果没有错误发生，新版本可以逐渐推广到整个基础设施。下图示范了金丝雀部署：

金丝雀和蓝绿的对比

名称	特点	优势	劣势
蓝绿部署	同时存在两个集群，两个集群中只有一个集群真正提供服务，另外一个集群测试、验证或待命	服务文档，版本回退简单，适用于各种场景的升级，大版本不兼容升级的或迭代兼容升级	浪费硬件资源，需要同时有两个集群，如果集群比较大，比如有1000个节点，这种方式几乎不可用
金丝雀部署	逐点部署，逐步替换线上服务	小步快跑，快速迭代	只能适用于兼容迭代的方式，如果是大版本不兼容的场景，就没办法使用这种方式了

灰度发布

灰度发布是迭代的软件产品在生产环境安全上线的一种重要手段。

灰度发布，也叫金丝雀发布。是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度，而我们平常所说的金丝雀部署也就是灰度发布的一种方式。

A/B Test

A/B测试和蓝绿发布、滚动发布以及金丝雀发布，完全是两回事。

蓝绿发布、滚动发布和金丝雀是发布策略，目标是确保新上线的系统稳定，关注的是新系统的BUG、隐患。

A/B测试是效果测试，同一时间有多个版本的服务对外服务，这些服务都是经过足够测试，达到了上线标准的服务，有差异但是没有新旧之分（它们上线时可能采用了蓝绿部署的方式）。

A/B测试关注的是不同版本的服务的实际效果，譬如说转化率、订单情况等。

A/B测试时，线上同时运行多个版本的服务，这些服务通常会有一些体验上的差异，譬如说页面样式、颜色、操作流程不同。相关人员通过分析各个版本服务的实际效果，选出效果最好的版本。

实现

kubernetes

官方的金丝雀发布方式

https://kubernetes.io/zh/docs/concepts/cluster-administration/manage-deployment/#canary-deployments

Deployment滚动更新策略实现金丝雀发布

利用Deployment的滚动更新策略maxSurge和maxUnavailable设置最大可超期望的节点数和最大不可用节点数可实现简单的金丝雀发布。

rollingUpdate.maxSurge最大可超期望的节点数，百分比 10% 或者绝对数值 5

rollingUpdate.maxUnavailable最大不可用节点数，百分比或者绝对数值

 1apiVersion: extensions/v1beta1
 2kind: Deployment
 3metadata:
 4 name: demo-deployment
 5 namespace: default
 6spec:
 7 replicas: 10
 8 selector:
 9 matchLabels:
10 name: hello-deployment
11 strategy:
12 type: RollingUpdate
13 rollingUpdate:
14 maxSurge: 10%
15 maxUnavailable: 0 
16 template:
17 metadata:
18 labels:
19 name: demo-deployment
20 spec:
21 containers:
22 - name: webserver
23 image: nginx:1.14
24 ports:
25 - containerPort:80
26

Ingress-Nginx配置Ingress Annotations实现金丝雀发布

Ingress-Nginx 支持配置 Ingress Annotations 来实现不同场景下的金丝雀发布。Nginx Annotations 支持以下 4 种 Canary 规则：

nginx.ingress.kubernetes.io/canary-by-header：基于 Request Header 的流量切分，适用于灰度发布以及 A/B 测试。当 Request Header 设置为 always时，请求将会被一直发送到 Canary 版本；当 Request Header 设置为 never时，请求不会被发送到 Canary 入口；对于任何其他 Header 值，将忽略 Header，并通过优先级将请求与其他金丝雀规则进行优先级的比较。
nginx.ingress.kubernetes.io/canary-by-header-value：要匹配的 Request Header 的值，用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值时，它将被路由到 Canary 入口。该规则允许用户自定义 Request Header 的值，必须与上一个 annotation (即：canary-by-header）一起使用。
nginx.ingress.kubernetes.io/canary-weight：基于服务权重的流量切分，适用于蓝绿部署，权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求。权重为 100 意味着所有请求都将被发送到 Canary 入口。
nginx.ingress.kubernetes.io/canary-by-cookie：基于 Cookie 的流量切分，适用于灰度发布与 A/B 测试。用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务的cookie。当 cookie 值设置为 always时，它将被路由到 Canary 入口；当 cookie 值设置为 never时，请求不会被发送到 Canary 入口；对于任何其他值，将忽略 cookie 并将请求与其他金丝雀规则进行优先级的比较。

注意：金丝雀规则按优先顺序进行如下排序：canary-by-header - > canary-by-cookie - > canary-weight很显然

canary-weight是一种随机策略。

canary-by-cookie和canary-by-header-value适合后端金丝雀发布实现

canary-by-cookie适合前端金丝雀发布实现。

 1apiVersion: extensions/v1beta1
 2kind: Ingress
 3metadata:
 4 name: demo-canary
 5 annotations: 
 6 kubernetes.io/ingress.class: nginx
 7 nginx.ingress.kubernetes.io/canary: "true"
 8 nginx.ingress.kubernetes.io/canary-by-header: "canary"
 9 nginx.ingress.kubernetes.io/canary-by-cookie: "canary"
10spec:
11 rules:
12 - host: demo-api.fulu.com
13 http:
14 paths:
15 - backend:
16 serviceName: demo-api-canary
17 servicePort: 80

具体流程

如果是第一次发布，必须是正常版本。
如果发布金丝雀版本，则先检测是否有-canary后缀的ingress、service、deployment，如果有则替换金丝雀版本的镜像，如果没有则创建-canary后缀的ingress、service、deployment。
如果发布正常版本，则先检测是否有-canary后缀的ingress、service、deployment，如果有则先删除它们，再替换正常版本的镜像。

蓝绿部署实现： https://www.cnblogs.com/itzgr/p/14602827.html

以上这些方式只是实现了一种非常简单的金丝雀发布流程，是没有办法做更精细，比如说按用户信息去灰度的规则的。对于同一个用户，也有可能一次请求到了金丝雀中，下一次请求又到了正式环境中。假如需要更加精细的灰度规则，可以考虑采用spring cloud, istio等工具

istio

Kubernetes 中的金丝雀部署

假设我们有一个已部署的 helloworld 服务 v1 版本，我们想要测试（或简单上线）新版本 v2。使用 Kubernetes，您可以通过简单地更新服务的 [Deployment] 中的镜像并自动进行部署来[上线]新版本的 helloworld 服务。如果我们特能够小心保证在启动并且在仅启动一个或两个 v2 副本[暂停]上线时有足够的 v1 副本运行，则能够保持金丝雀发布对系统的影响非常小。后续我们可以观察效果，或在必要时进行[回滚]。最好，我们也能够对 Deployment 设置 [HPA]，在上线过程中减少或增加副本以处理流量负载时，也能够保持副本比例一致。

尽管这种机制能够很好工作，但这种方式只适用于部署的经过适当测试的版本，也就是说，更多的是蓝/绿发布，又称红/黑发布，而不是 “蜻蜓点水“ 式的金丝雀部署。实际上，对于后者（例如，并没有完全准备好或者无意对外暴露的版本），Kubernetes 中的金丝雀部署将使用具有[公共 pod 标签]的两个 Deployment 来完成。在这种情况下，我们不能再使用自动缩放器，因为是有由两个独立的自动缩放器来进行控制，不同负载情况下，副本比例（百分比）可能与所需的比例不同。

无论我们使用一个或者两个部署，使用 Docker，Mesos/Marathon 或 Kubernetes 等容器编排平台进行的金丝雀发布管理都存在一个根本问题：使用实例扩容来管理流量；版本流量分发和副本部署在上述平台中并独立。所有 pod 副本，无论版本如何，在 kube-proxy 循环池中都被一视同仁地对待，因此管理特定版本接收的流量的唯一方法是控制副本比例。以小百分比维持金丝雀流量需要许多副本（例如，1％将需要至少 100 个副本）。即使我们可以忽略这个问题，部署方式功能仍然非常有限，因为它只支持简单（随机百分比）金丝雀部署。如果我们想根据某些特定规则将请求路由到金丝雀版本上，我们仍然需要另一种解决方案。

使用 Istio，流量路由和副本部署是两个完全独立的功能。服务的 pod 数量可以根据流量负载灵活伸缩，与版本流量路由的控制完全正交。这在自动缩放的情况下能够更加简单地管理金丝雀版本。事实上，自动缩放管理器仍然独立运行，其在响应因流量路由导致的负载变化与其他原因导致负载变化的行为上没有区别。

Istio 的[路由规则]也带来了其他的便利；你可以轻松实现细粒度控制流量百分比（例如，路由 1％的流量而不需要 100 个 pod），当然也可以使用其他规则来控制流量（例如，将特定用户的流量路由到金丝雀版本）。作为展示，让我们看一下采用这种方式部署 helloworld 服务的简单便捷。

首先我们定义 helloworld 服务，和普通 Kubernetes 服务一样，如下所示：

 1apiVersion: v1
 2kind: Service
 3metadata:
 4name: helloworld
 5labels:
 6 app: helloworld
 7spec:
 8 selector:
 9 app: helloworld
10 ...
11

然后我们添加 2 个 Deployment，分别为版本 v1 和 v2，这两个版本都包含服务选择标签 app：helloworld

 1kind: Deployment
 2metadata:
 3 name: helloworld-v1
 4spec:
 5 replicas: 1
 6 template:
 7 metadata:
 8 labels:
 9 app: helloworld
10 version: v1
11 spec:
12 containers:
13 - image: helloworld-v1
14 ...
15---
16apiVersion: extensions/v1beta1
17kind: Deployment
18metadata:
19 name: helloworld-v2
20spec:
21 replicas: 1
22 template:
23 metadata:
24 labels:
25 app: helloworld
26 version: v2
27 spec:
28 containers:
29 - image: helloworld-v2
30 ...

需要注意的是，这与使用普通 Kubernetes 进行[金丝雀部署]的方式完全相同，但是在 Kubernetes 方式下控制流量分配需要调整每个 Deployment 的副本数目。例如，将 10％的流量发送到金丝雀版本（v2），v1 和 v2 的副本可以分别设置为 9 和 1。

但是在[启用 Istio] 的集群中，我们可以通过设置路由规则来控制流量分配。如将 10％的流量发送到金丝雀版本本，我们可以使用 kubectl 来设置以下的路由规则：

 1kubectl apply -f - <<EOF
 2apiVersion: networking.istio.io/v1alpha3
 3kind: VirtualService
 4metadata:
 5 name: helloworld
 6spec:
 7 hosts:
 8 - helloworld
 9 http:
10 - route:
11 - destination:
12 host: helloworld
13 subset: v1
14 weight: 90
15 - destination:
16 host: helloworld
17 subset: v2
18 weight: 10
19---
20apiVersion: networking.istio.io/v1alpha3
21kind: DestinationRule
22metadata:
23 name: helloworld
24spec:
25 host: helloworld
26 subsets:
27 - name: v1
28 labels:
29 version: v1
30 - name: v2
31 labels:
32 version: v2
33EOF
34

当规则设置生效后，Istio 将确保只有 10% 的请求发送到金丝雀版本，无论每个版本的运行副本数量是多少。

以上是使用istio 进行的金丝雀部署，当然蓝绿也是类似的。

spring cloud

spring cloud gateway也可以实现灰度发布，另外还有一款 spring cloud 的增强组件，可以实现灰度、蓝绿等功能（Discovery: https://github.com/Nepxion/Discovery）

网关

利用云原生网关比如 APISIX ：

https://apisix.apache.org/zh/docs/apisix/plugins/traffic-split/#蓝绿发布
https://apisix.apache.org/zh/docs/apisix/plugins/traffic-split/#灰度发布

参考

自顶向下学习 RocketMQ（十）：消息重投和消息重试

Tue, 18 Jan 2022 10:59:23 +0000

消息重投

“

生产者在发送消息时，同步消息失败会重投，异步消息有重试，oneway 没有任何保证。消息重投保证消息尽可能发送成功、不丢失，但可能会造成消息重复，消息重复在 RocketMQ 中是无法避免的问题。消息重复在一般情况下不会发生，当出现消息量大、网络抖动，消息重复就会是大概率事件。另外，生产者主动重发、consumer 负载变化也会导致重复消息。如下方法可以设置消息重试策略：

retryTimesWhenSendFailed: 同步发送失败重投次数，默认为 2，因此生产者会最多尝试发送 retryTimesWhenSendFailed + 1 次。不会选择上次失败的>broker，尝试向其他 broker 发送，最大程度保证消息不丢。超过重投次数，抛出异常，由客户端保证消息不丢。当出现 RemotingException、>MQClientException 和部分 MQBrokerException 时会重投。

retryTimesWhenSendAsyncFailed: 异步发送失败重试次数，异步重试不会选择其他 broker，仅在同一个 broker 上做重试，不保证消息不丢。

retryAnotherBrokerWhenNotStoreOK: 消息刷盘（主或备）超时或 slave 不可用（返回状态非 SEND_OK），是否尝试发送到其他 broker，默认 false。十分重要消息可以开启。

”

此外，只有普通消息具有发送重试机制，顺序消息是没有的。

retryTimesWhenSendFailed

同步发送失败策略

1DefaultMQProducer producer = new DefaultMQProducer("pg"); 
2producer.setNamesrvAddr("rocketmqOS:9876"); 
3// 设置同步发送失败时重试发送的次数，默认为 2 次 
4producer.setRetryTimesWhenSendFailed(3); 
5// 设置发送超时时限为 5s，默认 3s 
6producer.setSendMsgTimeout(5000);

在我们 Spring Cloud Stream + Spring Cloud Alibaba RocketMQ 的例子的配置里，我们可以这样配置：

通过源码可以看到，它的默认值是 2：

retryTimesWhenSendAsyncFailed

异步发送失败策略

1DefaultMQProducer producer = new DefaultMQProducer("pg"); 
2producer.setNamesrvAddr("rocketmqOS:9876"); 
3// 指定异步发送失败后不进行重试发送 
4producer.setRetryTimesWhenSendAsyncFailed(0);

在我们 Spring Cloud Stream + Spring Cloud Alibaba RocketMQ 的例子的配置里，我们可以这样配置：

通过源码可以看到，它的默认值也是 2：

retryAnotherBrokerWhenNotStoreOK

消息刷盘失败策略

消息刷盘超时（ Master 、 Slave ），默认是不会将消息尝试发送到其他 Broker。对于重要消息可以通过在 Broker 的配置文件设置 retryAnotherBrokerWhenNotStoreOK 属性为 true 来开启。

在我们 Spring Cloud Stream + Spring Cloud Alibaba RocketMQ 的例子的配置里，我们可以这样配置：

消息重试

“

Consumer 消费消息失败后，要提供一种重试机制，令消息再消费一次。Consumer 消费消息失败通常可以认为有以下几种情况：

由于消息本身的原因，例如反序列化失败，消息数据本身无法处理（例如话费充值，当前消息的手机号被注销，无法充值）等。这种错误通常需要跳过这条消息，再消费其它消息，而这条失败的消息即使立刻重试消费，99%也不成功，所以最好提供一种定时重试机制，即过 10 秒后再重试。

由于依赖的下游应用服务不可用，例如 db 连接不可用，外系统网络不可达等。遇到这种错误，即使跳过当前失败的消息，消费其他消息同样也会报错。这种情况建议应用 sleep 30s，再消费下一条消息，这样可以减轻 Broker 重试消息的压力。

RocketMQ 会为每个消费组都设置一个 Topic 名称为“%RETRY%+consumerGroup”的重试队列（这里需要注意的是，这个 Topic 的重试队列是针对消费组，而不是针对每个 Topic 设置的），用于暂时保存因为各种异常而导致 Consumer 端无法消费的消息。考虑到异常恢复起来需要一些时间，会为重试队列设置多个重试级别，每个重试级别都有与之对应的重新投递延时，重试次数越多投递延时就越大。RocketMQ 对于重试消息的处理是先保存至 Topic 名称为“SCHEDULE_TOPIC_XXXX”的延迟队列中，后台定时任务按照对应的时间进行 Delay 后重新保存至“%RETRY%+consumerGroup”的重试队列中。

”

消费者消费某条消息失败后，会根据消息重试机制将该消息重新投递，若达到重试次数后消息还没有成功被消费，则消息将被投入死信队列。一条消息无论重试多少次，这些重试消息的 Message ID 不会改变。

suspendCurrentQueueTimeMillis

同步消费（顺序消息）消息模式下消费失败后再次消费的时间间隔。默认值：1000 ms

在我们 Spring Cloud Stream + Spring Cloud Alibaba RocketMQ 的例子的配置里，我们可以这样配置：

顺序消息的重试是无休止的，不间断的，直至消费成功，所以，对于顺序消息的消费，务必要保证应用能够及时监控并处理消费失败的情况，避免消费被永久性阻塞。

顺序消息没有发送失败重试机制，但具有消费失败重试机制

MaxReconsumeTimes

无序消息（包括普通消息、延时消息、定时消息和事务消息）的最大重试次数可通过自定义参数 MaxReconsumeTimes 取值进行配置。默认值为 16 次，该参数取值无最大限制，建议使用默认值。

间隔时间根据重试次数阶梯变化，取值范围：1 秒~2 小时。不支持自定义配置。

若最大重试次数小于等于 16 次，则间隔时间按照无序消息重试间隔时间阶梯变化。若最大重试次数大于 16 次，则超过 16 次的间隔时间均为 2 小时。

delayLevelWhenNextConsume

异步消费消息模式下消费失败重试策略：

-1, 不重复，直接放入死信队列
0,broker 控制重试策略
0,client 控制重试策略

默认值：0.

在我们 Spring Cloud Stream + Spring Cloud Alibaba RocketMQ 的例子的配置里，我们可以这样配置：

死信队列

当一条消息初次消费失败，消息队列会自动进行消费重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中。

正常情况下无法被消费的消息称为死信消息（Dead-Letter Message），存储死信消息的特殊队列称为死信队列（Dead-Letter Queue）。

对于无序消息集群消费下的重试消费，默认允许每条消息最多重试 16 次，如果消息重试 16 次后仍然失败，消息将被投递至死信队列

特征

不会再被消费者正常消费
有效期与正常消息相同，均为 3 天，3 天后会被自动删除

特性

一个死信队列对应一个 Group ID，而不是对应单个消费者实例。名称为 %DLQ%consumerGroup@consumerGroup
如果一个 Group ID 未产生死信消息，则不会为其创建相应的死信队列
一个死信队列包含了对应 Group ID 产生的所有死信消息，不论该消息属于哪个 Topic

参考

自顶向下学习 RocketMQ（九）：回溯消费

Mon, 17 Jan 2022 06:52:31 +0000

定义

“

回溯消费是指 Consumer 已经消费成功的消息，由于业务上需求需要重新消费，要支持此功能，Broker 在向 Consumer 投递成功消息后，消息仍然需要保留。并且重新消费一般是按照时间维度，例如由于 Consumer 系统故障，恢复后需要重新消费 1 小时前的数据，那么 Broker 要提供一种机制，可以按照时间维度来回退消费进度。RocketMQ 支持按照时间回溯消费，时间维度精确到毫秒。

”

Demo

我们仍然是利用 Spring Cloud Stream 的编程模型 + Spring Cloud Alibaba RocketMQ 来实现。

理论

在消费时，可以设置一个字段 ConsumeFromWhere（源码位置在：org.apache.rocketmq.common.consumer.ConsumeFromWhere），从哪开始消费。可选参数，去掉 Deprecated 的，剩下的就是

1public enum ConsumeFromWhere {
2 CONSUME_FROM_LAST_OFFSET,
3 CONSUME_FROM_FIRST_OFFSET,
4 CONSUME_FROM_TIMESTAMP,
5}

CONSUME_FROM_LAST_OFFSET：从最后的偏移量开始消费
CONSUME_FROM_FIRST_OFFSET：从最小偏移量开始消费
CONSUME_FROM_TIMESTAMP：从某个时间开始消费

我们需要设置从某个时间开始消费，即配置 CONSUME_FROM_TIMESTAMP 并设置好具体的时间点。

实现

首先还是看一下配置文件

 1server:
 2 port: 8080
 3 servlet:
 4 context-path: /mq-example
 5
 6spring:
 7 
 8 application:
 9 name: mq-example
10 cloud:
11 stream:
12 bindings:
13
14 input-backtracking:
15 content-type: application/json
16 destination: test-topic3
17 group: backtracking-consumer-group
18
19 # 定义 name 为 output 的 binding 生产
20 output-order:
21 content-type: application/json
22 destination: test-topic3
23
24 rocketmq:
25 # RocketMQ Binder 配置项，对应 RocketMQBinderConfigurationProperties 类
26 binder:
27 # 配置 rocketmq 的 nameserver 地址
28 name-server: 127.0.0.1:9876
29 group: rocketmq-group
30 bindings:
31 output-order:
32 # RocketMQ Producer 配置项，对应 RocketMQProducerProperties 类
33 producer:
34 #group: producer-group # 生产者分组
35 sync: true # 是否同步发送消息，默认为 false 异步。
36 input-backtracking: # 回溯消息配置
37 # com.alibaba.cloud.stream.binder.rocketmq.properties.RocketMQConsumerProperties
38 consumer:
39 consumeFromWhere: CONSUME_FROM_TIMESTAMP
40 consumeTimestamp: 20220117110148
41 enabled: true # 是否开启消费，默认为 true
42 broadcasting: false # 是否使用广播消费，默认为 false 使用集群消费

这里我们仍然用之前的 ouput-order 作为生产者，生产消息。

消息者配置上主要注意 input-backtracking 节点中的属性配置：

consumeFromWhere 即上文提到的从哪儿开始消费，这里我们指定时间消费
consumeTimestamp 即指定的时间点

程序入口：

1@SpringBootApplication
2@EnableBinding({ MySource.class})
3public class MqBootstrapApplication {
4 public static void main(String[] args) {
5 SpringApplication.run(MqBootstrapApplication.class);
6 }
7
8}

要加上 @EnableBinding

MySource:

1public interface MySource {
2
3 @Output("output-order")
4 MessageChannel output4Order();
5
6 @Input("input-backtracking")
7 MessageChannel inputBackTracking();
8
9}

controller 生产消息：

 1@GetMapping("/produce")
 2 public void produceMsg() {
 3
 4 Map<String, Object> headers = Maps.newHashMapWithExpectedSize(16);
 5 headers.put(MessageConst.PROPERTY_DELAY_TIME_LEVEL, 2);
 6 headers.put(MessageConst.PROPERTY_TAGS, "test03");
 7
 8 Order order = Order.builder().id(1L).desc("test").build();
 9 Message message = MessageBuilder.createMessage(order, new MessageHeaders(headers));
10 mySource.output4Order().send(message);
11
12 }

ReceiveService 消费消息：

 1
 2@Service
 3@Log4j2
 4public class ReceiveService {
 5
 6 @StreamListener("input-backtracking")
 7 public void receiveBackTrackingInput(String receiveMsg, GenericMessage message, @Headers Map headers) {
 8
 9 log.info("接收到回溯消息：{}", receiveMsg);
10
11 }
12
13}

测试

可以先调用 controller 生产消息，或者不用 Demo 中的生产者生产消息，找一个之前发过消息的 topic , 看一下它的消息轨迹，找到存储时间

如果你用之前发过消息的 topic 记得修改配置文件中的 topic名称：

确认找到的这条消息已经被消费过（因为要测回溯，至少是二次消费），将 consumeTimestamp 的时间配置在存储时间之后。

这时启动项目，观察 ReceiveService 的输出：

1 接收到回溯消息：{"id":1,"desc":"test"}

证明消息回溯消费成功。

参考

自顶向下学习 RocketMQ（七）：事务消息

Mon, 10 Jan 2022 23:50:00 +0000

定义

“

RocketMQ 事务消息（Transactional Message）是指应用本地事务和发送消息操作可以被定义到全局事务中，要么同时成功，要么同时失败。RocketMQ 的事务消息提供类似 X/Open XA 的分布事务功能，通过事务消息能达到分布式事务的最终一致。

”

Demo

下面的例子，还是以 spring cloud stream 编程模型为基础，结合 spring cloud alibaba RocketMQ 的实现，演示了如何使用事务消息。

流程

事务消息交互流程如下图所示：

事务消息发送步骤如下：

生产者将半事务消息发送至消息队列 RocketMQ 版服务端。
消息队列 RocketMQ 版服务端将消息持久化成功之后，向生产者返回 Ack 确认消息已经发送成功，此时消息为半事务消息。
生产者开始执行本地事务逻辑。
生产者根据本地事务执行结果向服务端提交二次确认结果（Commit 或是 Rollback），服务端收到确认结果后处理逻辑如下：

二次确认结果为 Commit：服务端将半事务消息标记为可投递，并投递给消费者。
二次确认结果为 Rollback：服务端不会将该消息投递给消费者，并按照如下逻辑进行回查处理。

事务消息回查步骤如下：

在断网或者是生产者应用重启的特殊情况下，上述步骤 4 提交的二次确认最终未到达服务端，经过固定时间后，服务端将对消息生产者即生产者集群中任一生产者实例发起消息回查。
生产者收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
生产者根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤 4 对半事务消息进行处理。

配置

和之前一样，我将生产者消息者配置在一起了，先来看一下配置文件：

 1spring:
 2 application:
 3 name: mq-example
 4 cloud:
 5 stream:
 6 bindings:
 7
 8 input-transaction:
 9 content-type: application/json
10 destination: TransactionTopic
11 group: transaction-consumer-group
12 
13 output-transaction:
14 content-type: application/json
15 destination: TransactionTopic
16
17 rocketmq:
18 # RocketMQ Binder 配置项，对应 RocketMQBinderConfigurationProperties 类
19 binder:
20 # 配置 rocketmq 的 nameserver 地址
21 name-server: 127.0.0.1:9876
22 group: rocketmq-group
23 bindings:
24 output-transaction:
25 # 对应 RocketMQProducerProperties 类
26 producer:
27 producerType: Trans
28 group: transaction-producer-group # 生产者分组
29 transactionListener: myTransactionListener
30

这里需要注意生产者类型为：Trans 即，事务消息。

还配置了相应的生产者组和消费者组，这里回顾一下这两个概念

消费者组：同一类 Producer 的集合，这类 Producer 发送同一类消息且发送逻辑一致。如果发送的是事务消息且原始生产者在发送之后崩溃，则 Broker 服务器会联系同一生产者组的其他生产者实例以提交或回溯消费。

生产者组：同一类 Consumer 的集合，这类 Consumer 通常消费同一类消息且消费逻辑一致。消费者组使得在消息消费方面，实现负载均衡和容错的目标变得非常容易。要注意的是，消费者组的消费者实例必须订阅完全相同的 Topic。RocketMQ 支持两种消息模式：集群消费（Clustering）和广播消费（Broadcasting）。

实现

transactionListener 为我们自定义的事务监听器，具体代码见下文：

 1@Component("myTransactionListener")
 2public class TransactionListenerImpl implements TransactionListener {
 3
 4 @Override
 5 public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
 6 Object num = msg.getProperty("test");
 7
 8 if ("1".equals(num)) {
 9 System.out.println("executer: " + new String(msg.getBody()) + " unknown");
10 return LocalTransactionState.UNKNOW;
11 } else if ("2".equals(num)) {
12 System.out.println("executer: " + new String(msg.getBody()) + " rollback");
13 return LocalTransactionState.ROLLBACK_MESSAGE;
14 }
15 System.out.println("executer: " + new String(msg.getBody()) + " commit");
16 return LocalTransactionState.COMMIT_MESSAGE;
17 }
18
19 @Override
20 public LocalTransactionState checkLocalTransaction(MessageExt msg) {
21 System.out.println("check: " + new String(msg.getBody()));
22 return LocalTransactionState.COMMIT_MESSAGE;
23 }
24
25}

以上代码是参考官方的 Demo, 可以看到根据 num 的不同，返回不同的事务状态

如果 num 为 1，则返回 UNKNOW，表示本地事务状态未知，需要定期回查事务状态，则会执行 checkLocalTransaction 方法。
如果 num 为 2，则返回 ROLLBACK_MESSAGE，表示本地事务状态为回滚，则 broker 会回滚之前的提交的事务消息，即不投递消息。
如果 num 为 3，则返回 COMMIT_MESSAGE，表示本地事务状态为提交，则 broker 会投递消息。

发送消息跟之前的代码类似：

 1 @GetMapping("/send_transaction")
 2 public void sendTransaction() {
 3
 4 String msg = "这是一条事务消息";
 5 Integer num = 2;
 6
 7 MessageBuilder builder = MessageBuilder.withPayload(msg)
 8 .setHeader(MessageHeaders.CONTENT_TYPE, MimeTypeUtils.APPLICATION_JSON);
 9 builder.setHeader("test", String.valueOf(num));
10 builder.setHeader(RocketMQConst.USER_TRANSACTIONAL_ARGS, "binder");
11 Message message = builder.build();
12 mySource.outputTransaction().send(message);
13 }

为了保证可靠消息最终一致性，需要有一个数据库表记录事务状态，

事务开始的时候先将 UNKNOW 状态存起来，当事务异常时，返回 ROLLBACK_MESSAGE 状态，并且在数据库表中记录此状态。当事务提交成功时，将状态修改为 COMMIT_MESSAGE。

有了事务消息表，checkLocalTransaction 方法就可以依据此表进行事务状态的查询。

当然，如果按上图所示，一个完整的分布式事务跨越 A、B 两个系统，如果 B 系统事务失败回滚时，考虑 A 系统的事务是否需要回滚，如需要，还需要 A 系统提供回滚接口，供 B 系统调用。