Kafkaで非同期APIを使用して払い戻しツールサービスを開発した経験

合理化されたプロセスと多数の相互接続されたサービスを備えたLamodaのような大企業を作ることができる方法は何でしょうか。 動機は完全に異なる場合があります。立法から、すべてのプログラマーに内在する実験への欲求までです。



しかし、これは、追加の利益を期待できないという意味ではありません。 Kafkaにイベント駆動型APIを実装した場合、正確に何が得られるのか、Sergey Zaika（ 少数の ）が教えてくれます。 ぬいぐるみや興味深い発見についても、確かにあります-実験はそれらなしではできません。







免責事項：この記事は、2018年11月にHighLoad ++でセルゲイが開催したmitapの資料に基づいています。 ラモダのカフカとのライブ体験は、他のスケジュールレポートと同じようにリスナーを魅了しました。 これは、志を同じくする人々を見つけることは常に可能であり、必要であるという事実の素晴らしい例であり、HighLoad ++の主催者はこれを助長する雰囲気を作り続けようとするでしょう。

プロセスについて

Lamodaは、独自のコンタクトセンター、配信サービス（および多くのアフィリエイトサービス）、写真スタジオ、巨大な倉庫を備えた大規模なeコマースプラットフォームであり、これらはすべてソフトウェアで動作します。 これらのサービスの一部またはすべてを使用でき、製品の最新情報を知りたいB2Bパートナーには、多数の支払い方法があります。 さらに、ラモダはロシア連邦に加えて3つの国で働いており、そこではすべてが少し異なります。 合計で、おそらく新しい注文を構成する方法は100を超えるため、独自の方法で処理する必要があります。 これはすべて、時には自明ではない方法で通信する多数のサービスの助けを借りて機能します。 また、主な責任が注文のステータスである中央システムもあります。 私たちは彼女をBOBと呼び、私は彼女と一緒に仕事をしています。

イベントドリブンAPIを備えた返金ツール

イベントドリブンという言葉はかなりハックされていますが、これが何を意味するのかをもう少し詳しく定義します。 まず、Kafkaイベント駆動型APIアプローチを試してみることにしたコンテキストから始めましょう。







どの店舗でも、顧客が支払う注文に加えて、製品が顧客に適合しなかったため、店舗が返品を要求される場合があります。 この比較的短いプロセス：そのような必要がある場合、情報を明確にし、お金を転送します。



しかし、法案の変更により返品は複雑であり、個別のマイクロサービスを実装する必要がありました。







私たちの動機：

1. 法律FZ-54-簡潔に言えば、法律では、数分でかなり短いSLAで、返品であれ受領であれ、各金融取引について税務署に報告することが義務付けられています。 私たちは、電子商取引として、かなりの数の業務を行っています。 技術的には、これは関連するすべてのシステムの新しい責任（したがって新しいサービス）と改善を意味します。
2. BOBスプリット -BOBから多数の非中核的責任を取り除き、全体的な複雑さを軽減するための社内プロジェクト。

この図は、基本的なLamodaシステムを示しています。 現在、それらのほとんどは、減少するモノリス周辺の5〜10個のマイクロサービスの星座のようなものです。 それらはゆっくりと成長していますが、中央にハイライトされたフラグメントを展開するのは怖いので、私たちはそれらを小さくしようとしています-それを落とすことはできません。 すべての交換（矢印）を予約する必要があり、それらのいずれかが利用できない場合があるという事実に基づいています。



BOBには、支払い、配送、通知システムなど、非常に多くのやり取りがあります。



技術的には、BOBは次のとおりです。

• 〜150k行のコード+〜100k行のテスト。
• php7.2 + Zend 1およびSymfonyコンポーネント3;
• > 100 APIおよび〜50のアウトバウンド統合。
• 独自のビジネスロジックを持つ4か国。

BOBの展開は高価で苦痛であり、コードの量とそれが解決するタスクは、誰も頭に入れることができないほどです。 一般的に、それを単純化する多くの理由があります。

返品プロセス

最初は、BOBと支払いの2つのシステムがプロセスに関与しています。 さらに2つ表示されます。

• 財政化サービスは、財政化と外部サービスとのコミュニケーションの問題を処理します。
• 払い戻しツール。BOBを膨張させないために、新しい交換が簡単に取り出されます。

プロセスは次のようになります。

