织梦网站被做跳转,有做挂名法人和股东的网站吗,适合初学者做的网页,网站建设功能文案1.什么是消息中间件#xff1f;
消息中间件基于队列模型在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统。
2.现实中的痛点#xff1a;
1.Http请求基于请求与响应的模型#xff0c;在高并发的情况下#xff0c;客户端发送大量的请求达到服务器端…1.什么是消息中间件
消息中间件基于队列模型在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统。
2.现实中的痛点
1.Http请求基于请求与响应的模型在高并发的情况下客户端发送大量的请求达到服务器端有可能会导致我们服务器端处理请求堆积。 2.Tomcat服务器处理每个请求都有自己独立的线程如果超过最大线程数会将该请求缓存到队列中如果请求堆积过多的情况下有可能会导致tomcat服务器崩溃的问题。
所以一般都会在nginx入口实现限流整合服务保护框架。 3.http请求处理业务逻辑如果比较耗时的情况下容易造成客户端一直等待阻塞等待过程中会导致客户端超时发生重试策略有可能会引发幂等性问题。 注意事项接口是为http协议的情况下最好不要处理比较耗时的业务逻辑耗时的业务逻辑应该单独交给多线程或者是mq处理。
3.消息中间件的作用
可以实现支撑高并发、异步解耦、流量削峰、降低耦合度。
3.1 支撑高并发
在高并发环境下如果消息的处理速度跟不上消息的生成速度就会导致消息队列堆积进而影响系统的稳定性和可用性。为了解决这个问题引入消息限流策略是非常必要的。
消息限流是一种通过控制消息的生成速率和处理速率来平衡生产者和消费者之间的关系。通过设置合理的限流参数可以控制系统的负载避免资源耗尽和系统崩溃的风险。
RabbitMQ与消息限流策略的结合
1、预取计数prefetch countRabbitMQ中的预取计数可以控制消费者从队列中获取消息的数量。通过合理设置预取计数可以平衡生产者和消费者之间的速率差异。当消费者处理完预取的消息后才会继续从队列中获取新的消息这样可以避免消息的堆积。
2、限制连接数和通道数在RabbitMQ中可以通过限制连接数和通道数来控制消息的生成速度和处理速度。通过限制连接数可以限制生产者的连接数控制消息的生成速度通过限制通道数可以提高消费者的处理速度避免系统负载过高。
3、延迟队列dead-letter queue延迟队列是一种特殊的队列用于存放无法立即处理的消息。当消息到达延迟队列后可以设置一个延迟时间在延迟时间过后再将消息重新发送给消费者进行处理。通过延迟队列可以有效控制消息的处理速率尤其适用于对实时性要求不高的场景。
3.2 异步解耦
应用场景一般用于用户注册后需要发送注册邮件和注册短信
传统做法
1.串行方式
串行的方式就是将注册信息写入数据库后发送注册邮件再发送注册短信以上三个任务全部完成后才返回给客户端。这有一个问题是邮件短信并不是必须的它只是一个通知而这种做法让客户端等待没有必要等待的东西。 2.并行方式
将注册信息写入数据库后同时执行发送邮件发送短信以上三个任务完成后返回给客户端并行的方式能提高处理的时间。 假设三个业务节点分别使用50ms串行方式使用时间150ms并行使用时间100ms。虽然并性已经提高的处理时间但是前面说过邮件和短信对我正常的使用网站没有任何影响客户端没有必要等着其发送完成才显示注册成功应该是写入数据库后就返回。
3.消息队列的方式
引入消息队列之后就可以异步处理发送注册邮件和注册短信的业务在注册信息写入数据库之后这些不妨碍用户使用的业务先加入到消息队列当中等待处理。 由此可见引入消息队列之后响应时间数据库写入时间写入消息队列的时间消息队列中的消息可以等待前面的消息处理完再处理。
3.3 降低耦合度
应用场景商城活动时下单高峰时期用户下单订单业务模块调用库存业务模块的接口。 这种情况下就会存在订单业务和库存业务高度耦合的问题一旦我们的库存业务使用不了了那我i们的订单业务也就无法使用了。引入消息队列就可以解决这一问题 订单系统用户下单后订单系统完成持久化处理将消息写入消息队列返回用户订单下单成功。
库存系统订阅下单的消息获取下单消息进行库操作。
就算库存系统出现故障,消息队列也能保证消息的可靠投递,不会导致消息丢失。
3.4 流量削峰
应用场景流量削峰一般用于秒杀活动中。秒杀活动一般会因为流量过大导致应用挂掉为了解决这个问题一般在应用前端加入消息队列。
作用
1、可以控制活动人数超过限制就会直接丢弃掉后来的订单
2、可以缓解短时间的高流量超出服务器承受范围压垮服务器 1、用户的请求服务器收到之后首先写入消息队列加入消息队列长度超过最大值则直接抛弃用户请求或跳转到错误页面。
2、秒杀业务根据消息队列中的请求信息再做后续处理。
3.5 消息队列优缺点
关于消息队列的优点也就是上面列举的就是在特殊场景下有其对应的好处解耦、异步、削峰。
缺点有以下几个
1.系统可用性降低系统引入的外部依赖越多越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了人 ABCD 四个系统好好的没啥问题你偏加个 MQ 进来万一 MQ 挂了咋整MQ 一挂整套系统崩溃的你不就完了如何保证消息队列的高可用可以点击这里查看。
2.系统复杂度提高硬生生加个 MQ 进来你怎么[保证消息没有重复消费]怎么[处理消息丢失的情况]怎么保证消息传递的顺序性头大头大问题一大堆痛苦不已。
3.一致性问题A 系统处理完了直接返回成功了人都以为你这个请求就成功了但是问题是要是 BCD 三个系统那里BD 两个系统写库成功了结果 C 系统写库失败了咋整你这数据就不一致了。
4. 常见的消息中间件
在介绍常见的消息中间件的方式的时候先介绍一下实现MQ的两种方式AMQPJMS
4.1 AMQP和JMS
AMQP全称Advanced Message Queuing Protocol一个提供统一消息服务的应用层标准高级消息队列协议是应用层协议的一个开放标准为面向消息的中间件设计基于此协议的客户端与消息中间件传递消息不受客户端/中间件不同产品、不同开发语言等条件的限制。该协议是一种二进制协议提供客户端应用于消息中间件之间异步、安全、高效的交互。相对于我们常见的REST APIAMQP更容易实现可以降低开销同时灵活性高可以轻松的添加负载平衡和高可用性的功能并保证消息传递在性能上AMQP协议也相对更好一些。官方解释
通俗来说在异步通讯中消息不会立刻到达接收方而是被存放到一个容器中当满足一定的条件之后消息会被容器发送给接收方这个容器即消息队列而完成这个功能需要双方和容器以及其中的各个组件遵守统一的约定和规则AMQP就是这样的一种协议消息发送与接收的双方遵守这个协议可以实现异步通讯。这个协议约定了消息的格式和工作方式。
JMS即Java消息服务Java Message Service应用程序接口是一个 Java 平台中关于面向消息中间件MOM的API用于在两个应用程序间或分布式系统中发送消息进行异步通信。Java消息服务是一个与具体平台无关的API绝大多数MOM提供商都对JMS提供支持。简单的理解两个应用程序之间需要进行通信使用一个JMS服务进行中间的转发通过JMS 的使用可以解除两个程序之间的耦合。
两者间的区别和联系
JMS是定义了统一的接口来对消息操作进行统一AMQP是通过规定协议来统一数据交互的格式JMS限定了必须使用Java语言AMQP只是协议不规定实现方式因此是跨语言的。JMS规定了两种消息模型而AMQP的消息模型更加丰富
4.2 常见的MQ产品
现在主流的消息中间件就4种kafka、ActiveMQ、RocketMQ、RabbitMQ
ActiveMQ基于JMS
RabbitMQ基于AMQP协议erlang语言开发稳定性好
RocketMQ基于JMS阿里巴巴产品目前交由Apache基金会
Kafka分布式消息系统高吞吐量
接下来看一下这四种中间件之间有什么区别
4.2.1 ActiveMQ
ActiveMQ现在来说已经算是一个比较过时的产品了以前早期的项目使用的都是这个MQ但是现在用的不多了。官网的更新频率已经变慢了好久才会更新一次。
它的单机吞吐量是万级的一些小的项目已经够用了但是对于高并发的情况下已经不行了
在可用性上看它使用的是主从架构实现的具有高可用性
在消息可靠性上看有较低的概率是会丢掉数据的
综合来看后续介绍的RabbitMQ完全可以代替掉这个
4.2.2 RabbitMQ
RabbitMQ出现后大多数国内的公司选择抛弃ActiveMQ选择RabbitMQ基本代替了ActiveMQ的位置而且社区比较活跃。
它的单机吞吐量也是万级的对于高并发的情况它也是难以胜任的。
在可用性上它使用的是镜像集群的模式可以保证高可用性
在消息的可靠性上它是可以保证不丢数据的
同时它还支持一些消息中间件的高级功能如消息重试、死信队列等
但是RabbitMQ的开发语言是erlang国内很少有人精通erlang所以经常无法阅读源码对于大多数中小型公司不需要面对数据上的挑战使用它还是非常合适的但是对于BAT大公司来说它就不太适合了。
4.2.3 RocketMQ
MQ-RocketMQ它是阿里开源的消息中间件久经沙场非常靠谱。
它支持高吞吐量单机可达到10万级能承受互联网的高并发的挑战。
在可用性上使用的是分布式架构可以搭建大规模的集群性能很高。
在可靠性上通过一定的配置可以达到数据的绝对不丢失。
同时Rocket-MQ支撑大量的高级功能如延迟消息事物消息、消息回溯、死信队列等。
它非常适用于Java体系的架构中因为使用Java语言进行开发的所以可以通过阅读源码的方式去了解更深的底层原理。
目前来看它没有什么特别大的缺点可以支持高并发下的技术挑战可以基于它实现分布式事务大型互联网公司和中小型公司都可以选择使用它来作为消息中间件使用。
4.2.4 Kafka
kafka的吞吐量被公认为中间件中的翘楚单机可以支持十几万的并发相当强悍。
在高可用上同样支持分布式集群部署。
在消息可靠性上如果保证异步的性能可能会出现消息丢失的情况因为它保存消息时是先存到磁盘缓冲区的如果机器出现故障缓冲区的数据是可能丢失的。
它的功能非常的单一就是消息的接收与发送因此不适合应用于许多场景。
它在行业内主要应用于大数据领域使用它进行用户行为日志的采集和计算来实现比如“猜你喜欢”的功能。
所以如果没有大数据的需求一般不会选择它。
4.2.5总结 图片转自https://www.cnblogs.com/qingbaizhinian/p/14476728.html
