AWS Kinesisは特定のタイプの注文を保証しますか？
AWSから ドキュメント ：
Kinesisデータストリームは、データレコードの順序付けされたシーケンスです。ストリームの各レコードには、Kinesis Data Streamsによって割り当てられたシーケンス番号があります
これらの2つの文の間に関連はありません。また、ドキュメントでは、どのような種類の順序であるかを明示的に指定していません。
簡単な調査の結果、AWSプロデューサーライブラリ（KPLなど）を使用している場合、Kinesisから使用するときに、libがKinesisレコードに正常に送信した順序が維持されることがわかりました。問題は、このレコードの順序が、ライブラリに送信したレコードの順序と同じになることを保証しないことです。
Application -(1)> KPL -(2)> Kinesis
順序は、KPLからKinesisに正常に送信されたレコードのシーケンスによって決定されます。 （ネットワーク障害の場合、他のレコードが送信された後、レコードがKPLから再度送信されます）。
単語の定義はランダムにhere です。
すべての結果が等しく可能性があるイベントの、またはそれに関連する...
私の結論は、アプリケーションがレコードをキネシスにランダムな順序で送信するということです。つまり、順序はまったくありません。アプリケーションがあらゆる種類の注文を保証する必要がある場合は、独自のライブラリを作成し、それらを使用しないでください。
ここで何か不足していますか？
私が使用する用語は、「ランダム」ではなく「任意」です。しかし、あなたの観察は正しいです。シーケンス番号は、レコードがパーティションに追加された順序を示すだけです。これらは、プロデューサーの順序感覚を反映するためではなく、コンシューマーが（AFTER_SEQUENCE_NUMBERシャードイテレーターを使用して）中断したところから読み続けることができるようにすることを目的としています。複数のシャードを導入し、パーティションキーを使用して書き込みを分散させると、問題はさらに難しくなります。
これは、ソースから宛先への複数のパスが存在するany分散システムの問題です。システム全体の順序を保証することはできません（まあ、lotの努力がないとできません） ）。
したがって、解決策は、システムにレコードを配置する前にレコードの順序付けを行うことです。アプリケーションが、レコードがストリームに書き込まれるまで順序を維持できると想定します（これはめったに当てはまりません）。次に、各レコードにシーケンス番号を追加できます（これは、書き込まれるペイロードの一部である必要があります）キネシス）。
次に、リーダーはそれらのシーケンス番号に基づいて順序を再適用する必要があります。これは完全に扱いにくい問題ではありません。ストリームに書き込まれる前に順序付けられたレコードは、ストリームから読み取られると通常互いに接近します（したがって任意順序、ないランダム）。したがって、途切れのないシーケンスが蓄積されるまでレコードをメモリに保持してから、それらを処理しているものに渡します。