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