インタビューの質問の分散収集のためのJavaフレームワーク

インタビューの質問の分散収集のためのJavaフレームワーク

1. ZooKeeperのは何ですか?

A:ZooKeeperのは、オープンソース分散アプリケーションコーディネーションサービスは、典型的な分散型データ整合性溶液です。それらは、効率的で信頼性の高いシステムを形成するために一緒に複雑でエラーが発生しやすい分散一貫サービスパッケージに設計され、そしてユーザーが利用可能な原子の一連の動作を使用して容易です。

2.ZooKeeperは、どの機能を提供しますか?

A:ZooKeeperのは、以下の機能を提供します。

  • サービス登録およびサブスクリプションを分散:分散環境では、高可用性を確保するためには、通常、同一のアプリケーションやサービスプロバイダと他のサービスに到達するためのより多くを展開します。そして、消費者は、このようなダボとして、典型的な登録およびサブスクリプションサービスは、これらのピアサーバーを実行するために、関連するビジネス・ロジックを選択する必要があります。
  • Configuration Centerを分散:定義によって、いわゆる物流センターをモデルにパブリッシュおよびサブスクライブ出版社が集中管理と動的更新の構成情報、データを取得する加入者のためのZooKeeperノード上のデータを公開する予定です。
  • ネーミングサービスを:分散システムでは、サービスのクライアントアプリケーション、サービスプロバイダーのアドレスやその他の情報を命名することで指定した名前に基づいてリソースを得ることが可能です。
  • 分散ロック:私たちは、データの整合性を確保するためにこれは強いZooKeeperのが主な原因です。

いくつかの組み込み3.ZooKeeperモードがありますか?

A:ZooKeeperのは、通常のビルドに3つのモードがあります。

  • スタンドアローンモード:zoo.cfgのみの設定1 server.idがスタンドアローンモードで、このモードは、一般的に、現在のホストがダウンした場合、他のすべてのZooKeeperサービスサーバの現在の仕事に依存が正常に動作しないことができ、テスト環境で使用されています。
  • 疑似分散モード:zoo.cfgに配置された機械ZooKeeperの異なるポート、同じスタンドアローンモード開始、このモードは、一般にテスト環境で使用されています。
  • 分散モード:複数のマシンごとの構成zoo.cfgファイル、各サーバはこのクラスタの上に構築され、自分のリストに追加されますが、完全に分散されています。

4.ZooKeeperは何がありますか?

A:次のようにZooKeeperの特性は以下のとおりです。

  • シーケンシャル一貫性(シーケンシャル一貫性):同じクライアントからのトランザクションは、ZooKeeperのは厳密に提出、その順序に従って実装が続く、提出。
  • アトミック(原子性):のZooKeeperクラスタにトランザクションをコミットすると、トランザクションは「完了」されるか、「すべての未完成のは」存在しない「部分的に完了しました」。
  • 単一のシステム・イメージ(単一のシステム・イメージ):クライアントは、ビューが得られるクラスタZooKeeperの内の任意のノードに接続されているのと同じです。
  • 信頼性(信頼性):永久に他のトランザクションをカバーするまで保持される状態変化を発生させるトランザクションが完了します。
  • リアルタイム(適時性):トランザクションが完了すると、クライアントは、時間の限られた期間とする最新のデータを取得します。

5.以下は、ZooKeeperの上のエラーの説明ですか?

A:全てのノードは安定したメモリ容量Bを持っている:任意のノードのZooKeeper(メッセージ送信・受信)との間で通信を行うことが可能であるC:性能を向上させるために、一部のノードは、ノード故障の別の部分を書き込む、ZooKeeperの成功した書き込み、同じデータが許可されDは:Cタイトルの解析:クラスター中に生きているノードの半分以上のような、より限り、ZooKeeperのを実行している、ZooKeeperの通常のサービスには答えることができますZooKeeperのは、同じデータが成功した書き込みにノードのサブセットが存在することはできません、書き込みノードの別の部分は、それがZooKeeperの「一貫満たしていない失敗します原則」の。

どのように6.ZooKeeperは、分散ロックを達成しますか?

A:次のように分散ロック・ステップのZooKeeperの実装:

  • クライアント接続のZooKeeper、および/ロックの一時的かつ整然とした子ノードを作成し、順序に対応するクライアント/ロック/ロック百億一、第二は/ロック/ロック百億二の最初の子ノードへように。
  • クライアントは、下/ロック子ノードのリストを取得し、ロックを取得するために考えられている場合は、子供の現在のリストについては、作成することを子ノードかどうかを判断することは、最年少の子ノード番号をノード、あるいは単に自分の削除されたメッセージの一つ前の子ノードを監視しますロックが得られるまでサブノード変更通知を取得した後、この手順を繰り返します。
  • ビジネスコードの実行;
  • ビジネスプロセスの完了後、対応する子ノードのリリースにロックを削除します。

