作業一：
一個典型的大型互聯網應用系統使用了哪些技術方案和手段，主要解決什麼問題？請列舉描述。
單機時代
應用服務器：Spring + Tomcat + Mybatis
此外，通過池化技術提高數據庫的 TPS 和 QPS
應用服務器：Spring + Tomcat + Mybatis + c3p0
數據庫：Mysql
瓶頸：服務經常宕機，可用性比較差。
雙機 HA
基於高可用的角度，
使用 keepalived 實現應用服務器和數據庫做 HA
瓶頸：應用服務器
應用集羣
反向代理：nginx
無狀態的應用服務：N 個
數據庫：HA
要點：
一、對於有狀態的服務涉及 Session 的處理。
- 反向代理支持 session 保持，但是應用服務器的增加和刪除，導致 session 失效
- 應用服務器之間進行 session 同步
- 部署 HA 或集羣模式的 session 服務器
- session 存在cookie中，右瀏覽器來告訴應用服務器 session，以此實現了session和應用服務器的解耦
二、動靜結合
1、靜態資源是用反向代理
2、靜態資源使用 CDN
3、靜態資源使用瀏覽器緩存
瓶頸：數據庫，讀寫比例失衡，超出數據庫處理能力
讀寫分離
絕大多數應用是讀多寫少，因此，進行讀寫分離。
反向代理：nginx
無狀態的應用服務：N 個
數據庫：HA + 多個從節點（3-5）
要點：
一、判斷主從延遲
1、 seconds_behind_master
2、點位法
3、 GTID 法
二、主從數據之間的延遲
1、強制走主庫法：對一致性低的，可以直接讀從節點；一致性高的，走主庫讀。
2、判斷主庫延遲法：對操作根據一致性的要求高度應用，通過判斷主庫延遲來決定讀從庫還是讀主庫。
3、半同步法
4、等主庫點位法
5、等 GTID 法
6、寫緩存法
三、訪問數據模式
1、三方依賴：ShardingJDBC、TDDL
2、代理層：MyCat、DBProxy
瓶頸：數據量很超過單機存儲能力。
分庫分表
反向代理：nginx
無狀態的應用服務：N 個
數據庫：HA + 多個從節點（3-5）+ 分庫 + 分表
要點：
1、全局唯一 ID：ID 發號器
2、分庫分表的邏輯：基於範圍、基於 hash
3、引入NoSQL：比如引入 ES 滿足特定場景的讀性能，HBase 滿足更大數據量的處理
引入緩存
反向代理：nginx
無狀態的應用服務：N 個
緩存：redis、memcached
數據庫：HA + 多個從節點（3-5）+ 分庫 + 分表
要點
一、緩存分離
本地緩存：guava、caffine、ehcache
分佈式緩存：redis、memcached
二、緩存更新套路
1、cache Aside
2、write through、read through
3、write back
三、緩存引入問題
1、熱點問題
2、緩存穿透
3、緩存擊穿
4、緩存雪崩
分佈式服務
反向代理：nginx
無狀態的應用服務：根據DDD 思想對服務精拆分
緩存：redis、memcached
數據庫：HA + 多個從節點（3-5）+ 分庫 + 分表
要點
1、服務治理：服務發現、配置中心、註冊中心、客戶端負載均衡、熔斷、限流、鏈路跟蹤等等服務治理手段。
2、DevOp、服務網格應對應用爆炸
3、引入消息中間件解耦。
數據驅動、智能化、中臺化
反向代理：nginx
無狀態的應用服務：根據DDD 思想對服務精拆分
緩存：redis、memcached
數據庫：HA + 多個從節點（3-5）+ 分庫 + 分表
數據分析：大數據平臺、AI 平臺
要點：
1、建立大數據技術對業務進行分析，找到業務數據的價值
2、引入機器學習、AI 技術賦能業務
3、AIops 簡化運維
4、Cloud Native
5、業務中臺、數據中臺、AI 中臺
參考
https://segmentfault.com/a/1190000018626163 細節還不夠
https://blog.csdn.net/jayxujia123/article/details/106731775
作業二：
根據當週學習情況，完成一篇學習總結
本週最大的收穫大概就是將進入阿里受挫的那段講解。
- 當前遇到的瓶頸期是自己成長的最快時期，突破了海闊天空。
- 發現問題比解決問題更加重要。想想google、facebook、阿里、京東、美團、頭條、拼多多的崛起無不是看問題的角度不一樣。發現問題，比解決問題更加重要。同樣的事情，高手更重要的是對問題的理解不一樣。今天看了人人網的發展歷程，不得不感慨，不是拿一副好牌就能贏。