spark整合dubbo，怎樣吧請求分發到不同的executor執行？

02-07

我最近在做把dubbo整合到spark裡面，想用spark的分散式處理dubbo的高並發。裡面不涉及到spark的其他操作，只是用spark的分散式，因為沒有task執行，怎樣吧請求分發到不同的executor執行？

Spark的分散式執行架構與其RDD所表達的lineage是緊密相關的，RDD的執行就是切分到stage和task的去分散式執行的。

很難理解題主想要達到的設計目標是怎樣的—在Dubbo接收了請求後，題主希望Spark解決的問題到底是什麼？

謝謝邀請

用kafka做兩個的對接吧

讓spark從kafka中拿數據

然後自己就會分發到不同的executor執行

大數據自學知乎專欄：從頭學習大數據

瀉藥

我最近在搞flink，和vert.x

spark我已經放棄了，因為覺得它的streaming api有待改善

dubbo根本就沒考慮過，因為vert.x最近有群友測試，發現效率比nginx還要高一點

等他的網關做好之後，就會考慮集成進來

我覺得樓主的問題和spark沒關係啊。。。感覺你問的是想要一個調度系統或者反向代理一類的

謝邀！個人不建議題注使用spark整合dubbo，原因是數據分析的穩定性不佳，建議參考下面的文章來搭建平台

著作權歸作者所有。

商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。

作者：Linux先生

鏈接：Dubbo與Zookeeper、SpringMVC整合和使用（負載均衡、容錯）

來源：Linux下載站

Dubbo與Zookeeper、SpringMVC整合和使用（負載均衡、容錯）

互聯網的發展，網站應用的規模不斷擴大，常規的垂直應用架構已無法應對，分散式服務架構以及流動計算架構勢在必行，Dubbo是一個分散式服務框架，在這種情況下誕生的。現在核心業務抽取出來，作為獨立的服務，使前端應用能更快速和穩定的響應。
Zookeeper是針對大型分散式系統的高可靠的協調系統，它主要是用來解決分散式應用中經常遇到的一些數據管理問題，如：統一命名服務、狀態同步服務、集群管理、分散式應用配置項的管理等。
由這個定義我們知道zookeeper是個協調系統，作用的對象是分散式系統。為什麼分散式系統需要一個協調系統了？理由如下：
開發分散式系統是件很困難的事情，其中的困難主要體現在分散式系統的「部分失敗」。「部分失敗」是指信息在網路的兩個節點之間傳送時候，如果網路出了故障，發送者無法知道接收者是否收到了這個信息，而且這種故障的原因很複雜，接收者可能在出現網路錯誤之前已經收到了信息，也可能沒有收到，又或接收者的進程死掉了。發送者能夠獲得真實情況的唯一辦法就是重新連接到接收者，詢問接收者錯誤的原因，這就是分散式系統開發里的「部分失敗」問題。

Zookeeper就是解決分散式系統「部分失敗」的框架。Zookeeper不是讓分散式系統避免「部分失敗」問題，而是讓分散式系統當碰到部分失敗時候，可以正確的處理此類的問題，讓分散式系統能正常的運行。
ZooKeeper典型的應用場景
Zookeeper 從設計模式角度來看，是一個基於觀察者模式設計的分散式服務管理框架，它負責存儲和管理大家都關心的數據，然後接受觀察者的註冊，一旦這些數據的狀態發生變化，Zookeeper 就將負責通知已經在 Zookeeper 上註冊的那些觀察者做出相應的反應，從而實現集群中類似 Master/Slave 管理模式，關於 Zookeeper 的詳細架構等內部細節可以閱讀 Zookeeper 的源碼
下面詳細介紹這些典型的應用場景，也就是 Zookeeper 到底能幫我們解決那些問題？下面將給出答案。
統一命名服務（Name Service）
分散式應用中，通常需要有一套完整的命名規則，既能夠產生唯一的名稱又便於人識別和記住，通常情況下用樹形的名稱結構是一個理想的選擇，樹形的名稱結構是一個有層次的目錄結構，既對人友好又不會重複。說到這裡你可能想到了 JNDI，沒錯 Zookeeper 的 Name Service 與 JNDI 能夠完成的功能是差不多的，它們都是將有層次的目錄結構關聯到一定資源上，但是 Zookeeper 的 Name Service 更加是廣泛意義上的關聯，也許你並不需要將名稱關聯到特定資源上，你可能只需要一個不會重複名稱，就像資料庫中產生一個唯一的數字主鍵一樣。
Name Service已經是Zookeeper 內置的功能，你只要調用 Zookeeper 的 API 就能實現。如調用 create 介面就可以很容易創建一個目錄節點。
配置管理（Configuration Management）
配置的管理在分散式應用環境中很常見，例如同一個應用系統需要多台 PC Server 運行，但是它們運行的應用系統的某些配置項是相同的，如果要修改這些相同的配置項，那麼就必須同時修改每台運行這個應用系統的 PC Server，這樣非常麻煩而且容易出錯。
像這樣的配置信息完全可以交給 Zookeeper 來管理，將配置信息保存在 Zookeeper 的某個目錄節點中，然後將所有需要修改的應用機器監控配置信息的狀態，一旦配置信息發生變化，每台應用機器就會收到 Zookeeper 的通知，然後從 Zookeeper 獲取新的配置信息應用到系統中。
配置管理結構圖
集群管理（Group Membership）
Zookeeper 能夠很容易的實現集群管理的功能，如有多台 Server 組成一個服務集群，那麼必須要一個「總管」知道當前集群中每台機器的服務狀態，一旦有機器不能提供服務，集群中其它集群必須知道，從而做出調整重新分配服務策略。同樣當增加集群的服務能力時，就會增加一台或多台 Server，同樣也必須讓「總管」知道。
Zookeeper 不僅能夠幫你維護當前的集群中機器的服務狀態，而且能夠幫你選出一個「總管」，讓這個總管來管理集群，這就是 Zookeeper 的另一個功能 Leader Election。
它們的實現方式都是在 Zookeeper 上創建一個 EPHEMERAL 類型的目錄節點，然後每個 Server 在它們創建目錄節點的父目錄節點上調用 getChildren(String path, boolean watch) 方法並設置 watch 為 true，由於是 EPHEMERAL 目錄節點，當創建它的 Server 死去，這個目錄節點也隨之被刪除，所以 Children 將會變化，這時 getChildren上的 Watch 將會被調用，所以其它 Server 就知道已經有某台 Server 死去了。新增 Server 也是同樣的原理。
Zookeeper 如何實現 Leader Election，也就是選出一個 Master Server。和前面的一樣每台 Server 創建一個 EPHEMERAL 目錄節點，不同的是它還是一個 SEQUENTIAL 目錄節點，所以它是個 EPHEMERAL_SEQUENTIAL 目錄節點。之所以它是 EPHEMERAL_SEQUENTIAL 目錄節點，是因為我們可以給每台 Server 編號，我們可以選擇當前是最小編號的 Server 為 Master，假如這個最小編號的 Server 死去，由於是 EPHEMERAL 節點，死去的 Server 對應的節點也被刪除，所以當前的節點列表中又出現一個最小編號的節點，我們就選擇這個節點為當前 Master。這樣就實現了動態選擇 Master，避免了傳統意義上單 Master 容易出現單點故障的問題。