本文主要內容來自於
用慣了Web Services，但是很少知道RPC和RMI，更不用說它們之間的區別了，所以先總結一下RPC以及RMI到底是什麼東西！！

在分散式系統通訊中有兩個最基本的遠端呼叫技術，分別是：

• RPC：一個對遠端節點上的過程的呼叫就像呼叫本地節點那樣完成；
• RMI：與特定的Java RMI要進行區分，與RPC最大區別在於使用了面向物件的概念，那麼在遠端呼叫時可以把物件應用作為引數傳遞，它的實現最典型的就是Java RMI，但不限於Java RMI；

1、互動協議

遠端呼叫允許客戶端透明地呼叫在伺服器程式中的過程，而這些伺服器程式在不同的程序中，並且通常在不同於客戶端的計算機中。如果要完成遠端呼叫，必然要設計出一種協議讓客戶端和服務端來遵守，這樣才能讓呼叫者和提供呼叫過程者協同完成工作。其實我們對這種“協議”也不陌生，比如熟知的TCP/IP協議和Http協議等等。在遠端呼叫過程中有多種互動協議，如下：

• 請求協議：可以用在不需要從遠端操作中返回值或者客戶端不需要得到遠端操作執行確認的場景中，請求傳送後客戶端不需要等待應答訊息而可以繼續執行；
• 請求-應答協議：這種方式使我們最常見的，伺服器的應答訊息可以看做是客戶端請求訊息的一個確認；
• 請求-應答-確認應答協議：

這三種協議傳遞訊息的方式如下：

這裡著重瞭解一下請求-應答協議。在請求-應答協議中訊息可以是同步的也可以是非同步的。

• 同步：來自伺服器的應答到達客戶端之前客戶端的程序是阻塞的，如果寫過socket程式的人一定深有體會；
• 非同步：可以用在客戶端對服務端返回的結果允許延遲的情況下，例如執行該過程需要消耗很長的時間，這樣就避免了客戶端程序的堵塞，但是如果服務端執行完則可以通過回撥的方式來通知客戶端執行結果；

在通訊過程中涉及到三個原語，關於原語可以理解為不可分割的部分，在執行原語過程中不可以被打斷，可以類似理解為一個事務。該通訊同步過程如下：

• doOperation：呼叫遠端操作，方法引數包括遠端伺服器的地址、埠以及待呼叫的操作和需要的引數，返回的結果可以是一個位元組陣列，然後根據協議使用的編碼方式解碼該陣列得出結果，傳送請求之後，程序開始阻塞來接收應答訊息。
• getRequest：伺服器程序通過該方法獲取請求資訊，當確定操作後開始執行，完成之後通過sendReply方法向客戶端傳送應答訊息，這是客戶端接收訊息後才解除阻塞繼續執行。

下面的偽碼可以大致描述上述的三個方法：

//doOperation()
public byte[] doOperation(Remote remote, int operationId, byte[] arguments)

在該方法的引數中，Remote描述了遠端的伺服器，裡面可以包含伺服器的地址和埠以及對應的一些處理的方法；第二個引數operationId用來標識要呼叫哪個操作，用來確定操作過程；第三個引數就是用來傳遞引數。

//getRequest()
public void getRequest()

該方法只是用來從伺服器的一個埠上獲取客戶端的請求。

//sendReply()
public void sendReply(byte[] reply, Remote client)

在該方法的引數中，client引數和remote引數類似是用來描述客戶端的，包括地址和埠號，reply是需要返回給客戶端的資料。
就像在傳送Http請求和接收響應時的Headers一樣，請求訊息和應答訊息中也有傳遞資訊的格式，如下所示：

• messageType表明該訊息是請求訊息還是應答訊息；
• requestId是用來標明一個請求訊息的，在每個doOperation()方法中都會為一條請求訊息生成一個RequestId，這樣在該請求訊息傳遞到伺服器端時，伺服器端的程式就會將該Id複製到對應的應答訊息上，這樣在客戶端才能檢查返回的應答資訊是否和發出的請求資訊相對應；
• remoteRef用來定位客戶端或者伺服器，包括ip和埠號等；
• operationId用來標識要呼叫哪項操作，可以通過索引將所有的操作編號；
• arguments則是要使用到的引數；

