网站代理工具,衡水企业做网站推广,免费推广手段,html5特效网站源码一#xff1a;消息队列的主要作用是什么#xff1f; 1.消息队列的特性#xff1a; 业务无关#xff0c;一个具有普适性质的消息队列组件不需要考虑上层的业务模型#xff0c;只做好消息的分发就可以了#xff0c;上层业务的不同模块反而需要依赖消息队列所定义的规范进行…一消息队列的主要作用是什么 1.消息队列的特性 业务无关一个具有普适性质的消息队列组件不需要考虑上层的业务模型只做好消息的分发就可以了上层业务的不同模块反而需要依赖消息队列所定义的规范进行通信。FIFO先投递先到达的保证是一个消息队列和一个buffer的本质区别。容灾对于普适的消息队列组件来说节点的动态增删和消息的持久化都是支持其容灾能力的重要基本特性。性能这个不必多说了消息队列的吞吐量上去了整个系统的内部通信效率也会有提高。 2.为什么需要消息队列 当系统中出现“生产“和“消费“的速度或稳定性等因素不一致的时候就需要消息队列作为抽象层弥合双方的差异。“ 消息 ”是在两台计算机间传送的数据单位。消息可以非常简单例如只包含文本字符串也可以更复杂可能包含嵌入对象。消息被发送到队列中“ 消息队列 ”是在消息的传输过程中保存消息的容器 。 使用场景 业务系统触发短信发送申请但短信发送模块速度跟不上需要将来不及处理的消息暂存一下缓冲压力。就可以把短信发送申请丢到消息队列直接返回用户成功短信发送模块再可以慢慢去消息队列中取消息进行处理。
调远程系统下订单成本较高且因为网络等因素不稳定攒一批一起发送。
任务处理类的系统先把用户发起的任务请求接收过来存到消息队列中然后后端开启多个应用程序从队列中取任务进行处理。
3.使用消息队列有什么好处消息队列作用 异步假设你有一个系统调用链路是系统A调用系统B一般耗时20ms系统B调用系统C一般耗时200ms系统C调用系统D一般耗时2s。用户一个请求过来巨慢无比因为走完一个链路需要耗费2220ms如果业务流程支持异步化的话是不是就可以考虑把系统C对系统D的调用抽离出去做成异步化的不要放在链路中同步依次调用。这样实现思路就是系统A - 系统B - 系统C直接就耗费220ms后直接成功了。然后系统C就是发送个消息到MQ中间件里由系统D消费到消息之后慢慢的异步来执行这个耗时2s的业务处理。通过这种方式直接将核心链路的执行性能提升了10倍。
解耦假设你有个系统A这个系统A会产出一个核心数据现在下游有系统B和系统C需要这个数据。那简单系统A就是直接调用系统B和系统C的接口发送数据给他们就好了。但是现在要是来了系统D、系统E、系统F、系统G等等十来个其他系统慢慢的都需要这份核心数据呢那么负责系统A的就要被烦死了然后如果要是某个下游系统突然宕机了呢系统A的调用代码里是不是会抛异常那系统A的同学会收到报警说异常了结果他还要去care是下游哪个系统宕机了。所以在实际的系统架构设计中如果全部采取这种系统耦合的方式在某些场景下绝对是不合适的系统耦合度太严重。并且互相耦合起来并不是核心链路的调用而是一些非核心的场景比如上述的数据消费导致了系统耦合这样会严重的影响上下游系统的开发和维护效率。因此在上述系统架构中就可以采用MQ中间件来实现系统解耦系统A就把自己的一份核心数据发到MQ里下游哪个系统感兴趣自己去消费即可不需要了就取消数据的消费。
消峰假设有一个系统平时正常的时候每秒可能就几百个请求正常处理都是OK的在高峰期一下子来了每秒钟几千请求弹指一挥间出现了流量高峰此时我们就可以用MQ中间件来进行流量削峰。所有机器前面部署一层MQ平时每秒几百请求大家都可以轻松接收消息。一旦到了瞬时高峰期一下涌入每秒几千的请求就可以积压在MQ里面然后那一台机器慢慢的处理和消费。等高峰期过了再消费一段时间MQ里积压的数据就消费完毕了。这个就是很典型的一个MQ的用法用有限的机器资源承载高并发请求如果业务场景允许异步削峰高峰期积压一些请求在MQ里然后高峰期过了后台系统在一定时间内消费完毕不再积压的话那就很适合用这种技术方案。
4.消息队缺点 系统可用性降低系统引入的外部依赖越多越容易挂掉本来就是A系统调用BCD三个系统的接口就好了人ABCD四个系统好好的偏加个MQ进来万一MQ挂了整套系统崩溃了。
系统复杂性提高硬生生加个MQ进来怎么保证消息没有重复消费怎么处理消息丢失的情况怎么保证消息传递的顺序性
一致性问题A系统处理完了直接返回成功了人都以为你这个请求就成功了但是问题是要是BCD三个系统那里BD两个系统写库成功了结果C系统写库失败了这数据就不一致了。 二如何保证消息队列的高可用
1.RabbitMQ高可用 单机模式Demo级别的生产环境不会使用 普通集群模式 同时部署多台RabbitMQ服务器当生产者将消息发送到RabbitMQ的集群中时 消息会存在元数据类似于消息的描述信息消息数据收到消息的MQ会将消息的元数据信息同步到其他的节点上当消费者从任意一台服务器上获取消息时如果当前服务器存在该消息的数据信息就获取成功否则就会根据元数据信息从其他节点上获取消息数据这样做并没有保证MQ的高可用因为存在消息数据的服务器挂掉消息一样不存在这样做只能保证MQ的吞吐量比较大。 采用镜像集群模式 你创建的queue无论元数据还是queue里的消息都会存在于多个实例上然后每次你写消息到queue的时候都会自动把消息到多个实例的queue里进行消息同步。 这样的话好处在于你任何一个机器宕机了别的机器都可以用。坏处在于 性能开销大消息同步所有机器导致网络带宽压力和消耗很重
没有扩展性如果某个queue负载很重你加机器新增的机器也包含了这个queue的所有数据并没有办法线性扩展你的queue
开启镜像集群模式rabbitmq有很好的管理控制台在后台新增一个策略这个策略是镜像集群模式的策略指定的时候可以要求数据同步到所有节点的也可以要求就同步到指定数量的节点然后你再次创建queue的时候应用这个策略就会自动将数据同步到其他的节点上去了。 2.kafka的高可用 kafka一个最基本的架构认识多个broker组成每个broker是一个节点你创建一个topic这个topic可以划分为多个partition每个partition可以存在于不同的broker上每个partition就放一部分数据。 这就是天然的分布式消息队列就是说一个topic的数据是分散放在多个机器上的每个机器就放一部分数据。kafka 0.8以前是没有HA机制的就是任何一个broker宕机了那个broker上的partition就废了没法写也没法读没有什么高可用性可言。kafka 0.8以后提供了HA机制就是replica副本机制。每个partition的数据都会同步到其他机器上形成自己的多个replica副本。然后所有replica会选举一个leader出来那么生产和消费都跟这个leader打交道然后其他replica就是follower。写的时候leader会负责把数据同步到所有follower上去读的时候就直接读leader上数据即可。只能读写leader很简单要是你可以随意读写每个follower那么就要care数据一致性的问题系统复杂度太高很容易出问题。kafka会均匀的将一个partition的所有replica分布在不同的机器上这样才可以提高容错性。 写数据的时候生产者就写leader然后leader将数据落地写本地磁盘接着其他follower自己主动从leader来pull数据。一旦所有follower同步好数据了就会发送ack给leaderleader收到所有follower的ack之后就会返回写成功的消息给生产者。当然这只是其中一种模式还可以适当调整这个行为 消费的时候只会从leader去读但是只有一个消息已经被所有follower都同步成功返回ack的时候这个消息才会被消费者读到。 三高并发情况下消息队列满了如何防止消息丢失
其实这个防止消息丢失每种MQ都要从三个角度来分析:生产者弄丢数据、消息队列弄丢数据、消费者弄丢数据以RabbitMQ为例 1.生产者丢数据 从生产者弄丢数据这个角度来看RabbitMQ提供transaction和confirm模式来确保生产者不丢消息。transaction机制就是说发送消息前开启事务(channel.txSelect())然后发送消息如果发送过程中出现什么异常事物就会回滚(channel.txRollback())如果发送成功则提交事物(channel.txCommit())。然而缺点就是吞吐量下降了。因此生产上用confirm模式的居多。一旦channel进入confirm模式所有在该信道上面发布的消息都将会被指派一个唯一的ID(从1开始)一旦消息被投递到所有匹配的队列之后rabbitMQ就会发送一个Ack给生产者(包含消息的唯一ID)这就使得生产者知道消息已经正确到达目的队列了.如果rabiitMQ没能处理该消息则会发送一个Nack消息给你你可以进行重试操作。 2.消息队列丢数据 处理消息队列丢数据的情况一般是开启持久化磁盘的配置。这个持久化配置可以和confirm机制配合使用你可以在消息持久化磁盘后再给生产者发送一个Ack信号。这样如果消息持久化磁盘之前rabbitMQ阵亡了那么生产者收不到Ack信号生产者会自动重发。那么如何持久化呢这里顺便说一下吧其实也很容易就下面两步 将queue的持久化标识durable设置为true,则代表是一个持久的队列
发送消息的时候将deliveryMode2
这样设置以后rabbitMQ就算挂了重启后也能恢复数据 3.消费者丢数据 消费者丢数据一般是因为采用了自动确认消息模式。这种模式下消费者会自动确认收到信息。这时rahbitMQ会立即将消息删除这种情况下如果消费者出现异常而没能处理该消息就会丢失该消息。至于解决方案采用手动确认消息即可。
