IBM MQ対Apache Kafka
私のクライアントがIBM MQブローカーとして持っている新しいアーキテクチャーのビッグデータを設計しています。ビッグデータアーキテクチャではKafkaを使用して作業しています。これは、他の方法よりも高速で信頼性が高く、強力だと思うためです。また、ストームとsparkストリーミング作業のためです。 Kafkaの方が簡単です。
私の質問は簡単です、それは本当ですか？あるいは、IBM MQをブローカーとしてアーキテクチャーのIBM MQを使用して信頼できるソリューションを開発し、Kafkaと同じ結果を得ることができますか？.
IBM MQの代わりにKafkaを使用する本当の理由はありますか？
すべてに依存すると思います。 Apache KafkaとIBM MQはどちらもメッセージングシステムですが、アプローチはまったく異なります。
単にストームと統合するメッセージングシステムを選択するだけの問題である場合、またはSparkストリーミングでメッセージのストリームを処理する場合、Kafkaの方が簡単です。ただしKafkaではなくIBM MQをすでに使用しているクライアントの場合、答えは同じではない可能性があります。
StormがMQと統合するためのスパウトを簡単に作成できると思いますが、オープンソースのJMSスパウトは、メッセージの確認方法の詳細のため、MQでは機能しません。 StormのMQスパウトのパフォーマンス特性が十分であれば、シナリオにMQを使用することは完全に可能です。
Kafkaの他の従来のメッセージングシステムと比較した場合の利点：
- Kafkaにキューの概念がない、つまりP2Pモデルがない
- メッセージの永続性
- トピック分割
- メッセージの順序付け
- メッセージの読み取り
- 負荷分散
- 自動フェイルオーバーと高可用性
詳細：
私は毎週この質問を聞いています...一般的にIBM MQまたはJMSは従来のメッセージングに使用されていますが、Apache Kafkaはストリーミングプラットフォームとして使用されています（メッセージング+分散ストレージ+データの処理）。さまざまなユースケース用に構築されています。
「従来のメッセージング」にはKafkaを使用できますが、Kafka固有のシナリオにはMQを使用できません。
記事 Apache Kafka vs. Enterprise Service Bus（ESB）—Friends、Enemies、or Frenemies は、なぜKafkaが競争力がないのかについて議論しています）ただし、統合およびメッセージングソリューション（IBM MQを含む）とそれらを統合する方法を補完します。
目的地が決まっている状況に陥ったとのことですが、.
IBM MQは、強力で信頼性が高く、堅牢なソリューションを提供できます。内部負荷分散ソリューション（cluster）を取得して、データの負荷を処理できるアーキテクチャを作成できるようにしました。 MQで10年間使用することを検討します。