Java バックエンドの社内面接での質問

21.インデックスを使用すべきでないのはどのような場合ですか?

1. 頻繁に追加、削除、または変更される列にはインデックスを作成しないでください。

2. インデックスが作成されていない繰り返し列が多数あります。

3. テーブルのレコードが少なすぎる場合は、インデックスを作成しないでください。

22. MVCCとは何ですか?

マルチバージョン同時実行制御 (MVCC=Multi-Version Concurrency Control) は、読み取り/書き込み競合を解決するために使用される不揮発性の方法です。

同時実行制御をロックします。つまり、トランザクションには一方向に増加するタイムスタンプが割り当てられ、変更ごとにバージョンが保存されます。バージョンとトランザクションのタイムスタンプ

アソシエーションでは、読み取り操作はトランザクションの開始前にデータベースのスナップショットのみを読み取ります (データのコピーがコピーされます)。このようにして、読み取り操作が書き込み操作をブロックする必要がなくなります。

操作、書き込み操作では読み取り操作をブロックする必要がなく、ダーティ読み取りや反復不可能な読み取りが回避されます。

23. MVCC はデータベースのどのような問題を解決できますか?

データベースの読み取りと書き込みを同時に行う場合、読み取り操作が書き込み操作をブロックする必要がなく、書き込み操作が読み取り操作をブロックする必要がないため、データのパフォーマンスが向上します。

データベースの同時読み取りおよび同時書き込みのパフォーマンス。同時に、ダーティ読み取り、ファントム読み取り、非反復読み取りなどのトランザクション分離の問題も解決できますが、更新の問題は解決できません。

失われた問題。

24. MVCCの実現原理について語る

MVCC の目的はマルチバージョン同時実行制御であり、データベースへの実装は読み取り/書き込み競合を解決することです。その実現原理は主に次のとおりです。

これは、レコード、アンドゥ ログ、および読み取りビューの 3 つの暗黙的なフィールドに依存することによって実現されます。

25. MySQLトランザクション分離レベル?

READ UNCOMMITTED (コミットされていない読み取り): トランザクション内の変更は、コミットされていない場合でも、他のトランザクションに表示されます。

の。ダーティリードが発生します。

READ COMMITTED (コミット読み取り): トランザクションの開始からコミットされるまで、他のトランザクションに加えられた変更はすべて無効になります。

見えない。反復不可能な読み取りが行われます。この分離レベルは、「非反復読み取り」とも呼ばれます。

REPEATABLE READ（可重复读）：一个事务按相同的查询条件读取以前检索过的数据，其他事

务插入了满足其查询条件的新数据。产生幻行，会导致幻读。（MySQL 默认隔离级别）

SERIALIZABLE（可串行化）：强制事务串行执行。

阿里内部资料26、 请说说 MySQL 数据库的锁？

关于 MySQL 的锁机制，可能会问很多问题，不过这也得看面试官在这方面的知识储备。

MySQL 中有共享锁和排它锁，也就是读锁和写锁。

1. 共享锁：不堵塞，多个用户可以同一时刻读取同一个资源，相互之间没有影响。

2. 排它锁：一个写操作阻塞其他的读锁和写锁，这样可以只允许一个用户进行写入，防止其他用

户读取正在写入的资源。

3. 表锁：系统开销最小，会锁定整张表，MyISAM 使用表锁。

4. 行锁：容易出现死锁，发生冲突概率低，并发高，InnoDB 支持行锁（必须有索引才能实现，

否则会自动锁全表，那么就不是行锁了）。

27、说说什么是锁升级？

MySQL 行锁只能加在索引上，如果操作不走索引，就会升级为表锁。因为 InnoDB 的行锁是加

在索引上的，如果不走索引，自然就没法使用行锁了，原因是 InnoDB 是将 primary key index

和相关的行数据共同放在 B+ 树的叶节点。InnoDB 一定会有一个 primary key，secondary

index 查找的时候，也是通过找到对应的 primary，再找对应的数据行。

当非唯一索引上记录数超过一定数量时，行锁也会升级为表锁。测试发现当非唯一索引相同的

内容不少于整个表记录的二分之一时会升级为表锁。因为当非唯一索引相同的内容达到整个记

录的二分之一时，索引需要的性能比全文检索还要大，查询语句优化时会选择不走索引，造成

索引失效，行锁自然就会升级为表锁。

28.悲観的ロックと楽観的ロックについて話す

悲観的なロック

データベースは外部から改変されることによって保守的に保たれている（このシステム内の他の現在のものや外部システムからのトランザクション処理も含む）と言われています。

データ変更プロセス全体の間、データはロック状態になります。悲観的な実装は、多くの場合、データベースによって提供されるロック マシンに依存します。

データ アクセスの排他性を真に保証できるのは、データベース レベルで提供されるロック メカニズムだけです。そうでない場合は、システムが実際のデータを要約したとしても、

ロック メカニズムでは、システムがデータを変更しないことを保証する方法はありません。

悲観的ロックの場合、トランザクションの分離を確保するために、読み取りには一貫したロックが必要です。データ読み取り時やその他のトランザクション時にロックする

これらのデータは変更できません。データを変更および削除する場合はロックも必要となり、他のトランザクションはこれらのデータを読み取ることができません。

楽観的なロック

楽観的ロック機構は、悲観的ロックと比較して、より緩やかなロック機構を採用しています。悲観的ロックはほとんどの場合データベース ロックに依存します。

操作の最大限の排他性を確保するために実装を制御します。ただし、特に長時間のイベントの場合、データベースのパフォーマンスに多くのオーバーヘッドが発生します。

ビジネスの観点からは、そのような費用は支払えないことがよくあります。

Ali の内部データによると、オプティミスティック ロック メカニズムにより、この問題はある程度解決されます。オプティミスティック ロックは、主にデータ バージョン (Version) 記録メカニズムに基づいて実装されます。

今。データバージョンとは何ですか? これは、データにバージョン識別子を追加することです。データベース テーブルに基づくバージョン ソリューションでは、通常、

実現するには、データベース テーブルに「バージョン」フィールドを追加します。データを読み出す際にはこのバージョン番号も一緒に読み出し、後から更新する際には、

このバージョン番号は 1 ずつ増加します。この時点で、送信されたデータのバージョン データと、データベース テーブル内の対応するレコードの現在のバージョン情報を比較します。

送信されたデータのバージョン番号がデータベース テーブルの現在のバージョン番号より大きい場合は更新され、それ以外の場合は期限切れデータとみなされます。

29.デッドロックをできるだけ回避するにはどうすればよいですか?

1. 少なくとも最悪の場合でもプログラムを終了でき、待機によるデッドロックが発生しないように、ロックを取得するためのタイムアウト時間を設定します。

2. シリアル実行と同様に、アクセス リソースを同じ順序で設定します。

3. トランザクションにおけるユーザーの交差を回避します。

4. トランザクションは短く、1 つのバッチにまとめてください。

5. 低い分離レベルを使用します。

6. バインディング リンクを使用します。

30. MySQLインデックスを使用する際の注意点は何ですか?

31、CHAR 和 VARCHAR 的区别？

CHAR 和VARCHAR 类型在存储和检索方面有所不同

CHAR 列长度固定为创建表时声明的长度，长度值范围是1 到255当 CHAR 值被存储时，它们

被用空格填充到特定长度，检索CHAR 值时需删除尾随空格。

阿里内部资料32、主键和候选键有什么区别？

表格的每一行都由主键唯一标识,一个表只有一个主键。主键也是候选键。按照惯例，候选键可以被

指定为主键，并且可以用于任何外 键引用。

33、主键与索引有什么区别？

主键一定会创建一个唯一索引，但是有唯一索引的列不一定是主键；

主键不允许为空值，唯一索引列允许空值；

一个表只能有一个主键，但是可以有多个唯一索引；

主键可以被其他表引用为外键，唯一索引列不可以；

主键是一种约束，而唯一索引是一种索引，是表的冗余数据结构，两者有本

34、 MySQL 如何做到高可用方案？

MySQL 高可用，意味着不能一台 MySQL 出了问题，就不能访问了。

1. MySQL 高可用：分库分表，通过 MyCat 连接多个 MySQL

2. MyCat 也得高可用：Haproxy，连接多个 MyCat

3. Haproxy 也得高可用：通过 keepalived 辅助 Haproxy

SpringCloud篇

1、什么是SpringCloud

Spring cloud 流应用程序启动器是基于 Spring Boot 的 Spring 集成应用程序，提供与外部系统的集

成。Spring cloud Task，一个生命周期短暂的微服务框架，用于快速构建执行有限数据处理的应用

程序。

2、什么是微服务

微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分为一组小的服务，

每个服务运行在其独立的自己的进程中，服务之间相互协调、互相配合，为用户提供最终价值。服

务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）

,每个服务都围绕着具体

的业务进行构建，并且能够被独立的构建在生产环境、类生产环境等。另外，应避免统一的、集中

阿里内部资料式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行

构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也

可以使用不同的数据存储。

3、SpringCloud有什么优势

使用 Spring Boot 开发分布式微服务时，我们面临以下问题

（1）与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题。

（2）服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目

录，在该目录中注册服务，然后能够查找并连接到该目录中的服务。

（3）冗余-分布式系统中的冗余问题。

（4）负载平衡 --负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路，

中央处理单元，或磁盘驱动器的分布。

（5）性能-问题 由于各种运营开销导致的性能问题。

（6）部署复杂性-Devops 技能的要求。

4、 什么是服务熔断？什么是服务降级？

熔断机制是应对雪崩效应的一种微服务链路保护机制。当某个微服务不可用或者响应时间太长时，

サービスはダウングレードされ、ノードのマイクロサービス呼び出しが融合され、「エラー」応答情報がすぐに返されます。ノードマイクロが検出された場合

サービスコールが正常に応答した後、コールリンクを再開します。SpringCloud フレームワークでは、ヒューズ メカニズムは Hystrix によって実装され、Hystrix が監視します。

マイクロサービス間の呼び出しのステータスを制御します。失敗した呼び出しが特定のしきい値に達すると、デフォルトでは 5 秒以内に 20 件の呼び出しが行われます。失敗した場合は、呼び出しが開始されます。

ヒューズ機構。

サービスの低下は通常、全体の負荷から考慮されます。つまり、サービスが壊れると、サーバーは呼び出されなくなり、クライアントは呼び出されなくなります。

ローカル フォールバック コールバックを自分で準備し、デフォルト値を返すことができます。そうすると、レベルは下がりますが、なんとか使えるようになりますが、

直接電話を切るよりも良いです。

Hystrix関連のメモ@EnableHystrix: ヒューズをオンにする @HystrixCommand(fallbackMethod="XXX"): ステートメント

失敗ロールバック処理関数 XXX。アノテーション付きメソッドの実行がタイムアウトすると (デフォルトは 1000 ミリ秒)、フォールバック関数が実行されます。

番号を指定すると、エラー メッセージが返されます。

5. EurekaとZookeeper はどちらもサービス登録および検出機能を提供できます。

2つの違いを教えてください。

Zookeeper は CP (C: 整合性、P: パーティションフォールトトレランス) を保証し、Eureka は AP (A: 高可用性) を保証します。

登録センターがサービス リストを照会する場合、登録センターが数分前に情報を返すことは許容できますが、直接の応答は許容できません。

ダウンは使用できません。言い換えれば、サービス登録機能は高可用性に対する比較的高い要件を持っていますが、zk ではそのような状況が発生します。

ネットワーク障害によりマスター ノードが他のノードとの接続を失った場合、残りのノードがリーダーを再選出します。問題はその選択です

Ali の内部データ リーダーは 30 ～ 120 秒と非常に時間がかかり、選択期間中に zk クラスターを利用できないため、選択期間中に登録サービスが麻痺します。

クラウド展開環境では、サービスは可能ですが、ネットワークの問題により zk クラスターがマスター ノードを失う可能性が非常に高くなります。

回復はしましたが、長い選択時間によって引き起こされる長期間の登録不能は容認できません。

2. Eureka は可用性を保証し、Eureka の各ノードは同等であり、いくつかのノードの障害は通常のノードの動作に影響を与えず、残りのノードは影響を受けません。

ノードは引き続き登録およびクエリ サービスを提供できます。ただし、エウレカのクライアントが特定のエウレカに登録または検出すると、接続エラーが発生します。

失敗した場合は、自動的に他のノードに切り替わります。1 つの Eureka が存在する限り、登録サービスは利用可能であることが保証されますが、情報は見つかりませんでした。

最新ではない可能性があります。さらに、Eureka には自己保護メカニズムもあり、15 分以内に 85% 以上のノードが正常でなくなった場合に備えられます。

ハートビートが発生すると、Eureka はクライアントと登録センターの間にネットワーク障害が発生したと判断し、この時点で次の状況が発生します。

①、

Eureka は、長期間ハートビートを受信して​​いないために期限切れになるはずのサービスを登録リストから削除しません。②、エウレカはまだできる

新しいサービスの登録およびクエリ要求を受け入れますが、他のノードとは同期されません (つまり、現在のノードが引き続き利用可能であることを確認するため)

③のとき

ネットワークが安定すると、現在のインスタンスの新しい登録情報が他のノードに同期されます。

したがって、Eureka は、Zookeeper のようなものではなく、ネットワーク障害により一部のノードが接続を失った状況にうまく対処できます。

マイクロサービス全体を麻痺させる

6. SpringBootとSpringCloudの違いは何ですか?

SpringBoot は、個々のマイクロサービスを迅速かつ便利に開発することに重点を置いています。

SpringCloud は、SpringBoot によって開発された個々のマイクロサービスを統合する、全体的な状況に焦点を当てたマイクロサービス調整およびガバナンスのフレームワークです。

複合管理、

マイクロサービス間の提供、構成管理、サービスディスカバリ、サーキットブレーカー、ルーティング、マイクロエージェント、イベントバス、グローバルロック、意思決定

キャンペーンや分散セッションなどの統合サービス

SpringBootはSpringCloudを使わずに開発プロジェクトを独立して利用することができ、

しかし、SpringCloud は SpringBoot と切り離すことができません。

依存関係。

SpringBoot は個々のマイクロサービスの迅速かつ便利な開発に重点を置いているのに対し、SpringCloud はグローバルなサービス ガバナンス フレームワークに重点を置いています。

7.負荷分散の意味は何ですか?

コンピューティングでは、複数のコンピュータ、コンピュータ クラスタ、ネットワーク リンク、中央処理装置、またはディスク ドライブにわたる負荷分散を改善できます。

コンピューティングリソースのワークロード分散。負荷分散は、リソース使用量を最適化し、スループットを最大化し、応答時間を最小限に抑え、負荷分散を回避するように設計されています。

単一リソースの過負荷。負荷分散に単一のコンポーネントではなく複数のコンポーネントを使用すると、信頼性が向上し、

可用性。負荷分散には通常、マルチレイヤ スイッチやドメイン ネーム システム サーバー プロセスなどの特殊なソフトウェアまたはハードウェアが必要です。

8.ハイストリックスとは何ですか? 耐障害性はどのように実現されるのでしょうか?

Hystrix は、障害が避けられない場合にアクセス ポイントをリモート システム、サービス、サードパーティ ライブラリに隔離するように設計されたレイテンシとフォールト トレラントなライブラリです。

障害が避けられない場合に、連鎖的な障害を阻止し、複雑な分散システムの回復力を実現します。

通常、マイクロサービス アーキテクチャを使用して開発されたシステムには、多数のマイクロサービスが関与します。これらのマイクロサービスは相互に連携します。

Ali の内部データに基づいて次のマイクロサービスを考えてください

上の図のマイクロサービス 9 が失敗した場合、従来の方法を使用して例外を伝播するとします。しかし、それでも全体的には

システムの故障。

マイクロサービスの数が増えると、この問題はさらに複雑になります。マイクロサービスの数は 1,000 に達する場合があります。ここで hystrix が登場します。

この場合、Hystrix のフォールバック メソッド機能を使用します。従業員と消費者向けの 2 つのサービスがあります

従業員消費者によって公開されるサービスを利用します。

簡略化した図を以下に示します。

ここで、何らかの理由で、employee-Producer によって公開されたサービスが例外をスローしたとします。この場合に使用するのは

Hystrix はフォールバック方式を定義しています。このフォールバック メソッドは、公開されたサービスと同じ戻り値の型を持つ必要があります。サービス内で暴露された場合

例外が発生した場合、フォールバック メソッドは何らかの値を返します。

9. Hystrixサーキットブレーカーとは何ですか? 必要ですか？

何らかの理由で、従業員と消費者がサービスを公開すると例外がスローされます。この場合、Hystrix を使用して次のように定義します。

フォールバック方式。公開されたサービスで例外が発生した場合、フォールバック メソッドはいくつかのデフォルト値を返します。

内部データもアリ fifirstPage メソッド() で例外が発生し続けると、Hystrix 回路が中断され、従業員とユーザーが一緒にスキップします

fifirtsPage メソッドを呼び出し、フォールバック メソッドを直接呼び出します。サーキット ブレーカーの目的は、最初のページ メソッド、または最初のページ メソッドが呼び出す可能性のある他のメソッドを提供することです。

時間を確保して例外を回復させるメソッド。例外の原因となっている問題には、さらに多くの問題がある可能性があります。

回復のチャンスは十分にあります。

10. RPCの実現原理について語る

まず、ネットワーク接続通信を処理するモジュールが必要です。これは、接続の確立、管理、メッセージ送信を担当します。次に、コーデックモジュールがあります

ネットワーク通信は送信用のバイトコードであり、使用するオブジェクトをシリアル化および逆シリアル化する必要があるためです。残りはクライアントです

サーバー側は開かれるサービス インターフェイスを公開し、クライアントはサービス インターフェイスのプロキシ実装を呼び出します。

プロキシ実装は、データを収集し、エンコードしてサーバーに送信し、結果が返されるのを待ちます。

11.エウレカの自己防衛機構とは何ですか?

Eureka Server ノードが短期間に非常に多くのインスタンス接続を失った場合 (ネットワーク障害やクライアントの頻繁な起動とシャットダウンなど)

end) ノードは登録情報を保護するために自己保護モードに入り、登録データの削除は行わなくなり、障害が回復すると自動的に自己保護モードが終了します。

保護モード。

12.リボンとは何ですか?

リボンは負荷分散クライアントであり、http と tcp の一部の動作を適切に制御できます。feign はデフォルトでリボンを統合します。

アリの内部情報13 、フェイジンとは何ですか？その利点は何ですか?

1. feign はインターフェイスベースの注釈を使用します 2. feign はリボンを統合し、負荷分散機能を備えています 3. Hystrix を統合し、

融合能力を持つ

使用方法: 1. pom 依存関係を追加します。2. @EnableFeignClients をスタートアップ クラスに追加します。 3. インターフェイスを定義します。

@FeignClient(name="xxx") は呼び出すサービスを指定します

14.リボンとフェーンの違いは何ですか?

1.Ribbon は他のサービスを呼び出しますが、その方法は異なります。2. スタートアップ クラスのアノテーションが異なり、リボンは @RibbonClient を装います

@EnableFeignClients とは 3. サービスが指定する場所が異なる @RibbonClient アノテーションでリボンを宣言し、Feign

それは、抽象メソッドを定義するインターフェイスで @FeignClient 宣言を使用することです。4. 呼び出し方法が異なります。リボンは独自に http を構築する必要があります。

リクエスト、http リクエストをシミュレートする

ダボ記事

実際、ダボのインタビューの質問に関しては、公式ウェブサイトが最良の資料であるべきだと思います。公式ウェブサイトには中国語版があり、多くの読者に配慮しているからです。

英語の文書を読むのに苦労している友達。ただ、公式サイトの内容が充実しているので、ここでは公式サイトと通常のインタビューを合わせて、質問も比較的多いです

トピックスが整理されました。

1. Dubboサービス リクエストのプロセスについて教えてください。

基本的なワークフロー:

上のアリの内部情報の写真における役割の説明:

2. Dubbo の動作原理について話す

動作原理は 10 の層に分かれています。

最初の層: サービス層、インターフェース層。サービスプロバイダーと消費者のために実装されます (開発者が実装するために残されます)。

第 2 層: 構成層、主に Dubbo のさまざまな構成、Dubbo 関連の構成用の構成層。

3 番目の層: プロキシ層、サービス プロキシ層は、クライアントのスタブとサービス オーダーのスケルトンを透過的に生成し、インターフェイスを呼び出します。

ポートには実装クラスがないため、エージェントを生成してから、バランスなどを担当するエージェント間のネットワーク通信を行う必要があります。

4 番目の層: レジストリ層、サービス登録層。サービスの登録と検出を担当します。

Ali の内部データの 5 番目のレイヤー: クラスター レイヤー、クラスター レイヤー、複数のサービス プロバイダーのルーティングと負荷分散のカプセル化、複数のインスタンスを 1 つに結合

サービス;

第六层：monitor 层，监控层，对 rpc 接口的调用次数和调用时间进行监控；

第七层：protocol 层，远程调用层，封装 rpc 调用；

第八层：exchange 层，信息交换层，封装请求响应模式，同步转异步；

第九层：transport 层，网络传输层，抽象 mina 和 netty 为统一接口；

第十层：serialize 层，数据序列化层。

这是个很坑爹的面试题，但是很多面试官又喜欢问，你真的要背么？你能背那还是不错的，我建议

不要背，你就想想 Dubbo 服务调用过程中应该会涉及到哪些技术，把这些技术串起来就 OK 了。

面试扩散

如果让你设计一个 RPC 框架，你会怎么做？其实你就把上面这个工作原理中涉及的到技术点总结一

下就行了。

3、Dubbo 支持哪些协议？

还有三种，混个眼熟就行：Memcached 协议、Redis 协议、Rest 协议。

上图基本上把序列化的方式也罗列出来了。

详细请参考：Dubbo 官网：http://dubbo.apache.org/zh-cn/docs/user/references/protocol/dub

bo.html。

4、注册中心挂了，consumer 还能不能调用 provider？

可以。因为刚开始初始化的时候，consumer 会将需要的所有提供者的地址等信息拉取到本地缓

存，所以注册中心挂了可以继续通信。但是 provider 挂了，那就没法调用了。

阿里内部资料关键字：consumer 本地缓存服务列表。

5、怎么实现动态感知服务下线的呢？

阿里内部资料服务订阅通常有 pull 和 push 两种方式：

pull 模式需要客户端定时向注册中心拉取配置；

プッシュ モードでは、登録センターを使用してデータをクライアントにアクティブにプッシュします。

Alibaba の内部データ Dubbo ZooKeeper 登録センターは、イベント通知とクライアント プルの方法を採用しています。サービスが初めてサブスクライブされると、プルされます

ディレクトリ内の全データに対応し、サブスクライブされたノードにウォッチャーを登録します。ディレクトリ ノードでデータが変更されると、

ZooKeeper はウォッチャーを通じてクライアントに通知します。通知を受信した後、クライアントはディレクトリ内の全データを再フェッチします。

そしてウォッチャーを再登録してください。このモードを使用すると、Dubbo サービスは動的なサービス検出を実現できます。

注: ZooKeeper は「ハートビート検出」機能を提供し、各サービス プロバイダーに定期的にリクエストを送信します (実際には、

ソケットの長期接続です)、長期間応答がない場合、サービス センターはサービス プロバイダーが「ハングした」と判断し、メッセージを送信します。

削除。

6. Dubbo負荷分散戦略?

ランダム (デフォルト): ランダムに来る

ローテーショントレーニング：1人ずつ来てください

アクティビティ: ロードするマシンのアクティビティ

一貫したハッシュ: 同じマシン上に存在する

7. Dubboフォールトトレランス戦略

フェイルオーバークラスターモード

プロバイダーがダウンして再試行した後、リクエストは他のプロバイダーに分散されます。デフォルトは 2 回です。再試行回数は手動で設定できます。推奨

書き込み操作の再試行回数を 0 に設定することをお勧めします。

フェイルバックモード

失敗の自動回復は、呼び出しが失敗した後、空の結果をサービス コンシューマに返します。そして、スケジュールされたタスクを通じて失敗した通話を呼び出します

リトライ。メッセージ通知などの操作を実行するのに適しています。

フェイルファストクラスタモード

フェイルファストは 1 回の呼び出しのみを行い、失敗の直後に例外をスローします。フェイルオーバーと同様、冪等操作や書き込み操作に適しています。

クラスタモードでリトライ回数を0に設定した場合。

フェールセーフクラスターモード

フェールセーフとは、呼び出し中に例外が発生した場合に、例外がスローされずに出力されるだけであることを意味します。監査ログへの書き込みに適しています

等々。

クラスターモードのフォーク

複数のサーバーを並行して呼び出し、いずれかが成功する限り戻ります。通常、リアルタイム要件の高い読み取り操作に使用されますが、より多くの時間を無駄にする必要があります。

サービスリソース。最大並列数は forks="2" で設定できます。

ブロードキャストクラスタモード

ブロードキャストはすべてのプロバイダーを 1 つずつ呼び出し、いずれかのプロバイダーがエラーを報告すると、そのプロバイダーもエラーを報告します。通常、すべてのプロバイダーにキャッシュまたはログを更新するように通知するために使用されます。

およびその他の地域リソース情報。

Ali の内部情報8. Dubbo の動的プロキシ戦略とは何ですか?

デフォルトでは、javassist 動的バイトコード生成を使用してプロキシ クラスが作成されますが、SPI 拡張メカニズムを通じて独自の動的プロキシを構成できます。

ストラテジー。

9. DubboとSpring Cloudの違いについて教えてください。

これは多くの面接官が好んで尋ねる質問で、両者に関係はないと思いますが、違いを聞きたい場合は、それについて話しましょう。

バー。

回答する際は、主に通信方法、登録センター、監視、サーキットブレーカー、その他 Spring ディストリビューションの 4 つのポイントを中心に回答します。

構成とサービス ゲートウェイについて知っておく必要があります。

コミュニケーションの方法

Dubbo は RPC 通信を使用しますが、Spring Cloud は HTTP RestFul メソッドを使用します。

登録センター

Dubbo は ZooKeeper (公式推奨)、および Redis、Multicast、Simple レジストリを使用しますが、推奨されません。;

Spring Cloud は Spring Cloud Netflix Eureka を使用します。

モニター

Dubbo は Dubbo-monitor を使用し、Spring Cloud は Spring Boot admin を使用します。

ブレーカ

Dubbo はサーキット ブレーカーの点では完璧ではありませんが、Spring Cloud は Spring Cloud Netflix Hystrix を使用します。

分散構成、ゲートウェイ サービス、サービス トラッキング、メッセージ バス、バッチ タスクなど。

Dubbo は現時点では空白であると言えますが、Spring Cloud にはそれをサポートする対応するコンポーネントがあります。

10.動物園の飼育員とダボの関係は何ですか?

動物園の飼育員の役割

Zookeeper はサービスの登録と負荷分散の実行に使用されますが、どのサービスがどのマシンによって提供されているかを呼び出し元に知らせる必要があります。

簡単に言えば、ipアドレスとサービス名の対応です。もちろん、この通信は呼び出し側でハードコーディングすることもできます。

これはビジネスコードに実装されていますが、サービスを提供するマシンがハングアップした場合、呼び出し側はそれを知ることができず、コードが変更されない場合、リクエストはハングアップし続けます。

機械がサービスを提供します。Zookeeper はハートビート メカニズムを通じて吊り下げられたマシンを検出でき、吊り下げられたマシンの IP とサービスに対応します。

リストから削除する。高同時実行性のサポートについては、簡単に言うと水平拡張であり、コードを変更せずにマシンを追加することで改善できます。

高い計算能力。新しいマシンを追加して動物園の飼育員にサービスを登録することで、より多くのサービス プロバイダーがより多くの顧客にサービスを提供できるようになります。

内部情報ダボもアリ

中間層を管理するためのツールです。多くのサービス アクセスがあり、ビジネス層とデータ ウェアハウスの間にサービス プロバイダーをスケジュールする必要があります。

この問題を解決するためのフレームワークを提供します。ここでのダボは単なるフレームであることに注意してください、棚に何を置くかは完全に依存します

車のスケルトンと同じように、ホイールのエンジンも一致させる必要があります。このフレームワークでスケジューリングを完了するには、分散型

登録センターにはすべてのサービスのメタデータが保存されます。zk またはその他のサービスを使用できますが、全員が zk を使用します。

飼育員とダボの関係

Dubbo は登録センターを抽象化し、さまざまなストレージ メディアを接続して登録センターにサービスを提供できます。

ZooKeeper，Memcached，Redis 等。

引入了 ZooKeeper 作为存储媒介，也就把 ZooKeeper 的特性引进来。首先是负载均衡，单注册中

心的承载能力是有限的，在流量达到一定程度的时 候就需要分流，负载均衡就是为了分流而存在

的，一个 ZooKeeper 群配合相应的 Web 应用就可以很容易达到负载均衡；资源同步，单单有负载

均衡还不 够，节点之间的数据和资源需要同步，ZooKeeper 集群就天然具备有这样的功能；命名

服务，将树状结构用于维护全局的服务地址列表，服务提供者在启动 的时候，向 ZooKeeper 上的

指定节点 /dubbo/${serviceName}/providers 目录下写入自己的 URL 地址，这个操作就完成了服

务的发布。 其他特性还有 Mast 选举，分布式锁等。

Nginx篇

1、简述一下什么是Nginx，它有什么优势和功能？

Nginx是一个web服务器和方向代理服务器，用于HTTP、HTTPS、SMTP、POP3和IMAP协议。因

它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。

Nginx---Ngine X，是一款免费的、自由的、开源的、高性能HTTP服务器和反向代理服务器；

也是一个IMAP、POP3、SMTP代理服务器；Nginx以其高性能、稳定性、丰富的功能、简单的

配置和低资源消耗而闻名。

阿里内部资料也就是说Nginx本身就可以托管网站（类似于Tomcat一样），进行Http服务处理，也可以作为

反向代理服务器 、负载均衡器和HTTP缓存。

Nginx 解决了服务器的C10K（就是在一秒之内连接客户端的数目为10k即1万）问题。它的设

计不像传统的服务器那样使用线程处理请求，而是一个更加高级的机制—事件驱动机制，是一

种异步事件驱动结构。

优点：

( 1 ) より高速これは2 つの側面で明らかです: 一方で、通常の状況では、単一のリクエストはより高速な応答を受け取りますが、他方では、

ピーク時 (数万の同時リクエストなど)、Nginx は他の Web サーバーよりも速くリクエストに応答できます。

( 2 ) 高い拡張性、クロスプラットフォーム Nginx の設計は非常に拡張性が高く、複数の異なる機能、異なるレベル、異なるタイプで完全に構成されています。

結合度が極めて低いモジュールで構成されています。したがって、バグを修正したり、特定のモジュールをアップグレードしたりする場合は、モジュール自体に集中することができます。

他のことは心配しないでください。さらに、HTTP モジュールでは、HTTP フィルター モジュールも設計されています。通常の HTTP モジュールが処理されます。

リクエストの後、リクエストの結果を再処理するための一連の HTTP フィルター モジュールが存在します。このようにして、新しい HTTP モジュールを開発するときに、

、HTTP コア モジュール、イベント モジュール、ログ モジュールなど、さまざまなレベルやさまざまなタイプのモジュールを使用できるだけでなく、

多数の既存の HTTP フィルター モジュールをそのまま再利用できます。この低結合の優れた設計により、巨大な Nginx が作成されました。

サードパーティのモジュールはもちろん、公開されているサードパーティのモジュールも、公式にリリースされたモジュールと同じくらい使いやすいです。Nginxモジュールはすべて埋め込まれています

公式にリリースされたモジュールやサードパーティのモジュールに関係なく、バイナリ ファイルで実行されます。これにより、サードパーティのモジュールが次のようになります

優れたパフォーマンスを備え、Nginx の高い同時実行機能を最大限に活用しているため、トラフィックの多い Web サイトの多くは独自の開発を行う傾向があります。

独自のビジネス特性を持つカスタム モジュール。

( 3 ) 高い信頼性: リバースプロキシの場合、ダウンタイムの可能性が非常に小さいです。高い信頼性は、Nginx を選択するための最も基本的な条件です。

Nginx の信頼性は誰の目にも明らかであるため、トラフィックの多い Web サイトの多くはコア サーバー上で Nginx を大規模に使用しています。

Nginx の高い信頼性は、コア フレームワーク コードの優れた設計とモジュール設計のシンプルさに加え、一般的に使用される公式

モジュールは非常に安定しており、各ワーカー プロセスは比較的独立しており、ワーカー プロセスが失敗した場合にはマスター プロセスがすぐに「プル」できます。

start" 新しいワーカー子プロセスを実行してサービスを提供します。

( 4 ) メモリ消費量が少ない 一般に、Nginx では、10,000 の非アクティブな HTTP キープアライブ接続はわずか 2.5MB しか消費しません。

メモリ。Nginx が大量の同時接続をサポートするための基盤です。

( 5 ) 1 台のマシンで100,000を超える同時接続をサポートこれは非常に重要な機能です。インターネットの急速な発展と利用により、

ユーザー数の急激な増加に伴い、大手企業や Web サイトは大量の同時リクエストに対処する必要があります。

リクエストを送信するサーバーは間違いなく誰からも好まれるでしょう。理論上、Nginx でサポートされる同時接続の上限はメモリに依存し、100,000

上限にはほど遠い。もちろん、より多くの同時リクエストをタイムリーに処理できるかどうかは、ビジネスの特性と密接に関係しています。

( 6 ) ホットデプロイマスター管理プロセスとワーカー作業プロセスの分離設計により、 Nginx はホットデプロイ機能を提供できます。

Nginx の実行ファイルは、24 時間 365 日の無停止サービスを前提としてアップグレードできます。もちろんサービスを止めずにアップデートにも対応

新しい設定項目やログファイルの置き換えなどの機能。

Ali 内部情報( 7 ) 最も自由なBSDライセンス契約これは、 Nginx の急速な発展の強力な原動力です。BSD 使用許諾契約は、ユーザーに次のことを許可するだけではありません。

Nginx は無料で使用でき、ユーザーは自分のプロジェクトで Nginx ソース コードを直接使用または変更し、公開することもできます。これは数え切れないほどの人を魅了しました

開発者は引き続き Nginx に知恵を出し続けています。もちろん、上記 7 つの機能が Nginx のすべてではなく、公式の機能モジュールが無数にあります。

ブロックとサードパーティの機能モジュールにより、Nginx はほとんどのアプリケーション シナリオを満たすことができます。これらの機能モジュールを重ね合わせて、より多くのことを実現できます。

強力かつ複雑な機能。一部のモジュールは、Nginx と Perl、Lua、その他のスクリプト言語の統合もサポートしており、開発効率が大幅に向上します。

率。这些特点促使用户在寻找一个Web服务器时更多考虑Nginx。 选择Nginx的核心理由还是它能

在支持高并发请求的同时保持高效的服务。

2、Nginx是如何处理一个HTTP请求的呢？

Nginx 是一个高性能的 Web 服务器，能够同时处理大量的并发请求。它结合多进程机制和异步机制

，异步机制使用的是异步非阻塞方式 ，接下来就给大家介绍一下 Nginx 的多线程机制和异步非阻塞

机制 。

1、多进程机制

服务器每当收到一个客户端时，就有 服务器主进程 （ master process ）生成一个 子进程（

worker process ）出来和客户端建立连接进行交互，直到连接断开，该子进程就结束了。

使用进程的好处是各个进程之间相互独立，不需要加锁，减少了使用锁对性能造成影响，同时降低

编程的复杂度，降低开发成本。其次，采用独立的进程，可以让进程互相之间不会影响 ，如果一个

进程发生异常退出时，其它进程正常工作， master 进程则很快启动新的 worker 进程，确保服务

不会中断，从而将风险降到最低。

缺点是操作系统生成一个子进程需要进行 内存复制等操作，在资源和时间上会产生一定的开销。当

有大量请求时，会导致系统性能下降 。

2、异步非阻塞机制

每个工作进程 使用 异步非阻塞方式 ，可以处理 多个客户端请求 。

当某个 工作进程 接收到客户端的请求以后，调用 IO 进行处理，如果不能立即得到结果，就去 处理

其他请求 （即为 非阻塞 ）；而 客户端 在此期间也 无需等待响应 ，可以去处理其他事情（即为 异

步 ）。

当 IO 返回时，就会通知此 工作进程 ；该进程得到通知，暂时 挂起 当前处理的事务去 响应客户端

请求 。

3、列举一些Nginx的特性

1. Nginx服务器的特性包括：

2. 反向代理/L7负载均衡器

3. 嵌入式Perl解释器

4. 动态二进制升级

5. 可用于重新编写URL，具有非常好的PCRE支持

阿里内部资料4、请列举Nginx和Apache 之间的不同点

5、在Nginx中，如何使用未定义的服务器名称来阻止处理请求？

只需将请求删除的服务器就可以定义为：

Server{

listen 80;

server_name "";

return 444;

}

这里，服务器名被保留为一个空字符串，它将在没有“主机”头字段的情况下匹配请求，而一个特殊

的Nginx的非标准代码444被返回，从而终止连接。

一般推荐 worker 进程数与CPU内核数一致，这样一来不存在大量的子进程生成和管理任务，避免

了进程之间竞争CPU 资源和进程切换的开销。而且 Nginx 为了更好的利用 多核特性 ，提供了 CPU

亲缘性的绑定选项，我们可以将某一个进程绑定在某一个核上，这样就不会因为进程的切换带来

Cache 的失效。

对于每个请求，有且只有一个工作进程 对其处理。首先，每个 worker 进程都是从 master进程

fork 过来。在 master 进程里面，先建立好需要 listen 的 socket（listenfd）

之后，然后再 fork 出

多个 worker 进程。

阿里内部资料所有 worker 进程的 listenfd 会在新连接到来时变得可读 ，为保证只有一个进程处理该连接，所有

ワーカー プロセスは listenfd 読み取りイベントを登録する前に accept_mutex をプリエンプトし、ミューテックスを取得するプロセスは listenfd 読み取りイベントを登録します。

イベントの場合は、読み取りイベントで accept を呼び出して接続を受け入れます。

ワーカー プロセスが接続を受け入れると、リクエストの読み取り、解析、リクエストの処理、およびデータの生成が開始されます。

その後、クライアントに戻り、最後に切断します。このような完全なリクエストは次のようになります。ということがわかります。

リクエストは完全にワーカー プロセスによって処理され、1 つのワーカー プロセス内でのみ処理されます。

Nginxサーバーの実行中に、

マスター プロセスとワーカー プロセスにはプロセスの対話が必要です。インタラクションはソケットによって実装されたパイプラインに依存します

満たすため。

6. Nginxサーバー上のマスター プロセスとワーカープロセスについて説明してください。

メイン プログラムのマスター プロセスが開始されると、for ループを通じて外部信号を受信して​​処理します。

メインプロセスは fork() 関数を通じてワーカー子プロセスを生成し、各子プロセスは for ループを実行して Nginx サーバーを実装します。

イベントを受信して​​処理します。

7.プロキシ内のフォワードプロキシとリバースプロキシについて説明してください

まず、プロキシ サーバーとは、一般に、プロキシ サーバーを介してインターネット上のサーバーにリクエストを送信する LAN 上のマシンを指します。

通常、サーバーはクライアント上で動作します。例: GoAgent 回避ソフトウェア。クライアントが壁を越えた操作を実行している場合、私たちは以下を使用します。

使用されるのはフォワード プロキシです。フォワード プロキシを通じて、クライアント上でソフトウェアが実行され、HTTP リクエストが転送されます。

他の異なるサーバーへのリクエストの分散を実現します。

リバース プロキシ サーバーはサーバー側で動作し、サーバー側でクライアントのリクエストを受信し、そのリクエストを特定のサービスに振り分けます。

サーバーはそれを処理し、対応する結果をサーバーからクライアントにフィードバックします。Nginx はリバース プロキシ サーバー ソフトウェアです。

上の図からわかるように、クライアントはフォワード プロキシ サーバーを設定する必要があります。もちろん、フォワード プロキシ サーバーの IP アドレスを知っていることが前提となります。

エージェントのポートもあります。リバース プロキシはフォワード プロキシの逆であり、プロキシ サーバーはクライアントに対する元のサービスのようなものです。

サーバーに接続するだけでよく、クライアントには特別な設定は必要ありません。クライアントからリバースプロキシの名前空間（name-space）へ

コンテンツは通常のリクエストを送信し、リバース プロキシがリクエストの転送先 (オリジン サーバー) を決定し、取得したコンテンツをサーバーに返します。

クライアント。

8. Nginxの目的を説明する

Nginx サーバーの最適な使用法は、SCGI、WSGI アプリケーション サーバーを使用して、動的 HTTP コンテンツを Web 上にデプロイすることです。

スクリプト用の FastCGI ハンドラー。ロードバランサーとしても機能します。

MQの記事

1. MQを使用する理由

コア: デカップリング、非同期、ピーククリッピング

Ali 内部情報1 ) デカップリング:システム A は 3 つの BCD システムにデータを送信し、インターフェイス呼び出しを通じてそれらを送信します。E システムもこのデータを必要とする場合はどうなるでしょうか? それか

C システムが不要になったらどうなるでしょうか? システムAの担当者が崩壊寸前…システムAは他の厄介なシステムと深刻に結合している

これらを組み合わせると、システム A は重要なデータを生成し、多くのシステムではシステム A がこのデータを送信する必要があります。使用する場合

MQ、システム A はデータを生成し、それを MQ に送信します。システムは、MQ 内で独自にデータを消費する必要があります。新しい場合

システムがデータを必要とする場合は、MQ から直接消費できます。システムがこのデータを必要としない場合は、MQ メッセージ メッセージをキャンセルします。

有料でも可能です。このようにして、システム A はデータを誰に送信するかを考える必要がなく、このコードを保守する必要も、

呼び出しが成功したかどうか、失敗のタイムアウトなどを考慮してください。

複数のシステムやモジュールを呼び出すシステムやモジュールのことですが、相互の呼び出しが非常に複雑でメンテナンスが大変です。

わざわざ。しかし実際には、MQ を使用してインターフェイスを非同期的に分離する場合、この呼び出しはインターフェイスを直接同期的に呼び出す必要はありません。

（2）异步：A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地

写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 +

450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请

求。如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一

个请求到返回响应给用户，总时长是 3 + 5 = 8ms。

（3）削峰：减少高峰时期对服务器压力。

欢迎关注微信公众号：Java后端技术全栈

2、MQ有什么优缺点

优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰。

缺点有以下几个：

系统可用性降低 系统引入的外部依赖越多，越容易挂掉。万一 MQ 挂了，MQ 一挂，整套系统崩

溃，你不就完了？

系统复杂度提高 硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？

怎么保证消息传递的顺序性？问题一大堆。

一致性问题 A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是

BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致

了。

3. Kafka 、ActiveMQ 、RabbitMQ 、およびRocketMQの違いは何ですか

そうじゃないですか？

スループットに関しては、Kafka と RocketMQ が高スループットをサポートしていますが、ActiveMQ と RabbitMQ はそれらよりも 1 桁低いです。ために

RabbitMQ はレイテンシの点で最も低いです。

1.コミュニティ活動の度合いから

Ali の内部情報 現在のインターネット上の情報によると、RabbitMQ、activeM、ZeroMQ のうち、一般的に RabbitMQ が最初です。

選択する。

2.永続メッセージの比較

ActiveMq と RabbitMq の両方がサポートされています。永続的なメッセージは主に、不可抗力などの状況でマシンがハングアップすることを指します。

情報が失われない仕組み。

3.総合的な技術実現

信頼性、柔軟なルーティング、クラスタリング、トランザクション、高可用性キュー、メッセージ順序付け、問題追跡、ビジュアル管理ツール、プラグイン

システムなど。

RabbitMq/Kafka が最高で、次に ActiveMq、そして最悪は ZeroMq です。もちろん、ZeroMq でも実行できますが、次のようにする必要があります。

実装するには手動でコードを記述する必要があり、コード量は少なくありません。特に信頼性: 永続性、配信確認、発行者確認、高可用性

セックス。

4.高い同時実行性

RabbitMQ が最も優れているのは間違いありません。その実装言語は、高い同時実行性と高可用性を備えて生まれた erlang 言語であるためです。

5.懸念事項の比較、RabbitMQとKafka

RabbitMq は Kafka よりも成熟しており、使いやすさ、安定性、信頼性の点で、RabbitMq は Kafka よりも優れています (理論上)

上長）。

なお、Kafka の位置づけは主にログなどです。

Kafka 設計の本来の目的はログを処理することであるため、それはログを処理することであると考えることができます。

ログ (メッセージ) システムは重要なコンポーネントであり、ターゲットが絞られているため、ビジネスの観点から RabbitMq を選択することをお勧めします。

さらに、Kafka のパフォーマンス (スループット、TPS) は RabbitMq よりもはるかに優れています。

4.高可用性を確保するにはどうすればよいですか?

RabbitMQ は、高可用性を実現するマスター/スレーブ(非分散)に基づいているため、より代表的です。RabbitMQ を使用します。

例として、最初の MQ の高可用性を実現する方法を説明します。RabbitMQ には、スタンドアロン モード、共通クラスター モード、

ミラーリングクラスターモード。

スタンドアロン モードはデモ レベルです。一般に、楽しむためにローカルで起動します。本番環境でスタンドアロン モードを使用する人はいません。

通常のクラスター モードは、複数のマシン上で複数の RabbitMQ インスタンスを各マシンに 1 つずつ起動することを意味します。あなたが作成した

キューは1 つのRabbitMQインスタンスにのみ配置されますが、各インスタンスはキューのメタデータを同期します (メタデータは次のように識別できます)。

キューの一部の構成情報については、キューが配置されているインスタンスをメタデータを通じて見つけることができます。実際に摂取すると、

別のインスタンスに接続されている場合、そのインスタンスはキューが配置されているインスタンスからデータをプルします。この企画は主に、

高スループットとは、クラスター内の複数のノードが特定のキューの読み取りおよび書き込み操作を処理することを意味します。

Alibaba 内部データ ミラーリング クラスター モード: このモードは、RabbitMQ のいわゆる高可用性モードです。通常のクラスターモードとは異なり、

ミラークラスターモードでは、キュー内のメタデータやメッセージに関係なく、作成したキューは複数のインスタンスに存在します。

是说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。然

后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。RabbitMQ 有很

好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候是可以

要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这

个策略，就会自动将数据同步到其他的节点上去了。这样的话，好处在于，你任何一个机器宕机

了，没事儿，其它机器（节点）还包含了这个 queue 的完整数据，别的 consumer 都可以到其它

节点上去消费数据。坏处在于，第一，这个性能开销也太大了吧，消息需要同步到所有机器上，导

致网络带宽压力和消耗很重！RabbitMQ 一个 queue 的数据都是放在一个节点里的，镜像集群下，

也是每个节点都放这个 queue 的完整数据。

Kafka 一个最基本的架构认识：由多个 broker 组成，每个 broker 是一个节点；你创建一个

topic，这个 topic 可以划分为多个 partition，每个 partition 可以存在于不同的 broker 上，每个

partition 就放一部分数据。这就是天然的分布式消息队列，就是说一个 topic 的数据，是分散放在

多个机器上的，每个机器就放一部分数据。Kafka 0.8 以后，提供了 HA 机制，就是 replica（复制

品）

副本机制。每个 partition 的数据都会同步到其它机器上，形成自己的多个 replica 副本。所有

replica 会选举一个 leader 出来，那么生产和消费都跟这个 leader 打交道，然后其他 replica 就是

follower。写的时候，leader 会负责把数据同步到所有 follower 上去，读的时候就直接读 leader

上記のデータで十分です。リーダーしか読み書きできないのですか？非常に簡単です。各フォロワーを自由に読み書きできるのであれば、次の点に注意する必要があります。

一貫性の問題によると、システムの複雑さが高すぎて、間違いが発生しやすくなります。Kafka はすべてを均等に分配します

耐障害性を向上させるために、レプリカはさまざまなマシンに分散されます。ブローカーがダウンしても大丈夫だから

ブローカー上のパーティションには他のマシン上にコピーがあります。そこにパーティション リーダーがある場合は、

したがって、この時点で、新しいリーダーがフォロワーの中から再選出され、誰もが引き続き新しいリーダーの読み書きを行うことができます。これは

高可用性と呼ばれるものがあります。データを書き込むときは、プロデューサーがリーダーに書き込み、次にリーダーがデータをローカル ディスクに書き込みます。

次に、他のフォロワーが率先してリーダーからデータを引き出します。すべてのフォロワーがデータを同期すると、データが送信されます

ack はリーダーに送信され、リーダーがフォロワーからすべての ack を受信した後、書き込み成功メッセージをプロデューサーに返します。（いつ

もちろん、これはモードの 1 つにすぎず、この動作は適切に調整できます) 消費するときは、リーダーからのみ読み取りますが、

メッセージがすべてのフォロワーによって同期的に正常に返されると、そのメッセージはコンシューマーによって読み取られます。

5.メッセージの信頼性の高い送信を保証するにはどうすればよいですか? メッセージが失われた場合はどうすればいいですか

データ損失の問題は、プロデューサー、MQ、およびコンシューマーで発生する可能性があります

プロデューサーの損失: プロデューサーが RabbitMQ にデータを送信すると、ネットワークの問題によりデータが途中で失われる可能性があります。

何でも可能です。このとき、RabbitMQ が提供するトランザクション機能を使用することを選択できます。つまり、データを送信する前にプロデューサーが開始されます。

RabbitMQ トランザクションの channel.tx を選択し、メッセージを送信します (メッセージが RabbitMQ によって正常に受信されなかった場合)。

プロデューサは例外エラーを受け取ります。この時点で、トランザクション channel.txRollback をロールバックして、メッセージを再度送信しようとします (メッセージを受信した場合)。

メッセージを受信すると、トランザクション channel.txCommit をコミットできます。パフォーマンスを消費しすぎるため、スループットが低下します。したがって、一般的に、次の場合、

RabbitMQ に書き込まれたメッセージが失われないようにするには、確認モードを有効にし、プロデューサで確認モードが有効になるように設定します。

数式の後、作成した各メッセージには一意の ID が割り当てられ、それが RabbitMQ に書き込まれると、RabbitMQ は

Ali の内部情報については、メッセージに問題がないことを示す ack メッセージを送り返します。RabbitMQ がメッセージの処理に失敗した場合は、折り返し電話します。

nack インターフェイスは、メッセージの受信に失敗したことを通知し、再試行できます。そして、このメカニズムを組み合わせてそれぞれを維持することができます。

メッセージ ID のステータス。一定時間が経過してもこのメッセージのコールバックを受信しなかった場合は、メッセージを再送信できます。トランザクションメカニズムと

cnofirm メカニズムの最大の違いは、トランザクション メカニズムが同期であり、トランザクションの送信後にそこでブロックされることですが、

確認メカニズムは非同期であり、メッセージを送信した後、次のメッセージを送信でき、そのメッセージは RabbitMQ によって受信されます。

メッセージを受信すると、インターフェイスを非同期にコールバックして、メッセージを受信したことを通知します。したがって、一般に、データの損失はプロデューサー側で回避されます。

確認メカニズムを使用しています。

Lost in MQ: RabbitMQ 自体がデータを失ったことを意味します。このためには、RabbitMQ の永続化、つまりメッセージの書き込みを有効にする必要があります。

入力後はディスクに永続化され、RabbitMQ が単独でハングアップした場合でも、回復後に以前に保存されたデータが自動的に読み込まれます。

データは失われません。永続性を設定するには 2 つの手順があります。キューの作成時に永続性を設定します。

RabbitMQ はキューのメタデータを保持しますが、キュー内のデータは保持しません。2つ目はメッセージを送信するときです

メッセージのdeliveryModeを2に設定することは、メッセージを永続的として設定することを意味し、この時点でRabbitMQはメッセージを永続化します。

ディスクに。これら 2 つの永続性は同時に設定する必要があり、RabbitMQ がハングアップして再起動しても、ディスクから保存されます。

ディスク上の回復キューを再起動し、キュー内のデータを復元します。永続化はプロデューサー側の確認メカニズムと連携できます。

プロデューサーには、メッセージがディスクに永続化された後でのみ ack が通知されるため、メッセージがディスクに永続化される前であっても、

RabbitMQ がハングアップし、データが失われ、プロデューサーは ACK を受信できません。自分で再送信することもできます。与えても注意してください

RabbitMQ は永続化メカニズムを有効にしました。このメッセージは RabbitMQ に書き込まれている可能性もありますが、まだ届いていません。

ディスクに保存されますが、残念ながらこの時点で RabbitMQ がハングアップし、メモリ内のデータが少し失われます。

消費者側の喪失: 消費するときは、消費したばかりでまだ処理していないため、プロセスが再起動などでハングアップしてしまい、恥ずかしい思いをします。

RabbitMQ は、すべてのデータが消費され、データが失われると考えます。現時点では、RabbitMQ が提供する ack メカニズムを使用する必要があります。

つまり、RabbitMQ の自動 ACK をオフにすると、API 経由で呼び出して、毎回自分のコードで確認できるようになります。

処理が完了したら、再度プログラム内でACKを行います。この場合、処理が終わっていない場合、ackは出ないのではないでしょうか？それか

RabbitMQ は処理が完了していないと判断し、この時点でこの消費を他のコンシューマーに割り当てます。

理由は、ニュースが失われることはありません。

6.メッセージの順序を保証する方法

まず、順序が乱れているシーンを見てみましょう。 RabbitMQ: 1 つのキュー、複数のコンシューマ。明らかに乱れていません。

Ali 内部データ ソリューション:

7.メッセージキューの遅延と有効期限の問題を解決するにはどうすればよいですか? メッセージキューがいっぱいです

次に何をすればいいでしょうか？何百万ものメッセージが何時間もバックログに残っています。それを解決するにはどうすればよいでしょうか?

メッセージバックログの処理方法：一時的な緊急拡張：

まずコンシューマの問題を解決して消費速度が回復することを確認してから、既存のコンシューマを停止します。新しいものを作成する

トピックとパーティションは元の数の 10 倍、キューの数は元の数の 10 倍が一時的に確立されます。次に、一時的なディストリビューションを作成します

データ コンシューマ プログラム。このプログラムはデータのバックログを消費するためにデプロイされ、消費後の時間のかかる処理を直接かつ均等に実行しません。

ポーリングは、一時的に確立されたキューの数の 10 倍を書き込みます。次に、コンシューマーを展開するマシンの数の 10 倍を一時的に要求します。

批 consumer 消费一个临时 queue 的数据。这种做法相当于是临时将 queue 资源和 consumer 资

源扩大 10 倍，以正常的 10 倍速度来消费数据。 等快速消费完积压数据之后，得恢复原先部署的

架构，重新用原先的 consumer 机器来消费消息。 MQ中消息失效：假设你用的是 RabbitMQ，

RabbtiMQ 是可以设置过期时间的，也就是 TTL。如果消息在 queue 中积压超过一定的时间就会被

RabbitMQ 给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在 mq

里，而是大量的数据会直接搞丢。我们可以采取一个方案，就是批量重导，这个我们之前线上也有

类似的场景干过。就是大量积压的时候，我们当时就直接丢弃数据了，然后等过了高峰期以后，比

如大家一起喝咖啡熬夜到晚上12点以后，用户都睡觉了。这个时候我们就开始写程序，将丢失的那

批数据，写个临时程序，一点一点的查出来，然后重新灌入 mq 里面去，把白天丢的数据给他补回

阿里内部资料来。也只能是这样了。假设 1 万个订单积压在 mq 里面，没有处理，其中 1000 个订单都丢了，你

只能手动写程序把那 1000 个订单给查出来，手动发到 mq 里去再补一次。

mq消息队列块满了：如果消息积压在 mq 里，你很长时间都没有处理掉，此时导致 mq 都快写满

了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数

据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上

再补数据吧。

8、让你来设计一个消息队列，你会怎么设计

比如说这个消息队列系统，我们从以下几个角度来考虑一下：

首先这个 mq 得支持可伸缩性吧，就是需要的时候快速扩容，就可以增加吞吐量和容量，那怎么

搞？设计个分布式的系统呗，参照一下 kafka 的设计理念，broker -> topic -> partition，每个

パーティションはマシンを配置し、データの一部を保存します。現時点でリソースが十分でない場合は、トピックにパーティションを追加するだけです。

次に、データを移行してマシンを追加すると、より多くのデータを保存して、より高いスループットを提供できるでしょうか?

次に、この mq のデータをディスクに配置するかどうかを考慮する必要があります。これは必須である必要があり、ディスクを使用すると、多数のプロセスがハングアップしないようにすることができます。

証拠は失われます。ディスクを落としたとき、どうやって落ちましたか? シーケンシャル書き込み。ディスクのランダム読み取りと書き込み、およびディスクのシーケンシャル読み取りのアドレス指定オーバーヘッドがありません。

書き込みのパフォーマンスは非常に高く、これはカフカの考えです。

次に、mq の可用性を考慮していますか? この点については、可用性に関する前のリンクで説明されている高レベルの Kafka を参照してください。

利用可能な安全策。複数のコピー -> リーダーとフォロワー -> ブローカーは電話を切り、外部の世界に奉仕するリーダーを再選出します。

データ 0 損失をサポートできますか? はい、前述した Kafka のデータ損失ゼロ ソリューションを参照してください。

データ構造とアルゴリズム

他の 2 冊の小冊子に掲載されています。

Linuxの記事

1.絶対パスを表すにはどのような記号が使用されますか? カレントディレクトリと上位ディレクトリとは何ですか？

メインディレクトリとは何ですか?ディレクトリを切り替えるにはどのようなコマンドを使用しますか?

絶対パス:

/etc/init.d など

現在のディレクトリと親ディレクトリ: ./ ../

ホームディレクトリ: ~/

ディレクトリを変更します: cd

Ali の内部情報2.現在のプロセスを確認するにはどうすればよいですか? 出口を実行するにはどうすればよいですか? 現在のパスを確認するにはどうすればよいですか?

現在のプロセスを表示します: ps

ps -l はこのログインに関連するプロセス情報をリストします; ps -aux はメモリ内のプロセス情報をクエリします; ps -aux | grep * query

*プロセスの詳細情報; メモリ内のプロセスの動的情報を表示するには top; プロセスを強制終了するには kill -9 pid。

実行終了: 終了

現在のパスを表示します: pwd

3.ファイル内のコマンドを確認します。

vi ファイル名#編集モードビュー、変更可能

cat ファイル名#すべてのファイルの内容を表示

more filename#ファイルの内容をページに表示する

ファイル名を少なくする#増やすと同様に、ページをめくったほうがよい

末尾ファイル名 #末尾のみ表示、行数指定も可能

head ファイル名 # ヘッダーのみを表示します。行数も指定できます

4.一般的に使用されるいくつかのLinuxコマンドをリストします。

ファイルリストをリストします: ls [パラメータ -a -l]

ディレクトリの作成と削除: mkdir rmdir

ファイルの最後の数行を表示するために使用されます: tail、例: tail -n 1000: 最後の 1000 行を表示します

パッケージング: tar -xvf

パックして圧縮: tar -zcvf

文字列の検索: grep

現在のディレクトリを表示します: pwd 空のファイルを作成します: touch

編集者: ヴィムヴィ

5.いつもどのようにログを確認しますか?

Linux ではログを表示するためのコマンドが多数あります (tail、cat、tac、head、echo など)。この記事では、一般的に使用されるいくつかの方法のみを紹介します。

1 、尻尾

最も一般的な表示方法

コマンド形式：tail[必須パラメータ][オプションパラメータ][ファイル]

Ali 内部データ -f ループで読み込む -q 処理情報を表示しない -v 詳細な処理情報を表示する -c<数値> バイト数を表示 -n<行番号> 行数を表示 -

q、--quiet、--silent 指定されたファイル名のヘッダー -s を出力しません。 --sleep-interval=S を -f とともに使用して、各繰り返しの間隔を示します。

S 秒ごとにスリープする

例えば：

tail -n 10 test.log ログの最後にある最後の 10 行のログをクエリします。

tail -n +10 test.log 10 行以降のすべてのログをクエリします。

tail -fn 10 test.log レコードの最後の 1000 行をリアルタイムで表示するループ (最も一般的に使用されます)

一般に、次のように grep 検索と組み合わせて使用​​することもできます。

tail -fn 1000 test.log | grep 'キーワード'

1 回限りのクエリのデータ量が大きすぎる場合は、次のようにページをめくって表示できます。

tail -n 4700 aa.log |more -1000 複数の画面に表示可能 (ctrl + f またはスペースバーはショートカットキーでも可能)

2 、頭

tail の逆で、head はログが何行前にあるかを確認します。

head -n 10 test.log ログ ファイル内のログの最初の 10 行をクエリします。

head -n -10 test.log 最後の 10 行を除くすべてのログについてログ ファイルをクエリします。

頭の他のパラメータは尾を参照します

3 、猫

猫は最初の行から最後の行まで画面に連続して表示されます

ファイル全体を一度に表示するには:

$猫ファイル名

キーボードからファイルを作成します。

$cat > ファイル名

複数のファイルを 1 つにマージします。

$cat file1 file2 > file は新しいファイルの作成のみが可能で、既存のファイルは編集できません

あるログ ファイルの内容を別のログ ファイルに追加します。

Alibaba 内部データ $cat -n textfile1 > textfile2

ログ ファイルをクリアします。

$cat : >テキストファイル2

注: > は作成を意味し、>> は追加を意味します。混乱しないでください。

cat のその他のパラメータは尻尾を参照します

4 、もっと見る

more コマンドは、vi エディターに基づくテキスト フィルターです。テキスト ファイルの内容をページごとに全画面表示し、vi をサポートします。

のキーワード ターゲティング アクション。詳細リストにはいくつかのショートカット キーが組み込まれています。一般的に使用されるものは、H (ヘルプ情報を取得)、Enter (下方向) です。

1 行スクロール)、スペース (1 画面下にスクロール)、Q (コマンドを終了)。more コマンドはファイルを前から後ろに読み取るため、起動時に

ファイル全体をロードします。

このコマンドは、一度に 1 画面のテキストを表示し、画面がいっぱいになると停止し、画面の下部にプロンプ​​ト メッセージが表示され、これまでに表示されていたテキストが表示されます。

このファイルの割合: –More– (XX%)

more の構文: more filename

下 n 行を入力します。定義する必要があります。デフォルトは 1 行です

Ctrl f 1 画面下にスクロールします

スペースバーで 1 画面下にスクロールします

Ctrl b 前の画面に戻る

= 現在の行の行番号を出力します

:f 出力ファイル名と現在の行の行番号

v vi エディターを起動する

!コマンドはシェルを呼び出してコマンドを実行します。

もうやめてください

5 、シード

このコマンドは、ログ ファイルの特定のセクションを検索し、時間範囲に基づいてクエリを実行し、行番号と時間範囲に基づいてクエリを実行できます。

行番号ごとに

sed -n '5,10p' ファイル名なので、ファイルの 5 行目から 10 行目までしか表示できません。

期間ごとに

sed -n '/2014-12-17 16:17:20/,/2014-12-17 16:17:36/p' test.log

6 、以下

Ali 内部データのlessコマンドがログをクエリするときの一般的なプロセスは次のとおりです。

ログを減らします。ログ

Shift + G コマンドでファイルの最後まで移動し、? と入力します。検索したいキーワードを追加します。1213

nを押してキーワードを検索します

SHIFT+N 逆引きキーワード

Less は more に似ています。less ではファイルを自由に参照できますが、more では前方にのみ移動でき、後方には移動できません。また、less ではチェックが行われます。

表示する前にファイル全体がロードされるわけではありません。

log2013.log ビュー ファイルが少ない

ps -ef |less ps プロセス情報を表示し、少ないページングで表示します

履歴 | 少ない コマンド履歴の使用記録を表示し、少ないページネーションで表示します

以下 log2013.log log2014.log 複数のファイルを参照する

共通のコマンドパラメータ:

Less は more に似ています。less ではファイルを自由に参照できますが、more では前方にのみ移動でき、後方には移動できません。また、less ではチェックが行われます。

表示する前にファイル全体がロードされるわけではありません。

log2013.log ビュー ファイルが少ない

ps -ef |less ps プロセス情報を表示し、少ないページングで表示します

履歴 | 少ない コマンド履歴の使用記録を表示し、少ないページネーションで表示します

以下 log2013.log log2014.log 複数のファイルを参照する

共通のコマンドパラメータ:

-b <バッファ サイズ> バッファ サイズを設定します

-g 最後に検索されたキーワードのみにフラグを立てます

-検索時に大文字と小文字を無視します

-m は、more コマンドと同様のパーセンテージを表示します。

-N 各行の行番号を表示します

-o <filename> 指定したファイルにlessの出力を保存します。

-Q 警告音を使用しません

-s 連続した空白行を 1 行に表示します

/string: 「string」を下方検索する関数

?string: 「string」を上方向に検索する関数

n: 前の検索を繰り返します (/ または ? に関連)

N: 前の検索を逆方向に繰り返します (/ または ? を基準にして)

b 1ページ戻る

h ヘルプインターフェイスを表示します

q はlessコマンドを終了します

通常、アプリケーションの他のコマンドと連携するためにログを確認します

Ali 内部データ履歴 // すべての履歴記録

History | grep XXX // 履歴内の特定の命令を含むレコード

履歴 | 詳細 // ページビューの記録

History -c // すべての履歴をクリアします

!! 最後のコマンドを繰り返します

レコードをクエリした後、次を選択します: !323

動物園飼育員の記事

1. Zookeeperとは何ですか?

直訳：名前の直訳は動物の管理者です。動物はHadoopなどの分散ソフトウェアを指します。管理者の3文字が反映されています

ZooKeeper の特徴: 保守、調整、管理、監視。

簡単な説明:一部のソフトウェアをクラスター化または分散化したい場合は、ZooKeeper を使用してそれを実現できます。

特徴：

最終的な整合性: クライアントから見えるデータは最終的に整合性があります。

信頼性: サーバーはメッセージを保存するため、メッセージは常に存在します。

リアルタイム: ZooKeeper は、2 つのクライアントが新しく更新されたデータを同時に取得することを保証できません。

独立性 (待機は無関係): 異なるクライアントは相互に直接影響しません。

原子性: 更新は成功するか失敗するかのいずれかであり、3 番目の状態はありません。

注：面接の質問に答えるときは、一言で答えるのではなく、概念や特徴などについての理解を述べてください。

次に、たとえ完全に的を射ているとは思わなくても、それについて話すことができます。面接官はあなたの話を中断することを好みません。あなたの目的は、面接官に話してもらうことです。

警察官はあなたがコミュニケーション上手だと思っています。もちろん、知らないのに知ったかぶりして素人考えを言いすぎるのはやめましょう。

2. ZooKeeper のアプリケーション シナリオは何ですか?

データの公開とサブスクリプション

パブリッシュとサブスクライブはいわゆる構成管理であり、その名前が示すように、データを ZooKeeper ノードに公開して、サブスクライバーが動的に取得できるようにすることです。

構成情報の一元管理と動的な更新を実現するデータ。たとえば、グローバル構成情報、アドレスリストなどは、使用するのに非常に適しています。

使用。

Ali 内でのデータのパブリッシュ/サブスクライブの一般的なシナリオは、パブリッシャーが 1 つまたは一連の ZooKeeper にデータをパブリッシュする構成センターです。

ノード上で、サブスクライバーはデータを動的に取得する目的を達成するためにデータをサブスクライブできます。

構成情報には通常、次のようないくつかの特徴があります。

1.データ量が少ないKV

2. データ内容は実行時に動的に変更されます

3. クラスタマシンの共有、一貫した構成

ZooKeeper はプッシュとプルを組み合わせて使用​​します。

1. プッシュ: サーバーは、監視ノードに登録されているクライアントに Wathcer イベント通知をプッシュします。

2. プル: クライアントは通知を受け取ると、サーバーに積極的にアクセスして最新のデータをプルします。

ネーミングサービス

分散ネーミング サービスとしてのネーミング サービスは、ZooKeeper を使用して、指定された名前を通じてリソースまたはサービスのアドレスを取得することを指します。

クラスター内のクラスター、提供されるサービスのアドレス、または名前として使用できるグローバル パスを作成します。

またはリモートオブジェクトなど。

統一ネーミングサービスのネーミング構造図は以下のとおりです。

Ali 内部情報 1. 分散環境では、さまざまなサービスの識別を容易にするために、アプリケーション/サービスに統一した名前を付けることが必要になることがよくあります。

ドメイン名と IP の対応と同様に、IP は覚えにくいですが、ドメイン名は覚えやすいです。

リソースまたはサービスのアドレス、プロバイダー、およびその他の情報を名前で取得します。

2. サービス/アプリケーション名を階層構造で整理します。

サービス名とアドレス情報を ZooKeeper に書き込むことができ、クライアントは ZooKeeper を通じて利用可能なサービスのリストを取得できます。

構成管理

プログラムは別のマシンに分散およびデプロイされ、プログラムの構成情報は ZooKeeper の znode の下に配置されます。

変更するとき、つまり znode が変更されるとき、zk 内のディレクトリ ノードの内容を変更し、watch を使用して各ノードに通知することができます。

クライアントが設定を変更します。

ZooKeeper の構成管理構造図は次のとおりです。

1. 分散環境では、構成ファイルの管理と同期が一般的な問題になります。

Alibaba 内部データ Hadoop クラスターなどのクラスターでは、すべてのノードの構成情報が一貫しています。

構成ファイルが変更された後は、各ノードと迅速に同期できることが期待されます。

2. 構成管理は ZooKeeper によって実装できます。

構成情報は、ZooKeeper 上の Znode に書き込むことができます。

各ノードはこの Znode をリッスンします。

Znode 内のデータが変更されると、ZooKeeper は各ノードに通知します。

クラスタ管理

いわゆるクラスター管理とは、マシンの終了と参加の有無、およびマスターの選択です。

クラスタ管理とは主にクラスタ監視とクラスタ制御を指します。前者はクラスター ランタイムのステータスの収集に焦点を当てており、後者はクラスター ランタイムのステータスの収集に焦点を当てています。

クラスタを運用・制御します。開発および運用保守では、クラスターに直面して、次のような要件が発生することがよくあります。

1. クラスター内で動作しているマシンの数を知りたい

2. クラスター内の各マシンの実行時状態に関するデータを収集します。

3. クラスター内のマシン上でオンラインおよびオフライン操作を実行します。

クラスタ管理構造図は次のとおりです。

1. 分散環境では、各ノードの状態をリアルタイムで知る必要があり、ノードのリアルタイムの状態に応じていくつかの調整を行うことができます。

2. ZooKeeper で実装できます。

ZooKeeper 上の Znode にノード情報を書き込むことができます。

この Znode をリッスンして、リアルタイムのステータス変化を取得します。

3. 代表的な用途

アリの内部情報 Hbase でのマスター ステータスの監視と選択。

ZooKeeper の強力な一貫性を利用して、分散型の高い同時実行性の場合にノード作成のグローバルな一意性を保証できます。

複数のクライアントが /currentMaster ノードの作成を要求しますが、最終的に正常に作成できるクライアント要求は 1 つだけです

分散型通知と調整

1. 分散環境では、サービスが管理するサブサービスのステータスを知る必要があることがよくあります。

a) NameNode は各データノードのステータスを知る必要があります。

b) JobTracker は各 TaskTracker のステータスを知る必要があります。

2. ハートビート検出メカニズムは ZooKeeper を通じて実現できます。

3. 情報のプッシュは、パブリッシュ/サブスクライブシステムに相当する ZooKeeper によって実現できます。

分散ロック

異なるノード上の異なるサービスは、いくつかのリソースに順次アクセスする必要がある場合があり、ここでは分散ロックが必要です。

分散ロックには、書き込みロック、読み取りロック、タイミング ロックという特性があります。

書き込みロック: zk 上に作成された一時的な番号のないノード。順序のない番号であるため、作成時に自動的に番号が付けられず、結果として

クライアントがロックを取得してから書き込みできるようにすることはできますか。

読み取りロック: zk 上に一時的な番号付きノードを作成します。これにより、次回クライアントが参加しても、同じノードが同時に作成されます。

の場合、自動的に番号が付けられ、ロック オブジェクトを取得してそれを読み取ることもできます。

タイミング ロック: zk 上に作成された一時的な番号付きノードは、番号のサイズに応じてロックを制御します。

分散キュー

分散キューには 2 つのタイプがあります。

1. キューのメンバーがすべて集まるとキューは使用可能になりますが、それ以外の場合はすべてのメンバーが到着するのを待ちます。これは同期キューです。

リスト。

a) ジョブは複数のタスクで構成されており、すべてのタスクが完了した後でのみジョブが完了するまで実行されます。

b) ジョブの /job ディレクトリを作成し、このディレクトリ内に完了したタスクごとに一時 Znode を 1 回作成します。

一時ノードの数がタスクの総数に達すると、ジョブが完了したことを示します。

2. キューは、プロデューサー モデルとコンシューマー モデルの実装など、FIFO 方式に従ってエンキューおよびデキュー操作を実行します。

3. Zookeeperの動作原理について教えてください。

Zookeeper の中核はアトミック ブロードキャストであり、サーバー間の同期を保証します。このメカニズムを実装するプロトコルは次のように呼ばれます。

ザブ合意。

Ali 内部データ Zab プロトコルには、リカバリ モード (マスター選出) とブロードキャスト モード (同期) の 2 つのモードがあります。

Zab プロトコルの正式名は、Zookeeper Atomic Broadcast** (Zookeeper Atomic Broadcast) です。動物園の飼育員が合格しました

分散トランザクションの最終的な一貫性を確保するための Zab プロトコル。Zab プロトコルでは、各リーダーが次の 3 つの段階を経る必要があります。

ステップ、ブロードキャスト。

サービスが開始されるか、リーダーがクラッシュした後、Zab はリカバリ モードに入ります。リーダーが選出され、サーバーの過半数が選択されると、Zab はリカバリ モードに入ります。

リーダーとの状態同期が完了すると、リカバリーモードが終了します。状態の同期により、リーダーとサーバーが同じ状態になることが保証されます。

システムステータス。

トランザクションの逐次一貫性を確保するために、Zookeeper は増分トランザクション ID 番号 (zxid) を使用してトランザクションを識別します。すべての提案

(提案) は提案されたときにすべて zxid が追加されました。実装では、zxid は 64 ビットの数値であり、その上位 32 ビットがエポックに使用されます。

来标识leader关系是否改变，每次一个leader被选出来，它都会有一 个新的epoch，标识当前属于

那个leader的统治时期。低32位用于递增计数。

epoch：可以理解为皇帝的年号，当新的皇帝leader产生后，将有一个新的epoch年号。

每个Server在工作过程中有三种状态：

LOOKING：当前Server不知道leader是谁，正在搜寻。

LEADING：当前Server即为选举出来的leader。

FOLLOWING：leader已经选举出来，当前Server与之同步。

4，请描述一下 Zookeeper 的通知机制是什么？

Zookeeper 允许客户端向服务端的某个 znode 注册一个 Watcher 监听，当服务端的一些指定事件

触发了这个 Watcher ，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客

户端根据 Watcher 通知状态和事件类型做出业务上的改变。

大致分为三个步骤：

客户端注册 Watcher

1、调用 getData、getChildren、exist 三个 API ，传入Watcher 对象。 2、标记请求

request ，封装 Watcher 到 WatchRegistration 。 3、封装成 Packet 对象，发服务端发送

request 。 4、收到服务端响应后，将 Watcher 注册到 ZKWatcherManager 中进行管理。 5、

请求返回，完成注册。

服务端处理 Watcher

1、服务端接收 Watcher 并存储。 2、Watcher 触发 3、调用 process 方法来触发 Watcher 。

客户端回调 Watcher

1，客户端 SendThread 线程接收事件通知，交由 EventThread 线程回调Watcher 。 2，客户端

的 Watcher 机制同样是一次性的，一旦被触发后，该 Watcher 就失效了。

阿里内部资料client 端会对某个 znode 建立一个 watcher 事件，当该 znode 发生变化时，这些 client 会收

到 zk 的通知，然后 client 可以根据 znode 变化来做出业务上的改变等。

5， Zookeeper 对节点的 watch 监听通知是永久的吗？

不是，一次性的。无论是服务端还是客户端，一旦一个 Watcher 被触发， Zookeeper 都会将其从

相应的存储中移除。这样的设计有效的减轻了服务端的压力，不然对于更新非常频繁的节点，服务

端会不断的向客户端发送事件通知，无论对于网络还是服务端的压力都非常大。

6， Zookeeper 集群中有哪些角色？

在一个集群中，最少需要 3 台。或者保证 2N + 1 台，即奇数。为什么保证奇数？主要是为了选举

算法。

7， Zookeeper 集群中Server有哪些工作状态？

LOOKING

寻找 Leader 状态；当服务器处于该状态时，它会认为当前集群中没有 Leader ，因此需要进入

Leader 选举状态

FOLLOWING

跟随者状态；表明当前服务器角色是 Follower

LEADING

领导者状态；表明当前服务器角色是 Leader

OBSERVING

观察者状态；表明当前服务器角色是 Observer

阿里内部资料8， Zookeeper 集群中是怎样选举leader的？

当Leader崩溃了，或者失去了大多数的Follower，这时候 Zookeeper 就进入恢复模式，恢复模式需

要重新选举出一个新的Leader，让所有的Server都恢复到一个状态LOOKING 。

Zookeeper 有两种选举算法：基于 basic paxos 实现和基于 fast paxos 实现。默认为 fast paxos

由于篇幅问题，这里推荐：选举流程

9， Zookeeper 是如何保证事务的顺序一致性的呢？

Zookeeper 采用了递增的事务 id 来识别，所有的 proposal （提议）都在被提出的时候加上了

zxid 。 zxid 实际上是一个 64 位数字。

高 32 位是 epoch 用来标识 Leader 是否发生了改变，如果有新的 Leader 产生出来， epoch 会自

增。 低 32 位用来递增计数。 当新产生的 proposal 的时候，会依据数据库的两阶段过程，首先会

向其他的 Server 发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始

执行。

10， ZooKeeper 集群中个服务器之间是怎样通信的？

Leader 服务器会和每一个 Follower/Observer 服务器都建立 TCP 连接，同时为每个

Follower/Observer 都创建一个叫做 LearnerHandler 的实体。

LearnerHandler は主に、データの同期を含む、リーダーとフォロワー/オブザーバー間のネットワーク通信を担当します。

転送依頼、議案採決等

リーダー サーバーは、すべてのフォロワー/オブザーバーの LearnerHandler を保存します。

11. ZooKeeper分散ロックはどのように実装されていますか?

Zookeeper 分散ロックをめぐって競合する N 個のクライアント (クライアント 1 とクライアント 2 など) が存在する場合。おおよそ次のとおりです。

1. 全員が立ち上がり、ロックノードの下に一時的に順序付けされたノードを次々と直接作成します

2. 最初のノードではない場合は、前のノードにリスナーを追加します

3. 前のノードがロックを解放している限り、そのノードは先頭にキューイングされます。これはキューイング メカニズムと同等です。

Ali の内部データと一時シーケンシャル ノードを使用するもう 1 つの目的は、一時シーケンシャル ノードを作成した後にクライアントが誤ってクラッシュした場合に備えられることです。

クライアントがダウンしているかどうかは問題ではありません。Zookeeper は、クライアントがダウンしていることを感知すると、対応する一時シーケンス ノードを自動的に削除します。これは、自動的に削除するのと同じです。

ロックを解放するか、独自のキューを自動的にキャンセルします。

ローカル ロックは JDK を使用して実装できますが、分散ロックは分散コンポーネントを使用する必要があります。ZooKeeper、Redis など。

オンライン コードのセクションは大きく、インタビューは通常書かれていません。いくつかの重要なポイントについてお話します。

注意点としては以下のようなものが挙げられます。

デッドロック問題: 事故によりロックがデッドロックになるはずがないため、ZK の一時ノードを使用し、クライアント接続に失敗するとロックがかかります。

自動的に解放されます。

ロック待機の問題: ロックにはキューイング要件があるため、ZK の順次ノードが必要です。

ロック管理の問題: ユーザーがロックを解除すると、他のユーザーに通知する必要があるため、監視が必要です。

モニタリングの集団効果: たとえば、ロックの競合者が 1000 人いて、ロックが解除された場合、1000 人の競合者に通知され、その後判定されます。

最終的に、シリアル番号が最も小さいものがロックを取得しました。他の 999 人の競技者は、聞くために再登録します。これが群集効果です、指摘してください

何かが起こると、群れ全体が警戒するでしょう。各競技者は自分の前のノードのみを監視する必要があります。たとえば、No.2 がロックを解除すると、

したがって、3番目のみが通知されました。

12. Zookeeperのシステム アーキテクチャを理解していますか?

ZooKeeper アーキテクチャ図を理解して習得する必要がある主な事項は次のとおりです。

(1) ZooKeeperはサーバーサイド(Server)に分かれています

クライアント（Client）とは、クライアント全体に接続できる

ZooKeeper がサービスを提供するサーバー上 (leaderServes パラメーターが明示的に設定されていない限り、リーダーはクライアントを受け入れることができません)

接続）。

(2) クライアントは、リクエストの送信、応答の受信、監視されたイベントの取得、および

ハートビートを送信します。この TCP 接続が切断されると、クライアントは自動的に別の ZooKeeper サーバーへの接続を試みます。クライアント

ZooKeeper サービスに初めて接続するとき、接続を受け入れる ZooKeeper サーバーはクライアントのセッションを確立します。

話。クライアントが別のサーバーに接続すると、セッションは新しいサーバーによって再確立されます。

(3) 上図の各サーバーは、Zookeeper サービスがインストールされたマシン、つまり Zookeeper サービスのセット全体を表します。

クラスター (または擬似クラスターで構成される)。

(4) ZooKeeper サービスを構成するサーバーは相互に認識している必要があります。メモリ内の状態イメージと永続的なイメージを維持します。

ストレージ内のトランザクション ログとスナップショット、

ZooKeeper サービスは、サーバーの大部分が利用可能な限り利用できます。

アリの内部情報 (5) ZooKeeper が起動すると、インスタンスからリーダーが選出され、リーダーがデータ更新などの処理を担当します。

更新操作が成功したという兆候は、ほとんどのサーバーがメモリ内のデータを正常に変更した場合に限ります。各サーバーはメモリに保存します

データの一部。

(6) Zookeeper はクラスター内で複製でき、クラスター間の Zab プロトコル (Zookeeper Atomic Broadcast) を使用して、

データの一貫性を維持する。

(7) Zab プロトコルは、リーダー選出フェーズとアトミック ブロードキャスト フェーズの 2 つのフェーズで構成されます。

a) クラスター内でリーダーが選出され、他のマシンはフォロワーと呼ばれ、すべての書き込み操作がクラスターに送信されます。

リーダーとして、すべての最新情報をブロードキャストを通じてフォロワーに伝えます。

b) リーダーが崩壊するか、リーダーがほとんどのフォロワーを失った場合、全員が安心できるように新しいリーダーを再選する必要があります。

一部のサーバーは正しい状態に復元されます。

c) リーダーが選出され、ほとんどのサーバーがリーダーとの状態同期を完了すると、リーダーの選出が行われます。

プロセスが終了し、Atomic ブロードキャストのプロセスに入ります。

d) アトミック ブロードキャストは、リーダーとフォロワーの間で情報を同期し、リーダーとフォロワーが同じシステムを持っていることを保証します。

州。

13. Zookeeper はなぜこのように設計されているのですか?

ZooKeeper 設計の目的は、高性能、高可用性、逐次一貫性のある分散調整サービスを提供し、データの最終的な一貫性を確保することです。

セックス。

高性能 (シンプルなデータモデル)

1. データノードをツリー構造に編成します。

2. すべてのデータノードはメモリに保存されます。

3. フォロワーとオブザーバーは非トランザクション要求を直接処理します。

高可用性 (クラスターの構築)

1. マシンの半数以上が生き残れば、サービスは正常に実行できます。

2. リーダーの自動選出

逐次整合性（トランザクション操作の順序）

1. 各トランザクションリクエストは、処理のためにリーダーに転送されます。

2. 各トランザクションには、グローバルに一意の増分 ID (zxid、64 ビット: エポック + 自動増分 ID) が割り当てられます。

最終的な整合性

1. 議決権行使の提案により取引提出の信頼性を確保する

2. 提案された投票方法では、クライアントがトランザクションの正常な送信を受信した後にのみ、ノードの半分以上が最新のデータを参照できるようにすることができます。

14. Zookeeperではどのような役割があるか知っていますか?

アリババの内部データ システム モデル:

リーダー

リーダー サーバーは、クライアントに読み取りおよび書き込みサービスを提供します。投票の開始と解決、およびシステムステータスの更新を担当します。

学習者

フォロワー (フォロワー) フォロワー サーバーは、クライアントに読み取りサービスを提供し、リーダー選出プロセスに参加し、書き込み操作に参加します。

「半分以上の書き込みが成功する」戦略を実行します。

オブザーバー (オブザーバー) オブザーバー サーバーはクライアントに読み取りサービスを提供しますが、リーダー選出プロセスには参加しません。

書き込み操作「書き込みの半分以上が成功する」戦略。これは、書き込みパフォーマンスに影響を与えることなく、クラスターの読み取りパフォーマンスを向上させるために使用されます。

クライアント (クライアント): サービス リクエストの開始者。

15. ZookeeperノードZNodeと関連する属性についてご存知ですか?

どのようなタイプのノードがありますか?

Znode には 2 つのタイプがあります。

永続的: クライアントとサーバーが切断された後、作成されたノードは削除されません (デフォルト)。

エフェメラル: クライアントとサーバーが切断された後、作成されたノードは自動的に削除されます。

Znode には 4 つの形式があります。

永続ディレクトリ ノード (PERSISTENT): クライアントが Zookeeper から切断した後も、ノードはまだ存在します。

連番ディレクトリノード(PERSISTENT_SEQUENTIAL)

クライアントが Zookeeper から切断した後もノードはまだ存在しますが、Zookeeper はノードの名前を順序付けしました。

No.: テンポラリディレクトリノード(EPHEMERAL)

クライアントが Zookeeper から切断されると、ノードが削除されます: 一時シーケンス番号ディレクトリ ノード

（エフェメラル_シークエンシャル）

クライアントが Zookeeper から切断された後、ノードは削除されますが、Zookeeper はノード名に連続番号を付けます。

「注意」 : ZNode の作成時にシーケンス識別子を設定します。値は ZNode 名に追加され、シーケンス番号は単調増加するカウントです。

カウンタは親ノードによって維持されます。

アリババの内部データノードの属性は何ですか?

znode ノードはデータを保存できるだけでなく、その他の特別なプロパティも持つことができます。次に、/test ノード分析を作成します。

それぞれの属性の意味を見てみましょう。

[zk: localhost:2181(CONNECTED) 6] get /test

456

cZxid = 0x59ac //

ctime = 月 3 月 30 日 15:20:08 CST 2020

mZxid = 0x59ad

mtime = 2020 年 3 月 30 日月曜日 15:22:25 CST

pZxid = 0x59ac

バージョン = 0

データバージョン = 2

aclバージョン = 0

ephemeralOwner = 0x0

データ長 = 3

子供の数 = 0

プロパティの説明

16. Zookeeperのマスター選択プロセスについて簡単に説明してください

Ali 内部データ Zookeeper の中核は、サーバー間の同期を保証するアトミック ブロードキャストです。このメカニズムを実装するプロトコルは次のように呼ばれます。

ザブ合意。Zab プロトコルには、リカバリ モード (マスター選出) とブロードキャスト モード (同期) の 2 つのモードがあります。サービス開始時、または

または、リーダーがクラッシュした後、リーダーが選出され、ほとんどのサーバーがリカバリ モードを完了すると、Zab はリカバリ モードに入ります。

リーダーの状態が同期されると、リカバリ モードが終了します。状態の同期により、リーダーとサーバーのシステム状態が同じになることが保証されます

州。リーダーの選出は、分散データの一貫性を確保するための鍵となります。

選挙には 2 つの主なシナリオがあります。それは、初期化とリーダーの不在です。

zk クラスター内のサーバーで次の 2 つの状況のいずれかが発生すると、リーダーの選出が開始されます。

(1) サーバが初期化され、起動されます。

(2) サーバ稼働中はリーダーとの接続を維持できません。

マシンがリーダー選出プロセスに入ると、現在のクラスターは次の 2 つの状態になる場合もあります。

(1) クラスター内に既にリーダーが存在します。

(2) 確かにクラスター内にリーダーは存在しません。

まず、最初のケースでは、通常、クラスター内の特定のマシンが比較的遅く起動しますが、起動する前は、クラスターは正常に動作していました。

リーダーサーバーはすでに存在します。マシンがリーダーを選出しようとすると、現在のサーバーのリーダー情報が通知されます。

リーダーマシンとの接続を確立し、状態の同期を行うだけで済みます。

重要な点は、リーダーが不在であることと、現時点でのリーダー選択システムであることです。

投票情報には 2 つの基本情報が含まれます。

sid: クラスター内のマシンのシリアル番号を識別するために使用されるサーバー ID。

zxid: Zookeeper のトランザクション ID 番号。

ZooKeeper の状態のすべての変更は、zxid と呼ばれるインクリメントされたトランザクション ID に対応します。

増分プロパティ。zxid1 が zxid2 より小さい場合、zxid1 は zxid2 より前に出現する必要があります。任意のノードを作成するか、任意のノードを更新します

データ、

または、ノードを削除すると Zookeeper の状態が変化し、zxid の値が増加します。

投票情報は(sid,zxid)の形式で識別されます。

たとえば、現在のサーバーが sid が 1、zxid が 8 のサーバーをリーダーとして推奨したい場合、投票情報は次のように表現できます。

（1，8）

クラスター内の各マシンは独自の投票を送信した後、クラスター内の他のマシンからの投票も受け入れます。各マシンは、

指定されたルールに従って、他のマシンから受け取った投票を処理し、自身の投票を変更するかどうかを決定します。

ルールは次のとおりです。

(1) 初期段階では全員が自分に投票します。

(2) 他のサーバーから投票を受け取る場合は、他のサーバーの投票と自分の投票を組み合わせる必要があります。

アリババ内部データノード

シド

サーバー1

1

サーバー2

2

サーバー3

3

まずzxidを確認してください。zxid が大きいサーバーがリーダーとして優先されます。zxid が同じ場合は、sid が大きい方の sid を比較します。

サーバーはリーダーとして機能します。

すべてのサービスが開始されるときの選択プロセス:

3 つのサーバー、server1、server2、server3:

1.server1 が起動しますが、マシンは選択されません。

2. サーバー 2 を起動し、サーバー 1 とサーバー 2 のステータスを検索中、ブロードキャスト投票に変更します。

3. Server3 が起動し、状態が looking に変わり、ブロードキャスト投票に参加します。

4. 初対面の状態では、誰もがお互いのことを知りませんので、誰もが自分を王様だ​​と思い、自分をリーダーとして投票します。

5. 投票情報の説明 投票情報は本来 5 つのタプルですが、ここでは論理を明確にするために式を簡略化しています。

初回は zxid = 0 で、sid は各ノードの名前です。この sid はzoo.cfg で設定されており、繰り返されません。

1. 初期 zxid=0、server1 投票 (1, 0)、server2 投票 (2, 0)、server3 投票 (3, 0)

2. サーバー 1 が投票 (2, 0) を受け取ると、まず投票の正当性を検証し、次に自身の投票を pk します。pk のロジックは次のとおりです。

まず zxid、server1 (zxid) = server2 (zxid) = 0、zxid が等しいと比較し、次に sid、server1 (sid) < を比較します。

server2(sid), pk 結果は、server2 の投票が勝利します。サーバー 1 は投票を (2, 0) に更新します。サーバー 1

再投票してください。

3. TODO ここで最終的に 2 になるか 3 になるかは実験によって決定する必要があります。

4. サーバー 2 がサーバー 1 から投票を受け取ると、最初に投票の正当性を検証し、次に pk を実行すると、自身の投票が勝ちとなり、サーバーを更新する必要はありません。

新しい自分の投票、PK の後、投票を再送信します。

5. 投票を数えます pk 後、投票が行われ、半数以上のノードが同じ票を投じた場合、リーダーが選出されたと判断されます。

6. 選挙が終了すると、選択したノードのステータスが LO​​OKING から LEADING に変わり、選挙に参加している他のノードのステータスも LOOKING から LEADING に変わります。

は次のようになります。オブザーバー ノードが存在する場合、オブザーバーが選挙に参加しない場合は、

ステータスは監視中ですが、変化はありません。

一般的に言えば

投票を開始 -> ノードのステータスが LO​​OKING になる -> 各ノードが自ら選択 -> PK の投票を受け取る -> big sid が勝利 -> 更新

投票 -> 再度投票 -> 投票を数え、半分以上の投票での選挙結果 -> ノードのステータスが独自のロール ステータスに更新されます。

17. Zookeeperクラスターの数が一般的に奇数なのはなぜですか?

Ali の内部情報では、まず飼育員の選出ルールを明確にする必要があります。リーダーの選出には、利用可能なノードの数 > ノードの合計数 / 2 が必要です。

例: 書き込みが成功したかどうかのマーク付けは、半分以上のノードが書き込みリクエストを正常に送信した場合にのみ有効とみなされます。同じく動物園の飼育員さん

リーダーノードの選択も、半数以上のノードが同意した場合にのみ有効となります。最後に、Zookeeper が正常かどうかは、次の値を超えるかどうかによって決まります。

ノードの半分は正常とみなされます。これは CAP の一貫性原則に基づいています。

Zookeeper には、クラスター内のマシンの半分以上が正常に動作している限り、クラスター全体が外部から利用できるという機能があります。

の。

つまり、飼育員が 2 人いる場合、1 人の飼育員が死亡している限り、その飼育員は使用できません。1 人は半分以下であるため、

2 人の飼育員の死亡耐性は 0 です。

同様に、飼育員が 3 人いた場合、1 人が死亡し、通常の飼育員が 2 人、半分以上残っているため、飼育員 3 人の許容範囲は次のようになります。

は 1;

同じやり方で：

2->0; 2 人の飼育員、最大 0 人の飼育員が利用できなくなります。

3->1; 飼育員は 3 人ですが、最大 1 人の飼育員が不在になる可能性があります。

4->1; 飼育員は 4 人ですが、最大 1 人の飼育員が不在になる可能性があります。

5->2; 5 人の飼育員、最大 2 人の飼育員が利用できない場合があります。

6->2; 2 人の飼育員、最大 0 人の飼育員が利用できない場合があります。

....

2n と 2n-1 の許容差は同じであり、両方とも n-1 であるというルールが見つかります。効率を高めるために、なぜそうでない方を追加するのでしょうか。

必要な飼育員はどうでしょうか。

Zookeeper の選挙戦略では、リーダーに選出されるには半数以上のノードの同意が必要です。ノード数が偶数の場合、投票につながる可能性があります。

同じ件数です。

18. Zookeeperリスナーの原理をご存知ですか?

1. Main() スレッドを作成します。

2. Main() スレッドに 2 つのスレッドを作成します。1 つはネットワーク接続通信 (connect) を担当し、もう 1 つは監視を担当します。

（リスナー）。

Ali 内部情報 3. 登録されたリスニング イベントを接続スレッドを通じて Zookeeper に送信します。

4. 将注册的监听事件添加到Zookeeper的注册监听器列表中。

5. Zookeeper监听到有数据或路径发生变化时，把这条消息发送给Listener线程。

6. Listener线程内部调用process()方法

19、说说Zookeeper中的ACL 权限控制机制

UGO（User/Group/Others）

目前在 Linux/Unix 文件系统中使用，也是使用最广泛的权限控制方式。是一种粗粒度的文件系统权

限控制模式。

ACL（Access Control List）访问控制列表

包括三个方面：

权限模式（Scheme）

（1）IP：从 IP 地址粒度进行权限控制

（2）Digest：最常用，用类似于 username:password 的权限标识来进行权限配置，便于区分不同

应用来进行权限控制

（3）World：最开放的权限控制方式，是一种特殊的 digest 模式，只有一个权限标

识“world:anyone”

（4）Super：超级用户

授权对象

授权对象指的是权限赋予的用户或一个指定实体，例如 IP 地址或是机器灯。

权限 Permission

（1）CREATE：数据节点创建权限，允许授权对象在该 Znode 下创建子节点

（2）DELETE：子节点删除权限，允许授权对象删除该数据节点的子节点

（3）READ：数据节点的读取权限，允许授权对象访问该数据节点并读取其数据内容或子节点列表

等

（4）WRITE：数据节点更新权限，允许授权对象对该数据节点进行更新操作

（5）ADMIN：数据节点管理权限，允许授权对象对该数据节点进行 ACL 相关设置操作

20、Zookeeper 有哪几种几种部署模式？

Zookeeper 有三种部署模式：

阿里内部资料1. 单机部署：一台集群上运行；

2. クラスター展開: 複数のクラスターが実行されます。

3. 擬似クラスター展開: クラスターは複数の Zookeeper インスタンスを起動して実行します。

21. Zookeeperクラスターはマシンの動的な追加をサポートしていますか?

実はこれは水平展開であり、Zookeeperはこの点があまり得意ではありません。ふたつのやり方：

すべて再起動: すべての Zookeeper サービスを閉じ、構成を変更した後に開始します。以前のクライアント セッションは影響を受けません。

1 つずつ再起動する: マシンの半分以上が稼働しており利用可能であるという原則に基づき、マシンを再起動しても、クラスター全体が提供する外部サービスには影響しません。これはより一般的です

あなたの使い方。

バージョン 3.5 では、動的拡張のサポートが開始されました。

22. ZABプロトコルについて説明する

ZABプロトコルはZooKeeper自身が定義したプロトコルであり、正式名称はZooKeeperアトミックブロードキャストプロトコルといいます。

ZABプロトコルには 2 つのモードがあります。リーダー ノードがクラッシュしたときに回復する方法と、すべてのノードにメッセージをブロードキャストする方法です。

ZooKeeper クラスター全体にリーダー ノードがない場合、クラッシュが発生します。たとえば、この時点ではクラスターの起動が開始されたばかりです。

点はお互いを知りません。たとえば、リーダー ノードの動作がダウンしているか、ネットワークに問題があり、他のノードがリーダー ノードに ping を送信できないとします。

クリックされました。このとき、ZAB のノード崩壊プロトコルが必要となり、すべてのノードが新しいリーダーを選出するために選出モードに入ります。選挙全体

リフティングプロセスは放送を通じて実現されます。選挙が成功した後は、すべてがリーダーのデータに基づいている必要があるため、

データは同期されています。

23. ZABとPaxosアルゴリズムの関係と違いは何ですか?

同じ点：

(1) どちらもリーダー プロセスと同様の役割を持ち、複数のフォロワー プロセスの動作を調整する責任があります。

(2) リーダー プロセスは、提案を送信する前に、フォロワーの半数以上が正しいフィードバックを提供するのを待ちます。

(3) ZAB プロトコルでは、各プロポーザルには現在のリーダー期間を表すエポック値と Paxos での名前が含まれます。

投票用紙の言葉

違い：

ZAB は可用性の高い分散データのプライマリおよびバックアップ システム (Zookeeper) を構築するために使用され、Paxos は分散された一貫した状態を構築するために使用されます。

マシンシステム。

24. ZooKeeper のダウンタイムにどう対処するか?

ZooKeeper 自体もクラスターなので、奇数のサーバーを構成することをお勧めします。ダウンタイムのため選挙が必要であり、選挙の半分には +1 票が必要です。

同点を避けるためにパスすることができます。偶数のサーバーを持たずに参加してください。

Ali の内部情報がフォロワーがダウンしているというものであれば、それは問題ではなく、使用には影響しません。ユーザーは気づいていません。リーダーがダウンした場合、クラスターは停止する必要があります

外部サービス。選出を開始します。リーダー ノードを選出した後、データ同期を実行して、すべてのノード データとリーダーの一貫性が確保されるようにします。

1つは、その後、外部の世界にサービスを提供し始めました。

なぜ投票には半分 + 1 が必要なのでしょうか? 半分で十分な場合、ネットワークの問題により、クラスターがそれぞれ 2 人のリーダーを選出する可能性があります。

弟の半分がサポートしてるのでデータがめちゃくちゃになってしまいます。

25. ZooKeeperのセッション管理の考え方について説明してください。

バケット戦略:

簡単に言えば、さまざまなセッションの有効期限には、15 秒の有効期限、15.1 秒の有効期限、15.8 秒の有効期限などの時間間隔がある場合があります。

ZooKeeper はこれらのセッションを一律 16 秒で期限切れにします。これは管理上非常に便利です。以下の式を見てください。有効期限は常に有効です。

ExpirationInterval の整数倍。

計算式：

ExpirationTime = currentTime + sessionTimeout

ExpirationTime = (ExpirationTime / ExpirationInrerval + 1) * ExpirationInterval 、

画像を参照してください:

デフォルトで設定されているセッション タイムアウトは 2tickTime ～ 20tickTimeです。

26. ZooKeeper の負荷分散とNginxの負荷分散の違いは何ですか?

動物園の飼育員：

単一点の問題はなく、zab メカニズムにより、単一点障害が発生してもリーダーを再選出できます。

サービスの登録と検出のみを担当し、転送は担当せず、データ交換 (消費者とサーバー間の直接通信) を削減します。

対応する負荷分散アルゴリズムを自分で実装する必要があります

Aliの内部情報Nginx ：

単一点の問題があり、単一点の負荷が高く、データ量が大きいため、高可用性を実現するには KeepAlived による支援が必要です。

各ロードは中間転送の役割として機能し、それ自体がリバース プロキシ サーバーになります。

組み込みの負荷分散アルゴリズム

27. ZooKeeperの連載について語る

シリアル化:

メモリデータはハードディスクに保存する際にシリアル化する必要があります。

ネットワークを通じて他のノードに送信されるメモリ データはシリアル化する必要があります。

ZK で使用されるシリアル化プロトコルは Jute で、Record インターフェイスを提供します。このインターフェイスには 2 つのメソッドが用意されています。

シリアル化メソッド

deserialize 逆シリアル化メソッド

この 2 つのメソッドでは、シリアル化するメソッドをストリーム オブジェクトに格納できます。

28. Zookeeper の Zxid とは何ですか?またその機能は何ですか?

Zxid はトランザクション ID です。トランザクションの逐次一貫性を確保するために、ZooKeeper は増分トランザクション Zxid を使用してトランザクションを識別します。

サービス。Zxid が提案に追加されます。Zxid は 64 ビットの数値で、その上位 32 ビットは Epoch によって王朝の変更を識別するために使用されます。

たとえば、選挙エポックごとに変更されます。下位 32 ビットはカウントアップに使用されます。

Epoch: 現在のクラスターの年齢または周期として理解できます。各リーダーは皇帝のようなもので、独自の年番号を持っています。

王朝が変わるごとに、リーダーが変わった後、前の時代に1が追加されます。これで旧リーダーがクラッシュしても

回復後は、フォロワーは現在の時代のリーダーの命令にのみ従うため、もう誰もそれを聞きません。WeChatの公開にご注目ください

公開番号: Java バックエンド テクノロジ フルスタック

29. ZooKeeperの永続化メカニズムを説明する

持続性とは何ですか?

ディスクまたはファイルに保存されたデータ。

マシンの再起動後、データは失われません。メモリ -> ディスクのマッピングはシリアル化に似ています。

ZooKeeperの永続性:

SnapShot スナップショット、メモリ内の全データを記録

TxnLog 増分トランザクション ログ。各追加、削除、および変更レコードを記録します (チェックはトランザクション ログではないため、データ変更は発生しません)

永続化はなぜこんなに面倒なのですか?

スナップショットの欠点は、ファイルが大きすぎるため、スナップショット ファイルが最新のデータではなくなることです。増分トランザクション ログの欠点は、実行に時間がかかることです。

ログが多すぎるため、読み込みが遅すぎます。この 2 つを組み合わせると最も効果的です。

Alibaba 内部データスナップショット モード:

DataTree データ構造内の ZooKeeper メモリに保存されているデータは、定期的にディスクに保存されます。

スナップショット ファイルはデータの定期的な完全バックアップであるため、通常、スナップショット ファイル内のデータは最新ではありません。

画像を参照してください:

30.動物園飼育員選挙における投票情報の 5 つのタプルとは何ですか?

リーダー: 選出されたリーダーの SID

Zxid: 選出されたリーダーのトランザクション ID

Sid: 現在のサーバーの SID

選挙エポック: 現在の投票ラウンド

peerEpoch: 現在のサーバーのエポック

エポック > Zxid > シド

Epoch と Zxid は同じかもしれませんが、Sid は違うはずなので、2 票の結果は確実に PK になります。

31. Zookeeperのスプリット ブレインについて教えてください。

簡単に言うと、スプリット ブレインとは、たとえば、クラスター内に 2 つのノードがある場合、両方のノードがこれを認識します。

クラスター内でマスターを選択する必要があります。そして、二人の意思疎通に問題がなければ、合意が得られます。

知識がある場合は、そのうちの 1 つをマスターとして選択します。しかし、それらの間の通信に問題がある場合、両方のノードは問題がないと感じます。

マスターが 1 つあるため、それぞれが自分自身をマスターとして選択するため、クラスター内に 2 つのマスターが存在することになります。

アリの内部情報は、ノードの死をどのような状況で判断するかという動物園飼育員にとって非常に重要な問題を抱えています。

下？分散システムではこれらをすべてモニタが判断しますが、モニタが他のノードの状態を判断することも困難です。

状態にある場合、信頼できる唯一の方法はハートビートです。Zookeeper もハートビートを使用して、クライアントがまだ生きているかどうかを判断します。

ZooKeeper を使用してリーダー HA を実行する方法は基本的に同じです。各ノードは一時的なリーダー シンボルの登録を試みます。

正常に登録されなかったノードなどはフォロワーになり、リーダーによって作成された一時ノードを監視メカニズムを通じて監視します。

Zookeeper は内部のハートビート メカニズムを使用してリーダーのステータスを判断し、リーダーに事故が発生すると、Zookeeper はすぐに学習して対応できます。

他のフォロワーに通知すると、後で他のヒマワリが応答し、切り替えが完了します。このモードも同様です

より一般的なモードは基本的にこの方法で実装されます。しかし、ここには非常に深刻な問題があり、気づかないと、

ハートビート タイムアウトはリーダーのハングによって発生する可能性がありますが、Zookeeper ノードによっても発生する可能性があるため、短期間でシステムはスプリット ブレインになります。

ノード間のネットワークに問題があり、リーダーが誤って死亡したように見えます。リーダーは実際には死んでいませんが、ZooKeeper との関係が原因です。

ネットワークに問題があると、Zookeeper はネットワークがダウンしていると判断し、他のノードに切り替えるように通知します。

リーダーになりましたが、元のリーダーは死んでいません。このとき、クライアントにもリーダー交代の知らせが届きますが、まだ

多少の遅延が発生し、飼育員は通信する必要があり、1 つずつ通知を受ける必要があります。現時点では、システム全体が非常に混乱しています。おそらく、一部のクライアントはすでに

新しいリーダーに接続するように通知された後、同時に 2 つのクライアントが存在する場合、一部のクライアントは依然として古いリーダーに接続されます。

リーダーの同じデータを更新する必要があり、この時点で 2 つのクライアントがそれぞれ新旧のリーダーに接続されていることが起こり、次のように表示されます

非常に深刻な問題です。

以下に簡単な概要を示します。

死のふり: リーダーはハートビート タイムアウト (ネットワーク上の理由による) により死亡したと見なされますが、リーダーはまだ生きています。

と。スプリットブレイン: 仮死状態のため、新しいリーダーを選出するために新リーダー選挙が開始されますが、古いリーダーのネットワークは再び接続されます。

その結果、2 つのリーダーが存在し、一部のクライアントは古いリーダーに接続し、一部のクライアントは新しいリーダーに接続します。

32.動物園飼育員のスプリットブレインの原因は何ですか?

主な理由は、タイムアウトを判断するときに Zookeeper クラスターと Zookeeper クライアントが完全に同期できないことです。

その後、クライアントよりも先にクラスターが検出された場合、上記の状況が発生します。同時に、検出と切り替え後に各クライアントに通知されます。

速度の順序もあります。一般に、この状況が発生する可能性は非常に低いため、リーダー ノードを Zookeeper クラスター ネットワークから切断する必要がありますが、

他のクラスタロール間のネットワークには問題はなく、上記の条件を満たす必要がありますが、一度発生すると重大な結果を引き起こす可能性があります。

その結果、データに不整合が生じます。

33. Zookeeper はスプリット ブレイン問題をどのように解決しますか?

スプリットブレインの問題を解決するには、一般的に次のような方法があります。 クォーラム（定足数）方式：例えば3ノード

クラスターでは、クォーラム = 2、つまり、クラスターは 1 つのノードの障害を許容できます。この時点で、1 つのリーダーを選出でき、クラスターは引き続き実行できます。

利用可能。たとえば、4 つのノードを持つクラスターの場合、そのクォーラム数は 3 であり、クォーラム数は 3 を超える必要があります。これは、クラスターの許容値が 1 のままであることに相当します。

2 つのノードに障害が発生した場合でも、クラスター全体は無効のままです。これは、動物園の飼育員が「スプリット ブレイン」を防ぐために使用するデフォルトの方法です。

冗長通信（冗長通信）モード：クラスタ内で複数の通信モードを使用し、通信モードが1つになることを防ぎます。

障害が発生すると、クラスター内のノードが通信できなくなります。

フェンシング（共有リソース）方式：例えば、共有リソースが見えればクラスタ内にあることを意味し、共有リソースのロックを取得できます。

リーダーが共有リソースを認識できない場合、そのリソースはクラスター内にありません。

アリの内部情報は、飼育員の「スプリット ブレイン」状況を回避するために、実際には非常にシンプルであり、フォロワー ノードが切り替わると、古いリーダー セクションはチェックされなくなります。

問題が発生したらすぐに切り替えますが、古いリーダーに変更が通知され、関連する変更が加えられたことを確認するために十分な時間スリープします。

シャットダウンのクリーンアップ作業を行ってからマスターとして登録することで、この種の問題を回避できます。このスリープ時間は通常、スリープ時間と同じように定義されます。

動物園管理者によって定義されたタイムアウト期間は十分ですが、この期間中はシステムが利用できなくなる可能性がありますが、データに関しては一貫性がありません。

結果を考えるとそれだけの価値があります。

1. ZooKeeper は、「スプリット ブレイン」現象を防ぐためにデフォルトでクォーラムを採用します。つまり、クラスタ内の半分以上のノードのみが投票します。

リーダーを選出するため。この方法により、唯一のリーダーを選出するか、選出が失敗するかのいずれかで、リーダーの一意性を確保できます。

敗北。飼育員における定足数の役割は次のとおりです。

クラスター内のノードの最小数は、クラスターが確実に使用できるようにリーダーを選出するために使用されます。

データが安全に保存される前に、クラスター内の最小数のノードによってデータが保存されたことをクライアントに通知します。これらのノードが維持されると、

データを保存すると、クライアントにはデータが安全に保存されたことが通知され、他のタスクを続行できるようになります。一方、クラスター内の残りのノードは

そのデータも最終的には保存されます。

リーダーが仮死状態で死亡した場合、残りの信者が新しいリーダーを選出します。このとき、かつての指導者は復活し、依然として

自分自身をリーダーとみなし、この時点では、他のフォロワーに書き込みリクエストを送信するときも拒否されます。なぜなら、新しいリーダーが誕生するたびに、

それが誕生すると、エポックラベルが生成され（リーダーの現在の統治期間を示します）、このエポックはインクリメントされます。

フォロワーが新しいリーダーの存在を確認し、そのエポックを知っている場合、現在のリーダーのエポックよりも小さいエポックをすべて拒否します。

要望もある。新しいリーダーの存在を知らないフォロワーはいますか? 可能性はありますが、ほとんどはそうではありません。そうでない場合は、新しいリーダー

生成できません。Zookeeper の書き込みもクォーラム メカニズムに従うため、大多数によってサポートされていない書き込みは無効であり、古い

リーダーが「自分はリーダーだ」と思っていても、やはり効果はありません。

「スプリット ブレイン」を回避するために上記のデフォルトのクォーラム方式を使用することに加えて、動物園管理者は次の予防措置を講じることもできます。

Shi: 2. 「スプリット ブレイン」の可能性を最小限に抑えるために、二重線などの冗長な心拍ラインを追加します。3. ディスクロックを有効にします。給仕

一方が共有ディスクをロックし、「スプリット ブレイン」が発生すると、もう一方は共有ディスク リソースを完全に「奪うことができなくなります」。ただし、ロックディスクを使用すると、

小さな問題ではありませんが、共有ディスクを占有している側が率先して「ロックを解除」しないと、相手が共有ディスクを取得することはできません。実際に提供されれば、

サービスノードが突然クラッシュしたりクラッシュしたりすると、ロック解除コマンドを実行できなくなります。バックアップ ノードは、共有リソースとアプリケーション サービスを引き継ぐことができません。で

HA の「スマート」ロックを設計した人物です。つまり、サービス提供側はハートビート ラインが完全に切断されたことのみを検出します (ピア エンドは検出できません)。

ディスクロックを有効にします。通常は施錠されていません。4. 仲裁メカニズムをセットアップします。たとえば、ハートジャンパが完全にオンになったときに、参照 IP (ゲートウェイ IP など) を設定します。

切断されると、2 つのノードはそれぞれ参照 IP に ping を実行する必要があります。失敗した場合は、ブレークポイントがローカル エンド (「ハートビート」だけでなく「外部」サービスにもある) であることを意味します。

「サービス」のローカルネットワークリンクが切断された場合、アプリケーションサービスを開始（または継続）するのが無駄であっても、率先して競争を放棄して、

ping通参考IP的一端去起服务。更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放

有可能还占用着的那些共享资源。

34、说说 Zookeeper 的 CAP 问题上做的取舍？

一致性 C：Zookeeper 是强一致性系统，为了保证较强的可用性，

“一半以上成功即成功”的数据同

步方式可能会导致部分节点的数据不一致。所以 Zookeeper 还提供了 sync() 操作来做所有节点的

数据同步，这就关于 C 和 A 的选择问题交给了用户，因为使用 sync()势必会延长同步时间，可用性

会有一些损失。

阿里内部资料可用性 A：Zookeeper 数据存储在内存中，且各个节点都可以相应读请求，具有好的响应性能。

Zookeeper 保证了数据总是可用的，没有锁。并且有一大半的节点所拥有的数据是最新的。

分区容忍性 P：Follower 节点过多会导致增大数据同步的延时（需要半数以上 follower 写完提

交）。同时选举过程的收敛速度会变慢，可用性降低。Zookeeper 通过引入 observer 节点缓解了

这个问题，增加 observer 节点后集群可接受 client 请求的节点多了，而且 observer 不参与投票，

可以提高可用性和扩展性，但是节点多数据同步总归是个问题，所以一致性会有所降低。

35、watch 监听为什么是一次性的？

如果服务端变动频繁，而监听的客户端很多情况下，每次变动都要通知到所有的客户端，给网络和

服务器造成很大压力。

一般是客户端执行 getData(节点 A,true) ，如果节点 A 发生了变更或删除，客户端会得到它的

watch 事件，但是在之后节点 A 又发生了变更，而客户端又没有设置 watch 事件，就不再给客户端

发送。

在实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我只要最新的数据即

可。

Redis篇

1，为什么要用缓存

使用缓存的目的就是提升读写性能。而实际业务场景下，更多的是为了提升读性能，带来更好的性

能，带来更高的并发量。 Redis 的读写性能比 Mysql 好的多，我们就可以把 Mysql 中的热点数据缓

存到 Redis 中，提升读取性能，同时也减轻了 Mysql 的读取压力。

欢迎关注微信公众号：Java后端技术全栈

2，使用 Redis 有哪些好处？

具有以下好处：

读取速度快，因为数据存在内存中，所以数据获取快；

支持多种数据结构，包括字符串、列表、集合、有序集合、哈希等；

支持事务，且操作遵守原子性，即对数据的操作要么都执行，要么都不支持；

还拥有其他丰富的功能，队列、主从复制、集群、数据持久化等功能。

3，

什么是 Redis？

阿里内部资料Redis 是一个开源（BSD 许可）、基于内存、支持多种数据结构的存储系统，可以作为数据库、缓

存和消息中间件。它支持的数据结构有字符串（strings）、哈希（hashes）、列表（lists）、集合

（sets）、有序集合（sorted sets）等，除此之外还支持 bitmaps、hyperloglogs 和地理空间（

geospatial ) インデックス半径クエリおよびその他の関数。

レプリケーション (Replication)、LUA スクリプト (Lua スクリプティング)、LRU 駆動イベント (LRU エビクション)、イベントが組み込まれています。

サービス (トランザクション) とさまざまなレベルのディスク永続化 (永続化) 機能、および Redis Sentinel (Sentry) および

クラスター (Cluster) は、キャッシュの高可用性を確保します (高可用性)。

4. Memcacheの代わりにRedisを使用する理由は何ですか?

この時点で念頭に置く必要があるのは、Memcache と Redis を区別することです。

Redis と Memcache はどちらもデータをメモリに保存し、どちらもメモリ データベースです。ただし、Memcache はキャッシュにも使用できます

その他、写真や動画など。

Memcache はキーと値の構造のデータ型のみをサポートしますが、Redis は単純なキーと値の型のデータをサポートするだけでなく、

同時に、リスト、セット、ハッシュなどのデータ構造のストレージも提供します。

仮想メモリ – Redis は、物理メモリが使い果たされたときに、長期間使用されていない一部の値をディスクにスワップできます。

分散 – Memcache クラスターを設定し、magent を使用して 1 つのマスターと複数のスレーブを実行します。Redis は 1 つのマスターと複数のスレーブを実行できます。1つのマスターになることができます

から

保存されたデータのセキュリティ – Memcache がハングアップするとデータは失われますが、Redis は定期的にディスクに保存できます (永続化)

Memcache の最大単一値は 1m、Redis の最大単一値は 512m です。

災害復旧 – Memcache がハングアップするとデータは復元できませんが、Redis データが失われた後は aof を通じて復元できます。

Redis はクラスター モードをネイティブでサポートしていますが、Redis3.0 バージョンでは公式の都合でクラスター モードをサポートできます。

ネイティブ クラスター モードがあり、これはクライアントによって実現され、クラスター フラグメントにデータを書き込む必要があります。

Memcached ネットワーク IO モデルは、マルチスレッド、ノンブロッキング IO 多重化ネットワーク モデルであり、そのプロトタイプは nigx に近いものです。一方、Redis

シングルスレッド IO 多重化モデルを使用して、主要な実装クラスである単純な AeEvent イベント処理フレームワークをカプセル化しました。

epoll、kqueue、select は Apache の初期モデルに近いものです。

5. Redisシングルスレッド モデルはなぜ非常に効率的ですか?

1. C言語実装、高効率

2. 純粋なメモリ操作

3. ノンブロッキングIO多重化モデルメカニズムに基づく

4. 単一スレッドを使用すると、複数スレッドの頻繁なコンテキスト切り替えの問題を回避できます。

5. 豊富なデータ構造 (フルネームはハッシュ構造を採用しており、読み取り速度が非常に速く、サブディレクトリなどのデータストレージにいくつかの最適化が行われています)

リクエストテーブル、スキップテーブルなど）

6 、Redisのスレッド モデルについて話します

Ali の内部情報からのこの質問は、ノンブロッキング IO 多重化モデルに基づく質問に対する前の回答で Redis について言及されているためです。この質問が戻ってきた場合

答えられないということは、前の答えが自分に穴を掘っているということであり、答えられないと面接官のあなたに対する印象が変わってしまう可能性があるからです。

少し割引されています。

Redis は内部でファイル イベント ハンドラーファイル イベント ハンドラーを使用します。これはシングルスレッドであるため、

Redis はシングルスレッド モデルと呼ばれます。IO多重化メカニズムを使用して、ソケット上のイベントに従って複数のソケットを同時に監視します。

をクリックして、処理する対応するイベント ハンドラーを選択します。

ファイル イベント ハンドラーの構造は 4 つの部分で構成されます。

1. 複数のソケット。

2. IO多重化プログラム。

3. ファイルイベントディスパッチャー。

4. イベント ハンドラー (接続応答ハンドラー、コマンド要求ハンドラー、コマンド応答ハンドラー)。

複数のソケットは異なる操作を同時に生成することができ、各操作は異なるファイル イベントに対応しますが、IO 多重化プログラムは

複数のソケットをリッスンすると、ソケットによって生成されたイベントがキューに入れられ、イベント ディスパッチャは毎回キューから 1 つのイベントを取り出します。

イベントを取得し、そのイベントを対応するイベント ハンドラーに渡して処理します。

クライアントと Redis の間の通信プロセスを見てみましょう。

この写真について簡単に説明しましょう。

1. クライアント Socket01 は Redis サーバー ソケットとの接続を確立するように要求し、サーバー ソケットは

AE_READABLE イベント。IO マルチプレクサはサーバー ソケットによって生成されたイベントをリッスンした後、イベントをキューにプッシュします。

真ん中。ファイル イベント ディスパッチャーはキューからイベントを取得し、それを接続応答ハンドラーに渡します。接続応答ハンドラーは、

クライアントと通信可能なSocket01。Socket01のAE_READABLEイベントをコマンドリクエストプロセッサと接続します。

対句。

2. この時点でクライアントがキー値の設定リクエストを送信すると仮定すると、Redis の Socket01 は

AE_READABLE イベントが発生すると、IO マルチプレクサーがイベントをキューにプッシュし、イベント ディスパッチャーがキューからイベントを取得します。

イベント。Socket01 の以前の AE_READABLE イベントがコマンド リクエスト ハンドラー、イベント ディスパッチャーに関連付けられているため、

イベントをコマンド要求ハンドラーに渡して処理します。コマンドリクエストプロセッサは、Socket01の設定されたキー値を読み取り、

セットキー値のメモリへの設定が完了します。操作が完了すると、Socket01 の AE_WRITABLE イベントが送信されます。

応答ハンドラーの関連付け。

3. この時点でクライアントが返された結果を受け取る準備ができている場合、Redis の Socket01 は

AE_WRITABLE イベントもキューにプッシュされ、イベント ディスパッチャーが関連するコマンド応答ハンドラーを見つけて、コマンドが応答します。

Ali の内部データ プロセッサは、この操作の結果 (ok など) を Socket01 に入力し、その後 Socket01 を解放します。

AE_WRITABLE イベントとコマンド応答ハンドラーの関連付け。

これで通信が完了します。このテキストを怖がらずに、画像と合わせて読んでください。1 回か 2 回実行してください。うまくいかなかったら、オンラインで情報を確認できます。

それを一緒に見て、私たちはそれを理解しなければなりません、そうでなければ、前での自慢は無駄になります。

7，为什么 Redis 需要把所有数据放到内存中？

Redis 将数据放在内存中有一个好处，那就是可以实现最快的对数据读取，如果数据存储在硬盘

中，磁盘 I/O 会严重影响 Redis 的性能。而且 Redis 还提供了数据持久化功能，不用担心服务器重

启对内存中数据的影响。其次现在硬件越来越便宜的情况下，Redis 的使用也被应用得越来越多，

使得它拥有很大的优势。

8，Redis 的同步机制了解是什么？

Redis 支持主从同步、从从同步。如果是第一次进行主从同步，主节点需要使用 bgsave 命令，再将

后续修改操作记录到内存的缓冲区，等 RDB 文件全部同步到复制节点，复制节点接受完成后将

RDB 镜像记载到内存中。等加载完成后，复制节点通知主节点将复制期间修改的操作记录同步到复

制节点，即可完成同步过程。

9， pipeline 有什么好处，为什么要用 pipeline？

使用 pipeline（管道）的好处在于可以将多次 I/O 往返的时间缩短为一次，但是要求管道中执行的

指令间没有因果关系。

用 pipeline 的原因在于可以实现请求/响应服务器的功能，当客户端尚未读取旧响应时，它也可以

处理新的请求。如果客户端存在多个命令发送到服务器时，那么客户端无需等待服务端的每次响应

才能执行下个命令，只需最后一步从服务端读取回复即可。

10，说一下 Redis 有什么优点和缺点

优点

速度快：因为数据存在内存中，类似于 HashMap ， HashMap 的优势就是查找和操作的时间复杂

度都是O (1) 。

支持丰富的数据结构：支持 String ，List，Set，Sorted Set，Hash 五种基础的数据结构。

持久化存储：Redis 提供 RDB 和 AOF 两种数据的持久化存储方案，解决内存数据库最担心的

万一 Redis 挂掉，数据会消失掉

高可用：内置 Redis Sentinel ，提供高可用方案，实现主从故障自动转移。 内置 Redis

Cluster ，提供集群方案，实现基于槽的分片方案，从而支持更大的 Redis 规模。

丰富的特性：Key过期、计数、分布式锁、消息队列等。

缺点

阿里内部资料由于 Redis 是内存数据库，所以，单台机器，存储的数据量，跟机器本身的内存大小。虽然

Redis 本身有 Key 过期策略，但是还是需要提前预估和节约内存。如果内存增长过快，需要定

期删除数据。

如果进行完整重同步，由于需要生成 RDB 文件，并进行传输，会占用主机的 CPU ，并会消耗

现网的带宽。不过 Redis 2.8 版本，已经有部分重同步的功能，但是还是有可能有完整重同步

的。比如，新上线的备机。

修改配置文件，进行重启，将硬盘中的数据加载进内存，时间比较久。在这个过程中， Redis

不能提供服务。

11 Redis 缓存刷新策略有哪些？

12， Redis 持久化方式有哪些？以及有什么区别？

Redis 提供两种持久化机制 RDB 和 AOF 机制:

RDB 持久化方式

是指用数据集快照的方式半持久化模式)记录 redis 数据库的所有键值对,在某个时间点将数据写入

一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。

优点：

只有一个文件 dump.rdb ，方便持久化。

容灾性好，一个文件可以保存到安全的磁盘。

パフォーマンスを最大化するには、子プロセスをフォークして書き込み操作を完了し、メインプロセスがコマンドの処理を継続できるようにして、IO を最大化します。シートを使用する

唯一の子プロセスが永続化に使用され、メイン プロセスは IO 操作を実行しないため、Redis の高いパフォーマンスが保証されます)

データセットが大きい場合、AOF よりも効率的です。

欠点:

データのセキュリティが低い。RDB は一定の間隔で永続化されますが、永続化の間に Redis に障害が発生するとデータが発生します

失った。したがって、この方法は、データ要件が厳密ではない場合に適しています。

AOF=Append -ファイル永続化のみの方法

Alibaba の内部データとは、すべてのコマンド ライン レコードが Redis コマンド リクエスト プロトコルの形式で永続的に保存され、AOF ファイルとして保存されることを意味します。

アドバンテージ：

(1) データセキュリティ、AOF 永続性は appendfsync 属性で設定でき、常に存在し、コマンド操作が実行されるたびに記録されます。

AOF ファイルに一度コピーします。

(2) 追加モードでファイルを書き込みます。サーバーが途中でダウンした場合でも、redis-check-aof ツールを使用してデータを解決できます。

一貫性の問題。

(3) AOF メカニズムの書き換えモード。AOF ファイルが書き換えられる前 (ファイルが大きすぎる場合、コマンドはマージされて書き換えられます)

Write)、一部のコマンド (flushall の誤用など) を削除できます。

欠点:

(1) AOF ファイルは RDB ファイルに比べてサイズが大きく、回復速度が遅くなります。

(2) データセットが大きい場合、RDB 起動よりも効率が悪くなります。

13.永続性には 2 種類ありますが、どのように選択すればよいですか?

1. RDB だけを使用しないでください。大量のデータが失われる可能性があります。

2. AOF だけを使用しないでください。AOF を使用すると、コールド バックアップのリカバリに RDB を使用しなくても、コールド バックアップに AOF を使用できるという 2 つの問題があります。

第二に、RDB は毎回単純かつ大まかにデータ スナップショットを生成します。これにより、より堅牢になり、AOF などの複雑なバックアップを回避できます。

バックアップおよび回復メカニズムのバグ。

3. Redis は 2 つの永続化メソッドの同時有効化をサポートしており、AOF と RDB の永続化メカニズムを包括的に使用できます。

データ リカバリの最初の選択肢として、AOF を使用してデータが失われないようにします。RDB を使用して、AOF でさまざまなレベルのコールド バックアップを実行します。

すべてのファイルが紛失または破損して利用できなくなった場合、RDB を使用して迅速なデータ回復を行うこともできます。

4. RDB と AOF の両方の永続化メカニズムが同時に使用されている場合、Redis の再起動時に AOF が使用されます。

AOF のデータはより完全であるため、データを構築します。

14. Redis を使用してメッセージ キューを実装するにはどうすればよいですか?

一般に、リスト構造はキューとして使用され、rpush がメッセージを生成し、lpop がメッセージを消費します。lpopからのニュースがない場合は、次のことが必要です。

寝てからもう一度試してください。

面接官は、睡眠を利用できますか?と尋ねるかもしれません。list には blpop と呼ばれる命令もあり、ニュースがない場合は

メッセージが届くまでブロックします。

面接官は、一度生産して複数回消費することは可能ですか? と尋ねる場合もあります。パブリッシュ/サブトピック サブスクライバー モードを使用すると、1:N を実現できます。

メッセージキュー。

面接官は、パブ/サブの欠点は何ですか?と尋ねる場合もあります。コンシューマがオフラインになると、生成されたメッセージは失われるため、次を使用する必要があります。

Rabbitmq などのプロフェッショナルなメッセージ キュー。

Ali の内部データ インタビュアーは、Redis が遅延キューをどのように実装しているのかを尋ねるかもしれません。もしそうなら、今頃あなたは面接官を殴り殺したいという誘惑に駆られているでしょう。

野球のバットなら、なぜそこまで詳しく聞くのですか？しかし、あなたは非常に自制した後、冷静にこう答えました。

sortedset では、タイムスタンプをスコアとして、メッセージの内容をキーとして zadd を呼び出してメッセージを生成し、コンシューマは次のメソッドを使用します。

zrangebyscore コマンドは、処理のために N 秒前のデータ ポーリングを取得します。

面接の拡散: 多くの面接官がやって来て、直接質問します。

Redis は遅延キューをどのように実装しますか?

15 、 Redisトランザクションについての理解について話す

Redisトランザクションとは何ですか? 原理は何ですか?

Redis のトランザクションはコマンドの集合であり、Redis の最小実行単位です。複数のコマンドを一度に実行することが保証されています。

トランザクションは単一の分離された操作であり、トランザクション内のすべてのコマンドはシリアル化されて順番に実行されます。サーバーがトランザクションを実行しています

プロセス中、他のクライアントから送信されたコマンド要求によって中断されることはありません。

その原理は、トランザクションに属するコマンドを最初に Redis に送信し、次にこれらのコマンドを順番に実行することです。

Redisの取引で注意すべき点は何ですか?

注意すべき点は次のとおりです。

Redis トランザクションは、MySQL トランザクションとは異なり、ロールバックをサポートしていません。すべて実行するか、まったく実行しないかのどちらかです。

トランザクションの実行中、Redis サーバーは他のクライアントから送信されたコマンド要求によって中断されません。トランザクションコマンドまで

すべての実行が完了した後でのみ、他のクライアントのコマンドが実行されます。

Redisトランザクションがロールバックをサポートしないのはなぜですか?

Redis トランザクションはロールバックをサポートしていませんが、実行されたコマンドに構文エラーがあり、Redis は実行に失敗します。これらの問題はプログラム層から解決できます。

表面のキャプチャと解像度。ただし、他の問題が発生した場合でも、残りのコマンドは実行されます。その理由はロールバックのためです

多くの作業を追加する必要がありますが、ロールバックのサポートがなければ、シンプルで高速な機能を維持できません。

16. Redis がシングルスレッドになるように設計されているのはなぜですか?

マルチスレッドにはロックが含まれ、マルチスレッドにはスレッドの切り替えと CPU の消費が含まれます。シングルスレッド、回避

必要なコンテキストの切り替えと競合状態。次に、CPU は Redis のボトルネックではありません。Redis のボトルネックはマシンのメモリまたはメモリである可能性が最も高くなります。

またはネットワーク帯域幅。

17 、 bigkeyとは何ですか？どのような影響がありますか?

Bigkey は、キー値が非常に大きなメモリ領域を占めるキーを指します。たとえば、文字列 a には 200M のデータが格納されます。

bigkey の主な効果は次のとおりです。

ネットワークの混雑。bigkey を取得するときに送信されるデータの量が比較的多く、帯域幅への圧力が増大します。

タイムアウト ブロック。bigkey は比較的大きな領域を占有するため、操作効率が比較的低くなり、ブロックされる可能性があります。

セックスが増えた。

アリババの内部データはメモリ空間の不均衡につながります。ビッグキーには大量のデータが保存され、同じキーは同じノードまたはサーバーに保存されます。

ストレージは一定の影響を及ぼします。

18.どのRedisクラスター モードに精通していますか?

1.レディスセンチネル

ボリュームが小さい場合は、Redis Sentinel を選択してください。ビジネスをサポートするにはシングルマスター Redis で十分です。

2. Redis クラスター

Redis が公式に提供するクラスタリング ソリューション。ボリュームが大きい場合は、Redis Cluster を選択し、断片化を通じてより多くのコンテンツを使用します。

ライブ。

3.トゥエンプロックス

Twemprox は、Twtter によってオープンソース化されている Redis および Memcached プロキシ サーバーで、主に Redis および Memcached の管理に使用されます。

Memcached クラスターは、キャッシュ サーバーへの直接接続の数を減らします。

4. コード

Codis はプロキシ ミドルウェアです。クライアントが Codis に命令を送信すると、Codis はその命令を以下に転送する責任があります。

Redis を実行して結果をクライアントに返します。Codis インスタンスは複数の Redis インスタンスに接続でき、起動することもできます。

複数の Codis インスタンスをサポートするには、各 Codis ノードが同等であるため、全体的な QPS 需要が増加する可能性があります。

災害復旧機能を果たします。

5. クライアントの断片化

Redis Cluster が登場する前はよく使用されていましたが、現在ではほとんど使用されず、ビジネス コード層に実装されています。

いくつかの無関係な Redis インスタンスは、コード層でキーに対してハッシュ計算を実行し、対応する Redis インスタンスに移動して操作します。

データを作る。この方法には、ハッシュ層コードに対する要件が比較的高く、考慮事項には、ノードに障害が発生した後の代替アルゴリズム スキームが含まれます。

データショック後の自動スクリプト回復、インスタンス監視など。

19. Redis Clusterクラスターを使用したことがありますか? クラスターの原理は何ですか?

使用される Redis クラスターの原理は次のとおりです。

すべてのノードは相互に接続されています

クラスタメッセージ通信はクラスタバス経由で通信し、クラスタバスのポートサイズはクライアントサービスポート+10000(固定値)となります。

ノードはバイナリ プロトコルを通じて相互に通信します

クライアントとクラスター ノード間の通信は、通常どおりテキスト プロトコル経由で行われます。

クラスターノードはクエリをプロキシしません

データはスロット ストレージに従って複数の Redis インスタンスに分散されます

クラスターノードがハングアップすると、自動的にフェイルオーバーします。

ノードの拡張・縮小が比較的スムーズに行える

Alibaba 内部データ Redis クラスターには 16384 の組み込みハッシュ スロットがあります。キーと値を Redis クラスターに配置する必要がある場合、最初に Redis が必要になります。

キーは crc16 アルゴリズムを使用して結果を計算し、結果の残りを 16384 まで計算します。これにより、各キーが数値に対応します。

0 ～ 16383 のハッシュ スロットの場合、redis はノード数に応じてハッシュ スロットを異なるノードにほぼ均等にマッピングします。

20. Redis Cluster クラスター スキームによりクラスター全体が使用できなくなるのはどのような状況ですか?

使用？

Redis はハッシュ コンセンサス アルゴリズムを使用せず、ハッシュ スロットを使用します。Redis には合計 16384 個のハッシュ スロットがあり、計算は次のようになります。

キーのハッシュ スロットについては、キーの CRC16 の 16384 を測定するだけで済みます。クラスター内に 3 つのクラスター ノード A、B、および C があるとします。

レプリケーション モードがない場合、各クラスター ノードに含まれるハッシュ スロットは次のとおりです。

ノード A には 0 ～ 5500 のハッシュ スロットが含まれます。

ノード B には 5501 ～ 11000 のハッシュ スロットが含まれています。

ノード C には 11001 ～ 16383 のハッシュ スロットが含まれています。

このとき、ノード B に障害が発生すると、5501 ～ 11000 の範囲のハッシュ スロットが不足するため、クラスター全体が使用できなくなります。

21. Redisクラスター アーキテクチャ モードとは何ですか?

Redis クラスター アーキテクチャは、単一ノードのスタンドアロン モードをサポートし、複数のスレーブを備えたマスター/スレーブ構造もサポートし、センチネルを備えたクラスター ユニットもサポートします。

デプロイモード。

22 、Redisハッシュ スロットの概念について話しますか?

Redis クラスターは一貫したハッシュを使用しませんが、ハッシュ スロットの概念を導入します。Redis クラスターには 16384 (2^14) ヘクタールがあります

スロット、各キーは CRC16 チェックとモジュロ 16384 に合格し、どのスロットを配置するかを決定します。クラスターの各ノードはその部分を担当します。

ハッシュスロット。

23. Redis の一般的なパフォーマンスの問題と解決策は何ですか?

Redis の一般的なパフォーマンスの問題と解決策は次のとおりです。

マスターは、R​​DB メモリ スナップショットや AOF ログ ファイルなどの永続的な作業を行わないことが最善です。

データがより重要な場合、スレーブは AOF バックアップ データをオンにし、ポリシーは 1 秒に 1 回同期するように設定されます。

マスターとスレーブのレプリケーションの速度と接続の安定性を考慮すると、マスターとスレーブが同じローカル エリア ネットワーク内にある方が良いでしょう。

高圧下ではスレーブ ライブラリをメイン ライブラリに追加しないようにしてください。

マスター/スレーブ レプリケーションにはグラフ構造を使用しないでください。一方向リンク リスト構造、つまりマスター <- スレーブ 1 <- スレーブ 2 <- を使用する方が安定しています。

Slave3….; このような構造は、単一障害点の問題を解決し、マスターからスレーブへの置き換えを実現するのに便利です。マスターがハングアップした場合

これで、すぐに Slave1 をマスターにできるようになり、他のものは変更されないままになります。

24. Redisに1億個のキーがある場合、そのうちの10wは特定のキーに基づいています。

固定の既知のプレフィックスから始めて、それらすべてを見つけるにはどうすればよいでしょうか?

内部情報については、keys コマンドと scan コマンドを使用できますが、scan を使用した方がよいことがわかります。

1.キーコマンドを使用します。

クエリにはkeysコマンドを直接使用しますが、運用環境で使用すると問題が発生します。keysコマンドはトラバーサルクエリです。

はい、クエリの時間計算量は O(n) であり、データ量が多いほどクエリ時間は長くなります。そして、Redis はシングルスレッドであり、キー命令は次のようになります。

スレッドが一定期間ブロックされると、オンライン Redis が一定期間一時停止され、キーが実行されるまで再開されません。これは生産しています

環境が許されていない。また、このコマンドにはページング機能がなく、すべての一致条件を一度に問い合わせることに注意してください。

ファイルのキー値を見ると、クエリ結果が非常に大きく、出力情報も非常に大きいことがわかります。したがって、このコマンドは推奨されません。

2.スキャンコマンドを使用する

scan コマンドはキーと同じマッチング機能を実現できますが、scan コマンドは実行中にスレッドをブロックせず、検索

検索するデータは重複している可能性があるため、クライアント操作によって重複を排除する必要があります。スキャンはカーソルを通じてクエリされるため、問題は発生しません。

Redis には一時停止の問題があります。Redis のクエリ処理中に、カーソルがクライアントに返されます。一度 null 値が返され、カーソルが 0 でない場合は、

これは、走査がまだ終わっておらず、クライアントがクエリの走査を継続していることを意味します。スキャンプロセス中、削除された要素はクエリされません。

はい、ただし、反復プロセス中に一部の要素が変更された場合、スキャンは対応する要素をクエリすることを保証できません。比較的言えば、スキャンコマンド

ルックアップには、keys コマンドよりも時間がかかります。

25.同時に有効期限を設定する必要があるキーが多数ある場合、何に注意する必要がありますか?

何？

多数のキーが同時に期限切れになると、同じ秒内にデータベースからデータが取得され、データベースに多大な負荷がかかる可能性があります。

強制的に実行すると、データベースがクラッシュし、システムに 502 問題が発生します。同時に失敗することもありますが、その時点ではデータベースにアクセスする必要はなく、負荷は高くありません。

サイズが十分に大きい場合、Redis には短期的なフリーズの問題が発生します。したがって、この種の問題の発生を防ぐためには、データを期限切れにすることが最善です

有効期限をより分散させるには、時間にランダムな値を追加します。

26.どのような状況でRedisがブロックされる可能性がありますか?

Redis がブロックされる主な理由は、内部と外部の 2 つです。

内部的な理由

Redis ホストの CPU 負荷が高すぎると、システムがクラッシュする原因になります。

データの永続化には多くのリソースが必要です。

Redis API または命令の不当な使用により、Redis に問題が発生します。

外部原因

外部的な理由は主にサーバーによって引き起こされます。たとえば、切り替えプロセス中のサーバーの CPU スレッドの競合、メモリの問題、ネットワークの問題などです。

ネットワークの問題など

27.キャッシュとデータベースを最初に更新するのは誰ですか?

解決

Ali 内部情報 1. 書き込み要求が来ると、書き込み要求をキャッシュ キューにキャッシュし、書き込み要求の特定の操作の実行を開始します (キャッシュ内のデータを削除します)

データ、データベースの更新、キャッシュの更新）。

2. データベースの更新中に別の読み取り要求が来た場合、その読み取り要求を再度キャッシュ キューに格納します (n 個のキューを作成できます)

列。キーのハッシュ値を使用してキュー数のモジュロハッシュ%nを取得し、対応するキューに分類します。キューは順序を保証する必要があります)

このうち、順序保証は、キューが完了する前に書き込みリクエストの実行を待ち、その後、読み取りリクエストよりも前の書き込みリクエストがキャッシュの削除に失敗することを保証します。

直接戻ります。データベース内のデータは現時点では古い値であり、キャッシュ内のデータと一貫性があり、キャッシュの一貫性はありません。

問題。

3. 書き込みリクエストによりキャッシュの削除が成功するとデータベースが更新され、更新に失敗した場合はそのままリターンして書き込みリクエストは終了します。

データベース内の値は古い値のままで、読み取りリクエストが来た後、キャッシュにデータがないことがわかります。

データベースに直接リクエストします。

同時にデータはキャッシュに書き込まれますが、この時点ではデータの整合性の問題は発生しません。

4. データの更新が成功したら、キャッシュを更新します。この時点でキャッシュの更新に失敗した場合は、キャッシュにデータが存在せず、データベースが新しいことになります。

この値を超えると、書き込みリクエストは終了しますが、この時点では読み取りリクエストは同じです。キャッシュにデータがない場合は、データベースからもデータが読み取られます。

そして実際には、更新キャッシュが成功したか失敗したかに関係なく、キャッシュに保存されます。

データの整合性の問題は発生しません。

上記の解決策は、主にシリアル化が使用され、各操作を順番に実行する必要があるため、データの不整合の問題を解決します。好き

特定のキュー要素のバックログが多すぎる場合は、読み取りリクエストをフィルタリングして、ページを更新して再度リクエストするようにユーザーに促すことができます。

潜在的な問題、この問題は多岐にわたるため、それについては各自で考えてください。

1. リクエスト時間が長すぎ、キューに大量の書き込みリクエストが溜まっており、すべての書き込みが完了するまで読み取りリクエストはデータを取得できません。

2. 読み取りリクエストの高い同時実行性

3. ホットスポット データ ルーティングの問題により、リクエストのスキューが発生します。

28.キャッシュヒット率を向上させるにはどうすればよいですか?

一般的に使用される主な手段は次のとおりです。

事前にデータをキャッシュにロードします。

キャッシュのストレージ容量を増やし、キャッシュされたデータを改善します。

キャッシュのストレージ データ タイプを調整します。

キャッシュの更新頻度を上げます。

29. Redis はキーの競合をどのように解決しますか?

Redis キーが同じ場合、後のキーが前のキーを上書きします。キーの競合を解決したい場合は、キー領域に名前を付けることが最善です

キーの繰り返しによって生じる競合を避けるために、ビジネス名とパラメーターに従って名前を個別に分けることができます。

30. Redis がメモリ不足を報告する場合はどうすればよいですか?

Redis のメモリ不足は次のように処理できます。

構成ファイル redis.conf の maxmemory パラメーターを変更して、Redis の使用可能なメモリを増やします。

メモリ使用効率を向上させるためにキャッシュ削除戦略を設定します。

Ali の内部データは、Redis クラスター モードを使用してストレージ容量を増やします。

31. Redis永続化メカニズムについて話す

Redis は永続性をサポートするインメモリ データベースであり、永続化メカニズムを通じてメモリ内のデータがハードディスク ファイルと同期され、データが確実に保存されます。

持続性。Redis が再起動すると、ハードディスク ファイルをメモリに再ロードすることで、データ回復の目的を達成できます。実施：一人で

fork() 子プロセスを作成し、現在の親プロセスのデータベース データを子プロセスのメモリにコピーして、一時プロセスに書き込みます。

一時ファイルでは、永続化プロセスが終了し、この一時ファイルを使用して最後のスナップショット ファイルを置き換え、子プロセスが終了し、メモリが

解放された。

RDB は Redis のデフォルトの永続化メソッドです。特定の期間戦略に従って、メモリ内のデータはスナップショットの形式でハードディスクに保存されます。

バイナリーファイル。つまり、スナップショット スナップショット ストレージ、対応する生成されたデータ ファイルは dump.rdb であり、構成ファイルの save パラメータを使用します。

スナップショットの期間を定義する数値。(

スナップショットは、それが表すデータのコピーまたはレプリカのいずれかになります。)

AOF：Redis会将每一个收到的写命令都通过Write函数追加到文件最后，类似于MySQL的binlog。

当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。 当两种方

式同时开启时，数据恢复Redis会优先选择AOF恢复。

32、缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级等问

题

一、缓存雪崩

我们可以简单的理解为：由于原有缓存失效，新缓存未到期间 (例如：我们设置缓存时采用了相同的

过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，

而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成

整个系统崩溃。 解决办法：

大多数系统设计者考虑用加锁（

最多的解决方案）或者队列的方式保

证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存

储系统上。还有一个简单方案就时讲缓存失效时间分散开。

二、缓存穿透 缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用

户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次

无用的查询）。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。 解决办法;

最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不

存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。 另外也有一个更为

简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然

この空の結果をキャッシュしますが、有効期限は非常に短く、5 分以内です。これによって直接設定されたデフォルト値

これをキャッシュに保存すると、データベースへのアクセスを継続せずに 2 回目から値がキャッシュに取得されますが、この方法は最も単純で失礼です。

5TB ハードディスクにはデータがいっぱいです。データを重複排除するアルゴリズムを作成してください。データが32ビットサイズの数値の場合

解決方法によると？64bitだとどうなるのでしょうか？

Ali の内部データは、ビットマップとブルーム フィルターというスペースの使用において極限に達しています。ビットマップ:

典型的

ハッシュテーブルです ビットマップは要素ごとに1ビットの情報しか記録できないのが欠点です 追加機能を充実させたい場合は残念ですが頼るしかないと思います

完了するには、より多くのスペースと時間を犠牲にしてください。

ブルームフィルター（推奨）

これは、k(k>1)k(k>1) の相互に独立したハッシュ関数を導入して、特定の空間において誤検知率が確実に高くなるようにすることです。

次に、要素の重みを判断するプロセスを完了します。その利点は、スペース効率とクエリ時間が一般的なアルゴリズムよりもはるかに優れていることです。欠点は、特定のアルゴリズムがあることです。

誤認率と除去難易度。ブルーム フィルター アルゴリズムの核となるアイデアは、複数の異なるハッシュ関数を使用して「競合」を解決することです。

Conflict」。ハッシュには競合（衝突）の問題があり、同じハッシュで取得した2つのURLの値が同じになる可能性があります。

競合が減れば、より多くのハッシュを導入できます。ハッシュ値の 1 つを通じて特定の要素がセットに含まれていない場合は、

その場合、その要素はセット内に存在しません。すべてのハッシュ関数がその要素がセット内にあることを示した場合にのみ、その要素が存在することを確認できます。

セットで。これがブルームフィルターの基本的な考え方です。ブルームフィルターは通常、特定の条件を決定するために使用されます。

要素が存在します。

3. キャッシュの予熱キャッシュの予熱は比較的一般的な概念であり、多くの小規模パートナーは簡単に理解できるはずだと思います。

解決策として、キャッシュ ウォームアップとは、システムがオンラインになった後、関連するキャッシュ データがキャッシュ システムに直接ロードされることを意味します。これにより、ユーザーが尋ねることができなくなります

リクエストするときは、まずデータベースにクエリを実行してから、データをキャッシュします。ユーザーは、事前にウォームアップされたキャッシュ データを直接クエリします。

解決

アイデア: 1. キャッシュ更新ページを直接記述し、オンライン時に手動で操作する 2. データ量が大きくないので、プロジェクトの開始時に使用できる

自動ロード; 3. キャッシュを定期的に更新します。

4. キャッシュの更新 キャッシュ サーバーに付属するキャッシュ無効化戦略 (Redis にはデフォルトで 6 つの戦略から選択できます)に加えて、

特定のビジネス ニーズに応じてキャッシュの削除をカスタマイズすることもできます。一般的な戦略は 2 つあります。

(1) 定期クリーンアップ期限切れ

キャッシュ;

(2) ユーザーからのリクエストがあった場合、リクエストで使用したキャッシュの有効期限が切れているかどうかを判断し、期限切れの場合は基盤システムにアクセスします。

システムは新しいデータを取得し、キャッシュを更新します。どちらにも独自の長所と短所があり、最初の短所は、キャッシュされた多数のキーを維持するのがより面倒であることです。

2 番目のタイプの欠点は、ユーザーがリクエストするたびにキャッシュが無効であると判断する必要があり、ロジックが比較的複雑であることです。どのようなプランを利用していますか？

独自のアプリケーションシナリオに応じて重量を量ることができます。

5. キャッシュの劣化 アクセス数が急激に増加すると、サービスの問題 (応答時間の遅さや無応答など) や非コア サービスがコア フローに影響を及ぼします。

プロセスのパフォーマンスを向上させる場合、たとえサービスに悪影響を与える場合でも、サービスが引き続き利用可能であることを確認する必要があります。システムは自己実行できます。

スイッチを構成して手動でダウングレードすることもできます。ダウングレードの最終的な目標は、たとえ損失があったとしても、コア サービスを利用可能な状態に保つことです。と

また、一部のサービス（ショッピングカートへの追加、決済など）はダウングレードできません。参照ログ レベルでスキームを設定します。

(1) 一般: たとえば

一部のサービスは、ネットワークのジッターやサービスがオンラインになるためにタイムアウトすることがあり、自動的にダウングレードされる可能性があります。

(2) 警告: 一部のサービスは

成功率が一定期間内に変動した場合 (たとえば、95% と 100% の間)、自動的または手動でダウングレードでき、アラームが送信されます。

(3) 間違っています

間違い: たとえば、可用性率が 90% 未満である、データベース接続プールが爆発している、またはトラフィックが突然急増し、システムが耐えられる最大値になっているなどです。

しきい値は、現時点では、状況に応じて自動的にダウングレードすることも、手動でダウングレードすることもできます。

(4) 重大なエラー：特別な理由によるデータエラーなど

、現時点では緊急手動ダウングレードが必要です。

サービスのダウングレードの目的は、データベースの雪崩問題の原因となる Redis サービスの障害を防ぐことです。したがって、無重力の人にとっては、

データをキャッシュしたい場合は、サービスのダウングレード戦略を採用できます。たとえば、Redis に問題がある場合、データは削除されないのが一般的です。

ライブラリクエリですが、デフォルト値をユーザーに直接返します。

33.ホットデータとコールドデータとは何ですか?

アリババの内部データのホット データの場合、キャッシュは重要ですが、コールド データの場合、ほとんどのデータは再びアクセスされる前にメモリから搾り出されている可能性があります。

メモリを消費するだけでなく、あまり価値がありません。頻繁に変更されるデータは、状況に応じてキャッシュの使用を検討してください。上記 2 つの例では、誕生日列が

テーブル情報やナビゲーション情報は、情報の変更頻度が高くなく、通常、読み取り率が非常に高いという特徴があります。ホットデータの場合、

たとえば、当社の IM 製品の 1 つ、誕生日ウィッシュ モジュール、およびその日の誕生日リストは、キャッシュされた後に何十万回も読み取られる可能性があります。もう一つの例

特定のナビゲーション製品では、ナビゲーション情報をキャッシュし、将来的に何百万回も読み込むことになります。データ更新前に少なくとも 2 回読み取り、キャッシュする

意味があるだけです。これは最も基本的な戦略であり、キャッシュが機能する前に失敗した場合、ほとんど意味がありません。それは節約します

それは存在し、変更頻度は非常に高いですが、キャッシュを考慮する必要があるシナリオについてはどうすればよいでしょうか? もつ！たとえば、データベースに対するこの読み取りインターフェイスの圧力

これは非常に大きいですが、ホット データです。現時点では、データベースへの負荷を軽減するためにキャッシュを考慮する必要があります。たとえば、

アシスタント製品、いいね数、お気に入り数、シェア数などは非常に一般的なホット データですが、常に変化しています。

データは Redis キャッシュに同期的に保存されるため、データベースの負荷が軽減されます。

34. MemcacheとRedisの違いは何ですか?

1) 保存方法 Memecache はすべてのデータをメモリに保存しますが、停電後はハングアップし、データはメモリ サイズを超えることはできません。

Redis の一部はハードディスク上に存在し、Redis はそのデータを永続化できます 2)、データ サポート タイプ memcached すべての値は単純です

単一の文字列 (代わりに redis) は、リスト、セット、zset、ハッシュ、およびその他のデータ構造を提供する、より豊富なデータ型をサポートします。

構造化ストレージ 3)、異なる基礎モデルを使用し、それらの間の基礎となる実装方法、およびクライアントと通信するためのアプリケーション プロトコルが異なります。

サンプル。一般的なシステムがシステム関数を呼び出すと移動に一定の時間がかかるため、Redis は VM 機構を自ら直接構築します。

动和请求。 4). value 值大小不同：Redis 最大可以达到 1gb；memcache 只有 1mb。 5）redis的

速度比memcached快很多 6）Redis支持数据的备份，即master-slave模式的数据备份。

35、单线程的redis为什么这么快

(一)纯内存操作 (二)单线程操作，避免了频繁的上下文切换 (三)采用了非阻塞I/O多路复用机制

36、redis的数据类型，以及每种数据类型的使用场景

回答：一共五种 (一)String 这个其实没啥好说的，最常规的set/get操作，value可以是String也可以

是数字。一般做一些复杂的计数功能的缓存。 (二)hash 这里value存放的是结构化的对象，比较方

便的就是操作其中的某个字段。博主在做单点登录的时候，就是用这种数据结构存储用户信息，以

cookieId作为key，设置30分钟为缓存过期时间，能很好的模拟出类似session的效果。 (三)list 使用

List的数据结构，可以做简单的消息队列的功能。另外还有一个就是，可以利用lrange命令，做基于

redis的分页功能，性能极佳，用户体验好。本人还用一个场景，很合适—取行情信息。就也是个生

产者和消费者的场景。LIST可以很好的完成排队，先进先出的原则。 (四)set 因为set堆放的是一堆

不重复值的集合。所以可以做全局去重的功能。为什么不用JVM自带的Set进行去重？因为我们的系

统一般都是集群部署，使用JVM自带的Set，比较麻烦，难道为了一个做一个全局去重，再起一个公

共服务，太麻烦了。 另外，就是利用交集、并集、差集等操作，可以计算共同喜好，全部的喜好，

自己独有的喜好等功能。 (五)sorted set sorted set多了一个权重参数score,集合中的元素能够按

アレンジするスコア。TOP N の操作を取得するリーダーボード アプリケーションとして使用できます。

37. Redis の有効期限戦略とメモリ削除メカニズム

Ali の内部データ Redis は、定期的な削除+遅延削除戦略を採用しています。タイミング削除ポリシーを使用しないのはなぜですか? タイミング削除、タイマーを使用して責任を負います

キーを監視し、有効期限が切れたら自動的に削除します。メモリは時間内に解放されますが、大量の CPU リソースを消費します。大規模な同時リクエストが発生した場合、CPU は

キーを削除するのではなく、リクエストの処理に時間がかかるため、この戦略は採用されません。定期的な削除+遅延削除はどのように機能しますか?

通常の削除では、redis はデフォルトで 100 ミリ秒ごとに期限切れのキーがあるかどうかをチェックし、期限切れのキーがある場合は削除されます。注意すべきは、

Redis は 100 ミリ秒ごとにすべてのキーをチェックするのではなく、ランダムに選択して検査します (100 ミリ秒ごとの場合、すべてのキーがチェックされます)

Redis がスタックしていないか確認してください)。したがって、通常の削除戦略のみを採用した場合、多くのキーはそれまでに削除されません。で

はい、遅延削除は便利です。つまり、キーを取得すると、redis がそれをチェックします。

有効期限 それは期限切れですか？有効期限が切れた場合は、この時点で削除されます。定期削除＋遅延削除で他に問題はないのでしょうか？

キーが定期的に削除されていない場合は、いいえ。この場合、キーをすぐに要求しませんでした。つまり、遅延削除は有効になりませんでした。これ

このようにして、redis のメモリはどんどん増えていきます。その場合は、メモリ削除メカニズムを採用する必要があります。redis.conf に設定の行があります

maxmemory-policy volatile-lru

この構成にはメモリ削除戦略が装備されています（何、設定してないの？反省してください）volatile-lru : 設定の有効期限が切れたときから

中間データ セット (server.db[i].expires) から最も最近使用されていないデータを選択して、設定された有効期限からvolatile-ttl : を削除します。

間にあるデータセット (server.db[i].expires) から期限切れになるデータを選択して、セットの期限切れからvolatile-random : を削除します。

時間データセット (server.db[i].expires) 内のデータをランダムに選択して、データセットからallkeys-lru : を削除します。

(server.db[i].dict) 最も最近使用されていないデータを選択して、データセットからallkeys-random : を削除します。

(server.db[i].dict) は、データ削除の非エンビクション(エビクション) を任意に選択します。データのエビクションを禁止し、新しい書き込み操作が行われます。

エラー ps: 有効期限のキーが設定されていない場合、前提条件 (前提条件) が満たされていない場合、volatile-lru、volatile

ランダムおよび volatile-ttl ストラテジーの動作は、基本的に noeviction (削除されない) と同じです。

38. Redis がシングルスレッドなのはなぜですか?

公式 FAQ には、Redis はメモリベースの操作であるため、CPU は Redis のボトルネックではなく、Redis のボトルネックはマシンである可能性が高いと記載されています。

メモリまたはネットワーク帯域幅のサイズ。シングルスレッドは実装が簡単で、CPU がボトルネックにならないため、シングルスレッドを使用するのが合理的です。

スレッド ソリューション (結局のところ、マルチスレッドでは多くの問題が発生します!) Redis はキュー テクノロジを使用して同時アクセスをシリアル アクセスに変更します 1)

リクエストの大部分は純粋なメモリ操作 (非常に高速) 2) シングルスレッド、不必要なコンテキストの切り替えと競合状態を回避

項目 3) ノンブロッキング IO の利点:

HashMap と同様にデータがメモリに保存されるため速度が速く、HashMap の利点は検索と操作の時間の複雑さです。

複雑さは O(1)

豊富なデータ型をサポートし、文字列、リスト、セット、ソートされたセット、ハッシュをサポート

トランザクションがサポートされ、操作はアトミックです。いわゆるアトミック性とは、データに対するすべての変更が実行されるか、まったく実行されないかのいずれかであることを意味します。

豊富な機能: キャッシュ、メッセージに使用でき、キーごとに有効期限を設定でき、有効期限が切れたら自動的に削除されます。

同時競合キーの問題

Ali の内部データには、キーを同時に設定するための複数のサブシステムがあります。このとき私たちは何に注意すべきでしょうか？

Redis のトランザクション メカニズムは推奨されません。米国のせいで

本番環境は基本的に Redis クラスター環境であり、データの断片化操作が行われています。トランザクションに複数のキー操作が含まれている

場合によっては、これらの複数のキーが必ずしも同じ redis サーバーに保存されているとは限りません。したがって、redis のトランザクションメカニズムは非常に悪趣味です。(1)

このキーを操作する場合、次の順序は必要ありません。

分散ロックを用意し、全員でロックを掴み、ロックを掴んだ後はset操作を行うだけ(2)

このキーを操作する場合は、次の順序が必要です。

分散ロック + タイムスタンプ。システム B が最初にロックを取得すると仮定して、key1 を次のように設定します。

{値B 3:05}。次に、システム A はロックを取得し、自身の valueA のタイムスタンプがキャッシュ内のタイムスタンプよりも古いことを発見したため、ロックを取得しません。

セット操作。等々。(3) キューを使用して set メソッドをシリアル アクセスに変更すると、redis も高い同時実行性を実現できます。

キーの読み取りと書き込みの一貫性は、Redis 操作ではアトミックであり、スレッドセーフな操作であるため、同時実行性の問題を考慮する必要はありません。

この部門はすでに同時実行性の問題への対処を支援しています。

39. Redis の一般的なパフォーマンスの問題と解決策?

(1) マスターは、R​​DB メモリのスナップショットや AOF ログ ファイルなどの永続的な作業を行わないのが最善です (2) データが重い場合

スレーブが AOF バックアップ データを開始する場合、マスター/スレーブ レプリケーションの速度と接続の安定性のために、戦略は 1 秒に 1 回同期するように設定されます (3)。

定性的には、マスターとスレーブが同じローカル エリア ネットワーク内にある方が良いです (4) 高圧下でマスター ライブラリにスレーブ ライブラリを追加しないようにしてください (5) マスターとスレーブ

レプリケーションにはグラフ構造を使用しないでください。一方向リンク リスト構造、つまりマスター <- スレーブ 1 <- スレーブ 2 <- スレーブ 3… を使用する方が安定しています。

40. Redisの操作がアトミックであるのはなぜですか?また、アトミック性を確保する方法は何ですか?

Redis の場合、コマンドのアトミック性は、操作を細分化することができず、操作が実行されるか実行されないかのいずれかであることを意味します。

Redis の操作がアトミックである理由は、Redis がシングルスレッドであるためです。Redis 自体が提供するすべての API はアトミック操作です

実際、Redis のトランザクションは、バッチ操作のアトミック性を保証することを目的としています。複数のコマンドも同時実行でアトミックですか?

違う

そうです、

get と set を単一コマンド操作に変更します。Redis トランザクションを使用するか、Redis+Lua== を使用して実現します。

41. Redisトランザクションを理解していますか?

Redis のトランザクション機能は、MULTI、EXEC、DISCARD、WATCH の 4 つのプリミティブによって実現されます。

すべてのコマンドはシリアル化され、順番に実行されます。1. Redis はロールバックをサポートしていません。「Redis はトランザクションが失敗してもロールバックせず、続行します。」

残りのコマンドの実行を続行します",

そのため、Redis の内部をシンプルかつ高速に保つことができます。2. トランザクション内のコマンドでエラーが発生した場合

エラーがある場合、すべてのコマンドは実行されません。 3. トランザクションでエラーが発生した場合、正しいコマンドが実行されます。

1) MULTI コマンドはトランザクションの開始に使用され、常に OK を返します。MULTI の実行後、クライアントは送信を続けることができます。

任意の数のコマンドを送信します。これらのコマンドはすぐには実行されませんが、EXEC コマンドが呼び出されたときにキューに入れられます。

キュー内のコマンドのみが実行されます。2) EXEC: すべてのトランザクション ブロックでコマンドを実行します。トランザクションブロック内のすべてのコマンドの戻り値を返します。

値はコマンドが実行される順序でリストされます。操作が中断された場合は nil を返します。3) DISCARD を呼び出すことにより、クライアントは

エンドはトランザクション キューを空にしてトランザクションの実行を放棄することができます。

そしてクライアントはトランザクション状態から抜け出します。4) WATCH コマンドは次のことができます。

为 Redis 事务提供 check-and-set （CAS）行为。 可以监控一个或多个键，一旦其中有一个键被修

改（或删除），之后的事务就不会执行，监控一直持续到EXEC命令。

42、Redis 的数据类型及使用场景

String

阿里内部资料最常规的 set/get 操作，Value 可以是 String 也可以是数字。一般做一些复杂的计数功能的缓存。

Hash

这里 Value 存放的是结构化的对象，比较方便的就是操作其中的某个字段。我在做单点登录的时

候，就是用这种数据结构存储用户信息，以 CookieId 作为 Key，设置 30 分钟为缓存过期时间，能

很好的模拟出类似 Session 的效果。

List

使用 List 的数据结构，可以做简单的消息队列的功能。另外，可以利用 lrange 命令，做基于 Redis

的分页功能，性能极佳，用户体验好。

Set

因为 Set 堆放的是一堆不重复值的集合。所以可以做全局去重的功能。我们的系统一般都是集群部

署，使用 JVM 自带的 Set 比较麻烦。另外，就是利用交集、并集、差集等操作，可以计算共同喜

好，全部的喜好，自己独有的喜好等功能。

Sorted Set

Sorted Set 多了一个权重参数 Score，集合中的元素能够按 Score 进行排列。可以做排行榜应用，

取 TOP(N) 操作。Sorted Set 可以用来做延时任务。

分布式篇

1、分布式幂等性如何设计？

在高并发场景的架构里，幂等性是必须得保证的。比如说支付功能，用户发起支付，如果后台没有

做幂等校验，刚好用户手抖多点了几下，于是后台就可能多次受到同一个订单请求，不做幂等很容

易就让用户重复支付了，这样用户是肯定不能忍的。

解决方案

1，查询和删除不在幂等讨论范围，查询肯定没有幂等的说，删除：第一次删除成功后，后面来删

除直接返回0，也是返回成功。

2. 一意のインデックスを構築します。新しいデータにダーティ データが含まれるのを防ぐため、一意のインデックスまたは一意の組み合わせインデックスを作成します (テーブル内に一意のインデックスがある場合、同時実行

例外が追加された場合は、再度クエリを実行するだけです。データはすでに存在しているはずなので、結果を返すだけです)。

3. トークン メカニズム: クリックの繰り返し、ネットワークの再送信、または nginx の再送信により、データは繰り返し送信されます。フロントエンド

データを送信する前に、バックエンド サービスからトークンを申請する必要があります。トークンは Redis または JVM メモリに配置され、一定期間有効です。提出後

バックグラウンドでトークンを確認し、同時にトークンを削除し、新しいトークンを生成して戻ります。Redis は削除操作を使用してトークンを判断し、トークンを削除する必要があります。

この関数はトークンの検証に合格することを意味しますが、トークンの検証に select+delete を使用すると同時実行の問題が発生するため、使用することはお勧めできません。

4. 悲観的なロック

Ali 内部データ悲観的ロックは通常、トランザクションと一緒に使用されます。データ ロック時間が非常に長い場合があります。実際の状況に応じて選択してください (さらに考慮してください)

ID が主キーであるかどうかを検討し、ID が主キーまたは InnoDB ストレージ エンジンでない場合は、テーブル全体がロックされます)。

5. オプティミスティックロック。データベーステーブルにバージョンフィールドを追加します。このフィールドを使用して、変更されたかどうかを判断できます。

6. 分散ロック (Redis や Zookeeper の分散ロックなど)。単一の番号がキーであり、キーの有効期間を設定します（支払いを防ぐため）

決済失敗後はロックは解除されません）、注文番号を使用してロックを生成するリクエストが来て、ビジネスコードの実行が完了するとロックが解除されます。

7.保証プランでは、まず注文が存在するかどうかを確認し、存在しない場合は支払いを行い、存在する場合は支払い結果を直接返します。

2.完全なHTTPリクエストの手順は何ですか?

1. DNS 解決 (アクセスされたドメイン名、再帰検索を通じて IP アドレスを見つけます)。

2. HTTP リクエスト。リクエストが入力されると、Socket 接続が確立され、TCP 3-way ハンドシェイクが開始されます。

HTTPS リクエストの場合は少し異なります。HTTPS セクションまで待ってください。話は変わります。

3.1. クライアントはリクエスト コマンド (通常は GET または POST リクエスト) をサーバーに送信します。

これは補足的な内容であり、インタビューは基本的に回答する必要はありません。

クライアントのネットワーク層は、アプリケーション層やトランスポート層を気にする必要はありません。

サーバーに到達するために、複数のルーターを通過することがあります。これらはルーターによって行われる作業です。あまり多くのことは行いません。

この説明は、ルーティング テーブルを参照してサーバーに到達するパスを決定することに他なりません。

クライアントのリンク層、パケットはリンク層を通じてルーターに送信され、指定された IP アドレスの MAC アドレスが近隣プロトコルを通じて検索されます。

アドレスを指定し、宛先アドレスを見つけるために ARP リクエストを送信します。応答を受け取った場合は、ARP リクエストとリプライの交換を使用できます。

これで IP パケットの送信準備が整い、IP パケットはサーバーのアドレスに送信されます。

3.2. クライアントはリクエストのヘッダー情報とデータを送信します。

4.1. サーバーは応答ヘッダー情報を送信します。

4.2. サーバーはクライアントにデータを送信します。

5. サーバーは TCP 接続を閉じます (4 回ウェーブ)。

ここで TCP 接続を閉じるかどうかは、HTTP キープアライブ メカニズムにも関係します。

同時に、クライアントは TCP 接続の終了をアクティブに開始することもできます。

6. クライアントは、返された HTML、CSS、および JS に従ってレンダリングします。

更新のために id='##' の table_# から id 、name を選択します。

update table_xxx set name=#name#,version=version+1 where version=#version#

Ali の内部情報3.分散トランザクションについての理解を教えてください

分散トランザクションは企業統合における技術的な困難であり、あらゆる分散システム アーキテクチャに関係するものでもあります。

特にマイクロサービスアーキテクチャにおいては、避けては通れないと言ってもいいほどです。

まず第一に、ACID、CAP、BASE 理論を理解する必要があります。

酸

データベース トランザクションを正しく実行するための 4 つの基本要素を指します。

1. 原子性

2. 一貫性

3. 隔離

4. 耐久性

キャップ

CAP 原則は、CAP 定理とも呼ばれ、一貫性 (一貫性)、可用性、

(可用性)、パーティション許容値 (パーティション許容値)。CAP 原則では、これら 3 つの要素は最大でも

2つの点を同時に実現し、3つすべてを考慮することは不可能です。

Alibaba 内部データの一貫性: 分散システム内のすべてのデータ バックアップが同時に同じ値を持つかどうか。

可用性: クラスター内の一部のノードに障害が発生した後でも、クラスター全体がクライアントの読み取りおよび書き込みリクエストに応答できるかどうか。

分割耐性: 実際の効果という点では、分割は通信の時間制限要件と同等です。制限時間内にシステムが番号に到達できない場合

一貫性によれば、これはパーティションが発生したことを意味し、現在の操作では C と A のどちらかを選択する必要があります。

BASE理論

BASE 理論は、CAP における一貫性と使いやすさの間のトレードオフの結果です。理論の核となる考え方は次のとおりです。

強力な一貫性。各アプリケーションは、独自のビジネス特性に応じて適切な方法を使用して、システムの最終的な一貫性を実現できます。

基本的に利用可能

ソフトな状態

最終的に一貫性のある (最終的な一貫性)

4.どのような分散トランザクション ソリューションを知っていますか?

私が知っている限りでは次の 5 つがあります。

1. 2フェーズコミット(2PC)

2. 3フェーズコミット(3PC)

3. 補償取引（TCC=Try-Confirm-Cancel）

4. ローカルメッセージキューテーブル（MQ）

5. Sagas トランザクション モデル (結果整合性)

上記の 5 つのタイプについて話した後、面接官は通常、次の質問を続けます (1 つか 2 つだけ、またはすべての場合もあります)。

5. 2フェーズコミットとは何ですか?

2 フェーズ コミット 2PC は、分散トランザクションで最も強力なトランザクション タイプの 1 つです。2 フェーズ コミットは、次の 2 つのフェーズでコミットされます。

最初のフェーズでは、各トランザクション データ ソースの準備ができているかどうかを尋ねます。

2 番目のフェーズでは、実際にデータをトランザクション データ ソースにコミットします。

トランザクションが ACID を満たすことを保証するには、コーディネーター (Cooradinator) を導入する必要があります。他のノードは参加者と呼ばれます

（参加者）。コーディネーターは、参加者の動作をスケジュールし、最終的にこれらの参加者がトランザクションをコミットするかどうかを決定する責任があります。

処理の流れは以下の通りです。

アリババ内部データステージ 1

a) コーディネーターはトランザクションの内容をすべての参加者に送信し、トランザクションをコミットできるかどうかを尋ね、応答を待ちます。

b) 各参加者はトランザクション操作を実行し、元に戻すおよびやり直しの情報をトランザクション ログに記録します (ただし、トランザクションはコミットしません)。

c) 如参与者执行成功，给协调者反馈 yes，否则反馈 no。

阶段二

如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(rollback)消息；否则，

发送提交(commit)消息。两种情况处理如下：

情况1：当所有参与者均反馈 yes，提交事务

a) 协调者向所有参与者发出正式提交事务的请求（即 commit 请求）。

b) 参与者执行 commit 请求，并释放整个事务期间占用的资源。

c) 各参与者向协调者反馈 ack(应答)完成的消息。

d) 协调者收到所有参与者反馈的 ack 消息后，即完成事务提交。

情况2：当有一个参与者反馈 no，回滚事务

a) 协调者向所有参与者发出回滚请求（即 rollback 请求）。

b) 参与者使用阶段 1 中的 undo 信息执行回滚操作，并释放整个事务期间占用的资源。

c) 各参与者向协调者反馈 ack 完成的消息。

d) 协调者收到所有参与者反馈的 ack 消息后，即完成事务。

问题

阿里内部资料1) 性能问题：所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。

2) 可靠性问题：如果协调者存在单点故障问题，或出现故障，提供者将一直处于锁定状态。

3) 数据一致性问题：在阶段 2 中，如果出现协调者和参与者都挂了的情况，有可能导致数据不一

致。

优点：尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证

强一致）。

短所:実装が複雑で、可用性が犠牲になり、パフォーマンスが大きく影響されるため、同時実行性が高くパフォーマンスが高いシナリオには適していません。

6. 3 フェーズ コミットとは何ですか?

3 フェーズ コミットは 2 フェーズ コミットを改良したもので、3PC が解決すべき最も重要な点は、コーディネータと参加者が同時に電話を切るという問題です。

そこで、3PCでは2PCの準備フェーズを再度2つに分け、3フェーズで提出できるようにしています。

処理の流れは以下の通りです。

ステージ1

a) コーディネーターは、トランザクションの内容を含む canCommit リクエストをすべての参加者に送信し、トランザクションをコミットできるかどうかを尋ね、すべての参加者がコミットできるのを待ちます。

参加者が答えた。

b) canCommit リクエストを受信した後、参加者がトランザクション操作を実行できると考える場合は、「はい」をフィードバックして準備状態に入ります。

それからフィードバックNo.

ステージ2

コーディネーターは参加者の反応に応じて、次の 2 つの可能性を考えます。

ケース1 :すべての参加者が「はい」とフィードバックし、コーディネーターがトランザクションを事前実行します。

a) コーディネーターは、すべての参加者に preCommit リクエストを送信し、準備フェーズに入ります。

b) preCommit リクエストを受信した後、参加者はトランザクション操作を実行し、元に戻すおよびやり直しの情報をトランザクション ログに記録します (ただし、トランザクション ログには記録されません)。

トランザクションをコミットします)。

c) 各参加者はコーディネーターに ack 応答または no 応答をフィードバックし、最後の指示を待ちます。

アリの内部情報状況2 : 1 人の参加者が「いいえ」とフィードバックするか、コーディネーターがタイムアウトを待ってもすべてのプロバイダーからフィードバックを受信できない限り、中断されます。

事務

a) コーディネーターは、すべての参加者に中止要求を送信します。

b) コーディネーターからの中止リクエストの受信、またはコーディネーターからのリクエスト待機中のタイムアウトに関係なく、参加者はイベントを中止します。

サービス。

ステージ3

この段階でコミットされる実際のトランザクションは、次の 2 つの状況に分けることもできます。

ケース1 :すべての参加者が ack 応答をフィードバックし、実際のトランザクションのコミットを実行する

a) コーディネーターが動作している場合は、すべての参加者に do Commit リクエストを発行します。

b) do Commit リクエストを受信した後、参加者はトランザクションのコミットを正式に実行し、トランザクション全体で占有されていたリソースを解放します。

c) 各参加者は、ack 完了メッセージをコーディネーターにフィードバックします。

d) コーディネーターがすべての参加者からフィードバックされた確認メッセージを受信すると、トランザクションの送信が完了します。

状況2 : 1 人の参加者が「いいえ」とフィードバックするか、調整グループがタイムアウト (ロールバック) を待った後にすべてのプロバイダーからフィードバックを受信できない限り、

事務。

a) コーディネーターが動作している場合は、すべての参加者にロールバック リクエストを送信します。

b) 参加者はフェーズ 1 のアンドゥ情報を使用してロールバック操作を実行し、トランザクション全体で占有されていたリソースを解放します。

c) 各参加者は、ack 完了のメッセージを調整グループにフィードバックします。

d) 調整グループがすべての参加者からフィードバックされた確認メッセージを受信すると、トランザクションのロールバックが完了します。

利点: 2 フェーズ コミットと比較して、3 フェーズ コミットはブロックの範囲を減らし、コーディネーターまたは参加者はタイムアウトを待った後にトランザクションを中断します。

コーディネーターの単一点の問題を回避します。フェーズ 3 でコーディネーターに問題が発生した場合、参加者はトランザクションの送信を続行します。

短所:データの不整合の問題は依然として存在します。参加者が preCommit リクエストを受信し、do commit コマンドを待機すると、

このとき、コーディネーターがトランザクションの中断を要求しても、コーディネーターが参加者と正常に通信できない場合、参加者はトランザクションの送信を続行するため、

一貫性のないデータ。

7.補償事務とは何ですか?

TCC (Try confirm Cancel) はサービス指向の 2 段階プログラミング モデルであり、次の補償メカニズムが採用されています。

Ali の内部データ TCC は、実際に採用されている補償メカニズムであり、その中心的な考え方は、各操作に対して、対応する確認と補償を登録する必要があるということです。

払い戻し（元に戻す）操作。

それは 3 つのステップに分かれています。

Try ステージでは、主にビジネス システムをテストし、リソースを予約します。

確認ステージは主に業務システムの確認と提出を行います。試行ステージが正常に実行され、確認ステージが開始されると、デフォルトの

確認段階では間違うことはあり得ません。つまり、Try が成功する限り、confirm も成功する必要があります。

Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

举个例子，假入你要向 老田 转账，思路大概是：

我们有一个本地方法，里面依次调用步骤： 1、

首先在 Try 阶段，要先调用远程接口把 你 和 老田 的钱给冻结起来。 2、在 Confifirm 阶段，执行远

程调用的转账的操作，转账成功进行解冻。 3、如果第2步执行成功，那么转账成功，如果第二步执

行失败，则调用远程冻结接口对应的解冻方法 (Cancel)。

优点：

性能提升：具体业务来实现控制资源锁的粒度变小，不会锁定整个资源。

数据最终一致性：基于 Confifirm 和 Cancel 的幂等性，保证事务最终完成确认或者取消，保证数据

的一致性。

可靠性：解决了 XA 协议的协调者单点故障问题，由主业务方发起并控制整个业务活动，业务活动

管理器也变成多点，引入集群。

缺点：TCC 的 Try、Confifirm 和 Cancel 操作功能要按具体业务来实现，业务耦合度较高，提高了开

发成本。

阿里内部资料8、消息队列是怎么实现的？

本地消息表（异步确保）

本地消息表这种实现方式应该是业界使用最多的，其核心思想是将分布式事务拆分成本地事务进行

处理，这种思路是来源于ebay。我们可以从下面的流程图中看出其中的一些细节：

基本思路就是：

消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提

交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送

失败，会进行重试发送。

消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经

处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个

业务补偿消息，通知生产方进行回滚等操作。

生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有

信頼性の高い自動アカウント調整補充ロジック、このソリューションは依然として非常に実用的です。

このスキームは BASE 理論に準拠し、最終整合性を採用しており、実際のビジネスシーンにより適していると筆者は考えています。

つまり、2PC のような複雑な実装はなく (呼び出しチェーンが非常に長い場合、2PC の可用性は非常に低くなります)、次のようなものにはなりません。

TCC と同様に、確認やロールバックを実行できない状況が発生する場合があります。

アドバンテージ：

分散トランザクションを回避し、最終的な整合性を実現する非常に古典的な実装です。.NETには既製のソリューションがあります

場合。

欠点:

メッセージテーブルは業務システムと連動するため、パッケージ化されたソリューションがなければ、対応する手間が多くなります。

MQトランザクションメッセージ

Ali の内部情報によると、一部のサードパーティ MQ は、RocketMQ などのトランザクション メッセージをサポートしています。トランザクション メッセージをサポートする方法も、

2 フェーズ コミットですが、市場の一部の主流 MQ は、RabbitMQ や Kafka などのトランザクション メッセージをサポートしていません。

サポート。

Ali の RocketMQ ミドルウェアを例に挙げると、そのアイデアはおおよそ次のとおりです。

Prepared メッセージの最初の段階では、メッセージのアドレスが取得されます。第 2 ステージはローカル トランザクションを実行し、第 3 ステージは第 1 ステージを通過します。

メッセージにアクセスして状態を変更するためのアドレス。

つまり、ビジネス メソッドでは、メッセージ キューに 2 つのリクエスト (メッセージの送信用とメッセージの確認用) を送信するとします。確認メッセージの場合

送信に失敗した場合、RocketMQ はメッセージ クラスター内のトランザクション メッセージを定期的にスキャンし、準備されたメッセージを見つけると送信します。

メッセージ送信者が確認するため、プロデューサーはチェック インターフェイスを実装する必要があり、RocketMQ は送信者が設定した戦略に基づいているかどうかを判断します。

ロールバックするか、確認メッセージの送信を継続するか。これにより、ローカル トランザクションと同時にメッセージ送信が成功または失敗することが保証されます。

残念ながら、RocketMQ には .NET クライアントがありません。RocketMQ の詳細については、このブログをご覧ください。

アドバンテージ：

ローカルデータベーストランザクションに依存せずに結果整合性を実現します。

欠点:

実装は難しく、主流の MQ はサポートしておらず、.NET クライアントも存在せず、RocketMQ トランザクション メッセージの一部のコードはオープン ソースではありません。

9.次に、 Sagasトランザクション モデルについて話します。

Saga モードは、分散非同期トランザクション、結果整合性トランザクション、および柔軟なトランザクションです。実装するには 2 つの異なる方法があります。

saga トランザクションを実装する最も一般的な方法は次の 2 つです。

1. イベント/コレオグラフィーコレオグラフィー: 中央のコーディネーターが存在しない (単一リスク ポイントがない) 場合、各サービスは他のサービスを生成してリッスンします。

イベントをサービスし、アクションを実行する必要があるかどうかを決定します。

Ali の内部データは、トランザクションを実行する最初のサービスを実装してから、イベントを発行する必要があります。イベントは 1 つ以上のサービスによってリッスンされます。

サービスはローカル トランザクションを実行し、新しいイベントを公開します (または公開しません)。一方、最後のサービスはローカル トランザクションを実行し、何も公開しません。

イベントは、分散トランザクションが終了するか、発行されたイベントが Saga 参加者のいずれにも届かず、トランザクションが終了することを意味します。

処理フローの説明:

注文サービスは新しい注文を保存し、状態を保留状態に設定し、ORDER_CREATED_EVENT という名前のイベントを発行します。

イベント。

決済サービスは ORDER_CREATED_EVENT をリッスンし、イベント BILLED_ORDER_EVENT を発行します。

インベントリ サービスは BILLED_ORDER_EVENT をリッスンし、インベントリを更新し、ORDER_PREPARED_EVENT を発行します。

貨物サービスは ORDER_PREPARED_EVENT をリッスンして、製品を配送します。ついに公開します

ORDER_DELIVERED_EVENT。

最後に、注文サービスは ORDER_DELIVERED_EVENT をリッスンし、注文のステータスを完了に設定します。

トランザクション中にインベントリ サービスが失敗したとします。ロールバックするには:

インベントリ サービスは PRODUCT_OUT_OF_STOCK_EVENT を生成します

注文サービスと支払いサービスは、上記の在庫サービスのこのイベントをリッスンします。

①決済サービスはお客様に返金されます。

② 注文サービスは注文ステータスを失敗に設定します。

利点:イベント/オーケストレーションは Saga パターンを実装する自然な方法です。シンプルで理解しやすく、構築に多くの労力を必要としません。

すべてのアクターは相互に直接結合していないため、疎結合になります。トランザクションに 2 ～ 4 つのステップが含まれる場合、

非常に適しているかもしれません。

2. コマンド/調整オーケストレーター: 中央コーディネーターは、集中処理イベントの意思決定とビジネス ロジックの分類を担当します。

saga コーディネーター Orchestrator は、コマンド/応答方式で各サービスと通信し、実行すべきアクションをサービスに伝えます。

注文サービスは保留状態を保存し、Order Saga Coordinator (略して OSO) に注文トランザクションを開始するように要求します。

OSO は支払い実行コマンドを収集サービスに送信し、収集サービスは支払い実行メッセージで応答します。

OSO は、Prepare Order コマンドを Inventory Service に送信し、Inventory Service は OrderPrepared メッセージで応答します。

OSO は注文配送コマンドを貨物サービスに送信し、貨物サービスは Order Delivered メッセージで応答します。

OSO Order Saga コーディネーターは、(BPM ビジネス プロセス XML 構成を読み取ることによって) 「注文の作成」トランザクションを実行するために必要なプロセスを事前に知っておく必要があります。

得る）。また、失敗した場合に以前のアクションを元に戻すコマンドを各参加者に送信することで、分散フィードバックを調整する責任もあります。

ロール。中央のコーディネーターがすべてを調整すると、ロールバックがはるかに簡単になります。コーディネーターがデフォルトで順方向のフローを実行し、ロールバックするためです。

逆の手順を実行するだけです。

アドバンテージ：

saga コーディネーターは saga アクターを呼び出しますが、アクターはコーディネーターを呼び出すことはないため、サービス間の循環依存関係を避けてください。

集中分散トランザクションのオーケストレーション。

コマンド/応答を実行するだけでよいため (実際、応答メッセージも一種のイベント メッセージです)、参加者の複雑さが軽減されます。

新しいステップが追加されてもトランザクションの複雑さは線形のままであり、ロールバックの管理が容易になります。

内部情報もアリ 最初のトランザクションが実行される前に 2 番目のトランザクションの対象オブジェクトを変更したい場合、調整で簡単に一時停止できます

最初のトランザクションが終了するまでサーバー上に保存されます。

10.分散ID生成にはいくつのスキームがありますか?

分散型IDの特徴

一意性: 生成された ID がネットワーク全体で一意であることを確認します。

順序どおりに増加: 生成された ID が、特定のユーザーまたはビジネスに対して特定の数値ずつ順番に増加するようにします。

高可用性: ID がいつでも正しく生成できるようにします。

带时间：ID里面包含时间，一眼扫过去就知道哪天的交易。

分布式ID生成方案

1. UUID

算法的核心思想是结合机器的网卡、当地时间、一个随记数来生成UUID。

优点：本地生成，生成简单，性能好，没有高可用风险

缺点：长度过长，存储冗余，且无序不可读，查询效率低

2. 数据库自增ID

使用数据库的id自增策略，如 MySQL 的 auto_increment。并且可以使用两台数据库分别设置不同

步长，生成不重复ID的策略来实现高可用。

优点：数据库生成的ID绝对有序，高可用实现方式简单

缺点：需要独立部署数据库实例，成本高，有性能瓶颈

3. 批量生成ID

阿里内部资料一次按需批量生成多个ID，每次生成都需要访问数据库，将数据库修改为最大的ID值，并在内存中

记录当前值及最大值。

优点：避免了每次生成ID都要访问数据库并带来压力，提高性能

缺点：属于本地生成策略，存在单点故障，服务重启造成ID不连续

4. Redis生成ID

Redis的所有命令操作都是单线程的，本身提供像 incr 和 increby 这样的自增原子命令，所以能保

证生成的 ID 肯定是唯一有序的。

优点：不依赖于数据库，灵活方便，且性能优于数据库；数字ID天然排序，对分页或者需要排

序的结果很有帮助。

缺点：如果系统中没有Redis，还需要引入新的组件，增加系统复杂度；需要编码和配置的工作

量比较大。

考虑到单节点的性能瓶颈，可以使用 Redis 集群来获取更高的吞吐量。假如一个集群中有5台

Redis。可以初始化每台 Redis 的值分别是1, 2, 3, 4, 5，然后步长都是 5。

5. Twitterのスノーフレークアルゴリズム(強調)

Twitter は Zookeeper を使用してグローバル ID 生成サービス Snowflake を実装

上の図に示すように、Twitter の Snowflake アルゴリズムは次の部分で構成されます。

1ビットの符号ビット:

Javaではlong型は符号付きなので、最上位ビットが符号ビットとなり、正の数は0、負の数は1となり、実際のシステムでは

通常、ID は正の数であるため、最上位ビットは 0 です。

41ビットのタイムスタンプ (ミリ秒レベル):

ここでの41ビットタイムスタンプは現在時刻のタイムスタンプではなく、タイムスタンプ（現在時刻）の差であることに注意してください。

スタンプ - 開始タイムスタンプ)、開始タイムスタンプは通常、プログラムによって指定された ID ジェネレーターによって使用されるタイムスタンプであるため、41

ビットミリ秒のタイムスタンプは、(1 << 41) / (1000x60x60x24x365) = 69 年まで使用できます。

10データマシンビット:

Ali の内部情報には、5 データ識別ビットと 5 マシン識別ビットが含まれます。これらの 10 ビットにより、分散システムに最大 1 << 10 = 1024 を展開できることが決まります。

のノード。この数を超えると、生成された ID が競合する可能性があります。

12桁のミリ秒単位のシーケンス:

この 12 ビットのカウントは、各ノードがミリ秒あたり最大 1 << 12 = 4096 ID を生成することをサポートします (同じマシン、同じ瞬間)。

合計するとちょうど 64 ビットになり、Long 型になります。

利点: 高性能、低遅延、時間順に並べられ、通常は ID の衝突が発生しません。

短所: マシンのクロックに依存し、独立した開発と展開が必要

6.百度Uidジェネレーター

UidGenerator は Baidu のオープンソースの分散 ID ジェネレーターで、snowflake アルゴリズムの実装に基づいており、問題ないようです。いいえ

しかし、国内のオープンソースプロジェクトの保守性は非常に心配です。

7.美団の葉

Leaf は Meituan のオープンソース分散 ID ジェネレーターであり、グローバルな一意性、増加傾向、単調増加、情報セキュリティを保証できます。

いくつかの分散スキームの比較について言及されていますが、リレーショナル データベースや Zookeeper などのミドルウェアも必要です。

11.べき等解とは何ですか?

べき等とは何ですか?

共通の説明: 同じリクエストに対しては同じ結果が返される必要があるため、クエリ クラス インターフェイスは自然な冪等インターフェイスです。

本当の答え: 冪等とは、同じリクエスト (同一のリクエスト) が 1 回以上実行されることによって引き起こされる副作用を指します。

（副作用）も同様です。

べき等とは何ですか?

フロントエンドはバックエンド インターフェイスを呼び出して支払いタイムアウトを開始し、再度再試行を開始します。複数回の支払いが発生する可能性があります。

Dubbo には再試行メカニズムもあります。

ページ上で複数回クリックします。

私たちが望んでいるのは、インターフェイスの冪等性は、実際にはインターフェイスを繰り返し呼び出すことができるということです。呼び出し元が複数回呼び出した場合、インターフェイスは最終的に

得られた結果は一貫しています。

解決

データを挿入するときは、重複排除テーブルを挿入し、データベースの一意のインデックス機能を使用して、一意のロジックを確保します。

悲観的ロック (更新用に選択) は、実行プロセス全体で注文に対応するレコードをロックします。注: DB でのこの種の読み取りは、書き込みよりも高速です。

使用量はできるだけ少なくしてください。

Ali の内部データは最初にクエリされ、次にデータが変更されます。同時実行性の低いバックグラウンド システムや一部のタスク ジョブの冪等性と繰り返し実行をサポートするために、次のことが簡単です。

単一の処理方法は、まずいくつかのキーデータを問い合わせ、それが実行されたかどうかを判断し、業務処理を実行することです。ノート

注: このメソッドは、コアの同時実行性の高いプロセスには使用しないでください。

ステートマシンは冪等であるため、ドキュメント関連のビジネスやタスク関連のビジネスを設計する際には必ずステートマシン、つまり業務命令が関与します。

上記の状態に従って、状態はさまざまな状況下で変化します。一般に、有限状態マシンが存在します。このとき、状態が

ステートマシンはすでに次の状態にありますが、このとき、理論的には変更できない前の状態への変化が生じます。

その後、有限状態マシンの冪等性が保証されます。

ページの繰り返し送信を防ぐためのトークン メカニズム:

集群环境：采用token加redis（redis单线程的，处理需要排队）或者

单JVM环境：采用token加redis或token加jvm内存

数据提交前要向服务的申请token，token放到redis或jvm内存，设置token有效时间，提交后后台

校验token，同时删除token，生成新的token返回。token特点：要申请，一次有效性，可以限流。

全局唯一ID，如果使用全局唯一ID，就是根据业务的操作和内容生成一个全局ID，在执行操作前先

根据这个全局唯一ID是否存在，来判断这个操作是否已经执行。如果不存在则把全局ID，存储到存

储系统中，比如数据库、redis等。如果存在则表示该方法已经执行。

12，常见负载均衡算法有哪些？

13、你知道哪些限流算法？

限流算法有四种常见算法：

计数器算法（固定窗口）

滑动窗口

漏桶算法

令牌桶算法

阿里内部资料14、说说什么是计数器（固定窗口）算法

计数器算法是使用计数器在周期内累加访问次数，当达到设定的限流值时，触发限流策略。下一个

周期开始时，进行清零，重新计数。

此算法在单机还是分布式环境下实现都非常简单，使用redis的incr原子自增性和线程安全即可轻松

实现。

这个算法通常用于QPS限流和统计总访问量，对于秒级以上的时间周期来说，会存在一个非常严重

的问题，那就是临界问题，如下图：

假设1min内服务器的负载能力为100，因此一个周期的访问量限制在100，然而在第一个周期的最

后5秒和下一个周期的开始5秒时间段内，分别涌入100的访问量，虽然没有超过每个周期的限制

量，但是整体上10秒内已达到200的访问量，已远远超过服务器的负载能力，由此可见，计数器算

法方式限流对于周期比较长的限流，存在很大的弊端。

15、说说什么是滑动窗口算法

スライディング ウィンドウ アルゴリズムは、期間を N 個の小さな期間に分割し、各小さな期間内の訪問数を記録し、時間に従ってスライドします。

期限切れのミニサイクルを削除します。

以下の図に示すように、時間を 1 分と仮定し、1 分を 2 つの小さな期間に分割し、それぞれの小期間内の訪問数をカウントすると、次のことがわかります。

最初の期間では訪問数が 75 で、第 2 期間では訪問数が 100 で、100 を超える訪問数は

抑制されました

Ali の内部データから、スライディング ウィンドウがより多くのグリッドに分割されるほど、スライディング ウィンドウのスクロールがよりスムーズになり、現在の制限統計がより正確になることがわかります。

それはそう。

このアルゴリズムは、固定ウィンドウ アルゴリズムの重大な問題をうまく解決できます。

16.リーキーバケットアルゴリズムとは何かについて話す

リーキーバケットアルゴリズムとは、アクセスリクエストが到着すると、アクセスリクエストを直接リーキーバケットに投入し、現在の容量が上限（電流制限値）に達した場合には破棄（トリガー）するというものです。

スロットリング戦略)。リーキー バケットは、リーキー バケットが空になるまで、固定レートでアクセス リクエストを解放します (つまり、リクエストは通過します)。

アリの内部情報17.トークンバケットアルゴリズムとは

トークン バケット アルゴリズムでは、トークン バケットがいっぱいになり、リクエストが到着するまで、プログラムが r (r=期間/現在の制限値) の速度でトークン バケットにトークンを追加します。

時間が来たら、トークン バケットからトークンをリクエストします。トークンが取得された場合、リクエストは渡されます。そうでない場合、電流制限ポリシーがトリガーされます。

アリの内部情報18.データベースは大量のデータをどのように処理しますか?

データベースの場合: サブデータベース サブテーブル、マスター/スレーブ アーキテクチャ、読み取り/書き込み分離。

横型サブライブラリ/サブテーブル、縦型サブライブラリ/サブテーブル。

水平方向のサブライブラリ/テーブルでは、各ライブラリとテーブルの構造はまったく同じです。

垂直サブライブラリ/テーブル、各ライブラリとテーブルの構造は異なります。

読み取りと書き込みの分離: ホストは書き込みを担当し、スレーブは読み取りを担当します。

19.長いリンクを短いリンクに変換してテキスト メッセージを送信するにはどうすればよいですか?

短縮 URL は、生成から使用まで次のステップに分かれています。

送信された長い URL を短い URL にマッピングするサービスがあります (例: www.baidu.com -> www.t.cn/)。

1。

短い URL をテキスト メッセージのコンテンツに結合して送信します。

ユーザーが短い URL をクリックすると、ブラウザは 301/302 でリダイレクトし、対応する長い URL にアクセスします。

該当するコンテンツを表示します。

阿里内部资料20、长链接和短链接如何互相转换？

思路是建立一个发号器。每次有一个新的长 URL 进来，我们就增加一。并且将新的数值返回.第一

个来的 url 返回"www.x.cn/0",第二个返回"www.x.cn/1"。

21、长链接和短链接的对应关系如何存储？

如果数据量小且 QPS 低，直接使用数据库的自增主键就可以实现。 还可以将最近/最热门的对应关

系存储在 K-V 数据库中,这样子可以节省空间的同时,加快响应速度。

22、如何提高系统的并发能力？

使用分布式系统。

部署多台服务器，并做负载均衡。

使用缓存（Redis）集群。

数据库分库分表 + 读写分离。

引入消息中间件集群。

网络篇

1，HTTP 响应码有哪些？分别代表什么含义？

200：成功，Web 服务器成功处理了客户端的请求。

301：永久重定向，当客户端请求一个网址的时候，Web 服务器会将当前请求重定向到另一个

网址，搜索引擎会抓取重定向后网页的内容并且将旧的网址替换为重定向后的网址。

302：临时重定向，搜索引擎会抓取重定向后网页的内容而保留旧的网址，因为搜索引擎认为

重定向后的网址是暂时的。

400：客户端请求错误，多为参数不合法导致 Web 服务器验参失败。

404：未找到，Web 服务器找不到资源。

500：Web 服务器错误，服务器处理客户端请求的时候发生错误。

503：服务不可用，服务器停机。

504：网关超时。

2，Forward 和 Redirect 的区别？

浏览器 URL 地址：Forward 是服务器内部的重定向，服务器内部请求某个 servlet，然后获取

响应的内容，浏览器的 URL 地址是不会变化的；Redirect 是客户端请求服务器，然后服务器给

客户端返回了一个 302 状态码和新的 location，客户端重新发起 HTTP 请求，服务器给客户端

响应 location 对应的 URL 地址，浏览器的 URL 地址发生了变化。

阿里内部资料数据的共享：Forward 是服务器内部的重定向，request 在整个重定向过程中是不变的，

request 中的信息在 servlet 间是共享的。Redirect 发起了两次 HTTP 请求分别使用不同的

request。

请求的次数：Forward 只有一次请求；Redirect 有两次请求。

3， Get 和 Post 请求有哪些区别？

用途：

get 请求用来从服务器获取资源

post 请求用来向服务器提交数据

表单的提交方式：

get 请求直接将表单数据以 name1=value1&name2=value2 的形式拼接到 URL 上（http://www.

baidu.com/action?name1=value1&name2=value2），多个参数参数值需要用 & 连接起来并

且用 ? 拼接到 action 后面；

post 请求将表单数据放到请求头或者请求的消息体中。

传输数据的大小限制：

get 请求传输的数据受到 URL 长度的限制，而 URL 长度是由浏览器决定的；

post 请求传输数据的大小理论上来说是没有限制的。

参数的编码：

get 请求的参数会在地址栏明文显示，使用 URL 编码的文本格式传递参数；

post 请求使用二进制数据多重编码传递参数。

缓存：

get 请求可以被浏览器缓存被收藏为标签；

post 请求不会被缓存也不能被收藏为标签。

4. TCPとUDPの違い、およびそれぞれの長所と短所について説明します。

1. TCP は接続指向です (たとえば、電話をかける前にダイヤルアップして接続を確立する必要があります)。UDP はコネクションレスです。つまり、データを送信する前に接続を確立する必要はありません。

キャッチ。

2. TCP は信頼性の高いサービスを提供します。つまり、TCP 接続を通じて送信されるデータにはエラーがなく、失われず、繰り返されず、順序どおりに送信されます。

到着: UDP はベストエフォートベースで配信します。つまり、信頼性の高い配信は保証されません。TCP パス チェックサム、再送信制御、シリアル番号識別、スライディング ウィンドウ

確実な伝送を実現するポート、確認応答。パケットロス時の再送制御や順序が狂ったサブパッケージの順序制御なども制御可能です。

3. UDPはTCPに比べてリアルタイム性が高く、作業効率が高いため、高速伝送やリアルタイム通信、ブロードキャスト通信に適しています。

手紙。

4. 各 TCP 接続はポイントツーポイントのみであり、UDP は 1 対 1、1 対多、多対 1、および多対多の対話型通信をサポートします。

Ali 内部情報 5. TCP ではシステム リソースに対する要件が多くなりますが、UDP ではシステム リソースに対する要件が低くなります。

5 、HTTPとHTTPSの違いについて話します

ポートが異なります:HTTPとHTTPSでは接続方法が異なり、使用しないポートも異なりますHTTPは80、HTTPSは443を使用します

リソース消費: HTTPS 通信は、HTTP と比較して、暗号化および復号化処理により多くの CPU リソースとメモリ リソースを消費します。

オーバーヘッド: HTTPS 通信には証明書が必要であり、そのような証明書は通常、認証局に申請するか、認証局によって支払われる必要があります。

6. HTTP 、TCP 、ソケットの関係は何ですか?

TCP/IP は、Transmission Control Protocol/Internet Protocol の略で、プロトコルのファミリーを指します。

HTTP 自体はプロトコルであり、Web サーバーからローカル ブラウザにハイパーテキストを転送するための転送プロトコルです。

ソケットは TCP/IP ネットワークの API であり、実際には、複雑な TCP/IP プロトコル ファミリを隠蔽するファサード モデルです。

ソケットインターフェースの背後。ユーザーにとっては、一連のシンプルなインターフェイスだけで十分です。指定された条件を満たすように Socket にデータを整理させます。

合意された合意。

要約すれば：

ネットワークに接続するにはIPプロトコルが必要です

TCP はデータを安全に送信できる仕組みであり、TCP プロトコルを使用してデータを送信する HTTP は Web サーバーです

クライアントが使用する特別なプロトコル。

HTTP は TCP プロトコルに基づいているため、Socket を使用して TCP 接続を確立できます。

7 、HTTP の長い接続と短い接続の違いについて話します

HTTP プロトコルの長い接続と短い接続は、本質的には TCP プロトコルの長い接続と短い接続です。

短い接続

HTTP/1.0 では、デフォルトで短いリンクが使用されます。つまり、ブラウザとサーバーが HTTP 操作を実行するたびに接続が確立されます。

接続は継続されますが、タスクが終了すると接続は終了します。クライアントが HTML または JavaScript などの他のタイプの Web リソースにアクセスする場合

ファイル、画像ファイル、CSS ファイルなど。ブラウザはそのような Web リソースに遭遇するたびに、HTTP セッションを確立します。

長い接続

HTTP/1.1 以降、接続特性を維持するためにデフォルトで長い接続が使用されます。長時間接続の場合、Webページを開いたとき

正常に完了した後、クライアントとサーバー間の HTTP データの送信に使用される TCP 接続は閉じられません。クライアントが再度このサービスにアクセスした場合

サーバー上の Web ページは、この確立された接続を引き続き使用します。キープアライブは接続を永続的に維持するのではなく、保持時間があります。

この時間は、別のサーバー ソフトウェア (Apache など) で設定できます。

8. TCP はなぜ3 回握手をしなければならないのに、2 回はできないのですか? なぜ？

Ali 内部データ TCP クライアントとサーバーは、接続を確立するために 3 回のハンドシェイクが必要です。まず、サーバーは監視を有効にし、クライアントが接続するのを待つ必要があります。

現時点では、サーバーは「リスニング」状態にあります。

クライアントはサーバーへの接続を開始し、初期シーケンス番号 seq=x を選択します。クライアントは「同期が送信されました」の状態になります。

サーバーはクライアントから接続要求を受信し、接続に同意してクライアントに確認応答を送信します。確認応答番号は ack=x+1 で、クライアントが接続されていることを示します。

エンドは、x+1 から始まる次のデータ パケット シーケンス番号を送信し、同時に seq=y の最初のシーケンス番号を選択できます。この時点でサーバーは

「同期受信」状態。

サーバーから確認を受信した後、クライアントはサーバーに確認メッセージを送信します。確認番号は ack=y+1 で、サーバーが送信できることを意味します。

次に送信されるデータ パケットのシリアル番号は y+1 から始まり、この時点でクライアントは「接続が確立されている」状態になります。

クライアントからの確認を受信した後、サーバーも「接続が確立されました」状態になります。

3 ウェイ ハンドシェイクのプロセスから、ハンドシェイクが 2 回だけであれば、クライアントの最初のシーケンス番号を確認でき、サーバーの最初のシーケンス番号を確認できることがわかります。

シリアルナンバーの確認は致しておりません。

9. TCPスティッキー パケットがどのように生成されるのか教えてください。粘着袋の問題を解決するにはどうすればよいですか?

上記の Ali の内部情報で TCP と UDP の違いについて話すとき、TCP はバイト ストリームに基づいてデータを送信し、アプリケーション層から TCP トランスポート層まで複数のデータ ストリームを送信することが述べられています。

データ パケットは境界のない一連のバイト ストリームであり、TCP ヘッダーにはデータ パケットの長さが記録されないため、TCP 送信データは

UDP はデータグラムに基づいてデータを送信し、UDP ヘッダーにもデータが記録されますが、データを送信するときにスティッキー パケットの送信とアンパックの問題が発生する可能性があります。

報告された長さに従って、異なるデータ パケットの境界を簡単に区別できます。

次に、TCP 送信データの状況をいくつか見ていきますが、まず 1 つ目の状況は正常であり、スティッキー パケットの送信もティアリングも発生していません。

バッグ。

2 番目のケースでは、明らかなパケットのスタックが発生し、データ受信者がこれを処理するのは困難です。

次の 2 つのケースでは、パケットのスタックとアンパッキングの現象が発生し、受信側で受信したデータ パケットが不完全か余分でした。

ブロック。

貼り付きと開梱現象の原因:

TCP 送信バッファの残りのスペースは完全なデータ パケットを送信するのに十分ではないため、アンパックが発生します。

送信されるデータが最大パケット長の制限を超えているため、データ送信時に TCP がアンパックされます。

送信されるデータ パケットが TCP 送信バッファの残りのスペースより小さいため、TCP は送信バッファを複数のデータ パケットで満たし、一度に送信します。

ゴー、粘着パッケージが発生します。

受信側が TCP 送信バッファ内のデータ パケットを時間内に読み込まない場合、スティッキー パケットが発生します。

Ali の内部データを貼り付けて解凍するための解決策:

送信者はデータ パケットにヘッダーを追加し、ヘッダーにデータ パケットの長さ属性を追加して、受信者がヘッダー内の長さフィールドを渡すようにします。

パケットの実際の長さを知ることができます。

送信されるデータ パケットがバッファ サイズより小さい場合、送信者は、データ パケットのサイズに関係なく、異なるデータ パケットを同じ長さに設定できます。

この長さの 0 を補足すると、受信側はバッファから固定長データを読み取って、異なるデータ パケットを区別できるようにします。

送信者は異なるデータ パケットに間隔を追加することで境界を決定でき、受信者は間隔を一致させることで異なるデータ パケットを区別できます。

データパケット。

10. TCP はどのように信頼性を保証しますか

シリアル番号と確認番号の仕組み:

TCP 送信側はデータ パケットを送信するときにシーケンス番号を選択し、受信側はデータ パケットを受信した後にデータ パケットの整合性を検出します。

テストに合格すると、データ パケットが受信されたことを示す ack 確認番号で応答します。

タイムアウト再送信メカニズム:

TCP送信側がデータパケットを送信した後、タイマーを開始し、一定時間受信側からの確認を受信しない場合は再起動します。

そのパケットを送信します。

順序が乱れたパケットを並べ替えます。

IP ネットワーク層から TCP 層に送信されるデータ パケットは順序が乱れている可能性があり、TCP 層はアプリケーション層に送信する前にデータ パケットの順序を変更します。

重複データを削除します。

IP ネットワーク層から TCP 層に送信されるパケットは重複する可能性があり、TCP 層は重複したパケットを破棄します。

フロー制御：

TCP 送信側と受信側の両方には、送信側がデータを送信する速度が速すぎて受信側が混乱することを防ぐために、固定サイズのバッファ スペースがあります。

エンドバッファがオーバーフローした場合、送信者は受信者が受け入れることができるデータのみを送信できます。この制御効果を達成するために、TCP はフロー制御を使用します。

制御プロトコル（可変サイズのスライディング ウィンドウ プロトコル）を実現します。

11. OSIモデルの 7 つの層とは何ですか?

OSI 7 層モデルは一般に、国際標準化グループである Open System Interconnect Reference Model (略して OSI) を指します。

ISO と国際電信電話諮問委員会 (CCITT) が共同で策定したオープンシステム相互接続参照モデルは、オープン相互接続情報システムです。

このシステムは、機能構造のフレームワークを提供します。

アプリケーション層: HTTP、HTTPS、FTP、SOCKS セキュア ソケット プロトコル、DNS ドメイン名などのさまざまなアプリケーション プロトコル

システム、GDP ゲートウェイ検出プロトコルなど。

プレゼンテーション層: 暗号化と復号化、変換と翻訳、圧縮と解凍 (LPP Lightweight Presentation Protocol など)。

セッション層: 異なるマシン上のユーザーが、SSL セキュア ソケット層プロトコル、TLS トランスポート層セキュリティ プロトコルなどのセッションを確立および管理します。

プロトコル、RPC リモート プロシージャ コール プロトコルなど。

アリババの内部データ伝送層: 上位層からデータを受け取り、必要に応じてデータを分割し、データをネットワーク層に配信して、

これらのデータ セグメントは、TCP 伝送制御プロトコル、UDP データグラム プロトコルなどのピアに効果的に到達します。

ネットワーク層: サブネットの動作を制御します: 論理アドレス指定、パケット送信、ルーティング選択 (IP、IPV6、SLIP など)。

データリンク層：物理アドレッシング、元のビットストリームをXTP圧縮伝送プロトコルなどの論理的な伝送路に変換し、

PPTP ポイントツーポイント トンネリング プロトコルなど。

物理層: IEEE802.2 などの機械的、電子的、タイミング インターフェイス通信チャネルでの生のビット ストリーム送信。

Ali 内部情報12 、ブラウザに「www.woaijava.com 」と入力した後、何が起こりましたか?

詳しく説明してください

ドメイン名→IPアドレスからIPアドレスを見つけるプロセスは、ブラウザキャッシュ、システムキャッシュ、ホストファイル、ルーターキャッシュなどを次々と通過します。

ルート ドメイン ネーム サーバーを保存し、再帰的に検索します。

TCP/IP 接続を確立します (3 ウェイ ハンドシェイク固有のプロセス)

ブラウザからHTTPリクエストが送信される

ルーターによって転送され、サーバーのファイアウォールを通過した後、HTTP リクエストはサーバーに到達します。

サーバーは HTTP リクエストを処理し、HTML ファイルを返します。

ブラウザはHTMLファイルを解析してブラウザ側に表示します。

ここで注意してください:

HTTP プロトコルは TCP/IP に基づくアプリケーション層プロトコルであり、HTTP データ要求のために最初に TCP/IP 接続を確立する必要があります。

これは、次のように理解できます: HTTP は、特定の形式のカプセル化または表示データを提供する自動車であり、ソケットは、提供するエンジンです。

ネットワーク経由で通信する機能。

2 台のコンピュータ間の通信は、2 つのポート間のデータ通信にすぎません。具体的なデータがどのような形式で表示されるかは、コンピュータによって異なります。

さまざまなアプリケーション層プロトコルが定義されています。

13.クロスドメインを実現するにはどうすればよいですか?

当浏览器执行 JS 脚本的时候，会检测脚本要访问的协议、域名、端口号是不是和当前网址一致，如

果不一致就是跨域。跨域是不允许的，这种限制叫做浏览器的同源策略，简单点的说法就是浏览器

不允许一个源中加载脚本与其他源中的资源进行交互。那么如何实现跨域呢？

JSONP、CORS方式、代理方式

1 JSONP 方式

script、img、iframe、link、video、audio 等带有 src 属性的标签可以跨域请求和执行资源，

JSONP 利用这一点“漏洞”实现跨域。

再看下 jQuery 的写法。

<script>

var scriptTag = document.createElement('script');

scriptTag.type = "text/javascript";

scriptTag.src = "http://10.10.0.101:8899/jsonp?callback=f";

document.head.appendChild(scriptTag);

</script>

$.ajax({

// 请求域名

url:'http://10.10.0.101:8899/login',

阿里内部资料JSONP 实现跨域很简单但是只支持 GET 请求方式。而且在服务器端接受到 JSONP 请求后需要设置

请求头，添加 Access-Control-Allow-Origin 属性，属性值为 * ，表示允许所有域名访问，这样浏

览器才会正常解析，否则会报 406 错误。

2 CORS 方式

CORS（Cross-Origin Resource Sharing）即跨域资源共享，需要浏览器和服务器同时支持，这种

请求方式分为简单请求和非简单请求。

ブラウザから送信されるXMLHttpRequestリクエストのリクエストメソッドがPOSTまたはGETの場合、リクエストヘッダーにはAccept、

Accept-Language、Content-Language、Last-Event-ID、Content-Type（application/x-www）

form-urlencoded、multipart/form-data、text/plain) の場合、このリクエストは単純なリクエストです。

単純なリクエストの場合、ブラウザはリクエスト ヘッダーに Origin 属性を追加し、リクエストの送信元 (プロトコル + ドメイン名 +

ポート）。

得る

// このリクエストの送信元を示します (プロトコル + ドメイン名 + ポート)

発信元: http://127.0.0.1:8080

// IP

ホスト: 127.0.0.1:8080

// 長い接続

接続: キープアライブ

コンテンツタイプ: テキスト/プレーン

Origin によって示されたドメイン名がサーバーの許可の範囲内にある場合、サーバーは次のように応答します。

// リクエストメソッド

タイプ:「GET」、

// データ型選択 jsonp

データ型:'jsonp',

// コールバックメソッド名

jsonpCallback:'コールバック',

});

// コールバックメソッド

関数コールバック(応答) {

console.log(応答);

}

response.setHeader("アクセス制御許可オリジン", "*");

Ali 内部情報 // この値は上記で説明されており、ブラウザによって指定されたドメイン名へのアクセスが許可されることを意味します。ブラウザによって渡されたオリジン、または * は、

すべてのドメインにアクセス可能

アクセス制御許可オリジン: http://127.0.0.1:8080

// ブラウザが Cookie を送信することにサーバーが同意するかどうかを示します

アクセス制御許可資格情報: true

// XMLHttpRequest#getResponseHeader()メソッドで取得できるフィールドを指定

アクセス制御公開ヘッダー: xxx

コンテンツタイプ: テキスト/html; 文字セット=utf-8

Access-Control-Allow-Credentials: true は、サーバーがブラウザーが Cookie を送信することに同意し、ブラウザーも

この設定では Cookie の送信がサポートされています。そうでない場合は、サーバーがブラウザをサポートしていても、Cookie は送信されません。

もう 1 つは単純ではないリクエストです。リクエスト メソッドが PUT または DELETE であるか、リクエスト ヘッダーにコンテンツが追加されています。

タイプ:application/json 属性と属性値のリクエスト。

この種類のリクエストは、ブラウザが XMLHttpRequest リクエストを正式に送信する前に、事前チェック HTTP リクエストを送信し、サーバーにいつ送信するかを尋ねます。

前の Web ページのドメイン名がサーバーの許可リストに含まれているかどうかに関係なく、通信リクエストはサーバーの確認後にのみ正式に送信されます。

プリフライトリクエストのヘッダー情報：

// プリフライトリクエストのリクエストメソッドはOPTIONSです

オプション

// このリクエストの送信元を示します (プロトコル + ドメイン名 + ポート)

発信元: http://127.0.0.1:8080

// 次の CORS リクエストに使用されるリクエスト メソッドを示します

アクセス制御要求メソッド: PUT

// 次の CORS リクエストで送信されるヘッダー情報属性を指定します

アクセス制御リクエストヘッダー: X-カスタムヘッダー

// IP

ホスト: 127.0.0.1:8080

// 長い接続

接続: キープアライブ

サーバーが CORS 関連のヘッダー情報なしでプリフライト要求に応答した場合、クロスドメインがサポートされていないことを意味します。

クロスドメイン応答が行われ、応答ヘッダー情報は次のとおりです。

HTTP/1.1 200 OK

// この値は上で述べたもので、ブラウザによって指定されたドメイン名へのアクセスが許可されることを意味します。ブラウザによって渡されたオリジン、または * はすべてを意味します。

var xhr = 新しい XMLHttpRequest();

// リクエストをCookieで送信するかどうかを設定

xhr.withCredentials = true;

xhr.open('post', 'http://10.10.0.101:8899/login', true);

xhr.setRequestHeader('Content-Type', 'text/plain');

阿里内部资料有域名都可以访问

Access-Control-Allow-Origin:http://127.0.0.1:8080

// 服务器支持的所有跨域请求方式，为了防止浏览器发起多次预检请求把所有的请求方式返回给浏览器

Access-Control-Allow-Methods: GET, POST, PUT

// 服务器支持预检请求头信息中的 Access-Control-Request-Headers 属性值

Access-Control-Allow-Headers: X-Custom-Header

// 服务器同意浏览器发送 cookie

Access-Control-Allow-Credentials: true

// 指定预检请求的有效期是 20 天，期间不必再次发送另一个预检请求

Access-Control-Max-Age:1728000

Content-Type: text/html; charset=utf-8

Keep-Alive: timeout=2, max=100

// 长连接

Connection: Keep-Alive

Content-Type: text/plain

接着浏览器会像简单请求一样，发送一个 CORS 请求，请求头中一定包含 Origin 属性，服务器的响

应头中也一定得包含 Access-Control-Allow-Origin 属性。

3 代理方式

跨域限制是浏览器的同源策略导致的，使用 nginx 当做服务器访问别的服务的 HTTP 接口是不需要

执行 JS 脚步不存在同源策略限制的，所以可以利用 Nginx 创建一个代理服务器，这个代理服务器的

域名跟浏览器要访问的域名一致，然后通过这个代理服务器修改 cookie 中的域名为要访问的 HTTP

接口的域名，通过反向代理实现跨域。

Nginx 的配置信息：

server {

# 代理服务器的端口

listen 88;

# 代理服务器的域名

server_name http://127.0.0.1;

location / {

# 反向代理服务器的域名+端口

proxy_pass http://127.0.0.2:89;

# 修改cookie里域名

proxy_cookie_domain http://127.0.0.2 http://127.0.0.1;

index index.html index.htm;

# 设置当前代理服务器允许浏览器跨域

add_header Access-Control-Allow-Origin http://127.0.0.1;

# 设置当前代理服务器允许浏览器发送 cookie

add_header Access-Control-Allow-Credentials true;

阿里内部资料前端代码：

14，TCP 为什么要三次握手，两次不行吗？为什么？

CP 客户端和服务端建立连接需要三次握手，首先服务端需要开启监听，等待客户端的连接请

求，这个时候服务端处于“收听”状态；

客户端向服务端发起连接，选择 seq=x 的初始序列号，此时客户端处于“同步已发送”的状态；

服务端收到客户端的连接请求，同意连接并向客户端发送确认，确认号是 ack=x+1 表示客户

端可以发送下一个数据包序号从 x+1 开始，同时选择 seq=y 的初始序列号，此时服务端处

于“同步收到”状态；

客户端收到服务端的确认后，向服务端发送确认信息，确认号是 ack=y+1 表示服务端可以发

次に送信されるデータ パケットのシリアル番号は y+1 から始まり、この時点でクライアントは「接続が確立されている」状態になります。

クライアントからの確認を受信した後、サーバーも「接続が確立されました」状態になります。

3 ウェイ ハンドシェイクのプロセスから、ハンドシェイクが 2 回だけであれば、クライアントの最初のシーケンス番号を確認でき、サーバーの最初のシーケンス番号を確認できることがわかります。

シリアルナンバーの確認は致しておりません。

}

}

var xhr = 新しい XMLHttpRequest();

// Cookie の送信を許可するようにブラウザを設定します

xhr.withCredentials = true;

// nginxプロキシサーバーにアクセスします

xhr.open('get', 'http://127.0.0.1:88', true);

xhr.send();

Ali 内部情報15 、TCPスティッキー パケットはどのようにして発生するのですか? 粘着袋の問題を解決するにはどうすればよいですか?

上記の TCP と UDP の違いについて説明する際、TCP はバイト ストリームに基づいてデータを送信し、アプリケーション層から TCP トランスポート層まで複数のデータを送信することに言及しました。

データ パケットは境界のない一連のバイト ストリームであり、TCP ヘッダーにはデータ パケットの長さが記録されないため、TCP 送信データは

UDP はデータグラムに基づいてデータを送信し、UDP ヘッダーにもデータが記録されますが、データを送信するときにスティッキー パケットの送信とアンパックの問題が発生する可能性があります。

報告された長さに従って、異なるデータ パケットの境界を簡単に区別できます。

Aliの内部情報によって引き起こされる固着と開封現象の理由:

TCP 送信バッファの残りのスペースは完全なデータ パケットを送信するのに十分ではないため、アンパックが発生します。

送信されるデータが最大パケット長の制限を超えているため、データ送信時に TCP がアンパックされます。

送信されるデータ パケットが TCP 送信バッファの残りのスペースより小さいため、TCP は送信バッファを複数のデータ パケットで満たし、一度に送信します。

ゴー、粘着パッケージが発生します。

受信側が TCP 送信バッファ内のデータ パケットを時間内に読み込まない場合、スティッキー パケットが発生します。

粘着性のあるパッケージの解凍に対する解決策:

送信者はデータ パケットにヘッダーを追加し、ヘッダーにデータ パケットの長さ属性を追加して、受信者がヘッダー内の長さフィールドを渡すようにします。

パケットの実際の長さを知ることができます。

送信されるデータ パケットがバッファ サイズより小さい場合、送信者は、データ パケットのサイズに関係なく、異なるデータ パケットを同じ長さに設定できます。

足这个长度的补充 0，接收端从缓冲区读取固定的长度数据这样就可以区分不同的数据包；

发送端通过给不同的数据包添加间隔符合确定边界，接收端通过这个间隔符合就可以区分不同

的数据包。

阿里内部资料16，HTTP1.0、HTTP1.1、HTTP2.0的关系和区别

一，对比

二、HTTP1.0：

浏览器的每次请求都需要与服务器建立一个TCP连接，服务器处理完成后立即断开TCP连接（无连

接），服务器不跟踪每个客户端也不记录过去的请求（无状态）。

三、HTTP1.1：

HTTP/1.0中默认使用Connection: close。在HTTP/1.1中已经默认使用Connection: keep-alive，避

免了连接建立和释放的开销，但服务器必须按照客户端请求的先后顺序依次回送相应的结果，以保

证客户端能够区分出每次请求的响应内容。通过Content-Length字段来判断当前请求的数据是否已

经全部接收。不允许同时存在两个并行的响应。

四、HTTP2.0：

HTTP/2引入二进制数据帧和流的概念，其中帧对数据进行顺序标识，如下图所示，这样浏览器收到

数据之后，就可以按照序列对数据进行合并，而不会出现合并后数据错乱的情况。同样是因为有了

序列，服务器就可以并行的传输数据，这就是流所做的事情。

流（stream）

已建立连接上的双向字节流 消息 与逻辑消息对应的完整的一系列数据帧 帧 HTTP2.0

通信的最小单位，每个帧包含帧头部，至少也会标识出当前帧所属的流（stream id）。 多路复

用：

1. すべての HTTP2.0 通信は、任意の数の双方向データ ストリームを伝送できる TCP 接続上で完了します。

2. 各データ ストリームはメッセージの形式で送信され、メッセージは 1 つ以上のフレームで構成されます。これらのフレームは順不同で送信でき、その後、

各フレームヘッダーのストリーム識別子 (ストリーム ID) が再構築されます。

Ali の内部データの例では、各リクエストはデータ ストリームであり、データ ストリームはメッセージの形式で送信され、メッセージは複数のフレームに分割され、フレーム ヘッダー レコードが記録されます。

ストリーム ID は、データ ストリームが属するデータ ストリームを識別するために使用され、接続内で異なる属性のフレームをランダムに混在させることができます。受信者が使用できるのは、

ストリーム ID により、フレームがさまざまなリクエストに関連付けられます。

3. さらに、多重化 (接続共有) により、重要なリクエストがブロックされる可能性があります。HTTP2.0の各データストリームは最適化可能

優先度と依存関係。優先度の高いデータ フローは最初にサーバーによって処理されてクライアントに返されます。また、データ フローは他のサブデータに依存することもあります。

データフロー。

4. HTTP2.0 は、1 つの TCP 上で任意の数の HTTP リクエストを実行できる、真の並列伝送を実現していることがわかります。この

この強力な機能は「バイナリ フレーム化」の機能に基づいています。

頭部圧縮

HTTP1.x では、ヘッダーのメタデータはプレーン テキストで送信され、通常、各リクエストに 500 ～ 800 バイトのペイロードが追加されます。

荷。

HTTP2.0 では、エンコーダを使用して送信する必要があるヘッダーのサイズを削減し、通信当事者はそれぞれヘッダー フィールド テーブルをキャッシュします。

これにより、ヘッダーの繰り返し送信が回避されるだけでなく、送信する必要があるサイズも削減されます。効率的な圧縮アルゴリズムにより大幅に圧縮可能

ヘッダーを削除し、送信されるパケットの数を減らして遅延を短縮します。

サーバープッシュ:

最初のリクエストに対するサーバーの応答に加えて、サーバーは、クライアントの明示的なリクエストなしで追加のリソースをクライアントにプッシュすることもできます。

懇願する。

17 、HTTPプロトコルとTCP/IPプロトコルの関係について話します

HTTP の長い接続と短い接続は、本質的には TCP の長い接続と短い接続です。

HTTP はアプリケーション層プロトコルに属し、トランスポート層では TCP プロトコルを使用し、ネットワーク層では IP プロトコルを使用します。

IP プロトコルは主にネットワークのルーティングとアドレス指定の問題を解決します。

TCP プロトコルは主に、ネットワーク上の受信側が送信側から送信されたすべてのデータを受信できるように、データ パケットを IP 層上で確実​​に送信する方法を解決します。

包，并且顺序与发送顺序一致。TCP协议是可靠的、面向连接的。

18，如何理解HTTP协议是无状态的？

HTTP协议是无状态的，指的是协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。

也就是说，打开一个服务器上的网页和上一次打开这个服务器上的网页之间没有任何联系。HTTP是

一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是

UDP协议（无连接）。

19，什么是长连接和短连接？

阿里内部资料在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连

接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的

Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重

新建立一个HTTP会话。

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加

入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连

接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会

永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现

长连接需要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

20，长连接和短连接的优缺点？

长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间 。对于频繁请求资源的客户来

说，较适用长连接。不过这里存在一个问题，存活功能的探测周期太长，还有就是它只是探测TCP

接続の存続はより洗練されたアプローチですが、悪意のある接続に遭遇した場合、キープアライブ機能だけでは十分ではありません。長時間接続の応用分野に

このコンテキストでは、通常、クライアントはそれらの間の接続を積極的に閉じません。クライアントとサーバー間の接続が閉じられていない場合は、

クライアント接続が増えると、サーバーは遅かれ早かれそれを処理できなくなります。このとき、サーバーは次のことを行う必要があります。

一部の悪意のある接続が原因でイベントが発生するのを防ぐために、イベントの読み取りおよび書き込みのために長期間発生しなかった一部の接続を閉じるなど、いくつかの戦略を採用する必要があります。

サーバー側のサービスが破損しています。条件が許せば、クライアント マシンを粒度として使用して、各クライアントの最大長期接続を制限できます。

これにより、悪意のあるクライアントによるバックエンド サービスの侵害を完全に回避できます。

短い接続はサーバーにとって管理が比較的簡単で、既存の接続はすべて、追加の制御方法を必要とせずに有用な接続です。しかし、もし

クライアントが頻繁に要求すると、TCP の確立と終了の操作に時間と帯域幅が無駄になります。

21 、ロング接続とショート接続の操作プロセスについて話します

ショート接続の操作手順は次のとおりです: 接続の確立 - データ送信 - 接続の終了... 接続の確立 - データ送信 - 接続の終了

長い接続に接続するための操作手順は次のとおりです。 接続の確立 - データ送信... (接続を維持) ... データ送信 - 接続を閉じる

22 、 TCP の3 ウェイ ハンドシェイクと 4 ウェイ ウェーブの全プロセスについて話します

3回の握手

Alibaba の内部データの最初のハンドシェイク: クライアントは syn パケット (syn=x) をサーバーに送信し、SYN_SEND 状態に入り、サーバーの確認を待ちます。

2番

2 回目のハンドシェイク: サーバーは syn パケットを受信し、クライアントの SYN (ack=x+1) を確認し、同時に SYN パケットを送信する必要があります。

(syn=y)、つまり SYN+ACK パケット。この時点でサーバーは SYN_RECV 状態に入ります。

3 回目のハンドシェイク: クライアントはサーバーのハンドシェイクを受け取ります。

SYN+ACK パケット、確認パケット ACK(ack=y+1) をサーバーに送信します。このパケットが送信された後、クライアントとサーバーは開始します。

ESTABLISHED 状態で、スリーウェイ ハンドシェイクが完了します。ハンドシェイク プロセス中に送信されるパケットにはデータが含まれておらず、3 ウェイ ハンドシェイクが完了すると、クライアントは

サーバーとのデータ送信が正式に開始されます。理想的には、TCP 接続が確立されると、どちらかの当事者が 2 つの通信当事者間の接続を積極的に閉じます。

TCP 接続は、接続が閉じられるまで維持されます。

四回手を振った

接続を確立するための「3 ウェイ ハンドシェイク」と同様に、TCP 接続を切断するには「4 ウェイ ハンドシェイク」が必要です。第 1 波: アクティブな近接パーティの送信

FIN は、アクティブなパーティからパッシブなクロージング パーティへのデータ送信をクローズするために使用されます。つまり、アクティブなクロージング パーティはパッシブなクロージング パーティに「私はもういません」と伝えます。

データを再度送信します (もちろん、fifin パケットの前に送信されたデータが受信されなかった場合、対応する ack 確認メッセージは自動的に閉じられます)

クローズされたパーティは依然としてデータを再送信しますが、この時点では、アクティブなクローズされたパーティは引き続きデータを受け入れることができます。第 2 の波: 受動的に閉じて受信する

FIN パケット受信後、相手に ACK を送信し、確認シーケンス番号は受信したシーケンス番号 + 1 (SYN と同様、FIN はシーケンスを占有)

番号）。第 3 の波: パッシブ クロージング パーティが FIN を送信して、パッシブ クロージング パーティからアクティブ クロージング パーティへのデータ送信をクローズします。

これは、アクティブなクロージングパーティに、私のデータも送信されており、これ以上データは送信しないことを伝えるためです。第 4 の波: 積極的なクロージング パーティーが受け取る

FIN後、受動的クロージングパーティにACKを送信し、シリアル番号が受信したシリアル番号+1であることを確認し、ここまでで4つの手を振ることが完了します。

23. OSIの 7 層モデルとは何ですか?

OSI (Open System Interconnection) は、国際標準化機構 (ISO) によって開発されたオープン システム相互接続参照モデルです。

コンピュータまたは通信システム間の相互接続のための標準システム。

アプリケーション層: HTTP、HTTPS、FTP、SOCKS セキュア ソケット プロトコル、DNS ドメイン名などのさまざまなアプリケーション プロトコル

システム、GDP ゲートウェイ検出プロトコルなど。

プレゼンテーション層: 暗号化と復号化、変換と翻訳、圧縮と解凍 (LPP Lightweight Presentation Protocol など)。

セッション層: 異なるマシン上のユーザーが、SSL セキュア ソケット層プロトコル、TLS トランスポート層セキュリティ プロトコルなどのセッションを確立および管理します。

プロトコル、RPC リモート プロシージャ コール プロトコルなど。

トランスポート層：上位層のデータを受け取り、必要に応じてデータを分割し、ネットワーク層にデータを配信して確実にデータを送信します。

これらのデータ セグメントは、TCP 伝送制御プロトコル、UDP データグラム プロトコルなどのピアに効果的に到達します。

ネットワーク層: サブネットの動作を制御します: 論理アドレス指定、パケット送信、ルーティング選択 (IP、IPV6、SLIP など)。

データリンク層：物理アドレッシング、元のビットストリームをXTP圧縮伝送プロトコルなどの論理的な伝送路に変換し、

PPTP ポイントツーポイント トンネリング プロトコルなど。

物理層: IEEE802.2 などの機械的、電子的、タイミング インターフェイス通信チャネルでの生のビット ストリーム送信。

内部情報もアリ24. OSIのような階層化の利点は何ですか?

OSI 階層化の利点は、次の 5 つの側面から説明できます。

1. プロトコルの仕様詳細を簡単に議論し、学ぶことができます。

2. レイヤー間の標準インターフェイスにより、プロジェクトのモジュール化が容易になります。

3. より良い相互接続環境を作成します。

4. 複雑さが軽減され、プログラムの修正が容易になり、製品開発のスピードが速くなります。

5. 各層は直下の層のサービスを利用するため、各層の機能を覚えやすくなります。

25. TCP/IP 4 層ネットワーク モデルについて話す

TCP/IP 階層化モデル (TCP/IP 階層化モデル) は、インターネット階層化モデル (インターネット階層化モデル) と呼ばれます。

インターネット参照モデル (インターネット参照モデル)。次の図は、TCP/IP 階層化モデルの 4 つの層を示しています。

Alibaba の内部データ TCP/IP プロトコルは 4 つの概念層で構成されており、そのうちの 3 つは ISO 参照モデルの対応する層に対応しています。ICP/IP プロトコル スイートには次のものが含まれていません。

物理層とデータリンク層が含まれるため、コンピュータネットワークシステム全体の機能を独立して完了することはできず、他の多くのプロトコルと通信する必要があります

共同作業。TCP/IP 階層化モデルの 4 つのプロトコル層は、それぞれ次の機能を実行します。

レイヤ 1 ネットワーク インターフェイス層

ネットワーク インターフェイス層には、既存のネットワーク メディアを介した IP データの転送を調整するためのプロトコルが含まれています。

プロトコル: ARP、RARP

レイヤー2

インターネットワーク層は、OSI 7 層参照モデルのネットワーク層に相当します。データのパッケージ化、アドレス指定、ルーティングを担当します。インターネット制御レポートも含まれます

インターネット制御メッセージ プロトコル (ICMP) は、ネットワーク診断情報を提供するために使用されます。

プロトコル: この層には、IP プロトコル、RIP プロトコル (Routing Information Protocol、経路情報プロトコル)、ICMP プロトコルが含まれます。

レイヤ 3 トランスポート層

トランスポート層は、OSI 7 層参照モデルのトランスポート層に対応し、2 つのエンドツーエンド通信サービスを提供します。

その中で、TCP プロトコル (Transmission Control Protocol) は信頼性の高いデータ ストリーム転送サービスを提供し、UDP プロトコル (Transmission Control Protocol) は信頼性の高いデータ ストリーム転送サービスを提供します。

データグラム プロトコル）は、信頼性の低いユーザー データグラム サービスを提供します。

4 番目のアプリケーション層

アプリケーション層は、OSI 7 層参照モデルのアプリケーション層とプレゼンテーション層に相当します。

アリババの内部情報インターネットのアプリケーション層プロトコルには、Finger、Whois、FTP (ファイル転送プロトコル)、Gopher、HTTP (ハイパーテキスト転送プロトコル) が含まれます。

プロトコル）、Telent（リモート ターミナル プロトコル）、SMTP（簡易メール転送プロトコル）、IRC（インターネット リレー セッション）、NNTP（ネットワーク ニュース）

トランスポートプロトコル）など

26.ドメイン名解決の詳しいプロセスについて教えてください。

1. ブラウザは www.baidu.com にアクセスし、ローカル DNS サーバーが Web サイトの解決された IP アドレスをキャッシュしているかどうかを尋ねます。

2. ローカル DNS サーバーにキャッシュがない場合は、root-servers.net のルート サーバーに移動して、URL に対応する IP アドレスを照会します。

サイト。

3. ルート サーバーはトップレベル ドメイン ネーム サーバーの URL gtld-servers.net を返し、ローカル DNS サーバーはトップレベル ドメイン ネーム サーバーにアクセスします。

サーバーは、URL に対応する IP アドレスを問い合わせます。

4. トップレベル ドメイン ネーム サーバーは、www.baidu.com のメイン地域サーバーのアドレスを返し、ローカル DNS サーバーは www.ba にアクセスします。

idu.com メイン領域サーバーは、このドメイン名に対応する IP アドレスを照会します。

5. ローカル DNS サーバーは、www.baidu.com の解決された IP アドレスを取得した後、将来の参照のためにそれをキャッシュし、解決された IP アドレスを次の宛先に送信します。

次の IP アドレスがブラウザに返されます。

27. IPアドレスにはいくつかの種類があります。それぞれの種類は何を表しますか。また、プライベート ネットワークとは何ですか?

パブリックアドレスとプライベートアドレスに大きく分けられ、パブリックアドレスは外部ネットワークから自由にアクセスでき、プライベートアドレスは内部ネットワークからのみアクセスできます。

Q プロキシサーバー経由でのみ外部ネットワークと通信できます。

パブリックアドレス:

1.0.0.1～126.255.255.254

128.0.0.1～191.255.255.254

192.0.0.1～223.255.255.254

224.0.0.1～239.255.255.254

240.0.0.1～255.255.255.254

プライベートアドレス:

10.0.0.0～10.255.255.255

172.16.0.0～172.31.255.255

192.168.0.0～192.168.255.255

0.0.0.0 ルーター転送使用

127.xxx 予約済み

255.255.255.255 LAN 上のブロードキャスト アドレス

28. TCP はどのようにして信頼性を保証するのか教えてください。

Ali 内部データのシリアル番号と確認番号のメカニズム:

TCP 送信側はデータ パケットを送信するときにシーケンス番号を選択し、受信側はデータ パケットを受信した後にデータ パケットの整合性を検出します。

テストに合格すると、データ パケットが受信されたことを示す ack 確認番号で応答します。

タイムアウト再送信メカニズム:

TCP送信側がデータパケットを送信した後、タイマーを開始し、一定時間受信側からの確認を受信しない場合は再起動します。

そのパケットを送信します。

順序が乱れたパケットを並べ替えます。

IP ネットワーク層から TCP 層に送信されるデータ パケットは順序が乱れている可能性があり、TCP 層はアプリケーション層に送信する前にデータ パケットの順序を変更します。

重複データを削除します。

IP ネットワーク層から TCP 層に送信されるパケットは重複する可能性があり、TCP 層は重複したパケットを破棄します。

フロー制御：

TCP 送信側と受信側の両方には、送信側がデータを送信する速度が速すぎて受信側が混乱することを防ぐために、固定サイズのバッファ スペースがあります。

エンドバッファがオーバーフローした場合、送信者は受信者が受け入れることができるデータのみを送信できます。この制御効果を達成するために、TCP はフロー制御を使用します。

制御プロトコル（可変サイズのスライディング ウィンドウ プロトコル）を実現します。

デザインパターン

アリババの内部データ設計パターン（デザインパターン）は、先人たちのコード開発経験を要約したもので、特定の問題を解決するための一連のルーチンです。それ

文法的な仕様ではなく、コードの再利用性、保守性、可読性、堅牢性、セキュリティを向上させるための一連のソリューション

場合。1

Ali 内部データ 1995 年、GoF (Gang of Four、Group of Four/Gang of Four) は「デザイン パターン: 再利用可能なオブジェクト指向ソフトウェアのためのデザイン パターン」を共同出版しました。

『Basics』には合計 23 のデザイン パターンが収録されており、以来、「GoF デザイン パターン」として知られるソフトウェア デザイン パターンの分野におけるマイルストーンを確立しました。

モード"。

通常、面接では次のことが尋ねられます。

あなたが知っているデザインパターンを教えてください。

このとき、普段から積み重ねてきた経験が必要であり、そうしますと答えなければなりません、名詞が役に立たないことを知っているだけです。困難

容易さと一般的な状況の観点から、次のように答えることができます。

シングルトン モード、プロキシ モード、テンプレート メソッド モード、デコレータ モード、ファクトリ モード、責任連鎖モード、オブザーバ モード、プロトタイプ モード

モード。

通常、これくらい答えられればもう大丈夫です。しかし、他のモードについては、きちんと理解することができます。そうでないと、面接官が「他に何かありますか？」と尋ねてきます。

デザインパターン？

この時点で、名詞を答えることができ、彼が再度尋ねると、これらのデザイン パターンは知られているだけで、仕事ではあまり使用されないと言うでしょう。

多くの。

1.シングルトンモードとは何かについて話す

回答: シングルトン パターンは一般的に使用されるソフトウェア デザイン パターンです。このパターンを適用する場合、シングルトン オブジェクトのクラスはインスタンスが 1 つだけ存在することを保証する必要があります。

インスタンスが存在する場合、システム全体で使用できるオブジェクト インスタンスは 1 つだけです。

利点: オブジェクトの作成と破棄が頻繁に行われず、システム リソースが浪費されます。

おそらくこれには、シングルトン パターンを手動で記述する必要がありますが、これは自分で学習する必要があります。シングルトン パターン、遅延パターン、を記述する方法は多数あるためです。

ハングリーマンモード、ダブルチェックモードなど 怠け者モードは使用時にオブジェクトを作成し、空腹者モードは事前にオブジェクトをロードします。

優れた静的静的オブジェクト。ダブル チェック モードは、マルチスレッドによって引き起こされる複数のオブジェクトの作成を避けるために 2 回チェックします。

シングルトン モードを記述する方法はたくさんありますが、要約してみましょう。

(1) Hungry Chinese シングルトンモードの記述方法：スレッドセーフ

(2) レイジースタイルのシングルトンパターン書き込み: 非スレッドセーフ

(3) ダブルチェックロックシングルトンモードの書き方：スレッドセーフティ

2.代理店モデルについての理解を話す

プロキシ モードはオブジェクトにプロキシを提供するもので、プロキシ オブジェクトは元のオブジェクトへの参照を制御します。

利点:

プロキシ モードでは呼び出し元と呼び出し先を調整できるため、システムの結合がある程度軽減されます。

プロキシされたオブジェクトの機能やサービスの一部を柔軟に非表示にしたり、追加の機能やサービスを追加したりできます。

Ali の内部情報の欠点:

プロキシ モードを使用するため、プログラムのパフォーマンスは直接呼び出しのパフォーマンスほど高くありません。

プロキシ パターンを使用すると、コードが複雑になります。

黄牛卖火车票：没有流行网络购票的年代是很喜欢找黄牛买火车票的，因为工作忙的原因，没时间

去买票，然后就托黄牛给你买张回家过年的火车票。这个过程中黄牛就是代理人，火车票就是被代

理的对象。

婚姻介绍所：婚姻介绍所的工作人员，搜集单身人士信息，婚介所的工作人员为这个单身人士找对

象，这个过程也是代理模式的生活案例。对象就是被代理的对象。

注意了，问代理模式的时候，很有可能会问：动态代理。在Spring篇中已经讲述过，如果你把动态

代理讲了后，很有可能还会问什么是静态代理？一个洞一个是静，大致也能才出来，就是中间代理

层使我们手动写的，通常说的代理模式就是静态代理。

3、说说工厂模式

答：简单工厂模式又叫静态工厂方法模式，就是建立一个工厂类，对实现了同一接口的一些类进行

实例的创建。比如，一台咖啡机就可以理解为一个工厂模式，你只需要按下想喝的咖啡品类的按钮

（摩卡或拿铁），它就会给你生产一杯相应的咖啡，你不需要管它内部的具体实现，只要告诉它你

的需求即可。

优点：

工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除

直接创建产品对象的责任，而仅仅“消费”产品；简单工厂模式通过这种做法实现了对责任的分

割，它提供了专门的工厂类用于创建对象；

客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可，对于

一些复杂的类名，通过简单工厂模式可以减少使用者的记忆量；

通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一

定程度上提高了系统的灵活性。

缺点：

不易拓展，一旦添加新的产品类型，就不得不修改工厂的创建逻辑；

产品类型较多时，工厂的创建逻辑可能过于复杂，一旦出错可能造成所有产品的创建失败，不

利于系统的维护。

4、抽象工厂模式

回答: 抽象ファクトリ パターンは、単純なファクトリに基づいて将来変更が必要になる可能性のあるコードを抽象化し、

サブクラスが決定を行います。

アリの内部情報、例えば上記のコーヒー工場を例に挙げると、ある日突然私の好みが変わりました。

単純なファクトリでコードを直接変更することは洗練されていないだけでなく、ソフトウェア設計の「オープン/クローズ原則」にも準拠していません。

新しいカテゴリに合わせて元のコードを変更する必要があります。このとき、メソッドのみを宣言する抽象ファクトリクラスを利用することができます。

サブクラス（サブファクトリー）の実装を行うことになりますが、この時は新たなカテゴリーの需要があり、新たにコードを作成するだけで済みます。

5.デコレーターパターンとは何ですか

回答: デコレーター パターンとは、オブジェクトの構造を変更せずに、オブジェクトにいくつかの追加機能を動的に追加することを指します。

利点: 装飾クラスと装飾クラスは互いに結合することなく独立して開発できます。装飾モードは継承の代替モードです。

式は、実装クラスの機能を動的に拡張できます。

デコレータ パターンのキー: デコレータで装飾されたオブジェクトが使用されます。

たとえば、「laowang」というオブジェクトを作成し、そのオブジェクトにさまざまな装飾を追加し、ジャケットを着たり、帽子をかぶったり...、この実行プロセス

デコレータパターンです。

有名な言葉です。「人は衣服に依存し、馬は鞍に依存します。」これらはすべてデコレーター モードのライフ ケースです。

6.プロキシ モードとデコレータ モードの違いは何ですか?

回答: いずれも構造モードであり、プロキシ モードはアクセス権の制御に重点を置き、デコレータ モードは機能の拡張に重点を置いています。

7.テンプレートメソッドパターン

回答: テンプレート メソッド パターンは、アルゴリズムのスケルトンを定義し、特定のコンテンツをサブクラスに遅らせて実装することを指します。

利点:

コードの再利用性を向上します。コードの同じ部分を抽象親クラスに配置し、異なるコードを異なるサブクラスに配置します。

逆制御が実現されます。親クラスを通じてそのサブクラスの操作を呼び出し、サブクラスの特定の実装を通じてさまざまな動作を拡張します。

逆制御が実現され、開閉の原理に準拠します。

お茶を飲む：お湯を沸かして茶葉を入れてお茶を飲みます。入れる茶葉は人によって異なり、プーアール茶もあれば鉄関茶もある

音など

毎日の仕事: 出勤時刻を記録し、出勤し、退勤時刻を記録します。バックエンド開発、フロントエンド開発、テストと人それぞれ仕事内容は異なります

テストや製品ごとに作業内容が異なります。

8.フライウェイトモードをご存知ですか?

回答: 名前が示すように、これは共有ユニットです。フライウェイト パターンの目的は、フライウェイト オブジェクトが利用できない場合に、オブジェクトを再利用してメモリを節約することです。

オブジェクトを変更します。

具体的に言うと、システム内に多数の重複オブジェクトがある場合、それらの重複オブジェクトが不変オブジェクトであれば、次のようになります。

オブジェクトはフライウェイト パターンを使用してフライウェイトとして設計でき、複数のコードによる参照のためにメモリ内にインスタンスが 1 つだけ保持されます。これにより内部の

ストレージ内のオブジェクトの数は、メモリを節約するために使用されます。

一般的な使用シナリオ: Integer のキャッシュは、フライウェイト モードの古典的な実装です。

フライウェイト パターンとシングルトン パターンはどのように同じように見えますか? 面接官はおそらく次のような質問を続けるでしょう。

9.フライウェイト モードとシングルトン モードの違いは何ですか?

回答: シングルトン モードは、1 つのオブジェクトのみに焦点を当てる作成モードです。フライウェイト モードは構造的なモードであり、メモリの節約とメモリの使用に重点を置いています。

プログラムのパフォーマンスを向上させるために使用します。

フライウェイト モード: Huo Cun の使用時に 1 つ以上のオブジェクトをキャッシュから直接取得できます。つまり、フライウェイトモードは異なります

オブジェクトは 1 つだけ存在する必要があります。

10.私たちの人生における戦略パターンのシナリオについて教えてください。

回答: 戦略パターンとは、一連のアルゴリズムを定義し、各アルゴリズムをカプセル化し、それらを交換可能にすることを指します。

利点: 開閉の原理に従い、優れた拡張性を備えています。

短所: 戦略の増加に伴い、外部エクスポージャがますます増加します。

すべての道はローマに通ず、すべての道は北京に通ずる。

私たちが北京に行くには、飛行機、高速鉄道、自分で車など、さまざまな交通手段（戦略）があります。あらゆる方法で

それぞれの戦略を理解してください。

これが人生における戦略パターンです。

11.責任連鎖モデルをご存知ですか?

回答: 動作設計パターンの 1 つであり、チェーン内の各ノードをオブジェクトとして扱い、各ノードが異なるリクエストを処理します。

そして、次のノード オブジェクトは内部で自動的に維持されます。リクエストがチェーンのヘッドエンドから送信されると、そのリクエストはチェーンのヘッドエンドに渡されます。

オブジェクトがリクエストを処理するまで、各ノードはオブジェクトを処理します。

アドバンテージ

リクエストと処理を分離。

リクエスト ハンドラー (ノード オブジェクト) は、関心のあるリクエストに焦点を当てて処理するだけで済みます。関心のないリクエストについては、直接実行できます。

次に、それを次のレベルのノード オブジェクトに転送します。

チェーン転送処理リクエスト機能を使用すると、リクエスト送信者はリンク構造を知る必要がなく、リクエスト処理結果を待つだけで済みます。

リンク構造は柔軟であり、リンク構造を変更することで責任を動的に追加または削除できます。

オープンとクローズの原則に従って、新しいリクエスト処理クラス (ノード) を簡単に拡張できます。

欠点がある

Ali の内部データ責任リンクが長すぎる場合、リクエストの配信と処理の効率に影響を与える可能性があります。

ノード オブジェクトへの循環参照がある場合、無限ループが発生し、システムがクラッシュします。

ライフケース: 社内で OA 承認プロセス、プロジェクト マネージャーの承認、部門マネージャーの承認を開始します。上司の承認、人的資源

承認。これは人生における責任の連鎖モデルであり、それぞれの役割の責任は異なります。

SpringMVC のインターセプターと Mybatis のプラグイン メカニズムはどちらもインターセプターの古典的な実装です。

12.アダプターモードについて理解しましたか?

回答: アダプター モードは、クラスのインターフェイスをクライアントが期待する別のインターフェイスに変更することで、インターフェイスによって元のインターフェイスが一致しないようにします。

連携しない 2 つのクラスも連携できます。

利点:

これにより、無関係な 2 つのクラスを一緒に実行し、中間変換の役割を果たすことができます。

柔軟性が高く、元のシステムを破壊しません。

短所: アダプターを過度に使用すると、コード構造が混乱しやすくなります。たとえば、A インターフェイスが呼び出されているのに、内部呼び出しは B であることがはっきりとわかるなどです。

インターフェースの実装。

人生のソケットは、さまざまなプラグに適応するために、2つの穴と3つの空の穴があり、基本的に適応できます。ユニバーサル充電器もあります

電化製品、USBインターフェースなど これらは人生におけるアダプターのパターンです。

13.オブザーバーパターンをご存知ですか?

回答: オブザーバー モードは、オブジェクト間の 1 対多の依存関係を定義することで、オブジェクトの状態が変化するたびに、その関連関係が変化するようにします。

依存オブジェクトは自動的に通知され、更新されます。オブザーバー モードは、パブリッシュ/サブスクライブ (パブリッシュ/サブスクライブ) モード、モデルとも呼ばれます。

Type-View (Model/View) パターン、Source-Listener (Source/Listener) パターン、または dependents (依存関係) パターン

モード。利点:

オブザーバー モードは、プレゼンテーション層とデータ ロジック層の分離を実現でき、安定したメッセージ更新配信メカニズムを定義し、抽象化します。

更新接口，使得可以有各种各样不同的表示层作为具体观察者角色；

观察者模式在观察目标和观察者之间建立一个抽象的耦合；

观察者模式支持广播通信；

观察者模式符合开闭原则（对拓展开放，对修改关闭）的要求。

缺点：

如果一个观察目标对象有很多直接和间接的观察者的话，将所有的观察者都通知到会花费很多

时间；

如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能

导致系统崩溃；

观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知

道观察目标发生了变化。

阿里内部资料在观察者模式中有如下角色：

Subject：抽象主题（抽象被观察者），抽象主题角色把所有观察者对象保存在一个集合里，每

个主题都可以有任意数量的观察者，抽象主题提供一个接口，可以增加和删除观察者对象；

ConcreteSubject：具体主题（具体被观察者），该角色将有关状态存入具体观察者对象，在

具体主题的内部状态发生改变时，给所有注册过的观察者发送通知；

Observer：抽象观察者，是观察者者的抽象类，它定义了一个更新接口，使得在得到主题更改

通知时更新自己；

ConcrereObserver：具体观察者，实现抽象观察者定义的更新接口，以便在得到主题更改通知

时更新自身的状态。

在Spring中大量的使用的观察者模式，只要看到是以Event结尾或者Publish开头的基本上都是观察

者模式。

上面一共说了11种设计模式，这些设计模式能应对绝大多数人和面试场景来说。建议私下自己用代

码实现一番，便于更好地理解。

maven篇

1、什么是maven？

maven主要服务于基于java平台的项目构建，依赖管理和项目信息管理。

maven项目对象模型(POM)，可以通过一小段描述信息来管理项目的构建，报告和文档的项目管理

ツールソフトウェア。これには、プロジェクト オブジェクト モデル、標準のコレクション、プロジェクトのライフサイクル、依存関係管理システム、および

ライフサイクル フェーズでプラグインの目標を定義するロジックを実行するために使用されます。Maven を使用する場合は、明確に定義されたプロジェクトを使用します。

オブジェクト モデルを使用してプロジェクトを記述すると、Maven は一連の共有 (またはカスタム) ロジックから横断的なロジックを適用できます。

定義済み) プラグイン。

2. Maven はどのような問題を解決できますか?

①サードパーティのjarパッケージを追加する

最も原始的な方法によれば、jar パッケージをプロジェクト WEB-INF/lib に手動でコピーします。各プロジェクトにはコピーが存在し、その結果、多数の

ファイルが重複しています。Maven は jar パッケージをローカルの倉庫に配置して一元管理し、jar パッケージは座標で参照するだけで済みます。

②jarパッケージ間の依存関係

jar パッケージは独立していないことが多く、多くの jar が正常に動作するには他の jar パッケージのサポートが必要です。これを jar パッケージ間の依存関係と呼びます。

関係によります。手動でインポートする場合、jar パッケージ間の依存関係を把握して 1 つずつインポートする必要があるため、非常に面倒でエラーが発生しやすくなります。

の。Maven を使用する場合、現在の jar パッケージが依存する他のすべての jar パッケージをインポートできます。

③サードパーティのjarパッケージを入手する

Ali の内部データの開発プロセスでは、多くの jar パッケージを使用する必要があり、それぞれの jar パッケージを公式 Web サイトから取得する方法が異なるため、作業がさらに困難になります。

災害。ただし、Maven を使用すると、座標の形式で jar パッケージに依存することができ、Maven は中央倉庫からそれをダウンロードし、これらの jar パッケージを同時にダウンロードします。

jar パッケージが依存する他の jar パッケージ。

④ プロジェクトを複数のエンジニアリングモジュールに分割する

プロジェクトの規模はますます大きくなり、パッケージ構造によってモジュールを分割することができなくなり、共同作業のためにプロジェクトを複数のプロジェクトに分割する必要があります。

発展。

3. Mavenの長所と短所は何ですか?

アドバンテージ

プロジェクトの依存関係管理の簡素化

使いやすく、初心者でもいくつかの一般的なコマンドを理解するだけで日常の作業に対応できます。

継続的統合ツール (jenkins) との統合が簡単

プロジェクト自体であっても、プロジェクトで使用される依存関係であっても、プロジェクトを簡単にアップグレードできます。

Mavenには、本番サイトや自動リリース版などの機能拡張に便利なプラグインが多数用意されています。

Maven で pips を使用する理由

欠点がある

Maven は学習するのが難しい巨大なビルド システムです。(多くの人にも同じことが言えます。始めるのは簡単ですが[利点]があり、熟練しています

難しい[欠点])

Maven は設定より規約を優先する戦略を採用しており、簡単に始めることができますが、一度問題が発生すると、ネットワーク環境でのデバッグが困難になります。

残念ながら、多くのリポジトリにアクセスできません

5. Mavenの座標は何ですか?

Maven の中核機能の 1 つは、プロジェクトの依存関係を管理し、必要なさまざまな jar パッケージを導入することです。ソリューションを自動化できるようにするには

Java コンポーネントを分析するには、Maven がこれらの Jar パッケージまたはその他のリソースを一意に識別する必要があります。これは、プロジェクトの依存関係を管理するための基礎となります。

基礎、つまり私たちが話している座標です。自社で開発したプロジェクトも含めて、座標によって一意に識別できる必要があるため、

他のプロジェクトで依存参照を作成するため。

Maven の座標は、groupId、artifactId、および version を通じてコン​​ポーネントを一意に識別します。groupId は通常、会社名または組織名です。

通常、artifactId はプロジェクト名で、versionId はバージョン番号です。

6. Mavenのライフサイクルについて話す

Maven のライフサイクル: プロジェクトの構築からプロジェクトのリリースのプロセスまで。

各ステージの説明:

Alibaba の内部情報7.あなたがよく知っているMavenコマンドを教えてください。

mvn アーキタイプ:生成 Maven プロジェクトの作成

mvn コンパイル コンパイル ソース コード

mvn デプロイ パブリッシュ プロジェクト

mvn test-compile コンパイルテストのソースコード

mvn test はアプリケーションで単体テストを実行します

mvn サイト プロジェクト関連情報 Web サイトを生成します

mvn clean はプロジェクト ディレクトリ内の生成された結果をクリアします

プロジェクトに従ってmvnパッケージによって生成されたjar

mvn install ローカル リポジトリに jar をインストールします

Mvn eclipse:eclipse は Eclipse プロジェクト ファイルを生成します

Mvnjetty:run は桟橋サービスを開始します

mvntomcat:run 启动tomcat服务

mvn clean package -Dmaven.test.skip=true:清除以前的包后重新打包，跳过测试类

8、如何解决依赖传递引起的版本冲突？

可通过dependency的exclusion元素排除掉依赖。

9、说说maven的依赖原则

最短路径原则（依赖传递的路径越短越优先）

pom文件申明顺序优先（路径长度一样，则先申明的优先）

阿里内部资料覆写原则（当前pom文件里申明的直接覆盖父工程传过来的）

10、说说依赖的解析机制？

当依赖的范围是 system 的时候，Maven 直接从本地文件系统中解析构件。

根据依赖坐标计算仓库路径，尝试直接从本地仓库寻找构件，如果发现对应的构件，就解析成功。

如果在本地仓库不存在相应的构件，就遍历所有的远程仓库，发现后，下载并解析使用。

如果依赖的版本是 RELEASE 或 LATEST，就基于更新策略读取所有远程仓库的元数据文件

（groupId/artifactId/maven-metadata.xml），将其与本地仓库的对应元合并后，计算出

RELEASE 或者 LATEST 真实的值，然后基于该值检查本地仓库，或者从远程仓库下载。

如果依赖的版本是 SNAPSHOT，就基于更新策略读取所有远程仓库的元数据文件，将它与本地仓库

对应的元数据合并，得到最新快照版本的值，然后根据该值检查本地仓库，或从远程仓库下载。

如果最后解析得到的构件版本包含有时间戳，先将该文件下载下来，再将文件名中时间戳信息删

除，剩下 SNAPSHOT 并使用（以非时间戳的形式使用）。

11、说说插件的解析机制

与依赖的构件一样，插件也是基于坐标保存在Maven仓库中。在用到插件的时候会先从本地仓库查

プラグインを見つけます。ローカル ウェアハウスにプラグインがない場合は、リモート ウェアハウスからプラグインを見つけて、ローカル ウェアハウスにダウンロードします。通常の依存関係アーティファクトとは異なります

はい、Maven は通常の依存関係のリモート リポジトリとプラグインのリモート リポジトリを異なる方法で扱います。前述のリモート ウェアハウスの構成は、一般的なものにのみ影響します。

一般的な依存関係は機能します。Maven に必要なプラグインがローカル ウェアハウスに存在しない場合、以前に構成したリモート ウェアハウスには送信されません。

プラグインの場合は、専用のプラグイン リモート ウェアハウスが必要です。

ElasticSearch篇

1.単語分割と転置インデックスの原理について話す

まず、単語の分割は検索のためのものです。

英語: 一度に 1 語ずつ、とてもシンプルです。私は学生です。単語はスペースで区切られます。

中国人: 私は学生なので、単語ごとに区切ることはできません、私は学生です。これは良いスコアです。また曖昧でユーザーを困らせる

使うユーザーも作るユーザーも安心してください。人間にとっては簡単ですが、機械にとっては非常に困難です。市場にはさまざまなトークナイザーが存在しますが、

効率性の重視と正確さの重視。

逆インデックス: 逆インデックスは前方行用です。

1. 最前列は、ES のよくある問題の概要について説明した文書がコンピューターにあることを覚えています。それからドキュメントを見つけて上から下にスクロールしました

ページで ES セクションを見つけます。文書を通じて文書の内容を見つけます。

Ali 内部情報 2. 反転: txt ファイル ES FAQ -> D:/配布問題の概要.doc。

したがって、反転とは、文書の内容によって文書を見つけることです。もちろん、内容がすべてではありません。それ以外の場合は文書を見つける必要はありません。内容はほんの一部です。

それで全部です。ここのtxtは検索エンジンです。

2.セグメント化ストレージのアイデアについて話す

Lucene はよく知られた検索オープン ソース ソフトウェアであり、ElasticSearch および Solr の下部で使用されます。

セグメント化されたストレージは Lucene のアイデアです。

初期の頃、ドキュメント全体に対して大規模な転置インデックスが構築されました。シンプルで速いですが、問題も伴います。

ドキュメントに小さな変更があり、インデックス全体を再構築する必要があります。速度が遅く、コストが高くなります。速度を向上させるには、定期的に更新してください。

有効性は悪いです。

インデックス ファイルは複数のサブファイルに分割され、各サブファイルはセグメントになります。変更されたデータの影響を受けないセグメントは処理する必要はありません。

3.セグメントの統合に関する戦略的思考についての理解について話す

分段的思想大大的提高了维护索引的效率。但是随之就有了新的问题。

每次新增数据就会新增加一个段，时间久了，一个文档对应的段非常多。段多了，也就影响检索性

能了。

检索过程：

1. 查询所有短中满足条件的数据

2. 对每个段的结果集合并

所以，定期的对段进行合理是很必要的。真是天下大势，分久必合合久必分。

策略：将段按大小排列分组，大到一定程度的不参与合并。小的组内合并。整体维持在一个合理的

大小范围。当然这个大到底应该是多少，是用户可配置的。这也符合设计的思想。

4、了解文本相似度 TF-IDF吗

简单地说，就是你检索一个词，匹配出来的文章，网页太多了。比如 1000 个，这些内容再该怎么

呈现，哪些在前面哪些在后面。这需要也有个对匹配度的评分。

TF-IDF 就是干这个的。

TF = Term Frequency 词频，一个词在这个文档中出现的频率。值越大，说明这文档越匹配，

正向指标。

IDF = Inverse Document Frequency 反向文档频率，简单点说就是一个词在所有文档中都出

现，那么这个词不重要。比如“的、了、我、好”这些词所有文档都出现，对检索毫无帮助。反

向指标。

阿里内部资料TF-IDF = TF / IDF

复杂的公式，就不写了，主要理解他的思想即可。

5、能说说ElasticSearch 写索引的逻辑吗？

ElasticSearch 是集群的 = 主分片 + 副本分片。

写索引只能写主分片，然后主分片同步到副本分片上。但主分片不是固定的，可能网络原因，之前

还是 Node1 是主分片，后来就变成了 Node2 经过选举成了主分片了。

客户端如何知道哪个是主分片呢？

看下面过程。

1. 客户端向某个节点 NodeX 发送写请求

2. NodeX 通过文档信息，请求会转发到主分片的节点上

3. プライマリ シャードが処理されると、データを同期するようにレプリカ シャードに通知し、成功メッセージを Nodex に送信します。

4. Nodexは処理結果をクライアントに返します。

6. ElasticSearchクラスター内のデータを検索するプロセスに精通していますか?

1. クライアントはクラスターにリクエストを送信し、クラスターはリクエストを処理する NodeX をランダムに選択します。

2. Nodex は最初に、ドキュメントがどのプライマリ シャードにあるかを計算します。たとえば、プライマリ シャード A には 3 つのコピー A1、A2、および A3 があります。それからリクエストしてください

3 つのレプリカのうち 1 つがポーリングされて、リクエストが完了します。

3. シャードを確認できない場合、たとえば、検索がドキュメントではない場合、すべてのシャードが走査されます。

さらに、ノードのストレージ容量には限界があるため、シャーディングという概念があります。ただし、フラグメントが失われる可能性があるため、二次的なものがあります。

本のコンセプト。

例えば：

ES クラスターには 3 つのシャード (シャード A、シャード B、シャード C) があり、シャード A + シャード B + シャード C = すべてのデータ、各シャード

作品は1/3くらいです。フラグメント A にはコピー A1 A2 A3 があり、データは同じです。

7. ElasticSearchにおける深いページめくりの問題とその解決策を理解していますか?

深いページめくり: たとえば、一度検索し、すべてのフラグメントをポーリングし、結果を収集し、TF-IDF などのアルゴリズムに従ってスコアを付け、上位 10 をソートします。

データが返されます。ユーザーは気分が良くなり、次のページを見たとします。TF-IDF によると、ES は引き続きすべてのシャードをポーリングし、結果を収集します

アルゴリズムがスコアを付けるのを待ち、並べ替え後に最初の 11 ～ 20 個のデータを返します。

ユーザーにとって、ページをめくるのは速いはずですが、実際には、最初の検索の複雑さは次の検索と同じくらい複雑になります。

解決すると、ユーザーの検索結果を Redis に 10 分間保存できます。このページングは​​非常に速く、10 分以上かかります。

ページをめくらないとページがめくれなくなり、データが消去される場合があります。

8. ElasticSearchのパフォーマンス最適化に精通している

Ali 内部情報1.一括送信

バックグラウンドでは大量の書き込み操作が行われ、各コミットはネットワーク オーバーヘッドになります。ネットワークは常に最適化の焦点です。

2.ハードディスクの最適化

インデックス ファイルはハードディスク上に配置する必要があり、セクションのアイデアにより、より小さなファイルがもたらされるため、ディスク IO が ES のパフォーマンスのボトルネックになります。ソリッドステートハードドライブ

ディスクは通常のハードディスクよりもはるかに優れています。

3.コピー数を減らす

レプリカはクラスターの可用性を保証できますが、インデックスの書き込み効率に重大な影響を与えます。インデックスを書き込むときは、インデックスが書き込まれるだけでなく、

インデックスのレプリカへの同期。ES はストレージ エンジンではないため、データ損失を考慮せず、パフォーマンスがより重要です。バッチインポートの場合は、ビルドします

コピーを閉じます。

9. ElasticSearchクエリの最適化方法とは何ですか?

設計段階のチューニング

(1) ビジネスの増分要件に従って、日付テンプレートに基づいてインデックスを作成し、ロールオーバー API を通じてインデックスをロールします。

(2) インデックス管理にはエイリアスを使用します。

(3) スペースを解放するために、毎朝定期的にインデックスに対して Force_merge 操作を実行します。

(4) ホットとコールドの分離機構を採用し、ホットデータはSSDに格納して検索効率を向上させ、コールドデータは定期的に縮小してデータ量を削減します。

マイナスストレージ。

(5) インデックスのライフサイクル管理にキュレーターを使用します。

(6) 分割する必要があるフィールドに対してのみ、単語セグメンタを合理的に設定します。

(7) マッピング ステージでは、各フィールドの属性、取得する必要があるかどうか、保存する必要があるかどうかなどを完全に組み合わせます。……

書き込みチューニング

(1) 書き込み前のコピー数を 0 に設定します。

(2) 書き込む前にrefresh_intervalをオフにし、-1に設定してリフレッシュメカニズムを無効にします。

(3) 書き込みプロセス中: 一括書き込みが採用されます。

（４）書き込み後のコピー数とリフレッシュ間隔を復元する。

(5) 自動生成された ID を使用してみます。

クエリのチューニング

(1) ワイルドカードを無効にする。

(2) バッチ条件 (数百または数千のシナリオ) を無効にします。

Ali の内部データ (3) は転置インデックスのメカニズムを最大限に活用しており、キーワードの種類は可能な限りキーワードにすることができます。

（４）データ量が多い場合には、検索前に時間に基づいてインデックスを確定することができる。

(5) 合理的なルーティングメカニズムをセットアップします。

その他のチューニング

導入チューニング、ビジネスチューニングなど

上記の部分では、面接官は基本的に、これまでの実務や運用保守の経験を​​評価します。

10. elasticsearch はマスター選挙をどのように実装しますか?

インタビュアー: ビジネス レベルだけに焦点を当てるのではなく、ES クラスターの基礎となる原則を理解したいと考えています。

前提条件:

(1) マスターノード候補となるノード(master:true)のみがマスターノードになれます。

(2) マスター ノードの最小数 (min_master_nodes) の目的は、スプリット ブレインを防止することです。

コードを確認すると、コア エントリは fifindMaster で、マスター ノードが正常に選択された場合は、対応するマスターが返され、それ以外の場合は null が返されます。選択する

手順は大まかに次のように説明されます。

ステップ1: マスターノード候補の数が基準（elasticsearch.ymlに設定した値）に達していることを確認する

Discovery.zen.minimum_master_nodes；

ステップ 2: 比較: まずマスター資格があるかどうかを判断し、候補マスター ノード資格を持つものが最初に返されます。

両方のノードがマスター ノード候補である場合、ID が小さい方がマスター ノードになります。ここでの ID は文字列型であることに注意してください。

余談: ノード ID を取得する方法。

GET /_cat/nodes?v&h=ip,port,heapPercent,heapMax,id,name

ip port heapPercent heapMax ID 名

11. elasticsearch のインデックス データが多すぎる場合はどうすればよいですか? 調整してデプロイするにはどうすればよいですか?

インタビュアー: 大量のデータの運用と保守の機能を理解したいと考えています。

回答: インデックス データの計画は、早い段階で綿密に計画する必要があります。格言にあるように、「最初に設計し、後でコーディング」することで、効果的に回避できます。

データの突然の急増は、クラスターの処理能力の不足により、オンライン顧客検索やその他のビジネスに影響を与えます。

チューニング方法:

動的インデックスレベル

Ali の内部情報は、ローリング ベースでインデックスを作成するためのテンプレート + 時間 + ロールオーバー API に基づいています。例: 設計フェーズの定義: ブログ インデックスのテンプレート形式は次のとおりです。

blog_index_timestamp の形式で、データは毎日増加します。これを行う利点: 単一インデックスのデータ量が急増しない

これは非常に大きく、上の行 2 の 32 乗 -1 に近く、インデックス ストレージは TB+、またはそれ以上に達しています。

1 つのインデックスが非常に大きくなると、ストレージなどのさまざまなリスクが発生するため、事前に検討して早めに回避してください。

ストレージ層

コールド データとホット データは別々に保存され、ホット データ (過去 3 日間または 1 週間のデータなど) が保存され、残りはコールド データになります。

新しいデータを書き込むことのないコールド データの場合は、ストレージ領域を節約するために定期的な Force_merge と縮小圧縮操作を検討できます。

検索効率。

導入レベル

以前に計画がなくなったら、これは緊急戦略です。

動的拡張をサポートする ES 独自の機能と組み合わせることで、マシンを動的に追加する方法により、クラスターへの負荷を軽減できます。

ノードやその他の計画は合理的であり、クラスターを再起動せずに動的追加を完了できます。

12.御社のクラスタ アーキテクチャ、インデックス データのサイズ、およびフラグメントの数について教えてください。

面接官: 申請者の会社がこれまでに経験したESの利用シナリオや規模、比較的大規模なインデックス設計を行ったことがあるのか​​知りたいのですが、

企画、調整。

回答: 正直に答えて、独自の実際的なシナリオを組み合わせてください。

例: ES クラスター アーキテクチャには 13 ノードがあり、インデックスにはさまざまなチャネルに従って合計 20 以上のインデックスがあります。日付によると、毎日の増分は 20 以上で、インデックスは次のようになります。

10 シャード、毎日 1 億以上のデータ増分、各チャネルの毎日のインデックス サイズ制御: 150 GB 以内。

13. ElasticSearchとは何ですか?

Elasticsearch は、Lucene ベースの検索エンジンです。HTTP Web およびスキーマフリーの JSON ドキュメントを使用したディストリビューションを提供します

スタイルの、マルチテナント対応の全文検索エンジン。Elasticsearch は Java で開発されており、[Apache] ライセンスの条件に基づいてオープン ソースとして利用できます。

リリース。

14. ElasticSearchのクラスター、ノード、インデックス、ドキュメント、タイプとは何ですか?

クラスターは、データ全体を一緒に保持し、提供する 1 つ以上のノード (サーバー) の集合です。

共同インデックス作成および検索機能。クラスターは一意の名前で識別されます。デフォルトでは「elasticsearch」です。この名前は重要です、

ノードは、名前でクラスターに参加するように設定されている場合にのみクラスターの一部になれるためです。

ノードは、クラスターの一部である単一のサーバーです。データを保存し、クラスターのインデックス作成および検索機能に参加します。

インデックスは、リレーショナル データベースの「データベース」に似ています。複数のタイプを定義するマップがあります。インデックスはマッピングする論理名前空間です。

1 つ以上のプライマリ シャードをターゲットとし、0 個以上のレプリカ シャードを持つことができます。MySQL => データベース ElasticSearch

=> インデックス

Ali の内部情報文書は、リレーショナル データベースの行に似ています。違いは、インデックス内の各ドキュメントが異なる構造 (単語) を持つことができることです。

セグメント）ですが、共通フィールドのデータ型は同じである必要があります。MySQL => データベース => テーブル =>

列/行 ElasticSearch => インデックス => タイプ => 属性を持つドキュメント

タイプはインデックスの論理的なカテゴリ/パーティションであり、そのセマンティクスは完全にユーザー次第です。

15. ElasticSearchのシャーディングとは何ですか?

ほとんどの環境では、各ノードは個別のボックスまたは仮想マシン上で実行されます。

インデックス-Elasticsearchでは、インデックスはドキュメントのコレクションです。

シャーディング - Elasticsearch は分散型検索エンジンであるため、通常、インデックスは次のように分割されます。

スライスと呼ばれる要素。

Ali 内部情報16 、ElasticSearchのレプリカとは何ですか?

インデックスは、分散とスケーリングを容易にするためにシャードに分割されます。レプリカはシャードのコピーです。ノードはクラスターに属するノードです

ElasticSearch の実行中のインスタンス。クラスターは、同じクラスター名を共有する 1 つ以上のノードで構成されます。

19. ElasticSearchのアナライザーとは何ですか?

ElasticSearch でデータのインデックスが作成されると、データはインデックスに対して定義された Analyzer によって内部的に変換されます。アナライザーは次のもので構成されます。

Tokenizer と 0 個以上の TokenFilter コンポーネント。コンパイラは 1 つ以上の CharFilter の前に置くことができます。分析モジュールにより、

アナライザーを論理名で登録すると、マッピング定義または一部の API で参照できるようになります。

Elasticsearch には、すぐに使用できる多数の構築済みアナライザーが付属しています。あるいは、組み込みの文字フィルターを組み合わせてコンパイルすることもできます。

カスタム アナライザーを作成するためのフィルターとフィルター。

20. ElasticSearchのコンパイラとは何ですか?

Ali の内部データ コンパイラは、文字列を用語またはトークン ストリームに分解するために使用されます。単純なコンパイラは、空白文字が発生すると文字列を分割する可能性があります。

または句読点。Elasticsearch には、カスタム アナライザーの構築に使用できるトークナイザーが多数組み込まれています。

21. ElasticSearchのフィルターとは何ですか?

データはトークナイザーによって処理された後、インデックスが作成される前にフィルターによって処理されます。

22 、属性、インデックス作成、ストレージを有効にする目的は何ですか?

Enabled 属性は、インデックスやサイズなど、さまざまな ElasticSearch 固有/クリエイティブ フィールドに適用されます。ユーザー指定のフィールドに「有効」がありません

「property.stored」は、データが Lucene によって保存され、要求された場合に返されることを意味します。

保存されたフィールドは必ずしも検索可能ではありません。デフォルトでは、フィールドは保存されませんが、ソース ファイルは完成しています。デフォルトを使用したいため

value (これは当然のことです) であるため、検索のために store 属性を Index 属性に設定しないでください。

インデックス付きプロパティは検索のみに使用できます。インデックス付きフィールドのみを検索できます。不一致の理由は、分析中のインデックス付きフィールドの変換です。

スワップするため、必要に応じて元のデータを取得できません。

トムキャット_

1. Tomcatのデフォルトのポートとその変更方法は何ですか?

默认端口为8080，可以通过在tomcat安装包conf目录下，service.xml中的Connector元素的port

属性来修改端口。

阿里内部资料2、tomcat 有哪几种Connector 运行模式(优化)？

这三种模式的不同之处如下：

BIO ：一个线程处理一个请求。缺点：并发量高时，线程数较多，浪费资源。Tomcat7版本或更低

版本中，在Linux系统中默认使用这种方式。

NIO ：利用Java的异步IO处理，可以通过少量的线程处理大量的请求。tomcat8.0.x中默认使用的是

NIO。Tomcat7必须修改Connector配置来启动：

<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"

connectionTimeout="20000" redirectPort="8443"/>

APR ：即Apache Portable Runtime，从操作系统层面解决io阻塞问题。Tomcat7或Tomcat8在

Win7或以上的系统中启动默认使用这种方式。

3、Tomcat有几种部署方式？

利用Tomcat的自动部署：把web应用拷贝到webapps目录（生产环境不建议放在该目录

中）。Tomcat在启动时会加载目录下的应用，并将编译后的结果放入work目录下。

使用Manager App控制台部署：在tomcat主页点击“Manager App” 进入应用管理控制台，可

Web アプリケーションまたは war ファイルへのパスを指定します。

conf/server.xml ファイルのデプロイメントを変更します。server.xml ファイルに、アプリケーションをデプロイするための Context ノードを追加します。

カスタム Web デプロイメント ファイルを追加します。xyz.xml ファイルを conf/Catalina/localhost/ パスの下に追加します。内容は次のとおりです。

コンテキスト ノードはアプリケーションをデプロイできます。

4. Tomcatコンテナはどのようにしてサーブレットクラスのインスタンスを作成しますか? どのような原理が使われているのでしょうか？

1. コンテナーが起動すると、webapps ディレクトリ内のすべての Web アプリケーションの web.xml ファイルが読み取られ、xml ファイルが編集されます。

サーブレットの登録情報を解析して読み取ります。次に、各アプリケーションに登録されているサーブレットクラスをロードし、

リフレクションによってインスタンス化されます。(最初のリクエストでインスタンス化される場合もあります)

2. サーブレットの登録時に 1 を加算し、正の数値の場合は先頭にインスタンス化され、未記述または負の数値の場合は初めてリクエストされます。

インスタンス化されました。

5. Tomcat を最適化するにはどうすればよいですか?

Web サーバーとしての Tomcat の処理パフォーマンスはユーザー エクスペリエンスに直接関係しており、一般的な最適化手段は次のとおりです。

web.xmlの監視を外し、サーブレットにjspを編集しておきます。物理メモリに余裕がある場合は、Tomcat が使用する JVM を増やします。

メモリー

サーバーが提供できる CPU、メモリ、およびハードディスクのパフォーマンスは、処理能力に決定的な影響を与えます。

同時実行性が高い状況では、大量の計算が行われるため、CPU の速度が処理速度に直接影響します。

Ali の内部データで大量のデータ処理がある場合、大量のメモリ容量が必要になるため、-Xmx -Xms - を使用できます。

XX:MaxPermSize およびその他のパラメータは、メモリのさまざまな機能ブロックを分割します。以前にもメモリ割り当て不足に遭遇したことがあり、

仮想マシンはフル GC になっており、処理能力が大幅に低下しています。

ハードディスクの主な問題は読み取りおよび書き込みのパフォーマンスであり、大量のファイルの読み取りおよび書き込みが行われると、ディスクがパフォーマンスのボトルネックになりやすくなります。一番いい方法

または、以下で説明するキャッシュを利用してください。

キャッシュと圧縮を活用する

静的ページの場合は、毎回ディスクから読み取らなくても済むように、キャッシュできることが最善です。ここではNginxを次のように使用します

キャッシュ サーバーは画像、CSS、JS ファイルをキャッシュし、バックエンド Tomcat へのアクセスを効果的に削減します。

さらに、ネットワーク転送を高速化するには、gzip 圧縮を有効にすることも重要です。しかし、Tomcat がすでに処理する必要があることを考えると、

管理すべきことがたくさんあるため、圧縮作業はフロントエンドの Nginx に引き継がれて完了します。

gzip で圧縮できるテキストに加えて、バランスを見つけるために画像処理ツールを使用して多くの画像を事前圧縮することもできます。

ポイントを使用すると、画質の低下が非常に少なくなり、ファイル サイズが大幅に削減されます。300 kb 以上から数十 kb に圧縮された画像を見たことがある

kb、違いはほとんどわかりません。

クラスターを採用する

単一サーバーのパフォーマンスには常に限界があり、水平方向の拡張を実現することが最善の方法であるため、Tomcat クラスターの構築はパフォーマンスを向上させる効果的な方法です。

できるという意味です。リクエスト分散用のサーバーとして引き続き Nginx を使用し、バックエンドの複数の Tomcat がセッションを共有して連携します。

する。以前に書いた「nginx+tomcat+memcached を使用して Web サーバーの負荷分散を構築する」を参照してください。

スレッド数を最適化する

コネクタ ポート = "8080" プロトコル = "HTTP/1.1" を検索し、maxThreads 属性と acceptCount 属性を追加します (make

acceptCount は maxThreads 以上です)。以下のようになります。

<コネクタポート="8080" プロトコル="HTTP/1.1"接続タイムアウト="20000"

redirectPort="8443"acceptCount="500" maxThreads="400" />

の：

• maxThreads: Tomcat がリクエスト処理に使用できるスレッドの最大数。デフォルトは 200 です。

• minSpareThreads: Tomcat の初期スレッド数、つまりアイドル状態のスレッドの最小数

• maxSpareThreads: Tomcat のアイドルスレッドの最大数。超過したスレッドは閉じられます。

• acceptCount: リクエストの処理に使用可能なスレッドをすべて使用した場合、処理キューに入れることができるリクエストの数が超過します。

この番号のリクエストは処理されません。デフォルトは 100 です。

スレッドプールの最適化を使用する

次のように、server.xml に executor ノードを追加し、コネクタの executor 属性を構成します。

<Executor name="tomcatThreadPool" namePrefix="req-exec-"maxThreads="1000"

minSpareThreads="50"maxIdleTime="60000"/>

<コネクタポート="8080" プロトコル="HTTP/1.1"executor="tomcatThreadPool"/>

Ali の内部情報には以下が含まれます。

• namePrefix: スレッド プール内のスレッド名のプレフィックス

• maxThreads: スレッド プール内のスレッドの最大数

• minSpareThreads: スレッド プール内のアイドル状態のスレッドの最小数

• maxIdleTime: アイドル状態のスレッドの最小数を超えると、より多くのスレッドがこの時間待機してから閉じられます。

• threadPriority: スレッドの優先順位

注: Tomcat に多数の同時ユーザーがいる場合、単一の JVM プロセスが実際に開くファイル ハンドルが多すぎる可能性があり、次のようなレポートが表示されます。

java.net.SocketException: 開いているファイルが多すぎるエラー。次の手順で確認できます。

• ps -ef |grep tomcat tomcat のプロセス ID を表示し、プロセス ID が 10001 であると仮定して ID 番号を記録します。

• lsof -p 10001|wc -l 現在のプロセス ID 10001 のファイル操作の数を表示します。

• コマンド ulimit -a を使用して、各ユーザーが開くことができるファイルの最大数を表示します。

起動速度の最適化

不要な Web アプリケーションを削除します。Tomcat は起動するたびにこれらのアプリケーションをデプロイするためです。

WebSocket: websocket-api.jar および tomcat-websocket.jar を閉じます。

乱数の最適化: JVM パラメーターを設定します: -Djava.security.egd=file:/dev/./urandom 。

メモリの最適化

Tomcat は起動後は Java プロセスであるため、この部分では JVM 部分の最適化のアイデアを参照できます。ヒープメモリ関連のパラメータ

数値、例:

• -Xms: 仮想マシンの初期化時の最小ヒープ メモリ。

• -Xmx: 仮想マシンが使用できる最大ヒープ メモリ。-Xms と -Xmx は、JVM による頻繁な GC の発生を避けるために同じ値に設定されます。

浮き沈みがある

• -XX:MaxNewSize: 新しい世代が占有するヒープメモリ全体の最大値。

その他、メソッド領域のパラメータ調整（注：JDKバージョン）、ガベージコレクタなどの最適化もあります。JVM 関連パラメータを参照してください: ステップごとに説明します

JVMチューニングパラメータを設定する

6. Tomcatの構成について詳しく知っていますか?

コンテキスト (Web アプリケーション、通常は WAR ファイルを表します。WAR に関する具体的な情報については、サーブレット仕様を参照してください) タグ。

docBase: Web アプリケーションまたは WAR のドキュメント ベース ディレクトリ (Document Base、コンテキスト ルートとも呼ばれます)

ファイルへのパス。絶対パス、またはコンテキストが属するホストを基準とした appBase パスを使用できます。

path: この Web アプリケーションの URL のプレフィックスを示します。つまり、要求された URL は http://localhost:8080/path/**** です。

Ali Internal data reloadable: この属性は非常に重要です。これが true の場合、Tomcat はアプリケーションの /WEB-INF/lib を自動的に検出します。

/WEB-INF/classes ディレクトリを変更すると、新しいアプリケーションが自動的にロードされ、Tomcat を再起動せずに変更できます。

応用。

useNaming : Catalina でこの Web アプリケーションの JNDI InitialContext オブジェクトを有効にする場合は、 true に設定します。したほうがいい

InitialContext は J2EE プラットフォームの規約に準拠しており、デフォルト値は true です。

workDir: Context によって提供される一時ディレクトリのパス。サーブレットの一時的な読み取り/書き込みに使用されます。使用

javax.servlet.context.tempdir プロパティにより、サーブレットはディレクトリにアクセスできます。指定されていない場合は、使用します

$CATALINA_HOME/work 下の適切なディレクトリ。

swallowOutput: 値が true の場合、System.out と System.err の出力は Web アプリケーションの出力にリダイレクトされます。

ロガー。指定しない場合、デフォルトは false です

debug : このエンジンに関連付けられたロガーによって記録されたデバッグ情報の詳細レベル。数値が大きいほど、出力はより詳細になります。そうでない場合

指定した場合、デフォルトは 0 です。

host (仮想ホストを表す) タグ。

name : ホスト名を指定します。

appBase : アプリケーションの基本ディレクトリ、つまりアプリケーションが保存されているディレクトリ。

unpackWARs: true の場合、Tomcat は WAR ファイルを自動的に解凍します。それ以外の場合、WAR ファイルは解凍されず、WAR ファイルから直接送信されます。

アプリケーションを実行します。

ロガー (ロギング、デバッグ、エラー メッセージ用) タブ。

className: ロガーによって使用されるクラス名を指定します。このクラスは org.apache.catalina.Logger インターフェイスを実装する必要があります。

prefix : ログ ファイルのプレフィックスを指定します。

suffix: ログ ファイルのサフィックスを指定します。

timestamp : true の場合、次の例のようにログ ファイル名に時刻が追加されます: localhost_log.2001-10-04.txt。

7. Tomcat とは何ですか?

Tomcat サーバーは、Apache Software Foundation プロジェクトの中核プロジェクトであり、無料のオープンソース Web アプリケーション サーバーです。

サーバー（サーブレットコンテナ）は軽量なアプリケーションサーバーであり、同時アクセスユーザーがそれほど多くない中小規模のシステムや場面で使用されます。

一般的に使用され、JSP プログラムの開発とデバッグの最初の選択肢です。

8.サーブレットとは何ですか?

Alibaba の内部データ サーブレットは JavaEE 仕様の一種で、主に Web サービスとしての Java の機能拡張とインターフェイスの統一を目的としています。他の社内工場による

Tomcat や Jetty などの企業は、Web 機能を内部で実装しています。http リクエストが到着した場合: コンテナはリクエストをサーブレットとしてカプセル化します。

HttpServletRequest オブジェクトは、init()、service()、およびその他のメソッドを呼び出して応答を出力します。応答はコンテナーによって httpresponse としてパッケージ化されます。

プロセスがクライアントに返されます。

9.サーブレット仕様とは何ですか?

Jar パッケージの観点から見ると、サーブレット仕様は 2 つの Jar ファイルです。servlet-api.jar と jsp-api.jar、Jsp も

サーブレット。

パッケージに関しては、javax.servlet と javax.servlet.http の 2 つのパッケージです。

インターフェースに関しては、Servletインターフェース、Filterインターフェース、Listenerインターフェース、ServletRequestインターフェース、

ServletResponseインターフェースなど クラス図は次のとおりです。

Alibaba 内部情報10. Tomcat をWebコンテナまたはサーブレットコンテナと呼ぶのはなぜですか?

グラフを使用してそれらの間の関係を表します。

簡単に理解すると、ServerSocket を開始し、ポート 8080 でリッスンします。サーブレットコンテナは、開発したサーブレットをインストールするために使用されます。

11. Tomcat はHttpリクエスト プロセスをどのように処理しますか?

ブラウザ上で入力するとします

http://localhost:8080/my-web-mave/index.jsp

在tomcat中是如何处理这个请求流程的：

1. 我们的请求被发送到本机端口8080，被在那里侦听的Coyote HTTP/1.1 Connector获得。

2. Connector把该请求交给它所在的Service的Engine来处理，并等待来自Engine的回应 。

阿里内部资料3. Engine获得请求localhost/my-web-maven/index.jsp，匹配它所拥有的所有虚拟主机Host ，

我们的虚拟主机在server.xml中默认配置的就是localhost。

4. Engine匹配到name=localhost的Host（即使匹配不到也把请求交给该Host处理，因为该Host

被定义为该Engine的默认主机）。

5. localhost Host获得请求/my-web-maven/index.jsp，匹配它所拥有的所有Context。

6. Host匹配到路径为/my-web-maven的Context（如果匹配不到就把该请求交给路径名为”"的

Context去处理）。

7. path=”/my-web-maven”的Context获得请求/index.jsp，在它的mapping table中寻找对应的

servlet 。

8. Context匹配到URL PATTERN为*.jsp的servlet，对应于JspServlet类。

9. 构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet

或doPost方法 。

10. Context把执行完了之后的HttpServletResponse对象返回给Host 。

11. Host把HttpServletResponse对象返回给Engine 。

12. Engine把HttpServletResponse对象返回给Connector 。

13. Connector把HttpServletResponse对象返回给客户browser 。

12、tomcat结构目录有哪些?

bin

启动，关闭和其他脚本。这些 .sh文件（对于Unix系统）是这些.bat文件的功能副本（对于

Windows系统）。由于Win32命令行缺少某些功能，因此此处包含一些其他文件。

比如说：windows下启动tomcat用的是startup.bat，另外Linux环境中使用的是startup.sh。对应

还有相应的shutdown关闭脚本。

conf

tomcat的配置文件和相关的DTD。这里最重要的文件是server.xml。它是容器的主要配置文件。

catalina.policy ：tomcat：安全策略文件，控制JVM相关权限，具体可以参考

java.security.Permission。

阿里内部资料catalina.properties ：tomcat Catalina 行为控制配置文件，比如：Common ClassLoader。

logging.properties ：tomcat日志配置文件。里面的日志采用的是JDK Logging。

server.xml ：tomcat server配置文件(对于我开发人员来说是非常重要)。

context.xml ：全局context配置文件，监视并加载资源文件，当监视的文件发生发生变化时，自

动加载 。

tomcat-user.xml ：tomcat角色配置文件。

web.xml ：Servlet标准的web.xml部署文件，tomcat默认实现部分配置 入内：

org.apache.catalina.servlets.DefaultServlet。

org.apache.jasper.servlet.JspServlet

logs

日志文件默认位于此处。

localhost は便利です。Tomcat が起動できない場合は、このファイルをよく読んでください。例えば：

NoClassDefFoundError

クラスが見つかりません例外

アクセスが一番無駄です。

catalina.{date} は主にコンソール出力であり、すべてのログがそこに含まれます。

ウェブアプリ

ここが Web アプリの場所です。実際、これらはすべて 1 つのプロジェクトです。

Web 展開を簡素化する方法。オンライン環境では、アプリケーションはここには配置されません。最善の方法は外部に出すことです。

lib : Tomcat は共有クラス ライブラリを保存します。例えば：

ecj-4.17.jar: eclipse Java コンパイラ

jasper.jar: JSP コンパイラ。

仕事

Tomcat の実行時に、コンパイルされた JSP ファイルなどのコンパイルされたファイルを保存します。

温度

運用中に生成される一時ファイルが保存されます。

Git の記事

内部情報もアリGit

SVN

1. Git は分散バージョン管理ツールです

1. SVN は集中バージョン管理ツールです

2. 第 3 世代のバージョン管理ツールに属します

2. 第 2 世代のバージョン管理ツールに属します。

3. クライアントは、ローカル システム上のリポジトリ全体のクローンを作成できます。

3. バージョン履歴はサーバー側のリポジトリに保存されます

4. オフラインでも提出可能

4. オンライン提出のみが許可されます

5. プッシュ/プル操作が高速化

5. 押し引き動作が遅い

6.コミットでプロジェクトを自動的に共有できる

6. 自動的に共有されるものはありません

1. GitとSVNの違いは何ですか?

2. Git とは何ですか?

以下の図に示すように、まず git の構造を理解してこの質問に答えることをお勧めします。この図を説明してみてください。

Git は分散バージョン管理システム (DVCS) です。ファイルの変更を追跡し、特定のバージョンに戻すことができます。

変化します。

その分散アーキテクチャには、SVN などの他のバージョン管理システム (VCS) に比べて多くの利点があります。大きな利点の 1 つは、

プロジェクト ファイルのすべてのバージョンを保存するには中央サーバーを利用します。

すべての開発者は、図で「ローカル リポジトリ」とマークしたリポジトリのコピーを「クローン」して、自分のハード ドライブ上に置くことができます。

プロジェクトの完全な履歴がディスク ドライブに保存されているため、サーバーがダウンした場合でも、必要な復旧データはすべてチームにあります。

友人のローカル Git リポジトリ内。

図に示すように、開発者が変更をコミットして他のチーム メンバーと共有できる中央のクラウド リポジトリもあります。

すべての共同作業者が「リモート リポジトリ」に変更をコミットしていることを示します。

3. Gitの commit コマンドとは何ですか?

Ali の内部データに対する答えは非常にシンプルです。コミットを書き込むコマンドはgit commit -aです。

-a フラグについて説明します。

コマンドラインに -a を追加することで、変更されたすべての追跡ファイルの新しい内容をコミットするように git に指示します。

また、初めて新しいファイルをコミットする必要がある場合は、 git commit -a の前にgit addを実行できます。

4. Gitの「ベア リポジトリ」とは何ですか?

「作業ディレクトリ」と「ベアリポジトリ」の違いを明確にする必要があります。

Git の「ベア」リポジトリには、バージョン管理情報のみが含まれ、作業ファイル (作業ツリーはありません) は含まれません。また、特別なものは含まれません。

.git サブディレクトリ。代わりに、.git サブディレクトリ内のすべてのものがホーム ディレクトリ自体に直接含まれ、作業ディレクトリには次のものが含まれます。

1. リポジトリに関連するすべての Git リビジョン履歴が含まれる .git サブディレクトリ。

2. 作業ツリー、またはチェックアウトされたプロジェクト ファイルのコピー。

5 Git は何語で書かれていますか?

言語の名前を言うだけでなく、なぜそれを使用するのかを説明する必要があります。次のように答えることをお勧めします。

GitはC言語で書かれています。GIT は高速であり、C 言語は実行時のオーバーヘッドを削減することでこれを実現します。

6. Gitでは、プッシュされて公開されたコミットをどのように元に戻しますか?

この質問には 2 つの答えが考えられますが、必ず両方を含めてください。

状況に応じて、以下のオプションを使用できます。 1 この質問には 2 つの答えがあります。

また、状況に応じて次のオプションが利用できるため、必ず両方の回答を回答に含めてください。

新しいコミット内の不良ファイルを削除または修正し、リモート リポジトリにプッシュします。これはバグを修正する最も自然な方法です。右

ファイルに必要な変更を加えた後、ファイルは使用するリモート リポジトリにコミットされます。

git commit -m "コミットメッセージ"

新しいコミットを作成し、不正なコミットで行われたすべての変更を元に戻します。次のコマンドを使用できます。

git revert <不正なコミットの名前>

7. git pullとgit fetchの違いは何ですか?

git pull コマンドは、特定のブランチの新しい変更またはコミットを中央リポジトリからプルし、ローカル リポジトリのターゲット ブランチを更新します。

git fetch も同じ目的に使用されますが、動作が少し異なります。git fetch を実行すると、必要なファイルがフェッチされます。

のブランチからすべての新しいコミットをプルし、ローカル リポジトリの新しいブランチに保存します。これらを対象ブランチに反映させたい場合

変更点としては、git fetch の後に git merge を実行する必要があります。ターゲットブランチとフェッチされたブランチのマージを行った後にのみ、

ターゲットブランチを更新します。便宜上、次の式を覚えておいてください。

阿里内部资料git pull = git fetch + git merge

8、git中的“staging area”或“index”是什么？

For this answer try to explain the below diagram as you can see: 可以通过下图进行解释：

在完成提交之前，可以在称为“staging area”或“index”的中间区域中对其进行格式化和审查。从图

中可以看出，每个更改首先在暂存区域中进行验证，我将其称为“stage fifile”，然后将更改提交到存

储库。

9、什么是 git stash?

首先应该解释 git stash 的必要性。

阿里内部资料通常情况下，当你一直在处理项目的某一部分时，如果你想要在某个时候切换分支去处理其他事

情，事情会处于混乱的状态。问题是，你不想把完成了一半的工作的提交，以便你以后就可以回到

当前的工作。解决这个问题的答案是 git stash。

再解释什么是git stash。

stash 会将你的工作目录，即修改后的跟踪文件和暂存的更改保存在一堆未完成的更改中，你可以

随时重新应用这些更改。

10、什么是git stash drop？

通过说明我们使用 git stash drop 的目的来回答这个问题。

git stash drop 命令用于删除隐藏的项目。默认情况下，它将删除最后添加的存储项，如果提供

参数的话，它还可以删除特定项。

下面举个例子。

如果要从隐藏项目列表中删除特定的存储项目，可以使用以下命令：

git stash list :次のような stash アイテムのリストが表示されます。

stash@{0}: マスター上の WIP: 049d078 インデックス fifile を追加しました stash@{1}: マスター上の WIP: c264051

「追加された fifile_size」stash@{2} を元に戻します: マスター上の WIP: 21d80a5 ログに番号を追加しました

stash@{0} という名前のプロジェクトを削除する場合は、コマンドgit stash Drop stash@{0}を使用します。

11.特定のコミットで変更されたファイルのリストを見つけるにはどうすればよいですか?

この問題では、コマンドを提供するだけでなく、そのコマンドが何を行うのかを説明することもできません。

特定のコミットで変更されたファイルのリストを取得するには、次のコマンドを使用します。

git diffff-tree -r {ハッシュ}

コミット ハッシュを指定すると、そのコミットで変更または追加されたすべてのファイルがリストされます。-r フラグを使用すると、コマンドは、個別のファイルをリストせずにリストします。

それらをルート ディレクトリ名のみに折りたたむことです。

オプションではありますが、面接官に好印象を与えるのに役立つ、以下の内容を含めることもできます。

出力には追加情報も含まれますが、これらは 2 つのフラグを含めることで簡単にマスクできます。

git diffff-tree –no-commit-id –name-only -r {ハッシュ}

ここで、-no-commit-id はコミット ハッシュが出力に表示されないようにし、-name-only はファイル名の代わりにファイル名のみを出力します。

のパス。

12. git configの機能は何ですか?

Ali の内部情報では、最初に git config が必要な理由が説明されています。

git はユーザー名を使用してコミットを ID に関連付けます。git config コマンドを使用して、git 構成を変更できます。

アカウント名。

例を挙げて説明しましょう。

ユーザー名と電子メール ID を提供して提出物を ID に関連付け、特定の提出物を誰が作成したかを知ることができるようにしたいとします。

支払い。このために私は以下を使用します:

git config --global user.name "Your Name":このコマンドはユーザー名を追加します。

git config --global user.email "あなたの電子メール アドレス":このコマンドは電子メール ID を追加します。

13.送信されたオブジェクトには何が含まれていますか?

Commit オブジェクトには次のコンポーネントが含まれています。これら 3 つについて言及する必要があります。

特定の時点でのプロジェクトの状態を表す一連のファイル

親コミットオブジェクトの参照

SHAI 名は 40 文字の文字列で、送信オブジェクトを一意に識別します。

14. Gitでリポジトリを作成するにはどうすればよいですか?

これはおそらく最もよく聞かれる質問ですが、答えは簡単です。

リポジトリを作成するには、まずプロジェクトのディレクトリを作成し (まだ存在しない場合)、次にコマンドgit initを実行します。これを実行することで

コマンドを実行すると、プロジェクトのディレクトリに .git ディレクトリが作成されます。

15. N個の提出物を 1 つの提出物に圧縮するにはどうすればよいですか?

N 個のコミットを 1 つのコミットに圧縮するには 2 つの方法があります。

新しいコミット メッセージを最初から作成する場合は、次のコマンドを使用します。

git restart –soft HEAD~N &&

gitコミット

既存のコミット メッセージを新しいコミット メッセージに連結したい場合は、これらのメッセージを抽出して git に渡す必要があります。

コミットすると、次のようにすることができます。

git restart –soft HEAD~N &&

git commit –edit -m"$(git log –format=%B –reverse .HEAD@{N})"

内部情報もアリ16. Git bisectとは何ですか？これを使用して (回帰) エラーを特定する方法

ソース？

最初に Git bisect の簡単な定義を与えることをお勧めします。

Git bisect は、バイナリ検索を使用してバグを引き起こすコミットを見つけるために使用されます。Git bisect のコマンドは次のとおりです。

git bisect <サブコマンド> <オプション>

上記のコマンドについて説明したので、このコマンドが何を行うかを説明しましょう。

このコマンドはバイナリ検索アルゴリズムを使用して、プロジェクト履歴内のどのコミットがバグを引き起こしたかを見つけます。あなたはそれが知られていると言うことができます

バグが含まれる「悪い」コミットと、バグが発生する前に知られていた「良い」コミットがそれを使用します。次に、これら 2 つを git bisect します

エンドポイント間のコミットを選択し、選択したコミットが「良い」か「悪い」かを尋ねます。導入された変更が見つかるまで絞り込み続けます

正確なコミット。

17.コミットする前に、テストが失敗したときにコードチェックツールを実行したい場合

コミットをブロックするようにGitリポジトリを構成するにはどうすればよいですか?

まず健全性チェックを導入することをお勧めします。

完全性テストまたはスモークテストは、継続的なテストが実行可能かつ合理的であるかどうかを判断するために使用されます。

これを実現する方法を以下で説明します。

これは、リポジトリのコミット前フックに関連する単純なスクリプトで実行できます。git は送信前に事前にトリガーします

コミットフック。このスクリプトでリンターなどの他のツールを実行したり、

サニティーチェック。

最後に、例として、次のスクリプトを参照できます。

#!/bin/sh

files=$(git diff –cached –name-only –diff-filter=ACM | grep '.go$')

if [ -z ファイル ]; それから

0番出口

フィ

unfmtd=$(gofmt -l $files)

if [ -z unfmtd ]; それから

0番出口

フィ

echo “Some .go files are not fmt’d”

exit 1

阿里内部资料这段脚本检查是否需要通过标准 Go 源代码格式化工具 gofmt 传递所有即将提交的 .go 文件。如果

脚步以非 0 状态退出，脚本会有效地阻止提交操作。

18.、描述一下你所使用的分支策略？

这个问题被要求用Git来测试你的分支经验，告诉他们你在以前的工作中如何使用分支以及它的用途

是什么，你可以参考以下提到的要点：

功能分支（Feature branching）

要素分支模型将特定要素的所有更改保留在分支内。当通过自动化测试对功能进行全面测试和

验证时，该分支将合并到主服务器中。

任务分支（Task branching）

在此模型中，每个任务都在其自己的分支上实现，任务键包含在分支名称中。很容易看出哪个

代码实现了哪个任务，只需在分支名称中查找任务键。

发布分支（Release branching）

一旦开发分支获得了足够的发布功能，你就可以克隆该分支来形成发布分支。创建该分支将会

启动下一个发布周期，所以在此之后不能再添加任何新功能，只有错误修复，文档生成和其他

面向发布的任务应该包含在此分支中。一旦准备好发布，该版本将合并到主服务器并标记版本

号。此外，它还应该再将自发布以来已经取得的进展合并回开发分支。

最后告诉他们分支策略因团队而异，所以我知道基本的分支操作，如删除、合并、检查分支等。

19、如果分支是否已合并为master，你可以通过什么手段知道？

答案很直接。

要知道某个分支是否已合并为master，你可以使用以下命令：

git branch –merged 它列出了已合并到当前分支的分支。

git branch –no-merged 它列出了尚未合并的分支。

20、 什么是SubGit？

SubGit は SVN を Git に移行するためのツールです。ローカルまたはリモートの Subversion リポジトリの書き込み可能な Git ミラーを作成します

好きなだけ、Subversion と Git を自由に使用してください。

これには多くの利点があります。たとえば、Subversion から Git または Atlassian Bitbucket に簡単にワンショットでインポートできます。

サーバーにはSubGitを使用しています。SubGit を使用して、既存の Subversion リポジトリの双方向 Git-SVN ミラーを作成できます。あなた

都合の良いときに Git にプッシュしたり、Subversion にコミットしたりできます。同期はSubGitによって行われます。

21.仕事で一般的に使用されるgitコマンドをいくつか挙げてください。

Ali の内部情報に新しいファイルを追加するコマンド: git add fifile または git add ファイルを送信するコマンド: git commit –m または git commit –a check

ワークスペースのステータスを確認します: git status –s でリモート ブランチをプルおよびマージします: git fetch/git merge または git pull で送信を表示します

ログコマンド: git reflflog

22.この提出の間違った操作を元に戻すにはどうすればよいですか?

インデックス領域に送信されたファイルをキャンセルしたい場合は、 git replace HEAD fifileを使用できます; ローカルウェアハウスに送信されたファイルをキャンセルしたい場合は、

ファイルを使用すると、現在のブランチのバージョン ライブラリを、 git restart –soft HEAD^nを介して、最後の送信、インデックス領域、および作業の状態に復元できます。

スペースは変更されません。git replace –mixed HEAD^n を使用して、現在のブランチのバージョン ライブラリとインデックス領域を最後に送信されたものに復元できます。

23. git stashコマンドを使用したことがありますか? 普段いつ使いますか？

コマンド git stash は、ワークスペースの変更内容をスタック領域に保存します。次のような状況で使用されます。

競合するファイルを解決する場合、最初に git stash が実行され、次に競合が解決されます。

緊急の開発タスクが発生したが、現在のタスクを送信できない場合、最初に git stash が実行され、次に緊急タスクの開発が実行され、その後、

その後、 git stash Pop を使用してスタック領域の内容を取り出し、開発を続行します。

ブランチを切り替えるときに、現在のワークスペースのコンテンツを送信できない場合は、最初に git stash が実行され、次にブランチ切り替えが実行されます。

24.ブランチ提出の履歴を表示するにはどうすればよいですか? ファイルの履歴を表示する

毛織物？

ブランチのコミット履歴を表示します。

コマンド git log –number: 現在のブランチの最初の番号の詳細な送信履歴を表示することを示します。

コマンド git log –number –pretty=oneline: 前のコマンドに基づいて単純化し、sha-1 コードのみを表示してコミットします。

情報;

コマンド git reflflog –number: すべてのブランチの最初の番号の簡略化された送信履歴を表示することを示します。

コマンド git reflflog –number –pretty=oneline: 簡略化された情報履歴情報を表示します。

ファイルの送信履歴を表示したい場合は、上記のコマンドの後にファイル名を追加するだけです。

注: 番号がない場合は、すべての提出時間が表示されます。

25. git mergeとgit rebaseを使用したことがありますか? それらの違いは何ですか?

簡単に言うと、 git merge と git rebase はどちらもブランチをマージするためのコマンドです。git merge ブランチはブランチの差分を取得します

コンテンツはローカルにプルされ、ローカル ブランチのコンテンツとともにコミッター オブジェクトが形成され、メイン ブランチに送信されます。

ブランチはメイン ブランチと一貫性があります。git rebase ブランチは、最初にブランチ ブランチをメイン ブランチにマージし、次にローカル ブランチをマージします。

コミットはメイン ブランチの後ろに配置されます。マージされたブランチは、マージされたメイン ブランチから別のブランチをプルするようなものです。ローカル ブランチ自体

コミット履歴は保存されません。

26. git Cherry-pickを使用しましたが、その効果は何ですか?

コマンド git Cherry-pick はブランチ A のコミットをブランチ B にコピーできます。ブランチ B でコマンド操作を実行します。

Ali 内部データは単一のコミットをコピーします: git Cherry-pick commitId

複数のコミットをコピーするには: git Cherry-pick commitId1...commitId3

注: 複数のコミットをコピーするコマンドには commitId1 は含まれません。

優しい力

この記事では、Markdown を使用してプログラマー固有の履歴書を作成する方法を説明するだけでなく、後でいくつかの優れた履歴書をお勧めします。

Markdown 履歴書を作成するために使用されるソフトウェアまたは Web サイト、および Markdown 形式を PDF 形式などにエレガントに変換する方法

他の形式。

Markdown 構文を使用して履歴書を作成し、履歴書を送信する前に Markdown 形式を PDF 形式に変換することをお勧めします。

Markdown 文法についてあまり詳しくない場合は、30 分かけて Markdown 文法の説明を簡単に確認してください。

http://www.markdown.cn 。

1.履歴書はなぜ重要ですか?

優れた履歴書は、応募面接と面接プロセス全体で非常に良い役割を果たします。自分の能力を誇張することなく

次に、良い履歴書を書くことも素晴らしい能力です。なぜ履歴書が重要なのでしょうか?

2.インタビューから始めましょう

オンライン応募の場合、必然的に人事部による履歴書の審査が行われるため、人事部が履歴書を審査するまでに10秒ほどかかる場合があり、その後人事部が履歴書を審査します。

これにより、レベルが不合格か合格かが決まります。

社内紹介の場合、履歴書にメリットがなければ、紹介してくれた人がいくら頑張っていてもどうしようもありません。

また、たとえ選考を通過したとしても、その後の面接では面接官も履歴書を見て、あなたが費用をかける価値があるかどうかを判断します。

面接の時間がたくさんあります。

したがって、あなたの履歴書は私たちのファサードのようなもので、これによって次の面接に参加できるかどうかが大きく決まります。

3.インタビューから始めましょう

人々が対面で聖典を読むことを好むことが分かりました。それは当然ですが、対面で読む聖典のほとんどは、多くの問題が特定の状況にあることを示していません。

聞いただけ。簡単な例を挙げると、一般的に、履歴書に質問されると記載されている場合にのみ質問されます (Java、データ構造など)。

構造、ネットワーク、アルゴリズムは誰もが尋ねなければならない基本です)、たとえば、redis を知っていると書いた場合、面接官はおそらく redis について質問するでしょう。

いくつかの問題。例: Redis の一般的なデータ型とアプリケーション シナリオ、Redis がシングルスレッドである理由、Redis と

memcached、redisのメモリ削除機構などの違い。

したがって、まず最初に明確にしておきたいのは、知らないことを履歴書に書かないことです。さらに、どうすればできるかを考慮する必要があります。

履歴書の中でハイライトを目立たせるようにしましょう。たとえば、特定のプロジェクトでどのような問題に取り組み、どのような問題が解決されましたか (プロジェクトが存在する限り)。

解決すべき問題があるはずです)、プロジェクトの 1 つでどのようなテクノロジが使用されているか、全体的なパフォーマンスと同時実行性が大幅に向上したかなどです。

アリの社内情報面接と仕事は別物で、頭の良い人は面接官を自分の得意分野に誘導しますが、そうでない人は面接官に鼻で誘導されてしまいます。

面接と就職は別ですが、納得のいく内定を獲得したいなら、自分自身の力が強くなければなりません。

4.知っておくべきいくつかのこと

会社の人事のほとんどは、学歴は重視しないと言っていますが（嘘です！）、学校がよほど優れていなければ、単純な人材で競争するのは難しいです。

履歴書に特別なハイライトがない限り、履歴書で目立つようにします。たとえば、特定の大きな工場でのインターンシップの経験、特定のコンテストで賞を受賞したことなどです。

等

新卒は就職活動の際に就業経験やインターンシップの経験がない人がほとんどなので、新卒の場合は秋採用や春採用を見逃さないようにしましょう。

騙す。これを逃すと、後々ソーシャルリクルーティングに直面する可能性が高く、この時、職歴なしでもさまざまな出会いに直面する可能性があります。

壁にぶつかってしまい、良い仕事が見つからない

履歴書に何を書くか注意してください。面接官はここで多くの質問をします。

プロジェクトの経験を完璧に表現することが非常に重要です。

5、必须了解的两大法则

STAR法则（Situation Task Action Result）

Situation：

事情是在什么情况下发生；

Task:：

你是如何明确你的任务的；

Action：

针对这样的情况分析，你采用了什么行动方式；

Result：

结果怎样，在这样的情况下你学习到了什么。

简而言之，STAR法则，就是一种讲述自己故事的方式，或者说，是一个清晰、条理的作文模板。不

管是什么，合理熟练运用此法则，可以轻松的对面试官描述事物的逻辑方式，表现出自己分析阐述

问题的清晰性、条理性和逻辑性。

FAB 法则（Feature Advantage Benefifit）

Feature：

是什么；

Advantage：

比别人好在哪些地方；

Benefifit：

如果雇佣你，招聘方会得到什么好处。

简单来说，这个法则主要是让你的面试官知道你的优势、招了你之后对公司有什么帮助。

6、项目经历怎么写

简历上有一两个项目经历很正常，但是真正能把项目经历很好的展示给面试官的非常少。对于项目

经历大家可以考虑从如下几点来写：

1. 对项目整体设计的一个感受

2. 在这个项目中你负责了什么、做了什么、担任了什么角色

3. 从这个项目中你学会了那些东西，使用到了那些技术，学会了那些新技术的使用

内部情報もアリ 4. さらに、プロジェクトの説明では、プロジェクト チームのメンバーをどのように調整して共同開発するか、またはプロジェクトの全体的な品質を反映するのが最善です。

あるいは、難しい問題に遭遇したときにどのように解決しましたか、あるいはそれを達成するためにこのプロジェクトでどのようなテクノロジーを使用しましたか?

どのような機能があるのか​​: Redis をキャッシュとして使用してアクセス速度と同時実行性を向上させる、メッセージ キューを使用してピークをカットしトラフィックを削減するなど。

7.専門スキルの書き方

まず自分が何を知っているかを自問し、次に、志望する企業が何を必要としているかを考えてください。一般の人事担当者はテクノロジーについてあまり詳しくない可能性があるため、選考を行っています

履歴書を選ぶときは、自分の専門スキルのキーワードに注目するかもしれません。会社が必要としているが分からないスキルに対して、いくらくらい投資できますか?

数日かけて習得すれば、このスキルを理解していることを履歴書に書くことができます。たとえば、次のように書くことができます（以下の部分は抜粋です）

私の履歴書、あなた自身の状況に応じていくつかの修正や改善を加えることができます):

コンピュータネットワーク、データ構造、アルゴリズム、オペレーティングシステムなどの授業中の基礎知識：マスター

Java の基礎: マスタリング

JVM仮想マシン（Javaメモリ領域、仮想マシンガベージアルゴリズム、仮想ガベージコレクタ、JVMメモリ管理）：マスター

高同時実行性、高可用性、高性能システム開発: マスター

Struts2、Spring、Hibernate、Ajax、Mybatis、JQuery ：掌握

SSH 統合、SSM 統合、SOA アーキテクチャ: マスタリング

ダボ：

マスター

動物園の飼育員: マスタリング

共通メッセージキュー: マスタリング

Linux: マスタリング

MySQL の一般的な最適化メソッド: マスター

Spring Boot +Spring Cloud +Docker:了解

Hadoop の HDFS、Storm、MapReduce、Hive、Hbase のエコロジー関連テクノロジ: 理解する

Python の基本、OpenCV、wxpy、wordcloud、matplotlib などのいくつかの一般的なサードパーティ ライブラリ: に精通している

8.組版上の注意事項

1. 派手すぎず、簡潔にするよう努めてください。

2. 一部の専門用語の大文字と小文字を間違えないでください (たとえば、MySQL を mysql と書いたり、Java を java と書いたりすることはできません)。私はこれを見る

ここに来ることはかなりタブーなので、この詳細に注意を払う必要があります。

3. 中国語とデジタル英語の間にスペースがあると、より快適に見えます。

9、其他一些小tips

1. 尽量避免主观表述，少一点语义模糊的形容词，尽量要简洁明了，逻辑结构清晰。

2. 如果自己有博客或者个人技术栈点的话，写上去会为你加分很多。

3. 如果自己的Github比较活跃的话，写上去也会为你加分很多。

4. 注意简历真实性，一定不要写自己不会的东西，或者带有欺骗性的内容

5. 项目经历建议以时间倒序排序，另外项目经历不在于多，而在于有亮点。

6. 如果内容过多的话，不需要非把内容压缩到一页，保持排版干净整洁就可以了。

阿里内部资料7. 简历最后最好能加上：

“感谢您花时间阅读我的简历，期待能有机会和您共事。”这句话，显的

你会很有礼貌。

10、你对我们公司有什么想问的吗？

背景

面试，是双方互相试探的一个过程。因此，不止求职者想了解面试官对咱的感观，面试官同样也想

听一下你对企业的看法。所以，在结束前，经常会被问到这样一个问题：

“你对公司有啥想法？

”

说实话，小编以前面试的时候，很怕被问到“对公司有什么想法？”/“你还有什么要问的？”/“你的职业

规划是什么？

”之类的问题。太假大空了，真心没意思。可没办法，面试官问了，咱总不能不答，于

是只能硬着头皮“胡邹乱噪”。顺利的时候还好，不顺的时候，经常被挑刺，从而失去即将到手的机

会。慢慢的，越来越认识到此类面试题的重要性，于是，总结出了一套应对方法，拿出来给大家分

享。那啥，仅供参考。

常规回答：谈公司的历史，产品

想必，绝大多数的求职者，在面试前会做准备功课。而对公司历史、产品的了解，则是必须掌握的

一项内容。如果你真的不知道该如何回答“你对公司有什么想法”这样的问题的话，不妨先说一说你

了解的公司概况，让面试官知道，你是有备而来，而不是来打酱油的。

进一步回答：说公司概况+个人规划

趋利避害，是每个人共同的特性。在面对不能很好掌控的面试题时，最好的办法，是换个角度，将

その答えはあなたの専門分野につながります。上記の質問をされた場合は、まず会社について知っていることを説明してから、次のように結論付けます。

いくつかの内容を組み合わせて、着任後の計画や実行できる仕事について話します。例えば、その仕事がどこまでできるか、会社が

そんなものどんな形で返すの、とにかくもっと本当の思いと今の実績を話して、平常心で頑張ってね。

授業前に宿題をするようにしてください。他の人に良い印象を与えることは間違いありません

参考回答

御社は私の印象としては理想的な会社であり、私にポジションを提供していただいたので、その社風に非常に興味を持っていると言えます。

会社の成り立ちや経営状況を比較的客観的に理解しています。スタッフの給与や収入も安定しています。会社の経営規範は非常に良好です

物流サービスなどは注目すべき点です。私が最も感動したのは、会社のあらゆるレベルのマネージャーがとても熱心で、それが私に感じられることです。

まるで家のようだ。そんな会社で働くのは誰もが憧れることだと思います！

11.自己紹介に夢中になる人が多い

事例１：自己紹介のタイミングをどう把握するか？

大学院を卒業したシャオ・リウさんはとても話し上手で、自己紹介は簡単だと思っているので、まったく準備をしません。

人々の意見を見てみましょう。就職活動の目標は不動産企画で、一度は地元の大手不動産会社に応募した。

自己紹介では不動産業界の動向についてたくさん話していましたが、本題からあまりにもかけ離れていたため、面接官が話を引っ込めざるを得ませんでした。自己紹介のみ

「途中で止める」ことも可能。

Ali の内部情報に関する提案: 1 分間で 1 つのコンテンツについて話す

自己紹介の時間は3分が一般的ですが、時間配分としては、最初の1分で学歴などの基本的な個人的状況を話し、2分目で基本的な個人的状況を話すことができます。

1分で自分の職歴、3分で新卒に関連する社会慣行、そしてこのポジションに対する理想や理想を語ることができます。

業界に対する見解。自己紹介を 1 分以内に完了する必要がある場合、自己紹介は焦点を絞って目立つようにする必要があります。

残り。

実際には、自己紹介の重要性を理解せず、単に自分の名前や身元などを紹介する応募者もいます。

最後に、学歴や職歴などの情報を追加しました。自己紹介は30分ほどで終わり、試験に臨みました。

警察官、以下の質問を待つのは全く不適切であり、面接官に自分を推薦する貴重な機会を無駄にします。一方他の人は

また、候補者が自分の経験すべてをこの数分間に詰め込もうとするのも賢明ではありません。自己紹介を合理的に整理する

適切な時期が来たら、最初に考慮すべきことは重要なポイントを強調することです。

事例２：自己紹介の準備はどうすればいいですか？

小芳さんは南部メディアの仕事に応募しに行ったが、面接は大きなオフィスで行われ、5人が少人数のグループになり、テーマについて自由に議論した。麺類

試験官は各申請者に最初に自己紹介をするよう指示し、小芳さんは 2 番目で、各文を紹介する前の申請者とは異なり、彼女が先に自己紹介を行っていました。

準備として、大学4年間でやってきたことを文章にして、少し韻を踏むように韻を意識して修正を加えました。（仕事

Field Entrepreneurship www.lz13.cn) Xiaofang の紹介は非常に流暢ですが、難点は、人々に暗誦しているような感覚を与えることです。

提案: 「朗読」の口調を採用しないでください

人事専門家は、自己紹介は事前に準備したり、事前に練習する友達を見つけたりすることは可能だが、自己紹介は避けるべきだと指摘した。

書き言葉の厳格さと抑制を利用して、柔軟な口頭言語を組織化する必要があります。次の場合は、朗読するような口調で自己紹介をしないでください。

そうなると面接官にとっては耐えられないでしょう。自己紹介をするときは、声に注意して、滑らかで自然な声のトーンになるようにしてください。

自信に満ちています。

事例 3: 自己紹介の際に業績についてどのように語ればよいでしょうか?

シャオ・ワンさんは、テレビ番組制作会社のコピーライティングの仕事に応募しようとしましたが、面接の際、相手はまず、関連する実務経験について話してほしいと彼に求めました。小さい

ワンさんの専攻はジャーナリズムとコミュニケーションですが、紙媒体を好み、テレビ番組制作の経験はほとんどありません。何をすべきか？

Xiao Wang は、彼が普段参加しているキャンパスのアクティビティについて話す以外に選択肢はありませんでした。非常に内容が濃いように聞こえますが、テレビとはほとんど関係がありません。

提案: そのポジションに関連する利点のみについて言及する

自己紹介をするときは、自分の実績を選択する必要があり、これらの実績は、現在応募している会社のビジネスの性質に関連している必要があります。インタビュー中、あなたは、

あなたがどれだけ優れているかを試験官に伝えるだけでなく、あなたがこの仕事にどれほど適しているかを試験官に伝えてください。面接と関係のないもの

たとえそれがあなたが誇る長所や強みだったとしても、不本意ながら諦めなければなりません。

結果を紹介するときは話す順番も非常に重要で、面接官に一番知ってもらいたいことを最初に入れると良いでしょう。

恋愛はあなたの最も誇りに思える仕事であることが多く、面接官に好印象を与えることもあります。

ケース 4: 自己紹介の際のヒントを学ぶ

アリ内部情報 阿峰さんは昨年、大きな国有企業のキャンパス就職説明会に参加し、その日は大きなスタジアムで開催され、チームは出口に整列した。

オフィス内で応募者と面接官が話せる時間はわずか数分ですが、どうすればその短い時間で面接官の好意を得ることができるのか、

次のラウンドに行ってみてはどうでしょうか？アフェンさんは通常の紹介をやめ、自分が完了したプロジェクトを面接官に紹介することに集中した。

裏付けとしての講師の評価。ちょっとしたスキルのおかげで、アフェンはこの種の「オーディション」面接に無事合格しました。

提案: 真実を話すことを前提とします

自己紹介では、自分の長所や得意分野をアピールする必要があり、これまでにやってきたことを紹介するなど、ちょっとしたテクニックを使うこともできます。

自分に特定の能力があることを確認するためのプロジェクト。また、自分の説明を裏付けるために、教師や友人などの他の人の発言を適切に引用することもできます。

述べました。ただし、どのようなトリックを使用する場合でも、事実に基づいて話すことを主張し、機能語や間投詞などをあまり使用しません。自分のことを自慢するのは通常難しいです

インタビュアーの目を逃れる。弱みについて話すときは、落ち着いて楽観的で自信を持って話す必要があります。

ケース 5: 自己紹介での舞台恐怖症を取り除くにはどうすればよいですか?

アホンさんは都心の大学を卒業し、憧れを抱いて広東省へ南下した。私は短大生なので、研究に熱心に取り組んできました。

タレント市場では、アホンは少し自信が欠けており、面接官に直面すると舞台恐怖症を示すことが多く、非常に緊張して自由に話すことができないこともあります

もちろん。また、この状況が面接に適していないことも理解していますが、自分を律する方法が見つかりません。

提案:会話で「3P原則」を使用する

人事の専門家は、自己紹介をするときは、自信（ポジティブ）、性格、という「3P原則」を忘れないようにする必要があると指摘しました。

（個人的な）、適切な（適切な）。答えは穏やかで、自分の個性を際立たせ、プロ意識と能力を強調し、適切な口調で話す必要があります。

誇張しないでください。

自己紹介をするときは、感情を調整し、基本的な状況を紹介するときは無表情で堅苦しくなければなりません。

欠点について話すときに高揚して興奮し、欠点について話すときに無気力でだるくなるのは未熟です。テーブル用

ダー、私はアホンに、面接に行く前に友達と一緒に練習するか、鏡の前で数回練習することを提案します。

13 、人事との話し方、給与についての話し方

給与の話をする前に、まず市場を理解する必要があり、自分を知り、敵を知って初めてすべての戦いに勝つことができるので、面接前に何をすべきかを誰もが明確に理解する必要があります。

この業界の給与水準はどのくらいですか？大手求人サイトにアクセスして、応募している職種の仕事内容を確認することができます。

給与水準はどうなっているのか。採用ウェブサイトで応募しているポジションの給与水準を知ることに加えて、いくつかの質問も必要です。

この分野で働いている友人やクラスメートに聞いてください。給与レベルを明確に理解すれば、給与交渉の際に特に無知であるとは思われなくなります

怒り。

自信を持って、給与について人事部と話すことを恐れないでください。給与交渉のこの段階は、採用面接プロセスにおいて避けられないものです。私たちは自信を持たなければなりません。

臆病な行動をしないでください。あなたが十分にプロフェッショナルであり、悪いパフォーマンスがない限り、面接官は気にしないことを覚えておいてください。

この質問ではオファーは得られません。したがって、給与交渉をするときは大胆になり、相手にあなたの自信を見てもらいましょう。結局本当に人事がなくなったとしても

採用されても構わない、大事なことならまた探せばいい！給与について話すのは全員の交渉スキルと精神性が試されるので、パニックにならないでください。

自分自身の利益を追求できるようになります！

Ali の内部情報と給与について話し合うときは、自分のホール カードを時期尚早に公開しないでください。給与交渉のプロセス中、全員のホール カードをあまりにも早く公開してはいけません。

主導権を失った。消極的であれば、高給交渉のチャンスを失う可能性があります。したがって、面接の際は、無理をしないでください。

早めに人事部に行き、給与の問題について話し合ってください。最初から給与要件について尋ねられたとしても、機転を利かせて話題を変える必要があります。ではない

企業があなたに興味を持っており、入社してほしいと確信しているときに、カードを公開しすぎるのは非常に不利です。

会社の給与制度を理解してから評価する.人事担当者から給与要件について尋ねられたときは、慌てて自分の心理的価格を提示しないでください。

まずは会社の給与体系がどのようなものかを聞いてから、自分の実情に合わせて給与の話をしましょう。まずrootが必要です

会社の給与水準やその他の福利厚生に応じて心理的価格を再評価し、最終的に適切な給与範囲を提示します。与える

誰もが給与の範囲内で最低ラインを維持する必要があり、簡単に譲歩しないでください。

14.人事担当者がプログラマーに最も聞きたがる20 の質問

人事担当者がよく尋ねる 20 の質問を以下に整理します。その答えは、全員が考え方を分散できるようにするためのものです。

クリックするだけで、面接中に不意を突かれることはありません。質問がある場合は、読者サークルで質問することもできます。

答え。

1. 自己紹介をお願いします。

2. 残業についてどう思いますか?

3. 給与要件は何ですか?

4. あなたのキャリアプランは何ですか?

5. 他にご質問はありますか?

6. 私たちの部隊がこの面接を通じてあなたを採用したものの、一定期間働いた後にあなたがこのポジションにふさわしくないことが判明した場合、どうしますか?

管理？

7. ある仕事を完了するとき、リーダーが要求する方法が最善ではないと思いますが、もっと良い方法がある場合、どうすればよいですか?

する？

8. 仕事でミスをして会社に経済的損失を与えた場合、どうすべきだと思いますか?

9. 転職についてのあなたの考えを教えてください。

10. 職場の同僚や上司とうまくやっていくのが難しいのですが、どうすればいいですか?

11. なぜ辞めたいのですか?

12. 仕事に対する期待と目標は何ですか?

13. あなたが応募したポジションに関して、まだ何が足りないと思いますか?

14. 誰かと口論したことがありますか? どうやって解決しましたか？

15. 私があなたを雇ったら、どのように仕事を遂行しますか?

16. この面接で採用されなかったらどうしますか?

17. オフィス勤務の新しい環境に適応する方法について話しますか?

18. 仕事で何を学びましたか?

19. 当社以外に応募した企業はどこですか?

20. いつから仕事を始められますか?

これらの質問は面接前に行われます。特に比較的小規模な企業の場合、人事担当者がよく話すため、これらの質問をすべて質問することをお勧めします。

面接で遭遇した場合にどう対処するか、ざっくり考えてみましょう。

アリの内部情報15.面接時のマナーとマナー

細部への注意

緊張を落ち着かせて、落ち着いて面接会場に入り、ドアを軽くノックし、許可を得て入室し、ドアを開け閉めしてください。

優しく優しく、面接官に笑顔で率先して挨拶し、住所も適当 今は先生に電話するのが一般的です、そうすれば全員に電話できます

こんにちは先生。急いで座らないでください。面接官は「座ってください」と言ったら感謝します。座ったら、体をまっすぐにして、周りを見ないでください。

相手の怒りを買わないように、慎重かつさりげなく行動しましょう。面接中は笑顔で注意深く話を聞き、面接の終わりには笑顔で立ち上がってこう言います。

ありがとう、そしてさようなら。会話スキル

相手の質問や紹介を注意深く聞き、適切にうなずいたり、質問したりし、明確な言葉、適度な音量、簡潔な言葉で質問に答えます。

実践、明確な意味。面接官の質問を遮ったり、特定の問題について面接官と議論したりしないでください。

意見の相違があれば

沈黙を守り、相手と焦って議論しないように注意してください。これは時間と感情の無駄です。分からない質問については

質問には正直に答えてください。ナンセンスなことは言わないでください。答えたくない質問について面接官に詳しく尋ねるときは、焦らないでください。

自分自身の態度を保ちましょう。いいマナー

言語がその人の内面の自己修養を反映するだけでなく、マナー、謙虚さ、礼儀正しさもあなたの資質と自己修養を反映する可能性があります。場所

したがって、面接では、品のある立ち振る舞い、謙虚で慎重な話し方、前向きで熱心な姿勢が適切です。質問に答えるときは、次のことを確認してください

相手の目は敬意を示しています。目はしっかりしていて自信に満ちていて、不安定ではありません。そうでないと、自信がないか、軽薄に見えてしまい、双方の意見が異なります。

感情的に一致団結して他の人と議論しないでください。しかし、謙虚でもなく、横柄でもなく、気楽に過ごしてください。特殊なポジションであれば除外しません

気分が良くない場合は、この方法を試さないでください。失敗する可能性があります。些細なトリックを避ける

この記事は前の記事と分割すべきですが、多くの人の潜在意識の行動を考慮して、特別に言及します。小さいものを持っている人が多い

動きの癖には、意識的なものもあれば、無意識的なものもありますが、心が緊張していると、小さな動きが多くなります。小さなジェスチャーが多すぎて表示できません

緊張していて自分に自信が持てず、気が散ってしまい、悪い印象を与えてしまいます。頭をかく、手をこする、鼻をほじる、踏みつけるなど

足など