どのように7.ZooKeeper分散トランザクションを実装しますか?

A:ZooKeeperのは、以下の4つの段階に分け、合計で、2フェーズ・コミットと類似の分散トランザクションを実装します。

  • ZooKeeperのは、クライアント・ノードが書き込み要求を送信し与えます。
  • 書き込みリーダーノードに要求を転送しますZooKeeperのノードは、クラスタの確認を待って、投票にリーダー放送を必要とします。
  • リーダー承認統計を投票、受信され、半分以上の票トランザクションがコミットされます。
  • トランザクションが正常にコミットした後、ZooKeeperのノードは、クライアントに伝えます。

8.なぜ、クラスタ内のマスターノードべきでしょうか?

:分散環境では、いくつかのビジネス・ロジックは、実行のために、クラスタ内のマシンの一つが、他のマシンが大幅に、ダブルカウントを減らし、パフォーマンスを向上させることができ、結果を、共有することができます必要があり、これは、マスターノードの存在意義です。

何9.Dubboこと?

A:リモートメソッド呼び出し、インテリジェントフォールトトレランスおよびロードバランシング、および自動登録及びサービス発見のためのインターフェース:ダボは、3つのコア機能を提供する高性能、軽量オープンソースのJava RPCフレームワークです。

10.Dubboは何がありますか?

A:次のようにダボ特性は以下のとおりです。

  • 呼び出すための高性能RPCインターフェイスプロキシ:リモートコールエージェントの能力に基づいて、高いパフォーマンスを提供し、粒子サイズへのサービス・インターフェース、リモートコール遮蔽開発者の基本的な内容。
  • インテリジェントな負荷分散:内蔵のロードバランシング戦略の様々な、下流ノードのインテリセンスの健康、大幅にスループットシステムを改善し、コール待ち時間を減らします。
  • オートサービスの登録と発見:レジストリのさまざまなサービスをサポートし、リアルタイムの認知サービスインスタンスの組立ラインオフ。
  • 高度にスケーラブル:+設計原理は、プラグインは、このようなプロトコル、トランスポート、シリアル化などのすべての中核能力は、拡張ポイント、等しい治療として設計されたサードパーティの実装を実現するために構築されてフォローマイクロカーネル。
  • ランタイムトラフィックスケジューリング:内蔵の条件、スクリプト、およびその他のルーティングポリシーの異なるルーティングルールを設定することにより、簡単にエンジンルームや他の機能に優先して、灰色の公開。
  • サービス管理・運用・保守の可視化:豊かなサービス管理、運用、保守ツールを提供します:常にサービスのメタデータ、サービス、健康状態やコールの統計情報を確認し、リアルタイムのルーティングポリシーが発行され、設定パラメータを調整します。

コアコンポーネントは11.Dubbo何がありますか?

A:ダボコアコンポーネント以下の通り:

  • プロバイダ:サービスプロバイダ
  • 消費:消費者サービス
  • レジストリ:サービスの登録と発見レジストリ
  • モニター:通話と通話回数の主要統計サービス
  • コンテナ:コンテナサービスの実行

均衡戦略をロード12.Dubbo?

A:次のようにダボ戦略のバランスをとるための責任は次のとおりです。

  • ランダム化された負荷バランシング(ランダムロードバランス):プレス重み設定ランダム確率、衝突の断面において高い確率が、呼量の大きい分布をより均一、かつ確率重量使用も均一にした後、重量によって与えられる動的な調節を容易にします。
  • ポーリング・ロード・バランシング(ラウンドロビンロードバランス):リセットポーリングレート後の大会の権利によっては、そこのような遅い蓄積プロバイダーの要求の問題、次のとおりです。第二のマシンは非常に遅いですが、ハングアップしていない、2番目の要求に転送するときその中のカードの上に、時間をかけて、すべての要求は、第二段階でカードに転送されます。
  • 通話アクティブ負荷分散(ロードバランスLeastActive)の最小数:違いの前と後のアクティブコールの最小数、アクティブコールカウント手段の数を使用しました。
  • 負荷分散ハッシュ(ConsistentHash LOADBALANCE):前方ハッシュ値は、要求が常に同じプロバイダの同じパラメータに送信されます。

負荷分散の構成は次の通りです

サーバーのサービスレベル

\<dubbo:service interface="xxx" loadbalance="roundrobin" /\>

