1 題外話和系統設計無關的
內存映射問題
一個進程虛擬地址 2^64/2^32 (64和32取決於計算機多少位)，虛擬地址裏面分段，每段裏面分頁
每個進程都只知道自己存在，以爲自己是計算機唯一存在的
邏輯地址 假設20 -> 線性地址-> 1000(段基地址) + 20(偏移量) -> 物理地址 (LRU分頁替換等)
C
預處理 -> 彙編 -> 鏈接 -> 生成可執行代碼(二進制)
這個編譯器教學講得是我看到的最好的，就是有點長，大二的時候看了兩遍，現在都忘差不多了
2 單點登錄問題
爲什麼會有單點登錄問題？
不同頁面登錄一個，其他頁面自動登錄
以前用session解決單點登錄問題，在現在Nginx集羣下不行了。衍生出3種解決方法
1 iphash
Nginx下 ip綁定一個服務器，以後所有這個ip請求都只走同一個服務器
2 同步session
但是有網路延遲，併發不能太高。不同的微服務下，不在同一集羣，session無法同步
3 redis/第三方緩存 (主流，百分之90使用)
1 user 登錄淘寶時，會put Map<key: 唯一值如UUID，value: user信息>到redis
2 put完後把key值返回user (cookie/localstore/session)
3 user 再次登錄天貓時候，通過(cookie/localstore/session)拿到key直接登錄
3 第三方登錄問題
通過QQ登錄百度網盤
1 user發送請求到百度網盤 (通過QQ登錄，但是百度網盤不能知道QQ信息)
2 百度網盤重定向，引導用戶到QQ登錄頁面
3 QQ校驗賬號密碼，狀態碼callback，狀態碼只用一次，有效期很短，只能callback地址用
4 QQ響應狀態碼給callback地址給百度網盤
5 百度網盤用狀態碼去換取token (token能存和加密user信息，有有效期)
6 QQ返回token給百度網盤
4 SSL非對稱加密
起初是對稱加密，交易雙方都使用同樣鑰匙，安全性得不到保證，所以非對稱加密誕生了
一個服務器通過公鑰加密再通過私鑰解密。公鑰是依賴於私鑰，通過私鑰生成
1 發送數據時： 數據+加密算法，被攔截下因爲沒有解密算法無法獲得數據
2 直接發送私鑰解密會數據泄露，所以需要第三方CA機構認證(收集企業信息，域名，公鑰)
3 客服端生成隨機數，利用CA公鑰再次加密。服務器拿私鑰解密拿到隨機數，雙方利用該隨機數作爲鑰匙進行以後通訊
5 設計高併發系統架構
設計高併發主要爲了降低TPS/QPS問題。最重要的要首先在上層能夠承受請求，然後再設計處理請求
地域上負載均衡：DNS
硬件上負載均衡：F5 集羣之間負載均衡
軟件上負載均衡：LVS，Nginx主機之間負載均衡
DNS，F5不是重點略過了
緩衝，緩存，複用，分治，親密粘性，負載均衡
降低QPS，可以一次請求多個css而不是一個css，可以使用雪碧圖(一個大圖包含多個小圖然後css切割小塊使用)
1 第一層LVS集羣承受10萬+QPS壓力，承受流量壓力。
使用LVS服務端負載均衡，keepalived集羣LVS
LVS用來承受流量壓力，Nignx層拿握手，後面再應用計算
爲什麼LVS性能高到能承受第一輪海量併發，而不是使用Nginx？
LVS在傳輸層，Ngnix在應用層。LVS沒有應用層的額外開銷，性能大大提升
LVS在傳輸層，負載均衡服務器，數據包轉發級別，不需要和客戶端三次握手
Nginx在應用層有會話，上下文，http的response，require等額外開銷
LVS具體原理
局域網內會通過NAT路由器，轉換IP地址的交換機
LVS原理類似NAT交換機，有三種IP交換實現策略
1 VS/DR (Virtual Server vs Direct ROuting)
通過改寫MAC地址，將請求發到真實服務器上，直接相應客戶，不再需要IP隧道的開銷。但要求調度器和真實服務器都有一塊網卡連在同一物理網段上
2 VS/NAT
調度器重寫請求報文目標地址，通過調度算法請求發送到真實服務器上。服務器響應後通過調度器，再次重寫報文源地址返回客戶
3 VS/TUN
使用NAT時，請求和響應都要調度器重寫，當請求太大時，調度器承受不了，所以調度器把請求報文通過IP隧道發送到真實服務器響應。所以調度器只處理請求報文，集羣吞吐量上升10倍。
2 CDN和FastDFS
FastDFS集羣保存靜態文件
FastDFS開源輕量級分佈式文件系統
Tracker跟蹤器類似HDFS的NameNode，storage儲存節點類似HDFS的DataNode
FastDFS和HDFS區別，FastDFS存文件不是雲計算，只面向文件上傳和下載
HDFS我在之前文章專門寫過
CDN從FastDFS中拉取數據
內容分發網絡
使用戶就近獲取所需要的內容，減少網絡阻塞，提高訪問響應
CDN依靠部署在各地邊緣服務器，包括中心平臺負載均衡，內容分發，調度等功能模塊
比如下載Jquery庫，通過CDN分析從就近節點上快速下載下來
3 第二層Nginx集羣網關層承受1萬QPS壓力，承受三次握手壓力
相比較Apache，Apache穩定成熟，輕量級，佔內存少，一個請求一個進程同步阻塞。
Nginx異步非阻塞，多個請求對應一個進程，社區活躍
在Nginx集羣層：本地緩存(存靜態頁面)，動靜分離(靜態頁面直接讀Nginx)，反向代理，負載均衡
4 微服務架構業務網關層
微服務和SOA區別？ -> SOA服務偏業務劃分，微服務功能服務劃分，微服務比SOA更細膩
如SpringCloud下Zuul網關組件
zuul 網關，整體管理
http超時，routes path xxx下都走該網關等
處理權限系統和單點登錄
Eureka(concurrentHashMap<String,Lease~心跳續約對象(註冊信息，過期時間等)>)/zookeeper
Feign/Dubbo 遠程調用RPC
Feign：
一端
@FeignClient(name="yunyun")
public interface yunyun{}
另一端
@Autowired
yunyun yun;
~create(){
直接調用yun下的方法
}
Ribbon 客戶端負載均衡
hystrix 容錯-限流，熔斷，降級
Stream 消息驅動 (如中間加MQ解耦)
View渲染(JSON,FreeMarker等)
5 額外具體業務層削峯
一些思路舉例
1 熔斷
2 降級
前端層面：使用本地緩存，使用假數據，JS訪問不到直接不發送數據，靜態化降級
後端層面：平時Redis+DB，高峯時Redis+kafka等消息隊列削峯+DB
3 限流
壓測計算每秒請求消耗時間，桶令牌限流，
4 每個業務層級AKF設計+主從+集羣
5 通過redis等緩存，請求不輕易走到數據庫層面
6 循環闌珊，倒計數器等多線程處理業務
7 Hadoop分佈式並行加快處理業務速度等