1. BOBは払い戻しリクエストを受け取ります。
2. BOBはこの払い戻しツールについて話します。
3. 払い戻しツールには支払いが記載されています：「返金してください。」
4. 支払いはお金を返します。
5. 払い戻しツールとBOBは、現在両方のステータスを必要としているため、互いにステータスを同期します。 BOBにはUI、アカウンティング用のレポート、通常は簡単に転送できない大量のデータがあるため、払い戻しツールに完全に切り替える準備はまだできていません。 2つの椅子に座る必要があります。
6. 会計要求は去ります。

その結果、私たちはカフカでイベントバスのようなものを作りました-イベントバスで、すべてが始まりました。 やれやれ、今では単一障害点（皮肉）があります。







長所と短所はかなり明白です。 バスを作ったので、今ではすべてのサービスがそれに依存しています。 これにより設計が簡素化されますが、システムに単一障害点が導入されます。 カフカは低下し、プロセスは上昇します。

イベント駆動型APIとは

この質問に対する適切な答えは、Martin Fowler（GOTO 2017）によるレポート「イベント駆動型アーキテクチャの多くの意味」にあります。



簡単に言えば、私たちがしたこと：

1. イベントストレージを介してすべての非同期交換をラップしました。 関心のある各消費者にネットワーク経由でステータスの変更を通知する代わりに、ステータス変更イベントを中央リポジトリに書き込み、トピックに関心のある消費者がそこから表示されるすべてを読み取ります。
2. この場合のイベントは、どこかで何かが変更されたという通知（ notification ）です。 たとえば、注文ステータスが変更されました。 ステータスの変更に伴う何らかの種類のデータに関心があり、通知に含まれていない消費者は、自分でステータスを調べることができます。
3. 最大のオプションは、本格的なイベントソーシングである状態転送です。このイベントには、処理に必要なすべての情報が含まれます。どこからどのようなステータスまで転送されたか、データが正確にどのように変更されたかなどです。

払い戻しツールの発売の一環として、3番目のオプションを使用しました。 これにより、詳細な情報を取得する必要がないため、イベントの処理が簡素化されました。さらに、新しいイベントが発生するたびに消費者からのgetリクエストが明確になるというシナリオが除外されました。



払い戻しツールサービスは読み込まれないため、Kafkaは必要というよりペンテストのようなものです。 払い戻しサービスが高負荷のプロジェクトになったら、ビジネスは幸せになるとは思いません。

非同期交換

非同期交換の場合、PHP部門は通常RabbitMQを使用します。 リクエストのデータを収集してキューに入れ、同じサービスのコンシューマーがそれを読み取って送信しました（または送信しませんでした）。 API自体については、LamodaはSwaggerを積極的に使用しています。 APIを設計し、Swaggerで記述し、クライアントコードとサーバーコードを生成します。 また、少し高度なJSON RPC 2.0も使用します。



あちこちでesbバスが使用され、誰かがactiveMQに住んでいますが、一般的にはRabbitMQが標準です。

非同期交換

イベントバスを介して取引所を設計する場合、類推が追跡されます。 同様に、イベント構造の説明を通じて将来のデータ交換について説明します。 yaml形式、コード生成は自分で行う必要があり、ジェネレーターは仕様に従ってDTOを作成し、クライアントとサーバーにそれらの操作方法を教えます。 生成はgolangとphpの 2つの言語になります。 これにより、ライブラリの一貫性が保たれます。 ジェネレータはgolangで記述されており、gogiという名前が付けられています。



Kafkaでのイベントソーシングは典型的なものです。 Kafka Confluentのメインエンタープライズバージョンからの解決策があります。Zalandoドメインエリアの「兄弟」からの解決策であるnakadiがあります。 バニラ・カフカから始める動機は、どこでも使用するかどうかを最終的に決定するまでソリューションを無料のままにし、さらに操作と改善の余地を残すことです： JSON RPC 2.0のサポート、2つの言語のジェネレーター、およびその他の機能を確認します。



皮肉なことに、このような幸せなケースでさえ、同様の決定を下したザランドと同様のビジネスがある場合、それを効果的に使用することはできません。



アーキテクチャ上、起動時のパターンは次のとおりです。Kafkaから直接読み取りますが、イベントバスを介してのみ書き込みます。 Kafkaには多くの読み物があります：ブローカー、バランサー、そして水平スケーリングの準備が多かれ少なかれ、私はそれを維持したかったです。 記録として、イベントバスとして知られる1つのゲートウェイをラップしたかったのです。それが理由です。

イベントバス

またはイベントバス。 これは、いくつかの重要な役割を担う単なるステートレスhttpゲートウェイです。

