Thrift第五課 應用模式以及運行異常

1 簡單應答模式html

結構模型服務器

1)調用RPC接口的過程當中,參數是請求的結構信息,返回值是服務器的反饋信息網絡

2)對於服務器的告警信息和系統公告信息,客戶端須要定時發送查詢的RPC接口,而後在RPC的接口返值框架

中攜帶反饋信息ide

侷限性函數

測試代碼測試

short sThriftPort = 0;ui

std::string strThriftIP;spa

CSystemConfig::GetInstance().GetThriftServiceInfo(strThriftIP, sThriftPort);.net

boost::shared_ptr<UploadMessageServiceHandler> handler(new UploadMessageServiceHandler());

boost::shared_ptr<TProcessor> processor(new UploadMessageServiceProcessor(handler));

boost::shared_ptr<TServerTransport> serverTransport(new TServerSocket(sThriftPort));

boost::shared_ptr<TTransportFactory> transportFactory(new TBufferedTransportFactory());

boost::shared_ptr<TProtocolFactory> protocolFactory(new TBinaryProtocolFactory());


boost::shared_ptr<ThreadManager> threadManager = ThreadManager::newSimpleThreadManager(10);

boost::shared_ptr<BoostThreadFactory> threadFactory(new BoostThreadFactory());

threadManager->threadFactory(threadFactory);

threadManager->start();


TThreadPoolServer server(processor, serverTransport, transportFactory, protocolFactory, threadManager);

server.serve();


Windows下將PosixThreadFactory換成PlatformThreadFactory
Linux下將BoostThreadFactory換成PosixThreadFactory


在上述的服務器端進行客戶端請求的監聽,存在以下的問題

1 服務器端只有等待客戶端的鏈接,等待客戶端的請求發送,而後把應答的消息返回到客戶端,若是服務器端想主動發送消息

給客戶端,在當前的這種框架下是不可能實現的,必須調整當前的thrift的框架邏輯.

2 當客戶端沒有正常關閉套接字,服務器端會一直等待客戶端的請求,沒有機制確保服務器端知道客戶端已經丟棄當前的鏈接。

這種沒有客戶端發送心跳確保在線的機制,是否可以知足生產的需求,有待商榷

3 客戶端通常都是在NAT環境以後,因此客戶端沒法開啓端口對服務器的推送消息進行接收,只有在客戶端主動鏈接服務器,

保持鏈接的通道,能夠進行雙向通道的通訊

4 服務器端不會主動關閉鏈接,關閉鏈接都是由客戶端進行的,若是有惡意的鏈接,耗盡全部的線程,致使拒絕服務的風險


2 服務器模式

客戶端也是服務器,須要啓動端口進行監聽服務器端消息的推送


侷限性

客戶端須要開放端口進行監聽,若是客戶端部署在私有的網絡,經過NAT鏈接到公網的服務器,這一點目前單純依賴thrift框架沒法實現


3 雙向通道模式

結構模型

雙向通道確實可讓服務器端直接推送告警和系統公告信息給客戶端,可是thrift在這種應用結構中,不容許調用的RPC接口有任何的返回值,就相似於UDP的郵件的投遞,服務器端的反饋信息須要經過用RPC

發送給客戶端客戶端以一種相似回調的方式來獲取到反饋的信息


侷限性

發送的請求,須要在回調函數中獲得反饋信息,對因而否執行成功,客戶端須要等待


C#客戶端異常剖析

1)未將對象引用設置到對象的實例 緣由:沒法鏈接Thrift服務器

2)沒法將數據寫入傳輸鏈接(遠程主機強迫關閉了一個現有的鏈接) 緣由:Thrift服務器崩潰或者重啓,鏈接中斷

3)應用服務跟客戶端的代碼不一致:調用的目標發生了異常(沒法將數據寫入傳輸鏈接: 你的主機中的軟件停止了一個已創建的鏈接) 


C++接收代碼

類:class TDispatchProcessor : public TProcessor

函數:

  virtual bool process(boost::shared_ptr<protocol::TProtocol> in,

                       boost::shared_ptr<protocol::TProtocol> out,

                       void* connectionContext) {

    std::string fname;

    protocol::TMessageType mtype;

    int32_t seqid;

    in->readMessageBegin(fname, mtype, seqid);


    if (mtype != protocol::T_CALL && mtype != protocol::T_ONEWAY) {

      GlobalOutput.printf("received invalid message type %d from client",

                          mtype);

      return false;

    }


    return dispatchCall(in.get(), out.get(), fname, seqid, connectionContext);

  }


WireShark抓包能夠看到發送的服務接口,在服務器端能夠看到接收到的RPC接口,可是發送出去的接口在限制詞thrift中沒法看到,只能經過限制端口來看到全部的報文信息,能夠經過報文的長度來知道是哪一個接口


https://www.cnblogs.com/xiaosuiba/p/4122459.html

https://blog.csdn.net/qq_27989757/article/details/50761051

文章描述了Thrift雙向通訊的基本機制

https://blog.csdn.net/lwwl12/article/details/77449550


oneway修飾符意味着客戶端發送一個請求,可是沒有監放任何的返回信息,因此oneway方法必須是void類型。沒有oneway修飾的函數,在調用函數的時候,會一直阻塞在函數的調用中,等待另外一方的返回結果,這種是同步狀況,會致使客戶端阻塞,切記!!

相關文章
相關標籤/搜索