springMvc DeferredResult的long polling應用

http://www.kailing.pub/article/index/arcid/163.html

1.瞭解servlet以及spring mvc中的非同步？

Spring MVC 3.2開始引入了基於Servlet 3的非同步請求處理。相比以前，控制器方法已經不一定需要返回一個值，而是可以返回一個java.util.concurrent.Callable的物件，並通過Spring MVC所管理的執行緒來產生返回值。與此同時，Servlet容器的主執行緒則可以退出並釋放其資源了，同時也允許容器去處理其他的請求。通過一個TaskExecutor，Spring MVC可以在另外的執行緒中呼叫Callable。當Callable返回時，請求再攜帶Callable返回的值，再次被分配到Servlet容器中恢復處理流程。以下程式碼給出了一個這樣的控制器方法作為例子：

@RequestMapping(method=RequestMethod.POST)
public CallableprocessUpload(final MultipartFile file) {

    return new Callable() {
        public String call() throws Exception {
            // ...
            return "someView";
        }
    };
}

另一個選擇，是讓控制器方法返回一個DeferredResult的例項。這種場景下，返回值可以由任何一個執行緒產生，也包括那些不是由Spring MVC管理的執行緒。舉個例子，返回值可能是為了響應某些外部事件所產生的，比如一條JMS的訊息，一個計劃任務，等等。以下程式碼給出了一個這樣的控制器作為例子：

@RequestMapping("/quotes")
@ResponseBody
public DeferredResultquotes() {
    DeferredResultdeferredResult = new DeferredResult();
    // Save the deferredResult somewhere..
    return deferredResult;
}

// In some other thread...
deferredResult.setResult(data);

如果對Servlet 3.0的非同步請求處理特性沒有了解，理解這個特性可能會有點困難。因此，閱讀一下前者的文件將會很有幫助。

以下給出了這個機制運作背後的一些原理：

一個servlet請求ServletRequest可以通過呼叫request.startAsync()方法而進入非同步模式。這樣做的主要結果就是該servlet以及所有的過濾器都可以結束，但其響應（response）會留待非同步處理結束後再返回撥用request.startAsync()方法會返回一個AsyncContext物件，可用它對非同步處理進行進一步的控制和操作。比如說它也提供了一個與轉向（forward）很相似的dispatch方法，只不過它允許應用恢復Servlet容器的請求處理程式ServletRequest提供了獲取當前DispatherType的方式，後者可以用來區別當前處理的是原始請求、非同步分發請求、轉向，或是其他型別的請求分發型別。

有了上面的知識，下面可以來看一下Callable的非同步請求被處理時所依次發生的事件：

1. 控制器先返回一個Callable物件
2. Spring MVC開始進行非同步處理，並把該Callable物件提交給另一個獨立執行緒的執行器TaskExecutor處理
3. DispatcherServlet和所有過濾器都退出Servlet容器執行緒，但此時方法的響應物件仍未返回
4. Callable物件最終產生一個返回結果，此時Spring MVC會重新把請求分派回Servlet容器，恢復處理
5. DispatcherServlet再次被呼叫，恢復對Callable非同步處理所返回結果的處理
6. 對DeferredResult非同步請求的處理順序也非常類似，區別僅在於應用可以通過任何執行緒來計算返回一個結果：
7. 控制器先返回一個DeferredResult物件，並把它存取在記憶體（佇列或列表等）中以便存取
8. Spring MVC開始進行非同步處理
9. DispatcherServlet和所有過濾器都退出Servlet容器執行緒，但此時方法的響應物件仍未返回
10. 由處理該請求的執行緒對 DeferredResult進行設值，然後Spring MVC會重新把請求分派回Servlet容器，恢復處理
11. DispatcherServlet再次被呼叫，恢復對該非同步返回結果的處理

2.簡述polling和long polling的區別？

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

舉一個生活中的列子來說明長輪詢比輪詢好在哪裡：電商雲集的時代，大家肯定都有查詢快遞的經歷，怎麼最快知道快遞的進度呢？polling和long polling的方式分別如下：

• polling：如果我想在兩分鐘內看到快遞的變化，那麼，輪詢會每隔兩分鐘去像伺服器發起一次快遞變更的查詢請求，如果快遞其實是一個小時變更一次，那麼polling的方式在獲取一次真實有效資訊時需要發起30次
• long polling：首先發起查詢請求，服務端沒有更新的話就不回覆，直到一個小時變更時才將結果返回給客戶，然後客戶發起下次查詢請求。長輪詢保證了每次發起的查詢請求都是有效的，極大的減少了與服務端的互動，基於web非同步處理技術，大大的提升了服務效能

如果在發散的觸類旁通一下，long polling的方式和釋出訂閱的模式有點類似之處，只是每次拿到了釋出的結果之後需要再次發起訊息訂閱

3.因為DeferredResult，所以long polling？

因為DeferredResult技術，所以使得long polling不會一直佔用容器資源，使得長輪詢成為可能。長輪詢的應用有很多，簡述下就是：需要及時知道某些訊息的變更的場景都可以用長輪詢來解決，當然，你可能又想起了釋出訂閱了，哈哈

 

• 比如：線上聊天？一個服務端，多個客戶端，服務端管理所有的人的訊息，客戶端向服務端發起給自己的訊息的請求，服務端處理後給返回，然後客戶端再次發起？
• 在比如類釋出訂閱的例子：配置中心服務，當配置中心的配置變更好，相關的客戶端程式需要及時更新最新的配置。disconf就是基於zookeeper的釋出訂閱來做的，apollo就是採用的DeferredResult的long polling來做的，客戶端發起長輪詢，配置中心監聽器監聽到配置變更後，將結果響應給客戶端。apollo的具體做法可見服務端：com/ctrip/framework/apollo/configservice/controller/NotificationControllerV2.java 客戶端：com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java

 

4.簡單的測試用例？

多個請求的結果，使用另一個請求控制他的響應返回。本例項構建在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()+"個deferredResult未響應");
        });
        return deferredResult;
    }
    @GetMapping("/returnLongPollingValue")
    public void returnLongPollingValue(){
        for (Map.Entry entry:deferredResultMap.entrySet()){
            entry.getValue().setResult("kl");
        }
    }
}

2.定義介面訪問例項，使用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;
	/**
	 * 模擬多個瀏覽器客戶端發起長輪詢請求，等待testLongPolling測試用例請求通知服務端返回各瀏覽器的請求結果
	 * @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("收到響應："+kl);
			});
		}
		System.in.read();
	}
	/**
	 * 通知服務端返回上個測試的長輪詢結果
	 */
	@Test
	public void testLongPolling(){
		asyncFeginService.returnLongPollingValue();
	}
}

測試時，先啟動contextLoads會發起四個非同步請求，一直等待請求結果響應，直到testLongPolling通知服務端返回deferredResult的值