1.了解servlet以及spring mvc中的異步

Spring MVC 3.2開始引入了基于Servlet 3的異步請求處理。相比以前，控制器方法已經(jīng)不一定需要返回一個(gè)值，而是可以返回一個(gè)java.util.concurrent.Callable的對象，并通過Spring MVC所管理的線程來產(chǎn)生返回值。與此同時(shí)，Servlet容器的主線程則可以退出并釋放其資源了，同時(shí)也允許容器去處理其他的請求。通過一個(gè)TaskExecutor，Spring MVC可以在另外的線程中調(diào)用Callable。當(dāng)Callable返回時(shí)，請求再攜帶Callable返回的值，再次被分配到Servlet容器中恢復(fù)處理流程。以下代碼給出了一個(gè)這樣的控制器方法作為例子：

@RequestMapping(method=RequestMethod.POST)
public CallableprocessUpload(final MultipartFile file) {
    return new Callable() {
        public String call() throws Exception {
            // ...
            return "someView";
        }
    };
}

另一個(gè)選擇，是讓控制器方法返回一個(gè)DeferredResult的實(shí)例。這種場景下，返回值可以由任何一個(gè)線程產(chǎn)生，也包括那些不是由Spring MVC管理的線程。舉個(gè)例子，返回值可能是為了響應(yīng)某些外部事件所產(chǎn)生的，比如一條JMS的消息，一個(gè)計(jì)劃任務(wù)，等等。以下代碼給出了一個(gè)這樣的控制器作為例子：

@RequestMapping("/quotes")
@ResponseBody
public DeferredResultquotes() {
    DeferredResultdeferredResult = new DeferredResult();
    // Save the deferredResult somewhere..
    return deferredResult;
}
    // In some other thread...
    deferredResult.setResult(data);

如果對Servlet 3.0的異步請求處理特性沒有了解，理解這個(gè)特性可能會有點(diǎn)困難。因此，閱讀一下前者的文檔將會很有幫助。

以下給出了這個(gè)機(jī)制運(yùn)作背后的一些原理：

一個(gè)servlet請求ServletRequest可以通過調(diào)用request.startAsync()方法而進(jìn)入異步模式。這樣做的主要結(jié)果就是該servlet以及所有的過濾器都可以結(jié)束，但其響應(yīng)（response）會留待異步處理結(jié)束后再返回調(diào)用request.startAsync()方法會返回一個(gè)AsyncContext對象，可用它對異步處理進(jìn)行進(jìn)一步的控制和操作。比如說它也提供了一個(gè)與轉(zhuǎn)向（forward）很相似的dispatch方法，只不過它允許應(yīng)用恢復(fù)Servlet容器的請求處理進(jìn)程ServletRequest提供了獲取當(dāng)前DispatherType的方式，后者可以用來區(qū)別當(dāng)前處理的是原始請求、異步分發(fā)請求、轉(zhuǎn)向，或是其他類型的請求分發(fā)類型。

有了上面的知識，下面可以來看一下Callable的異步請求被處理時(shí)所依次發(fā)生的事件：

• 控制器先返回一個(gè)Callable對象
• Spring MVC開始進(jìn)行異步處理，并把該Callable對象提交給另一個(gè)獨(dú)立線程的執(zhí)行器TaskExecutor處理
• DispatcherServlet和所有過濾器都退出Servlet容器線程，但此時(shí)方法的響應(yīng)對象仍未返回
• Callable對象最終產(chǎn)生一個(gè)返回結(jié)果，此時(shí)Spring MVC會重新把請求分派回Servlet容器，恢復(fù)處理
• DispatcherServlet再次被調(diào)用，恢復(fù)對Callable異步處理所返回結(jié)果的處理
• 對DeferredResult異步請求的處理順序也非常類似，區(qū)別僅在于應(yīng)用可以通過任何線程來計(jì)算返回一個(gè)結(jié)果：
• 控制器先返回一個(gè)DeferredResult對象，并把它存取在內(nèi)存（隊(duì)列或列表等）中以便存取
• Spring MVC開始進(jìn)行異步處理
• DispatcherServlet和所有過濾器都退出Servlet容器線程，但此時(shí)方法的響應(yīng)對象仍未返回
• 由處理該請求的線程對 DeferredResult進(jìn)行設(shè)值，然后Spring MVC會重新把請求分派回Servlet容器，恢復(fù)處理
• DispatcherServlet再次被調(diào)用，恢復(fù)對該異步返回結(jié)果的處理

2.簡述polling和long polling的區(qū)別

這里暫拋開某些場景webSocket的解決方案。

舉一個(gè)生活中的列子來說明長輪詢比輪詢好在哪里：電商云集的時(shí)代，大家肯定都有查詢快遞的經(jīng)歷，怎么最快知道快遞的進(jìn)度呢？polling和long polling的方式分別如下：

