0
点赞
收藏
分享

微信扫一扫

常见限流算法及其实现

捌柒陆壹 03-06 18:00 阅读 4

RabbitMQ

1.为什么使用MQ?优点是什么

因为MQ可以异步处理,提高系统吞吐量。
应用解耦,系统之间可以通过消息通信,不关心其他系统的处理。
流量削峰,可以通过消息队列的长度,控制请求量。可以缓解短时间内的高并发请求。

解耦:A->BCD,但是如果E也想要这个数据,或者C不想要了。A就需要修改。与各种下游系统严重耦合。
如果使用MQ,A系统产生一条消息,到MQ,哪个系统要消息就去消息系统里去消费。
异步:A接收请求,在本地写库,在BCD三个系统分别要进行写库,本地很快,其它系统完成后传过来很慢,如果同步方式,
A需要BCD都完成之后,才能返回给前端,用户会觉得好慢。如果使用异步化处理的话,A本地写库完成,再往消息队列里写一个数据,就可以返回了。
削峰:大流量来的时候,系统可能承受不住这么大的压力,如果用MQ,就可以对这些请求不用急着处理,转化为MQ里的消息数据,然后以恒定的速率吐出。

2.消息队列有什么缺点?

系统可用性降低:MQ挂了,系统就挂了,增加环节就是在增加风险。
复杂性提高:要考虑的问题多了:比如一致性问题(A的消息给BCD用,BC成功,D失败,就是不一致了),如何保证消息不被重复消费,如何保证消息可靠性传输。

3. 不同的MQ的对比?

  1. ActiveMQ 老牌消息中间件,很多公司运用的很广泛,功能强大,但是互联网公司的高并发扛不住。一般在传统企业,做异步调用,系统解耦。
  2. RocketMQ 阿里开源的,超高并发、高吞吐,性能好,基于java。
  3. rabbitMQ 支持高并发,高吞吐,性能很高,同时有完善的后台管理界面。还支持集群化,高可用部署架构,功能完善。但是缺点是基于erlang开发,不好研究源码。
  4. kafka功能少,优势在于专为超高吞吐量的实时日志采集,实时数据同步,实时数据计算等场景来设计。用在日志或者大数据计算方面比较多。

4.为啥使用rabbitMq不用RocketMQ?

rocketMQ不够稳定,社区活跃度不高,rabbitMQ很稳定。

5.MQ有哪些常见问题?如何解决?

  1. 消息的顺序性问题
  • 单线程化。比如一个订单的各种状态,下单,付款,发货,如果有多个队列,要按照id保证进入一个队列。
  • 一个队列对应一个消费者,这样就能保证顺序。
  • 或者一个队列可以对应多个消费者,但是消费者在业务逻辑内部要做判断,如果订单还在下单阶段就收到了发货的消息,那就只能抛出异常,回复nack,让rabbitMQ重发。
  1. 消息的重复问题
  • 为了确保每条消息至少成功一次的原则,队列里可能一条消息发了多次,需要在业务中做幂等性处理。
    • 查询和删除操作天然幂等。
    • 增改过程需要特殊处理。
  • 举个例子,论坛发帖,在打开编辑页面的时候就产生一个token,服务端存在redis,前端也存一份,然后发送消息的时候,看看redis里有没有这个token,有就新增,同时把redis的token删掉,后面的消息拿着同样的token找不到redis的对应token,就是重复消费,就丢弃。
    在这里插入图片描述
  • 再举个例子,比如一个订单的各种状态,下单,付款,发货,一个字段记录这些状态,1->2->3.
  • 每次的消息就更改状态,消息重复过来了发现状态已经变了,那就不再做任何事情。
  • 订单新增的时候,要在消息里,订单里有唯一的id,可以用uuid,用雪花算法,redis原子自增,等等方式实现。

6. RabbitMQ

一个开源的,erlang编写的,基于AMQP协议的消息中间件

6.1 RabbitMQ的基本概念

在这里插入图片描述

  1. Producer:数据发送方,一般一个消息有两个部分,有效载荷和标签,用标签定位到把消息发送到哪个消费者
  2. Broker: 消息队列服务器实体
  3. Exchange: 消息交换器,从生产者那里收到消息,指定一个routing key,来指定这个消息的路由规则,routing key要和exchange type还有binding key联合使用生效。
  4. binding:绑定,绑定exchange和queue的同时,一般会指定一个binding key。
  5. queue 队列 一个message可以被同时拷贝到多个queue中。
  6. Connection 一个TCP连接,producer和consumer都是通过tcp连接到rabbitMQ server的。
  7. channel是建立在上述的tcp连接中的虚拟连接,AMPQ连接, 如果每一次访问RabbitMQ都建立一个Connection,在消息量大的时候建立TCP Connection的开销将是巨大的,效率也较低。Channel是在connection内部建立的逻辑连接,如果应用程序支持多线程,通常每个thread创建单独的channel进行通讯,AMQP method包含了channel id帮助客户端和message broker识别channel,所以channel之间是完全隔离的。Channel作为轻量级的Connection极大减少了操作系统建立TCP connection的开销。
  8. Consumer 消费方
  9. virtual host 虚拟主机
  10. 多个不同的用户使用一个rabbitmq server 提供的服务时,可以划分出多个vhost,每个用户在自己的vhost里面建立exchange/queue.
    在这里插入图片描述

6.2 RabbitMQ的工作模式

  1. direct
    消息的routing key与exchange的某个binding key完全符合,则转发到对应的队列中。
  2. fanout
    如果exchange 收到消息,就广播到所有绑定的队列上
  3. topic
    不需要完全匹配,而是符合匹配规则的路由规则即可。#代表任意个单词,*代表一个单词

