tdd懶人瘦身油多少錢（Java后端架構(gòu)師技術(shù)圖譜）

前言歡迎工作一到五年的Java工程師朋友們加入我們，私信回復(fù)【資料】即可獲取我們提供免費(fèi)的Java架構(gòu)學(xué)習(xí)資料（里面有高可用、高并發(fā)、高性能及分布式、Jvm性能調(diào)優(yōu)、Spring源碼，MyBatis，Netty,Redis,Kafka,My

前言

歡迎工作一到五年的Java工程師朋友們加入我們，私信回復(fù)【資料】即可獲取我們提供免費(fèi)的Java架構(gòu)學(xué)習(xí)資料（里面有高可用、高并發(fā)、高性能及分布式、Jvm性能調(diào)優(yōu)、Spring源碼，

MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個(gè)知識(shí)點(diǎn)的架構(gòu)資料）

合理利用自己每一分每一秒的時(shí)間來學(xué)習(xí)提升自己，不要再用"沒有時(shí)間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個(gè)交代！

數(shù)據(jù)結(jié)構(gòu)

隊(duì)列

• 《java隊(duì)列——queue詳細(xì)分析》
• 非阻塞隊(duì)列：ConcurrentlinkedQueue(無界線程安全)，采用CAS機(jī)制（compareAndSwapObject原子操作）。
• 阻塞隊(duì)列：ArrayBlockingQueue(有界)、linkedBlockingQueue（無界）、DelayQueue、PriorityBlockingQueue，采用鎖機(jī)制；使用 ReentrantLock 鎖。
• 《linkedList、ConcurrentlinkedQueue、linkedBlockingQueue對(duì)比分析》

集合

• 《Java Set集合的詳解》

鏈表、數(shù)組

• 《Java集合詳解--什么是List》

字典、關(guān)聯(lián)數(shù)組

• 《Java map 詳解 - 用法、遍歷、排序、常用API等》

棧

• 《java數(shù)據(jù)結(jié)構(gòu)與算法之棧（Stack）設(shè)計(jì)與實(shí)現(xiàn)》
• 《Java Stack 類》
• 《java stack的詳細(xì)實(shí)現(xiàn)分析》
• Stack 是線程安全的。
• 內(nèi)部使用數(shù)組保存數(shù)據(jù)，不夠時(shí)翻倍。

樹

二叉樹

每個(gè)節(jié)點(diǎn)最多有兩個(gè)葉子節(jié)點(diǎn)。

• 《二叉樹》

完全二叉樹

• 《完全二叉樹》
• 葉節(jié)點(diǎn)只能出現(xiàn)在最下層和次下層，并且最下面一層的結(jié)點(diǎn)都集中在該層最左邊的若干位置的二叉樹。

平衡二叉樹

左右兩個(gè)子樹的高度差的絕對(duì)值不超過1，并且左右兩個(gè)子樹都是一棵平衡二叉樹。

• 《淺談數(shù)據(jù)結(jié)構(gòu)-平衡二叉樹》
• 《淺談算法和數(shù)據(jù)結(jié)構(gòu): 八 平衡查找樹之2-3樹》

二叉查找樹（BST）

二叉查找樹（Binary Search Tree），也稱有序二叉樹（ordered binary tree）,排序二叉樹（sorted binary tree）。

• 《淺談算法和數(shù)據(jù)結(jié)構(gòu): 七 二叉查找樹》

紅黑樹

• 《最容易懂得紅黑樹》
• 添加階段后，左旋或者右旋從而再次達(dá)到平衡。
• 《淺談算法和數(shù)據(jù)結(jié)構(gòu): 九 平衡查找樹之紅黑樹》

B，B+，B*樹

MySQL是基于B+樹聚集索引組織表

• 《B-樹，B+樹，B*樹詳解》
• 《B-樹，B+樹與B*樹的優(yōu)缺點(diǎn)比較》
• B+樹的葉子節(jié)點(diǎn)鏈表結(jié)構(gòu)相比于 B-樹便于掃庫，和范圍檢索。

LSM 樹

LSM（Log-Structured Merge-Trees）和 B+ 樹相比，是犧牲了部分讀的性能來換取寫的性能(通過批量寫入)，實(shí)現(xiàn)讀寫之間的。 Hbase、LevelDB、Tair（Long DB）、nessDB 采用 LSM 樹的結(jié)構(gòu)。LSM可以快速建立索引。

• 《LSM樹 VS B+樹》
• B+ 樹讀性能好，但由于需要有序結(jié)構(gòu)，當(dāng)key比較分散時(shí)，磁盤尋道頻繁，造成寫性能。
• LSM 是將一個(gè)大樹拆分成N棵小樹，先寫到內(nèi)存（無尋道問題，性能高），在內(nèi)存中構(gòu)建一顆有序小樹（有序樹），隨著小樹越來越大，內(nèi)存的小樹會(huì)flush到磁盤上。當(dāng)讀時(shí)，由于不知道數(shù)據(jù)在哪棵小樹上，因此必須遍歷（二分查找）所有的小樹，但在每顆小樹內(nèi)部數(shù)據(jù)是有序的。
• 《LSM樹（Log-Structured Merge Tree）存儲(chǔ)引擎》
• 極端的說，基于LSM樹實(shí)現(xiàn)的Hbase的寫性能比MySQL高了一個(gè)數(shù)量級(jí)，讀性能低了一個(gè)數(shù)量級(jí)。
• 優(yōu)化方式：Bloom filter 替代二分查找；compact 小數(shù)位大樹，提高查詢性能。
• Hbase 中，內(nèi)存中達(dá)到一定閾值后，整體flush到磁盤上、形成一個(gè)文件（B+數(shù)），HDFS不支持update操作，所以Hbase做整體flush而不是merge update。flush到磁盤上的小樹，定期會(huì)合并成一個(gè)大樹。

BitSet

經(jīng)常用于大規(guī)模數(shù)據(jù)的排重檢查。

• 《Java Bitset類》
• 《Java BitSet（位集）》

常用算法

• 《常見排序算法及對(duì)應(yīng)的時(shí)間復(fù)雜度和空間復(fù)雜度》

排序、查找算法

• 《常見排序算法及對(duì)應(yīng)的時(shí)間復(fù)雜度和空間復(fù)雜度》

選擇排序

• 《Java中的經(jīng)典算法之選擇排序（SelectionSort）》
• 每一趟從待排序的記錄中選出最小的元素，順序放在已排好序的序列最后，直到全部記錄排序完畢。

冒泡排序

• 《冒泡排序的2種寫法》
• 相鄰元素前后交換、把最大的排到最后。
• 時(shí)間復(fù)雜度 O(n2)

插入排序

• 《排序算法總結(jié)之插入排序》

快速排序

• 《坐在馬桶上看算法：快速排序》
• 一側(cè)比另外一次都大或小。

歸并排序

• 《圖解排序算法(四)之歸并排序》
• 分而治之，分成小份排序，在合并(重建一個(gè)新空間進(jìn)行復(fù)制)。

希爾排序

TODO

堆排序

• 《圖解排序算法(三)之堆排序》
• 排序過程就是構(gòu)建最大堆的過程，最大堆：每個(gè)結(jié)點(diǎn)的值都大于或等于其左右孩子結(jié)點(diǎn)的值，堆頂元素是最大值。

計(jì)數(shù)排序

• 《計(jì)數(shù)排序和桶排序》
• 和桶排序過程比較像，差別在于桶的數(shù)量。

桶排序

• 《【啊哈！算法】最快最簡單的排序——桶排序》
• 《排序算法（三）：計(jì)數(shù)排序與桶排序》
• 桶排序?qū)0,1)區(qū)間劃分為n個(gè)相同的大小的子區(qū)間，這些子區(qū)間被稱為桶。
• 每個(gè)桶單獨(dú)進(jìn)行排序，然后再遍歷每個(gè)桶。

基數(shù)排序

按照個(gè)位、十位、百位、...依次來排。

• 《排序算法系列：基數(shù)排序》
• 《基數(shù)排序》

二分查找

• 《二分查找(java實(shí)現(xiàn))》
• 要求待查找的序列有序。
• 時(shí)間復(fù)雜度 O(logN)。
• 《java實(shí)現(xiàn)二分查找-兩種方式》
• while + 遞歸。

Java 中的排序工具

• 《Arrays.sort和Collections.sort實(shí)現(xiàn)原理解析》
• Collections.sort算法調(diào)用的是合并排序。
• Arrays.sort() 采用了2種排序算法 -- 基本類型數(shù)據(jù)使用快速排序法，對(duì)象數(shù)組使用歸并排序。

布隆過濾器

常用于大數(shù)據(jù)的排重，比如email，url 等。 核心原理：將每條數(shù)據(jù)通過計(jì)算產(chǎn)生一個(gè)指紋（一個(gè)字節(jié)或多個(gè)字節(jié)，但一定比原始數(shù)據(jù)要少很多），其中每一位都是通過隨機(jī)計(jì)算獲得，在將指紋映射到一個(gè)大的按位存儲(chǔ)的空間中。注意：會(huì)有一定的錯(cuò)誤率。 優(yōu)點(diǎn)：空間和時(shí)間效率都很高。 缺點(diǎn)：隨著存入的元素?cái)?shù)量增加，誤算率隨之增加。

• 《布隆過濾器 -- 空間效率很高的數(shù)據(jù)結(jié)構(gòu)》
• 《大量數(shù)據(jù)去重：Bitmap和布隆過濾器(Bloom Filter)》
• 《基于Redis的布隆過濾器的實(shí)現(xiàn)》
• 基于 Redis 的 Bitmap 數(shù)據(jù)結(jié)構(gòu)。
• 《網(wǎng)絡(luò)爬蟲：URL去重策略之布隆過濾器(BloomFilter)的使用》
• 使用Java中的 BitSet 類 和 加權(quán)和hash算法。

字符串比較

KMP 算法

KMP：Knuth-Morris-Pratt算法（簡稱KMP） 核心原理是利用一個(gè)“部分匹配表”，跳過已經(jīng)匹配過的元素。

• 《字符串匹配的KMP算法》

深度優(yōu)先、廣度優(yōu)先

• 《廣度優(yōu)先搜索BFS和深度優(yōu)先搜索DFS》

貪心算法

• 《算法：貪婪算法基礎(chǔ)》
• 《常見算法及問題場(chǎng)景——貪心算法》

回溯算法

• 《 五大常用算法之四：回溯法》

剪枝算法

• 《α-β剪枝算法》

動(dòng)態(tài)規(guī)劃

• 《詳解動(dòng)態(tài)規(guī)劃——鄒博講動(dòng)態(tài)規(guī)劃》
• 《動(dòng)態(tài)規(guī)劃算法的個(gè)人理解》

樸素貝葉斯

• 《帶你搞懂樸素貝葉斯分類算法》
• P(B|A)=P(A|B)P(B)/P(A)
• 《貝葉斯推斷及其互聯(lián)網(wǎng)應(yīng)用1》
• 《貝葉斯推斷及其互聯(lián)網(wǎng)應(yīng)用2》

推薦算法

• 《推薦算法綜述》
• 《TOP 10 開源的推薦系統(tǒng)簡介》

最小生成樹算法

• 《算法導(dǎo)論--最小生成樹（Kruskal和Prim算法）》

最短路徑算法

• 《Dijkstra算法詳解》

并發(fā)

Java 并發(fā)

• Java 并發(fā)知識(shí)合集
• JAVA并發(fā)知識(shí)圖譜

多線程

• 《40個(gè)Java多線程問題總結(jié)》

線程安全

• 《Java并發(fā)編程——線程安全及解決機(jī)制簡介》

一致性、事務(wù)

事務(wù) ACID 特性

• 《數(shù)據(jù)庫事務(wù)ACID特性》

事務(wù)的隔離級(jí)別