• 生産の検証 -イベントが仕様を満たしていることを検証します。
• イベントマスタシステム 、つまり、これは、どの構造のイベントが有効であると見なされるかという質問に答える、企業内のメインで唯一のシステムです。 検証には、コンテンツの厳密な指定のためのデータ型と列挙が含まれます。
• シャーディングのハッシュ関数 -Kafkaメッセージ構造はキーと値であり、ここではキーからのハッシュがそれをどこに置くかを計算します。

なぜ

私たちは、合理化されたプロセスを持つ大企業で働いています。 なぜ変更するのですか？ これは実験であり、いくつかの利点が期待されます。

1：n + 1回の交換（1対多）

Kafkaを使用すると、新しい消費者をAPIに簡単に接続できます。



いくつかのシステム（およびいくつかの新しいシステム）で同時に最新の状態に保つ必要があるディレクトリがあるとします。 以前は、set-APIを実装するバンドルを発明し、コンシューマシステムのアドレスがマスターシステムに報告されました。 これで、マスターシステムはトピックの更新と、読書に興味があるすべての人に更新を送信します。 新しいシステムが登場しました-彼らはトピックでそれに署名しました。 はい、バンドルもできますが、より簡単です。



BOBの一部である払い戻しツールの場合、Kafkaを使用してそれらを同期させておくと便利です。 支払いは、彼らがお金を返したと言います：BOB、RTはそれを見つけて、彼らのステータスを変えました、Fiscalization Serviceはそれを見つけて小切手をノックアウトしました。







クライアントに注文/返品に関するニュースを通知する単一の通知サービスを作成する計画があります。 現在、この責任はシステム間で分散しています。 通知サービスに、Kafkaからの関連情報をキャッチして応答する（および他のシステムでこれらの通知を無効にする）ことを教えるだけで十分です。 新しい直接交換は必要ありません。

データ駆動

システム間の情報は透明になります-あなたがどんなに血なまぐさい企業であっても、あなたのバックログがどれほど膨れあがっていても。 Lamodaにはデータ分析部門があり、ビジネスおよびインテリジェントシステムの両方で、システム上のデータを収集し、再利用可能な形式にします。 Kafkaを使用すると、大量のデータをすばやく提供し、この情報を最新の状態に保つことができます。

複製ログ

RabbitMQのように、メッセージは読み取り後に消えません。 イベントに処理に十分な情報が含まれている場合、オブジェクトに対する最近の変更の履歴があり、必要に応じてこれらの変更を適用することができます。



レプリケーションログの保存期間は、このトピックの記録強度によって異なりますが、Kafkaを使用すると、保存時間とデータボリュームの制限を柔軟に設定できます。 集中的なトピックの場合、短期的な操作不能の場合でも、すべての消費者が情報が消える前に読む時間があることが重要です。 通常、日単位のデータを保存することが判明しますが、これはサポートには十分です。







次に、Kafkaに精通していない人のために、ドキュメントを少し改めます（写真もドキュメントから）



AMQPにはキューがあります。コンシューマーのキューにメッセージを書き込みます。 原則として、1つのキューは同じビジネスロジックを持つ1つのシステムによって処理されます。 複数のシステムに通知する必要がある場合は、アプリケーションに複数のキューに書き込むか、それ自体を複製するファンアウトメカニズムとの交換を設定するように教えることができます。



Kafkaには、メッセージを書くという同様のトピック抽象化がありますが、読むと消えません。 デフォルトでは、Kafkaに接続すると、すべてのメッセージを受信すると同時に、中断した場所を保存する機会があります。 つまり、順番に読むと、メッセージに既読のマークを付けることはできませんが、IDを保存し、そこから読み続けることができます。 停止するIDはオフセットと呼ばれ、メカニズムはコミットオフセットです。



したがって、異なるロジックを実装できます。 たとえば、さまざまな国の4つのインスタンスにBOBがあります。ラモダはロシア、カザフスタン、ウクライナ、ベラルーシにあります。 個別にデプロイされるため、独自の構成とビジネスロジックが少しあります。 メッセージでどの国を指しているかを示します。 各国の各BOBコンシューマーは異なるgroupIdで読み取り、メッセージが彼に適用されない場合はスキップします。 オフセット+1を直ちにコミットします。 同じトピックが支払いサービスによって読み取られる場合、別のグループでこれが行われるため、オフセットは重複しません。



イベント要件：

• データの完全性。 イベントに十分なデータがあり、処理できるようにしたいです。

