1. 自黑式攻擊

1.1. 自黑只會偶爾成為人類的美德

1.2. 對系統來說，絕對不會推崇自黑

1.3. “自黑式攻擊”是指系統或有人類參與的擴展系統聯合外部對自身發起攻擊

1.4. 好的營銷可以隨時殺死你

1.5. 典型例子

2. 共享資源

2.1. 以面向服務的架構或“公共服務”專案為幌子，共享資源會成為水平擴展層級所有成員都需要使用的某個設施

2.2. 可以是集群管理器或鎖管理器

2.3. 當共享資源流量過載時，它會成為限制系統容量的瓶頸

2.4. 當共享資源有冗余且是非獨占的時，就沒有問題

2.5. 最具擴展性的架構是無共享架構

3. 避免自黑式攻擊

3.1. 構建無共享架構

3.2. 保護共享資源

3.3. 預留一部分基礎設施，或整備一些新的云資源，用于應對商業促銷或流量激增

3.4. 當訪問流量激增時，可以使用自動化擴展技術

3.5. 保持溝通渠道暢通

3.6. 快速地重新分配實惠的優惠

4. 放大效應

4.1. 生物學中的平方-立方定律

4.2. “多對一”或“多對少”的關系

5. 點對點通信

5.1. 放大效應“咬人最兇”的情況

5.2. 當只有一兩個實體進行通信時，機器之間的點對點通信可能作業得很好

5.3. 每個實體必須直接與其他實體進行溝通，連接的總數，會以實體數量平方的數量級上升

5.4. 連接數會擴展到時間復雜度O(n^2)

5.5. 務必將單個服務內的點對點通信，與服務之間的點對點通信區分開

5.6. 除非是微軟或谷歌這樣的公司，其他公司不可能構建與生產環境相同大小的測驗農場

5.7. 替換方式

讀發布！設計與部署穩定的分布式系統（第2版）筆記08_自黑與放大

1. 自黑式攻擊

1.1. 自黑只會偶爾成為人類的美德

1.2. 對系統來說，絕對不會推崇自黑

1.3. “自黑式攻擊”是指系統或有人類參與的擴展系統聯合外部對自身發起攻擊

1.4. 好的營銷可以隨時殺死你

1.4.1. 并不是每個自黑的“傷口”，都可以歸咎于營銷部門

1.5. 典型例子

1.5.1. 公司市場部發出的致“精選用戶組”的一份郵件

1.5.2. 該郵件包含一些特權或優惠資訊，其復制速度比木馬病毒快得多

1.5.3. 定價錯誤使得一個SKU的訂購次數等于其他所有產品的訂購總數

1.5.4. 在基于ATG的基礎設施中，鎖管理器總是會處理分布式鎖管理，以確保快取的一致性

1.5.4.1. 鎖管理器資源只有一個，隨著網站橫向擴展，鎖管理器會成為瓶頸，并且最侄訓成為風險

1.5.4.2. 如果一個熱門專案被無意修改，最終就可能會導致數以百計的服務器上出現數千個請求處理的執行緒，都在排隊等待該專案的寫入鎖

2. 共享資源

2.1. 以面向服務的架構或“公共服務”專案為幌子，共享資源會成為水平擴展層級所有成員都需要使用的某個設施

2.2. 可以是集群管理器或鎖管理器

2.3. 當共享資源流量過載時，它會成為限制系統容量的瓶頸

2.4. 當共享資源有冗余且是非獨占的時，就沒有問題

2.4.1. 可以同時為多個消費者提供服務

2.5. 最具擴展性的架構是無共享架構

2.5.1. 在無共享架構中，系統容量與服務器的數量幾乎呈線性關系

2.5.2. 無共享架構的問題在于，它會犧牲故障轉移來獲得更好的擴展性

2.5.3. 通過減少共享資源的扇入個數，可以近似實作無共享架構，即減少呼叫共享資源的服務器

3. 避免自黑式攻擊

3.1. 構建無共享架構

