基本內容：秒殺系統瓶頸分析、系統部署架構、應用伺服器叢集化後的session問題、nginx負載均衡演算法、XSS與CSRF、正向代理與反向代理、Http一次通訊過程、兩類springs事務、結構體的大小與記憶體對齊。

瓶頸：

    不是mysql慢，也不是java慢。而是事務在Java客戶端執行：{傳送第i條語句給mysql，等待mysql執行結果，根據業務邏輯判斷執行第i+1條語句|commit|rollback操作}。傳送一條sql語句與等待該語句執行結果存在相對很大的網路延遲，由於mysql執行事務會加鎖，因此鎖的持有時間會很長，導致系統併發度降低。

解決思路:減少鎖的持有時間。

    深度優化：在mysql端執行事務。1.通過儲存過程實現引數傳遞，在儲存過程內部執行事務。2.客戶端呼叫儲存過程即可。

系統部署架構：

    1.用CDN做靜態資源快取(css,js,圖片，靜態模板)，CDN一般部署在離使用者最近的結點(網路跳數最少)。

    2.用nginx做負載均衡伺服器。

    3.jetty，tomcat服務叢集。即業務程式碼開發的地方。

    4.用redis叢集做後端快取層。

    5.mysql資料庫儲存層。分庫(專庫專用)/分表(垂直，水平)/分片。主從結構。

    6.hadoop叢集對資料進行統計分析。

應用伺服器叢集化後的session問題

(1)Session Sticky策略。把請求固定分發到某臺web伺服器上，主要有ip_hash演算法或者通過SessionId對映。

   (2)Session Replication。把Session資訊同步儲存到所有web伺服器上，可以解決單點問題。問題：帶來session同步的額外開銷；每臺web伺服器要儲存所有的session資料，佔用空間。session複製方案適合於叢集節點數不太多的場景。

   (3)Session集中儲存，用一臺伺服器專門用來儲存Session資訊，其它各web伺服器向該伺服器獲取Session。問題：引入額外的web伺服器與Session伺服器的網路通訊。

   (4)把Session儲存在Cookie中。Session實體儲存在客戶端。問題：客戶端對Cookie有大小限制；沒有實現物理上的隔絕，可能有潛在的不安全性。

5類nginx負載均衡演算法：

    (1)輪訓。

    (2)加權輪詢。考慮到各結點效能不一，更合理利用伺服器資源。

    (3)ip_hash。對ip進行hash，同一個IP的訪客固定訪問一臺的伺服器，可以避免session共享問題。

    (4)url_hash。對url進行hash，使每個url定向到一臺伺服器上。

    (5)fair。按伺服器響應時間來分配請求，優先分配給響應時間短的。

XSS與CSRF

    XSS：攻擊者把惡意程式碼提交到後端伺服器，由後端伺服器渲染顯示給正常訪問者。

    CSRF：惡意網站竊取訪問者的cookie資訊，然後冒充訪問者傳送請求。解決方案：token隱藏域。

正向代理與反向代理

在正向代理中，代理伺服器與客戶端同屬一個LAN，對服務端透明。

   在反向代理中，代理伺服器與服務端同屬一個LAN，對客戶端透明。反向代理也可以實現負載均衡功能，也在做靜態資源快取。

Http一次通訊過程：

    建立tcp連線，發起請求，服務端解析、處理請求得到資料模型，用資料模型對檢視進行渲染，返回渲染後的內容，釋放連線。

Spring事務管理：

    (a)5種spring事務隔離級別：default，未提交讀，提交讀，可重複讀，序列化。default取決於底層資料庫，sqlserver和oracle是提交讀，mysql是可重複讀。

C語言結構體大小與記憶體對齊：

    結構體大小不是簡單的成員累加，涉及到填充對齊。1.第一個成員偏移量是0；2.每個成員的偏移量是該成員大小的倍數，不夠則需要在該成員前面填充；3.結構體大小是最大成員的倍數，不夠則需要在最後一個成員後面進行填充。

大端、小端儲存：

    大端：高位在低地址，低位在高地址。小端：高位在高地址，低位在低地址，和我們的邏輯方法一致。百度百科。

參：大型分散式網站架構設計與實踐

https://www.imooc.com/article/20110?block_id=tuijian_wz

https://www.cnblogs.com/lvgg/p/6140584.html

https://www.cnblogs.com/sss4/p/7106084.html

https://www.cnblogs.com/Anker/p/6056540.html