其實在上述的requestId是有缺陷的，由於傳送請求訊息的程序可能不止一個，而且這些程序可能不在同一臺電腦上，那麼這些訊息的requestId不會重複嗎？當然會了，那麼怎樣解決這個問題？可以加上該程序所在的主機的ip地址和相應的埠號就能區分出這些requestId是從哪些程序傳送出來的。
對於請求-應答協議可以從Http協議中深入瞭解，因為這就是一個典型的請求-應答協議的例子。

2、故障處理

在遠端過程呼叫時不可避免的會出現各種各樣的問題，比如由於網路傳輸的問題導致的資訊傳遞中斷，或者當伺服器出現故障時不能及時返回應答資訊等等。想想如果在傳送Http請求時出現這樣的問題我們會看到什麼，網路錯誤！！Time Out！！通常就是幾種方式，如果使用了瀏覽器，不同的瀏覽器可能會建議我們去檢查什麼東西。那麼在遠端呼叫時一樣要考慮這種問題，這裡使用超時來暗示這種問題的存在。但是當超出我們設定的時間之後會發生什麼，其實是由我們來處理的，比如：

• 最簡單的但是也是最懶的方法，直接將這種超時的資訊拋給客戶端呼叫者，由他來決定下一步幹什麼，但是這就顯得我們的方法太不“智慧”了；
• 另外一種方法可以通過程式設計來實現，如果這次超時，可以進行重試，重試的次數可以程式設計決定，多長時間重試一次亦可以程式設計決定；
• 或者在客戶端通過非同步的方式來呼叫該過程，那麼我們在客戶端就不用考慮超時的問題了，這樣請求訊息和應答訊息就有足夠的時間進行傳遞，而當應答訊息返回時，可以通過回撥的方法來通知客戶端，這種可以設計成基於事件的，類似於AngularJs中的onSuccess()和onError()等，但是這樣做的前提是客戶端對該應答訊息的延遲有相當的容忍程度；

上面提到可以通過重試來解決超時的問題，但是別的問題又來了，當在伺服器端對客戶端呼叫的操作的處理的時間和返回結果的時間總和大於我們在客戶端設定的超時時間，就會產生請求訊息重複傳送的問題，但是本來執行該項請求就很費時間，所以絕不能夠再讓伺服器重複執行該操作，所以在服務端應該能夠識別requestId連續且來自同一個客戶端的訊息並且過濾掉重複的訊息。

對於重複的請求訊息，其中還有一些細節可以體會一下。

• 如果服務端接收到重複訊息時還沒有發回應答訊息，這樣就比較簡單了，等待服務端執行完畢然後返回該應答訊息即可；
• 但是如果接到重複訊息之後發現應答訊息已經發送出去，不可否認，這種情況是存在的，這時服務端就不能區分該重複的請求資訊是客戶端故意重新發的，還有由於超時程式自己重試的。
  
  • 我的想法是，如果客戶端和服務端可以溝通就好了，可以彼此設定超時時間是多少，這樣在服務端那就可以根據超時時間來判斷自己識別重複請求訊息的策略。
  • 但是如果彼此不能協商，那麼必須要做的就是每一個請求訊息都要做出應答，如果對於不耗時的操作可以這麼做，是沒有問題的，這可以看做是一個冪等操作，這種操作執行一次的效果與執行多次的效果是相同的；但是對於耗時的操作，可以通過在服務端使用快取儲存上次操作的結果來說減少執行的時間，但是這也有問題，如果儲存在快取中的資料與實際儲存在伺服器後臺的資料不一致時就會返回錯誤的資訊，這種問題可以通過在更新伺服器的資料時也同時更新快取或者清除相關的快取來保持資料的一致性；

相關文章：