• 誠実さ イベントが一貫しており、それを処理できることをイベントバスに委任します。
• 順序が重要です。 復帰の場合、私たちは歴史を扱うことを余儀なくされます。 通知の場合、順序は重要ではありません。それらが同種の通知である場合、最初に到着した順序に関係なく、電子メールは同じになります。 返品の場合、明確なプロセスがあり、注文を変更すると例外が発生し、払い戻しは作成も処理もされません-異なるステータスになります。
• コヒーレンス。 リポジトリがあり、APIの代わりにイベントを作成します。 新しいイベントや既存のイベントへの変更に関する情報をサービスに迅速かつ安価に転送する方法が必要です。 これは、別個のgitリポジトリとコードジェネレーターで共通の仕様を使用して実現されます。 したがって、異なるサービスのクライアントとサーバーは同意しました。

ラモダのカフカ

3つのKafkaインストールがあります。

1. ログ
2. 研究開発;
3. イベントバス。

今日は最後のポイントについてのみ話します。 イベントバスでは、3つのブローカー（サーバー）と合計27のトピックという非常に大規模なインストールはありません。 原則として、1つのトピックは1つのプロセスです。 しかし、これは微妙な瞬間であり、今から触れます。







上はrpsチャートです。 払い戻しプロセスには青緑色の線（はい、X軸上にある線）が付いており、ピンクはコンテンツ更新プロセスです。



Lamodaのカタログには何百万もの製品が含まれており、データは常に更新されています。 一部のコレクションは時代遅れになり、それらの代わりに新しいものがリリースされ、新しいモデルがカタログに常に表示されます。 明日、お客様にとって何が面白いかを予測するため、常に新しいものを購入し、写真を撮り、ウィンドウを更新しています。



ピンクのピークは製品の更新、つまり製品の変更です。 男たちが写真を撮った、写真を撮った、そして再び撮ったことがわかる！ -イベントのパケットをダウンロードしました。

Lamoda Eventsのユースケース

このような操作には、構築されたアーキテクチャを使用します。

• 返品ステータスの追跡 ：行動を促すフレーズと、関連するすべてのシステムからのステータスの追跡。 支払い、ステータス、会計、通知。 ここでは、アプローチを試し、ツールを作成し、すべてのバグを収集し、ドキュメントを書き、同僚にその使用方法を伝えました。
• 製品カードの更新：構成、メタデータ、特性。 1つのシステムが読み取り（表示）し、いくつかのシステムが書き込みます。
• 電子メール、プッシュ、SMS ：注文が収集され、注文が到着し、返品が受け付けられた、など、それらの多く。
• 在庫、倉庫の更新 -アイテムの定量的な更新、数字だけ：倉庫での受け取り、返品。 商品の予約に関連するすべてのシステムは、最も関連性の高いデータで動作する必要があります。 排水管のアップグレードシステムは非常に複雑になりましたが、Kafkaはそれを簡素化します。
• データ分析 （R＆D部門）、MLツール、分析、統計。 情報を透明にしたい-このため、Kafkaは非常に適しています。

今、より興味深い部分は、6か月にわたって発生した詰め込みバンプと興味深い発見についてです。

設計の問題

たとえば、配信プロセス全体をKafkaに転送するなど、新しいことをしたいとします。 現在、プロセスの一部はBOBの注文処理に実装されています。 注文の配送サービスへの転送、中間倉庫への転送などの背後には、ステータスモデルがあります。 モノリス全体があり、2つに加えて、配信専用APIの束があります。 彼らは配達についてより多くを知っています。



これらは類似した領域のように見えますが、BOBでの注文処理と配信システムでは、ステータスが異なります。 たとえば、一部の宅配便サービスは中間ステータスを送信せず、最終ステータスのみを配信します。「配信済み」または「紛失」です。 それどころか、商品の移動について詳細に報告する人もいます。 誰もが独自の検証ルールを持っています。誰かにとっては、電子メールは有効であるため、処理されます。 他の人にとっては有効ではありませんが、通信のための電話があるため、注文は処理されます。そのような注文はまったく処理されないと誰かが言うでしょう。

データストリーム

Kafkaの場合、データフローを整理するという疑問が生じます。 このタスクは、いくつかのポイントの戦略の選択に関連しています。それらすべてを検討します。

あるトピックで、または別のトピックで？

