高可用性のメッセージキューを確保するために[ターン]

オリジナルhttp://prchen.com/2019/06/23/%E4%BF%9D%E8%AF%81%E6%B6%88%E6%81%AF%E9%98%9F%E5%88% 97％E7％以下の9％84％E9％のABの％98％E5％8F％AF％E7の％94％A8％のE6の％80％A7 /

実際の生産では、メッセージキューの芸術の導入は、確かにこのようなカップリングシステム、非同期応答速度、平坦化のピーク圧力を低下させるなどの利点を、もたらすでしょう。しかし、いずれの技術は両刃の剣であり、同時にメッセージキューは、いくつかのリスクを取る必要があります紹介：外部システムへの依存度が導入された、より多くのエラーが発生しやすいです。メッセージミドルウェアがダウンしていると、それはシステム全体が使用不能に原因となります。そのため、メッセージキューの高可用性を確保することは非常に重要です。

MQは、どのように高可用性を確保するには？

RabbitMQの高可用性モード

高可用性を確保することはRabbitMQの3つのモードがあります：スタンドアローンモード、ノーマルモードのクラスタ、クラスタミラーリングモード

スタンドアローンモード

開発者は、テスト環境を使用するために、NAの生産環境
通常のクラスタモデル

クラスタ環境にデプロイMQの複数のメッセージキュー（待ち行列）を作成し、濃縮MQ例中に配置される、同期メタデータ（プロファイルはメッセージ自体としてではなく、理解することができる）のメッセージキューの他のすべてのインスタンス。消費者は、メッセージをプルする必要がある場合、メッセージキューは、ホストインスタンスに接続されていない場合、インスタンスは、メッセージキュープルメッセージ・インスタンス上にあります。

欠点の通常のクラスタモデル：
1. MQクラスタ内で発生する可能性があり、大規模なデータ転送を、より大きなオーバーヘッド
2. 可用性が低いです。ハングアップキューインスタンスたら、メッセージが失われ、消費者は通常、消費することはできません
ミラーリングクラスタモデル

このモードでは、メッセージキューが作成されたメッセージキュー内のメタデータのメッセージが複数のインスタンスに存在するかどうか、は、各時間はプロデューサーがMQインスタンスにメッセージを送信し、自動的に複数のインスタンスにメッセージを送信しますメッセージキューの同期メッセージ。

どのように私は、ミラークラスタモデルを回すのですか？

在上一篇文章中提到，RabbitMQ有很好的管理控制台，只需要在后台新增一个镜像集群模式的策略，命令数据同步到所有或指定数量的MQ实例中，当生产者再次创建消息队列时应用这个策略，即可自动同步数据到其他实例中。

镜像集群模式的优势：

高可用。MQ集群中任何一台机器挂了都没事，有备用机器。

镜像集群模式的弊端：
1. 由于RabbitMQ不支持分布式集群，消息队列同步到所有MQ实例会增大网络带宽压力，系统性能开销也相应提高
2. 扩展性不好。无法线性扩展消息队列，一旦在集群中增加机器，就要同步所有消息队列中的数据。

Kafka的高可用模式

Kafka集群由多个Kafka实例构成，每个实例被称为broker，每个broker是一个节点；当生产者创建一个topic时，这个topic可以划分为多个partition（区），每个partition可以存在于不同的broker上，每个partition就放一部分数据。

上述模式是天然的分布式消息队列，即一个 topic 的数据，分布在不同的MQ上，每台MQ只放一部分数据。

实际上 RabbmitMQ 不是分布式消息队列，它只是提供了一些集群、HA(High Availability, 高可用性) 机制的传统消息队列。

Kafka 0.8 以前，是没有 HA 机制的，任何一个 broker 宕机了会导致 broker 上的 partition 就挂掉，无法读写，没有什么高可用性可言。

Kafka 0.8 以后，提供了 HA 机制，即 replica（复制品）副本机制。每个 partition 的数据都会同步到其它机器上，形成自己的多个 replica 副本。所有 replica 会选举一个 leader 出来，那么生产和消费都跟这个 leader 打交道，然后其他 replica 被称为 follower。写的时候，leader 会负责把数据同步到所有 follower 上去，读的时候就直接读 leader 上的数据即可。只能读写 leader？很简单，要是你可以随意读写每个 follower，那么就要解决数据一致性的问题，系统复杂度太高，很容易出问题。Kafka 会均匀地将一个 partition 的所有 replica 分布在不同的机器上，保证了高可用。

如此一来，就保证了消息队列的高可用。每个 broker 中的 partition 在其他机器上都有副本，因此不用担心某个 broker 宕机。如果宕机的 broker 中有某个 partition 的 leader，那么此时会从 follower 中重新选举一个新的 leader 出来，大家继续读写新的 leader 即可。这就是Kafka实现高可用的模式。

メッセージプロデューサを書くときに、プロデューサーが指導を書いた後、リーダーはリーダーからデータを取得するための独自の取り組みで、他のフォロワー、その後、ローカルディスクにデータを書き込みます。すべてのデータが良いフォロワー同期したら、それはリーダーのACKに送信され、ACKリーダーのすべてのフォロワーの受領後、成功したプロデューサーにメッセージを書き込むために戻ります。（もちろん、これは唯一のモードであり、この動作は適切に調整されてもよいです）

個人消費のニュースをすると、リーダーから読み取り専用が、メッセージが正常に同期された場合にのみ、ニュースは消費者によって読まれるときに、すべてのフォロワーは、ACKを返しました。

概要

本論文では、RabbitMQのとカフカは、高可用性モードを確実に説明しています。

ノーマルモード、ノーマルモードとミラークラスタクラスタモード：高可用性を確保RabbitMQの3つのモードがあります。

前記メッセージが、データ伝送の大量、大きなオーバーヘッドをプルする際に必要となるよう、共通のクラスタメッセージキューは、単一のマシン上に存在します。

通常のクラスタモデルと比較すると、システムのオーバーヘッド、および貧しいスケーラビリティを高め、高可用性クラスタを確保しながら、クラスターモデルをミラーリングすることは、複数のサーバに保存されているメッセージキューを置くが、理由は単純ではなく、分散システム。

カフカのサポートは、分散型の高可用性は、0.8の前に何のメカニズムではありません0.8後に提供し、レプリカ・コピーのメッセージキューの高可用性を確保するための良い方法。各マシン上のパーティションは、他のマシンへのコピーを持っており、各パーティションがリーダーを持って、フォロワー、生産者と消費者のための他のマシンにのみリーダーで読み取り操作と書き込みます、リーダーがハングアップしたときに、なります再選挙新しいリーダーでフォロワーから、それは読み取りと書き込みには影響しません。