如需最新的稳定版本,请使用 Spring Data Redis 3.4.0! |
Redis 流
Redis Streams 以抽象方法对日志数据结构进行建模。通常,日志是仅附加数据结构,从一开始就使用,在随机位置使用,或者通过流式传输新消息来使用。
在 Redis 参考文档中了解有关 Redis Streams 的更多信息。 |
Redis Streams 大致可以分为两个功能领域:
-
附加记录
-
使用记录
尽管此模式与 Pub/Sub 有相似之处,但主要区别在于消息的持久性及其使用方式。
Pub/Sub 依赖于瞬态消息的广播(即,如果您不监听,就会错过一条消息),而 Redis Stream 使用一种持久的、仅附加的数据类型,该数据类型会保留消息,直到流被修剪。使用的另一个不同之处在于 Pub/Sub 注册服务器端订阅。Redis 将到达的消息推送到客户端,而 Redis Streams 需要主动轮询。
这org.springframework.data.redis.connection
和org.springframework.data.redis.stream
软件包为 Redis Streams 提供核心功能。
附加
要发送记录,与其他作一样,您可以使用低级别的RedisConnection
或高级StreamOperations
.这两个实体都提供add
(xAdd
) 方法,该方法接受记录和目标流作为参数。而RedisConnection
需要原始数据(字节数组),则StreamOperations
允许将任意对象作为记录传入,如以下示例所示:
// append message through connection
RedisConnection con = …
byte[] stream = …
ByteRecord record = StreamRecords.rawBytes(…).withStreamKey(stream);
con.xAdd(record);
// append message through RedisTemplate
RedisTemplate template = …
StringRecord record = StreamRecords.string(…).withStreamKey("my-stream");
template.opsForStream().add(record);
流记录带有Map
、键值元组作为其有效负载。将记录附加到流中会返回RecordId
可以用作进一步的参考。
消费
在消费端,可以使用一个或多个流。Redis Streams 提供读取命令,允许从已知流内容内和流端之外的任意位置(随机访问)使用流,以使用新的流记录。
在低级别,RedisConnection
提供xRead
和xReadGroup
分别映射用于使用者组内读取和读取的 Redis 命令的方法。请注意,多个流可以用作参数。
Redis 中的订阅命令可能会阻塞。也就是说,调用xRead on a connection 会导致当前线程在开始等待消息时阻塞。仅当 read 命令超时或收到消息时,才会释放线程。 |
要使用流消息,可以在应用程序代码中轮询消息,也可以通过消息侦听器容器使用两种异步接收之一,即命令式或反应式。每次有新记录到达时,容器都会通知应用程序代码。
同步接收
虽然流使用通常与异步处理相关联,但也可以同步使用消息。超载的StreamOperations.read(…)
方法提供此功能。在同步接收期间,调用线程可能会阻塞,直到消息可用。物业StreamReadOptions.block
指定接收方在放弃等待消息之前应等待的时间。
// Read message through RedisTemplate
RedisTemplate template = …
List<MapRecord<K, HK, HV>> messages = template.opsForStream().read(StreamReadOptions.empty().count(2),
StreamOffset.latest("my-stream"));
List<MapRecord<K, HK, HV>> messages = template.opsForStream().read(Consumer.from("my-group", "my-consumer"),
StreamReadOptions.empty().count(2),
StreamOffset.create("my-stream", ReadOffset.lastConsumed()))
通过 Message Listener Containers 进行异步接收
由于其阻塞性质,低级轮询没有吸引力,因为它需要为每个消费者管理连接和线程。为了缓解这个问题, Spring Data 提供了消息侦听器,它完成了所有繁重的工作。如果您熟悉 EJB 和 JMS,您应该会发现这些概念很熟悉,因为它的设计尽可能接近 Spring Framework 及其消息驱动的 POJO (MDP) 中的支持。
Spring Data 附带了两个针对所使用的编程模型量身定制的实现:
-
StreamMessageListenerContainer
充当命令式编程模型的消息侦听器容器。它用于使用 Redis Stream 中的记录,并驱动StreamListener
注入其中的实例。 -
StreamReceiver
提供消息侦听器的反应式变体。它用于将来自 Redis Stream 的消息作为潜在的无限流使用,并通过Flux
.
StreamMessageListenerContainer
和StreamReceiver
负责将消息接收和分派到侦听器中进行处理的所有线程。消息侦听器容器/接收器是 MDP 和消息传递提供商之间的中介,负责注册以接收消息、资源获取和释放、异常转换等。这样,作为应用程序开发人员,您可以编写与接收消息(并对其做出反应)相关的(可能复杂的)业务逻辑,并将样板 Redis 基础设施问题委托给框架。
这两个容器都允许运行时配置更改,以便您可以在应用程序运行时添加或删除订阅,而无需重新启动。此外,容器使用延迟订阅方法,使用RedisConnection
仅在需要时。如果所有侦听器都已取消订阅,则自动执行清理并释放线程。
祈使的StreamMessageListenerContainer
与 EJB 世界中的消息驱动 Bean (MDB) 类似,流驱动 POJO (SDP) 充当流消息的接收者。SDP 的一个限制是它必须实现StreamListener
接口。另请注意,如果您的 POJO 在多个线程上接收消息,确保您的实现是线程安全的非常重要。
class ExampleStreamListener implements StreamListener<String, MapRecord<String, String, String>> {
@Override
public void onMessage(MapRecord<String, String, String> message) {
System.out.println("MessageId: " + message.getId());
System.out.println("Stream: " + message.getStream());
System.out.println("Body: " + message.getValue());
}
}
StreamListener
表示函数接口,因此可以使用其 Lambda 表单重写实现:
message -> {
System.out.println("MessageId: " + message.getId());
System.out.println("Stream: " + message.getStream());
System.out.println("Body: " + message.getValue());
};
实现StreamListener
,现在是时候创建一个消息侦听器容器并注册一个订阅了:
RedisConnectionFactory connectionFactory = …
StreamListener<String, MapRecord<String, String, String>> streamListener = …
StreamMessageListenerContainerOptions<String, MapRecord<String, String, String>> containerOptions = StreamMessageListenerContainerOptions
.builder().pollTimeout(Duration.ofMillis(100)).build();
StreamMessageListenerContainer<String, MapRecord<String, String, String>> container = StreamMessageListenerContainer.create(connectionFactory,
containerOptions);
Subscription subscription = container.receive(StreamOffset.fromStart("my-stream"), streamListener);
请参阅各种消息侦听器容器的 Javadoc,了解每个实现支持的功能的完整描述。
反应性的StreamReceiver
流数据源的反应式使用通常通过Flux
的事件或消息。reactive receiver 实现由StreamReceiver
并且它超载receive(…)
消息。与StreamMessageListenerContainer
因为它正在利用驱动程序提供的线程资源。接收流是StreamMessage
:
Flux<MapRecord<String, String, String>> messages = …
return messages.doOnNext(it -> {
System.out.println("MessageId: " + message.getId());
System.out.println("Stream: " + message.getStream());
System.out.println("Body: " + message.getValue());
});
现在我们需要创建StreamReceiver
并注册订阅以使用 Stream Messages:
ReactiveRedisConnectionFactory connectionFactory = …
StreamReceiverOptions<String, MapRecord<String, String, String>> options = StreamReceiverOptions.builder().pollTimeout(Duration.ofMillis(100))
.build();
StreamReceiver<String, MapRecord<String, String, String>> receiver = StreamReceiver.create(connectionFactory, options);
Flux<MapRecord<String, String, String>> messages = receiver.receive(StreamOffset.fromStart("my-stream"));
请参阅各种消息侦听器容器的 Javadoc,了解每个实现支持的功能的完整描述。
需求驱动型消费使用背压信号来激活和停用轮询。StreamReceiver 如果满足需求,订阅将暂停轮询,直到订阅服务器发出进一步需求的信号。根据ReadOffset 策略,这可能会导致邮件被跳过。 |
Acknowledge
策略
当您通过Consumer Group
,服务器将记住已传递的给定邮件,并将其添加到待处理条目列表 (PEL) 中。已送达但尚未确认的消息列表。
消息必须通过以下方式进行确认StreamOperations.acknowledge
以便从 Pending Entries 列表中删除,如下面的代码段所示。
StreamMessageListenerContainer<String, MapRecord<String, String, String>> container = ...
container.receive(Consumer.from("my-group", "my-consumer"), (1)
StreamOffset.create("my-stream", ReadOffset.lastConsumed()),
msg -> {
// ...
redisTemplate.opsForStream().acknowledge("my-group", msg); (2)
});
1 | 从组 my-group 中读取为 my-consumer。未确认收到的消息。 |
2 | 处理后确认消息。 |
在接收时使用自动确认消息receiveAutoAck 而不是receive . |
ReadOffset
策略
流读取作接受读取偏移量规范,以使用来自给定偏移量的消息。ReadOffset
表示读取偏移量规范。Redis 支持 3 种偏移量变体,具体取决于您是独立使用流还是在使用者组内使用流:
-
ReadOffset.latest()
– 阅读最新消息。 -
ReadOffset.from(…)
– 在特定消息 ID 后读取。 -
ReadOffset.lastConsumed()
– 在上次使用的消息 ID 之后读取(仅限使用者组)。
在基于消息容器的使用上下文中,我们需要在使用消息时提前(或增加)读取偏移量。推进取决于请求ReadOffset
和消费模式(带/不带消费者组)。以下矩阵说明了容器如何前进ReadOffset
:
读取偏移量 | 独立 | 消费组 |
---|---|---|
最近的 |
阅读最新消息 |
阅读最新消息 |
特定消息 ID |
使用上次看到的消息作为下一个 MessageId |
使用上次看到的消息作为下一个 MessageId |
上次消耗 |
使用上次看到的消息作为下一个 MessageId |
每个使用者组的最后使用消息 |
从特定消息 ID 和最后使用的消息读取可被视为安全作,可确保使用附加到流的所有消息。
使用 latest 消息进行读取可以跳过在 poll作处于停滞时间状态时添加到流中的消息。轮询引入了一个停滞时间,在该时间中,消息可以在各个轮询命令之间到达。流消耗不是线性连续读取,而是拆分为重复读取XREAD
调用。
序列化
发送到流的任何 Record 都需要序列化为其二进制格式。由于流与哈希数据结构接近,流键、字段名称和值使用在RedisTemplate
.
Stream 属性 | 序列化器 | 描述 |
---|---|---|
钥匙 |
keySerializer 的 |
用于 |
田 |
hashKeySerializer |
用于有效负载中的每个映射键 |
值 |
hashValueSerializer 的 |
用于有效负载中的每个 map 值 |
请务必查看RedisSerializer
s 一起使用,请注意,如果您决定不使用任何序列化器,则需要确保这些值已经是二进制的。
对象映射
简单值
StreamOperations
允许通过ObjectRecord
直接发送到流中,而不必将这些值放入Map
结构。
然后,该值将分配给有效负载字段,并且可以在读回值时提取该值。
ObjectRecord<String, String> record = StreamRecords.newRecord()
.in("my-stream")
.ofObject("my-value");
redisTemplate()
.opsForStream()
.add(record); (1)
List<ObjectRecord<String, String>> records = redisTemplate()
.opsForStream()
.read(String.class, StreamOffset.fromStart("my-stream"));
1 | XADD my-stream * “_class” “java.lang.String” “_raw” “my-value” |
ObjectRecord
的序列化过程与所有其他 Records 完全相同,因此也可以使用返回MapRecord
.
复杂值
可以通过 3 种方式向流中添加复杂值:
-
使用字符串 JSON 表示形式转换为简单值。
-
用合适的
RedisSerializer
. -
将值转换为
Map
适合使用HashMapper
.
第一个变体是最直接的变体,但忽略了 stream 结构提供的字段值功能,但 stream 中的值仍然可以被其他使用者读取。
第二个选项具有与第一个选项相同的好处,但可能会导致非常具体的使用者限制,因为所有使用者都必须实现完全相同的序列化机制。
这HashMapper
方法是稍微复杂的一种,它使用 steams 哈希结构,但扁平化源。只要选择了合适的序列化程序组合,其他使用者仍然能够读取记录。
HashMappers 将有效负载转换为Map 替换为特定类型。确保使用能够(反)序列化哈希的 Hash-Key 和 Hash-Value 序列化器。 |
ObjectRecord<String, User> record = StreamRecords.newRecord()
.in("user-logon")
.ofObject(new User("night", "angel"));
redisTemplate()
.opsForStream()
.add(record); (1)
List<ObjectRecord<String, User>> records = redisTemplate()
.opsForStream()
.read(User.class, StreamOffset.fromStart("user-logon"));
1 | XADD user-logon * “_class”, “com.example.User” “firstname” “night” “lastname” “angel” |
StreamOperations
默认使用 ObjectHashMapper 。
您可以提供HashMapper
适合您的要求StreamOperations
.
redisTemplate()
.opsForStream(new Jackson2HashMapper(true))
.add(record); (1)
1 | XADD user-logon * “firstname” “night” “@class” “com.example.User” “lastname” “angel” |
一个
|