ディレクトリ
1インタラクティブ、クライアントとサーバー側の
2、悪いパフォーマンスのネットワーク通信が頻繁にもたらしました
3、バッチメカニズム：パッケージ化バッチに複数のメッセージ
4、要求メカニズム：バッチリクエストに充填する複数の
「この記事では、我々は最高のパフォーマンスを確保するために、どのように通信ネットワーク設計のためのときに、このメカニズム、優れたメッセージングミドルウェアのために、メッセージ指向ミドルウェア技術関連のトピックに、クライアントとサーバーの通信を語りますでも良い設計により、10倍以上の性能向上ので？それを才能。
いくつかのネットワーク通信関連のメカニズムを設計するために、どのように最適化する方法を基礎となるときは、この論文では、クライアントとサーバーの通信に、あなたの分析を与える例として、カフカにカフカを持っています。
1インタラクティブ、クライアントとサーバー側の
私たちは、メッセージングミドルウェアとしてカフカを使用している場合はプロデューサーたちが理解することができるはず、彼にメッセージを送信するよう、クライアントにバインドされています。
カフカのために、それは彼自身のサポート分散メッセージストアで、そしてそれが何を意味するのでしょうか？
たとえば、今、あなたは「トピック」を持っている、「トピック」あなたはメッセージデータのセットのロジックを理解することができます。
たとえば、今、あなたはすべての注文を置くが行くように、「トピック」に送信され、その後、「トピック」の順番のデータを入れている、「OrderTopic」と呼ばれています。
そして、データの「トピック」量は大きな、大きな、右、マシン上に置くことができないことができますか？
そこで、我々はマシンデータは、それぞれの一部として保存することができ、複数のマシンに保存されたカフカを分散させることができます。
これは、各サーバはカフカブローカーと呼ばれ、メカニズムカフカ分散メッセージストアで1台のコンピュータ上のデータを管理する責任があります。
以下のチャートを見てみましょう：
「トピック」「パーティション」、データストアの各「パーティション」部分を複数に分割することができ、各パーティションは、このように複数のマシン上に記憶されたデータの分散を達成する、異なるマシンカフカブローカ上にあります効果。
次に、クライアントは、次の3つの「パーティション」が、つまり、カフカブローカーの上に置かれた、例えば、次の3つの「パーティション」に「OrderTopic」注文データ分割を定義し、カフカブローカーの時間にメッセージを送信しますすべて3桁カフカブローカーにデータを配布します。
この時点では、ブローカーは、負荷のバランスをとる戦略を起工3、例えば、一様に注文データに分散させたように、注文データ、30,000合計は、各パーティションに万件のオーダーメッセージを配布することを前提とデフォルト設定されますマシン上で。
全体のプロセスは、以下に示すとおり
2、悪いパフォーマンスのネットワーク通信が頻繁にもたらしました
まあ、今の質問は、クライアントがどのように彼が過去に送られたとき、たとえば、今、あなたは、カフカを行くために送りたい、カフカブローカーへのメッセージである送信しますか？
直接注文メッセージは、ブローカーにそれを送って、ネットワーク要求に対応していますか？
あなたがそうするならば、それは頻繁に通信ネットワーク、ブローカーと頻繁にネットワーク通信を引き起こすことがバインドされ、複雑なネットワーク接続、送信処理に関連し、それぞれが、その後、今度は貧弱なクライアントのパフォーマンスにつながります。
あなたの例を与える、あなたが通信ネットワークを介してブローカーに注文を送信するたびに、時間のかかる10msのを必要と言います。
注文がブローカーのネットワークトラフィックに送られるのであれば、それは100件のオーダーに2つ目を送信することで、私たちは考えて、真実ではないのですか？
あなたが送信する毎秒万件のオーダーがあると言う場合、それはあなたがあなたのパフォーマンスは、需要の遠く及ばなかった送信することはありますが、それは、パフォーマンスの低下である。しかし、それはカフカ速度に注文を送信するために、あなたのシステムを表示されます特にです遅いです。
3、バッチメカニズム：パッケージ化バッチに複数のメッセージ
すべてのアドレスこの問題のだから、最初、カフカは、最初の最適化は、バッチメカニズムを達成することであるでした。
これは彼が、メモリバッファに使用すると、メモリバッファに行くために、その後、メモリバッファに、バッチを荷造りするために複数の注文となります順序を書くたびにクライアントを置くことであることを意味します。
たとえば、デフォルトのカフカは、それはその後、彼はネットワーク通信を経由してブローカーに送信されたバッチをお付けいたします、バッチになります16キロバイトが、それはあなたのデフォルトが一緒に16キロバイトのフルサイズをこすりするために超えていることを意味するサイズのバッチを指定しました。
假如说一个batch发送到broker，同样也是耗费10ms而已，但是一个batch里可以放入100条订单，那么1秒是不是可以发送100个batch？
此时，1秒是不是就可以发送10000条订单出去了？
而且在打包消息形成batch的时候，是有讲究的，你必须是发送到同一个Topic的同一个Partition的消息，才会进入一个batch。
这个batch里就代表要发送到同一个Partition的多条消息，这样后续才能通过一个网络请求，就把这个batch发送到broker，对应写入一个Parititon中。
4、request机制：多个batch打包成一个request
事情到这里就结束了吗？还没有！
比如现在我们要是手头有两个Topic，每个Topic都有3个Partition，那么每个Broker是不是就会存放2个Partition？其中1个Partition是Topic01的，1个Partition是Topic02的。
现在假如说针对Topic01的Partition02形成了一个batch，针对Topic02的Partition02也形成了一个batch，但是这两个batch其实都是发往同一个Broker的，如上图的第二个Broker。
此时，还是一个网络请求发送一个batch过去吗？
其实就完全没必要了，完全此时可以把多个发往同一个Broker的batch打包成一个request，然后一个request通过一次网络通信发送到 那个Broker上去。
假设一次网络通信还是10ms，那么这一次网络通信就发送了2个batch过去。
通过这种多个batch打包成一个request一次性发往Broker的方式，又进一步提升了网络通信的效率和性能。
其实 batch机制 + request 机制，都是想办法把很多数据打包起来，然后一次网络通信尽量多发送一些数据出去，这样可以提升单位时间内发送数据的数量。
这个单位时间内发送数据的数量，也就是所谓的“吞吐量”，也就是单位时间内可以发送多少数据到broker上去。
例えば、毎秒はどのくらいのクライアントの「スループット」を表現するためにある過去、3万件のメッセージを送ることができます。
したがって、この原則を理解し、あなたは、このような非常に良いアイデアを設計することを学ぶことができます。あなたはカフカへのインタビュアーと話す場合にもインタビューの中でも、面接でカフカ底をregalingすることができ、それが効果的にネットワークの通信性能を改善する方法です。
最後に、絵再び、完全な要約として。