1.まず、あなたが知っているいくつかの言語、主にバックエンドを紹介します
2.クロスドメインを理解していますか？
ドメイン：WebサイトのURL構成には、プロトコル名、サブドメイン名、メインドメイン名、およびポート番号が含まれます。たとえば、https：//www.github.com/80です。ここで、httpsはプロトコル名、www.github.comはサブドメイン名、github.comはメインドメイン名、ポート番号は80です。ページ上のURLからデータを要求する場合、プロトコル名、サブドメイン名、およびメインの場合ドメイン名とポート番号のいずれかが異なると、クロスドメインの問題が発生します。http：// localhost：80 / ページでhttp://127.0.0.1:80/をリクエストして も、 クロスドメインの問題が発生します（ドメイン名が異なるため）。ここでのすべてのドメインは、protocol \ domain name \ port numberのコレクションを指し、同じドメインは、プロトコルドメイン名とポート番号が同じであることを意味します
クロスドメインの問題は、ブラウザが同じオリジンポリシーによって制限されていることです。現在のドメイン名のjsは、同じドメインのウィンドウプロパティのみを読み取ることができます。
同じオリジン戦略：フロントエンド開発プロセスでは、
<a/>,<form/>,<img/>,<script/>,<iframe/>やajax操作などの一般的なHTMLタグがリソースアドレスを指すか、リソースのリクエストを開始できます。ここで説明するリクエストには、同じドメインのリクエストとクロスドメインのリクエストが含まれます。同じ起源の戦略は、違法な攻撃から防御するために使用されるブラウザのコア基本セキュリティ戦略ですが、違法な攻撃から防御したいという理由だけで、すべてのクロスドメインの問題をブロックすることはできません。クロスドメインリクエスト：リクエストドメインが、リクエストされたリソースが指すドメインと矛盾している場合
- フロントエンド開発では、サードパーティのサービスインターフェイス（モックサーバー、偽のAPIなど）がよく使用されます。専門的な分業の出現により、フロントエンド開発者にさまざまなインターフェイスを提供する多くの専門的な情報サービスプロバイダーがあります。この場合、クロスドメインリクエストが必要です（それらのほとんどはcrosによって解決されます）
- フロントエンドとバックエンドは異なるサービスに属しています。フロントエンドとバックエンドの分離アーキテクチャを採用すると、クロスドメインの問題が発生します（それらのほとんどはリバースプロキシ方式で解決されます）
解決：
- 最も単純で最も一般的な方法：jsonpを使用します。つまり、名前が示すように、JSONをボックスに入力するパディング付きのjsonを使用します。
- 一度限り：サーバー側でクロスオリジンリソースアクセスCORS（クロスオリジンリソース共有）を直接設定し、リクエストヘッダーヘッダーでAccess-Control-Allow-Originを設定して、データを取得できるドメイン名を指定します
- シンプルで効果的：画像を直接リクエストする
- 「お父さん」を見つける：document.domainを変更してサブドメインをクロスする
- グッドブラザーズ：window.nameを介してドメイン間でデータを受信します
- 新石器時代：HTML5のwindow.postMessageメソッドを使用したクロスドメイン
3.httpキャッシングメカニズムについて教えてください。
Webキャッシュ：データベースキャッシュ、サーバー側キャッシュ（プロキシサーバーキャッシュ、CDNキャッシュ）、ブラウザーキャッシュに大別できます。ブラウザのキャッシュには、HTTPキャッシュ、indexDB、Cookie、localstorageなどの多くのコンテンツが含まれています。
HTTPメッセージ：ブラウザーとサーバーが通信するときに送信および応答されるデータブロック。
ブラウザはサーバーにデータを要求し、要求（要求）メッセージを送信します。サーバーはデータをブラウザに返し、応答（応答）メッセージを返します。
メッセージ情報は主に2つの部分に分かれています
- 属性を含むヘッダー————————–追加情報（Cookie、キャッシュ情報など）およびキャッシュ関連のルール情報はすべてヘッダーに含まれています
- データの本文が含まれています———————実際に送信したいHTTP要求の部分
応答ヘッダーのプロパティ：
- Etag（Last-Modified / If-Modified-Sinceよりも高い優先度）：サーバーが要求に応答すると、サーバー上の現在のリソースの一意の識別子をブラウザーに通知します（生成ルールはサーバーによって決定されます）。
- 最終変更：サーバーが要求に応答すると、リソースの最終変更時刻がブラウザーに通知されます。
- If-Modified-Since：サーバーを再度要求する場合、このフィールドを使用して、最後の要求中にサーバーから返されたリソースの最終変更時刻をサーバーに通知します。要求を受信した後、サーバーはヘッダーIf-Modified-Sinceを見つけ、それを要求されたリソースの最終変更時刻と比較します。リソースの最終変更時間がIf-Modified-Sinceより大きい場合、リソースが変更されたことを示し、リソースコンテンツ全体に応答し、ステータスコード200を返します。リソースの最終変更時間がIf-Modified-Since以下の場合、リソースには新しい変更はHTTP304に応答し、保存されたキャッシュを引き続き使用するようにブラウザに指示します。
- If-None-Match：サーバーを再度要求する場合、このフィールドを使用して、クライアントセグメントによってキャッシュされたデータの一意の識別子をサーバーに通知します。サーバーがリクエストを受信した後、ヘッダーIf-None-Matchが見つかると、リクエストされたリソースの一意の識別子と比較されます。異なる場合は、リソースが変更されたことを示し、リソースコンテンツ全体に応答し、ステータスコード200を返します。同じ、リソースを示します。新しい変更がない場合は、HTTP 304で応答して、保存されたキャッシュの使用を続行するようにブラウザーに通知します。
- 有効期限：HTTP 1.0です。現在、デフォルトのブラウザはデフォルトでHTTP 1.1を使用しているため、その機能は基本的に無視されます。
- Cache-Control：Expiresと一致し、現在のリソースの有効期間を示し、ブラウザーがブラウザーのキャッシュからデータを直接フェッチするか、サーバーにデータをフェッチする要求を再送信するかを制御します。Cache-Controlには、より多くの選択肢とより詳細な設定があるというだけです。同時に設定すると、その優先度はExpiresよりも高くなります。6つの値があります。
キャッシュ制御 最も重要なルールです。一般的な値はprivate、public、no-cache、max-age、no-storeであり、デフォルトはprivateです。 民間 クライアントはキャッシュできます 公衆 クライアントとプロキシサーバーの両方をキャッシュできます（フロントエンドの学生は、パブリックとプライベートが同じであると考えることができます） max-age = xxx キャッシュされたコンテンツはxxx秒で期限切れになります キャッシュなし キャッシュされたデータを検証するためにコントラストキャッシュを使用する必要があります（後述） ノーストア： すべてのコンテンツがキャッシュされず、強制キャッシュされ、コントラストキャッシュがトリガーされません（フロントエンド開発の場合、キャッシュが多いほど良いので、基本的に886と言います）
必須キャッシング：サーバーはブラウザーにキャッシング時間を通知します。キャッシング時間中、次のリクエストはキャッシュを直接使用し、時間切れの場合は比較キャッシング戦略が実行されます。 キャッシュの比較：キャッシュ情報のEtagとLast-Modifiedをリクエストでサーバーに送信すると、サーバーがそれを確認します。304ステータスコードが返されると、ブラウザーはキャッシュを直接使用します。
4.いくつかのIOモデルを導入しますか？
ブロッキングIO、非ブロッキングIO、多重化IO、信号駆動型IO、および非同期IO。
- IOのブロック：最も伝統的なIOモデル、つまり、データの読み取りと書き込みのプロセスでブロックが発生します。ユーザースレッドがIO要求を発行すると、オペレーティングシステムカーネルはデータの準備ができているかどうかを確認し、準備ができていない場合はデータの準備ができるのを待ち、ユーザースレッドはブロック状態になり、ユーザースレッドはCPUを引き渡します。データの準備ができると、カーネルはデータをユーザースレッドにコピーし、結果をユーザースレッドに返し、ユーザースレッドはブロック状態を解放します。
- ノンブロッキングIO：ユーザースレッドが読み取り操作を開始すると、待機する必要はありませんが、すぐに結果を取得します。結果がエラーの場合、データの準備ができていないことがわかっているため、読み取り操作を再度送信できます。カーネル内のデータの準備が整い、ユーザースレッドからの要求を再度受信すると、すぐにデータをユーザースレッドにコピーして、戻ります。したがって、実際、非ブロッキングIOモデルでは、ユーザースレッドは、カーネルデータの準備ができているかどうかを常に確認する必要があります。つまり、非ブロッキングIOはCPUを引き渡しませんが、常にCPUを占有します。ただし、ノンブロッキングIOの場合、非常に深刻な問題があります。whileループでは、カーネルデータの準備ができているかどうかを常にポーリングする必要があるため、CPU使用率が非常に高くなります。したがって、whileループが一般的に使用されることはめったにありません。データを読み取ります。
//伪代码 while(true){ new MyThread(socket) } class MyThread{ data = socket.read(); if(data!= error){ //处理数据 break; }- マルチプレックスIO：マルチプレックスIOモデルは、現在最も使用されているモデルです。マルチプレックスIOモデルでは、複数のソケットのステータスを継続的にポーリングするスレッドがあり、ソケットに実際に読み取りおよび書き込みイベントがある場合にのみ、実際のIO読み取りおよび書き込み操作が実際に呼び出されます。マルチプレックスIOモデルでは、複数のソケットを管理するために使用できるスレッドは1つだけです。システムは、新しいプロセスやスレッドを作成する必要も、これらのスレッドやプロセスを維持する必要もありません。また、ソケットの読み取りおよび書き込みイベントがある場合に限ります。 IOリソースは時間になったときにのみ使用されるため、リソースの占有が大幅に削減されます。Java NIOでは、selector.select（）を使用して、各チャネルに到着イベントがあるかどうかを照会します。イベントがない場合は、常にそこでブロックされます。したがって、このメソッドにより、ユーザースレッドがブロックされます。マルチスレッド+ブロッキングIOを使用して同様の効果を達成できると言う友人もいるかもしれませんが、マルチスレッド+ブロッキングIOでは、各ソケットがスレッドに対応しているため、特に長い間、多くのリソースを占有します。接続に関しては、スレッドリソースが解放されることはありません。将来、接続が多いと、パフォーマンスのボトルネックが発生します。マルチプレックスIOモードでは、1つのスレッドで複数のソケットを管理できます。ソケットに実際に読み取りおよび書き込みイベントがある場合にのみ、実際の読み取りおよび書き込み操作を実行するためにリソースが消費されます。したがって、多重IOは、接続数が多い状況に適しています。さらに、マルチプレックスIOが非ブロッキングIOモデルよりも効率的である理由は、非ブロッキングIOでは、ソケットステータスがユーザースレッドを通じて常に要求されるのに対し、マルチプレックスIOでは、各ソケットがポーリングされるためです。状態はカーネルによって実行され、この効率はユーザースレッドの効率よりもはるかに高くなります。ただし、多重化IOモデルは、ポーリングを使用してイベントが到着したかどうかを検出し、到着したイベントに1つずつ応答することに注意してください。したがって、多重化IOモデルの場合、イベント応答本体が大きくなると、後続のイベントは遅れて処理されず、新しいイベントのポーリングに影響します。
- 信号駆動型IO：ユーザースレッドがIO要求操作を開始すると、対応するソケットに信号関数を登録し、ユーザースレッドは実行を継続します。カーネルデータの準備ができると、信号がユーザースレッドに送信されます。ユーザースレッドが信号を受信すると、シグナル関数でIO読み取りおよび書き込み操作を呼び出して、実際のIO要求操作を実行します。
- 非同期IO：これは最も理想的なIOモデルです。非同期IOモデルでは、ユーザースレッドが読み取り操作を開始すると、他のことをすぐに開始できます。一方、カーネルの観点からは、非同期読み取りを受信するとすぐに戻り、読み取り要求が正常に開始されたことを示すため、ユーザースレッドのブロックは生成されません。次に、カーネルはデータ準備の完了を待ってから、データをユーザースレッドにコピーします。これがすべて完了すると、カーネルはユーザースレッドに信号を送信して、読み取り操作が完了したことを通知します。つまり、ユーザースレッドは、実際のIO操作全体の実行方法を必要とせず、要求を開始するだけで済みます。カーネルから返された成功信号を受信すると、IO操作が完了し、データを直接使用できます。つまり、非同期IOモデルでは、IO操作の2つのフェーズはユーザースレッドをブロックしません。両方のフェーズはカーネルによって自動的に完了し、操作が完了したことをユーザースレッドに通知する信号が送信されます。ユーザースレッドでの特定の読み取りおよび書き込みのために、IO関数を再度呼び出す必要はありません。この点は、信号駆動モデルとは異なります。信号駆動モデルでは、ユーザースレッドが信号を受信すると、データの準備ができていることを示します。次に、ユーザースレッドは、実際の読み取りおよび書き込み操作のためにIO関数を呼び出す必要があります。非同期IOモデルでは、この信号は、IO操作が完了したことを示しており、実際の読み取りおよび書き込み操作のためにユーザースレッドでiO関数を呼び出す必要はありません。非同期IOには、オペレーティングシステムの基盤となるサポートが必要であることに注意してください。これは、多重IOであるか信号駆動モデルであるかにかかわらず、IO操作の第2段階でユーザースレッドがブロックされるためです。つまり、カーネルによるデータコピーのプロセスにより、ユーザースレッドが許可されます。ブロック。
5.ノードモデルを知っていますか？
Node.jsのは、使用してイベント駆動型および非同期I / Oを実装するために、シングルスレッド、同時実行性の高いJavaScriptのランタイム環境を。
6. mysqlを知っていますか？sqlインデックスを知っていますか？データベースには大量のデータがあり、すばやく検索する方法があります。
クエリ効率が遅い理由：
1：インデックスなしまたはインデックス障害
where条件は、次のステートメントを使用してインデックスを無効にします：null、！=、<>、または接続、in（使用する必要があり、キーワードexistで置き換えることができます）であり、inではありません '％abc％';
使用パラメーター：num = @ num、式操作：ここでnum / 2 = 100、関数操作：ここでsubstring（name、1、3）= 'abc'-name;
2：クエリされたデータの量が多すぎて、不要な行と列が返されます
有用なフィールドのみをクエリします。すべてのフィールドをクエリするために*を使用しないでください。「*」を特定のフィールドリストに置き換え、使用されていないフィールドは返しません。
複数のクエリに複数のスレッドを使用します。クエリ条件が特定の期間などの範囲条件である場合、時間条件を分割して複数のクエリ結果を組み合わせることができます。
3：ロックまたはデッドロック
4：I / Oスループットが小さく、ボトルネック効果があります。
5：メモリが不足しています。
作成するオブジェクトの数を減らします。オブジェクトは、使用する必要がある場合にのみ作成され、コンテキスト全体を通過することはありません。
時間内にjvmメモリをクリーンアップします。
6：ネットワーク速度が遅い。
SQL最適化手法
1：インデックスが複合インデックスの場合、システムがインデックスを使用することを保証する条件として、インデックスの最初のフィールドを使用する必要があります。そうしないと、インデックスは参照されず、フィールドの順序は可能な限りインデックスの順序と一致する必要があります。
2：インデックスはできるだけ多くありません。テーブルインデックスは6を超えないようにするのが最適です。インデックスは選択の効率を向上させることができますが、挿入と更新によってインデックスが再構築されるため、挿入と更新の効率も低下します。そのため、インデックスの作成方法を慎重に検討する必要があります。
3：テーブル構築のいくつかの最適化：
可能な限り数値フィールドを使用します。データに数値情報のみが含まれている場合は、文字タイプとして設計しないようにしてください。これにより、クエリと接続のパフォーマンスが低下し、ストレージのオーバーヘッドが増加します。エンジンは、クエリと接続を処理するときに文字列の各文字を1つずつ比較するため、数値タイプの場合は1回の比較で十分です。
最初に、可変長フィールドのストレージスペースが小さく、ストレージスペースを節約できるため、char / ncharの代わりにvarchar / nvarcharを使用してみてください。次に、クエリの場合、比較的小さなフィールドでの検索効率が明らかに高くなります。
4：カーソルの効率が悪いため、カーソルの使用は避けてください。カーソルで操作するデータが10,000行を超える場合は、書き換えを検討してください。（カーソルは非常に古い機能であり、ほとんど廃止されています。）5：すべてのインデックスがクエリに有効であるとは限りません。SQLはテーブルのデータに基づいて最適化されます。インデックス列で大量のデータが繰り返されると、SQLクエリはインデックスを使用しない場合があります。たとえば、性別、男性、および女性はほぼ半分であるため、性別に基づいてインデックスを作成しても、クエリの効率には影響しません。
6：大規模なトランザクション操作を回避し、システムの同時実行性を向上させるようにしてください。
予防：
1：likeを使用するときは、必ず空白にすることを忘れないでください
...ここで、「％」のような名前。変数名。「％」;（変数値は外部から渡されます）
次の場合：変数が空の場合、次のsqlになります
... where name like '%%';-この条件の結果は、「すべてのデータを選択するか、すべてのデータを更新するか、すべてのデータを削除する」です。これは、書き込み条件がないことと同等であり、発生後に深刻な問題になります。
2：ワイルドカードと同様：％と_の使用
ワイルドカードの分類：%%ワイルドカード：任意の文字が何度でも表示されることを示します**（0にすることができます）**
。_アンダースコアワイルドカード：1文字のみに一致し、それ以上またはそれ以下ではなく、1文字のみに一致します。Like演算子：
LIKEの機能は、mysqlの背後にある検索パターンが、比較のために直接等しいマッチングの代わりにワイルドカードを使用することであることを示すことです。
注：like演算子を使用する場合、一般的なマッチング演算子を使用しない後者の効果は、=、SELECT *と一致します。 FROM products WHERE products.prod_name like '1000';一致する結果は1000のみですが、JetPack1000のような結果と一致することはできません。1）ワイルドカードの使用率：
「yves」で始まるレコードに一致:(レコード「yves」を含む）
SELECT * FROM products WHERE products.prod_name like'yves％ ';「yves」を含むレコードに一致します（レコード「yves」を含む）
SELECT * FROM products WHERE products.prod_name like '％yves％';「yves」で終わるレコードを一致させます（レコード「yves」を含み、レコード「yves」、つまり、ここで注意が必要なyvesの後にスペースがあるレコードを除く）
SELECT * FROM products WHERE products.prod_name like '％yves';2）ワイルドカード文字の使用：
SELECT * FROM products WHERE products.prod_name like'_yves ';
一致する結果は：record like "yyves"。SELECT * FROM products WHERE products.prod_name like'yves__ ';
一致する結果は次のとおりです： "yvesHe"のようなレコード（下線は1文字のみ一致し、それ以上または以下）その他の操作：
tb（...）値に挿入（...）、（...）...; tb（...）値に挿入するよりも優れています（...）; tb（...）値に挿入する（...）; ...バッチ挿入の方法が非常に効率的です[理由]：ここでの2回目のSQL実行の効率が高い主な理由は、マージ後のログ量（MySQLのbinlogおよびinnodbトランザクションによってログが作成される）が減少し、ログが減少することです。データブラッシングの量と頻度。これにより、効率が向上します。SQLステートメントをマージすることにより、SQLステートメントの解析回数を減らし、ネットワーク送信IOを減らすこともできます。
7.プロセスとスレッドを理解していますか？CPU処理の基本単位は何ですか？
プロセスはオペレーティングシステムのリソース割り当ての基本単位であり、スレッドはタスクのスケジューリングと実行の基本単位です。プロセスはスレッドのコンテナです
8.CPU処理のアルゴリズムについて教えてください。
9.プロセスデッドロックとは何ですか？
デッドロックの定義：デッドロックは、リソースの競合により、プロセスセット内の複数のプロセスが互いに待機する現象です。例：AとBは餃子を食べ、Aは大豆ソースを、Bは酢を、Aは酢を、Bは大豆ソースを食べます。その結果、どちらも餃子を食べるのを待ちます。
デッドロックの原因：不十分なシステムリソース、複数のプロセスの不当な進行シーケンス、不適切なリソース割り当て
デッドロックに必要な条件：
（1）相互除外：リソースは共有できず、1つのプロセスでのみ使用できます。
（2）要求および保留条件（保留および待機）：すでにリソースを取得しているプロセスは、新しいリソースを再度申請できます。
（3）プリエンプションなし：割り当てられたリソースを対応するプロセスから強制的に奪うことはできません。
（4）循環待機条件（循環待機）：システム内の複数のプロセスがループを形成し、ループ内の各プロセスは、隣接するプロセスによって占有されているリソースを待機しています。
デッドロックに対処するには、次の4つの方法があります。1）デッドロックを防止する2）デッドロックを回避する3）デッドロックを検出して削除する
デッドロックの防止：4つの必要な条件の1つを破壊します
①相互排除条件の破壊：リソースの共有を許可します。たとえば、SPOOLingテクノロジーを使用すると、複数のプロセスで同時に印刷データを生成できます。
短所：SPOOLingテクノロジーは、プロセステーブルなどのすべてのリソースに適しているわけではないため、リソースの相互除外を破棄するのがより困難であり、この方法はあまり適していません。
②破壊要求と保持条件：リソースは一度に割り当てられます。
短所：このメカニズムでは、プロセスは実行プロセス中にリソースに適用されなくなりますが、このメソッドの効率は非常に低く、リソースを十分に活用できません。
③不可侵条件を破る：要求されたリソースが満たされない場合に元々占有されていたリソースを放棄する方法と、所有よりも優先度の高いリソースを申請するプロセスにのみ適用される方法の2つがあります。リソースのプロセス優先度が高い場合、プロセスによって要求されたリソースが他のプロセスによって占有されていて、アプリケーションプロセスの優先度が高い場合、リソースを占有しているプロセスを強制的に放棄する可能性があります。この方法は、通常、プロセッサとストレージリソースに適用できます。
④破壊サイクル待機条件：システムは各タイプのリソースに番号を割り当て、各プロセスは番号の昇順でリソースを要求し、リリースは逆になります（哲学者の食事の問題など）
デッドロックを回避するには、2つの方法があります。1）リソースが順番に割り当てられ、2）バンカーのアルゴリズムです。
デッドロックを解除するには、次の2つの方法があります。1）リソース剥奪方法2）プロセスキャンセル方法3）プロセスロールバック方法
10. WebサイトのURLを教えてください。このURLのすべてのURLと、重複していないこれらのURLを介してリダイレクトされたすべてのURLを書き留めてください。
11.ファイルをアップロードするコンテンツタイプとボタンをクリックするコンテンツタイプの違いは何ですか？http送信プロトコルの違いは何ですか？
コンテンツタイプ：
一般に、Webページに存在するContent-Typeを指します。これは、ネットワークファイルのタイプとWebページのエンコーディングを定義し、ブラウザがこのファイルを読み取るフォームとエンコーディングを決定するために使用されます。これは、PHPWebページのクリックが頻繁に発生する結果です。ファイルや写真をダウンロードする理由です。ヘッダーは、実際に返されたコンテンツのコンテンツタイプをクライアントに通知します。Httpのエンティティヘッダーフィールドです。要求または返されるメッセージ本文のエンコード方法を説明するために使用されます。要求ヘッダーと応答ヘッダーの両方に存在します。
一般的なタイプ：
text /（plain、css、html、xml）（text ,, css、html、xml）type
application /（x-javascript、json、xml、octet-stream）（js、json、xml、binary stream data）type
image / png jpg gif image / *エクセルファイルのアップロード：
.xls application/vnd.ms-excel
12.アルゴリズムの問題：合計が最大の連続サブ配列となるように、int配列{1、2、5、-7、8、-10}を出力します。
総括する：
今回の準備は主にjsの知識です。バイトインタビューが非常に低レベルであるとは思っていなかったので、レビューしませんでした。。。アルゴリズムの質問をブラッシュアップしませんでした。30分ほどやりましたが、できませんでした。。。少し前のAntFinancialのインタビューよりもはるかに難しいと感じています。。。