序
前言


第1部分 數(shù)據(jù)持久化層場景實戰(zhàn)

第1章 冷熱分離/
1.1 業(yè)務場景：幾千萬數(shù)據(jù)量的工單表如何快速優(yōu)化/
1.2 數(shù)據(jù)庫分區(qū)，從學習到放棄/
1.3 冷熱分離簡介/
1.3.1 什么是冷熱分離/
1.3.2 什么情況下使用冷熱分離/
1.4 冷熱分離一期實現(xiàn)思路：冷熱數(shù)據(jù)都用MySQL/
1.4.1 如何判斷一個數(shù)據(jù)到底是冷數(shù)據(jù)還是熱數(shù)據(jù)/
1.4.2 如何觸發(fā)冷熱數(shù)據(jù)分離/
1.4.3 如何分離冷熱數(shù)據(jù)/
1.4.4 如何使用冷熱數(shù)據(jù)/
1.4.5 歷史數(shù)據(jù)如何遷移/
1.4.6 整體方案/
1.5 冷熱分離二期實現(xiàn)思路：冷數(shù)據(jù)存放到HBase/
1.5.1 冷熱分離一期解決方案的不足/
1.5.2 歸檔工單的使用場景/
1.5.3 HBase原理介紹/
1.5.4 HBase的表結構設計/
1.5.5 二期的代碼改造/
1.6 小結/

第2章 查詢分離/
2.1 業(yè)務場景：千萬工單表如何實現(xiàn)快速查詢/
2.2 查詢分離簡介/
2.2.1 何為查詢分離/
2.2.2 何種場景下使用查詢分離/
2.3 查詢分離實現(xiàn)思路/
2.3.1 如何觸發(fā)查詢分離/
2.3.2 如何實現(xiàn)查詢分離/
2.3.3 查詢數(shù)據(jù)如何存儲/
2.3.4 查詢數(shù)據(jù)如何使用/
2.3.5 歷史數(shù)據(jù)遷移/
2.3.6 MQ Elasticsearch的整體方案/
2.4 Elasticsearch注意事項/
2.4.1 如何使用Elasticsearch設計表結構/
2.4.2 Elasticsearch的存儲結構/
2.4.3 Elasticsearch如何修改表結構/
2.4.4 陷阱一：Elasticsearch是準實時的嗎/
2.4.5 陷阱二：Elasticsearch宕機恢復后，數(shù)據(jù)丟失/
2.4.6 陷阱三：分頁越深，查詢效率越低/
2.5 小結/

第3章 分表分庫/
3.1 業(yè)務場景：億級訂單數(shù)據(jù)如何實現(xiàn)快速讀寫/
3.2 拆分存儲的技術選型/
3.2.1 MySQL的分區(qū)技術/
3.2.2 NoSQL/
3.2.3 NewSQL/
3.2.4 基于MySQL的分表分庫/
3.3 分表分庫實現(xiàn)思路/
3.3.1 使用什么字段作為分片主鍵/
3.3.2 分片的策略是什么/
3.3.3 業(yè)務代碼如何修改/
3.3.4 歷史數(shù)據(jù)如何遷移/
3.3.5 未來的擴容方案是什么/
3.4 小結/


第2部分 緩存層場景實戰(zhàn)

第4章 讀緩存/
4.1 業(yè)務場景：如何將十幾秒的查詢請求優(yōu)化成毫秒級/
4.2 緩存中間件技術選型(Memcached,MongoDB,Redis)/
4.3 緩存何時存儲數(shù)據(jù)/
4.4 如何更新緩存/
4.4.1 組合1：先更新緩存，再更新數(shù)據(jù)庫/
4.4.2 組合2：先刪除緩存，再更新數(shù)據(jù)庫/
4.4.3 組合3：先更新數(shù)據(jù)庫，再更新緩存/
4.4.4 組合4：先更新數(shù)據(jù)庫，再刪除緩存/
4.4.5 組合5：先刪除緩存，更新數(shù)據(jù)庫，再刪除緩存/
4.5 緩存的高可用設計/
4.6 緩存的監(jiān)控/
4.7 小結/