イベントの仕様があります。 BOBでは、このような注文を配信する必要があることを記述し、注文番号、その構成、一部のSKUおよびバーコードなどを示します。 商品が倉庫に到着すると、配送はステータス、タイムスタンプ、および必要なすべてのものを受け取ることができます。 しかし、さらにこのデータの更新をBOBで受け取りたいと考えています。 配信からデータを取得する逆のプロセスに直面しています。 これは同じイベントですか？ それとも、別のトピックに値する別の交換ですか？



おそらく、それらは非常によく似ており、1つのトピックを作成する誘惑は不合理ではありません。なぜなら、個別のトピックは個別のコンシューマー、個別の構成、これらすべての個別の世代だからです。 しかし、事実ではありません。

新しいフィールドまたは新しいイベント？

ただし、同じイベントを使用すると、別の問題が発生します。 たとえば、すべての配信システムがBOBを生成できるDTOを生成できるわけではありません。 IDを送信しますが、それらは必要ないため保存しません。イベントバスプロセスを開始するという観点から、このフィールドは必須です。



このフィールドが必須であるというイベントバスのルールを導入すると、BOBまたは開始イベントハンドラーで追加の検証ルールを設定する必要があります。 検証はサービスに忍び込み始めます-それはあまり便利ではありません。



もう1つの問題は、増分マイニングの誘惑です。 イベントに何かを追加する必要があると言われますが、慎重に考えれば、別のイベントになっているはずです。 しかし、このスキームでは、別のイベントは別のトピックです。 別のトピックは、上で説明したプロセス全体です。 開発者は、JSONスキームに別のフィールドを追加して再生成したいだけです。



払い戻しの場合、6か月間イベントイベントに参加しました。 払い戻し更新と呼ばれるメタイベントが1つありました。このイベントには、この更新が実際に何を構成するかを記述するタイプフィールドがありました。 このため、このタイプでこのイベントを検証する方法を示すバリデーターを持つ「美しい」スイッチがありました。

イベントのバージョン管理

Avroを使用してKafkaでメッセージを検証できますが、すぐにそれを使用してConfluentを使用する必要がありました。 この場合、バージョン管理には注意する必要があります。 モデルには「左」があるため、レプリケーションログからメッセージを再読み込みできるとは限りません。 基本的に、モデルが後方互換性を持つようにバージョンをビルドすることが判明しました。たとえば、フィールドを一時的にオプションにします。 違いが強すぎる場合は、新しいトピックの執筆を開始し、クライアントは古いトピックを読んだときに移植されます。

読み取り順序保証パーティション

Kafka内のトピックはパーティションに分割されています。 エンティティと交換を設計する間、それはあまり重要ではありませんが、それをどのように適合させ、スケーリングするかを決定するときは重要です。



通常の場合、Kafkaで1つのトピックを作成します。 デフォルトでは、1つのパーティションが使用され、このトピックのすべてのメッセージがそのパーティションに分類されます。 そして、消費者はこれらのメッセージを順番に読み取ります。 メッセージが2つの異なるコンシューマーによって読み取られるようにシステムを拡張する必要があるとします。 たとえば、SMSを送信する場合、追加のパーティションを作成するようにKafkaに指示できます。Kafkaは2つの部分でメッセージのレイアウトを開始します。



Kafkaはどのようにそれらを共有しますか？ 各メッセージには本文（JSONを格納する）とキーがあります。 このキーにハッシュ関数を添付して、メッセージがどのパーティションに分類されるかを決定できます。



払い戻しの場合、これは2つのパーティションを取る場合に重要です。つまり、並列コンシューマーが最初のイベントよりも早く2番目のイベントを処理し、トラブルが発生する可能性があります。 ハッシュ関数は、同じキーを持つメッセージが同じパーティションに入るようにします。

イベントとコマンド

これは、私たちが遭遇した別の問題です。 イベントはイベントです。たとえば、アイテムがキャンセルされた、払い戻しが発生したなど、どこかで何かが発生した（something_happened）と言います。 誰かがこれらのイベントをリッスンすると、「キャンセルされたアイテム」によって払い戻しの本質が作成され、「払い戻しが発生しました」がセットアップのどこかに書き込まれます。



しかし、通常、イベントを設計するとき、無駄にイベントを書きたくはありません-誰かがそれを読むと仮定します。 誘惑は、something_happened（item_canceled、re還_refunded）を書くことではなく、something_should_be_doneを書くことです。 たとえば、アイテムは返品可能です。



