ackによって引き起こされた嵐の待ち時間

Question

私はkafkaとstormを接続するためにkafka-stormを使用していました。 zookeeper、kafka、stormという3つのサーバーがあります。 9つのパーティションを持つkafkaのトピック 'test'があります。

ストームトポロジでは、KafkaSpoutエグゼキュータの数は9です。デフォルトでは、タスクの数も9でなければなりません。そして、 'extract'ボルトはKafkaSpoutに接続されている唯一のボルト、 'log'スパウトです。

UIから、スパウトには大きな障害が発生しています。しかし、ボルトで実行されたメッセージの数=放出されたメッセージの数 - ボルトで失敗したメッセージの数。この式は、最初に失敗したメッセージが空の場合にほぼ一致します。

私の理解によれば、これはボルトがメッセージをスパウトから受信しましたが、ack信号は飛行中に中断されています。だからこそスパウトの厄介者の数が非常に少ない理由です。

この問題は、timeout秒とspout保留メッセージ番号を増やすことで解決できます。しかし、これによりメモリ使用量が増え、無限に増やすことはできません。

スパム/ボルトで嵐を強制的に無視してタイムアウトまでその信号を待たないようにする方法があれば、私はさまよっていました。これにより、全体的に大幅に増加するはずですが、メッセージ処理が保証されません。

Answer 1

ackersの数を0に設定すると、stormは自動的にすべてのサンプルを確認します。

config.setNumAckers(0); 

UIはデータフローの5％しか測定しないことに注意してください。 あなたは

config.setStatsSampleRate(1.0d); 

を設定しない限り、ボルトのタイムアウトを増やすとtopology.max.spout.pendingの量を減らしてみてください。

また、spoutのnextTuple（）メソッドがブロックされておらず、最適化されていることを確認してください。

コードをプロファイリングすることをお勧めします。多分あなたの嵐のキューは満たされており、サイズを大きくする必要があります。

config.put(Config.TOPOLOGY_TRANSFER_BUFFER_SIZE,32); 
    config.put(Config.TOPOLOGY_EXECUTOR_RECEIVE_BUFFER_SIZE,16384); 
    config.put(Config.TOPOLOGY_EXECUTOR_SEND_BUFFER_SIZE,16384); 

Answer 2

あなたの能力番号はあなたが本当にシステムリソース（CPU、メモリ）を最大限に活用していることを信じて私をリードし、少し高いです。言い換えれば、このシステムはちょっと渋滞しているようで、タプルがタイムアウトしているのはおそらくそうです。 topology.max.spout.pending設定プロパティを使用して、スパウトからの飛行機タプルの数を制限することができます。十分に数を減らすことができれば、タプルがタイムアウトすることなく、トポロジが効率的に負荷を処理できるはずです。