第5章 寫緩存/
5.1 業(yè)務場景：如何以小代價解決短期高頻寫請求/
5.2 寫緩存/
5.3 實現(xiàn)思路/
5.3.1 寫請求與批量落庫這兩個操作同步還是異步/
5.3.2 如何觸發(fā)批量落庫/
5.3.3 緩存數(shù)據(jù)存儲在哪里/
5.3.4 緩存層并發(fā)操作需要注意什么/
5.3.5 批量落庫失敗了怎么辦/
5.3.6 Redis的高可用配置/
5.4 小結/

第6章 數(shù)據(jù)收集/
6.1 業(yè)務背景：日億萬級請求日志收集如何不影響主業(yè)務/
6.2 技術選型思路/
6.2.1 使用什么技術保存埋點數(shù)據(jù)的現(xiàn)場/
6.2.2 使用什么技術收集日志數(shù)據(jù)到持久化層/
6.2.3 為什么使用Kafka/
6.2.4 使用什么技術把Kafka的數(shù)據(jù)遷移到持久化層/
6.3 整體方案/
6.4 小結/

第7章 秒殺架構/
7.1 業(yè)務場景：設計秒殺架構必知必會的那些事/
7.2 整體思路/
7.2.1 瀏覽頁面如何將請求攔截在上游/
7.2.2 下單頁面如何將請求攔截在上游/
7.2.3 付款頁面如何將請求攔截在上游/
7.2.4 整體服務器架構/
7.3 小結/


第3部分 基于常見組件的微服務場景實戰(zhàn)

第8章 注冊發(fā)現(xiàn)/
8.1 業(yè)務場景：如何對幾十個后臺服務進行高效管理/
8.2 傳統(tǒng)架構會出現(xiàn)的問題/
8.2.1 配置煩瑣，上線容易出錯/
8.2.2 加機器要重啟/
8.2.3 負載均衡單點/
8.2.4 管理困難/
8.3 新架構要點/
8.3.1 中心存儲服務使用什么技術/
8.3.2 使用哪個分布式協(xié)調服務/
8.3.3 基于ZooKeeper需要實現(xiàn)哪些功能/
8.4 ZooKeeper宕機了怎么辦/
8.5 小結/

第9章 全鏈路日志/
9.1 業(yè)務場景：這個請求到底經歷了什么/
9.2 技術選型/
9.2.1 日志數(shù)據(jù)結構支持OpenTracing/
9.2.2 支持Elasticsearch作為存儲系統(tǒng)/
9.2.3 保證日志的收集對性能無影響/
9.2.4 查詢統(tǒng)計功能的豐富程度/
9.2.5 使用案例/
9.2.6 終選擇/
9.3 注意事項/
9.3.1 SkyWalking的數(shù)據(jù)收集機制/
9.3.2 如果SkyWalking服務端宕機了，會出現(xiàn)什么情況/
9.3.3 流量較大時，如何控制日志的數(shù)據(jù)量/
9.3.4 日志的保存時間/
9.3.5 集群配置：如何確保高可用/
9.4 小結/

第10章 熔斷/
10.1 業(yè)務場景：如何預防一個服務故障影響整個系統(tǒng)/
10.1.1 個問題：請求慢/
10.1.2 第二個問題：流量洪峰緩存超時/
10.2 覆蓋場景/
10.3 Sentinel 和Hystrix/
10.4 Hystrix的設計思路/
10.4.1 線程隔離機制/
10.4.2 熔斷機制/
10.4.3 滾動（滑動）時間窗口/
10.4.4 Hystrix調用接口的請求處理流程/
10.5 注意事項/
10.5.1 數(shù)據(jù)一致性/
10.5.2 超時降級/
10.5.3 用戶體驗