• 未提交讀：一個(gè)事務(wù)可以讀取另一個(gè)未提交的數(shù)據(jù)，容易出現(xiàn)臟讀的情況。
• 讀提交：一個(gè)事務(wù)等另外一個(gè)事務(wù)提交之后才可以讀取數(shù)據(jù)，但會(huì)出現(xiàn)不可重復(fù)讀的情況（多次讀取的數(shù)據(jù)不一致），讀取過程中出現(xiàn)UPDATE操作，會(huì)多。（大多數(shù)數(shù)據(jù)庫默認(rèn)級(jí)別是RC，比如SQL Server，Oracle），讀取的時(shí)候不可以修改。
• 可重復(fù)讀： 同一個(gè)事務(wù)里確保每次讀取的時(shí)候，獲得的是同樣的數(shù)據(jù)，但不保障原始數(shù)據(jù)被其他事務(wù)更新（幻讀），Mysql InnoDB 就是這個(gè)級(jí)別。
• 序列化：所有事物串行處理（犧牲了效率）
• 《理解事務(wù)的4種隔離級(jí)別》
• 數(shù)據(jù)庫事務(wù)的四大特性及事務(wù)隔離級(jí)別
• 《MySQL的InnoDB的幻讀問題 》
• 幻讀的例子非常清楚。
• 通過 SELECT ... FOR UPDATE 解決。
• 《一篇文章帶你讀懂MySQL和InnoDB》
• 圖解臟讀、不可重復(fù)讀、幻讀問題。

MVCC

• 《【mysql】關(guān)于innodb中MVCC的一些理解》
• innodb 中 MVCC 用在 Repeatable-Read 隔離級(jí)別。
• MVCC 會(huì)產(chǎn)生幻讀問題（更新時(shí)異常。）
• 《輕松理解MYSQL MVCC 實(shí)現(xiàn)機(jī)制》
• 通過隱藏版本列來實(shí)現(xiàn) MVCC 控制，一列記錄創(chuàng)建時(shí)間、一列記錄刪除時(shí)間，這里的時(shí)間
• 每次只操作比當(dāng)前版本小（或等于）的 行。

鎖

Java中的鎖和同步類

• 《Java中的鎖分類》
• 主要包括 synchronized、ReentrantLock、和 ReadWriteLock。
• 《Java并發(fā)之AQS詳解》
• 《Java中信號(hào)量 Semaphore》
• 有數(shù)量控制
• 申請(qǐng)用 acquire，申請(qǐng)不要?jiǎng)t阻塞；釋放用 release。
• 《java開發(fā)中的Mutex vs Semaphore》
• 簡單的說 就是Mutex是排它的，只有一個(gè)可以獲取到資源， Semaphore也具有排它性，但可以定義多個(gè)可以獲取的資源的對(duì)象。

公平鎖 & 非公平鎖

公平鎖的作用就是嚴(yán)格按照線程啟動(dòng)的順序來執(zhí)行的，不允許其他線程插隊(duì)執(zhí)行的；而非公平鎖是允許插隊(duì)的。

• 《公平鎖與非公平鎖》
• 默認(rèn)情況下 ReentrantLock 和 synchronized 都是非公平鎖。ReentrantLock 可以設(shè)置成公平鎖。

悲觀鎖

悲觀鎖如果使用不當(dāng)（鎖的條數(shù)過多），會(huì)引起服務(wù)大面積等待。推薦優(yōu)先使用樂觀鎖+重試。

• 《【MySQL】悲觀鎖&樂觀鎖》
• 樂觀鎖的方式：版本號(hào)+重試方式
• 悲觀鎖：通過 select ... for update 進(jìn)行行鎖(不可讀、不可寫，share 鎖可讀不可寫)。
• 《Mysql查詢語句使用select.. for update導(dǎo)致的數(shù)據(jù)庫死鎖分析》
• mysql的innodb存儲(chǔ)引擎實(shí)務(wù)鎖雖然是鎖行，但它內(nèi)部是鎖索引的。
• 鎖相同數(shù)據(jù)的不同索引條件可能會(huì)引起死鎖。
• 《Mysql并發(fā)時(shí)經(jīng)典常見的死鎖原因及解決方法》

樂觀鎖 & CAS

• 《樂觀鎖的一種實(shí)現(xiàn)方式——CAS》
• 和MySQL樂觀鎖方式相似，只不過是通過和原值進(jìn)行比較。

ABA 問題

由于高并發(fā)，在CAS下，更新后可能此A非彼A。通過版本號(hào)可以解決，類似于上文Mysql 中提到的的樂觀鎖。

• 《Java CAS 和ABA問題》
• 《Java 中 ABA問題及避免》
• AtomicStampedReference 和 AtomicStampedReference。

CopyOnWrite容器

可以對(duì)CopyOnWrite容器進(jìn)行并發(fā)的讀，而不需要加鎖。CopyOnWrite并發(fā)容器用于讀多寫少的并發(fā)場(chǎng)景。比如白名單，黑名單，商品類目的訪問和更新場(chǎng)景，不適合需要數(shù)據(jù)強(qiáng)一致性的場(chǎng)景。

• 《JAVA中寫時(shí)復(fù)制(Copy-On-Write)Map實(shí)現(xiàn)》
• 實(shí)現(xiàn)讀寫分離，讀取發(fā)生在原始數(shù)據(jù)上，寫入發(fā)生在副本上。
• 不用加鎖，通過最終一致實(shí)現(xiàn)一致性。
• 《聊聊并發(fā)-Java中的Copy-On-Write容器》

RingBuffer

• 《線程安全的無鎖RingBuffer的實(shí)現(xiàn)【一個(gè)讀線程，一個(gè)寫線程】》

可重入鎖 & 不可重入鎖

• 《可重入鎖和不可重入鎖》
• 通過簡單代碼舉例說明可重入鎖和不可重入鎖。
• 可重入鎖指同一個(gè)線程可以再次獲得之前已經(jīng)獲得的鎖。
• 可重入鎖可以用戶避免死鎖。
• Java中的可重入鎖：synchronized 和 java.util.concurrent.locks.ReentrantLock
• 《ReenTrantLock可重入鎖（和synchronized的區(qū)別）總結(jié)》
• synchronized 使用方便，編譯器來加鎖，是非公平鎖。
• ReenTrantLock 使用靈活，鎖的公平性可以定制。
• 相同加鎖場(chǎng)景下，推薦使用 synchronized。

互斥鎖 & 共享鎖

互斥鎖：同時(shí)只能有一個(gè)線程獲得鎖。比如，ReentrantLock 是互斥鎖，ReadWriteLock 中的寫鎖是互斥鎖。 共享鎖：可以有多個(gè)線程同時(shí)或的鎖。比如，Semaphore、CountDownLatch 是共享鎖，ReadWriteLock 中的讀鎖是共享鎖。

• 《ReadWriteLock場(chǎng)景應(yīng)用》

死鎖

• 《“死鎖”四個(gè)必要條件的合理解釋》
• 互斥、持有、不可剝奪、環(huán)形等待。
• Java如何查看死鎖？
• JConsole 可以識(shí)別死鎖。
• java多線程系列：死鎖及檢測(cè)
• jstack 可以顯示死鎖。

操作系統(tǒng)

計(jì)算機(jī)原理

• 《操作系統(tǒng)基礎(chǔ)知識(shí)——操作系統(tǒng)的原理，類型和結(jié)構(gòu)》

CPU

多級(jí)緩存

典型的 CPU 有三級(jí)緩存，距離核心越近，速度越快，空間越小。L1 一般 32k，L2 一般 256k，L3 一般12M。內(nèi)存速度需要200個(gè) CPU 周期，CPU 緩存需要1個(gè)CPU周期。

• 《從Java視角理解CPU緩存和偽共享》

進(jìn)程

TODO

線程

• 《線程的生命周期及狀態(tài)轉(zhuǎn)換詳解》

協(xié)程

• 《終結(jié)python協(xié)程----從yield到actor模型的實(shí)現(xiàn)》
• 線程的調(diào)度是由操作系統(tǒng)負(fù)責(zé)，協(xié)程調(diào)度是程序自行負(fù)責(zé)
• 與線程相比，協(xié)程減少了無謂的操作系統(tǒng)切換.
• 實(shí)際上當(dāng)遇到IO操作時(shí)做切換才更有意義，（因?yàn)镮O操作不用占用CPU），如果沒遇到IO操作，按照時(shí)間片切換.

Linux

• 《Linux 命令大全》

設(shè)計(jì)模式

設(shè)計(jì)模式的六大原則

• 《設(shè)計(jì)模式的六大原則》
• 開閉原則：對(duì)擴(kuò)展開放,對(duì)修改關(guān)閉，多使用抽象類和接口。
• 里氏替換原則：基類可以被子類替換，使用抽象類繼承,不使用具體類繼承。
• 依賴倒轉(zhuǎn)原則：要依賴于抽象,不要依賴于具體，針對(duì)接口編程,不針對(duì)實(shí)現(xiàn)編程。
• 接口隔離原則：使用多個(gè)隔離的接口,比使用單個(gè)接口好，建立最小的接口。
• 迪米特法則：一個(gè)軟件實(shí)體應(yīng)當(dāng)盡可能少地與其他實(shí)體發(fā)生相互作用，通過中間類建立聯(lián)系。
• 合成復(fù)用原則：盡量使用合成/聚合,而不是使用繼承。

23種常見設(shè)計(jì)模式

• 《設(shè)計(jì)模式》
• 《23種設(shè)計(jì)模式全解析》
• 《設(shè)計(jì)模式類圖與示例》

應(yīng)用場(chǎng)景

• 《細(xì)數(shù)JDK里的設(shè)計(jì)模式》
• 結(jié)構(gòu)型模式：
• 適配器：用來把一個(gè)接口轉(zhuǎn)化成另一個(gè)接口，如 java.util.Arrays#asList()。
• 橋接模式：這個(gè)模式將抽象和抽象操作的實(shí)現(xiàn)進(jìn)行了解耦，這樣使得抽象和實(shí)現(xiàn)可以獨(dú)立地變化，如JDBC；
• 組合模式：使得客戶端看來單個(gè)對(duì)象和對(duì)象的組合是同等的。換句話說，某個(gè)類型的方法同時(shí)也接受自身類型作為參數(shù)，如 Map.putAll，List.addAll、Set.addAll。
• 裝飾者模式：動(dòng)態(tài)的給一個(gè)對(duì)象附加額外的功能，這也是子類的一種替代方式，如 java.util.Collections#checkedList|Map|Set|SortedSet|SortedMap。
• 享元模式：使用緩存來加速大量小對(duì)象的訪問時(shí)間，如 valueOf(int)。
• 代理模式：代理模式是用一個(gè)簡單的對(duì)象來代替一個(gè)復(fù)雜的或者創(chuàng)建耗時(shí)的對(duì)象，如 java.lang.reflect.Proxy
• 創(chuàng)建模式:
• 抽象工廠模式：抽象工廠模式提供了一個(gè)協(xié)議來生成一系列的相關(guān)或者獨(dú)立的對(duì)象，而不用指定具體對(duì)象的類型，如 java.util.Calendar#getInstance()。
• 建造模式(Builder)：定義了一個(gè)新的類來構(gòu)建另一個(gè)類的實(shí)例，以簡化復(fù)雜對(duì)象的創(chuàng)建，如：java.lang.StringBuilder#append()。
• 工廠方法：就是 一個(gè)返* 回具體對(duì)象的方法，而不是多個(gè)，如 java.lang.Object#toString()、java.lang.Class#newInstance()。
• 原型模式：使得類的實(shí)例能夠生成自身的拷貝、如：java.lang.Object#clone()。
• 單例模式：全局只有一個(gè)實(shí)例，如 java.lang.Runtime#getRuntime()。
• 行為模式：
• 責(zé)任鏈模式：通過把請(qǐng)求從一個(gè)對(duì)象傳遞到鏈條中下一個(gè)對(duì)象的方式，直到請(qǐng)求被處理完畢，以實(shí)現(xiàn)對(duì)象間的解耦。如 javax.servlet.Filter#doFilter()。
• 命令模式：將操作封裝到對(duì)象內(nèi)，以便存儲(chǔ)，傳遞和返回，如：java.lang.Runnable。
• 解釋器模式：定義了一個(gè)語言的語法，然后解析相應(yīng)語法的語句，如，java.text.Format，java.text.Normalizer。
• 迭代器模式：提供一個(gè)一致的方法來順序訪問集合中的對(duì)象，如 java.util.Iterator。
• 中介者模式：通過使用一個(gè)中間對(duì)象來進(jìn)行消息分發(fā)以及減少類之間的直接依賴，java.lang.reflect.Method#invoke()。
• 空對(duì)象模式：如 java.util.Collections#emptyList()。
• 觀察者模式：它使得一個(gè)對(duì)象可以靈活的將消息發(fā)送給感興趣的對(duì)象，如 java.util.EventListener。
• 模板方法模式：讓子類可以重寫方法的一部分，而不是整個(gè)重寫，如 java.util.Collections#sort()。
• 《Spring-涉及到的設(shè)計(jì)模式匯總》
• 《Mybatis使用的設(shè)計(jì)模式》

