反応（2）交通牛乳工場の流れに応じて

ディレクトリ

式の応答トーク
- なぜウェブバックエンドの開発、反応性のない感はありません
Javaの9のサポートリストリーム
例
概要
深い読み

式の応答トーク

前回の記事で、「ハリウッド」への反応からプログラミング応答では、いくつかの相違について話して、概念のいくつかのタイプについて話しました。しかし、まだ唯一の実際の戦闘に関与していないもののために、概念レベルにとどまります。
だから私は読んだ後、またはおそらくいくつかの表面的。

リアクティブプログラミング重点が出産どちらの治療の流れのための非同期技術は、空中からではなく、技術的な練習の数が多いから、そのように外の概念を要約しています：

私たちは、Javaの非同期IO（非同期IO）を考えるのは簡単、非同期を話した、と比較し、BIO、NIOの概念を行うために使用されます。誰もが知っているように、Swingのフレームワークはずっと前に非常に滑り止め遊んで非同期のことを考えてきた（JavaのUI）登場し、あなたがその内部のオブザーバーモードの実装を見ることができると信じていません（オブザーバー）があります。
私たちは、ストリーミングについて話している、今日FLINKフレームワークの人気の考えることは容易です。しかし、ほとんどすべてのビッグデータ分析、バッチ・アプリケーションは、ETL、地図の最も単純なようにベースのストリーミングを、処理されたジョブを減らします。

なぜウェブバックエンドの開発、反応性のない感はありません

フロントエンドアプリケーションに加えて、ビッグデータの分野における反応性の概念は、実際には非常に広範です。しかし、バックエンドのWeb開発者のほとんどのために、おそらく著者自身の経験に人気の高いではない、人々はこれらの長年そのコードであるか、外部のコード成層を行うことに加えて、反応プレーを見ていないようです主要な役割を配置します。理由は、バックエンドのWeb開発の分野では基本的に非常に簡単です達成するために、HTTPプロトコル機構に依存している、ということです>応答-要求通知の結果である要求を送信した後、対話モード、クライアントの結果を返すようにするために、待っているだろう、イニシアチブは、クライアントではなく、非同期通知、したがって反応しないスタイルによって取得されます。しかし、これはユーザーの一貫した使用に沿ったものである、ほとんどのケースを変更し、私たちが深い認識に応答しないこの時点で、必要はありません。

別のシナリオは、反応性に沿って、より多くのリッチクライアント（リッチアプリケーション）、シナリオと仮定すると、対話型の複雑なフロントエンドの多くを必要とし、我々は、フロントエンドのコードで実装いくつかのロジックを置くことを選択することができます。このWebインタラクションでページ全体を更新することはもはやですが、「リアルタイム」の双方向メッセージングクライアントとサーバになって、これらのアプリケーションは、このようなように、それらのベースのチャットアプリケーション用WebSocketの実装、ゲームとして、より一般的ではありません。

平野は傾向から判断すると、反応性の見通しは今、最も人気のあるプログラミング言語は（例えばRxのスタイルのフレームワークを提供するなど）その影を持っているので、ここでと言っているわけではない、まだ非常に不確実です。
しかし、次の大きなデータ処理、リアルタイムのストリーム・コンピューティングは、環境によって決定される主流、となります。反応性であり、そして、この「ストリーム指向」プログラミングモードは、間違いなく非常に適しています。

Javaの9のサポートリストリーム

JavaプラットフォームJDK 9は、それが反応性を完全にサポートを提供し、この前のJDKのバージョンでは、だけでなく、そのように、いくつかのAPIは関連性がありますまで。

非同期計算を実行するための未来とCompletableFutureインターフェース。前者よりも後者は非同期通知、およびシリアルタスクの他の特性の結果を改善することです。
ストリームインタフェースは、「フロー」方法、そのような反復、マッピング変換であるために、従来のセットに変換することができます。

反応これらの関連付けを完了APIはありませんが、Javaの9は、2013年応答フロー仕様（リアクティブストリーム仕様）からの反応ストリームAPIをサポートしていました。

https://www.reactive-streams.org/

本明細書に基づいて、以下のいくつかの主要なインターフェイスを定義しています。

インターフェースで定義されるJava応答フロー統一されたインタフェースjava.util.concurrent.Flow

出版社の
すなわち、データの発行者。パブリッシャは、インターフェイスが加入者を追加するための方法を定義してサブスクライブ：
加入者は、
加入者データを意味します。加入者インタフェースは、さまざまなイベントに応答するための4つのメソッドを定義します。

まず、サブスクライブメソッド呼び出しの後（サブスクリプション現在のサブスクリプションの関係を表している）加入者のonSubscribe（購読秒）メソッドがトリガされますが、成功しています。
その後、通常は、パブリッシャにデータを要求するためにサブスクリプション要求（長N）メソッドをコールし続けることができ、n個のデータ・エントリの最大数です。

パブリッシャは3人の加入者のコールバックメソッドに対応する3つの異なるメッセージを持っています。