6.3 ack机制

  1. 有手动和自动ack的方式,一般采用手动。autoAck = false;
  2. 服务端在收到ack信号之后才会删除内存(或者磁盘)中的消息,其实是先标记,再删除。
  3. 队列中有两种消息,一部分是还没有投递出去的消息,一部分已经投递但是还没得到确认的消息。
  4. 如果没有收到确认,消息不会有过期时间,所以也就是给消费者充足的处理时间。只有检测到消费者已经断开了,才会将消息重新放入队列,等待投递给下一个消费者。
  5. 除了ack,还可以拒绝消息,void basicReject(long deliveryTag,boolean requeue);
  6. requeue true重新放入队列,false直接丢弃

6.4 TTL过期时间

  1. 有队列过期时间,还有消息过期时间,以两者较小为准,超过了就过期。
  2. DLX Dead-Letter-Exchange,死信交换机,当一个消息变成死信,就可以发送到另一个交换机,就是死信交换机。
  3. 变成死信三种情况,过期,被拒绝,队列达到最大长度。
  4. 可以用来分析那些被拒绝的消息,转到新的交换机再用新的消费者程序去分析。
    在这里插入图片描述

6.5 延迟队列

  1. 消息放入队列之后,并不会立即被消费,等待一定时间再消费。
  2. 场景:下单之后,十分钟不支付将取消订单,订单信息先发送到正常队列里。然后过了时间之后,再转到另一个交换机–>死信交换机这里再去真正消费。
    在这里插入图片描述

6.6 生产者确认

如何确认消息成功的发送到了rabbitMQ的Exchange?
可以使用事务机制,但是,性能太低了。

try{
    channel.txSelect();
    channel.basicPublish(xxx);
    channel.txCommit();
}catch(Exception e){
    e.printStackTrace();
    channel.txRollBack();
}

在这里插入图片描述
生产者确认

在这里插入图片描述
生产者将channel设置为confirm模式,一旦信道进入comfirm模式,所有在该信道上的消息就会有一个从1开始的编号,deliveryTag,消息到达匹配的队列之后,rabbitMQ会发送Basic.ACK给生产者,包含那个编号,生产者就知道了。
事务机制是阻塞的,生产者确认机制是异步的。生产者收到ACK之后,可以在回调中处理,收到NACK也可以在另一个回调逻辑中处理。

7. 如何保证RabbitMQ消息的可靠传输?

  1. 不可靠一般的原因就是丢了。
  2. 丢失可能是生产者丢失,消息列表丢失、消费者丢失。
  3. 生产者丢失就采用事务或者异步confirm机制,没收到confirm或者收到nack就重发了。这可能导致消息重复。
  4. 消息队列丢失数据:需要消息持久化,配合confirm,持久化磁盘之后再ack,在这之前有问题那么生产者会重发,在这之后有问题,反正已经持久化了有备份。
  5. 消费者丢失,把ack从自动改为手动,处理成功之后ack。造成的消息重复问题,一般需要消费者业务上做幂等性处理。

8.如何保证RabbitMQ的高可用?

为了确保RabbitMQ的高可用性,通常需要考虑以下几个方面:

  1. 集群部署(Clustering)

    将多个RabbitMQ节点配置成集群,可以提供负载均衡和故障转移的能力。在集群模式下,消息队列可以分布在多个节点上,提高系统的吞吐量。如果一个节点失败,其他节点仍然可以继续工作。

  2. 镜像队列(Mirrored Queues)

    在RabbitMQ集群中,可以设置镜像队列来确保队列中的消息被复制到多个节点。如果一个节点崩溃,队列的其他副本可以接管,保证消息不丢失。这是通过设置队列的x-ha-policy参数来实现的。

  3. 持久化(Persistence)

    对消息和队列进行持久化可以保护数据不会因为服务器崩溃而丢失。将消息标记为持久化(通过设置消息的delivery_mode属性为2),并确保队列也被声明为持久化,可以提高数据的可靠性。

  4. 确认和事务机制(Acknowledgments and Transactions)

    使用消息确认机制可以保证消息被正确处理。消费者处理完消息后发送ack(确认)给RabbitMQ,若RabbitMQ没有收到确认,它会将消息重新分发给其他消费者。此外,RabbitMQ还支持事务性消息处理。

  5. 监控和报警(Monitoring and Alerting)

    监控RabbitMQ的运行状况并设置相应的警报机制,可以及时发现并解决潜在的问题。可以利用RabbitMQ提供的管理插件来监视队列的长度、消息吞吐量和节点状态。

  6. 硬件和基础设施的冗余

    在硬件层面,确保服务器、存储和网络连接的冗余可以减少单点故障的风险。使用如RAID或SAN等存储方案可以提高存储系统的可靠性。

  7. 负载均衡(Load Balancing)

    使用负载均衡器可以分散到集群的连接和流量。这不仅增加了系统的吞吐量,也避免了单个节点的过载。

  8. 备份和恢复(Backup and Recovery)

    定期备份RabbitMQ的状态,包括消息队列的配置和消息数据。在发生灾难性故障时,可以用备份快速恢复服务。

  9. 升级和补丁管理

    定期应用RabbitMQ和操作系统的更新和补丁,可以减少因为已知安全问题或软件缺陷导致的服务中断。

  10. 故障切换(Failover)策略

    为系统设计故障切换策略,以便在节点或组件失败时能够快速恢复服务。

要实现这些策略,可能需要对RabbitMQ的高级特性有深入的了解,并且在系统设计和运维阶段做出相应的规划和实施。此外,持续的性能测试和优化也是确保RabbitMQ高可用的重要环节。

举报

相关推荐

0 条评论