カフカsession.timeout.ms heartbeat.interval.msパラメータなどのデータ記憶装置上のいくつかの考えの違い
多くの場合、我々は、コンピュータの世界でデータを扱う必要があり、これは我々がCURDエンジニアの冗談を言った理由の一つです。2年間のコードを記述し、ストレージシステムの多くとの接触は、Redisのは、MySQLは、カフカ、Elasticsearchは...あなたには、いくつかは、これらのシステムの背後に隠さ見つけることができます、ゆっくりといつもおなじみの背後にあるいくつかの一般的な設計思想を見つけ、その後、下に行きます数学的理論。
生活の中で発生した大量のデータは、さまざまな治療法の適用に基づいて2つのカテゴリーに分け、コンピュータ処理、OLTPとOLAPに引き渡さする必要があります。そのようなメッセージングミドルウェア（カフカ）を収集するためにダウン投げのログインフロー、システムログ情報、安定した流れ、などのいくつかのデータを、いくつかのデータは、そのようなユーザ特性を記録する記述としては、インデックスを構築する日付で、MySQLを保存するのに適しています。言い換えれば、大量のデータの顔、データのみの小さな一歩を格納している、どのようにこれらのデータを一緒に重要であるストレージシステムを反映するために、次のとおりです。便利あり、クエリ簡単かつ迅速に見つけることができるようにするためのインタフェースは、我々はデータが欲しいです。データはカフカの上に置かれ、そしてそれがどのような調査に任されている場合は？MySQLでデータ場合、理想的には、TF-IDFによれば、ES、このデータ構造に基づいて逆索引上に配置され、高基数カラムB +ツリーインデックス照会構築、およびテキスト・データ・タイプのために適した、BM25等迅速に所望のデータを取得する文書類似性アルゴリズムの尺度。
このことから、あなたはその背後にある「クエリ」のストレージの原則（使用されるデータ構造）を満たすために、異なるストレージシステムを見ることができます異なっています。高い信頼性と高可用性：そして、これらのストレージ・システムのための2つの問題に直面しています。信頼性は、私の意見では、信頼性の高いデータを確保する方法を議論するために、ストレージシステム自体、通常、単一のインスタンス上に立っています。たとえば、MySQLインスタンスは、耐久性を確保するために、REDOログ・ファイルを使用して、チェックポイントのメカニズムを合わせて実行し、二重書き込みバッファに加えて、データ・ページは、信頼性の確保するために書かれています。同様に、データの信頼性を確保するために使用Elasticsearchトランスログ機構もあります。だから、私は彼らの間で様々なチェックポイントのメカニズムを比較したい場合があり、より多くのストレージシステムを学びたいと思っています。
なぜ信頼性データは、それを必要としていますか？根本原因メモリは揮発性メモリである、ノイマン型の緊急性に応じて、プログラムが操作を行うためにCPUにメモリからデータをフェッチします。データがない場合には、そのデータが失われることはありません場合は、ディスク、システムのダウンタイムにはfsync？
可用性のために、クライアントの観点から。私はあなたがRedisののRedisのインスタンスまたはクラスタの背後にいる気にしないことを、あなたは通常、ちょうど私だけで結構良いリーダーサービスを提供します。ここではSPOFを避けるために、分散クラスタが便利になる、マシンは、上に別のマシンを切りました。分散システムでは、各ストレージ・インスタンスを管理する必要性、文字が我々は、コールマスターノード、コントローラノードなどのノードを分割する必要があります。結局のところ、経営者がよくレベルを持つことで、私たちの役割は、それをどのように管理するかを、同じですか？メインElasticsearchとカフカは、モデルから採用しながら、この時点では、Redisのクラスタで具体RedisのクラスタまたはクラスタとカフカElasticsearchクラスタが非常に異なっているが、基本的にP2P構造で、なぜあなたは言うのですか？そこRedisのノード点マスターとスレーブノードを、そのそれぞれのマスタノードとの間の等価性が、データは各マスターノードに方法のRedisのhash16384スロットに分配され、各マスタノードは、タンクの転倒を処理する責任を負いますなるデータ、分散データマスターノード角度が定義され、カフカのコントローラ・ノードは、マスタノードがデータの分布の観点で定義されていないelasticsearchが、クラスタ管理の定義の観点からクラスタのメタ情報を保存します。そして、私の中にそれらの間の特定の違いについての記事もいくつかの説明がありました。また、MySQLのリレーショナルデータベースとして、対象の分散クラスタ弱いの能力上のデータの整合性制約、トランザクションサポートの制限に。
最近、私はカフカのトピック、一部の大企業、中小企業のニュースいくつかの量の消費にメッセージを送信する問題、より多くのサービスに出くわしました。ニュースカフカはよくいくつかのビジネスの支出問題の遅れが生じ、消費者に優先メッセージでサポートされていないため。簡単な解決策は、レガシーシステムがもたらしたトピックの消費者と処理ロジックの複雑さの生産を増加させ、いくつかの問題に直面しているいくつかのトピックを追加することです。一つの方法は、使用するために、カフカスタンドアロンの消費者を使用することでconsumer.partitionFor("TOPIC_NAME")、次に使用し、トピックの下にあるすべてのパーティション情報を取得するconsumer.assign(partitions)明示的に指定された消費パーティションコンシューマを。もう一つの方法は、パーティションアロケーション戦略コンシューマ・グループのカスタムカフカの消費者に基づいて、この時間はあなたがカフカ既存のパーティションの割り当て方法を理解している、と時間をリバランストリガーを理解、どのようなシーンということですか？
カフカの消費者は、消費者のニュース消費者パーティションを行うためのメッセージを消費するには？範囲、ラウンドロビン、粘着性：これは、デフォルトで3があり、消費者のパーティションの割り当てポリシーです。本当にどこにでも、ラウンドロビンアルゴリズムといえば、それは多くの場合、いくつかのシーンで使用されている負荷分散が必要です。各ノードがESのコーディネータノードとして使用することができますので、このようなElasticsearchクライアントは、ESサーバーへの検索要求を送信すると、デフォルトでは、ユーザーのクエリ要求を受信し、コーディネータノードにクエリ結果に大量に消費全てのフラグメントを、まとめる必要がありますメモリやCPU、ES ClientはES上のノードにクエリを送信し、ラウンドロビン選択アルゴリズムです。あなたは慎重に見ている場合は、内部のRedisにおけるアルゴリズムの影が存在しますでしょう。別の例：アクセスパターンにRedisのLRUキャッシュキーは、一般的に電力分配手段（べき乗則分布）次の特徴の小さい部分とキーのアクセス頻度は、アクセス特性として、他のキーよりはるかに大きいです、良い結果を達成するためにLRUキャッシュ。また、Redisのは、タイプが新しいskipNodeノードに基づいてskiplistでソートセットにどの層に属していますか？また、これはべき乗則の分布の問題、そのソースコード注釈です：
私たちが作成しようとしている新しいskiplistノードのランダムなレベルを返します。この関数の戻り値は、より高いレベルが返される可能性が低いpowerlaw-同様分布で、1及びZSKIPLIST_MAXLEVEL（両方を含む）の間です。
実際に、私はいくつかのアイデアを表現したいか、それが解決され、それは汎用性があり、様々な異なるストレージシステムで使用される、より良いシステムの背後にある原理を理解するために、一緒にそれらを比較します。
最近、いくつかのメモを書くたびに、私の心の中の思考の他の種類のいくつかは、常に存在しています。これは主に、これらの2つの設定パラメータを書きカフカたかったであろう：最初のsession.timeout.msと結果のheartbeat.interval.msとの違いは、データストレージに関連したパスに何かを引き出します。
続けていきましょう：
個人消費、それにメッセージを仕切る：質問があります：トピックは、多くの場合、複数のパーティションを持っている、と我々はそれゆえ、コンシューマ・グループにより個人消費にこのトピックを作成しますので、？コンシューマ・グループ、消費者、消費者グループ内のコンシューマ・グループ、および各グループコーディネーター：これは、3つの概念を含みます。グループ管理プロトコルによって割り当てられるconusmerパーティションが実装されている以下の通り：
グループコーディネーターJoinGroup要求に送信され、各消費者の消費者グループは、すべての消費者情報のこのグループコーディネーターのメンバーが存在しますので、それは消費者としてリーダーの消費者を選択することで、リーダーの消費者が言っ語った：あなたは情報やメンバーを取ります私はあなたにそれを分割し、消費者の消費のために責任があるパーティション情報を配置するトピックをあげます
私達の構成によれば次に、リーダー消費者割り当て方式（パラメータpartition.assignment.strategyで指定された）各消費者のために消費される各パーティションを計算します。したがって、各コンシューマ・グループ・コーディネータSyncGroupは、要求を送信するが、唯一の消費者は、パーティショングループコーディネータリーダー消費者の受信後、リーダーパーティション割り当てポリシーを要求し、この方式では消費者に配布しました。マップを描き、これは次のとおりです。
通常の状況では、コンシューマ・グループのうち、消費者がリバランスをトリガするとき、パーティションの考えを再定式化するために呼ばれるリバランス。そして、パーティションの良いアイデアを開発し、あなたがしなければならない迅速なパラメータとheartbeat.interval.msに関連する各消費者を、知らせます。具体的には、それは：各消費者は、定期的に時間パラメータに従って送信されますheartbeat.interval.msがリバランスが発生した場合、グループコーディネータhearbeat、グループコーディネータは、各消費者の応答は、各消費者の応答を受信したであろう含有指定しますREBALANCE_IN_PROGRESSアイデンティティ、各消費者はすでにグループのコーディネーターは、各消費者の知っている間、リバランス起こっ認識できるように生存を。
なぜheartbeat.interval.msとsession.timeout.msはそれを比較する必要がありますか？session.timeout.msは意味：消費者のクラッシュのために必要なグループコーディネーターの検出時間が発生します。コンシューマ・グループは、第二、消費者の内側にハングアップ検出session.timeout.msを取ります。例えば= 10、heartbeat.interval.ms = 3 session.timeout.ms
session.timeout.ms任意のメッセージは、消費者が受信されない場合は、このしきい値コーディネーター内のしきい値を指定し、「論理的」インデックス、--- 10秒であり、それが消費者のコーディネーターがハングアップと考えられています。heartbeat.interval.msは、消費者にコーディネータにハートビートパケットを送信するために3秒ごとに、小さいheartbeat.interval.ms、やすいハートビートパケットを伝える「物理」の指標であり、それが送られたTCPパケットの数に影響しますそしてそれが持っていた実質的な影響を、私はそれを呼ばれる理由である、「物理的」な指標の理由。
期間heartbeat.interval.ms消費者内のグループコーディネーターがハートビートを受信しない場合、グループは正当化、消費者の外にそれを置きます。消費者は、スティック上の小さなミスを犯したかのようにそれを殺しました。実際には、それは遅延をネットワーク化することが可能であり、それはハートビートパケットが通常に、多分次のハートビートに到着影響し、長い時間の消費者のGCが発生する可能性があります。
heartbeat.interval.msは確かに消費者のグループがリバランスが発生した場合、REBALANCE_IN_PROGRESS内部のハートビートパケットによって、消費者のことができるようになりますsession.timeout.ms未満で時宜を得たノウハウ、それによって消費者の消耗品のパーティションを更新し、リバランス起こりました。以上session.timeout.ms、グループコーディネータは、消費者がハングアップしたと思われる場合は、それは確かにリバランスではありません消費者に情報を伝えます。
オリジナル：https://www.cnblogs.com/hapjin/p/10926882.html
最近、特定のESアナライザはプラグインのシンボル検索に合わせてカスタマイズいくつかの正規化、中国語の単語（カスタム単語を生成するための単語）の結果の単語正解精度、と会った、中国の産業の検索語の問題は、書く時間を必要とします... 。