單例模式

• 《單例模式的三種實(shí)現(xiàn) 以及各自的優(yōu)缺點(diǎn)》
• 《單例模式－－反射－－防止序列化破壞單例模式》
• 使用枚舉類型。

責(zé)任鏈模式

TODO

MVC

• 《MVC 模式》
• 模型(model)－視圖(view)－控制器(controller)

IOC

• 《理解 IOC》
• 《IOC 的理解與解釋》
• 正向控制：傳統(tǒng)通過new的方式。反向控制，通過容器注入對(duì)象。
• 作用：用于模塊解耦。
• DI：Dependency Injection，即依賴注入，只關(guān)心資源使用，不關(guān)心資源來源。

AOP

• 《輕松理解AOP(面向切面編程)》
• 《Spring AOP詳解》
• 《Spring AOP的實(shí)現(xiàn)原理》
• Spring AOP使用的動(dòng)態(tài)代理，主要有兩種方式：JDK動(dòng)態(tài)代理和CGLIB動(dòng)態(tài)代理。
• 《Spring AOP 實(shí)現(xiàn)原理與 CGLIB 應(yīng)用》
• Spring AOP 框架對(duì) AOP 代理類的處理原則是：如果目標(biāo)對(duì)象的實(shí)現(xiàn)類實(shí)現(xiàn)了接口，Spring AOP 將會(huì)采用 JDK 動(dòng)態(tài)代理來生成 AOP 代理類；如果目標(biāo)對(duì)象的實(shí)現(xiàn)類沒有實(shí)現(xiàn)接口，Spring AOP 將會(huì)采用 CGLIB 來生成 AOP 代理類

UML

• 《UML教程》

微服務(wù)思想

• 《微服務(wù)架構(gòu)設(shè)計(jì)》
• 《微服務(wù)架構(gòu)技術(shù)棧選型手冊(cè)》

康威定律

• 《微服務(wù)架構(gòu)的理論基礎(chǔ) - 康威定律》
• 定律一：組織溝通方式會(huì)通過系統(tǒng)設(shè)計(jì)表達(dá)出來，就是說架構(gòu)的布局和組織結(jié)構(gòu)會(huì)有相似。
• 定律二：時(shí)間再多一件事情也不可能做的完美，但總有時(shí)間做完一件事情。一口氣吃不成胖子，先搞定能搞定的。
• 定律三：線型系統(tǒng)和線型組織架構(gòu)間有潛在的異質(zhì)同態(tài)特性。種瓜得瓜，做獨(dú)立自治的子系統(tǒng)減少溝通成本。
• 定律四：大的系統(tǒng)組織總是比小系統(tǒng)更傾向于分解。合久必分，分而治之。
• 《微服務(wù)架構(gòu)核?20講》

運(yùn)維 & 統(tǒng)計(jì) & 技術(shù)支持

常規(guī)監(jiān)控

• 《騰訊業(yè)務(wù)系統(tǒng)監(jiān)控的修煉之路》
• 監(jiān)控的方式：主動(dòng)、被動(dòng)、旁路(比如輿情監(jiān)控)
• 監(jiān)控類型： 基礎(chǔ)監(jiān)控、服務(wù)端監(jiān)控、客戶端監(jiān)控、 監(jiān)控、用戶端監(jiān)控
• 監(jiān)控的目標(biāo)：全、塊、準(zhǔn)
• 核心指標(biāo)：請(qǐng)求量、成功率、耗時(shí)
• 《開源還是商用？十大云運(yùn)維監(jiān)控工具橫評(píng)》
• Zabbix、Nagios、Ganglia、Zenoss、Open-falcon、監(jiān)控寶、 360網(wǎng)站服務(wù)監(jiān)控、阿里云監(jiān)控、百度云觀測(cè)、小蜜蜂網(wǎng)站監(jiān)測(cè)等。
• 《監(jiān)控報(bào)警系統(tǒng)搭建及二次開發(fā)經(jīng)驗(yàn)》

命令行監(jiān)控工具

• 《常用命令行監(jiān)控工具》
• top、sar、tsar、nload
• 《20個(gè)命令行工具監(jiān)控 Linux 系統(tǒng)性能》
• 《JVM性能調(diào)優(yōu)監(jiān)控工具jps、jstack、jmap、jhat、jstat、hprof使用詳解》

APM

APM — Application Performance Management

• 《Dapper，大規(guī)模分布式系統(tǒng)的跟蹤系統(tǒng)》
• CNCF OpenTracing，中文版
• 主要開源軟件，按字母排序
• Apache SkyWalking
• CAT
• CNCF jaeger
• Pinpoint
• Zipkin
• 《開源APM技術(shù)選型與實(shí)戰(zhàn)》
• 主要基于 Google的Dapper（大規(guī)模分布式系統(tǒng)的跟蹤系統(tǒng)） 思想。

統(tǒng)計(jì)分析

• 《流量統(tǒng)計(jì)的基礎(chǔ)：埋點(diǎn)》
• 常用指標(biāo)：訪問與訪客、停留時(shí)長、跳出率、退出率、轉(zhuǎn)化率、參與度
• 《APP埋點(diǎn)常用的統(tǒng)計(jì)工具、埋點(diǎn)目標(biāo)和埋點(diǎn)內(nèi)容》
• 第三方統(tǒng)計(jì)：友盟、百度移動(dòng)、魔方、App Annie、talking data、神策數(shù)據(jù)等。
• 《美團(tuán)點(diǎn)評(píng)前端無痕埋點(diǎn)實(shí)踐》
• 所謂無痕、即通過可視化工具配置采集節(jié)點(diǎn)，在前端自動(dòng)解析配置并上報(bào)埋點(diǎn)數(shù)據(jù)，而非硬編碼。

持續(xù)集成(CI/CD)

• 《持續(xù)集成是什么？》
• 《8個(gè)流行的持續(xù)集成工具》

Jenkins

• 《使用Jenkins進(jìn)行持續(xù)集成》

環(huán)境分離

開發(fā)、測(cè)試、生成環(huán)境分離。

• 《開發(fā)環(huán)境、生產(chǎn)環(huán)境、測(cè)試環(huán)境的基本理解和區(qū)》

自動(dòng)化運(yùn)維

Ansible

• 《Ansible中文權(quán)威指南》
• 《Ansible基礎(chǔ)配置和企業(yè)級(jí)項(xiàng)目實(shí)用案例》

puppet

• 《自動(dòng)化運(yùn)維工具——puppet詳解》

chef

• 《Chef 的安裝與使用》

測(cè)試

TDD 理論

• 《深度解讀 - TDD（測(cè)試驅(qū)動(dòng)開發(fā)）》
• 基于測(cè)試用例編碼功能代碼，XP（Extreme Programming）的核心實(shí)踐.
• 好處：一次關(guān)注一個(gè)點(diǎn)，降低思維負(fù)擔(dān)；迎接需求變化或改善代碼的設(shè)計(jì)；提前澄清需求；快速反饋；

單元測(cè)試

• 《Java單元測(cè)試之JUnit篇》
• 《JUnit 4 與 TestNG 對(duì)比》
• TestNG 覆蓋 JUnit 功能，適用于更復(fù)雜的場(chǎng)景。
• 《單元測(cè)試主要的測(cè)試功能點(diǎn)》
• 模塊接口測(cè)試、局部數(shù)據(jù)結(jié)構(gòu)測(cè)試、路徑測(cè)試 、錯(cuò)誤處理測(cè)試、邊界條件測(cè)試 。

壓力測(cè)試

• 《Apache ab 測(cè)試使用指南》
• 《大型網(wǎng)站壓力測(cè)試及優(yōu)化方案》
• 《10大主流壓力/負(fù)載/性能測(cè)試工具推薦》
• 《真實(shí)流量壓測(cè)工具 tcpcopy應(yīng)用淺析》
• 《nGrinder 簡易使用教程》

全鏈路壓測(cè)

• 《京東618：升級(jí)全鏈路壓測(cè)方案，打造軍演機(jī)器人ForceBot》
• 《餓了么全鏈路壓測(cè)的探索與實(shí)踐》
• 《四大語言，八大框架｜滴滴全鏈路壓測(cè)解決之道》
• 《全鏈路壓測(cè)經(jīng)驗(yàn)》

A/B 、灰度、藍(lán)綠測(cè)試

• 《技術(shù)干貨 | AB 測(cè)試和灰度發(fā)布探索及實(shí)踐》
• 《nginx 根據(jù)IP 進(jìn)行灰度發(fā)布》
• 《藍(lán)綠部署、A/B 測(cè)試以及灰度發(fā)布》

虛擬化

• 《VPS的三種虛擬技術(shù)OpenVZ、Xen、KVM優(yōu)缺點(diǎn)比較》

KVM

• 《KVM詳解，太詳細(xì)太深入了，經(jīng)典》
• 《【圖文】KVM 虛擬機(jī)安裝詳解》

Xen

• 《Xen虛擬化基本原理詳解》

OpenVZ

• 《開源Linux容器 OpenVZ 快速上手指南》

容器技術(shù)

Docker

• 《幾張圖幫你理解 docker 基本原理及快速入門》
• 《Docker 核心技術(shù)與實(shí)現(xiàn)原理》
• 《Docker 教程》

云技術(shù)

OpenStack

• 《OpenStack構(gòu)架知識(shí)梳理》

DevOps

• 《一分鐘告訴你究竟DevOps是什么鬼？》
• 《DevOps詳解》

文檔管理

• Confluence-收費(fèi)文檔管理系統(tǒng)
• GitLab?
• Wiki

中間件

Web Server

Nginx

• 《Ngnix的基本學(xué)習(xí)-多進(jìn)程和Apache的比較》
• Nginx 通過異步非阻塞的事件處理機(jī)制實(shí)現(xiàn)高并發(fā)。Apache 每個(gè)請(qǐng)求獨(dú)占一個(gè)線程，非常消耗系統(tǒng)資源。
• 事件驅(qū)動(dòng)適合于IO密集型服務(wù)(Nginx)，多進(jìn)程或線程適合于CPU密集型服務(wù)(Apache)，所以Nginx適合做反向代理，而非web服務(wù)器使用。
• 《nginx與Apache的對(duì)比以及優(yōu)缺點(diǎn)》
• nginx只適合靜態(tài)和反向代理，不適合處理動(dòng)態(tài)請(qǐng)求。

OpenResty

• 官方網(wǎng)站
• 《淺談 OpenResty》
• 通過 Lua 模塊可以在Nginx上進(jìn)行開發(fā)。
• agentzh 的 Nginx 教程

Tengine

• 官方網(wǎng)站

Apache Httpd

• 官方網(wǎng)站

Tomcat

架構(gòu)原理

• 《TOMCAT原理詳解及請(qǐng)求過程》
• 《Tomcat服務(wù)器原理詳解》
• 《Tomcat 系統(tǒng)架構(gòu)與設(shè)計(jì)模式,第 1 部分: 工作原理》
• 《四張圖帶你了解Tomcat系統(tǒng)架構(gòu)》
• 《JBoss vs. Tomcat: Choosing A Java Application Server》
• Tomcat 是輕量級(jí)的 Serverlet 容器，沒有實(shí)現(xiàn)全部 JEE 特性（比如持久化和事務(wù)處理），但可以通過其他組件代替，比如Spring。
• Jboss 實(shí)現(xiàn)全部了JEE特性，軟件開源免費(fèi)、文檔收費(fèi)。