3.1.1. 在無共享架構中，每臺服務器在不知道任何其他服務器的情況下，仍然能夠運行

3.1.2. 服務器不共享資料庫、集群管理器或任何其他資源，這是水平擴展的理想狀態

3.1.3. 通過中間件模式減少過量請求造成的影響，或盡量通過冗余和后端同步協議，實作共享資源本身的水平擴展

3.1.4. 當共享資源不可用或沒有回應時，還可以為系統設計一個后備模式

3.1.5. 如果提供悲觀鎖的鎖管理器不可用，那么應用程式可以進入后備模式并使用樂觀鎖

3.2. 保護共享資源

3.2.1. 當流量激增時，編程錯誤、意外的放大效應和共享資源都會產生風險

3.2.2. 前端負載的增加，會導致后端處理量呈指數級增長

3.3. 預留一部分基礎設施，或整備一些新的云資源，用于應對商業促銷或流量激增

3.4. 當訪問流量激增時，可以使用自動化擴展技術

3.4.1. 注意服務器啟動的延遲時間

3.5. 保持溝通渠道暢通

3.5.1. 應對人為的攻擊，關鍵在于培訓、教育和溝通

3.6. 快速地重新分配實惠的優惠

3.6.1. 任何一個認為能限量發布特惠商品的人，都在自找麻煩

3.6.2. 根本就沒有限量分配這回事

3.6.3. 即使限制了一個超劃算的特惠商品可以購買的次數，系統仍然會崩潰

4. 放大效應

4.1. 生物學中的平方-立方定律

4.1.1. 蟲子的重量隨著體積增加而增加，符合時間復雜度O(n^3)

4.1.2. 蟲子的腿部力量會隨腿的橫截面積的增加而增加，符合時間復雜度O(n^2)

4.1.3. 如果讓蟲子增大為原來的10倍，那么變大后的蟲子的“力量與體重”之比就會變成原來的1/10

4.1.4. 蟲子的腿根本支撐不了10倍大的個頭

4.2. “多對一”或“多對少”的關系

4.2.1. 如果這個關系中一方的規模增大，另一方就會受到放大效應的影響

4.2.2. 由于開發環境和測驗環境的規模很少會與生產環境一致，因此很難在前兩個環境中，看到放大效應跳出來“咬人”

4.2.3. 1臺資料庫服務器被10臺機器呼叫時，可以很好地運行

4.2.4. 呼叫它的機器數量再額外添加50臺時，資料庫服務器就可能會崩潰

5. 點對點通信

5.1. 放大效應“咬人最兇”的情況

5.2. 當只有一兩個實體進行通信時，機器之間的點對點通信可能作業得很好

5.3. 每個實體必須直接與其他實體進行溝通，連接的總數，會以實體數量平方的數量級上升

5.4. 連接數會擴展到時間復雜度O(n^2)

5.5. 務必將單個服務內的點對點通信，與服務之間的點對點通信區分開

5.6. 除非是微軟或谷歌這樣的公司，其他公司不可能構建與生產環境相同大小的測驗農場

5.6.1. 這種型別的軟體缺陷是不可能被測驗出來的，必須通過設計來避免

5.6.2. 參照測驗環境檢查生產環境，以發現放大效應

5.7. 替換方式

5.7.1. UDP廣播

5.7.1.1. 廣播能夠應對服務器數量的不斷增長，但它不節省帶寬

5.7.1.2. 與廣播訊息不相關的服務器產生一些額外的負載

5.7.2. TCP或UDP組播

5.7.2.1. 只允許相關的服務器接收訊息，傳送效率更高

5.7.3. 發布-訂閱訊息傳遞

5.7.3.1. 服務器在訊息發送的那一刻沒有監聽，也可以收到訊息

5.7.3.2. 傳遞的效率也較高

5.7.3.3. 通常會讓基礎設施成本大增

5.7.4. 訊息佇列

5.7.5. 在所有可行的方案中，選擇最簡單的那個來做