Question

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

有发布者和订阅者。

Publisher和Subscriber的伪代码类似于

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

好的，我理解基于反应拉动的方法优于简单循环的一些优点。

如果订阅者请求n个项目，发布者是否有必要在订阅者上调用onNext（）n次？或者它也可以，如果发布者使用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()次来电。通常，这意味着代表源和消费者之间活动连接的Subscription实现将处理request调用。

与简单的循环有什么不同？

Reactive Streams允许无阻塞消费;您的示例会阻止线程，直到getMessages()可以检索List条消息。使用Publisher的不错的属性是，无论源Publisher是阻塞还是非阻塞，您都不必以不同方式使用事件。它为两种情况提供了统一的编程模型。如果有一天getMessages()收到非阻止变体，则不必更改使用其包装Publisher的下游。

差异是否都与可用的不同类型的调度程序有关？

Scheduler表示异步边界的抽象：生成事件的线程和消耗这些事件的线程。不同的Scheduler实现以不同的方式管理其线程，具体取决于这些线程的利用率。一些线程将执行计算密集型任务，一些线程将因与非反应源的交互而阻塞。 Schedulers类给出了各种标准实现的描述。

使用反应流的反应性拉动背压

1 个答案: