目錄
第一版 單台伺服器應用
第二版 應用伺服器和資料庫伺服器分離
第三版 應用伺服器集群
第四版 負載均衡器
第五版 資料庫伺服器集群
第六版 搜尋引擎集群
第七版 快取伺服器
第八版 資料庫水平/垂直拆分
第九版 應用伺服器垂直拆分
第十版 soa服務（分布式架構）
本節會學習以下內容：
出現以下問題：
由於流量越來越大出現伺服器效能問題。
對架構增加了一台伺服器，應用和資料庫分別部署到不同的伺服器上，對於開發和測試沒有任何影響，只需要應用伺服器新增乙個遠端呼叫資料庫伺服器的連線，有效的緩解了應用伺服器負載的壓力。
出現以下問題：
隨著請求流量得進一步增大出現應用伺服器效能問題。
流量請求得到緩解。
應用伺服器集群後出現以下問題：
1.需要使用session+cookie維護使用者
2.如何做請求**（cdn，前端做負載均衡器）
1.負載均衡器優化了訪問請求在伺服器組之間的分配，消除了伺服器之間的負載不平衡，從而提高了系統的反應速度與總體效能；
2.負載均衡器可以對伺服器的執行狀況進行監控，及時發現執行異常的伺服器，並將訪問請求轉移到其它可以正常工作的伺服器上，從而提高伺服器組的可靠性採用了負均衡器器以後，可以根據業務量的發展情況靈活增加伺服器，系統的擴充套件能力得到提高，同時簡化了管理。
負載均衡器之後出現以下問題：
隨著流量的新增，資料庫伺服器有效能壓力，資料庫遇到瓶頸。
資料庫伺服器集群後出現以下問題：
1.資料庫讀寫分離
2.資料庫資料同步
3.資料庫路由
搜尋引擎集群後出現以下問題：
1.搜尋引擎的索引資料如何同步，實時增量or定時全量？
使用者量是沒有上限的
快取、 限流、 降級
注：架構到了第七版還不能算分布式架構，只能說是由多台伺服器組成的高可用的架構
目前將資料庫進行垂直拆分，還未進行資料庫水平拆分（比如將訂單表分庫分表就屬於水平拆分）
以**為例：
user.taobao.com
product.taobao.com
order.taobao.com
根據不同網域名稱請求訪問不同伺服器，如果涉及到使用者需要查詢商品或訂單，直接在使用者伺服器裡寫dao層查詢商品或訂單資料庫表。
產生問題：應用伺服器互動呼叫問題。
從分布式分析引擎到分布式儲存
事因偶然，開始了apache storm原始碼的閱讀歷程，即而了解到apache spark一時風頭無兩，又一頭墜入到無比陌生的scala世界，開始了艱澀的spark原始碼閱讀之路。閱讀不是目的，用這些工具來解決實際中的問題才是根本，恰好由於通訊公司利潤下降，行業景氣度不如之前，人心思變，於是在沒做...
從分布式分析引擎到分布式儲存
事因偶然，開始了apache storm原始碼的閱讀歷程，即而了解到apache spark一時風頭無兩，又一頭墜入到無比陌生的scala世界，開始了艱澀的spark原始碼閱讀之路。閱讀不是目的，用這些工具來解決實際中的問題才是根本，恰好由於通訊公司利潤下降，行業景氣度不如之前，人心思變，於是在沒做...
從 分布式論壇 到 分布式資料庫
從 分布式論壇 到 分布式資料庫 如果有分布式資料庫，實現分布式論壇也許很容易，寫法與傳統的論壇系統完全一樣就行了 這裡說的 分布式 是一種鬆散的分布式，不像乙個機房裡多台伺服器協作組成乙個更大的邏輯伺服器 這些伺服器是穩定而且高速連線的 而這裡說的 分布式 是由一組普通的網際網路上的pc組成的，它...