哪些情况会失败

网络问题有很多原因出发失败。防火墙也可能会中断Idle连接,网络失败不是很快确定的。 硬件和软件也会导致系统崩溃。客户端软件保持运行,而逻辑错误也可能会导致channel和connection错误。这就要求我们可以恢复new channel或者connection从这个问题中。

#Connection 失败

Connection失败后,客户端需要重新构建一个新的Connection。任何之前打开的Channel会重新打开。

会有特定的异常抛出,例如Java 提供了ShutdownListener和DotNet提供的Iconnection.ConnectionShutdown时间。

##确认和提交(Acknowledgements and Confirms)

当连接失败,消息可能在客户端和服务器端之间进行传输。 确认可以让服务器和客户端之间知道彼此的状态。 在RabbitMQ中,Consumer与服务器之间确认行为叫做”Acknowledgements”,而Producer与服务器之间确认行为叫做“Confirms”。

Acknowledgements的场景:消费软件不确认这个消息,直到它使用接受到的消息,完成自己的工作。一旦Broker接受到这个消息确认信息,将清除这个消息。

Confirms的场景:当Broker接受到不能路由的消息,并且消息被设置为mandatory,消息basic.return会在basic.ack之前返回。对于路由之后的消息,basic.ack会让所有接受到这个消息的数据,存储到磁盘中。对于镜像队列来说(Mirrored Queue),会让所有镜像都统一确认这些消息。

##心跳
部分网络问题,包的丢失可能是由于操作系统破坏了TCP链接。AMQP使用心跳的特征在软件层次检测链接是否被破坏了。心跳也会阻止一些网络设备阻止当前“idle”tcp链接。 broker会协商连接的heartbeat的频率。

#对于Producer(消息生产者)

当使用confirm时候,如果channel或者connection失败,Producer应该重新发送所有没有来得及提交的数据。

这里可能会造成数据重复,因为服务器broker可能已经发送确认数据到Producer了。因此consumer应用可以处理重复数据,保持一个幂等的状态。(幂等状态是指,无论consumer处理了几次相同的数据,结果都是一样的。例如:x=2是幂等。x=x+2就不是幂等)

##确定消息是被路由的

producer应该保证发送的消息被路由(Router)到队列中(Queues). 为了保证producer发送消息可以被最少一条队列接受(Queue),我们在发送消息的时候,必须设置mandatory标示,在发送消息时候(AMQP的协议对应basic.publish,Java的版本对应Channel.basicPublish方法)。当消息没有被队列接受时,我们可以通过返回值(AMQP协议的basic.return)获得一个返回码和其他文本数据。

Producer也应该认识到发送消息到集群中,集群之间都需要复制消息。也增加了网络失败造成的延时情况。

#对于Consumer(对于消费者)

如果一个消息发送到Consumer,而Consumer没有确认并且Connection中断,那么这个消息重新进入队列,再次发送出去之后,会有一个redelivedred标签。帮助Consumer的应用判断当前数据是否重复发送。

##Consumer取消
Consumer取消是服务器端发起,告诉Consumer当前消费被终止了。Consumer取消发起的原因:当前的Queue被删除,或者其他失败情况。这是Rabbitmq的一个扩展,部分客户端才能支持。(Java和DotNet都支持)。

##消息不能被处理
consumer可以发送消息给服务端,告知消息被拒绝(AMQP的basic.reject和basic.nack),让服务器重新发送他们,或者根据dead-le

#分布式下的RabbitMQ
当网络不稳定的时候,使用federation和shovel来实现功能。我们也可以配置他们实现confirm和acknowledgement功能。