調(diào)優(yōu)方案

《Tomcat 調(diào)優(yōu)方案》

• 啟動(dòng)NIO模式（或者APR）；調(diào)整線程池；禁用AJP連接器（Nginx+tomcat的架構(gòu)，不需要AJP）；
• 《tomcat http協(xié)議與ajp協(xié)議》
• 《AJP與HTTP比較和分析》
• AJP 協(xié)議（8009端口）用于降低和前端Server（如Apache，而且需要支持AJP協(xié)議）的連接數(shù)(前端)，通過長連接提高性能。
• 并發(fā)高時(shí)，AJP協(xié)議優(yōu)于HTTP協(xié)議。

Jetty

• 《Jetty 的工作原理以及與 Tomcat 的比較》
• 《jetty和tomcat優(yōu)勢(shì)比較》
• 架構(gòu)比較:Jetty的架構(gòu)比Tomcat的更為簡單。
• 性能比較：Jetty和Tomcat性能方面差異不大，Jetty默認(rèn)采用NIO結(jié)束在處理I/O請(qǐng)求上更占優(yōu)勢(shì)，Tomcat默認(rèn)采用BIO處理I/O請(qǐng)求，Tomcat適合處理少數(shù)非常繁忙的鏈接，處理靜態(tài)資源時(shí)性能較差。
• 其他方面：Jetty的應(yīng)用更加快速，修改簡單，對(duì)新的Servlet規(guī)范的支持較好;Tomcat 對(duì)JEE和Servlet 支持更加全面。

緩存

• 《緩存失效策略（FIFO 、LRU、LFU三種算法的區(qū)別）》

本地緩存

• 《HashMap本地緩存》
• 《EhCache本地緩存》
• 堆內(nèi)、堆外、磁盤三級(jí)緩存。
• 可按照緩存空間容量進(jìn)行設(shè)置。
• 按照時(shí)間、次數(shù)等過期策略。
• 《Guava Cache》
• 簡單輕量、無堆外、磁盤緩存。
• 《Nginx本地緩存》
• 《Pagespeed—懶人工具，服務(wù)器端加速》

客戶端緩存

• 《瀏覽器端緩存》
• 主要是利用 Cache-Control 參數(shù)。
• 《H5 和移動(dòng)端 WebView 緩存機(jī)制解析與實(shí)戰(zhàn)》

服務(wù)端緩存

Web緩存

• nuster - nuster cache
• varnish - varnish cache
• squid - squid cache

Memcached

• 《Memcached 教程》
• 《深入理解Memcached原理》
• 采用多路復(fù)用技術(shù)提高并發(fā)性。
• slab分配算法： memcached給Slab分配內(nèi)存空間，默認(rèn)是1MB。分配給Slab之后 把slab的切分成大小相同的chunk，Chunk是用于緩存記錄的內(nèi)存空間，Chunk 的大小默認(rèn)按照1.25倍的速度遞增。好處是不會(huì)頻繁申請(qǐng)內(nèi)存，提高IO效率，壞處是會(huì)有一定的內(nèi)存浪費(fèi)。
• 《Memcached軟件工作原理》
• 《Memcache技術(shù)分享：介紹、使用、存儲(chǔ)、算法、優(yōu)化、命中率》
• 《memcache 中 add 、 set 、replace 的區(qū)別》
• 區(qū)別在于當(dāng)key存在還是不存在時(shí)，返回值是true和false的。
• 《memcached全面剖析》

Redis

• 《Redis 教程》
• 《redis底層原理》
• 使用 ziplist 存儲(chǔ)鏈表，ziplist是一種壓縮鏈表，它的好處是更能節(jié)省內(nèi)存空間，因?yàn)樗鎯?chǔ)的內(nèi)容都是在連續(xù)的內(nèi)存區(qū)域當(dāng)中的。
• 使用 skiplist(跳躍表)來存儲(chǔ)有序集合對(duì)象、查找上先從高Level查起、時(shí)間復(fù)雜度和紅黑樹相當(dāng)，實(shí)現(xiàn)容易，無鎖、并發(fā)性好。
• 《Redis持久化方式》
• RDB方式：定期備份快照，常用于災(zāi)難恢復(fù)。優(yōu)點(diǎn)：通過fork出的進(jìn)程進(jìn)行備份，不影響主進(jìn)程、RDB 在恢復(fù)大數(shù)據(jù)集時(shí)的速度比 AOF 的恢復(fù)速度要快。缺點(diǎn)：會(huì)丟數(shù)據(jù)。
• AOF方式：保存操作日志方式。優(yōu)點(diǎn)：恢復(fù)時(shí)數(shù)據(jù)丟失少，缺點(diǎn)：文件大，回復(fù)慢。
• 也可以兩者結(jié)合使用。
• 《分布式緩存--序列3--原子操作與CAS樂觀鎖》

架構(gòu)

• 《Redis單線程架構(gòu)》

回收策略

• 《redis的回收策略》

Tair

• 官方網(wǎng)站
• 《Tair和Redis的對(duì)比》
• 特點(diǎn)：可以配置備份節(jié)點(diǎn)數(shù)目，通過異步同步到備份節(jié)點(diǎn)
• 一致性Hash算法。
• 架構(gòu)：和Hadoop 的設(shè)計(jì)思想類似，有Configserver，DataServer，Configserver 通過心跳來檢測(cè)，Configserver也有主備關(guān)系。

幾種存儲(chǔ)引擎:

• MDB，完全內(nèi)存性，可以用來存儲(chǔ)Session等數(shù)據(jù)。
• Rdb（類似于Redis），輕量化，去除了aof之類的操作，支持Restfull操作
• LDB（LevelDB存儲(chǔ)引擎），持久化存儲(chǔ)，LDB 作為rdb的持久化，google實(shí)現(xiàn)，比較高效，理論基礎(chǔ)是LSM(Log-Structured-Merge Tree)算法，現(xiàn)在內(nèi)存中修改數(shù)據(jù)，達(dá)到一定量時(shí)（和內(nèi)存匯總的舊數(shù)據(jù)一同寫入磁盤）再寫入磁盤，存儲(chǔ)更加高效，縣比喻Hash算法。
• Tair采用共享內(nèi)存來存儲(chǔ)數(shù)據(jù)，如果服務(wù)掛掉（非服務(wù)器），重啟服務(wù)之后，數(shù)據(jù)亦然還在。

消息隊(duì)列

• 《消息隊(duì)列-推/拉模式學(xué)習(xí) & ActiveMQ及JMS學(xué)習(xí)》
• RabbitMQ 消費(fèi)者默認(rèn)是推模式（也支持拉模式）。
• Kafka 默認(rèn)是拉模式。
• Push方式：優(yōu)點(diǎn)是可以盡可能快地將消息發(fā)送給消費(fèi)者，缺點(diǎn)是如果消費(fèi)者處理能力跟不上，消費(fèi)者的緩沖區(qū)可能會(huì)溢出。
• Pull方式：優(yōu)點(diǎn)是消費(fèi)端可以按處理能力進(jìn)行拉去，缺點(diǎn)是會(huì)增加消息延遲。
• 《Kafka、RabbitMQ、RocketMQ等消息中間件的對(duì)比 —— 消息發(fā)送性能和區(qū)別》

消息總線

消息總線相當(dāng)于在消息隊(duì)列之上做了一層封裝，統(tǒng)一入口，統(tǒng)一管控、簡化接入成本。

• 《消息總線VS消息隊(duì)列》

消息的順序

• 《如何保證消費(fèi)者接收消息的順序》

RabbitMQ

支持事務(wù)，推拉模式都是支持、適合需要可靠性消息傳輸?shù)膱?chǎng)景。

• 《RabbitMQ的應(yīng)用場(chǎng)景以及基本原理介紹》
• 《消息隊(duì)列之 RabbitMQ》
• 《RabbitMQ之消息確認(rèn)機(jī)制（事務(wù)+/confirm/i）》

RocketMQ

Java實(shí)現(xiàn)，推拉模式都是支持，吞吐量遜于Kafka。可以保證消息順序。

• 《RocketMQ 實(shí)戰(zhàn)之快速入門》
• 《RocketMQ 源碼解析》

ActiveMQ

純Java實(shí)現(xiàn)，兼容JMS，可以內(nèi)嵌于Java應(yīng)用中。

• 《ActiveMQ消息隊(duì)列介紹》

Kafka

高吞吐量、采用拉模式。適合高IO場(chǎng)景，比如日志同步。

• 官方網(wǎng)站
• 《各消息隊(duì)列對(duì)比，Kafka深度解析，眾人推薦，精彩好文！》
• 《Kafka分區(qū)機(jī)制介紹與示例》

Redis 消息推送

生產(chǎn)者、消費(fèi)者模式完全是客戶端行為，list 和 拉模式實(shí)現(xiàn)，阻塞等待采用 blpop 指令。

• 《Redis學(xué)習(xí)筆記之十：Redis用作消息隊(duì)列》

ZeroMQ

TODO

定時(shí)調(diào)度

單機(jī)定時(shí)調(diào)度

• 《linux定時(shí)任務(wù)cron配置》
• 《Linux cron運(yùn)行原理》
• fork 進(jìn)程 + sleep 輪詢
• 《Quartz使用總結(jié)》
• 《Quartz源碼解析 ---- 觸發(fā)器按時(shí)啟動(dòng)原理》
• 《quartz原理揭秘和源碼解讀》
• 定時(shí)調(diào)度在 QuartzSchedulerThread 代碼中，while()無限循環(huán)，每次循環(huán)取出時(shí)間將到的trigger，觸發(fā)對(duì)應(yīng)的job，直到調(diào)度器線程被關(guān)閉。

分布式定時(shí)調(diào)度

• 《這些優(yōu)秀的國產(chǎn)分布式任務(wù)調(diào)度系統(tǒng)，你用過幾個(gè)？》
• opencron、LTS、XXL-JOB、Elastic-Job、Uncode-Schedule、Antares
• 《Quartz任務(wù)調(diào)度的基本實(shí)現(xiàn)原理》
• Quartz集群中，獨(dú)立的Quartz節(jié)點(diǎn)并不與另一其的節(jié)點(diǎn)或是管理節(jié)點(diǎn)通信，而是通過相同的數(shù)據(jù)庫表來感知到另一Quartz應(yīng)用的
• 《Elastic-Job-Lite 源碼解析》
• 《Elastic-Job-Cloud 源碼解析》

RPC

• 《從零開始實(shí)現(xiàn)RPC框架 - RPC原理及實(shí)現(xiàn)》
• 核心角色：Server: 暴露服務(wù)的服務(wù)提供方、Client: 調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方、Registry: 服務(wù)注冊(cè)與發(fā)現(xiàn)的注冊(cè)中心。
• 《分布式RPC框架性能大比拼 dubbo、motan、rpcx、gRPC、thrift的性能比較》

Dubbo

• 官方網(wǎng)站
• dubbo實(shí)現(xiàn)原理簡單介紹

** SPI ** TODO

Thrift

• 官方網(wǎng)站
• 《Thrift RPC詳解》
• 支持多語言，通過中間語言定義接口。

gRPC

服務(wù)端可以認(rèn)證加密，在外網(wǎng)環(huán)境下，可以保證數(shù)據(jù)安全。

• 官方網(wǎng)站
• 《你應(yīng)該知道的RPC原理》

數(shù)據(jù)庫中間件

Sharding Jdbc

• 官網(wǎng)
• 源碼解析

日志系統(tǒng)

日志搜集

• 《從零開始搭建一個(gè)ELKB日志收集系統(tǒng)》
• 《用ELK搭建簡單的日志收集分析系統(tǒng)》
• 《日志收集系統(tǒng)-探究》

配置中心

• Apollo - 攜程開源的配置中心應(yīng)用
• Spring Boot 和 Spring Cloud
• 支持推、拉模式更新配置
• 支持多種語言
• 《基于zookeeper實(shí)現(xiàn)統(tǒng)一配置管理》
• 《 Spring Cloud Config 分布式配置中心使用教程》

servlet 3.0 異步特性可用于配置中心的客戶端

