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. 在所有可行的方案中，選擇最簡單的那個來做