1

Micro CloudFoundry にデプロイされた 2 つの Spring MVC アプリケーションがあり、1 つはファイルを読み取り、RabbitMQ のトピック Exchange のキューに約 3325 のメッセージを送信し、もう 1 つは非同期 MessageListener の助けを借りてそれらのメッセージを消費しています。問題は、リスナーがシーケンスなしでメッセージを取得していることです。一度に実行されているリスナーのスレッドが少なくとも 2 つあると思います。以下に示す OnMessage() メソッドで一連のメッセージを出力しようとしました。メッセージは、12、13、12、13 などの順序ではなく、パターンの残りの部分とは異なって受信されます。このカウントは、実際にはメッセージと共に受信された配信タグです。

Raw Message number: 1 contains: 1340099549587,BMA150 3-axis
Raw Message number: 1 contains: 1340099549626,BMA150 3-axis
Raw Message number: 2 contains: 1340099549666,BMA150 3-axis
Raw Message number: 2 contains: 1340099549705,BMA150 3-axis
Raw Message number: 3 contains: 1340099549746,BMA150 3-axis
Raw Message number: 3 contains: 1340099549810,BMA150 3-axis
Raw Message number: 4 contains: 1340099549866,BMA150 3-axis
Raw Message number: 4 contains: 1340099549906,BMA150 3-axis
Raw Message number: 5 contains: 1340099549951,BMA150 3-axis
Raw Message number: 5 contains: 1340099549999,BMA150 3-axis
Raw Message number: 6 contains: 1340099550063,BMA150 3-axis
Raw Message number: 6 contains: 1340099550063,BMA150 3-axis 
Raw Message number: 7 contains: 1340099550112,BMA150 3-axis 
Raw Message number: 7 contains: 1340099550169,BMA150 3-axis
Raw Message number: 8 contains: 1340099550258,BMA150 3-axis
Raw Message number: 8 contains: 1340099550210,BMA150 3-axis
Raw Message number: 9 contains: 1340099550324,BMA150 3-axis
Raw Message number: 9 contains: 1340099550362,BMA150 3-axis
Raw Message number: 10 contains: 1340099550380,BMA150 3-axis
Raw Message number: 10 contains: 1340099550417,BMA150 3-axis
Raw Message number: 11 contains: 1340099550456,BMA150 3-axis
Raw Message number: 11 contains: 1340099550496,BMA150 3-axis
Raw Message number: 12 contains: 1340099550535,BMA150 3-axis
Raw Message number: 13 contains: 1340099550575,BMA150 3-axis
Raw Message number: 12 contains: 1340099550616,BMA150 3-axis
Raw Message number: 13 contains: 1340099550714,BMA150 3-axis
Raw Message number: 14 contains: 1340099550682,BMA150 3-axis
Raw Message number: 14 contains: 1340099550748,BMA150 3-axis
Raw Message number: 15 contains: 1340099550795,BMA150 3-axis
Raw Message number: 15 contains: 1340099550850,BMA150 3-axis

私のSimpleMessageListenerContainerのコードは次のとおりです。

    @Bean
public SimpleMessageListenerContainer listenerContainer() {
        SimpleMessageListenerContainer container = new   SimpleMessageListenerContainer();      
        container.setConnectionFactory(connectionFactory());
        container.setQueues(super.workQueue());
        container.setConcurrentConsumers(1);
        MessageListenerAdapter messageListenerAdapter = new MessageListenerAdapter(new MessageHandler());
        container.setMessageListener(messageListenerAdapter);
        return container;
    }

迅速なご対応、誠に有難う御座います。

よろしくお願いします、

4

2 に答える 2

0

OPは2つのスレッドを使用して1つのキューから消費していたようです。そして、出力を 1 つのファイルに記録します。

2 つのスレッドが独立して動作していたので、一方のスレッドが他方よりも高速であったことに驚かないでください。

当時、基礎となるOSが何を管理していたのか誰が知っていますか?

OPがリスナーインスタンスを1つだけ使用したことは、おそらく悪いアドバイスではありません。

于 2020-11-17T06:34:19.477 に答える
-1

あなたの問題はおそらく複数のコンシューマーに関係しています。私のアドバイスは、メッセージの順序が間違っていても問題が発生しないようにソリューションを設計することです。（これは実用的ではないかもしれませんが）。

以下はhttp://www.rabbitmq.com/semantics.htmlからのものです。

メッセージ順序の保証

AMQP 0-9-1 コア仕様のセクション 4.7 では、順序が保証される条件について説明しています。1 つのチャネルで発行され、1 つの交換と 1 つのキューを通過し、1 つの送信チャネルを通過するメッセージは、送信されたのと同じ順序で受信されます。RabbitMQ は、リリース 2.7.0 以降、より強力な保証を提供します。

メッセージは、requeue パラメーター (basic.recover、basic.reject、basic.nack) を備えた AMQP メソッドを使用して、または未確認のメッセージを保持している間にチャネルを閉じることによって、キューに戻すことができます。これらのシナリオのいずれかにより、RabbitMQ リリースが 2.7.0 より前のキューの後ろにメッセージが再キューイングされました。RabbitMQ リリース 2.7.0 から、再キューイングまたはチャネル閉鎖が存在する場合でも、メッセージは常に発行順にキューに保持されます。

リリース 2.7.0 以降では、キューに複数のサブスクライバーがある場合、個々のコンシューマーがメッセージの順序が正しくないことを観察する可能性があります。これは、メッセージを再キューイングする可能性がある他のサブスクライバーのアクションによるものです。キューの観点からは、メッセージは常に発行順に保持されます。

そのため、コンシューマーは 1 つだけにするようにアドバイスされているようです。

于 2013-01-29T23:14:12.837 に答える