クライアントのサービスレベル

\<dubbo:reference interface="xxx" loadbalance="roundrobin" /\>

サーバー側のメソッドレベル

\<dubbo:service interface="xxx"\>
   \<dubbo:method name="xxx" loadbalance="roundrobin"/\>
\</dubbo:service\>

クライアントメソッドレベル

\<dubbo:reference interface="xxx"\>
   \<dubbo:method name="xxx" loadbalance="roundrobin"/\>
\</dubbo:reference\>

以下の13.Dubboどちらが契約をサポートしていませんか?

A:ダボ://
B:RMI://
C:Redisの://
D:安らか://

回答:D

トピック決意:安らかは、プログラミング標準ではなく、トランスポート・プロトコルであり、ダボをサポートしていません。

何14.Dubboのデフォルトのレジストリ、それを使用する他のオプションがあるのですか?

:ZooKeeperのはナコス、Redisの、簡単な登録センター(通常のダボサービス)だけでなく、登録センターとして推奨されます。

マルチレジストリが行う15.Dubboをサポートしていますか?

A:でも同時に異なるレジストリ内の同じ名前の登録サービスを引用し、ダボは、マルチレジストリをサポートするために、同じ時間に同じサービスを登録し、または別のサービスが異なるレジストリまでに登録されています。

マルチレジストリ登録:

\<?xml version="1.0" encoding="UTF-8"?\>
\<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://dubbo.apache.org/schema/dubbo" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd"\>
    \<dubbo:application name="world" /\>
    \<!-- 多注册中心配置 --\>
    \<dubbo:registry id="hangzhouRegistry" address="10.20.141.150:9090" /\>
    \<dubbo:registry id="qingdaoRegistry" address="10.20.141.151:9010" default="false" /\>
    \<!-- 向多个注册中心注册 --\>
    \<dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService" registry="hangzhouRegistry,qingdaoRegistry" /\>
\</beans\>

何の接続16.Dubboをサポートしていますか?

A:マルチキャスト、さらにはZooKeeperのレジストリまで:ダボがサポート主な接続があります。

①マルチキャストモードは、限り、ブロードキャストアドレスとして、あなたがお互いを見つけることができ、任意の中央ノードを起動する必要はありません。

  • プロバイダは、自身のアドレスをブロードキャストを開始するとき
  • 消費者は、サブスクリプション要求をブロードキャストを開始すると
  • プロバイダが加入者に自分のアドレスのユニキャストサブスクリプション要求を受信すると、あなたがユニキャスト= falseを設定した場合、その後、加入者に放送
  • 消費者は、プロバイダのアドレスを受信した、接続アドレスのRPCコール

小規模なアプリケーションや開発段階での使用にのみ適した構造的制約により、マルチキャストネットワーク、。マルチキャストアドレス:224.0.0.0〜239.255.255.255

コンフィギュレーション

\<dubbo:registry address="multicast://224.5.6.7:1234" /\>

若しくは

\<dubbo:registry protocol="multicast" address="224.5.6.7:1234" /\>

同時にマシンが複数の消費者のプロセスを起動した場合、消費者への配信プロバイダのアドレス情報、ユニキャストダボのデフォルトのブロードキャストの量を削減するために、消費者はそれ以外の場合は、消費者が受け取ることができる必要があります、=偽のユニキャスト宣言する必要がありますメッセージ、同じマシン上で実行されているサービスは、消費者はまた、ユニキャストを宣言する必要があり、消費者はそうでない場合、消費者がサービスの例外のために利用可能なプロバイダで、その結果、メッセージを受信できない、偽=:

\<dubbo:registry address="multicast://224.5.6.7:1234?unicast=false" /\>

若しくは

\<dubbo:registry protocol="multicast" address="224.5.6.7:1234"\>
    \<dubbo:parameter key="unicast" value="false" /\>
\</dubbo:registry\>

②直接接続は、レジストリ自体はあなたがコミュニケーションの全体的な一貫性を減らすために第三者に頼ることができ、一般的なダボサービスです。

\<dubbo:registry protocol="zookeeper" address="N/A" file="./.dubbo-platform"/\>

簡単な登録センターはダボサービスに公開されます。

