Kafka
ミッションクリティカルなデータの「真実の情報源」としてkafkaを使用することは賢明ですか？
設定は次のとおりです。
- kafkaは、データの根本的な情報源です。 -クエリは、kafkaからハイドレートされたキャッシュ（つまり、Redis、ktables）で行われます
- 耐久性のために構成されたKafka（無限トピック保持、3 +レプリケーション係数など）
- アーキテクチャはCQRSパターンに従います（kafkaへの書き込み、キャッシュからの読み取り）
- アーキテクチャにより、読み取りと書き込みの間の結果整合性が可能
いかなる状況でもデータを失うことは許可されていません
理論的には、複製によって耐久性と復元力が保証されます。コンフルエント自身が上記のパターンを奨励します。
私が考えることができる唯一の欠陥は：
- キャッシュが爆発し、最初から再水和する必要がある->クエリ
- ブローカーディスクが消去または破損する-> kafka再調整、トピックに大量のデータが含まれる場合、ダウンタイムが長くなる
この種のセットアップを本番環境で実行して戦闘テストした人はいますか？つまりディスクの破損に遭遇し、ブローカーはダウンしましたが、それでもデータを保持していますか？
kafkaはもともとRMDBSレベルの耐久性のために設計されていなかったので、これは悪い設定ですが、これが事実である具体的な理由を指摘することはできません。
いかなる状況でもデータを失うことは許されません
Kafka自体に別の欠陥がある可能性があります。つまり、まれな状況（潜在的な将来のバージョン）Kafkaが自身のデータを破壊する可能性があることを意味します。
それはPostgresに数回起こりました。マスターとレプリカのglibcバージョンが異なるとデータが破損する最近の問題を覚えています。また、Postgresがパニック（シャットダウン）を伴うfsync中にエラーの処理を開始するまで、データが破損する可能性もあります。これは、より多くの機能を備えているため、データの永続化に特化した製品であり、バグの表面が大きくなります。
私の意見では、レッスンは、データのアーカイブをより低温のストレージに個別に保存することです。この場合、いくつかのプロセスがデータを破壊する可能性は低くなります。また、2つのストレージシステムがあること。 g。 KafkaそしてS3は、それらの1つがデータを破壊した場合、他の1人が同時にそれを行う可能性が低いことを意味します。
それはすべて、あなたの状況の定義に依存すると思います。