reactive streams与观察者模式

本文主要研究下java里头的reactive streams与观察者模式。

reactive streams

reactive编程范式是一个异步编程范式,主要涉及数据流及变化的传播,可以看做是观察者设计模式的扩展。

java里头的iterator是以pull模型,即订阅者使用next去拉取下一个数据;而reactive streams则是以push模型为主,订阅者调用subscribe方法订阅,发布者调用订阅者的onNext通知订阅者新消息。

reactive streams java api

reactive streams定义了4个java api,如下

Processor

processor既是Subscriber也是Publisher,代表二者的处理阶段

Publisher

publisher是数据的提供者, 将数据发布给订阅者

Subscriber

在调用Publisher.subscribe(Subscriber)之后,Subscriber.onSubscribe(Subscription)将会被调用

Subscription

Subscription代表订阅者与发布者的一次订阅周期,一旦调用cancel去掉订阅,则发布者不会再推送消息。

观察者模式

reactive streams与观察者模式_第1张图片
080309_mlKt_1383356.png

观察者模式的实现有推模型和拉模型

  • 拉模型

即发布者通知订阅有新消息,订阅者再去找发布者拉取

  • 推模型

即发布者通知订阅者有消息,通知的时候已经带上了一个新消息

reactor实例

maven

        
            io.projectreactor
            reactor-core
            3.1.2.RELEASE
        

reactor 3 是java里头reactive streams的一个实现,基于reactive streams的java api,是spring 5反应式编程的基础。

Flux实例

    @Test
    public void testBackpressure(){
        Flux.just(1, 2, 3, 4)
                .log()
                .subscribe(new Subscriber() {
                    private Subscription s;
                    int onNextAmount;

                    @Override
                    public void onSubscribe(Subscription s) {
                        this.s = s;
                        s.request(2);
                    }

                    @Override
                    public void onNext(Integer integer) {
                        System.out.println(integer);
                        onNextAmount++;
                        if (onNextAmount % 2 == 0) {
                            s.request(2);
                        }
                    }

                    @Override
                    public void onError(Throwable t) {}

                    @Override
                    public void onComplete() {}
                });

        try {
            Thread.sleep(10*1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

小结

从上面的代码看,reactive streams实际上是推拉结合的模式的结合。为什么还要拉呢?

rabbitmq vs kafka

rabbitmq是以推为主的,如果消费者消费能力跟不上,则消息会堆积在内存队列中(必要时可能写磁盘)

kafka则是以拉为主的,生产者推送消息到broker,消费者自己根据自己的能力从broker拉取消息,由于消息是持久化的,因此无需关心生产消费速率的不平衡

backpressure

backpressure这个是为处理生产速率与消费速率不平衡这个问题而衍生出来的,订阅者可以在next方法里头根据自己的情况,使用request方法告诉发布者要取N个数据,发布者则向订阅者推送N个数据。通过request达到订阅者对发布者的反馈。而对于发布者而言,为了实现backpressure,则需要有一个缓存队列来缓冲订阅者没来得及消费的数据。涉及到缓冲,就涉及容量是有界还是无界,如果是有界则在缓冲慢的时候,处理策略是怎样等等。

doc

  • reactive streams java api
  • Java 9 揭秘(17. Reactive Streams)
  • Java 9 Reactive Streams

你可能感兴趣的:(reactive streams与观察者模式)