等待API服務器中的響應

我有一個Netty HTTP服務器用作API服務器。用戶將事件發送到API服務器，並使用執行器服務或併發框架（如Akka）在同一服務器上的其他線程上處理事件。我有兩個答案選項;當我將事件發送到另一個線程時，我可以等待響應並將其寫入套接字或將確認消息寫回套接字。等待API服務器中的響應

當我等待響應時，http請求的延遲增加，服務器可以處理的請求數減少。另一方面，不能控制背壓，所以我們不知道服務器何時處理事件，並且我不能通知用戶服務器處理了事件。但是，服務器可以處理的http請求數量會增加，因爲幾乎所有請求的延遲都很低。

public void channelRead(ChannelHandlerContext ctx, Object msg) { 
    if (msg instanceof HttpRequest) { 
     executor.submit(new Event(msg)); 
     // do not wait for the response 
     ctx.write(new DefaultFullHttpResponse(HTTP_1_1, OK)); 
    } 
} 

public void channelRead(ChannelHandlerContext ctx, Object msg) { 
    if (msg instanceof HttpRequest) { 
     Future<Object> future = executor.submit(new Event(msg)); 
     future.after(x -> ctx.write(new DefaultFullHttpResponse(HTTP_1_1, OK))); 
    } 
}

因爲它是一個API服務器，我沒有等待，以便通知被處理事件的用戶的響應，因爲它只是一個寫請求不返回響應。那麼對於http服務器來說哪種方式最爲方便，您認爲第二種方式值得其性能受益嗎？

來源

2014-10-26 Boyolame

那麼問題是什麼？ – biziclop 2014-10-26 18:31:12

我更新了問題@biziclop – Boyolame 2014-10-26 19:01:57

我認爲答案取決於您的要求。一般而言，遵循的一個好哲學是保持簡單。這可能意味着需要完成最少量的工作，這可能意味着留下可擴展空間。如果您的用例不提供狀態是有意義的，那麼您會這樣做的原因是什麼？然而，通常在簡單和提供足夠的系統可視性之間進行權衡。這聽起來像你不確定什麼是和不是必需的？

問問你自己以下問題：

的客戶端可以使用返回狀態做一些有意義的事？你的客戶沒有這種身份可以做什麼？
您是否可以預見客戶需要在未來發生變化以要求回覆後處理？（即退貨狀態，退貨正文，錯誤代碼等）
您的服務器是否需要跟蹤從獲取客戶端請求到將服務器轉換爲服務器所發生的一切？
您的可見度和調試問題的能力是什麼？
添加功能所需的額外複雜性和開銷是多少？這可以接受嗎？

這些只是在這種情況下你應該問自己的許多問題中的幾個。根據您提供的信息，我不確定是否有可能向您提供「您應該做X」或「您應該做Y」的答案。我認爲最好的辦法是重新評估你的要求，然後問自己一些像上面列出的問題。

來源

2014-10-28 01:07:09

等待API服務器中的響應

回答

相關問題