メッセージデータ：onNext方式に対応し、発行元を示すデータが生成されます。
エラーメッセージ：のonErrorメソッドは、パブリッシャがエラーを生成した表示に対応します。
メッセージの終了：対応onCompleteの方法は、出版社はすべてのデータの解放を完了したことを示します。

上記の3つの肯定応答は、エラーメッセージには、メッセージを後で生成されない、ストリームの現在の端部は、その端部に到達したことを示します。

サブスクリプション
サブスクリプションは、サブスクリプションの関係で表されます。（方法キャンセル）オブジェクトれるデータ（リクエストメソッド）を要求するか、解除することができます。
プロセッサ
特別なオブジェクトプロセッサは、プロデューサが、また、加入者の両方を表します。

負圧のサポート

負圧が上記インターフェースで定義されている式の流れに応じて重要な機能であり、実質的に負圧のサポートが提供されています。
出版社のみ要求を受信した後、データが生成されます。これは、自分の能力に応じて、加入者は、出版社自身のが洗い流されることはありません確実にするために要求されるデータの量を決定することを保証します。

例

さて、ストリームAPIを使用する方法反応性を実証するための簡単なコード例を持ちます。

特定の植物とミルクは、例えば、収入を増加させるために、植物は工場直接販売事業を開始しました。お客様は、直接工場に日の酪農一定数を注文することができ、毎日が工場出荷時のサービス担当者牛乳屋ドアです。
このシナリオをシミュレートするために、我々は次のようなコードがあると認識します。

牛乳工場、実現出版社：

public class MilkFactory extends SubmissionPublisher<String> {

    private final ScheduledFuture<?> periodicTask;
    private final ScheduledExecutorService scheduler;

    private static final List<String> milks = Arrays.asList("益力多", "酸牛奶", "原味奶", "低脂蛋奶", "羊奶", "甜牛奶");

    public MilkFactory() {
        super();
        //初始化定时器
        scheduler = new ScheduledThreadPoolExecutor(1);

        //每一天生产完牛奶并推送给消费者
        periodicTask = scheduler.scheduleAtFixedRate(
                () -> submit(produceMilk()), 0, 1, TimeUnit.SECONDS);
    }

    //随机生产牛奶
    private String produceMilk() {
        return milks.get((int) (Math.random() * milks.size()));
    }

    //关闭流
    public void close() {
        periodicTask.cancel(false);
        scheduler.shutdown();
        super.close();
    }
}

（バッファ実現Publisherを提供する）MilkFactory統合自己SubmissionPublisher、その内部には、毎日牛乳生産のリリースをシミュレートするユーザーのためのタイマーを開始します。
データは、送信（）メソッドを介してユーザにプッシュされてもよいです。

お客様が加入者を達成します：

public class MilkCustomer implements Flow.Subscriber<String> {
    private Flow.Subscription subscription;
    private AtomicInteger available = new AtomicInteger(0);
    private int dayCount;

    public MilkCustomer(int dayCount) {
         this.dayCount = dayCount;
    }
    @Override
    public void onSubscribe(Flow.Subscription subscription) {
        this.subscription = subscription;
        //设置总量
        available.set(dayCount);

        //第一天
        subscription.request(1);
    }

    @Override
    public void onNext(String milk) {
        System.out.println("今天的牛奶到了: " + milk);

        //如果还有存量，继续请求
        if(available.decrementAndGet() > 0){
            subscription.request(1);
        }else{
            System.out.println("牛奶套餐已经派完，欢迎继续订购");
            this.subscription.cancel();
        }
    }

    @Override
    public void onError(Throwable t) {
        t.printStackTrace();
    }

    @Override
    public void onComplete() {
        System.out.println("closed.");
    }
}

MilkCustomerが上院にDAYCOUNTを受け入れるように、それは量は、注文したことを意味したときにミルク初日の最初のサブスクリプション要求、その後、ミルク、それが受信するたびに次の日の総消費量が完了するまで要求した後。

テスト手順

次のコードを実行します。

MilkFactory factory = new MilkFactory();

//订阅1周
MilkCustomer customer = new MilkCustomer(7);

factory.subscribe(customer);

出力：

今天的牛奶到了: 酸牛奶
今天的牛奶到了: 羊奶
今天的牛奶到了: 原味奶
牛奶套餐已经派完，欢迎继续订购

概要

上記の例では、反応性ストリームAPIのJava実装では、「牛乳屋ドア」トラフィックフローを提供します。
全体のプロセスは、重要な地域の対流過程を理解する上で嘘、およびサブスクリプションの関係は比較的簡単です。しかし、現在の反応達成には、このような春WebFlux（SpringBoot 2サポートは）まだ次の操作を行うための機会が続く構築する代わりに、反応性ストリームAPIの原子炉のプライベートAPIをベースにしていて、完全に統一されていません。

深い読み

今後の差とCompletableFutureについて
https://juejin.im/post/5adbf8226fb9a07aac240a67