分佈式程序設計

本資料只是我的研究，無實際操做

解決問題切分功能

• 負載均衡
  • IO均衡
    • 網絡IO
    • 日誌IO
    • 存儲IO
  • 數據共享
    • 只讀共享
    • 更改推送
    • 併發控制
    • 會話共享
  • 多機協調工做
    • 中心服選舉
    • 線上註冊節點
      
    • 程序異常處理
    • 請求異常容錯處理
    • 交互優先訪問相鄰節點
• 數據挖掘
  • 實時分析
  • 異步分析
  • 分析任務分發
  • 統計收集
  • 領域分析
• 物理存儲容災
  • 方案1 mysql 主從服
  • 方案2 定時備份數據庫
  • 方案3 定時鏡像mysql 物理儲存文件
  • 方案4 物理盤作陣列

切分設計說明

設計原則

• 按用戶規模設計
• 按實際需求設計
• 潛在問題同將來可預測問題分析設計

程序員比較關注的是功能正常運行，業務邏輯會不會出錯。底層通訊、協調、物理容災是不關心的，我認爲物理容災交給運維同事負責比較好，他們或者會想出更好方案，數據挖掘是後期工做，前期只設計支持模型.
而咱們只負責負載均衡部份
什麼樣的程序須要分佈式？

• 大規模用戶
  • 單個應用支撐用戶數1W人
  • 單個應用內存佔4G運行空間
  • 單物理服每秒寬帶
  • 開物理服 = 預測需求用戶/ ( 單臺物理內存/ 單個應用內存 * 單個應用支撐用戶數 )
• 我的研究

百萬級別以上的用戶用分佈式好點，少於百萬仍是單機吧

分析案例

• 內容網站
• 只讀部份 主頁,列表頁
• 修改部份 評論，廣告
• 小結
• 主頁訪問量大，可弄個靜態緩存集羣組而後直接CDN技術解決

• 評論變更頻煩，可按一週7天切分7個集羣，輪盤式發佈處理

• 視頻網站
  • 可用P2P技術分流，擴展web插件支持p2p
  • 主頁，列表頁，評論同內容網站同樣
• 社交網站

  • 消息推送，可按小時/天 切分集羣，輪盤式發佈處理,FIFO策略控制集羣，入庫或徹底丟去

  • 小結
  • 消息生命週期徹底由緩存控制
  • 消息上限可控制
  • 集中精力處理緩存,消息共享

  • 全部消息都是在線推送，推送成功再記錄，減小IO壓力

• 圖片分享網站(不是這方面專業，沒什麼好說的感受跟視頻服同樣燒錢)
  • 對高清圖片進行優化
  • 專門的圖片存儲集羣(硬盤、內存性能要好,cpu 能夠差點)
  • 熱擴展物理硬盤
  • 路由服來分配策略
• 電商網站
  • 大量圖片資源同圖片服同樣
  • 按期執行推薦算法，刷新一級緩存
  • 水平擴展產品，每種產品應獨立開發
• 總結
  • 一級緩存集羣(主頁)負責今天的熱點內容，以及推薦內容等
  • 二級緩存集羣(節點)負責緩存本地節點數據

功能細節實現

越寫愈加現注意的細節太多了，能夠出一本書，之後有空再補上