• polling：如果我想在兩分鐘內(nèi)看到快遞的變化，那么，輪詢會每隔兩分鐘去像服務(wù)器發(fā)起一次快遞變更的查詢請求，如果快遞其實(shí)是一個(gè)小時(shí)變更一次，那么polling的方式在獲取一次真實(shí)有效信息時(shí)需要發(fā)起30次
• long polling：首先發(fā)起查詢請求，服務(wù)端沒有更新的話就不回復(fù)，直到一個(gè)小時(shí)變更時(shí)才將結(jié)果返回給客戶，然后客戶發(fā)起下次查詢請求。長輪詢保證了每次發(fā)起的查詢請求都是有效的，極大的減少了與服務(wù)端的交互，基于web異步處理技術(shù)，大大的提升了服務(wù)性能

如果在發(fā)散的觸類旁通一下，long polling的方式和發(fā)布訂閱的模式有點(diǎn)類似之處，只是每次拿到了發(fā)布的結(jié)果之后需要再次發(fā)起消息訂閱

3.因?yàn)镈eferredResult，所以long polling

因?yàn)镈eferredResult技術(shù)，所以使得long polling不會一直占用容器資源，使得長輪詢成為可能。長輪詢的應(yīng)用有很多，簡述下就是：需要及時(shí)知道某些消息的變更的場景都可以用長輪詢來解決，當(dāng)然，你可能又想起了發(fā)布訂閱了，哈哈

• 比如：在線聊天？一個(gè)服務(wù)端，多個(gè)客戶端，服務(wù)端管理所有的人的消息，客戶端向服務(wù)端發(fā)起給自己的消息的請求，服務(wù)端處理后給返回，然后客戶端再次發(fā)起？
• 在比如類發(fā)布訂閱的例子：配置中心服務(wù)，當(dāng)配置中心的配置變更好，相關(guān)的客戶端程序需要及時(shí)更新最新的配置。disconf就是基于zookeeper的發(fā)布訂閱來做的，apollo就是采用的DeferredResult的long polling來做的，客戶端發(fā)起長輪詢，配置中心監(jiān)聽器監(jiān)聽到配置變更后，將結(jié)果響應(yīng)給客戶端。

apollo的具體做法可見

• 服務(wù)端：com/ctrip/framework/apollo/configservice/controller/NotificationControllerV2.java 
• 客戶端：com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java

4.簡單的測試用例

多個(gè)請求的結(jié)果，使用另一個(gè)請求控制他的響應(yīng)返回。本實(shí)例構(gòu)建在spring boot 1.5.7上。

1.定義異步接口

/**
 * Created by kl on 2017/9/27.
 * Content :
 */
@RestController
@RequestMapping("/async")
public class AsyncController {
    final Map deferredResultMap=new ConcurrentReferenceHashMap<>();
    @GetMapping("/longPolling")
    public DeferredResultlongPolling(){
        DeferredResultdeferredResult=new DeferredResult(0L);
        deferredResultMap.put(deferredResult.hashCode(),deferredResult);
        deferredResult.onCompletion(()->{
            deferredResultMap.remove(deferredResult.hashCode());
            System.err.println("還剩"+deferredResultMap.size()+"個(gè)deferredResult未響應(yīng)");
        });
        return deferredResult;
    }
    @GetMapping("/returnLongPollingValue")
    public void returnLongPollingValue(){
        for (Map.Entry entry:deferredResultMap.entrySet()){
            entry.getValue().setResult("kl");
        }
    }
}

2.定義接口訪問實(shí)例，使用fegin

/**
 * Created by kl on 2017/9/27.
 * Content :
 */
@FeignClient(url = "localhost:8976",name = "async")
public interface AsyncFeginService {
    @GetMapping("/async/longPolling")
    String longPolling();
    @GetMapping("/async/returnLongPollingValue")
     void returnLongPollingValue();
}

3.測試用例

@RunWith(SpringRunner.class)
@SpringBootTest
public class LongPollingdemoApplicationTests {
	@Autowired
	AsyncFeginService asyncFeginService;
	/**
	 * 模擬多個(gè)瀏覽器客戶端發(fā)起長輪詢請求，等待testLongPolling測試用例請求通知服務(wù)端返回各瀏覽器的請求結(jié)果
	 * @throws Exception
	 */
	@Test
	public void contextLoads() throws Exception{
		ExecutorService executorService=Executors.newFixedThreadPool(4);
		for (int i=0;i<=3;i++){
			executorService.execute(()->{
				String kl=asyncFeginService.longPolling();
				System.err.println("收到響應(yīng)："+kl);
			});
		}
		System.in.read();
	}
	/**
	 * 通知服務(wù)端返回上個(gè)測試的長輪詢結(jié)果
	 */
	@Test
	public void testLongPolling(){
		asyncFeginService.returnLongPollingValue();
	}
}

測試時(shí)，先啟動contextLoads會發(fā)起四個(gè)異步請求，一直等待請求結(jié)果響應(yīng)，直到testLongPolling通知服務(wù)端返回deferredResult的值。

以上就是springMvc中DeferredResult的long polling應(yīng)用示例解析內(nèi)容，更多關(guān)于springMvc DeferredResult的long polling應(yīng)用的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論