1、Spark組件之間使用RPC機制進行通信，RPC的客戶端在本地撰寫并呼叫業務介面，介面在本地通過RPC框架的動態代理機制生成一個對應的實作類，在這個實作類中完成soket通信、遠程呼叫等功能的邏輯包裝，而在RPC的服務端既撰寫業務介面也撰寫了具體的業務實作類，通過RPC框架以介面的方式暴露出來，供客戶端遠程呼叫，
Spark2.x之前使用的是Akka作為底層框架來實作Actor模型的，Spark2.x之后用Netty替換了Akka作為底層框架，來實作Actor模型（Akka底層用的也是Netty），
BIO：客戶端呼叫后一直等待服務端的執行回傳，客戶端才能繼續執行自生在呼叫點位后面的邏輯，造成客戶端邏輯的阻塞，
NIO：客戶端呼叫后，繼續執行呼叫點位后的本地邏輯，通過事件監聽等機制獲得服務端的回傳，客戶端無阻塞，但是客戶端需要付出額為的精力去實時監聽服務端的執行是否完畢，
AIO：客戶端呼叫后，繼續執行呼叫點位后的本地邏輯，服務端主動將結果發送到共享的地方，客戶端靈活取用，客戶端無阻塞也無額外開銷，（服務端通常使用call-back等機制實作對客戶端的通知、Feature來約定共享資料區）但是目前Linux不支持AIO，Windows支持，
2、Actor模型：每一個通信端點都擁有一對inbox-outbox，任何資訊的接收都通過inbox，同樣任何資訊的發送都必須通過outbox，多條資訊就在box中排序處理，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/29384.html
標籤：大數據
上一篇：Spark記憶體管理
下一篇：SparkShuffle機制