| 失效链接处理 |
|
ActiveMQ知识点汇总 PDF 下载
本站整理下载：
相关截图：
主要内容：
背景
为什么要在系统里引入消息中间件？在什么场景下需要使用消息中间件？
系统之间直接调用实际工程落地和存在的问题？
微服务架构后，链式调用是我们在写程序时候的一般流程，为了完成一个整体功能会将其拆分成多个函数(或
子模块)，比如模块A调用模块B，模块B调用模块C，模块C调用模块D。但在大型分布式应用中，系统间的
RPC交互繁杂，一个功能背后要调用上百个接口并非不可能，从单机架构过渡到分布式微服务架构的通例，这
些架构会有哪些问题？
系统之间接口耦合比较严重
每新增一个下游功能，都要对上游的相关接口进行改造；
例如：如果系统A要发送数据给系统B和系统C，发送给每个系统的数据可能有差异，因此系统A对要发送
给每个系统的数据进行了组装，然后逐一发送；
当代码上线后又新增了一个需求：
把数据也发送给D，新上了一个D系统也要接受A系统的数据，此时就需要修改A系统，让他感知到D系统
的存在，同时把数据处理好再给D。在这个过程你会看到，每接入一个下游系统，都要对系统A进行代码
改造，开发联调的效率很低。其整体架构如下图
面对大流量并发时，容易被冲垮
每个接口模块的吞吐能力是有限的，这个上限能力如果是堤坝，当大流量（洪水）来临时，容易被冲
垮。
例如秒杀业务：上游系统发起下单购买操作，我就是下单一个操作；下游系统完成秒杀业务逻辑（读取
订单，库存检查，库存冻结，余额检查，余额冻结，订单生产，余额扣减，库存减少，生成流水，余额
解冻，库存解冻）
等待同步存在性能问题
RPC接口上基本都是同步调用，整体的服务性能遵循“木桶理论”，即整体系统的耗时取决于链路中最慢的
那个接口。
比如A调用B/C/D都是50ms，但此时B又调用了B1，花费2000ms，那么直接就拖累了整个服务性能。
根据上述的几个问题，在设计系统时可以明确要达到的目标：
要做到系统解耦，当新的模块接进来时，可以做到代码改动最小；能够解耦
设置流量缓冲池，可以让后端系统按照自身吞吐能力进行消费，不被冲垮；能削峰
强弱依赖梳理能将非关键调用链路的操作异步化并提升整体系统的吞吐能力；能够异步
定义
面向消息的中间件（message-oriented middleware）MOM能够很好的解决以上问题，是指利用高效
可靠的消息传递机制与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。
通过提供消息传递和消息排队模型在分布式环境下提供应用解耦，弹性伸缩，冗余存储、流量削峰，异
步通信，数据同步等功能。
大致的过程是这样的：
发送者把消息发送给消息服务器，消息服务器将消息存放在若干队列/主题topic中，在合适的时
候，消息服务器会将消息转发给接受者。在这个过程中，发送和接收是异步的，也就是发送无需等
待，而且发送者和接受者的生命周期也没有必然的关系
尤其在发布pub/订阅sub模式下，也可以完成一对多的通信，即让一个消息有多个接受者
|
| Java1234官方群25： | 
|
| Java1234官方群25： | 838462530 |
苏公网安备 32061202001004号