• 《servlet3.0 新特性——異步處理》

API 網(wǎng)關(guān)

主要職責(zé)：請(qǐng)求轉(zhuǎn)發(fā)、安全認(rèn)證、協(xié)議轉(zhuǎn)換、容災(zāi)。

• 《API網(wǎng)關(guān)那些兒》
• 《談API網(wǎng)關(guān)的背景、架構(gòu)以及落地方案》
• 《使用Zuul構(gòu)建API Gateway》
• 《Spring Cloud Gateway 源碼解析》
• 《HTTP API網(wǎng)關(guān)選擇之一Kong介紹》

網(wǎng)絡(luò)

協(xié)議

OSI 七層協(xié)議

• 《OSI七層協(xié)議模型、TCP/IP四層模型學(xué)習(xí)筆記》

TCP/IP

• 《深入淺出 TCP/IP 協(xié)議》
• 《TCP協(xié)議中的三次握手和四次揮手》

HTTP

• 《http協(xié)議詳解(超詳細(xì))》

HTTP2.0

• 《HTTP 2.0 原理詳細(xì)分析》
• 《HTTP2.0的基本單位為二進(jìn)制幀》
• 利用二進(jìn)制幀負(fù)責(zé)傳輸。
• 多路復(fù)用。

HTTPS

• 《https原理通俗了解》
• 使用非對(duì)稱加密協(xié)商加密算法
• 使用對(duì)稱加密方式傳輸數(shù)據(jù)
• 使用第三方機(jī)構(gòu)簽發(fā)的證書，來加密公鑰，用于公鑰的安全傳輸、防止被中間人串改。
• 《八大免費(fèi)SSL證書-給你的網(wǎng)站免費(fèi)添加Https安全加密》

網(wǎng)絡(luò)模型

• 《web優(yōu)化必須了解的原理之I/o的五種模型和web的三種工作模式》
• 五種I/O模型：阻塞I/O，非阻塞I/O，I/O復(fù)用、事件(信號(hào))驅(qū)動(dòng)I/O、異步I/O，前四種I/O屬于同步操作，I/O的第一階段不同、第二階段相同，最后的一種則屬于異步操作。
• 三種 Web Server 工作方式：Prefork(多進(jìn)程)、Worker方式(線程方式)、Event方式。
• 《select、poll、epoll之間的區(qū)別總結(jié)》
• select，poll，epoll本質(zhì)上都是同步I/O，因?yàn)樗麄兌夹枰谧x寫事件就緒后自己負(fù)責(zé)進(jìn)行讀寫，也就是說這個(gè)讀寫過程是阻塞的。
• select 有打開文件描述符數(shù)量限制，默認(rèn)1024（2048 for x64），100萬并發(fā)，就要用1000個(gè)進(jìn)程、切換開銷大；poll采用鏈表結(jié)構(gòu)，沒有數(shù)量限制。
• select，poll “醒著”的時(shí)候要遍歷整個(gè)fd集合，而epoll在“醒著”的時(shí)候只要判斷一下就緒鏈表是否為空就行了，通過回調(diào)機(jī)制節(jié)省大量CPU時(shí)間；select，poll每次調(diào)用都要把fd集合從用戶態(tài)往內(nèi)核態(tài)拷貝一次，而epoll只要一次拷貝。
• poll會(huì)隨著并發(fā)增加，性能逐漸下降，epoll采用紅黑樹結(jié)構(gòu)，性能穩(wěn)定，不會(huì)隨著連接數(shù)增加而降低。
• 《select，poll，epoll比較 》
• 在連接數(shù)少并且連接都十分活躍的情況下，select和poll的性能可能比epoll好，畢竟epoll的通知機(jī)制需要很多函數(shù)回調(diào)。
• 《深入理解Java NIO》
• NIO 是一種同步非阻塞的 IO 模型。同步是指線程不斷輪詢 IO 事件是否就緒，非阻塞是指線程在等待 IO 的時(shí)候，可以同時(shí)做其他任務(wù)
• 《BIO與NIO、AIO的區(qū)別》
• 《兩種高效的服務(wù)器設(shè)計(jì)模型：Reactor和Proactor模型》

Epoll

• 《epoll使用詳解（精髓）》

Java NIO

• 《深入理解Java NIO》
• 《Java NIO編寫Socket服務(wù)器的一個(gè)例子》

kqueue

• 《kqueue用法簡介》

連接和短連接

• 《TCP/IP系列——長連接與短連接的區(qū)別》

框架

• 《Netty原理剖析》
• Reactor 模式介紹。
• Netty 是 Reactor 模式的一種實(shí)現(xiàn)。

零拷貝（Zero-copy）

• 《對(duì)于 Netty ByteBuf 的零拷貝(Zero Copy) 的理解》
• 多個(gè)物理分離的buffer，通過邏輯上合并成為一個(gè)，從而避免了數(shù)據(jù)在內(nèi)存之間的拷貝。

序列化(二進(jìn)制協(xié)議)

Hessian

• 《Hessian原理分析》 Binary-RPC;不僅僅是序列化

Protobuf

• 《Protobuf協(xié)議的Java應(yīng)用例子》 Goolge出品、占用空間和效率完勝其他序列化類庫，如Hessian；需要編寫 .proto 文件。
• 《Protocol Buffers序列化協(xié)議及應(yīng)用》
• 關(guān)于協(xié)議的解釋；缺點(diǎn)：可讀性差;
• 《簡單的使用 protobuf 和 protostuff》
• protostuff 的好處是不用寫 .proto 文件，Java 對(duì)象直接就可以序列化。

數(shù)據(jù)庫

基礎(chǔ)理論

數(shù)據(jù)庫設(shè)計(jì)的三大范式

• 《數(shù)據(jù)庫的三大范式以及五大約束》
• 第一范式：數(shù)據(jù)表中的每一列（每個(gè)字段）必須是不可拆分的最小單元，也就是確保每一列的原子性；
• 第二范式（2NF）：滿足1NF后，要求表中的所有列，都必須依賴于主鍵，而不能有任何一列與主鍵沒有關(guān)系，也就是說一個(gè)表只描述一件事情；
• 第三范式：必須先滿足第二范式（2NF），要求：表中的每一列只與主鍵直接相關(guān)而不是間接相關(guān)，（表中的每一列只能依賴于主鍵）；

MySQL

原理

• 《MySQL的InnoDB索引原理詳解》
• 《MySQL存儲(chǔ)引擎－－MyISAM與InnoDB區(qū)別》
• 兩種類型最主要的差別就是Innodb 支持事務(wù)處理與外鍵和行級(jí)鎖
• 《myisam和innodb索引實(shí)現(xiàn)的不同》

InnoDB

• 《一篇文章帶你讀懂Mysql和InnoDB》

優(yōu)化

• 《MySQL36條軍規(guī)》
• 《MYSQL性能優(yōu)化的最佳20+條經(jīng)驗(yàn)》
• 《SQL優(yōu)化之道》
• 《mysql數(shù)據(jù)庫死鎖的產(chǎn)生原因及解決辦法》
• 《導(dǎo)致索引失效的可能情況》
• 《 MYSQL分頁limit速度太慢優(yōu)化方法》
• 原則上就是縮小掃描范圍。

索引

聚集索引, 非聚集索引

• 《MySQL 聚集索引/非聚集索引簡述》
• 《MyISAM和InnoDB的索引實(shí)現(xiàn)》

MyISAM 是非聚集，InnoDB 是聚集

復(fù)合索引

• 《復(fù)合索引的優(yōu)點(diǎn)和注意事項(xiàng)》
• 文中有一處錯(cuò)誤：

對(duì)于復(fù)合索引,在查詢使用時(shí),最好將條件順序按找索引的順序,這樣效率最高; select * from table1 where col1=A AND col2=B AND col3=D 如果使用 where col2=B AND col1=A 或者 where col2=B 將不會(huì)使用索引

• 原文中提到索引是按照“col1，col2，col3”的順序創(chuàng)建的，而mysql在按照最左前綴的索引匹配原則，且會(huì)自動(dòng)優(yōu)化 where 條件的順序，當(dāng)條件中只有 col2=B AND col1=A 時(shí)，會(huì)自動(dòng)轉(zhuǎn)化為 col1=A AND col2=B，所以依然會(huì)使用索引。
• 《MySQL查詢where條件的順序?qū)Σ樵冃实挠绊憽?/li>

自適應(yīng)哈希索引(AHI)

• 《InnoDB存儲(chǔ)引擎——自適應(yīng)哈希索引》

explain

• 《MySQL 性能優(yōu)化神器 Explain 使用分析》

NoSQL

MongoDB

• MongoDB 教程
• 《Mongodb相對(duì)于關(guān)系型數(shù)據(jù)庫的優(yōu)缺點(diǎn)》
• 優(yōu)點(diǎn)：弱一致性（最終一致），更能保證用戶的訪問速度；內(nèi)置GridFS，支持大容量的存儲(chǔ)；Schema-less 數(shù)據(jù)庫，不用預(yù)先定義結(jié)構(gòu)；內(nèi)置Sharding；相比于其他NoSQL，第三方支持豐富；性能優(yōu)越；
• 缺點(diǎn)：mongodb不支持事務(wù)操作；mongodb占用空間過大；MongoDB沒有如MySQL那樣成熟的維護(hù)工具，這對(duì)于開發(fā)和IT運(yùn)營都是個(gè)值得注意的地方；

Hbase

• 《簡明 Hbase 入門教程（開篇）》
• 《深入學(xué)習(xí)Hbase架構(gòu)原理》
• 《傳統(tǒng)的行存儲(chǔ)和（Hbase）列存儲(chǔ)的區(qū)別》
• 《Hbase與傳統(tǒng)數(shù)據(jù)庫的區(qū)別》
• 空數(shù)據(jù)不存儲(chǔ)，節(jié)省空間，且適用于并發(fā)。
• 《Hbase Rowkey設(shè)計(jì)》
• rowkey 按照字典順序排列，便于批量掃描。
• 通過散列可以避免熱點(diǎn)。

搜索引擎

搜索引擎原理

• 《倒排索引--搜索引擎入門》

Lucene

• 《Lucene入門簡介》

Elasticsearch

• 《Elasticsearch學(xué)習(xí)，請(qǐng)先看這一篇！》
• 《Elasticsearch索引原理》

Solr

• 《 Apache Solr入門教程》
• 《elasticsearch與solr比較》

sphinx

• 《Sphinx 的介紹和原理探索》

性能

性能優(yōu)化方法論

• 《15天的性能優(yōu)化工作，5方面的調(diào)優(yōu)經(jīng)驗(yàn)》
• 代碼層面、業(yè)務(wù)層面、數(shù)據(jù)庫層面、服務(wù)器層面、前端優(yōu)化。
• 《系統(tǒng)性能優(yōu)化的幾個(gè)方面》

容量評(píng)估

• 《聯(lián)網(wǎng)性能與容量評(píng)估的方法論和典型案例》
• 《互聯(lián)網(wǎng)架構(gòu)，如何進(jìn)行容量設(shè)計(jì)？》
• 評(píng)估總訪問量、評(píng)估平均訪問量QPS、評(píng)估高峰QPS、評(píng)估系統(tǒng)、單機(jī)極限QPS

CDN 網(wǎng)絡(luò)

• 《CDN加速原理》
• 《國內(nèi)有哪些比較好的 CDN？》

連接池

• 《主流Java數(shù)據(jù)庫連接池比較與開發(fā)配置實(shí)戰(zhàn)》

性能調(diào)優(yōu)

• 《九大Java性能調(diào)試工具，必備至少一款》

大數(shù)據(jù)

流式計(jì)算

Storm

• 官方網(wǎng)站
• 《最詳細(xì)的Storm入門教程》

Flink

• 《Flink之一 Flink基本原理介紹》

Kafka Stream

• 《Kafka Stream調(diào)研：一種輕量級(jí)流計(jì)算模式》計(jì)；
• 推薦系統(tǒng)用戶畫像標(biāo)簽實(shí)時(shí)更新；
• 線上服務(wù)健康狀況實(shí)時(shí)監(jiān)測(cè)；
• 實(shí)時(shí)榜單；
• 實(shí)時(shí)數(shù)據(jù)統(tǒng)計(jì)。