一方で、これはイベントがどのように使用されるかを示します。 一方、通常のイベント名とはあまり似ていません。 さらに、do_somethingコマンドはここから遠くありません。 しかし、誰かがこのイベントを読んだという保証はありません。 そして、あなたが読んだ場合、正常に読んでください。 そして、私がそれを首尾よく読んだなら、私は何かをしました、そして、この何かはうまくいきました。 イベントがdo_somethingになった瞬間、フィードバックが必要になりますが、これは問題です。







RabbitMQの非同期交換では、メッセージを読んでHTTPにアクセスすると、少なくともメッセージが受信されたことを示す応答が返されます。 Kafkaに手紙を書いたとき、Kafkaに手紙を書いたというメッセージがありますが、その処理方法については何も知りません。



そのため、この場合、応答イベントを導入して監視を設定し、非常に多くのイベントが発生した場合、その後などに同じ数の応答イベントが到着するようにする必要がありました。 これが起こらなかった場合、何かがうまくいかなかったようです。 たとえば、イベント「item_ready_to_refund」をディスパッチした場合、払い戻しが行われ、お金がクライアントに返され、イベント「money_refunded」が送信されることが予想されます。 しかし、これは正確ではないため、監視が必要です。

ニュアンス

かなり明白な問題があります：トピックから順番に読んで、何らかのメッセージが悪い場合、消費者は落ちて、あなたは去りません。 すべてのコンシューマを停止し 、さらにオフセットをコミットして読み続ける必要があります。



私たちはそれを知っていて、それを置いたが、それでも起こった。 これは、イベントがイベントバスの観点から有効であり、イベントがアプリケーションバリデータの観点から有効だったために発生しましたが、PostgreSQLの観点からは有効ではありませんでした。システムはINTのみを備えたPostgreSQLでした。 サイズがわずかに小さく、IDは適合しませんでした。 symfonyは例外で死亡しました。 もちろん、私たちはそれを信じてこのオフセットをコミットしようとしていたので、例外をキャッチしましたが、その前に、メッセージが正常に処理されなかったため、問題カウンターをインクリメントしたいと思いました。 このプロジェクトのカウンターもデータベースにあり、Symfonyはすでにデータベースとの通信を閉じており、2番目の例外はオフセットをコミットする機会なしにプロセス全体を強制終了しました。



しばらくの間、サービスは終了しました-幸いなことに、Kafkaではメッセージが残っているため、それほど怖くありません。 作業が復元されると、それらを読み取ることができます。 これは便利です。



Kafkaには、ツールを使用して任意のオフセットを設定する機能があります。 ただし、これを行うには、すべてのコンシューマーを停止する必要があります。この例では、コンシューマーの再デプロイを行わない個別のリリースを準備します。 その後、Kafkaはツーリングを使用してオフセットをシフトでき、メッセージは通過します。



別のニュアンス- レプリケーションログとrdkafka.so-は、プロジェクトの詳細に関連しています。 PHPがあります。PHPでは、原則として、すべてのライブラリがrdkafka.soリポジトリを介してKafkaと通信し、その後何らかのラッパーが付属します。 これらは私たちの個人的な問題かもしれませんが、すでに読んだものを読み直すだけではそれほど簡単ではないことがわかりました。 一般的に、ソフトウェアの問題がありました。



パーティションを操作する機能に戻ると、ドキュメントでは直接、 consumer> = topic partitionsと表示されます。 しかし、私はこれが私が望んでいるよりもずっと遅れて知りました。 スケーリングして2つのコンシューマーを使用する場合は、少なくとも2つのパーティションが必要です。 つまり、2万のメッセージが蓄積されたパーティションが1つあり、新しいパーティションを作成した場合、メッセージの数はすぐに均等になります。 したがって、2つの並列コンシューマを使用するには、パーティションを処理する必要があります。

モニタリング

私たちがそれを監視する方法は、現在のアプローチがどんな問題を抱えているかをさらに明確にするだろうと思います。



たとえば、データベース内の商品のステータスを最近変更した数を考慮し、それに応じて、これらの変更でイベントが発生するはずであり、この数を監視システムに送信します。 Kafka , . , .







, , , events-bus , . , Refund Tool , BOB - ( ).







consumer-group lag. , . , 0, . Kafka , .



Burrow , Kafka. API consumer-group , . Failed warning, , — , . , .







API. bob-live-fifa, partition refund.update.v1, , lag 0 — offset -.







updated_at SLA (stuck) . , , . Cron, , 5 refund ( ), - , . Cron, , 0, .



, , :

• ;
• ;
• .

, — API Kafka, .

-, HighLoad++ , , .

-, KnowledgeConf . , 26 , .

PHP Russia ++ ( DevOpsConf ) — , .