rabbitMq对象序列化和反序列化之手动ACK配置失效

在工作中,遇到的一个问题,记录一下!如果觉得有用,麻烦点个赞~谢谢

注意:

如果在服务方配置了则程序会走自动确认消费,配置文件的配置就不生效了(Spring boot在整合rabbit mq的时候,它会自动给你创建simpleRabbitListenerContainerFactory这样的一个类,如果用@bean构建了,那么它就不去创建了。所以写的那些配置它也不会加载。)

使用 JSON 序列化与反序列化(服务方配置)

  • RabbitMQ 提供了 Jackson2JsonMessageConverter 来支持消息内容 JSON 序列化与反序列化

  • 消息服务者在服务消息时应设置 MessageConverter 为 Jackson2JsonMessageConverter

@Configuration
public class RabbitMQConfig {
    
    @Bean
    public RabbitListenerContainerFactory<?> rabbitListenerContainerFactory(ConnectionFactory connectionFactory){
        SimpleRabbitListenerContainerFactory factory = new         SimpleRabbitListenerContainerFactory();
        factory.setConnectionFactory(connectionFactory);
        factory.setMessageConverter(new Jackson2JsonMessageConverter());
        return factory;
    }

}

那么你再使用提交ack机制的时候

//提交单条消息
channel.basicAck(deliveryTag,false); 

就会出现如下 错误:

第一条:

        表明这条消息对于MQ来说没找到,重点是这个---unknown delivery tag 1-参考rabbitMQ的tag机制可知这条消息已经完成了消费。

com.rabbitmq.client.ShutdownSignalException: channel error; protocol method: #method<channel.close>(reply-code=406, reply-text=PRECONDITION_FAILED - unknown delivery tag 1, class-id=60, method-id=80)

第二条 :

        表明这条消息被一个设置为自动确认的任务给确认了,意思就是 你配置的手动ack变成了自动ack!

Restarting Consumer: tags=[{amq.ctag-zms15dchTPRiv8SH2W0_8Q=videoChange}], channel=Cached Rabbit Channel: AMQChannel(amqp://admin@59.110.229.19:5672/,2), conn: Proxy@131c5bd Shared Rabbit Connection: SimpleConnection@3a500321 [delegate=amqp://admin@59.110.229.19:5672/, localPort= 50032], acknowledgeMode=AUTO local queue size=0

这个问题解决办法就是把所有的配置信息用代码设置,例如我们的手动确认ack机制。就OK了

@Bean
public RabbitListenerContainerFactory<?> rabbitListenerContainerFactory(ConnectionFactory connectionFactory){
    SimpleRabbitListenerContainerFactory factory = new         SimpleRabbitListenerContainerFactory();
    factory.setConnectionFactory(connectionFactory);
    factory.setMessageConverter(new Jackson2JsonMessageConverter());
    factory.setAcknowledgeMode(AcknowledgeMode.MANUAL); //设置手动ack
    return factory;
}

<think>嗯,用户想知道RabbitMQSocket在消息传递效率方面的差异。首先,我需要理解两者的基本概念用途。RabbitMQ是一个消息队列系统,通常用于应用间的异步通信解耦。而Socket是更底层的网络通信机制,直接处理数据传输。接下来,我得比较它们在性能上的不同点,比如吞吐量、延迟、资源消耗等方面。 用户可能是一个开发者,正在设计一个需要处理大量消息的系统,纠结于选择哪种通信方式。他们可能关心在高并发或大数据量下的表现,以及实现的复杂度维护成本。用户可能没有明确提到这些因素,但深层需求可能是寻找最适合自己应用场景的解决方案,而不仅仅是性能数据。 首先,我需要回顾两者的架构差异。RabbitMQ作为中间件,提供了消息持久化、确认机制、路由等功能,这些功能虽然增加了可靠性,但也会带来额外的开销。而Socket直接传输数据,没有这些中间步骤,理论上延迟更低,但需要自己处理错误恢复、消息顺序等问题。 接下来,性能指标方面,吞吐量方面,Socket可能更高,因为没有中间件的处理开销。但RabbitMQ在持久化高可靠性的场景下,虽然吞吐量可能低一些,但能保证消息不丢失。延迟方面,Socket更优,尤其是局域网内,RabbitMQ因为需要经过中间件处理,会有更多的延迟。 资源消耗方面,RabbitMQ需要维护队列、交换器等结构,占用更多内存CPU,而Socket更轻量。但这也意味着使用Socket时,开发者需要自己实现很多功能,增加了开发复杂度。 用户可能的应用场景是什么?如果是需要高可靠性解耦的异步任务处理,RabbitMQ更适合。如果是实时性要求极高的场景,比如高频交易,可能Socket更合适。但用户的问题主要是效率对比,所以需要详细说明在不同情况下的表现。 另外,引用中的信息需要注意。比如引用[1]提到RabbitMQ适合异步任务解耦,引用[2]提到消息回查机制,引用[3]比较了ActiveMQ的问题。这些可以支持RabbitMQ在可靠性的优势,但性能方面需要结合具体情况。 可能还需要考虑集群扩展性。RabbitMQ支持集群,可以水平扩展,而Socket需要自己实现负载均衡故障转移,这可能影响效率。 总结来说,RabbitMQ消息可靠性系统解耦方面有优势,适合复杂的业务场景,而Socket在极致的性能需求下更高效,但需要更多的开发工作。用户需要根据自己的需求权衡选择。</think>### RabbitMQ vs Socket 性能对比分析 #### 1. **架构与功能差异** - **RabbitMQ**:基于AMQP协议的消息中间件,提供消息持久化、确认机制、路由规则、负载均衡等功能,支持异步通信解耦[^1]。 - **Socket**:底层网络通信接口,直接通过TCP/UDP传输数据,无内置的消息管理机制,需手动处理粘包、重传、序列化等问题。 #### 2. **性能核心指标对比** | 指标 | RabbitMQ | Socket | |---------------|------------------------------|--------------------------| | **吞吐量** | 中等(受队列持久化影响) | 高(无中间件开销) | | **延迟** | 较高(需经过中间件处理) | 低(直接点对点传输) | | **资源消耗** | 较高(维护队列、交换器等) | 低(仅需基础网络资源) | | **可靠性** | 高(支持消息确认、持久化) | 依赖手动实现(易丢消息) | #### 3. **典型场景效率分析** - **高并发异步任务**: RabbitMQ通过消息队列缓冲请求,避免系统过载,适合处理突发流量[^1]。 例如,10万条任务处理时,RabbitMQ可稳定维持约5k-10k msg/s的吞吐量,而Socket若未优化可能因资源竞争导致性能波动。 - **实时数据传输**: Socket在局域网内延迟可低至0.1ms,适合高频交易等场景; RabbitMQ因协议解析队列操作,延迟通常在1-10ms。 - **大规模持久化场景**: RabbitMQ启用磁盘持久化后,吞吐量下降约30%,但保证数据安全; Socket需自行实现持久化逻辑,可能引入更高开销。 #### 4. **优化方向** - **RabbitMQ**: - 使用`mandatory`标志确保消息可达[^2] - 关闭不必要的ACK确认(如用`autoAck=true`) - 采用多线程消费者提升并发 ```python channel.basic_qos(prefetch_count=100) # 提升消费者吞吐量 ``` - **Socket**: - 使用二进制协议(如Protobuf)减少数据体积 - 实现连接池复用TCP连接 - 添加应用层ACK机制模仿消息确认[^2] #### 5. **选择建议** - 选**RabbitMQ**若需:消息可靠性、系统解耦、流量削峰[^1] - 选**Socket**若需:极致性能、定制协议、低资源环境
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

一名陈序员

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值