Wondershare EdrawMind
マインドマップギャラリー Java アーキテクト p5 ～ p7 への昇進パス (年収 500,000 ～ 700,000)
- 9
Java アーキテクト p5 ～ p7 への昇進パス (年収 500,000 ～ 700,000)
Java アーキテクト p5 ～ p7 の昇進パス (年収 500,000 ～ 700,000)、実用的なデータ構造とアルゴリズム、マイクロサービス ソリューションのデータ構造モデル、JVM 仮想マシンの実用的なパフォーマンス チューニング。並行プログラミングの実践、マイクロサービス フレームワークのソース コード解釈、コレクション フレームワークのソース コード解釈、分散アーキテクチャ ソリューション。インターネット分散トランザクション アーキテクチャの設計と実際の実装、分散メッセージ ミドルウェアの原則、MySQL の実際のパフォーマンスの最適化、Netty の詳細なソース コード解釈。
2023-11-21 16:53:38 に編集されました
- おすすめ
- アウトライン
JAVA アーキテクトとしての進歩への道
データ構造とアルゴリズムの実践
数学の知識の復習
索引
対数
シリーズ
モジュロ演算
複雑さ
時間の複雑さ
空間の複雑さ
データ構造
スタックモデル
先入れ後出しの原則
ポップ/プッシュ
スタックアプリケーション
キューモデル
先入れ先出しの原則
シーケンシャルキュー
連鎖されたキュー
デク
優先キュー
ツリーモデル
二分木
AVLツリー
手がかり二分木
赤黒い木
広がる木
ハッシュモデル
ハッシュ関数
リニア検出方式
二乗検出法
ダブルハッシュ
ハッシュ関数方式
直接アドレス指定方式
デジタル分析
スクエア・ミディアム法
折り方
余りを残す除算メソッド
乱数法
競合に対処する方法
線形プローブとその後のハッシュ
二乗プローブとハッシュ
ヒープモデル
左側の山
スキューパイル
アルゴリズムの練習
ソートアルゴリズム
挿入ソート
ヒルソート
ヒープソート
マージソート
クイックソート
バブルソート
実践的なアルゴリズム
貪欲なアルゴリズム
ハフマン符号化
おおよそのビン梱包の問題
分割統治アルゴリズム
分割統治アルゴリズムの実行時間
最近の問題
質問を選択してください
動的プログラミング
再帰の代わりにテーブルを使用する
行列の乗算の順序
最適二分探索木
すべての点のペアの最短経路
ランダム化アルゴリズム
乱数発生器
ジャンプ台
適性検査
マイクロサービス ソリューションのデータ構造モデル
登録センタークラスターアルゴリズム
Nacos クラスター選挙 Raft アルゴリズム
疫病拡散アルゴリズム P2P-ゴシッププロトコル
Eureka メッセージ ブロードキャスト一貫性プロトコル
分散トランザクション整合性プロトコル
強力な整合性プロトコル
弱い整合性プロトコル
最終的な整合性プロトコル
Zookeeper コンセンサス プロトコル アルゴリズム
ZAB アトミック ブロードキャスト プロトコル
Paxos コンセンサスプロトコル
分散キャッシュ削除アルゴリズム
LRU (最近使用されていない) キャッシュ削除アルゴリズム
LFU (最も頻繁に使用されないアルゴリズム) キャッシュ削除アルゴリズム
ARC (Adaptive Cache Replacement Algorithm) キャッシュ削除アルゴリズム
FIFO (先入れ先出し) キャッシュエビクションアルゴリズム
MRU (最近使用された) キャッシュ削除アルゴリズム
分散キャッシュブレークダウンプロトコル
ブルームフィルター
カッコーフィルター
負荷分散アルゴリズム
ポーリングメカニズムのアルゴリズム
ランダムアルゴリズム
固定IPアルゴリズム
重み付けアルゴリズム
マイクロサービス電流制限アルゴリズム
カウンタ（固定ウィンドウ）アルゴリズム
スライディング ウィンドウ アルゴリズム
リーキーバケットアルゴリズム
トークンバケットアルゴリズム
分散コンピューティングタスクスケジューリングアルゴリズム (xxl-job)
回転方法
重み付け方法
ハッシュ化
最小結合法
最小欠損法
最速の応答方法
遺伝的アルゴリズム
アリコロニーアルゴリズムソリューション
分散データの同期および一貫性プロトコル
MySQL
半同期レプリケーション
非同期レプリケーション
グローバル同期
キャッシュ
運河
カワウソ
(openresty/tengine) 実際の高い同時実行性
ネイティブNginxコアモジュール
Nginxモジュールの種類
標準HTTPモジュール
オプションのHTTPモジュール
サードパーティモジュール (lua)
Nginxのイベント駆動型モデルと機能
Nginxコアの構成
仮想ホスト構成
上流の
位置
静的ディレクトリ構成
httpsプロトコルの設定
Nginx 負荷分散アルゴリズムの構成
ポーリングメカニズムのアルゴリズム
ランダムアルゴリズム
固定IPアルゴリズム
重み付けアルゴリズム
オープンレスティ/テンジン
OpenrestyとLuaを組み合わせて10億レベルの商品詳細ページを実現
Tengine は Alibaba によって開発された Web サーバー プロジェクトです。
JVM仮想マシンの実践的なパフォーマンスチューニング
プログラミング言語開発の歴史
アセンブリ言語/機械語
C/C言語
java/php/簡単言語/ython
JVMクラスローダーClassLoader
HotSpot仮想マシン(C)ソースコードからのクラスローダー実装原理の解析
クラスローダーとは何ですか
クラスファイルをメモリに読み込みます
クラスローダーの分類
ブートストラップ クラス ローダー (C で書かれた)
$JAVA_HOME/jre/lib
拡張クラスローダー (Java で書かれた)
JAVA_HOME/jre/lib/ext
(アプリケーション) AppClassLoader クラスローダー (Java で記述)
クラスパス下のクラスおよびjarパッケージ
カスタム クラス ローダー (Java で書かれた)
カスタムクラスファイルのディレクトリ
保護者による委任メカニズムの利点
その目的は、開発者が定義したクラスと jdk が定義したソース コード クラス間の競合を防止し、メモリ内でのクラスの一意性を確保することです。
クラスローダーの親委任の原則とそれを破る方法
spiの仕組み
スタートアップクラス/拡張機能/アプリケーションクラスローダーの詳細なソースコード分析
Java SPIService Provider インターフェイスの原則
Tomcat/Jetty クラスローダーの実装原理
クラスローダーをカスタマイズしてバイトコードと手書きのホットデプロイメントプラグインをロードする方法
ローカルディスク
ネットワークの取得
データベース
動的プロキシ生成
戦争/瓶
JVMメモリ構造原理の分析
JVMランタイムゾーン
プログラムカウンター
次の CPU コンテキストの切り替えを容易にして実行を再開できるように、コードを実行している現在のスレッドの行番号を記録します。
ヒープ
新しいオブジェクトはヒープ (スレッドによって共有) に保存されます。
実稼働環境でのヒープ メモリ リークのトラブルシューティング
メモリーリーク
ヒープメモリリークとは何ですか
ヒープ メモリ アプリケーション スペース、GC でメモリを解放できません
メモリリークが発生するシナリオ
スレッドローカルのメモリリーク
hashMap カスタム キー オブジェクトのメモリ リーク
実稼働環境でのヒープ メモリ リークのトラブルシューティング
JPS/Jマップ
Jvisualvm/jconsole
メモリオーバーフロー
ヒープメモリオーバーフローとは何ですか
ヒープ メモリ内の領域を申請するときに、十分な領域がありません。
ヒープメモリオーバーフロー
データベースから一度に大量のデータを取得するなど、メモリにロードされるデータの量が多すぎる
コレクション クラス内にオブジェクトへの参照があり、使用後にクリアされないため、JVM はそれをリサイクルできません。
コード内に無限ループがあるか、ループによって生成される重複オブジェクト エンティティが多すぎます。
起動パラメータのメモリ値の設定によるヒープ メモリの設定が小さすぎます。
メモリオーバーフローの解決策
ヒープメモリを増やす
ヒープメモリ構造の詳細
ヒープ構造の分割
新世代/旧世代
新しい世代
新しく作成されたオブジェクトは新しい世代に保存されます
老齢
頻繁に使用されるオブジェクトは古い世代に保存されます
JDKのバージョン
jdk1.7
eden (エデンの園) (s0) から (s1) 永続世代 (メソッド領域)
jdk1.8
eden (エデンの園) (s0) から (s1) 永続世代 (メタスペース)
特性：
新しい世代と古い世代のデフォルトの比率は 1:2 です。
-XX:新しい比率
s0/s1 8:1:1 のデフォルト Eden
-XX:生存率
よく使う単語
YoungGen（新世代）
oldGen (旧世代)
s0(から)
s1(へ)
PermGen (永続的な世代)
メタスペース
GCの分類
部分的なコレクション
新世代コレクション (マイナー GC/ヤング GC)
古い世代のコレクション (メジャー GC/古い GC)
CMS GC は古い世代を個別に収集します。
ヒープおよびメソッド領域の収集
(フルGC): Javaヒープおよびメソッド領域(メタ空間)全体のガベージコレクションを収集します。
面接でよくある質問
フル GC とマイナー GC/ヤング GC の違い
フル gc は新世代と旧世代のコレクションをトリガーします
マイナー GC が新世代の GC コレクションをトリガーする
マイナー GC 収集時間が非常に頻繁に発生する
full gc は、古い世代またはメソッド領域 (メタスペース) にメモリが不足している場合にリサイクルをトリガーします。
フル GC の GC 回収効率は非常に低い
完全な GC リサイクルをトリガーしないようにしてください
大きなオブジェクトはどこに保管されますか?
eden領域を保存できない場合は、旧世代に直接保存されます。
GCログの分析
記憶逃避
スペース保証
スレッドスタックとスタックフレームの内部構造の解析
ローカル変数テーブル
オペランドスタック
動的接続
メソッドのエクスポート
ローカル メソッド スタック (JNI 呼び出し C コード) テクノロジ
文字列定数プール
定数プールの分類
静的定数プール
定数プールを実行する
文字列定数プール
異なるJDKバージョンのストレージ領域への定数プール
JDK1.6以前の文字列定数プールはメソッド領域に格納されます(永続生成)
JDK1.7では、文字列定数プールがヒープに格納され始めます。
JDK1.8の文字列定数プールはヒープに格納されます
文字列面接でよくある質問
JDK1.7 が文字列定数プールをヒープに保存し始めたのはなぜですか?
JDK7 では、文字列定数プールはヒープ領域に配置されます。永続世代のリサイクル効率は非常に低いため、永続世代のガベージ コレクションはフル GC 中にのみ実行され、古い世代のスペースが不足し、永続世代が不足した場合にフル GC がトリガーされます。 。
このため、文字列定数プールの再利用効率が低くなります。私たちの開発では、多数の文字列が作成され、再利用効率が低くなり、永続的な世代メモリが不足します。ヒープに置くと、時間内にメモリを再利用できます。
文字列 s1 = "mayikt";
String s1 = "mayikt"; s1 は文字列定数プールを指します。
new String("mayikt");
ヒープ内にヒープスペースアドレスを作成し、それをs2に返します。 s2 はヒープ メモリ アドレスを取得し、mayikt は String クラスに文字列定数プールを導入します。
JVMオブジェクトのメモリレイアウト
オブジェクトのレイアウト
オブジェクトヘッダー
インスタンスデータ
パディングを揃える
新しいオブジェクトは何バイトを占有しますか?
オブジェクトのアクセス場所
ハンドルモード
メモリの一部は、ハンドル プールとして Java ヒープに分割される場合があります。ローカル変数の参照に格納されるのは、オブジェクトのハンドル アドレスです。
ダイレクトポインタ方式
参照に格納されるのは、直接オブジェクトのアドレスです。
オブジェクトの作成方法
1.新しいオブジェクト
2. リフレクションを使用してオブジェクトを作成する
3. clone() を使用してオブジェクトのクローンを作成します
4. 逆シリアル化されたオブジェクトを使用する
5. サードパーティ ライブラリ Objenesls がオブジェクトを作成する
オブジェクトの詳細を作成する
1. オブジェクトのクラスがロード、解析、初期化されているかどうかを確認します。
1. Java 仮想マシンは、バイトコードの新しい命令を検出すると、まずこの命令のパラメータによって定数プール (メタスペース内) 内のクラスのシンボリック参照を見つけることができるかどうかを確認し、このシンボリック参照によって表されるクラスを確認します。ロード、解析、および初期化されているかどうか (クラスがメタスペースによってロードされているかどうかを判断するため)
そうでない場合は、対応するクラスのロード プロセスを最初に実行する必要があります (その後、親委任メカニズムを使用してクラス (クラスのフル パス) を見つけます。見つからない場合は、エラー ClassNotFoundException が報告されます)。
2. クラス読み込みチェックに合格すると、仮想マシンは新しいオブジェクトにメモリを割り当てます。
ヒープメモリが通常の場合に使用します
ポインタの衝突
ヒープメモリが不規則な場合に使用します
フリーリスト
3. オブジェクトの作成は、仮想マシンで頻繁に行われる動作です。たとえポインターが指す場所を変更するだけであっても、同時実行環境ではスレッドセーフではありません。
1. CAS 失敗再試行を使用して更新のアトミック性を確保します。
2. Eden (Eden Campus) の現在のスレッドに固有の TLAB スペースをスレッドごとに割り当てます。
4. 属性のデフォルト値を設定します。メモリ割り当てが完了したら、仮想マシンは割り当てられたメモリ空間 (ただし、オブジェクト ヘッダーは含まれません) をゼロに初期化する必要があります。TLAB を使用する場合は、この作業を事前に割り当てることもできます。ちなみにTLABへ。この手順により、オブジェクトのインスタンス フィールドが初期値を割り当てずに Java コードで直接使用できるようになり、プログラムはこれらのフィールドのデータ型に対応するゼロ値にアクセスできるようになります。
5. オブジェクトのヘッダー情報を設定します。Java 仮想マシンは、オブジェクトがどのクラスのインスタンスであるか、クラスのメタデータ情報の検索方法、オブジェクトのハッシュ コードなど、オブジェクトに必要な設定を行う必要もあります。 (実際には、オブジェクトのハッシュ コードは、Object::hashCode() メソッドが実際に呼び出されるまで遅延します)、オブジェクトの GC 生成年齢、およびその他の情報。この情報は、オブジェクトのオブジェクト ヘッダー (Object Header) に格納されます。バイアス ロックが有効かどうかなど、仮想マシンの現在の実行ステータスに応じて、オブジェクト ヘッダーはさまざまな方法で設定されます。
6. initメソッドを実行して初期化します。
JVM ガベージ コレクション アルゴリズム
ガベージコレクションアルゴリズム
マークアンドスイープアルゴリズム
利点: 高効率/メモリアドレスの移動なし
短所: 断片化が起こりやすい
タグソートアルゴリズム
利点: 断片化の問題を回避します。
短所: メモリアドレスの移動、効率の低さ
マーク付きコピーアルゴリズム
利点: 断片化の問題を回避します。
短所: メモリアドレスの移動、高効率
生成アルゴリズムの原理
新しい世代
老齢
JDK1.0-14コレクター
ガベージコレクターの組み合わせ
(新世代パラレル) ParNew (旧世代シリアル) 旧シリアル
(新世代シリアル) シリアル、(旧世代) 旧シリアル
(新世代シリアル) シリアル/CMS (旧世代同時実行)
(JDK9は廃止されました)
(新世代の同時実行性) ParNew/CMS (旧世代の同時実行性)
(JDK9 では推奨されません)
(新世代パラレル) パラレル/シリアルOld (旧世代シリアル)
推奨されません
(新世代でのパラレル) パラレル スカベンジ/パラレル オールド (旧世代でのパラレル)
JDK8のデフォルト
G1 (JDK9 デフォルト) ヒープ コレクション全体
JDK8のデフォルト
シリアル (シングル GC スレッドのリサイクル)
シリアルガベージコレクタの詳細説明
組み合わせ
新世代 (シリアル) マーク付きレプリケーション アルゴリズム
シリアル旧マーク圧縮アルゴリズム
アプリケーションシナリオ
シングルコア CPU と小さなメモリを使用する
並列 (複数の GC スレッドのリサイクル)
ParNewガベージコレクタの詳しい説明
アプリケーションシナリオ
新しい世代
マルチコアCPUに最適
組み合わせ
(旧世代) 古いシリアル (マーク圧縮アルゴリズム)
(旧世代) CMS (マーク アンド スイープ アルゴリズム)
並列ガベージコレクタの詳細説明
アプリケーションシナリオ
新世代/旧世代の複数の GC コレクションを同時に実行
組み合わせ
平行
並列oldGC
同時実行性 (GC スレッドとユーザー スレッドが同時に実行される)
CMS ガベージ コレクターの原理 (重要なポイント)
実施原則
イニシャルマーク
同時マーキング
ラベルを付け直す
同時クリア
CMS コレクターの欠点は何ですか?
マークアンドスイープアルゴリズムにより断片化の問題が発生する
代替の SerialOld は非効率的です
増分更新方式に基づいてラベル欠落の問題を解決
G1コレクターの原則（ポイント）
実施原則
複数の異なる領域
リージョンメモリーセット（Remember Set）
Cardtableの詳しい説明
オリジナルのスナップショット (Satb) に基づいて建物のマーキング問題を解決します。
ZGCガベージコレクタの詳しい説明
Epsilon および Shenandoah ガベージ コレクターの詳細な説明
ガベージコピーアルゴリズム
ガベージコレクション機構の3色マーキングアルゴリズムの原理
3 色マーキング アルゴリズムによって引き起こされる複数のラベリング/ラベリング欠落の問題
浮遊ゴミ
入札漏れの問題
オブジェクト欠落ラベルの解決策
増分更新方式 (CMS) に基づく
オリジナルのスナップショット方式satb(G1)に基づく
リージョンメモリセット（Remember Set）とカードテーブル（Cardtable）の詳細説明
世界を止めて
ストップ・ザ・ワールド問題はなぜ起こるのか？
ストップ・ザ・ワールド問題を回避する方法
JVMチューニングツールの詳細説明
JDK 独自の Jstat、Jinfo、Jmap、Jhat、および Jstack チューニング コマンドの詳細な説明
Jvisualvm および Jconsole チューニング ツールの詳細な説明
Alibabaツールarthasの使い方を詳しく解説
GCログ解析ツール
GCログの詳細を読む方法
GCEasyログ分析ツールの利用
ログ解析ツールGCViewerの利用
JVMパラメータチューニングの実践
1億レベルのトラフィックプロジェクトのヒープメモリ若い世代と古い世代のガベージコレクションパラメータの設定とチューニング
オンライン実稼働環境 OMM メモリ オーバーフロー監視ツールと位置決めソリューション
直接的なシステムのフリーズにつながるオンライン実稼働環境での深刻なフル GC を削減する方法に関する最適化プラクティス
高同時実行システム、オンライン実稼働環境で頻繁な GC 操作を回避する方法
高同時実行システム、G1/CMS コレクターを最適化する方法
1 日平均 100 万 PV サービスの JVM ヒープの初期メモリ サイズを設定する方法
同時プログラミングの実際
オペレーティング システムの基本
ユーザーモードとカーネルモード間の切り替え処理
Linuxプロセスモデル管理
Linuxのプロセス間通信の原理
Linux ネットワーク通信の原則
マルチスレッドの基本
マルチスレッドのクイックスタート
プロセス/スレッドとは何ですか
プロセスはリソース割り当ての最小単位です
スレッドはプログラム実行の最小単位です
マルチスレッドアプリケーションのシナリオ
クライアント（モバイルアプリ/）開発
SMS の送信/電子メールの非同期送信
実行に時間がかかるコードをマルチスレッドの非同期実行に変更します。
ログを非同期で書き込む
マルチスレッドのダウンロード
マルチスレッドとシングルスレッドの違い
マルチスレッド（並列実行）
シングルスレッド（同期実行）
マルチスレッド CPU スイッチングの概念を理解する方法
現在の CPU が別のスレッドを実行するように切り替わります。
マルチスレッドを有効にすると有効になるというのは本当ですか?
必ずしもそうとは限りませんが、スレッドを開きすぎると、CPU コンテキストの切り替えが発生しやすくなります。
ユーザースレッドとデーモンスレッドの違い
スレッドを正常に停止する方法
マルチスレッドの 7 つの状態の分析
初期状態
準備完了状態
稼働状況
<font face="宋体"><span style="font-size: 14px;">死亡状態</span></font><br>
ブロッキング状態
タイムアウト待機
待機状態
マルチスレッドを作成する 5 つの方法
Thread クラスを継承してスレッドを作成する
Runnable インターフェイスを実装してスレッドを作成する
Callable と Future を使用してスレッドを作成する
Executor フレームワークなどのスレッド プールを使用する
@Async 非同期アノテーションを使用してスレッドを作成する
ラムダ式を使用してスレッドを作成する
マルチスレッドのスレッドセーフ
スレッドの安全性の問題とは何ですか
複数のスレッドが同じグローバル変数に同時に書き込むと、他のスレッドによって干渉される可能性があり、スレッドの安全性の問題が発生する可能性があります。
ロックとシンクロロックの違い
lock ロックを手動で取得および解放する
同期はロックを自動的に取得および解放します
SynchronizedJDK6 は自動ロック アップグレード プロセスを開始します
lock ロックの基礎となる実装は aqs ロックに基づいており、ロックを手動でアップグレードする必要があります。
マルチスレッドのデッドロックの問題
マルチスレッドによるデッドロックのトラブルシューティング方法
jconsole.exe がデッドロックを診断します
マルチスレッドデッドロックスレッドの原因
同期内でネストされた同期
スレッドの安全性の問題を解決する方法 (スレッドの同期を確保する方法)
Synchronized はスレッドの安全性の問題を解決します
同期された同期コードは高速です
同期された変更されたインスタンス メソッド
同期された変更された静的メソッド
ロックロックはスレッドの安全性の問題を解決します
複数のスレッド間の通信
待って通知する
wait は現在のロックを解放し、現在のスレッドをブロックします。
ブロックされたスレッドを目覚めさせる通知
結合方式の原理
最下層は待機カプセル化に基づいています
同期原理
オブジェクトがどのように構成されるか
オブジェクトヘッダー
マークワード
ハッシュ コード (HashCode)、GC 生成経過時間、ロック ステータス フラグ、スレッドが保持するロック、偏ったスレッド ID、偏ったタイムスタンプ
クラス・ポインター<br>
インスタンスデータ
メンバーのプロパティ
パディングを揃える
オブジェクトのサイズは 8 バイトの整数倍でなければなりません。8 バイトの整数倍でない場合は、整列されて埋め込まれます。
同期ロックのアップグレード プロセス
バイアスロック
ロックとロック解除には追加のオーバーヘッドは必要ありません。これらは、同じスレッドが同期されたコード ブロックにアクセスする場合にのみ適しており、複数のスレッドが同時に競合した場合、ロックは取り消されます。
軽量ロック
競合するスレッドはブロックされないため、プログラムの応答速度が向上します。ロックの競合するスレッドが取得されない場合、スピンは、同期されたコード ブロックが非常に高速に実行される状況に適しています。 7)以降の回転
ウェイトロック
スレッド競合はスピンを使用せず、CPU リソースを消費せず、比較的長時間の同期コード実行に適しています。
同期ロック拡張処理原理の解析
バイアスロック(101)
1. 現在のスレッドは、オブジェクト ヘッダーのマークワードからバイアスされたロックかどうかを取得し、バイアスされたロックである場合は、スレッドの id=== 現在のスレッド ID であるかどうかを判断します。
2. 現在のスレッド ID と等しい場合、CAS 操作は繰り返し実行されず、同期コード ブロックに直接入ります。
3. 現在のスレッド ID と等しくない場合、ロックのない状況で競合する他のスレッドがない場合は、CAS を直接使用してマークワードのロック ステータスを 101 に変更し、現在のスレッド ID も保存します。マークワードで。
4. 他のスレッドは、バイアス ロックのキャンセル数が 20 に達すると、バイアス ロックをバッチで T2 スレッドに直接リダイレクトします (注意: t2 と競合する他のスレッドはありません)。バイアスロックのキャンセル回数が20回、40回に達すると、後でバッチのアンドゥが開始されます。
5. バイアスされたロックをキャンセルするには、バイアスされたロック スレッドをグローバルな安全なポイントで停止し、マークワードを軽量ロックに変更し、バイアスされたロック スレッドを起動する必要があります。
6. 注: JDK15 は、デフォルトでバイアスされたロックの最適化をオフにします。
軽量ロック(000)
1. 複数のスレッドが同じロックを同時に競合する場合は、軽量ロックをアップグレードし、CAS (マークワード ロック ステータス = 00 を変更) を使用します。成功した場合は、マークワードに置き換えて、スタック フレームに直接 HashCode 値を保存します。 、ロック レコード アドレスはマークワードに格納されます。
2. 軽量ロックを使用してロックを解放すると、マークワード値の内容が復元されます。
ヘビーウェイト(010)(Cモニター)
1. スレッドが複数回再試行してもロックを取得できなかった場合、現在のロックはヘビーウェイト ロックにアップグレードされます。
2.2. ロックを取得していないスレッドは、C Monitor オブジェクトの EntryList コレクションに格納されます。同時に、現在のスレッドは、ウェイクアップして競合に再参加するためのプロセス コストを直接ブロックして解放します。 CPU コンテキストの切り替えが発生する必要があるため、後の期間のロックは非常に高くなります。ユーザー モードからカーネルに切り替え、オブジェクト ヘッダーのマークワード値を C モニターに変更します。メモリ アドレス ポインター Java オブジェクトは C モニターに関連付けられています。
C モニターモニターロック（重量ロック）
モニター (オブジェクト重量ロック)
再帰 (再帰の数/再エントリの数)
所有者 (現在ロックを保持しているスレッド ID を記録します)
waitSet (プールが待機状態になるのを待っているスレッドが _WaitSet に追加されます)
entryList (ロック プール: ロック ブロック状態を待機しているスレッドがリストに追加されます)
待機プール内のスレッドが起動されると、すぐにロックが取得されますか?
待機プール内のスレッドが目覚めると、待機プールはロック プールに転送され、再びロックを競合するためにキューに入れられます。
ロックの粗密化、削除、パフォーマンスの最適化
ロックの粗面化
各スレッドはできるだけ短い時間ロックを保持します。
ロックの排除
ロックの削除は、コンパイラ レベルで発生するロック最適化方法です。
揮発性キーワードの原則
キーワードのプロパティ
視認性の確保
並べ替えを無効にする
アトミック性の保証はない
Javaメモリモデル
CPUマルチコアハードウェアアーキテクチャの解析
jmmエイト同期仕様
揮発性キャッシュコヒーレンスプロトコル
バスロック
MESIプロトコル
偽共有の問題
キャッシュラインの基本概念
銀行充填計画
なぜ並べ替え/メモリバリア/ダブルチェックロックに volatile を追加する必要があるのですか?
同期型と揮発性型の違い
Volatile がアトミック性を保証しない理由
同時ロックの分類
悲観的なロック
楽観的ロック
スピンロック
リエントラントロック
フェアロック
不当なロック
aqs ソースコードの解釈
LockSupport のソース コードの解釈
AbstractQueuedSynchronizer のソース コードの解釈
ReentrantLock/ReentrantReadWriteLock、ReadWriteLock のソース コード解釈
セマフォ/CountDownLatch/CyclicBarrie ソース コードの解釈
AQS の最下層を実装する方法
A.Cas は AQS のスレッドの安全性を保証します
B. 二重リンクリストにはブロックされたスレッドが格納されます
C.LockSupport はスレッドをブロックしてウェイクアップします
コア属性
状態状態値
ノードステータス(waitStatus)
-2 現在のスレッドはブロックし、同時にロックを解放します。
-1 は後続のノードのスレッドを起動します<br>
AQS アプリケーションのシナリオ
lock lock の基礎となる実装
公平なロックと不公平なロック
デフォルトは不公平なロックです
競合ロック時間
公平なロック: ロックを競合するときに、そのロックがすでに別のスレッドによって保持されている場合、そのロックは二重リンク リストの最後に直接格納されます。
不公平なロック: ロックを競合するときに、そのロックがすでに別のスレッドによって保持されている場合でも、CAS は再度試行されます。
核となる設計原則
ロックメソッド()
CAS を使用して、AQS クラスのステータス値を 0 から 1 に変更します。
変更が成功した場合（ロックの取得に成功した場合）
変更に失敗した場合（ロックの取得に失敗した場合）
AQS二重リンクリストに格納
ロック解除メソッド()
CAS を使用して、AQS クラスのステータスを 0 から 1 に変更します。
CASが成功した場合
AQS 二重リンク リスト内のヘッド ノードの次のノードによってキャッシュされたスレッドをウェイクアップする必要がある
質問: ロックを解除するとロックが解除され、複数のスレッドではなく 1 つのスレッドだけがウェイクアップされるのはなぜですか?
最下位層は双方向リンク リストを使用してブロックされたスレッドを保存します。すべてのスレッドを起動するコストは非常に高くなります。
ロックにはロックのアップグレード プロセスがなく、開発者が自分でロックを拡張する必要があります。
Lock の基礎となる ConcurrentHashMap1.7 ソース コード
状態
注: 条件とロックは同じ二重リンクリストを使用しません。
ロックプールと待機プール
ロック プール: ロックの競合に失敗し、AQS 二重リンク リストに格納されているロック内のスレッドを指します。
待機プール: await メソッドを呼び出し、アクティブにロックを解放し (aqs ステータス値 = 0)、待機プールの二重リンク リストに格納する現在のスレッドを指します。
待機プール内のスレッドをウェイクアップするにはどうすればよいですか?
この signal() を呼び出すと、待機プール内のノード (スレッド) が AQS 二重リンク リストのロック プールに転送され、再びロック リソースを競合します。
この signal() を呼び出して、unlock メソッドを呼び出した後、ウェイクアップ ロック プール内のスレッドはロック リソースを求めて競合を開始します。
カウントダウンラッチ(カウンター)
コンストラクターを通じて new CountDownLatch(1)
AQS に基づく基礎となる実装は、AQS クラスのステータス値を 1 に設定します。
await メソッド
現在のスレッド ブロックを AQS 二重リンク リストに保存します
秒読み
AQS クラスでステータス値 -1 を操作し、AQS ステータスが 0 に変更された場合、AQS クラスの二重リンク リストに格納されているスレッドを起動します。
セマフォ(セマフォ)
コンストラクターを通じて new Semaphore(3)
AQS に基づく基礎となる実装は、AQS クラスのステータス値を 3 に設定します。
取得の基本的な操作は、AQS クラスのステータス値 -1 を変更することです。AQS クラスのステータス値が 0 に変更された場合、現在のスレッドをブロックし、AQS クラスの二重リンク リストに格納する必要があります。
リリースの最下層は、AQS クラスのステータス 1 で動作します<br>
AQS クラスでブロックされているスレッドを同時にウェイクアップします (ウェイクアップされるのは 1 つだけです)
CyclicBarrier (同期バリア)
コンストラクター new CyclicBarrier(2) を通じて<br>
最下層は、CyclicBarrier カウント属性に値 = 2 を割り当てます。
最下層の呼び出し待機
CyclicBarrier カウント 1 の操作
カウント=0
実行を継続し、待機プール内のすべてのスレッドを起動します。
カウント!=0
待機プールに保管されます
同時アトミック操作
アトミッククラス
CAS（楽観的ロック）原理
Unsafe魔法クラスの詳しい説明
ブロッキングキューBlockingQueue の原則
ブロッキングキューの分類
ArrayBlockingQueue 配列限定キュー
ConcurrentLinkedQueue リンク リスト境界付きキュー
PriorityBlockingQueue 優先ソート無制限キュー
DelayQueue 遅延無制限キュー
フレームワークアプリケーション
BlockingQueue に基づく手書きのスレッド プール
BlockingQueueをベースにした手書きメッセージミドルウェア
BlockingQueue に基づく手書きログ フレームワーク
Executor スレッド プールとコア ソース コード解析の詳細な説明
スレッドプールを使用する理由
再利用性
一元管理
レスポンスの向上
スレッド プールを作成する 4 つの方法
newCachedThreadPool(); キャッシュ可能なスレッド プール
newFixedThreadPool(); 長さを固定して、スレッドの最大数を制限できます。
newScheduledThreadPool(); をスケジュールできます。
newSingleThreadExecutor();
実際の最下層は、ThreadPoolExecutor コンストラクターのカプセル化スレッド プールに基づいています。
スレッドプールの核となる原理の分析
LinkedBlockingQueue
生産者と消費者モデル
アリババがエグゼキューターの使用を推奨しない理由
LinkedBlockingQueue 無制限キューの基礎的な使用では、メモリ オーバーフローが発生する傾向があります
スレッド プールのキューがいっぱいの場合の対処方法
拒否ポリシー
AbortPolicy はタスクを破棄し、ランタイム例外をスローします
CallerRunsPolicy 実行タスク
DiscardPolicy 無視すると何も起こりません
DiscardOldestPolicy はキューからキックされ、最初にキューに入ります。
RejectedExecutionHandler インターフェイスを実装し、プロセッサをカスタマイズする
スレッドプールパラメータを適切に構成する方法
CPU を集中的に使用する
最適なスレッド数 = CPU コア数または CPU コア数 ±1
集中的な
最適なスレッド数 = ((スレッド待機時間スレッド CPU 時間)/スレッド CPU 時間) * CPU 数
ThreadPoolExecutor に基づいてスレッド プールをカスタマイズする方法
FutureTask のソース コードの解釈
LockSupport に基づいた FutureTask の実装
Wait/Notifyに基づいたFutureTaskの実装
ForkJoin のソース コードの解釈
プログラミングの同時開発
仕事盗みの仕組み
フォーク結合の原則
スレッドローカルのソースコード解釈
スレッドローカルとは何ですか
スレッドローカルアプリケーションのシナリオ
1.Springトランザクションテンプレートクラス
2.httprequestを取得する
3.Aop 呼び出しチェーンはパラメーターを渡します
スレッドローカルと同期の違い
Threadlocal のメモリ リークを防ぐ方法
1.removeメソッドを呼び出す
2. set メソッドを使用すると、前のキーが null であったことがクリアされます。
マイクロサービス フレームワークのソース コードの解釈
SpringBoot のソースコードの解釈
SpringBoot 自動構成の仕組み
SpringBootコアモジュールのソースコード解釈
SpringBootコアアノテーションのソースコード解釈
SpringBoot 組み込みサーブレット コンテナのソース コードの解釈
SpringBootパッケージの導入と運用保守管理
サーブレット コンテナが Webflux を克服する方法
SpringCloudNetfilix (第一世代) コアコンポーネントのソースコード解釈
Eureka サービスの登録と検出のソース コードの解釈
エウレカサービスリニューアル（ハートビート）
Eureka サーバー側サービスの廃止
Eurekaサービスの自己保護メカニズム
サービスがダウンした場合はどうなりますか?
ローカルサービスは再試行メカニズムを使用します
ローカルサービスはアドレスフェイルオーバーを実装します
エウレカサービスオフライン通知
Eureka クラスターのデータ同期
Fegin 宣言型サービス呼び出しのソース コード解釈
Hystrix は、サービス電流制限、ダウングレード、サーキット ブレーカーのソース コード解釈を実装しています。
Zuul ユニファイド ゲートウェイ、サービス ルーティング、フィルターのソース コード解釈の詳細な説明
Config 分散構成センターのソース コード解釈
Sleuth 分散リンク追跡ソース コード解釈
リボンクライアント負荷分散の詳細説明とソースコード分析
SpringCloudAlibaba (第 2 世代) のソース コードの解釈
Nacos 分散登録センターのソース コード解釈
サービスの登録と検出
Nacos サービスの登録と検出のソース コードの解釈
サービス登録の原則
エウレカクライアント
JerseyClientを使用して登録リクエストを送信します
エウレカサーバー側
ConcurrentHashMap を使用してインターフェイス アドレスをキャッシュする
キーはサービス名です
値はキャッシュインターフェイスのアドレスです
Naocs サービスのハートビート検出と更新のソース コード解釈
デフォルトでは、EurekaClient は 30 秒ごとにハートビート更新パッケージを送信して時間を延長し、私がまだ生きていることを EurekaServer に伝えます。
デフォルトでは、EurekaServer は 60 秒ごとにキャッシュ アドレス内で期限切れのアドレスを検索し、それらを新しいコレクションに保存し、ランダム アルゴリズムを使用してそれらをクリアします。
Naocs サービスのオフラインとヘルスチェックのソースコード解釈
Nacos クラスター Raft 選挙アルゴリズムのソース コードの解釈
Nacos サーバーのロングポーリング処理メカニズム
Nacos クラスターノード間のデータ同期の原理
Nacos での AP モードのソース コードの解釈
Nacos における CP モードのソースコードの解釈
Nacos クラスター スプリット ブレイン ソリューション
分散構成センター
Nacos 分散構成センターの実装原理
Nacos で構成ファイルを動的に更新する方法
ゲートウェイ 新世代のマイクロサービス ゲートウェイのソース コード解釈
Gateway のパフォーマンスが Zuul のパフォーマンスよりも優れているのはなぜですか?
ゲートウェイ動的ルーティングのソースコード分析
ルートに一致する時間ルールを指定する
ルートに一致するクッキー
ヘッダー一致ルート
ホストマッチングルート
ルートに一致するリクエストメソッド
ルートに一致するリクエストパス
ゲートウェイフィルターのソースコード分析
カスタムゲートウェイフィルター
ゲートウェイは Nacos を統合して負荷分散を実現します
ゲートウェイは Sentinel を統合してゲートウェイ電流制限を実装します
Seata 分散トランザクション フレームワークのソース コードの解釈
分散トランザクションを解決するための Seata の 3 つのコア コンポーネントのソース コードの解釈
Seata は undo_log テーブルに基づいて SQL ステートメントを逆生成し、ソース コード解釈をロールバックします
Seata ブランチ トランザクション グローバル ロック設計のソース コードの解釈
GlobalTransactionalInterceptor ソース コードの解釈
TM が TC にリモート接続してグローバル トランザクション ID のソース コード解釈を取得する方法
Seata のフロントおよびリアミラーのソース コードの詳細なソース コード解釈
Seata と LCN ロールバックの違いは何ですか?
Canal 分散データ同期フレームワークのソース コード解釈
Canal全体のアーキテクチャのソースコード解釈
MySQL マスター/スレーブ レプリケーションの原理アーキテクチャ分析
Canal がノードから BinLog ファイルをサブスクライブするふりをする方法
EventParser と EventSink の設計原則
Canal の増分サブスクリプション/消費設計原則
Canal の高同時データ同期パフォーマンスの最適化
データ間の同期のレイテンシを短縮する方法
データ同期メッセージシーケンスの一貫性を回避する方法
データ同期損失の問題を回避する方法
センチネル
サービスの分離
電流制限アルゴリズム
トークンバケット
漏れのあるバケツ
セマフォに基づいて実装 セマフォ
カウントウィンドウを修正
スライディングテクノロジーウィンドウ
フロー制御ルール
スレッド
セマフォに基づいて実装 セマフォ
QPS
トークンバケット
ヒストリックス
フロー制御ルール
セマフォの分離
センチネルで
QPS
トークンバケット
スレッドプールの分離
欠陥は CPU リソースを消費します
電流制限方式
Google Guava(レートリミッター)
アリババセンチネル
Nginx
Redis lua は電流制限を実装します
電流制限はnginxまたはゲートウェイで行うことをお勧めします。
コレクションフレームワークのソースコードの解釈
Hash (ハッシュ関数) マップ コレクション フレームワークのソース コード解釈
基本知識
== と等しいの違いと基礎となる実装
イコールを書き換えてハッシュコードも書き換える理由
2進数と10進数の変換/^(排他的論理和演算)/>>>(符号なし右シフト)/&(AND演算)
低レベルの実装
JDK1.7
配列リンクリスト
ヘッド挿入法（同時拡張無限ループ問題）
コードの記述は簡単です
JDK1.8
配列リンクリスト赤黒ツリー
尻尾挿入法
ハイエンドのコード作成
赤黒ツリー変換
(配列容量 >= 64 & リンク リストの長さは 8 より大きい)
赤黒ツリー ノードの数 <6 変換リンク リスト
ハッシュ関数の計算
(h = key.hashCode()) ^ (h >>> 16)
i = (n - 1) & ハッシュ
時間の複雑さ
キーが競合しない
時間計算量は O(1) です
キーの競合
リンク リスト ストレージが O(N) です
赤黒ツリーのストレージは O(LogN)
ハッシュコードの衝突問題
ハッシュコード値は同じですが、コンテンツ値は異なります。
特徴：
配列の 0 位置を格納するためのキーは null です。
一方向リンクリストを使用して実装
順序付けされていないハッシュ ストレージ
パフォーマンスの最適化
HashMap でメモリ リークの問題を回避する方法
HashMap がハッシュ競合の可能性を減らす仕組み
HashMap でコレクションの初期値のサイズを合理的に指定する方法
HashMap の面接でよくある質問
Equals を書き直すときに HashCode メソッドを書き直す必要があるのはなぜですか?
HashMap がメモリ リークの問題を回避する方法
HashMap1.7 の最下層はどのように実装されていますか?
HashMapKey は null としてどこに保存されますか?
HashMap1.7 の最下層はどのように実装されていますか?
HashMapKey は null としてどこに保存されますか?
HashMap がハッシュ競合問題を解決する方法
HashMap が配列拡張問題を実装する方法
HashMap の最下層は単一リンク リストを使用しますか、それとも二重リンク リストを使用しますか?
キーに基づく HashMap クエリの時間計算量
HashMap1.7と1.8の違いは何ですか?
HashMap1.8におけるマルチスレッド展開の無限ループ問題を回避する方法
なぜ HashMap1.8 は赤黒ツリーを導入する必要があるのでしょうか?
荷重係数が 1 ではなく 0.75 なのはなぜですか
HashMap の最下層はどのようにしてハッシュ競合の可能性を減らすのでしょうか?
HashMap はどのようにして 10,000 個のキーを最も効率的に保存するのでしょうか?
HashMap の上位ビットと下位ビット、およびモジュロ演算の利点は何ですか?
キーをハッシュ値として使用するだけではなく、上位 16 ビットと XOR 演算を実行するのはなぜでしょうか?
HashMap ではハッシュ関数はどのように実装されていますか?
HashMap の最下層は順番に格納されていますか? <br>
LinkedHashMap と TreeMap の基礎となる層はどのように順序付けを実現するのでしょうか?
同時実行性が高い状況で HashMap を使用する方法
ConcurrentHashMap の基礎となる実装の原則
ConcurrentHashMap コレクション フレームワークのソース コードの解釈
基本知識
同期してロックする
セグメンテーション ロックの概念を理解する方法
CAS アルゴリズムと揮発性
基礎となる実装
JDK1.7
データ構造
配列セグメントのセグメンテーション ロック HashEntry リンク リストの実装
ロックの実装
ロック ロック CAS オプティミスティック ロック UNSAFE クラス
能力拡張の実施
複数セグメントの同時拡張をサポート
JDK1.8
データ構造
ノード配列を直接使用してデータを保存する
配列リンクリスト赤黒ツリー
ロックの実装
セグメントセグメントデザインのキャンセル
インデックスは競合せず、cas ロックを使用します
インデックスの競合は同期を使用します
能力拡張の実施
同時拡張をサポート
特徴: マルチスレッド、高効率をサポート、デフォルトで 16 セグメントに分割
特徴：
ConcurrentHashMap は null キーをサポートしていません
リストコレクションのソースコード分析
配列リストの基礎となる実装
データ構造
配列
時間の複雑さ
添字クエリの時間計算量 o(1)
拡大
膨張率はオリジナルの1.5倍
スレッドセーフではありません
長所と短所
追加や削除の効率は低く拡張が必要ですが、クエリの効率は比較的高いです。
ベクターの基礎となる実装
データ構造
配列
時間の複雑さ
添字クエリの時間計算量 o(1)
拡大
拡張はオリジナルの2倍です
スレッドの安全性
LinkedList の基礎となる実装
リンク リスト データ構造に基づいて、添字クエリの時間計算量 ()
データ構造
リンクされたリスト
時間の複雑さ
添字クエリの時間計算量 log2(n) 二分探索
スレッドセーフではありません
長所と短所
追加、削除、変更の効率は高いですが、クエリの効率は比較的低くなります。
分散アーキテクチャソリューション
インターネット マイクロサービスの冪等アーキテクチャの設計と実践
べき等設計とは何ですか?冪等な制作背景
クライアント応答タイムアウト
ビジネスの実行時間が非常に長い場合は、代わりに mq 非同期を使用することをお勧めします。
再試行ポリシー
サービス インターフェイスの冪等の問題の主な理由を解決する
データベースレベル
冪等性の理由をアーキテクチャレベルから分析する
ゲートウェイ層
インターフェース層
グローバルIDに基づいてビジネスロジックが実行されているかどうかを事前に問い合わせる
DB層
挿入型の一意の注釈制約
更新型楽観的ロック機構
グローバル ID は本当にインターフェイスの冪等性を保証しますか?
必ずしも必要というわけではありませんが、データベース レベルを考慮する必要があります
RPC インターフェースの冪等性を確保する方法
グローバルID
ロック機構 (効率が低いため推奨されません)
実際のビジネス シナリオに基づいた冪等設計を実装する
インターネット分散ロック アーキテクチャの設計と実践
分散ロックはどのようなシナリオで使用されますか?
スケジュールされたタスクのスケジューリングの冪等性の確保の問題
過剰販売の問題を防ぐフラッシュセールの保証
分散ロックの基本的な実装原理
再試行戦略
非常に迅速な業務遂行に適しています
タイムアウト制御
長寿命設計
生活を続ける際のデッドロックの問題を回避する方法
パフォーマンスの最適化
群れ効果を考慮する
高可用性
ブロッキングタイムアウトを設定する
ロックの粒度が減少しました
公平性
分散ロックの互換性テストと回復設計
分散ロック実装ソリューション
Zookeeper は分散ロックを実装します (CP モード)
本旨
一時ノード
パスの一意性
ウォッチャーイベント
特徴
cpモードを使用する
アドバンテージ
スプリットブレイン問題の先天的解決策 (半分以上のメカニズム)
より信頼性と安定性が向上
欠点がある
クラスター同期のデータ効率が低い
低性能
2 つの実装方法
同じ一時ノードに基づいて実装されます
群れ効果が起こる可能性がある
一時的な順次ノードに基づいて実装
群れの問題を回避する
一時連番ノード
現在のノードが最小ノードであれば、ロックが正常に取得されたことを意味します。
現在のノードが最小ノードでない場合は、前のノードをサブスクライブします
キュレーターフレームワーク分散ロック
ロックを取得
一時的な連続番号付けノードに基づく実装
一時的なシーケンス ノードを作成し、最も小さいノードがロックを取得します。
ブロック
自分で作成した現在の一時シーケンス ノードが最小ではありません。前のノードをサブスクライブします
ロックを解除する
仮連番ノードを削除する
面接の難しさ
zk マスター ノードはどのようにダウンし、どのような影響がありますか?
ZK の再選出が発生し、ZK 環境全体が一時的に利用できなくなります。
zabプロトコルを考慮する必要がある
最初に zxid を比較し、次に myid を比較します
zk クライアントのデッドロック問題を回避する方法
ZKサーバーがダウンしています
zk クライアントはブロッキング タイムアウトを設定します
zk のダウンタイムを監視した後、アクティブにウェイクアップされます。
zk クライアントがダウンしています
zk の固有の特性により、デッドロックの問題が回避され、ロックが積極的に解放されます。
他の zk クライアントがブロッキング タイムアウトを設定する
ロックを取得した JVM はロックを解放しません。
寿命延長の回数を制御し、複数回の寿命延長後に積極的にロックを解放すると、トランザクションはロールバックされます。
Redis は分散ロック (AP モード) を実装します。
本旨
Setnx は分散ロックを実装します
ロックを取得
複数の jvm を同時に setnx すると、最終的には 1 つの jvm だけが成功します。
ロックを解除する
キーを削除する
特徴
APモードを使用する
アドバンテージ
高い同時実行性をサポート
効率は大丈夫です
非同期同期データ方式の使用
欠点がある
先天性スプリットブレイン問題 (Redis クラスターには多数派メカニズムがありません)
あまり安定していない
Redis の先天的なシングルスレッドにより、setnx スレッドの安全性の問題が確実に発生する可能性があります
レディソンフレームワーク
ロックを取得
luaスクリプトを使用してハッシュキーを作成する
ロックを解除する
キーを削除する
長寿命設計
デフォルトでは、ウォッチドッグ スレッドはキーの有効期限が切れることを防ぐために 10 秒ごとにアクティブ化されます。
面接の難しさ
クライアントのデッドロックの問題を回避する方法
期限切れのキーを設定する
寿命延長の回数を制限する
トランザクションのロールバック
キーの有効期限が切れていますが、ビジネスはまだ実行されていません。どうすればよいですか?
長寿命設計
全体的な寿命の延長 (推奨されません)
段階的な寿命延長 (推奨)
デフォルトでは、キーの期限切れを防ぐために、寿命は 10 秒ごとに事前に更新されます。
デッドロックの問題によるライフ更新の回数を制限するために、ライフを複数回更新します。
トランザクションのロールバック
積極的にロックを解除する
Redis クラスターでマスター ノードがダウンした場合はどうすればよいですか? <br>
RedLock レッド ロック アルゴリズムを使用する
Redis クラスターではマスターとスレーブの区別はありません
クライアントは、複数の Redis サーバーの setnx 要件の半分以上を満たし、ロックを正常に取得します。
クライアントがロックの取得にかかる合計時間 > キーの有効期限を設定した場合、ロックは自動的に解放されます。
このアルゴリズムは実際に ZK を使用して分散ロックを実装します。
インターネット分散トランザクション アーキテクチャの設計と実践
分散トランザクションの背景
単一プロジェクトの複数のデータソース
jta Atomikos は分散トランザクションを解決します
RPC リモート呼び出しインターフェイス
分散トランザクション整合性プロトコル
強力な整合性プロトコル
クラスタ内では、各ノードのコピーデータが一貫している必要があります
弱い整合性プロトコル
クラスター内では、一部のノード レプリカに一貫性のないデータが含まれることが許可されています
最終的な整合性プロトコル
短期間のデータ遅延は許容されますが、最終的にはデータの一貫性が必要になります
分散トランザクション設計のアイデア
ベース理論とCAP理論
基礎理論
基本的にご利用いただけます<br>
柔らかい状態
最終的な整合性
キャップ
基礎理論
一貫性(C)
クラスタ内では、各ノードのコピーデータが一貫している必要があります
在庫状況(A)
クラスター内の一部のノードに障害が発生した後でも、クラスター全体はクライアントの読み取りおよび書き込みリクエストに応答できますか?
パーティショントレランス (P)
パーティション フォールト トレランス (P) は、主にネットワークの変動によって引き起こされる不可避のエラーを表しており、これら 3 つのモードを同時に実現することはできないため、現在は CP モードと AP モードの 2 つのモードのみです。
モード選択
CP (データの一貫性の保証)
可用性は保証されません
Ap (可用性を保証)
ただし、各コピーのデータの一貫性は保証できません<br>
比較解析
ナコス
Nacos は、バージョン 1.0 以降、CP/AP 混合モード クラスタをサポートします。デフォルトでは、AP モードです。
ユーレカ
APモード
動物園の飼育員
CPモード
登録センターはAPモードを推奨しています
柔軟かつ厳格な事務
厳格なトランザクションは ACID 理論を満たします
柔軟なトランザクションは BASE 理論を満たします (基本的に利用可能、結果的に一貫性がある)
2PC/3PC/TCC<br>
分散トランザクション解決フレームワーク
LCN は分散トランザクションの問題を解決します
Seata は分散トランザクションの問題を解決します
MQ は分散トランザクションの問題を解決します
TCC は分散トランザクションの問題を解決します
分散トランザクションの問題を解決するためにコールバック メソッドを再試行します<br>
インターネット分散タスク スケジューリング アーキテクチャの設計と実践
従来のスケジュールされたタスクの欠点
CPUリソースを消費する
非デカップリングはビジネス ロジックに影響を与える
分散タスク スケジューリングの核となる設計アイデア
ログのトレーサビリティ
柔軟な伸縮
並列スケジューリングのサポート
高可用性戦略
障害対応戦略
動的シャーディング戦略
分散タスクスケジューリングフレームワーク
XXLJob ソースコードの解釈
ElasticJob ソースコードの解釈
mysql および Redis データ整合性プロトコル
解決
1. mysql データを更新し、Redis キャッシュを手動でクリアします
利点: 遅延が少ない
短所: 分離されていない
2. mysql データを更新し、mq 非同期の形式でデータを Redis に同期します。
利点: デカップリングの実装、補償戦略の再試行、インターフェイスの応答の改善
短所: 遅延が大きい
3. mq 非同期形式 (canal フレームワーク実装) と組み合わせた MySQLBinLog へのサブスクライブに基づいてデータを Redis に同期します。
利点: より多くのデカップリング、リトライ補償戦略、改善されたインターフェイス応答
短所: レイテンシーがますます高くなっています
核となるデザインのアイデア
最終的な整合性の考え方は、一時的なデータの不一致は許容されるが、最終的なデータは一貫していなければならないということです。
二重書き込み整合性プロトコルの原理
最初にキャッシュを削除してからデータベースを更新します (推奨されません)
二重削除を遅らせる必要がある、二度削除する
初めてキャッシュを削除する
2 回目は、他のスレッドの同時実行を避けるために、ダーティ リード データを Redis に同期するため、数秒 (2 番目のスレッド ビジネスが古いデータを Redis に更新する時間) 遅れてキャッシュを削除します。
まずデータベースを更新してからキャッシュを削除します
これを mq と組み合わせて、メッセージ シーケンスの一貫性を確保し、キャッシュの削除が成功する必要があります。
DoubleWrite 整合性プロトコル
二重書き込みとは何ですか
最初にデータベースを更新し、次にキャッシュを更新します
どのような問題が発生するか
同時実行状況では、複数のスレッドが同時に書き込みを行い、別のスレッドがダーティ読み取りデータをキャッシュに書き込む可能性があります。
ダーティリードを解決する方法
mysql トランザクションの行ロック メカニズムを使用すると、複数のスレッドが同時に操作を書き込みます。最終的には、行ロックを取得した後、Redis が正常に同期される必要があります。他のスレッドのみが解放されます。スレッドは書き込むことができます
分散ロックを使用して実装 (推奨されません。mysql 行ロックに基づいて直接実装できます)
カナルフレームの設計原理
canal は、mysql と Redis の間のデータ同期の原理を解決します
1.canal は自身を mysql スレーブ ノードとして偽装し、mysql マスター ノードの binlog ファイルをサブスクライブします。
2. mysql マスターノードの binlog ファイルが変更されると、binlog ファイル<br> が運河サーバーに送信されます。
3. 運河サーバーは binlog ファイルを json 形式に変換し、それを運河クライアントに送信します。
4. カナルクライアントはデータを Redis/ES に同期します。
運河の同期モード
tcp (低効率)
カフカ (推奨)
カフカデータ同期を統合するカナルの効率を向上させる方法
MQ トピック モードの統合
単一トピックと単一パーティション (グローバル binlog の厳密な順序)
マルチトピックの単一パーティションにより、テーブルレベルの順序付けが保証されます。
同じテーブル名は同じパーティションに配置され、最終的には同じコンシューマーによって使用されます。
ハッシュ モードと組み合わせた単一トピック、マルチトピック マルチパーティション
メッセージシーケンスの一貫性の問題を解決する方法
複数のパーティションを設定し、主キー ID などのテーブル内のフィールドに基づいてハッシュを計算します。同じ ID が同じパーティションに配置され、同じコンシューマーによって使用されます。
mysql と redis の間のデータの同期に遅延はありますか?
データ同期プロセス中に短い遅延が発生しますが、これは正常な現象です。強い一貫性を実現し、最終一貫性の考え方に従うことは困難です。
分散メッセージミドルウェアの原理
MQの基本概念モデル
同期と非同期
トラフィックピーククリッピング
スケーラビリティ/デカップリング
バッファリング/回復可能性
生産者と消費者
MQ の共通ソリューション
MQ がメッセージの蓄積を回避する方法
消費者率の向上（クラスター）
コンシューマはメッセージをバッチで取得します
MQ はコンシューマによる繰り返しの消費をどのように回避するか (冪等の問題)
グローバルIDのビジネスシナリオで一意性を確保
MQ はメッセージが失われないことをどのように保証しますか?
メッセージ確認の仕組み
持続性
メッセージ確認応答
MQ がメッセージ シーケンスの一貫性を保証する方法
同じコンシューマとキューをバインドする
MQ プッシュおよびプル アーキテクチャ モデル
生産者が消費結果を得る方法
グローバル ID を非同期的に返し、フロントエンドは ajax を使用して定期的にアクティブにクエリを実行します。
主流の MQ フレームワーク
うさぎmq
建築的思考
Rabbitmq 管理プラットフォーム センター
仮想ホスト
メッセージキューを別のチーム開発パスに保存する
交換
ルート配布メッセージ
ルーティングキー
RabitMQ キュー モデル
シンプルモード<br>
仕事モード
ブロードキャストモード---ファンアウト
ルーティングモード --direct
テーマモード --topic
RabitMQ 4 つのスイッチ タイプ
ダイレクトエクスチェンジ（ダイレクトスイッチ）
ファンアウト交換
話題の交換
ヘッダー交換
RabbitMQ のよくある面接の質問
RabbitMQ がメッセージが失われないことを保証する方法
プロデューサー
プロデューサがメッセージを MQ サーバーに正常に配信することを確認します。
Ackメッセージ確認メカニズム（確認）
同期または非同期フォーム
トランザクションメッセージ
消費者
消費手動受け取りモード
自動署名 (非推奨)
手動署名 (推奨)
MQ サーバー側メッセージの永続性
RabbitMQ デッドレターキュー
メッセージは MQ に配信され、有効期限が切れています。
キューコンテナがいっぱいです
コンシューマーが複数のメッセージの消費に失敗した場合、そのメッセージはデッドレターキューに転送されます。
RabbitMQ メッセージの自動再試行メカニズム
何度試しても失敗する場合はどうすればよいですか?
配信不能キューに移動
スケジュールされた補正または手動補正のログ テーブルに記録します。
消費者の冪等性の問題を回避するにはどうすればよいでしょうか?
グローバルIDのビジネスシナリオで一意性を確保
カフカ
Kafka コア アーキテクチャ設計モデル
ブローカー (MQ サーバー側)
トピックス（テーマを業務別に分類）
Partiiton (パーティションストレージメッセージ)
プロデューサー
消費者
消費者グループ
レプリカ（レプリカ機構）
オフセット（消費実績）
Kafka が高い同時実行性をサポートできる理由
ストレージ構造レベル
メッセージは帯域幅送信を削減するために圧縮されます
Kafka パーティション パーティション ストレージ構造モデル
.log ストレージ メッセージ ファイル
.index はメッセージのインデックスを格納します。
.timeIndex、時間インデックス ファイル
分割保存ログ（分割ファイル）
スパース インデックスを使用してメッセージの物理的な場所を検索します (メッセージごとにインデックスは作成されません)。
利点: スペースの節約
メッセージは保存された後、正常に使用された後すぐには削除されません。メッセージはオフセットに基づいて取得されます (ログ クリーニング戦略の構成を検討する必要があります)。
Javaアプリケーションレベル
プロデューサー
プロデューサーはメッセージをバッチで配信します (バッファー プール設計)
消費者
コンシューマはメッセージをバッチ (複数のオフセット) で取得します。
パーティションごとに 1 つのコンシューマ (スケーラビリティ)
Linuxカーネルレベル
シーケンシャルな読み取りと書き込みを使用する
ゼロコピーメカニズムを使用する
sendfile mmap ユーザーモードとカーネルモードのマッピング
データをコピーするために CPU は必要ありません
ユーザーモードとカーネルモード間の切り替え回数を減らす
ページ キャッシュを使用して読み取りと書き込みを改善する
ディスクのブラッシングの問題を考慮する必要がある
Kafka がメッセージの信頼性を保証する方法
レプリケーション
ISR レプリカの信頼性の高いメカニズム
パーティション内のレプリカの選択
HW ハイウォーターマーク: 消費者が消費できる最大オフセット
LEO キュー内の最大オフセット値
プロデューサーがメッセージ確認応答を配信します
0 はプロデューサーが待機しないことを意味します (メッセージが失われる可能性があります)
1 は、プロデューサーが待機中で、リーダーがディスクをフラッシュしていることを意味します (デフォルト構成を推奨)
-1 は、プロデューサーがすべてのノードが同期されるまで待機する必要があることを意味します。
Kafka の選挙原理コントローラーの原理
Zookeeper の一時ノードに依存して選挙を実装する
消費者がオフセットを手動で送信する
Kafka は指定されたオフセットを持つメッセージをどのように見つけますか?
1. セグメントセグメントファイルをオフセットに基づいて検索（二分探索）
2. インデックス ファイル (スパース インデックス) にアクセスし、対応する物理的な保存場所を見つけます。
3. 物理的なアクセス場所に従って、ログにアクセスして、物理的に対応するメッセージを見つけます。
メッセージインデックス値を見つける
物理メッセージを直接返す (時間計算量 o(1))
メッセージインデックス値が見つかりませんでした
順番に検索 (時間計算量 o(N))
Kafka のパフォーマンスの最適化
プロデューサー
プロデューサのメモリ バッファ サイズ
再試行ポリシー「retries」および「retries.backoff.ms」
このパラメータは、再試行の回数と間隔を設定します。
確認メカニズム: acks バランスをとるために 1 に設定することをお勧めします
消費者
コンシューマパーティションの数
コンシューマは複数のオフセットに基づいてメッセージをバッチで取得します
消費者が手動でオフセットを提出できるようにする
ブローカー (MQ サーバー側)
ログ保持ポリシーの構成
ログデータファイルのフラッシュ戦略
レプリカ複製構成
ネットワークとIOスレッド構成の最適化
MySQL の実用的なパフォーマンスの最適化
MySQLのパフォーマンスの最適化
MySQL アーキテクチャと実行プロセスの原則
SQL ステートメントの実行方法
組み込みのクエリキャッシュ
文法と語彙の解析
セマンティックプロセッサ
オプティマイザー/実行計画
クエリ実行エンジン
InnoDb のメモリ構造とディスク構造
バッファ設計
バッファプール機能
メモリ バッファがいっぱいです。どうすればよいですか?
バッファプールのサイズを設定するにはどうすればよいですか?
MySQL のレイテンシの問題とデータ フラッシュ戦略
MySQL の抽象データ ページ単位を理解する方法
ディスク上のデータ ページとキャッシュ ページはどのように対応しているのでしょうか?
キャッシュページに相当する記述情報とは何ですか？
マシン構成に基づいてバッファー プールを適切に設定する方法
運用環境ではバッファプールにどれくらいのメモリを設定する必要がありますか?
合計サイズ = 2 倍 (チャンク サイズ * バッファー プールの数)
MySQL の基礎となる通信プロトコルの原理
リナックス
TCP/IPソケット
mysqlメッセージ
スリーウェイハンドシェイク認証
Unixソケット
ウィンドウズ
名前付きパイプ
メモリの共有
MySQLの基礎となるモジュール部
初期化モジュール
コアAPI
ネットワークインタラクションモジュール
クライアントとサーバーの対話プロトコル モジュール
ユーザーモジュール
アクセス制御モジュール
接続管理、接続スレッド、およびスレッド管理
クエリ解析および転送モジュール
クエリオプティマイザーモジュール
ロギングモジュール
ストレージ エンジン インターフェイス モジュール
MySQL インデックスの基本的な実装原理
インデックスデータ構造モデル
ハッシュ表
二分探索木
赤黒い木
バランスの取れたマルチフォーク検索ツリー
Bツリーズ
インデックスにはどのようなカテゴリがありますか?
全文インデックス
主キーインデックス
複合インデックス
一意のインデックス
innodbとmyisamの違い インデックスの違い<br>
MySQL インデックスの確立と使用の基本原則
MySQL トランザクションの基礎となる原則
Spring宣言とプログラミングトランザクションの違い
トランザクションが開始されるだけでコミット/ロールバックが行われない場合、どのような問題が発生しますか?
mysql マルチバージョン制御 MVCC 原理
MySQL トランザクション分離レベル
反復可能な読み取り
読み取りコミット
コミットされていない読み取り
連載化
MySQL のロックとロックの解放の原則
行ロック、テーブルロック、ページロック
悲観的ロック/楽観的ロック
ギャップロック
ギャップロックとは何ですか？
ギャップ ロックが RR 分離レベルでのファントム読み取りを防ぐ主な理由なのはなぜですか?
主キーインデックス/一意インデックス 現在の読み取りにギャップロックが追加されますか?
範囲クエリを通じてギャップ ロックを追加するかどうか
検索条件が存在しない場合、現在の読み取りにギャップが追加されますか?
デッドロック解析の原理
2段階ロック
なぜデッドロックが発生するのでしょうか?
MySQLUndo ログの基本原理
アンドゥログとリドゥログの違い
UndoLog はトランザクションのアトミック性の原則を実装します。
RedoLog はトランザクション永続性の原則を実装します
MySQL の実用的なパフォーマンスの最適化
SQL の遅いクエリの分析と解決策
MySQL の低速クエリを有効にする方法
実行計画の原則の解釈を説明する
id: 列が大きいほど実行優先度が高くなります。id が同じ場合は上から順に実行されます。id が NULL の場合は最後に実行されます。
select_type: クエリのタイプを示します。
table: 行によってどのテーブルがアクセスされているかを説明します。
型列
システム
定数
eq_ref
参照
<p class="MsoNormal"><b><span style="font-family: "Times New Roman"; font-size: 10.5pt;">範囲 </span></b></p>
索引
全て
エクストラとは追加の情報を意味します
SQL とインデックスの最適化の原則
インデックスの失敗を防ぐために、最適な左のプレフィックス ルールに従ってください。
テーブルバッククエリを避けるためにカバーインデックスを使用してみてください。
ファイルソートを回避するために、ソートは最適な左プレフィックス方式に従います。
最小タイプは範囲範囲クエリ レベルを満たす
ID 条件で OffSet をフィルタリングするか、サブクエリで ID の関連付けを特定するページネーションの最適化
結合テーブル クエリは、大きなテーブル データを駆動するために小さなテーブルを最適化します。3 つ以上のテーブルに対して結合を使用することは禁止されています。
ファジーと同様に、最良の左プレフィックス ルールに従うか、複合インデックス ファジー クエリを使用します。
MySQL 構成の最適化の原則
ストレージエンジンとテーブル構造の最適化
Alibaba 開発マニュアル 観点から MySQL を最適化する
MySQL テーブルとデータベース
単一テーブルが最大サイズに達すると、テーブルとデータベースに分割されます。
水平分割と垂直分割の違い
サブテーブルとサブデータベース戦略
剰余/範囲モジュロ
範囲ごとに分割
日付ごとに分割
月ごとに分割
列挙値によるシャード
バイナリモジュロ範囲スライス
一貫したハッシュシャーディング
ターゲットフィールドプレフィックスで指定されたパーティション<br>
プレフィックス ASCII コードと値に従ってモジュロ範囲を分割します。
開発者のカスタマイズ
よくある問題
テーブルとデータベースのパーティション分割後にクエリを実行する利点と欠点は何ですか?
テーブルとデータベースを分割した後にページング クエリを実装する方法
テーブルとデータベースを分割した後にテーブル結合クエリを実装する方法
MyCat が推奨されない理由
Nettyの詳細なソースコード解釈
ネットワークモデルの概念的基礎
TCP/IP 5層アーキテクチャモデル
アプリケーション層
トランスポート層
ネットワーク層
データリンク層
物理層
ソケットネットワークプログラミング
TCPプロトコル
UDPプロトコル
URLアドレスを入力してIPアドレス原理を解決する方法
HTTP プロトコルの基礎となる原則
HTTPS プロトコルのリクエストとレスポンスの原則
HTTPS および SSL/TLS の原則
httpプロトコルとソケットの違い
IOモデルの原理
ブロッキング I/O モデル
ノンブロッキングI/Oモデル
多重化I/Oモデル
信号駆動型 I/O モデル
非同期I/Oモデル
NIOとBIOの違い
AIOの基本原則
BIO から NIO への進化
ストリーム指向とバッファ指向
ブロッキングとノンブロッキング
NIO 実装原理 (オペレーティング システム カーネル)
核心概念
カーネルバッファ
プロセスバッファ
Linuxカーネル
選択する
時間計算量は O(n) で、ファイル記述子の監視には一定の制限があります。
世論調査
時間計算量は O(n) で、ファイル記述子のリスニングに制限はありません。
エポール
時間計算量は O(1) で、ファイル記述子のリスニングに制限はありません。
Netty ソースコードの解釈
Nettyの一般的な使用シナリオ
RPC フレームワーク
Tomcatサーバー
オンラインゲーム
NIO アーキテクチャの原則
バッファ
セレクタ
通路
Netty の高性能設計
非同期ノンブロッキング通信
ゼロコピー/メモリプール
MMAP書き込み
ファイルを送信
考慮すべきこと:
CPUのコピー数を減らす方法
ダイレクトメモリ DMA コピーの原理
カーネルスイッチの数を減らす方法
効率的な Reactor スレッドモデル
シングル リアクター シングル スレッド
単一リアクターのマルチスレッド化
リアクトルマスタースレーブモデル
ロックフリーシリアル設計コンセプト
シリアル化フレームワークのサポート
Netty ソースコードの解釈
Netty スレッド モデルとソース コード分析
高性能シリアル化プロトコル protobuf とソース コード分析
スティッキーパケットアンパッキング現象と解決策、コーデックソースコード解析
ダイレクトメモリとNettyゼロコピーの詳細説明
Nettyフレームワークの実践
Netty 手書き RPC フレームワークに基づく (模倣性の高い Dubbo)
バックギャモン ゲームの Netty 手書きマルチプレイヤー オンライン バージョンに基づいています
Netty 手書き Web サーバー (模倣性の高い Tomcat) に基づく
Linux システムのカーネル原理の分析
Linuxカーネルの準備作業
Linux カーネル アーキテクチャの簡単な分析
Linuxアーキテクチャとカーネル構造の違い
Linux主導のプラットフォームメカニズム
Linux カーネル アーキテクチャ
Spring System Frameworkのソースコードの解釈
Spring5 のソースコードの解釈
SpringMVC ソースコードの解釈
SpringBoot のソースコードの解釈
新しい小売電子商取引プロジェクト
建築設計のアイデア
新しい小売コンセプト<br>
技術アーキテクチャ計画
スプリングブーツ
SpringCloudアリババ
中間設計
テクニカルセンター
ビジネスセンター
組織センター
クラウドコンピューティング
SaaS (サービスとしてのソフトウェア)
PaaS（プラットフォームサービス）
IaaS（インフラストラクチャサービス）
Devops と K8S の運用および開発の統合
毎時
サービス追跡を実装する
監視アラーム
フロントエンドとバックエンドの分離
フロントエンド-----vue は ajax テクノロジーに似ており、フロントエンド エンジニアによって実装されます。
バックエンド ------ インターフェース形式 バックエンドエンジニアが Java を実装
インフラストラクチャサービスの構築
Nacos サービス登録センター/構成センターの展開
エンタープライズレベルの Maven プライベートサーバーを構築する
マイクロサービスチームでRPCインターフェースの呼び出しを実装する
APIインターフェース仕様プロトコルを定義する
エンタープライズレベルのコードウェアハウス管理プラットフォームを構築する
po/do/vo/dto/bo アプリケーションを選択
目的は、RPC によって送信されるデータのセキュリティを確保することです。
アプリを選択
DO (Data Object): データベースのテーブル構造に 1 対 1 で対応し、DAO 層を通じてデータ ソース オブジェクトを上向きに送信します。
DTO (Data Transfer Object): データ転送オブジェクト、サービスまたはマネージャーによって外部に転送されるオブジェクト
BO (ビジネスオブジェクト): ビジネスオブジェクト。サービス層が出力するビジネスロジックをカプセル化したオブジェクト
AO (アプリケーション オブジェクト): アプリケーション オブジェクト。 Web層とサービス層の間の抽象再利用オブジェクトモデル
VO (View Object): 表示レイヤー オブジェクト。通常は Web によってテンプレート レンダリング エンジン レイヤーに送信されるオブジェクトです。
会員センターのデザイン
ログインインターフェースの実装
セッションを使用しない理由
セッションが JVM サーバーに保存される場合は、ノード クラスターの同期の問題を考慮する必要があります。
トークンの実装方法
実施原則
ユーザーIDとしてRedisのキー値としてトークン(UUID)をランダムに生成します。
トークンをクライアントに返すと、クライアントはトークンを渡すたびにインターフェイスを呼び出します。
長所と短所
アドバンテージ
パラメータの信頼性を非表示にする
欠点がある
Redis クエリを実行する必要がある
JWTの実装
コンポーネント
ヘッダー(ヘッダー)
ペイロード(ペイロード)
サイン
長所と短所
アドバンテージ
ユーザーデータをサーバーに保存する必要がないため、サーバー側の負担が軽減されます。
軽量、json スタイルは比較的シンプル
クロスランゲージ
欠点がある
有効期間を更新できません
jwtを破棄できません
Jwtでログアウトを実装する方法
ブラウザの Cookie をクリアします (ただし、サーバーはまだ存在します)。
時間を少し短めに設定することをお勧めします
マルチスレッドとスレッドプーリングを統合する
ログイン後に送信される電子メール、テキスト メッセージ、クーポンをマルチスレッドで処理することで、インターフェイスの応答効率が向上します。
大規模なプロジェクトでは、サーバーの CPU リソースを削減するために、mq の非同期で時間のかかる処理が使用されます。
SSOシングルサインオン
ウェブフォーム
Cookieに基づいて実装されます
フロントエンドとバックエンドの分離
トークンまたはjwtに基づいて実装されます
よくある問題
実際のクライアントのIP情報を取得する方法
nginxでユーザーの実際のIPを設定することによって
フロントエンドとバックエンドの分離というクロスドメインの問題を解決する方法
jsonp を使用しますが、ポストリクエストはサポートしません (非推奨)
SpringMVC @CrossOrigin アノテーションを使用する (推奨)
ゲートウェイに基づいてクロスドメインの問題を解決する (推奨)
Nginx ベースのさまざまなプロジェクトに基づくアクセス (推奨)
共同ログインの実装
oauth2オープンプロトコル
1. appidに基づいて認可リンクアドレスを生成します。
2. 認証コードを取得する
3. 認可コードに基づいて accessToken を取得します
4. 認可コードに基づいてユーザー情報を取得する
分散型ソリューション
従来の収集ログの欠点
各サーバー上のログを検索するには tail を使用します
解決
aop elk kafka は分散ログ収集を実装します
Elk が Kafka を追加する必要がある理由
各 Logstash インストールの運用とメンテナンスのコストを削減します。
予防
AOP は、収集されたログを同時キューにキャッシュし、非同期の別のスレッドで Kafka にログを配信します。
集約された支払いの設計
支払いアーキテクチャのプロセス
署名方法の検証
RSA非対称暗号化
MD5
コールバックメソッド
同期コールバック
サードパーティの支払いが成功すると、支払いブラウザのリダイレクトの形で販売者側にジャンプします。
非同期コールバック
サードパーティの支払いは、HttpClient と同様のテクノロジーを使用して販売者に通知を送信します
デザインパターン
戦略パターン
テンプレートメソッドパターン
よくある問題
同期コールバックと非同期コールバックがインターフェイスのセキュリティを確保する方法
同期コールバックはブラウザの形式でジャンプし、注文ステータスは変更されません。
非同期コールバックが署名を正常に検証したら、注文ステータスを変更するための冪等の問題に注意してください。
ユーザーが繰り返し支払うことを防ぐ方法
同じ注文番号がフォームからサードパーティの支払いに送信され、サードパーティの支払いは注文番号に基づいてグローバルな一意性を保証します。
ユーザーの支払いは正常に完了したが、注文ステータスがまだ未払いの場合はどうすればよいですか?
この現象は正常です。結果整合性の考え方により、Alipay インターフェイスを積極的に呼び出して、注文が支払われたかどうかを問い合わせることができます。<br>
ユーザーの支払い金額と注文金額が一致しない場合の対処方法
非同期コールバックでは、注文に基づいてユーザーの実際の注文番号とユーザーの支払い金額が一致しているかどうかがクエリされます<br>一致していない場合は異常な注文です。
どのタイプの支払表の金額フィールドが適していますか?
整数型の直接ストレージは後で要素に変換できます
10進数型
30 分の時間外労働で未払いの注文に対処する方法
MQ 遅延キューに基づいて実装 (推奨)
1. 注文が正常に行われた後、遅延キュー メッセージを MQ に配信します。
2. メッセージの有効期限が切れると、メッセージはデッドレターキューに転送されます。
3. デッドレターキューコンシューマはメッセージをリッスンし、注文ステータスが支払い済みかどうかを確認します。
Redis の期限切れキーに基づいて実装 (非推奨)
1. 注文が正常に完了したら、30 分の有効期限キーを Redis に設定します。
2. クライアントはキーの有効期限を監視するときに、注文ステータスが支払い済みかどうかを確認します。
3. 期限切れキーの監視を有効にするには、プレフィックスに注意し、別の Redis ライブラリをサブスクライブする必要があります。
よくある問題
ユーザーのカードは 30 分以内に支払います。注文ステータスの一貫性を確保するにはどうすればよいですか?
1. Alipay 注文をリダイレクトするタイムアウトを 30 分に設定します
2. 遅延キューは、31 ～ 35 分程度で Alipay インターフェイスをアクティブに呼び出し、注文番号に基づいて支払いステータスを確認します。
3. Alipay インターフェイスを呼び出した後も支払いが行われない場合、注文は時間がかかるとみなされます。
製品サービスシステムアーキテクチャ設計
高い同時実行性への耐性を実現する方法
フロントエンド層
最適化
動的および静的な分離アーキテクチャ
静的リソースサーバー
動的リソースサーバー
静的リソース圧縮
.min ファイルを生成する
CDNキャッシュ
近接の原則に従って訪問する
最終効果
帯域幅送信を減らす
インターフェース層
最適化
GC リサイクル stw の問題の数を減らすための JVM パラメーターの調整
マルチスレッド/MQ 非同期デカップリングの形式で時間のかかる操作を処理します。
Redis キャッシュを使用して DB アクセスの負荷を軽減する
テーブルとデータベースの分割/MySQL の大規模データのインデックスの最適化を検討する
最終効果
運用保守層
Docker または K8S を使用して展開を柔軟に拡張/縮小する
JavaSE
基本的な文法
データの種類
基本的なデータ型
数値型
整数 (バイト、ショート、整数、ロング)
浮動小数点数（float、double）
文字(文字)
非数値型
ブール値
参照データ型
クラス
インターフェース
配列[]
オブジェクト指向
コレクションフレームワーク
IOストリーム
反射機構
マルチスレッド化
JDBC
JavaWeb
ベース
サーブレット
JSP
フレーム
春5
Spring5 と SpringBoot の関係
SpringBeanのインジェクション方法
SpringBeanのインジェクション方法
パラメトリック コンストラクターの挿入プロパティ
p 名前空間インジェクション
null 値と特殊記号を挿入する
内部 Bean を注入する
外部 Bean を注入する
インジェクトカスケード割り当て
コレクション型のプロパティを挿入する
春の工場豆
SpringBean のライフサイクル
ステップ 1: リフレクション技術を使用してオブジェクトを初期化し、引数なしのコンストラクターを呼び出します。
ステップ 2: リフレクションを使用して set メソッドを呼び出し、プロパティに値を割り当てます。
実行の 3 番目のステップ: Bean のポストプロセッサーのプリメソッド
ステップ 4: オブジェクトで init メソッドを呼び出す
ステップ 5: Bean のポストプロセッサーのポストメソッド
ステップ 6: オブジェクトを破棄し、破棄メソッドを呼び出す
SpringBean スコープ
シングルトンオブジェクト
複数のインスタンス オブジェクト
SpringBean自動配線
SpringBean外部プロパティファイル
SpringBeanアノテーションフォーム
SpringBeanアノテーション起動メソッド
SpringBeanのアノテーション起動関数
SpringBean アノテーションのスキャン構成
オートワイヤードおよび修飾子の注釈
@リソースの使用状況
SpringBean AOP
AOPの基本概念
AOPの基本的な役割
静的プロキシと動的プロキシ
@AspectJ アノテーションの使用法
aop を使用してログを均一に出力する
SpringBeanのトランザクション操作
取引の分類
手動取引
プログラミングの問題
不倫の7つのコミュニケーション行動
PROPAGATION_REQUIRED (デフォルトの伝播動作)
現在のスレッドにトランザクションがある場合は、現在のトランザクションに参加します
現在のスレッドにトランザクションがない場合は、新しいトランザクションを作成します
PROPAGATION_SUPPORTS
現在のスレッドにトランザクションがある場合は、現在のトランザクションに参加します
現在のスレッドにトランザクションが存在しない場合は、トランザクション以外の<br>方法で実行されます。
PROPAGATION_MANDATORY
現在のスレッドにトランザクションがある場合は、現在のトランザクションに参加します
現在のスレッドにトランザクションがある場合は例外をスローします
PROPAGATION_REQUIRES_NEW
現在のスレッドにトランザクションが存在する場合、現在のトランザクションは一時停止され、新しいトランザクションが作成されます。
PROPAGATION_NOT_SUPPORTED
常に非トランザクション方式で実行される
PROPAGATION_NEVER
常に非トランザクション方式で実行され、現在のスレッドにトランザクションが存在する場合は例外がスローされます。
PROPAGATION_NESTED
現在のスレッドにトランザクションがある場合、トランザクションはネストされます
SpringMVC
マイバティス
休止状態
マイクロサービス
スプリングブート2.0
SpringBoot フレームワークを使用する必要がある理由
開発者がサードパーティのフレームワークを迅速に統合できるように支援します (原則: Maven 依存関係のカプセル化)
XML設定を削除し、アノテーションを完全に使用します（原則：Springシステムの組み込みアノテーションメソッド）
外部 Tomcat および内部実装サーバーは不要 (原則: Java 言語は組み込み Tomcat サーバーをサポートします)
SpringBoot と SpringCloud の違い
SpringCloud の依存関係と SpringBoot コンポーネント
SpringMVC を使用して Http プロトコル インターフェイスを作成する
Spring Cloud は完全なマイクロサービス ソリューション フレームワークです
SpringBoot 依存関係の概要
スプリングブート開始親、
スプリングブートスターターウェブ
@RestController ロール
コントローラーのすべてのメソッドは JSON 形式を返します
SpringBootの起動方法
@EnableAutoConfiguration
@ComponentScan
@SpringBootApplication
現在のパッケージまたはサブパッケージ内のすべてのクラスをスキャンできます
SpringBoot は静的リソース アクセスを統合します
テンプレートエンジンフレームワークとは
SEO 検索に有益な Web のレンダリング
FTLテンプレートエンジンを統合
thymeleaf テンプレート エンジンを統合
SpringBootはデータソースを統合します
Jdbcテンプレート
マイバチ
冬眠する
SpringBoot 統合ホット デプロイメント
devtoolsツールを統合する
クラスローダーの実装
ロンボク島を統合する
SpringBoot統合構成ファイル
@value アノテーションを使用して構成ファイルを読み取る
yml形式を変換するプロパティ
@ConfigurationProperties
構成ファイルのプレースホルダーの使用法
複数の環境で異なる構成ファイルを統合する
ポートとコンテキストパスを変更する
SpringBoot統合ログフレームワーク
ログバック
ログ4j
aop を使用してログ情報を均一に出力する
SpringBoot のスケジュールされたタスク
スケジュールされたタスクの @Scheduled アノテーションを統合する
Quartz 式と組み合わせた時間指定された統合タスク
SpringBoot は非同期マルチスレッドを統合します
@Async無効化問題に注意
@Async はスレッド プールを統合します
グローバルキャッチ例外を統合する
リリースをパッケージ化して実行する
プロジェクトツール
港湾労働者
基本的な考え方
なぜ docker を使用する必要があるのか
Docker を使用する利点
コンテナと仮想マシンの違い
環境のインストール
Linux環境にdockerをインストールする
Win環境にdockerをインストールする
三大要素
画像ファイル
容器
倉庫
鏡の原理
Docker ダウンロードイメージの原理
Docker イメージの読み込み原理
ブートファイル
rootfs
ユニオンFS
クラウドアクセラレーションによるイメージ構成
Alibaba Cloud の高速化イメージ
ファーウェイクラウドアクセラレーションイメージ
HKUST 加速ミラー
Docker の一般的なコマンド
docker --help (ヘルプコマンド)
docker --version (バージョンの表示)
docker イメージ (イメージを表示)
docker search (画像検索)
docker pull (イメージをダウンロード)
最新 -----イメージ ファイルの最新バージョンをタグ付けします
ドッカーコンテナ
docker run (コンテナの起動)
docker start コンテナ ID を開始します
docker stop コンテナー ID
docker rm コンテナー ID
docker exec -it [コンテナID] bash (コンテナに入る)
docker logs --since 30m CONTAINER_ID (コンテナー ログの表示)
Docker Commit (現在のコンテナに基づいてイメージ ファイルに作成されます)
Docker データ ボリューム -v
よく使うソフトウェアをインストールする
トムキャット
docker run -p 8081:8080 -d tomcat:8
Nginx
docker run --name nginx81 -d -p 81:80
MySQL
docker create --name mysql3308 -e MYSQL_ROOT_PASSWORD=root -p 3308:3306 mysql:5.7
DockerFile の解析
DockerFileの記述仕様
DockerFile ディレクティブ
Dockerfileに基づいてspringbootプロジェクトをビルドする
Docker Compose
一般的なコマンドを作成する
docker-compose -h
ドッカー構成アップ
docker-compose ダウン
docker-compose ログ
docker-compose プル
dokcer-compose 構成
docker-compose の再起動
docker-compose の開始
テンプレートファイルを作成する
SpringBoot MySQL Nginx マイクロサービス プロジェクトをデプロイする
Docker可視化ツールの使用法
ポーテイナー
DockerUI
k8s
メタネイティブの概念
マイクロサービス
アプリケーション間の安定した通信
独立して展開/伸縮自在に拡張・縮小可能
開発
自動リリース パイプライン、Ci/CD ツール
実稼働環境を迅速に導入
開発と運用保守の一体化
継続的デリバリー
頻繁なリリース、迅速な納品、迅速なフィードバック、リリースのリスクの軽減
コンテナ化
マイクロサービスに最適なキャリア
デザインパターン
プロキシモード