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