MQ在分佈式系統中的應用於協作

前期業務比較簡單  用戶量不大 系統壓力較小


1.單系統應用架構


接入層：nginx  路由
Tomcat
    業務層：Java  application
    數據層：MySQL
            controller service  dao
2.當單一應用越來越龐大，業務複雜度迅速上升
 
    方案一：將單一的業務項目拆分成多個獨立子廢物，  登陸服務  登陸服務  定位服務  配單服務


           子服務之間可以基於消息（MQ）的通信，


           或是基於RPC的通信  


           通信協議：http協議： restful ， spring boot 


           dubbo框架使用dubbo協議


           http不是萬能的,其他協議： tcp  郵箱服務  stmp  視頻類的服務  udp




   什麼時候用MQ通信什麼時候用rpc通信？
   
   ---MQ  異步   類似後臺計算  統計分析
      RPC  同步  關注對方響應結果
          比如：app 登陸服務 


========================================================
背景：
     一臺機器扛不住了   複製一臺  （分應用  不分庫）     
       Nginx  路由 反向代理
     Tomcat  Tomcat   （完全相同的多個Tomcat）
     
         database  （多個Tomcat訪問一個數據庫）
     缺點：數據庫壓力太大，MQ，redis 等能減輕數據庫壓力  
           MQ是存在硬盤的，redis是存在內存中的，redis主要起緩存數據的作用。
          


3. 切換到分佈式會面臨的問題
  
  3.1 分佈式全局唯一  
    . 業務唯一或者數據庫主鍵唯一   
    主鍵儘量用整型int long bigint ;uuid 儘量不用，性能不好    ObjectId 


  3.2 服務接口冪等
     . 輸入和輸出  純函數  function  結果是不受影響的  scala（純函數）
       重複執行一次或多次 結果是不受影響的
  3.3 錯綜複雜的服務依賴關係
     。dubbo  服務治理類框架


     例：完成一個完整的訂單服務  後臺需要請求5-6個接口


  3.4 面對複雜的網絡問題
     。網絡都升級了  3g/4g/5g  512k  2m  netty/mina
  3.5 面對失敗重試策略
     .調用某個服務失敗後的策略
  3.6 面對服務高可用（多機熱備）
     。HAProxy
  3.7 面對數據最終一致性
     .犧牲部分數據庫的強一致性，來提高性能
  3.8 面對數據同步問題（跨機器、跨機房）
     。RocketMq 


 ============================================================






  瞭解docker  虛擬化進程
   
   瞭解netty rpc java8  


   activemq 性能不如rabbitmq  建議選後者




   eppol poll select  


   kafka 做日誌分析


   rocketmq  建立在kafka