\<?xml version="1.0" encoding="UTF-8"?\>
\<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://dubbo.apache.org/schema/dubbo" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd"\>
    \<!-- 当前应用信息配置 --\>
    \<dubbo:application name="simple-registry" /\>
    \<!-- 暴露服务协议配置 --\>
    \<dubbo:protocol port="9090" /\>
    \<!-- 暴露服务配置 --\>
    \<dubbo:service interface="org.apache.dubbo.registry.RegistryService" ref="registryService" registry="N/A" ondisconnect="disconnect" callbacks="1000"\>
        \<dubbo:method name="subscribe"\>\<dubbo:argument index="1" callback="true" /\>\</dubbo:method\>
        \<dubbo:method name="unsubscribe"\>\<dubbo:argument index="1" callback="false" /\>\</dubbo:method\>
    \</dubbo:service\>
    \<!-- 简单注册中心实现,可自行扩展实现集群和状态同步 --\>
    \<bean id="registryService" class="org.apache.dubbo.registry.simple.SimpleRegistryService" /\>
\</beans\>

シンプルなレジストリサービスを参照します。

\<dubbo:registry address="127.0.0.1:9090" /\>

または:

<dubbo:service interface="org.apache.dubbo.registry.RegistryService" group="simple" version="1.0.0" ... >

または:

<dubbo:registry address="127.0.0.1:9090" group="simple" version="1.0.0" />

適用性:このSimpleRegistryServiceは、単に、実現クラスタを参照カスタム・レジストリーとして使用することができますサポートしていませんが、本番環境のために直接適していません。

③ZooKeeperのレジストリは、飼育係はApacahe Hadoopのサブプロジェクトで、登録センター、工業用高強度としてダボサービスの変更のプッシュをサポートするためのディレクトリサービスのツリーは、本番環境で使用され、推奨することができます。

サービスプロバイダの起動:URLアドレス/dubbo/com.foo.BarService/providersの下で、独自のディレクトリを作成するために

  • 消費者がサービスを開始すると:/dubbo/com.foo.BarService/providers URLアドレスのサブスクリプションプロバイダーのディレクトリを、そして/dubbo/com.foo.BarService/consumersの下で、独自のURLアドレスのディレクトリを作成します
  • 起動時にモニタリングセンター:/dubbo/com.foo.BarServiceディレクトリのURLアドレスの下のすべてのプロバイダと消費者に加入

これは、次の機能をサポートします。

  • 停電やその他の異常シャットダウンのプロバイダは、レジストリが自動的に情報提供を削除することができた場合
  • 再起動するには、レジストリは、自動的に登録データだけでなく、サブスクリプション要求を復元することができた場合
  • セッションの有効期限が切れると、自動的に登録データだけでなく、サブスクリプション要求を復元することができます
  • 設定した場合<dubbo:registry check="false" />、記録は、登録およびサブスクリプション要求の再試行タイマーの背景に失敗します
  • よる<dubbo:registry username="admin" password="1234" />ログイン設定のZooKeeper
  • <dubbo:registry group="dubbo" />使用無根ツリーを設けていない飼育係ルートノードを設定します
  • サポート*ワイルドカード<dubbo:reference group="*" version="*" />すべてのパケットがサービスプロバイダーとすべてのバージョンを購読することができます

飼育係の使用

プロバイダを増やし、消費者の顧客は、ミッドジャーパッケージの依存関係を飼育係:

\<dependency\>
    \<groupId\>org.apache.zookeeper\</groupId\>
    \<artifactId\>zookeeper\</artifactId\>
    \<version\>3.3.3\</version\>
\</dependency\>

ダボサポートzkclientと学芸員2種類の飼育係のクライアントの実装:

注:zkclientあなたがzkclientクライアントを使用したい場合は、私たちが自分で拡張する必要があり、2.7.35のバージョンを達成するために削除されました。

zkclientクライアントを使用します

飼育係のクライアントの健康状態を向上させるために、認識し始めデフォルトzkclientによってバージョン2.2.0から。zkclientは、飼育係Datameerオープンソースのクライアントの実装です。

デフォルトの設定:

\<dubbo:registry ... client="zkclient" /\>

または:

dubbo.registry.client=zkclient

または:

zookeeper://10.20.153.10:2181?client=zkclient

または直接に頼る必要のダウンロード

\<dependency\>
    \<groupId\>com.github.sgroschupf\</groupId\>
    \<artifactId\>zkclient\</artifactId\>
    \<version\>0.1\</version\>
\</dependency\>

使用キュレータークライアント

バージョン2.3.0からは、オプションの学芸員が達成をサポートするために始めました。キュレーターオープンソースNetflixが飼育係クライアントの実装です。

あなたが実装キュレーターを変更する必要がある場合、configure:

\<dubbo:registry ... client="curator" /\>

または:

dubbo.registry.client=curator

または:

zookeeper://10.20.153.10:2181?client=curator

または直接ダウンロードに依存する必要があります。