Hadoop

• 《用通俗易懂的話說下hadoop是什么,能做什么》
• 《史上最詳細(xì)的Hadoop環(huán)境搭建》

HDFS

• 《【Hadoop學(xué)習(xí)】HDFS基本原理》

MapReduce

• 《用通俗易懂的大白話講解Map/Reduce原理》
• 《 簡單的map-reduce的java例子》

Yarn

• 《初步掌握Yarn的架構(gòu)及原理》

Spark

• 《Spark(一): 基本架構(gòu)及原理》

安全

web 安全

XSS

• 《xss攻擊原理與解決方法》

CSRF

• 《CSRF原理及防范》

SQL 注入

• 《SQL注入》

Hash Dos

• 《邪惡的JAVA HASH DOS攻擊》
• 利用JsonObject 上傳大Json，JsonObject 底層使用HashMap；不同的數(shù)據(jù)產(chǎn)生相同的hash值，使得構(gòu)建Hash速度變慢，耗盡CPU。
• 《一種高級(jí)的DoS攻擊-Hash碰撞攻擊》
• 《關(guān)于Hash Collision DoS漏洞：解析與解決方案》

腳本注入

• 《上傳文件漏洞原理及防范》

漏洞掃描工具

• 《DVWA》
• W3af
• OpenVAS詳解

驗(yàn)證碼

• 《驗(yàn)證碼原理分析及實(shí)現(xiàn)》
• 《詳解滑動(dòng)驗(yàn)證碼的實(shí)現(xiàn)原理》
• 滑動(dòng)驗(yàn)證碼是根據(jù)人在滑動(dòng)滑塊的響應(yīng)時(shí)間，拖拽速度，時(shí)間，位置，軌跡，重試次數(shù)等來評(píng)估風(fēng)險(xiǎn)。
• 《淘寶滑動(dòng)驗(yàn)證碼研究》

DDoS 防范

• 《學(xué)習(xí)手冊(cè)：DDoS的攻擊方式及防御手段》
• 《免費(fèi)DDoS攻擊測(cè)試工具大合集》

用戶隱私信息保護(hù)

1. 用戶密碼非明文保存，加動(dòng)態(tài)salt。
2. 身份證號(hào)，手機(jī)號(hào)如果要顯示，用 “*” 替代部分字符。
3. 聯(lián)系方式在的顯示與否由用戶自己控制。
4. TODO

• 《個(gè)人隱私包括哪些》
• 《在互聯(lián)網(wǎng)上，隱私的范圍包括哪些？》
• 《用戶密碼保存》

序列化漏洞

• 《Lib之過？Java反序列化漏洞通用利用分析》

加密解密

對(duì)稱加密

• 《常見對(duì)稱加密算法》
• DES、3DES、Blowfish、AES
• DES 采用 56位秘鑰，Blowfish 采用1到448位變長秘鑰，AES 128，192和256位長度的秘鑰。
• DES 秘鑰太短（只有56位）算法目前已經(jīng)被 AES 取代，并且 AES 有硬件加速，性能很好。

哈希算法

• 《常用的哈希算法》
• MD5 和 SHA-1 已經(jīng)不再安全，已被棄用。
• 目前 SHA-256 是比較安全的。
• 《基于Hash摘要簽名的公網(wǎng)URL簽名驗(yàn)證設(shè)計(jì)方案》

非對(duì)稱加密

• 《常見非對(duì)稱加密算法》
• RSA、DSA、ECDSA(螺旋曲線加密算法)
• 和 RSA 不同的是 DSA 僅能用于數(shù)字簽名，不能進(jìn)行數(shù)據(jù)加密解密，其安全性和RSA相當(dāng)，但其性能要比RSA快。
• 256位的ECC秘鑰的安全性等同于3072位的RSA秘鑰。
• 《區(qū)塊鏈的加密技術(shù)》

服務(wù)器安全

• 《Linux強(qiáng)化論：15步打造一個(gè)安全的Linux服務(wù)器》

數(shù)據(jù)安全

數(shù)據(jù)備份

TODO

網(wǎng)絡(luò)隔離

內(nèi)外網(wǎng)分離

TODO

登錄跳板機(jī)

在內(nèi)外環(huán)境中通過跳板機(jī)登錄到線上主機(jī)。

• 《搭建簡易堡壘機(jī)》

授權(quán)、認(rèn)證

RBAC

• 《基于組織角色的權(quán)限設(shè)計(jì)》
• 《權(quán)限系統(tǒng)與RBAC模型概述》
• 《Spring整合Shiro做權(quán)限控制模塊詳細(xì)案例分析》

OAuth2.0

• 《理解OAuth 2.0》
• 《一張圖搞定OAuth2.0》

雙因素認(rèn)證（2FA）

2FA - Two-factor authentication，用于加強(qiáng)登錄驗(yàn)證

常用做法是 登錄密碼 + 手機(jī)驗(yàn)證碼（或者令牌Key，類似于與網(wǎng)銀的 USB key）

• 【《雙因素認(rèn)證（2FA）教程》】(http://www.ruanyifeng.com/blog/2017/11/2fa-tutorial.html)

單點(diǎn)登錄(SSO)

• 《單點(diǎn)登錄原理與簡單實(shí)現(xiàn)》
• CAS單點(diǎn)登錄框架

常用開源框架

開源協(xié)議

• 《開源協(xié)議的選擇》
• 如何選擇一個(gè)開源軟件協(xié)議

日志框架

Log4j、Log4j2

• 《log4j 詳細(xì)講解》
• 《log4j2 實(shí)際使用詳解》
• 《Log4j1,Logback以及Log4j2性能測(cè)試對(duì)比》
• Log4J 異步日志性能優(yōu)異。

Logback

• 《最全LogBack 詳解、含java案例和配置說明》

ORM

• 《ORM框架使用優(yōu)缺點(diǎn)》
• 主要目的是為了提高開發(fā)效率。

MyBatis：

• 《mybatis緩存機(jī)制詳解》
• 一級(jí)緩存是SqlSession級(jí)別的緩存，緩存的數(shù)據(jù)只在SqlSession內(nèi)有效
• 二級(jí)緩存是mapper級(jí)別的緩存，同一個(gè)namespace公用這一個(gè)緩存，所以對(duì)SqlSession是共享的；使用 LRU 機(jī)制清理緩存，通過 cacheEnabled 參數(shù)開啟。
• 《MyBatis學(xué)習(xí)之代碼生成器Generator》

網(wǎng)絡(luò)框架

TODO

Web 框架

Spring 家族

Spring

• Spring 簡明教程

Spring Boot

• 官方網(wǎng)站
• 《Spring Boot基礎(chǔ)教程》

Spring Cloud

• Spring Boot 中文索引站
• Spring Cloud 中文文檔
• 《Spring Cloud基礎(chǔ)教程》

工具框架

• 《Apache Commons 工具類介紹及簡單使用》
• 《Google guava 中文教程》

分布式設(shè)計(jì)

擴(kuò)展性設(shè)計(jì)

• 《架構(gòu)師不可不知的十大可擴(kuò)展架構(gòu)》
• 總結(jié)下來，通用的套路就是分布、緩存及異步處理。
• 《可擴(kuò)展性設(shè)計(jì)之?dāng)?shù)據(jù)切分》
• 水平切分+垂直切分
• 利用中間件進(jìn)行分片如，MySQL Proxy。
• 利用分片策略進(jìn)行切分，如按照ID取模。
• 《說說如何實(shí)現(xiàn)可擴(kuò)展性的大型網(wǎng)站架構(gòu)》
• 分布式服務(wù)+消息隊(duì)列。
• 《大型網(wǎng)站技術(shù)架構(gòu)（七）--網(wǎng)站的可擴(kuò)展性架構(gòu)》

穩(wěn)定性 & 高可用

• 《系統(tǒng)設(shè)計(jì)：關(guān)于高可用系統(tǒng)的一些技術(shù)方案》
• 可擴(kuò)展：水平擴(kuò)展、垂直擴(kuò)展。 通過冗余部署，避免單點(diǎn)故障。
• 隔離：避免單一業(yè)務(wù)占用全部資源。避免業(yè)務(wù)之間的相互影響 2. 機(jī)房隔離避免單點(diǎn)故障。
• 解耦：降低維護(hù)成本，降低耦合風(fēng)險(xiǎn)。減少依賴，減少相互間的影響。
• 限流：滑動(dòng)窗口計(jì)數(shù)法、漏桶算法、令牌桶算法等算法。遇到突發(fā)流量時(shí)，保證系統(tǒng)穩(wěn)定。
• 降級(jí)：緊急情況下釋放非核心功能的資源。犧牲非核心業(yè)務(wù)，保證核心業(yè)務(wù)的高可用。
• 熔斷：異常情況超出閾值進(jìn)入熔斷狀態(tài)，快速失敗。減少不穩(wěn)定的外部依賴對(duì)核心服務(wù)的影響。
• 自動(dòng)化測(cè)試：通過完善的測(cè)試，減少發(fā)布引起的故障。
• 灰度發(fā)布：灰度發(fā)布是速度與安全性作為妥協(xié)，能夠有效減少發(fā)布故障。
• 《關(guān)于高可用的系統(tǒng)》
• 設(shè)計(jì)原則：數(shù)據(jù)不丟(持久化)；服務(wù)高可用(服務(wù)副本)；絕對(duì)的100%高可用很難，目標(biāo)是做到盡可能多的9，如99.999%（全年累計(jì)只有5分鐘）。

硬件負(fù)載均衡

• 《轉(zhuǎn)！！負(fù)載均衡器技術(shù)Nginx和F5的優(yōu)缺點(diǎn)對(duì)比》
• 主要是和F5對(duì)比。
• 《軟/硬件負(fù)載均衡產(chǎn)品 你知多少？》

軟件負(fù)載均衡

• 《幾種負(fù)載均衡算法》 輪尋、權(quán)重、負(fù)載、最少連接、QoS
• 《DNS負(fù)載均衡》
• 配置簡單，更新速度慢。
• 《Nginx負(fù)載均衡》
• 簡單輕量、學(xué)習(xí)成本低；主要適用于web應(yīng)用。
• 《借助LVS+Keepalived實(shí)現(xiàn)負(fù)載均衡 》
• 配置比較負(fù)載、只支持到4層，性能較高。
• 《HAProxy用法詳解 全網(wǎng)最詳細(xì)中文文檔》
• 支持到七層（比如HTTP）、功能比較全面，性能也不錯(cuò)。
• 《Haproxy+Keepalived+MySQL實(shí)現(xiàn)讀均衡負(fù)載》
• 主要是用戶讀請(qǐng)求的負(fù)載均衡。
• 《rabbitmq+haproxy+keepalived實(shí)現(xiàn)高可用集群搭建》

限流

• 《談?wù)劯卟l(fā)系統(tǒng)的限流》
• 計(jì)數(shù)器：通過滑動(dòng)窗口計(jì)數(shù)器，控制單位時(shí)間內(nèi)的請(qǐng)求次數(shù)，簡單粗暴。
• 漏桶算法：固定容量的漏桶，漏桶滿了就丟棄請(qǐng)求，比較常用。
• 令牌桶算法：固定容量的令牌桶，按照一定速率添加令牌，處理請(qǐng)求前需要拿到令牌，拿不到令牌則丟棄請(qǐng)求，或進(jìn)入丟隊(duì)列，可以通過控制添加令牌的速率，來控制整體速度。Guava 中的 RateLimiter 是令牌桶的實(shí)現(xiàn)。
• Nginx 限流：通過 limit_req 等模塊限制并發(fā)連接數(shù)。

應(yīng)用層容災(zāi)

