2 回答
TA貢獻(xiàn)1858條經(jīng)驗(yàn) 獲得超8個(gè)贊
郵件跟蹤在兩個(gè)主要方面與典型的 RPC 跟蹤不同。因?yàn)樗遣煌模耘cRPC相比并不是找出前進(jìn)道路的最佳方法。我將在這里簡(jiǎn)要提及幾件事,這些事情主要在我為該主題制作的幻燈片中。
在消息傳遞中,通常沒(méi)有在使用者和消息處理器之間傳遞線程上下文。這與 RPC 不同,RPC 通常至少在請(qǐng)求端有一個(gè)切換。
當(dāng)我們有一個(gè)線程上下文時(shí),我們應(yīng)該使用它來(lái)建立父信息(兔子處理就是這種情況)。但是,情況往往并非如此。因此,當(dāng)我們不知道消息傳遞處理抽象時(shí),我們經(jīng)常重新序列化消息上的標(biāo)頭。
在你的例子中,你說(shuō)的是spring-rabbit,它在處理塊期間使用線程上下文來(lái)適當(dāng)?shù)卦O(shè)置“當(dāng)前跨度”。由于我們不想將基于線程的上下文與消息中的內(nèi)容混淆,因此我們清除了標(biāo)頭。
“重試”案確實(shí)對(duì)此提出了質(zhì)疑。在這種情況下,父母應(yīng)該是什么,如何知道?有問(wèn)題的檢測(cè)的一個(gè)問(wèn)題是,我們實(shí)際上沒(méi)有看到使用消息的代碼。
具體來(lái)說(shuō),rabbitmq輪詢(xún)工具不存在,所以我們放了一個(gè)“假的消費(fèi)者跨度”來(lái)追溯性地解釋這一點(diǎn)。如果消息已重新播放。也許第二個(gè)消費(fèi)者跨度是有效的。坦率地說(shuō),我們沒(méi)有考慮這一點(diǎn)。
無(wú)論如何,我的觀點(diǎn)是,我們不應(yīng)該過(guò)分關(guān)注消息傳遞跟蹤和RPC之間的差異,因?yàn)槟抢飼?huì)有一些有意的差異。讓我們專(zhuān)注于差距本身,并可能在gitter上這樣做,我認(rèn)為這會(huì)導(dǎo)致github問(wèn)題。
無(wú)論如何,我希望上下文可以回答您的問(wèn)題,即使它不會(huì)改變代碼當(dāng)前執(zhí)行其功能的事實(shí)。
TA貢獻(xiàn)1802條經(jīng)驗(yàn) 獲得超5個(gè)贊
作為一種解決方法,我們需要將重試攔截器沿鏈向下移動(dòng)。
@Bean
@Order
BeanPostProcessor reorderingSimpleRabbitListenerContainerFactory() {
return new BeanPostProcessor() {
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
if (SimpleRabbitListenerContainerFactory.class.isAssignableFrom(bean.getClass())) {
final Class<RetryOperationsInterceptor> retryInterceptor = RetryOperationsInterceptor.class;
Advice[] adviceChain = ((SimpleRabbitListenerContainerFactory) bean).getAdviceChain();
Arrays.sort(adviceChain, (o1, o2) -> {
if (o1.getClass().isAssignableFrom(retryInterceptor)) {
return 1;
}
if (o2.getClass().isAssignableFrom(retryInterceptor)) {
return -1;
}
return 0; // it is stable sort, so no worry
});
}
return bean;
}
};
}
添加回答
舉報(bào)
