主要的知識：
redis集羣+storm集羣+nginx+tomcat+mysql
真正能支撐高併發以及高可用的複雜系統中的緩存架構有哪些東西？
（1）如何讓redis集羣支撐幾十萬QPS高併發+99.99%高可用+TB級海量數據+企業級數據備份與恢復？：redis企業級集羣架構
（2）如何支撐高性能以及高併發到極致？同時給緩存架構最後的安全保護層？：(nginx+lua)+redis+ehcache的三級緩存架構
（3）高併發場景下，如何解決數據庫與緩存雙寫的時候數據不一致的情況？：企業級的完美的數據庫+緩存雙寫一致性解決方案
（4）如何解決大value緩存的全量更新效率低下問題？：緩存維度化拆分解決方案
（5）如何將緩存命中率提升到極致？：雙層nginx部署架構，以及lua腳本實現的一致性hash流量分發策略
（6）如何解決高併發場景下，緩存重建時的分佈式併發重建的衝突問題？：基於zookeeper分佈式鎖的緩存併發重建解決方案
（7）如何解決高併發場景下，緩存冷啓動MySQL瞬間被打死的問題？：基於storm實時統計熱數據的分佈式快速緩存預熱解決方案
（8）如何解決熱點緩存導致單機器負載瞬間超高？：基於storm的實時熱點發現，以及毫秒級的實時熱點緩存負載均衡降級
（9）如何解決分佈式系統中的服務高可用問題？避免多層服務依賴因爲少量故障導致系統崩潰？：基於hystrix的高可用緩存服務，資源隔離+限流+降級+熔斷+超時控制
（10）如何應用分佈式系統中的高可用服務的高階技術？：基於hystrix的容錯+多級降級+手動降級+生產環境參數優化經驗+可視化運維與監控
（11）如何解決恐怖的緩存雪崩問題？避免給公司帶來巨大的經濟損失？：獨家的事前+事中+事後三層次完美解決方案
（12）如何解決高併發場景下的緩存穿透問題？避免給MySQL帶來過大的壓力？：緩存穿透解決方案
（13）如何解決高併發場景下的緩存失效問題？避免給redis集羣帶來過大的壓力？緩存失效解決方案
一些感悟
像老師所言，redis，memcached，activemq等等很多技術，如果只會簡單的操作，其實是很喫虧的，起碼我們需要想明白幾個問題：
1.我們爲什麼要用這個東西？（這個真的很重要，但是好像以前學習的時候，沒有去想）
2.我們應該在什麼場景下使用這個東西，應該怎麼使用
3.這個東西是怎麼解決我們面對的問題的（內部是怎麼實現的）
4.學了之後怎麼用，企業級的系統怎麼結合知識去實踐
小型電商網站的架構以及瓶頸
小型電商如果使用頁面靜態化的架構：
如果模板改變了，如果是全量渲染，那麼需要重新把所有的數據都渲染一遍，生成html，這樣工作量會特別大。
如果不是全量渲染，那麼來一個渲染一個再返回，假設請求量突然增加，那麼就會導致網站請求超時。
頁面靜態化：利用動態技術生成HTML頁面，來一個請求，返回一個頁面（已經渲染好），這樣的好處是：
1.加快頁面打開瀏覽速度，靜態頁面無需連接數據庫打開速度較動態頁面有明顯提高；
2.有利於搜索引擎優化SEO
3.減少服務器的負擔，瀏覽網頁不需要調用系統的數據庫服務器。
4.網站更加安全，減少注入的可能性。
缺點當然也有：
1.交互性差，功能上有所限制
2.佔用硬盤資源
3.不是很靈活，靜態化需要開關，這個需要專門設計。
頁面少的時候，可以使用上面這一套，但是如果頁面很多，上億的量，一個模板修改，重新渲染消耗太多時間。
大電商網站的系統架構
從最左邊開始，各種服務可能最底層直接依賴了mysql，如果這些服務的數據有變更，那麼就直接寫到MQ消息隊列中。
數據緩存生產服務監聽MQ，不斷更新緩存的數據。這個數據緩存生產服務可能會使用ehcache等。這個ehcache會把數據放到redis中，到這裏就結束了。這樣ehcache，redis就會一直保持着最新的數據，與數據庫同步。特殊情況ehcache也會去直接查詢數據庫。
監聽MQ，能及時監聽到修改，更新ehcache，更新到redis。緩存的數據需要設置過期時間。
前端如果有訪問nginx去本地緩存中查詢數據，填充到模板中返回。
如果緩存中沒有，會去redis查詢緩存，查到了寫一份本地緩存，渲染模板，返回。
但是如果redis也沒有，怎麼辦？nginx直接去查詢ehcache，查詢到之後，寫一份到redis，寫到本地緩存，填充，返回。
如果html模板變了，那麼不需要全部都渲染，只需要將模板放到nginx服務器上就可以了，因爲這樣直接用緩存是很快的，來一個渲染一個。沒有網絡的開銷，沒有業務邏輯，渲染到模板中，html頁面返回。
兩者的區別
小電商由於沒有緩存服務，那麼不可能每一個請求來之後，再去查詢數據庫，查到數據之後再渲染得到模板，這樣的話業務處理，網絡開銷很費時間。但是如果採取全量渲染的話，量多的情況下就需要渲染很長時間。
大電商結構，採取緩存，相當於加了很多中間層，緩存的速度是特別快的，所以就不需要全量渲染，所以應該保證數據的新鮮度就就可以了。所以在中間用了ehcache和redis等。
感覺有點像計算機系統的設計結構（不夠快，加一層）
高併發
同一時間數量極大的訪問量。
QPS:每秒鐘的請求量（Query Per Second）
高可用性
網站能夠迴應訪問，正常運行，就是可用狀態，各種宕機，服務器掛了，就是不可用狀態。
99.99%可用性就是：一年365天中，有99.99%的時間是可用的。
注：主要來自中華石衫課程學習筆記