• 《防雪崩利器：熔斷器 Hystrix 的原理與使用》
• 雪崩效應(yīng)原因：硬件故障、硬件故障、程序Bug、重試加大流量、用戶大量請(qǐng)求。
• 雪崩的對(duì)策：限流、改進(jìn)緩存模式(緩存預(yù)加載、同步調(diào)用改異步)、自動(dòng)擴(kuò)容、降級(jí)。
• Hystrix設(shè)計(jì)原則：
• 資源隔離：Hystrix通過將每個(gè)依賴服務(wù)分配獨(dú)立的線程池進(jìn)行資源隔離, 從而避免服務(wù)雪崩。
• 熔斷開關(guān)：服務(wù)的健康狀況 = 請(qǐng)求失敗數(shù) / 請(qǐng)求總數(shù)，通過閾值設(shè)定和滑動(dòng)窗口控制開關(guān)。
• 命令模式：通過繼承 HystrixCommand 來包裝服務(wù)調(diào)用邏輯。
• 《緩存穿透，緩存擊穿，緩存雪崩解決方案分析》
• 《緩存擊穿、失效以及熱點(diǎn)key問題》
• 主要策略：失效瞬間：單機(jī)使用鎖；使用分布式鎖；不過期；
• 熱點(diǎn)數(shù)據(jù)：熱點(diǎn)數(shù)據(jù)單獨(dú)存儲(chǔ)；使用本地緩存；分成多個(gè)子key；

跨機(jī)房容災(zāi)

• 《“異地多活”多機(jī)房部署經(jīng)驗(yàn)談》
• 通過自研中間件進(jìn)行數(shù)據(jù)同步。
• 《異地多活（異地雙活）實(shí)踐經(jīng)驗(yàn)》
• 注意延遲問題，多次跨機(jī)房調(diào)用會(huì)將延時(shí)放大數(shù)倍。
• 建房間專線很大概率會(huì)出現(xiàn)問題，做好運(yùn)維和程序?qū)用娴娜蒎e(cuò)。
• 不能依賴于程序端數(shù)據(jù)雙寫，要有自動(dòng)同步方案。
• 數(shù)據(jù)永不在高延遲和較差網(wǎng)絡(luò)質(zhì)量下，考慮同步質(zhì)量問題。
• 核心業(yè)務(wù)和次要業(yè)務(wù)分而治之，甚至只考慮核心業(yè)務(wù)。
• 異地多活監(jiān)控部署、測(cè)試也要跟上。
• 業(yè)務(wù)允許的情況下考慮用戶分區(qū)，尤其是游戲、郵箱業(yè)務(wù)。
• 控制跨機(jī)房消息體大小，越小越好。
• 考慮使用docker容器虛擬化技術(shù)，提高動(dòng)態(tài)調(diào)度能力。
• 容災(zāi)技術(shù)及建設(shè)經(jīng)驗(yàn)介紹

容災(zāi)演練流程

• 《依賴治理、灰度發(fā)布、故障演練，阿里電商故障演練系統(tǒng)的設(shè)計(jì)與實(shí)戰(zhàn)經(jīng)驗(yàn)》
• 常見故障畫像
• 案例：預(yù)案有效性、預(yù)案有效性、故障復(fù)現(xiàn)、架構(gòu)容災(zāi)測(cè)試、參數(shù)調(diào)優(yōu)、參數(shù)調(diào)優(yōu)、故障突襲、聯(lián)合演練。

平滑啟動(dòng)

• 平滑重啟應(yīng)用思路 1.端流量（如vip層）、2. flush 數(shù)據(jù)(如果有)、3, 重啟應(yīng)用
• 《JVM安全退出（如何優(yōu)雅的關(guān)閉java服務(wù)）》 推薦推出方式：System.exit，Kill SIGTERM；不推薦 kill-9；用 Runtime.addShutdownHook 注冊(cè)鉤子。
• 《常見Java應(yīng)用如何優(yōu)雅關(guān)閉》 Java、Spring、Dubbo 優(yōu)雅關(guān)閉方式。

數(shù)據(jù)庫擴(kuò)展

讀寫分離模式

• 《Mysql主從方案的實(shí)現(xiàn)》
• 《搭建MySQL主從復(fù)制經(jīng)典架構(gòu)》
• 《Haproxy+多臺(tái)MySQL從服務(wù)器(Slave) 實(shí)現(xiàn)負(fù)載均衡》
• 《DRBD+Heartbeat+Mysql高可用讀寫分離架構(gòu)》
• DRDB 進(jìn)行磁盤復(fù)制，避免單點(diǎn)問題。
• 《MySQL Cluster 方式》

分片模式

• 《分庫分表需要考慮的問題及方案》
• 中間件： 輕量級(jí)：sharding-jdbc、TSharding；重量級(jí)：Atlas、MyCAT、Vitess等。
• 問題：事務(wù)、Join、遷移、擴(kuò)容、ID、分頁等。
• 事務(wù)補(bǔ)償：對(duì)數(shù)據(jù)進(jìn)行對(duì)帳檢查;基于日志進(jìn)行比對(duì);定期同標(biāo)準(zhǔn)數(shù)據(jù)來源進(jìn)行同步等。
• 分庫策略：數(shù)值范圍；取模；日期等。
• 分庫數(shù)量：通常 MySQL 單庫 5千萬條、Oracle 單庫一億條需要分庫。
• 《MySql分表和表分區(qū)詳解》
• 分區(qū)：是MySQL內(nèi)部機(jī)制，對(duì)客戶端透明，數(shù)據(jù)存儲(chǔ)在不同文件中，表面上看是同一個(gè)表。
• 分表：物理上創(chuàng)建不同的表、客戶端需要管理分表路由。

服務(wù)治理

服務(wù)注冊(cè)與發(fā)現(xiàn)

• 《永不失聯(lián)！如何實(shí)現(xiàn)微服務(wù)架構(gòu)中的服務(wù)發(fā)現(xiàn)？》
• 客戶端服務(wù)發(fā)現(xiàn)模式：客戶端直接查詢注冊(cè)表，同時(shí)自己負(fù)責(zé)負(fù)載均衡。Eureka 采用這種方式。
• 服務(wù)器端服務(wù)發(fā)現(xiàn)模式：客戶端通過負(fù)載均衡查詢服務(wù)實(shí)例。
• 《SpringCloud服務(wù)注冊(cè)中心比較:Consul vs Zookeeper vs Etcd vs Eureka》
• CAP支持：Consul（CA）、zookeeper（cp）、etcd（cp） 、euerka（ap）
• 作者認(rèn)為目前 Consul 對(duì) Spring cloud 的支持比較好。
• 《基于Zookeeper的服務(wù)注冊(cè)與發(fā)現(xiàn)》
• 優(yōu)點(diǎn)：API簡單、Pinterest，Airbnb 在用、多語言、通過watcher機(jī)制來實(shí)現(xiàn)配置PUSH，能快速響應(yīng)配置變化。

服務(wù)路由控制

• 《分布式服務(wù)框架學(xué)習(xí)筆記4 服務(wù)路由》
• 原則：透明化路由
• 負(fù)載均衡策略：隨機(jī)、輪詢、服務(wù)調(diào)用延遲、一致性哈希、粘滯連接
• 本地路由有限策略：injvm(優(yōu)先調(diào)用jvm內(nèi)部的服務(wù))，innative(優(yōu)先使用相同物理機(jī)的服務(wù)),原則上找距離最近的服務(wù)。
• 配置方式：統(tǒng)一注冊(cè)表；本地配置；動(dòng)態(tài)下發(fā)。

分布式一致

CAP 與 base 理論

• 《從分布式一致性談到CAP理論、base理論》
• 一致性分類：強(qiáng)一致(立即一致)；弱一致(可在單位時(shí)間內(nèi)實(shí)現(xiàn)一致，比如秒級(jí))；最終一致(弱一致的一種，一定時(shí)間內(nèi)最終一致)
• CAP：一致性、可用性、分區(qū)容錯(cuò)性(網(wǎng)絡(luò)故障引起)
• base：Basically Available（基本可用）、Soft state（軟狀態(tài)）和Eventually consistent（最終一致性）
• base理論的核心思想是：即使無法做到強(qiáng)一致性，但每個(gè)應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹硎瓜到y(tǒng)達(dá)到最終一致性。

分布式鎖

• 《分布式鎖的幾種實(shí)現(xiàn)方式》
• 基于數(shù)據(jù)庫的分布式鎖：優(yōu)點(diǎn)：操作簡單、容易理解。缺點(diǎn)：存在單點(diǎn)問題、數(shù)據(jù)庫性能夠開銷較大、不可重入；
• 基于緩存的分布式鎖：優(yōu)點(diǎn)：非阻塞、性能好。缺點(diǎn)：操作不好容易造成鎖無法釋放的情況。
• Zookeeper 分布式鎖：通過有序臨時(shí)節(jié)點(diǎn)實(shí)現(xiàn)鎖機(jī)制，自己對(duì)應(yīng)的節(jié)點(diǎn)需要最小，則被認(rèn)為是獲得了鎖。優(yōu)點(diǎn)：集群可以透明解決單點(diǎn)問題，避免鎖不被釋放問題，同時(shí)鎖可以重入。缺點(diǎn)：性能不如緩存方式，吞吐量會(huì)隨著zk集群規(guī)模變大而下降。
• 《基于Zookeeper的分布式鎖》
• 清楚的原理描述 + Java 代碼示例。
• 《jedisLock—redis分布式鎖實(shí)現(xiàn)》
• 基于 setnx(set if ont exists)，有則返回false，否則返回true。并支持過期時(shí)間。
• 《Memcached 和 Redis 分布式鎖方案》
• 利用 memcached 的 add（有別于set）操作，當(dāng)key存在時(shí)，返回false。

分布式一致性算法

PAXOS

• 《分布式系列文章——Paxos算法原理與推導(dǎo)》
• 《Paxos-->Fast Paxos-->Zookeeper分析》
• 《【分布式】Zookeeper與Paxos》

Zab

• 《Zab：Zookeeper 中的分布式一致性協(xié)議介紹》

Raft

• 《Raft 為什么是更易理解的分布式一致性算法》
• 三種角色：Leader（領(lǐng)袖）、Follower（群眾）、Candidate（候選人）
• 通過隨機(jī)等待的方式發(fā)出投票，得票多的獲勝。

Gossip

• 《Gossip算法》

兩階段提交、多階段提交

• 《關(guān)于分布式事務(wù)、兩階段提交協(xié)議、三階提交協(xié)議》

冪等

• 《分布式系統(tǒng)---冪等性設(shè)計(jì)》
• 冪等特性的作用：該資源具備冪等性，請(qǐng)求方無需擔(dān)心重復(fù)調(diào)用會(huì)產(chǎn)生錯(cuò)誤。
• 常見保證冪等的手段：MVCC（類似于樂觀鎖）、去重表(唯一索引)、悲觀鎖、一次性token、序列號(hào)方式。

分布式一致方案

• 《分布式系統(tǒng)事務(wù)一致性解決方案》
• 《保證分布式系統(tǒng)數(shù)據(jù)一致性的6種方案》

分布式 Leader 節(jié)點(diǎn)選舉

• 《利用zookeeper實(shí)現(xiàn)分布式leader節(jié)點(diǎn)選舉》

TCC(Try//confirm/i/Cancel) 柔性事務(wù)

• 《傳統(tǒng)事務(wù)與柔性事務(wù)》
• 基于base理論：基本可用、柔性狀態(tài)、最終一致。
• 解決方案：記錄日志+補(bǔ)償（正向補(bǔ)充或者回滾）、消息重試(要求程序要冪等)；“無鎖設(shè)計(jì)”、采用樂觀鎖機(jī)制。

分布式文件系統(tǒng)

• 說說分布式文件存儲(chǔ)系統(tǒng)-基本架構(gòu) ？
• 《各種分布式文件系統(tǒng)的比較》 ？
• HDFS：大批量數(shù)據(jù)讀寫，用于高吞吐量的場(chǎng)景，不適合小文件。
• FastDFS：輕量級(jí)、適合小文件。

唯一ID 生成

全局唯一ID

• 《高并發(fā)分布式系統(tǒng)中生成全局唯一Id匯總》
• Twitter 方案（Snowflake 算法）：41位時(shí)間戳+10位機(jī)器標(biāo)識(shí)（比如IP，服務(wù)器名稱等）+12位序列號(hào)(本地計(jì)數(shù)器)
• Flicker 方案：MySQL自增ID + "REPLACE INTO XXX:SELECT LAST_INSERT_ID();"
• UUID：缺點(diǎn)，無序，字符串過長，占用空間，影響檢索性能。
• MongoDB 方案：利用 ObjectId。缺點(diǎn)：不能自增。
• 《TDDL 在分布式下的SEQUENCE原理》
• 在數(shù)據(jù)庫中創(chuàng)建 sequence 表，用于記錄，當(dāng)前已被占用的id最大值。
• 每臺(tái)客戶端主機(jī)取一個(gè)id區(qū)間（比如 1000~2000）緩存在本地，并更新 sequence 表中的id最大值記錄。
• 客戶端主機(jī)之間取不同的id區(qū)間，用完再取，使用樂觀鎖機(jī)制控制并發(fā)。

一致性Hash算法

• 《一致性哈希算法》

設(shè)計(jì)思想 & 開發(fā)模式

DDD(Domain-driven Design - 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì))

