java - 使用 Reactive Streams 的 Reactive Pull-Based BackPressure

Question

这是我对这个主题的理解。

有发布者和订阅者。

发布者和订阅者的伪代码是这样的

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() 上每次收到一条消息，实现它看起来要困难得多。

Answer 1

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类描述了各种标准实现的用途。