資訊專欄INFORMATION COLUMN
摘要：負(fù)載均衡，故障轉(zhuǎn)移與同步調(diào)用的連接池思路基本相同。而由于異步調(diào)用，端會(huì)很快返回，所以端多個(gè)服務(wù)同時(shí)路由到同一個(gè)的情況是很少的，因此一個(gè)服務(wù)的一個(gè)只需要建立少量的連接。
要實(shí)時(shí)就用同步，要吞吐率就用異步。
同步調(diào)用流程略
實(shí)現(xiàn)負(fù)載均衡：連接池中建立了與一個(gè)RPC-server集群的連接，連接池在返回連接的時(shí)候，需要具備負(fù)載均衡策略。
實(shí)現(xiàn)故障轉(zhuǎn)移：連接池中建立了與一個(gè)RPC-server集群的連接，當(dāng)連接池發(fā)現(xiàn)某一個(gè)機(jī)器的連接異常后，需要將這個(gè)機(jī)器的連接排除掉，返回正常的連接，在機(jī)器恢復(fù)后，再將連接加回來。
實(shí)現(xiàn)發(fā)送超時(shí)：因?yàn)槭峭阶枞{(diào)用，拿到一個(gè)連接后，使用底層socket帶超時(shí)的send/recv即可實(shí)現(xiàn)帶超時(shí)的發(fā)送和接收。
流程略
為什么要待發(fā)送隊(duì)列、待接收隊(duì)列？
因?yàn)橐獙⒐ぷ骶€程和io收發(fā)線程兩者的同步關(guān)系解除，從而引入工作線程池和io收發(fā)線程池。
為什么要上下文
因?yàn)檎?qǐng)求包的發(fā)送，響應(yīng)包的callback回調(diào)不在同一個(gè)工作線程中完成，需要一個(gè)context來記錄一個(gè)請(qǐng)求的上下文，把請(qǐng)求-響應(yīng)-回調(diào)等一些信息匹配起來。通過rpc框架的內(nèi)部請(qǐng)求id作為key，來保存調(diào)用開始時(shí)間time，超時(shí)時(shí)間timeout，回調(diào)函數(shù)callback，超時(shí)回調(diào)timeout_callback等信息。
注意：請(qǐng)求id由client端服務(wù)調(diào)用時(shí)生成，會(huì)序列化成字節(jié)流發(fā)送給server端，server端會(huì)返回該請(qǐng)求id。
負(fù)載均衡，故障轉(zhuǎn)移
與同步調(diào)用的連接池思路基本相同。
注意：由于同步調(diào)用的連接池使用阻塞方式收發(fā)，需要與一個(gè)服務(wù)的一個(gè)server ip建立多條連接來保證client端多個(gè)服務(wù)同時(shí)路由到同一個(gè)server時(shí)不會(huì)阻塞。而由于異步調(diào)用，server端會(huì)很快返回response，所以client端多個(gè)服務(wù)同時(shí)路由到同一個(gè)server的情況是很少的，因此一個(gè)服務(wù)的一個(gè)server ip只需要建立少量的連接。
超時(shí)發(fā)送與接收
超時(shí)管理器啟動(dòng)timer對(duì)上下文管理器中的所有context進(jìn)行掃描，看上下文中請(qǐng)求發(fā)送時(shí)間是否過長，如果過長，就不再等待result包，將該context從上下文管理器中移除，直接執(zhí)行timeout_callback。
注意：如果timeout_callback執(zhí)行后，client端接收到了server端的result包，此時(shí)因?yàn)橥ㄟ^req-id在上下文管理器里找不到對(duì)應(yīng)的context（說明已經(jīng)超時(shí)處理過了），就直接將請(qǐng)求丟棄。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/68517.html
摘要：對(duì)于與而言，則可以看做是消息傳遞技術(shù)的一種衍生或封裝。在生產(chǎn)者通知消費(fèi)者時(shí)，傳遞的往往是消息或事件，而非生產(chǎn)者自身。通過消息路由，我們可以配置路由規(guī)則指定消息傳遞的路徑，以及指定具體的消費(fèi)者消費(fèi)對(duì)應(yīng)的生產(chǎn)者。采用和來進(jìn)行遠(yuǎn)程對(duì)象的通訊。 消息模式 歸根結(jié)底，企業(yè)應(yīng)用系統(tǒng)就是對(duì)數(shù)據(jù)的處理，而對(duì)于一個(gè)擁有多個(gè)子系統(tǒng)的企業(yè)應(yīng)用系統(tǒng)而言，它的基礎(chǔ)支撐無疑就是對(duì)消息的處理。與對(duì)象不同，消息本質(zhì)上...
摘要：微軟的雖然引入了事件機(jī)制，可以在隊(duì)列收到消息時(shí)觸發(fā)事件，通知訂閱者。由微軟作為主要貢獻(xiàn)者的，則對(duì)以及做了進(jìn)一層包裝，并能夠很好地實(shí)現(xiàn)這一模式。 在分布式服務(wù)框架中，一個(gè)最基礎(chǔ)的問題就是遠(yuǎn)程服務(wù)是怎么通訊的，在Java領(lǐng)域中有很多可實(shí)現(xiàn)遠(yuǎn)程通訊的技術(shù)，例如：RMI、MINA、ESB、Burlap、Hessian、SOAP、EJB和JMS等，這些名詞之間到底是些什么關(guān)系呢，它們背后到底是基...
摘要：微軟的雖然引入了事件機(jī)制，可以在隊(duì)列收到消息時(shí)觸發(fā)事件，通知訂閱者。由微軟作為主要貢獻(xiàn)者的，則對(duì)以及做了進(jìn)一層包裝，并能夠很好地實(shí)現(xiàn)這一模式。 在分布式服務(wù)框架中，一個(gè)最基礎(chǔ)的問題就是遠(yuǎn)程服務(wù)是怎么通訊的，在Java領(lǐng)域中有很多可實(shí)現(xiàn)遠(yuǎn)程通訊的技術(shù)，例如：RMI、MINA、ESB、Burlap、Hessian、SOAP、EJB和JMS等，這些名詞之間到底是些什么關(guān)系呢，它們背后到底是基...
閱讀 2112·2023-04-26 02:41
閱讀 2155·2021-09-24 09:47
閱讀 1562·2019-08-30 15:53
閱讀 1216·2019-08-30 13:01
閱讀 1896·2019-08-29 11:27
閱讀 2872·2019-08-28 17:55
閱讀 1782·2019-08-26 14:00
閱讀 3396·2019-08-26 10:18