• 《淺談我對(duì)DDD領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的理解》
• 概念：DDD 主要對(duì)傳統(tǒng)軟件開發(fā)流程(分析-設(shè)計(jì)-編碼)中各階段的割裂問題而提出，避免由于一開始分析不明或在軟件開發(fā)過程中的信息流轉(zhuǎn)不一致而造成軟件無法交付（和需求方設(shè)想不一致）的問題。DDD 強(qiáng)調(diào)一切以領(lǐng)域（Domain）為中心，強(qiáng)調(diào)領(lǐng)域?qū)＜遥―omain Expert）的作用，強(qiáng)調(diào)先定義好領(lǐng)域模型之后在進(jìn)行開發(fā)，并且領(lǐng)域模型可以指導(dǎo)開發(fā)（所謂的驅(qū)動(dòng)）。
• 過程：理解領(lǐng)域、拆分領(lǐng)域、細(xì)化領(lǐng)域，模型的準(zhǔn)確性取決于模型的理解深度。
• 設(shè)計(jì)：DDD 中提出了建模工具，比如聚合、實(shí)體、值對(duì)象、工廠、倉儲(chǔ)、領(lǐng)域服務(wù)、領(lǐng)域事件來幫助領(lǐng)域建模。
• 《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的基礎(chǔ)知識(shí)總結(jié)》
• 領(lǐng)域（Doamin）本質(zhì)上就是問題域，比如一個(gè)電商系統(tǒng)，一個(gè)論壇系統(tǒng)等。
• 界限上下文（Bounded Context）：闡述子域之間的關(guān)系，可以簡單理解成一個(gè)子系統(tǒng)或組件模塊。
• 領(lǐng)域模型（Domain Model）：DDD的核心是建立（用通用描述語言、工具—領(lǐng)域通用語言）正確的領(lǐng)域模型；反應(yīng)業(yè)務(wù)需求的本質(zhì)，包括實(shí)體和過程；其貫穿軟件分析、設(shè)計(jì)、開發(fā) 的整個(gè)過程；常用表達(dá)領(lǐng)域模型的方式：圖、代碼或文字；
• 領(lǐng)域通用語言：領(lǐng)域?qū)＜摇㈤_發(fā)設(shè)計(jì)人員都能立即的語言或工具。
• 經(jīng)典分層架構(gòu)：用戶界面/展示層、應(yīng)用層、領(lǐng)域?qū)印⒒A(chǔ)設(shè)施層，是四層架構(gòu)模式。
• 使用的模式：
• 關(guān)聯(lián)盡量少，盡量單項(xiàng)，盡量降低整體復(fù)雜度。
• 實(shí)體（Entity）：領(lǐng)域中的唯一標(biāo)示，一個(gè)實(shí)體的屬性盡量少，少則清晰。
• 值對(duì)象（Value Object）：沒有唯一標(biāo)識(shí)，且屬性值不可變，小二簡單的對(duì)象，比如Date。
• 領(lǐng)域服務(wù)（Domain Service）： 協(xié)調(diào)多個(gè)領(lǐng)域?qū)ο螅挥蟹椒]有狀態(tài)(不存數(shù)據(jù))；可以分為應(yīng)用層服務(wù)，領(lǐng)域?qū)臃?wù)、基礎(chǔ)層服務(wù)。
• 聚合及聚合根（Aggregate，Aggregate Root）：聚合定義了一組具有內(nèi)聚關(guān)系的相關(guān)對(duì)象的集合；聚合根是對(duì)聚合引用的唯一元素；當(dāng)修改一個(gè)聚合時(shí)，必須在事務(wù)級(jí)別；大部分領(lǐng)域模型中，有70%的聚合通常只有一個(gè)實(shí)體，30%只有2~3個(gè)實(shí)體；如果一個(gè)聚合只有一個(gè)實(shí)體，那么這個(gè)實(shí)體就是聚合根；如果有多個(gè)實(shí)體，那么我們可以思考聚合內(nèi)哪個(gè)對(duì)象有獨(dú)立存在的意義并且可以和外部直接進(jìn)行交互；
• 工廠（Factory）：類似于設(shè)計(jì)模式中的工廠模式。
• 倉儲(chǔ)（Repository）：持久化到DB，管理對(duì)象，且只對(duì)聚合設(shè)計(jì)倉儲(chǔ)。
• 《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(DDD)實(shí)現(xiàn)之路》
• 聚合：比如一輛汽車（Car）包含了引擎（Engine）、車輪（Wheel）和油箱（Tank）等組件，缺一不可。
• 《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)系列（2）淺析VO、DTO、DO、PO的概念、區(qū)別和用處》

命令查詢職責(zé)分離(CQRS)

CQRS — Command Query Responsibility Seperation

• 《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)系列 (六)：CQRS》
• 核心思想：讀寫分離（查詢和更新在不同的方法中），不同的流程只是不同的設(shè)計(jì)方式，CQ代碼分離，分布式環(huán)境中會(huì)有明顯體現(xiàn)（有冗余數(shù)據(jù)的情況下），目的是為了高性能。
• 《DDD CQRS架構(gòu)和傳統(tǒng)架構(gòu)的優(yōu)缺點(diǎn)比較》
• 最終一致的設(shè)計(jì)理念；依賴于高可用消息中間件。
• 《CQRS架構(gòu)簡介》
• 一個(gè)實(shí)現(xiàn) CQRS 的抽象案例。
• 《深度長文：我對(duì)CQRS/EventSourcing架構(gòu)的思考》
• CQRS 模式分析 + 12306 搶票案例

貧血，充血模型

• 《貧血，充血模型的解釋以及一些經(jīng)驗(yàn)》
• 失血模型：老子和兒子分別定義，相互不知道，二者實(shí)體定義中完全沒有業(yè)務(wù)邏輯，通過外部Service進(jìn)行關(guān)聯(lián)。
• 貧血模型：老子知道兒子，兒子也知道老子；部分業(yè)務(wù)邏輯放到實(shí)體中；優(yōu)點(diǎn)：各層單項(xiàng)依賴，結(jié)構(gòu)清楚，易于維護(hù)；缺點(diǎn)：不符合OO思想，相比于充血模式，Service層較為厚重；
• 充血模型：和貧血模型類似，區(qū)別在于如何劃分業(yè)務(wù)邏輯。優(yōu)點(diǎn)：Service層比較薄，只充當(dāng)Facade的角色，不和DAO打交道、復(fù)合OO思想；缺點(diǎn)：非單項(xiàng)依賴，DO和DAO之間雙向依賴、和Service層的邏輯劃分容易造成混亂。
• 腫脹模式：是一種極端情況，取消Service層、全部業(yè)務(wù)邏輯放在DO中；優(yōu)點(diǎn)：符合OO思想、簡化了分層；缺點(diǎn)：暴露信息過多、很多非DO邏輯也會(huì)強(qiáng)行并入DO。這種模式應(yīng)該避免。
• 作者主張使用貧血模式。

Actor 模式

TODO

響應(yīng)式編程

Reactor

TODO

RxJava

TODO

Vert.x

TODO

DODAF2.0

• 《DODAF2.0方法論》
• 《DODAF2.0之能力視角如何落地》

Serverless

無需過多關(guān)系服務(wù)器的服務(wù)架構(gòu)理念。

• 《什么是Serverless無服務(wù)器架構(gòu)？》
• Serverless 不代表出去服務(wù)器，而是去除對(duì)服務(wù)器運(yùn)行狀態(tài)的關(guān)心。
• Serverless 代表一思維方式的轉(zhuǎn)變，從“構(gòu)建一套服務(wù)在一臺(tái)服務(wù)器上，對(duì)對(duì)個(gè)事件進(jìn)行響應(yīng)轉(zhuǎn)變?yōu)闃?gòu)建一個(gè)為服務(wù)器，來響應(yīng)一個(gè)事件”。
• Serverless 不代表某個(gè)具體的框架。
• 《如何理解Serverless？》
• 依賴于 Baas （(Mobile) Backend as a Service） 和 Faas （Functions as a service）

Service Mesh

• 《什么是Service Mesh？》
• 《初識(shí) Service Mesh》

項(xiàng)目管理

架構(gòu)評(píng)審

• 《架構(gòu)設(shè)計(jì)之如何評(píng)審架構(gòu)設(shè)計(jì)說明書》
• 《人人都是架構(gòu)師：非功能性需求》

重構(gòu)

• 《架構(gòu)之重構(gòu)的12條軍規(guī)》

代碼規(guī)范

• 《阿里巴巴Java開發(fā)手冊(cè)》

代碼 Review

制度還是制度! 另外，每個(gè)公司需要根據(jù)自己的需求和目標(biāo)制定自己的 check list

• 《為什么你做不好 Code Review？》
• 代碼 review 做的好，在于制度建設(shè)。
• 《從零開始Code Review》
• 《Code Review Checklist》
• 《Java Code Review Checklist》
• 《如何用 gitlab 做 code review》

RUP

• 《運(yùn)用RUP 4+1視圖方法進(jìn)行軟件架構(gòu)設(shè)計(jì)》

看板管理

• 《說說看板在項(xiàng)目中的應(yīng)用》

SCRUM

SCRUM - 爭球

• 3個(gè)角色:Product Owner(PO) 產(chǎn)品負(fù)責(zé)人;Scrum Master（SM），推動(dòng)Scrum執(zhí)行;Team 開發(fā)團(tuán)隊(duì)。
• 3個(gè)工件：Product Backlog 產(chǎn)品TODOLIST，含優(yōu)先級(jí);Sprint Backlog 功能開發(fā) TODO LIST；燃盡圖；
• 五個(gè)價(jià)值觀：專注、勇氣、公開、承諾、尊重。
• 《敏捷項(xiàng)目管理流程-Scrum框架最全總結(jié)！》
• 《敏捷其實(shí)很簡單3---敏捷方法之scrum》

敏捷開發(fā)

TODO

極限編程（XP）

XP - eXtreme Programming

• 《主流敏捷開發(fā)方法：極限編程XP》
• 是一種指導(dǎo)開發(fā)人員的方法論。
• 4大價(jià)值：
• 溝通：鼓勵(lì)口頭溝通，提高效率。
• 簡單：夠用就好。
• 反饋：及時(shí)反饋、通知相關(guān)人。
• 勇氣：提倡擁抱變化，敢于重構(gòu)。
• 5個(gè)原則：快速反饋、簡單性假設(shè)、逐步修改、提倡更改（小步快跑）、優(yōu)質(zhì)工作（保證質(zhì)量的前提下保證小步快跑）。
• 5個(gè)工作：階段性沖刺；沖刺計(jì)劃會(huì)議；每日站立會(huì)議；沖刺后review；回顧會(huì)議。

結(jié)對(duì)編程

邊寫碼，邊review。能夠增強(qiáng)代碼質(zhì)量、減少bug。

• 《結(jié)對(duì)編程》

PDCA 循環(huán)質(zhì)量管理

P——PLAN 策劃，D——DO 實(shí)施，C——CHECK 檢查，A——ACT 改進(jìn)

• 《PDCA》

FMEA管理模式

TODO

通用業(yè)務(wù)術(shù)語

TODO

技術(shù)趨勢(shì)

TODO