有沒(méi)有辦法計(jì)算作業(yè)重新排隊(duì)的次數(shù)（通過(guò)拒絕或 Nak）而無(wú)需手動(dòng)重新排隊(duì)作業(yè)？我需要重試工作“n”次，然后在“n”次后放棄。ps：目前我手動(dòng)重新排隊(duì)作業(yè)（如果計(jì)數(shù)器不存在或值小于“n”，則刪除舊作業(yè)，創(chuàng)建具有確切內(nèi)容和額外計(jì)數(shù)器標(biāo)頭的新作業(yè)）
2 回答
拉丁的傳說(shuō)
TA貢獻(xiàn)1789條經(jīng)驗(yàn) 獲得超8個(gè)贊
有redelivered消息屬性，該屬性設(shè)置為true時(shí)消息重新發(fā)送一個(gè)或更多的時(shí)間。
如果您想跟蹤重新傳遞計(jì)數(shù)或左重新傳遞數(shù)（又名跳數(shù)限制或 IP 堆棧中的 ttl），您必須將該值存儲(chǔ)在消息正文或標(biāo)題中（字面意思是 - 消費(fèi)消息，修改它，然后將修改后的消息發(fā)布回代理）。
隔江千里
TA貢獻(xiàn)1906條經(jīng)驗(yàn) 獲得超10個(gè)贊
在消息實(shí)際上是死信的情況下，您可以檢查x-death消息頭的內(nèi)容。
例如，當(dāng)您reject/ nackwithrequeue = false并且隊(duì)列具有關(guān)聯(lián)的死信交換時(shí)就是這種情況。
在這種情況下，此標(biāo)頭的內(nèi)容是一個(gè)數(shù)組。每個(gè)元素描述一次失敗的交付嘗試，包含嘗試交付的時(shí)間、路由信息等信息。
這適用于 RabbitMQ - 我不知道它是否適用于一般的 AMQP。
編輯
自從我最初寫(xiě)這個(gè)答案以來(lái)，x-death標(biāo)題結(jié)構(gòu)已更改。
標(biāo)頭更改格式通常是一件非常糟糕的事情，但在這種特殊情況下，原因是如果消息連續(xù)死信，消息大小將無(wú)限增長(zhǎng)。
因此，我刪除了用于獲取消息死亡人數(shù)的代碼段。
仍然可以從新的標(biāo)題格式中獲得死亡人數(shù)。
- 2 回答
- 0 關(guān)注
- 353 瀏覽
添加回答
舉報(bào)
0/150
提交
取消