\<dependency\>
    \<groupId\>com.netflix.curator\</groupId\>
    \<artifactId\>curator-framework\</artifactId\>
    \<version\>1.1.10\</version\>
\</dependency\>

飼育係のスタンドアロン構成:

\<dubbo:registry address="zookeeper://10.20.153.10:2181" /\>

または:

\<dubbo:registry protocol="zookeeper" address="10.20.153.10:2181" /\>

飼育係のクラスタ構成:

\<dubbo:registry address="zookeeper://10.20.153.10:2181?backup=10.20.153.11:2181,10.20.153.12:2181" /\>

または:

\<dubbo:registry protocol="zookeeper" address="10.20.153.10:2181,10.20.153.11:2181,10.20.153.12:2181" /\>

グループに分け、同じ飼育係は、レジストリ:

<dubbo:registry id="chinaRegistry" protocol="zookeeper" address="10.20.153.10:2181" group="china" />
<dubbo:registry id="intlRegistry" protocol="zookeeper" address="10.20.153.10:2181" group="intl" />

17.サービスのヒューズは何ですか?

:によりシステムの全体的な可用性を保護するために過剰な圧力及び訪問遅い応答または失敗、上流のサービスに依存するサービスは、一時的に下流のサービスへの呼び出しを遮断アプリケーションシステムでは、。全体的な措置を維持するために、ローカルの犠牲は、吹きと呼ばれています。

18.Dubboは結果をキャッシュすることができますか?サポートキャッシングの種類は何ですか?

A:はい、ダボは、ユーザーの負担を軽減するためにキャッシュを追加し、人気の高いデータアクセス速度を加速するために、宣言キャッシュを提供します。

ダボサポートキャッシュタイプは次のとおりです。

  • 以上の原理に基づいて、LRUは、最近最もホットなデータがキャッシュされている維持し、余分なキャッシュを削除するために使用しました。
  • そのようなページをレンダリングするようにThreadLocal現在のスレッドキャッシュ、各ポータルは、スレッドのキャッシュを介してユーザ情報を確認する必要があり、ポータルの多くを使用し、この不要なアクセスを減らすことができます。
  • JCacheの統合は、キャッシュ実装のすべての種類を埋めることができます。

以下のような構成は以下のとおりです。

\<dubbo:reference interface="com.foo.BarService" cache="lru" /\>

若しくは

\<dubbo:reference interface="com.foo.BarService"\>
    \<dubbo:method name="findBar" cache="lru" /\>
\</dubbo:reference\>

19.Dubboいくつかのフォールトトレラントクラスタモードがありますか?

:ダボクラスタフォールトトレラントモードは、次のように。

①フェールオーバークラスタ

障害発生時の自動切り替えの失敗は、他のサーバーを再試行してください。通常の読み取り操作のために使用されるが、再試行がより長い遅延をもたらすでしょう。あなたは、することができますretries="2"(最初は除く)の再試行回数を設定します。

再配置され、以下のように番号を再度:

\<dubbo:service retries="2" /\>

若しくは

\<dubbo:reference retries="2" /\>

若しくは

\<dubbo:reference\>
    \<dubbo:method name="findFoo" retries="2" /\>
\</dubbo:reference\>
②フェイルファーストクラスタ

のみ通話を開始するためのクイック失敗は、すぐにエラーが失敗しました。書き込み操作は、一般に、新しいレコードとして、非冪等の自然の中で使用されます。

③フェイルセーフクラスタ

セキュリティ障害、異常、直接無視。監査ログを書き込むことが一般的に動作可能。

④フェイルバッククラスタ

自動回復は、背景レコード失敗した要求、再送タイマを失敗しました。典型的には、メッセージ通知動作。

⑤フォーククラスタ

長い成功の復帰などとしてあること、並行して複数のサーバを呼び出します。通常、読み出し動作の高いリアルタイム要件のために使用されるが、より多くのサービスは、リソースを無駄にする必要があります。=「2」フォークを介して並列の最大数を設定することができます。

⑥放送クラスタ

すべてのブロードキャスト・プロバイダー、1つのコールずつ呼び出し、Renyiyitaiエラーはエラーです。典型的には、このようなキャッシュなど、すべてのプロバイダに通知したり、ローカルリソース情報をアップデートログインするために使用します。


私は公共の数の関心を歓迎し、「返信キーワードのJavaを両手贈り物があるだろう、」!私はあなたに成功したインタビューをしたいです

%97%E5%8F%B7 %E4%BA%8C%E7%BB%B4%E7%A0%81.png)

おすすめ

転載: www.cnblogs.com/dailyprogrammer/p/12272760.html