クライアントから受信した注文を処理することを主な目的とするNode.jsアプリケーションがループバックを実行しています。現在、受注プロセスでは、支払い、データベースへの挿入、確認メールの送信など、httpリクエストの処理中にすべての注文処理が処理されます。Heroku上の複数のdynosにまたがってスケーリングされたときに同じキュージョブが複数回処理されるのを避ける方法
この方法では、現時点ではスケーラビリティが欠けていますアプリケーションが成長するにつれて、1分間に何千もの注文を処理する必要があります。さらに、現在のところ、注文プロセスでは独自のデータベースにデータが書き込まれていますが、スピードや可用性を制御できない第三者の統合（システムまで）が検討されています。
さらに、現在、競合状態になる可能性もあります。クライアントが簡単に参照できるように各注文に「短いコード」を割り当てる必要があります。これらは回転する必要があるため、開始番号が1で最大値が100の場合、101番目の番号には番号1を割り当てる必要があります。私たちは以前の注文を見て、前の参照を1つインクリメントするか、またはそれを最初に戻すかのどちらかです - 交通量が少ないため現時点では問題ありませんが、これを拡大すると複数の注文に同じ参照番号。
したがって、このすべてを管理するキューを実装したいと考えています。私たちのアプリは現在、Herokuに配備されています。ここでは、アプリが必要とする毎月のナンバークランチングのためにワーカープロセスを使用しています。あるキュー（https://devcenter.heroku.com/articles/asynchronous-web-worker-model-using-rabbitmq-in-node、https://devcenter.heroku.com/articles/background-jobs-queueing）の実装に関するHerokuの記事の一部を読んでいる間に、複数の作業者のdynos上で、これらのキューに入れられたアイテムがどのように処理され、同じジョブが一度は複数のダイノスによって。処理の順序はそれほど重要ではありませんが、繰り返しの欠如は、2つのオーダーが同時に処理され、上記の競合状態のリスクを冒すように非常に重要です。
これは基本的に私の質問です。 Heroku上の複数のdynosにまたがってスケーリングされたときに、同じキュージョブが複数回処理されることを回避するにはどうすればよいですか？
http://stackoverflow.com/questions/35946177/node-js-message-queue-を参照してください。 Herokuでnode.jsを使ってこれを設定する方法については、on-heroku/36029289＃36029289を参照してください。 –
この回答は、OPによって要求される「正確に1回」の配送を解決するものではありません。 – idbehold
@idbeholdキューは「正確に1回」の配信を要求します。トム、3桁のコードの回転は、10進数のエンコーディングで問題になります。あなたは一度に999の理論上の未処理注文しか持てません。若干優れたオプションは、異なるベースエンコーディングを使用することです。たとえば、base58エンコーディング（http://stackoverflow.com/a/18949941/673882）を使用した場合、3文字のみを使用して195,000を超える組み合わせになります。これらの参照番号が内部注文番号を参照するために恒久的に保存されていることを意味する場合、そのソリューションは機能しません。 –