这是我对这个主题的理解。
有发布者和订阅者。
发布者和订阅者的伪代码是这样的
Publisher{
Subscriber s;
subscribe(Subscriber s){
this.s = s;
s.onSubscribe(new Subscription(){
onRequest(int n){
List<Message> messages = service.getMessages(n);
s.onNext(messages);
}
onCancel(){
s.onComplete();
}
});
}
}
Subscriber{
Subscription s;
onSubscribe(Subscription s){
this.s = s;
s.request(5);
}
onNext(List<Message> messages){
messages.stream().parallel().map(this::process).collect(toList());
s.request(5);
}
onComplete(){}
onError(e){}
private boolean process(Message m){
//process message and return true/false according to whether it passed/failed.
}
}
我的理解是,根据应用程序的能力,订阅者会调用请求。当应用程序运行状况良好时,订阅者可以快速处理消息并花更多时间请求消息。 如果应用程序负载不足,订阅者将仅在处理完当前批处理后请求下一批处理。如果处理需要时间,则减少对更多消息的请求。 消息流将根据应用程序的能力而定。
我的理解正确吗?
它与简单循环有何不同?
while(true){
List<Message> messages = service.getMessages(5);
messages.stream().parallel().map(this:process).collect(toList());
}
同样在这种情况下,下一批消息在并发处理消息后才被读取。同样在这种情况下,当应用程序运行良好时,将读取更多消息。如果慢消息将被较少地阅读。
这两种方法有何不同?差异是否都与可用的不同类型的调度程序有关?我不明白,这里的优势到底是什么。
更新 1
好的,我了解基于响应式(Reactive)拉动的方法相对于简单循环的一些优势。
如果订阅者请求n个项目,Publisher是否需要在订阅者上调用n次onNext()?或者,如果发布者使用 n 个元素的列表调用订阅者一次(就像在前面的代码片段中一样),它是否也很好?如果需要进行 n 个 onNext() 调用,则订阅者会变得稍微复杂一些。
Publisher{
Subscriber s;
subscribe(Subscriber s){
this.s = s;
s.onSubscribe(new Subscription(){
request(int n){
service.getMessagesAsyc(n, (List<Message> messages) -> messages.stream().forEach(s::onNext));
}
onCancel(){
s.onComplete();
}
});
}
}
Subscriber{
Subscription s;
COUNT = 5;
volatile int i = COUNT;
onSubscribe(Subscription s){
this.s = s;
s.request(COUNT);
}
onNext(Message message){
CompletableFuture.runAsync(() -> process(message));
requestMessagesIfNeeded();
}
private synchronized requestmessagesIfNeeded(){
if(0 == i--){
i = COUNT;
s.request(COUNT);
}
}
private boolean process(Message m){
//process message and return true/false according to whether it passed/failed.
}
}
如果可以向订阅者传递一个包含 n 条消息的列表,那么其他优点也很少。假设订阅者只需要确认成功处理的消息,在第一种方法中使用批量确认 API 很容易做到这一点。
Map<Boolean, List<Message>> partitioned = messages.stream().parallel().collect(partitioningBy(this::process));
service.ackowledge(partitioned.get(true));
s.request(5);
第二种方法,我在 onNext() 上每次收到一条消息,实现它看起来要困难得多。
最佳答案
onRequest(int n){ List<Message> messages = service.getMessages(n); s.onNext(messages); }
这是对 Reactive Streams 的错误看法。 request
告诉 Publisher
它可以执行 n
onNext()
调用。通常,这意味着表示源和消费者之间 Activity 连接的订阅
实现将处理请求
调用。
How is it different from a simple loop?
Reactive Streams 允许非阻塞消费;您的示例会阻塞一个线程,直到 getMessages()
可以检索消息的 List
。使用 Publisher
的好处是,无论源 Publisher
是阻塞还是非阻塞,您都不必以不同方式使用事件。它为这两种情况提供了统一的编程模型。如果有一天 getMessages()
收到一个非阻塞变体,则不必更改使用其包装器 Publisher
的下游。
Is the differences all about different types of Schedulers that are available?
Scheduler
表示异步边界上的抽象:产生事件的线程和使用这些事件的线程。不同的 Scheduler
实现以不同的方式管理它们的线程,具体取决于这些线程的利用率。一些线程将执行计算密集型任务,一些线程将由于与非 react 源的交互而阻塞。 Schedulers类描述了各种标准实现的用途。
关于java - 使用 Reactive Streams 的 Reactive Pull-Based BackPressure,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/46787315/