發展背景
1、單一應用架構：一個應用將所有功能部署在一起，減少部署結點和成本
2、垂直應用架構：訪問量逐漸增大，單一應用的加速度越來越小，將應用拆分成互不相干的幾個應用，提升效率
3、分佈式服務架構：垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作爲獨立的服務，逐漸形成穩定的服務中心
什麼是分佈式系統
分佈式系統是若干個獨立計算機的集合，這些計算機對於用戶來說就像是單個相關係統。
從進程角度看，兩個進程分別運行在兩臺主機上，他們相互協作最終完成一個功能，那麼理論上這兩個程序組成的系統，可以稱作是“分佈式系統”
分佈式和微服務的區別：
微服務架構偏向於業務，比如可以將系統按照子業務、數據庫、接口不同的維度劃分成不同的微服務
分佈式系統偏向於機器，目前可以說微服務架構是分佈式架構，因爲大部分公司把每個服務部署在不同的機器上
分佈式會遇到的問題
1、分佈式session
解決方案：
1、session粘滯：當用戶訪問集羣中某一臺機器後，強制指定後續所有請求均落到此機器上
使用場景：機器數適中、對穩定性要求不是非常苛刻
優點：實現簡單、配置方便、沒用額外的網絡開銷
缺點：網絡中有機器down掉時，用戶session會丟失，容易造成單點故障
方案：nginx中的ip_hash負載均衡方法
2、session複製：將一臺機器上的session複製廣播到集羣中其他機器上
使用場景：機器較少、網絡流量較少
優點：實現簡單、配置較少、當網絡中有機器down時不影響用戶訪問
缺點：廣播式複製到其他機器有一定的延時，帶來一定的網絡開銷
方案：開源方案tomcat-redis-session-manager 暫不支持tomcat8
3、緩存集中式管理：將session存入分佈式緩存集羣中的某臺機器上，當用戶訪問不同結點時先從緩存中拿session信息
使用場景：集羣中機器多、網絡環境複雜
優點：可靠性好
缺點：實現複雜、穩定性依賴於緩存的穩定性、session信息放入緩存時要有合理的策略寫入
方案：開源方案spring session,也可以自己實現，重點重寫HttpServletRequestWrapper中的getSession方法
2、分佈式配置中心
在分佈式系統中，一次構建、發佈、上線是一個非常重要的過程，它不像單機時代重啓一臺機器就行，在分佈式系統中，它涉及到將軟件包發佈到超過幾千臺的機器，然後將幾千臺機器一個一個重啓。所以從這個角度看，我們認爲每一個大型分佈式系統都應該有一個配置中心
常見的分佈式配置變更：
- 線程池、連接池大小
- 開關限流配置
- 數據源主備容災切換
- 路由規則
開源解決方案：
- disconf 百度開源
- diamond 阿里開源
- zookeeper 成熟的分佈式配置解決方案
- 等等
3、分佈式事務
分佈式事務解決的最本質的訴求是數據一致性
比如零售行業，庫存與出貨的數據一致
比如金融行業，轉賬賬戶數據一致
幾個典型的解決方案：
- XA事務方案
- 柔性事務
- 基於消息的最終一致
- 業務補償與人工定正
4、分佈式鎖
分佈式的CAP理論告訴我們，任何一個分佈式系統都無法同時滿足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance）
CAP最多同時滿足兩項
常見的解決方案：
- mysql
- 內存數據庫（redis、memcached等）
- zookeeper
zookeeper介紹
1、下載與安裝
下載地址：https://zookeeper.apache.org/
1.1 解壓
1.2 配置
進入conf文件夾，找到zoo_sample.cfg文件，並複製爲zoo.cfg
1.3 配置文件解釋
tickTime：zookeeper服務器之間或客戶端與服務器之間維持心跳的時間間隔，也就是每個tickTime時間會發送一個心跳
initLimit：Follower在啓動過程中，會從Leader同步所有最新數據，然後確定自己能夠對外服務的起始狀態。Leader允許Follower在initLimit時間內完成這個工作。
syncLimit：在運行過程中，Leader負責與集羣中其他機器進行通訊，如果Leader發出心跳包syncLimit時間後，沒有收到Follower的響應，就認爲Follower不存在了。
dataDir：存儲快照文件目錄
2、集羣中的角色
領導者：負責 進行投票的發起和決議，最終更新狀態
跟隨着：用於接收客戶請求並返回客戶結果
觀察者：可以接收客戶端連接，將寫請求轉發給領導者結點，但觀察者不參與投票，只同步領導者的狀態