使用Message Queue處理REST請求

Question

我有兩個申請，如下所述：

1. Spring Boot應用程序-充當其余端點，將請求發布到消息隊列。 （Apache Pulsar）
2. 鷺（Storm）拓撲-處理從消息隊列（PULSAR）接收的消息，並具有處理的所有邏輯。

我的需求是，我需要通過Spring Boot應用程序為不同的用戶查詢提供服務，該應用程序將該查詢發送到消息隊列，並在spout中使用。 一旦噴嘴和螺栓處理了請求，螺栓將再次發布一條消息。 來自Bolt的響應在Spring引導（消費者）時處理，並回復用戶請求。 典型地如下圖所示：

為了滿足相同的請求，我現在在內存中緩存延遲的結果對象（我為發送到拓撲的每條消息都設置了一個reqID，並且我還維護了一個鍵，值對）在消息到達時我解析請求id並將結果設置為defferedResult（我知道這是一個錯誤的設計， 應該如何解決這個問題？ ）。

在這種情況下，如何從拓撲接收的消息順序不是順序的，如何繼續將響應提供給相同的請求（因為每個請求（即進程）需要花費自己的時間，並且生產者螺栓將在響應時觸發響應）收到一個）。

我有點受這種設計的束縛，無法繼續進行下去。

//Controller
public DeferredResult<ResponseEntity<?>> process(//someinput) {
    DeferredResult<ResponseEntity<?>> result = new DeferredResult<>(config.getTimeout());
    CompletableFuture<String> serviceResponse = service.processAsync(inputSource);
    serviceResponse.whenComplete((response, exception) -> {
        if (!ObjectUtils.isEmpty(exception))
            result.setErrorResult(//error);
        else
            result.setResult(//complete);
    });
    return result;
}

//In Service
public CompletableFuture processAsync(//input){
    producer.send(input);
    CompletableFuture result = new CompletableFuture();
    //consumer has a listener as shown below
    // **I want to avoid below line, how can I redesign this**
    map.put(id, result);
  return result;
}

//in same service, a listener is present for consumer for reading the messages
consumerListener(Message msg){
     int reqID = msg.getRequestID();
     map.get(reqID).complete(msg.getData);
}

如上所示，一收到消息，我就獲得了completableFuture對象並設置了結果，該對象內部調用了延遲結果對象並將響應返回給用戶。

Answer 1

在這種情況下，如何從拓撲接收的消息順序不是順序的，如何繼續將響應提供給相同的請求（因為每個請求（即進程）需要花費自己的時間，並且生產者螺栓將在響應時觸發響應）收到一個）。

聽起來您正在尋找“ 相關標識符”消息傳遞模式。 粗略地講，您將計算/創建一個標識符，該標識符將附加到發送給pulsar的消息上，並安排Heron將其從收到的請求復制到發送的響應中。

因此，當您的Spring Boot組件在步驟5消耗pulsar的消息時，請將相關ID匹配到正確的http請求，然后返回結果。

據我所知，使用原始的requestId（）作為關聯標識符應該沒問題。

為了滿足相同的請求，我現在在內存中緩存延遲的結果對象（我為發送到拓撲的每條消息都設置了一個reqID，並且我還維護了一個鍵，值對）在消息到達時我解析請求id並將結果設置為defferedResult（我知道這是一個錯誤的設計，如何解決這個問題？）。

最終，您可能會在某種程度上這樣做。 這就是說，消費者在第5步將要使用相關ID查找的東西 ，儲存由生產者。 試圖跨越四個不同的流程邊界傳遞原始請求很可能會落淚。

更一般的形式是在地圖中存儲一個callback ，而不是CompletableFuture 。 但是在這種情況下，回調可能只是完成了將來。

我想在設計中仔細檢查一件事：您要確保消費者在第5步中能夠在消息到達之前看到它應該使用的未來。 換句話說，應該在內存障礙之前發生某事，以確保第5步中的映射查找不會失敗。