"Principles of Reactive Programming" 之<Actors are Distributed> (1)

devos發表於2014-12-18

week7中的前兩節課的標題是”Actors are Distributed",講了很多Akka Cluster的內容,同時也很難理解。

Roland Kuhn並沒有講太多Akka Cluster自身如何工作的細節,而是更關注於如何利用Akka Cluster來把Actor分佈到不同的節點上,或許這麼安排是因為Akka Cluster能講的東西太多,而Coursera的課時不夠。但是,從聽眾的角度來說,這節課只是初步明白了下Akka Cluster能幹啥,但是想要自己用起來,特別是想了解其工作的機制,還需要自己再去看很多東西。在我看了下Akka的文件裡關於Cluster的一章之後,發現不懂的地方更多了……好吧,不能再搞魔獸世界了!

鑑於不懂的地方太多,還是按照課程講的順序先過一遍,整理一下不懂的地方,以後分開研究。下面是課程的內容, 包括:課程PPT的內容,作者在講課過程中一些重要的觀點和我的一些理解。

Roland Kuhn在視訊開頭的時候,介紹了一下本週要講的內容:

In this last week of the reactive programming course, we will focus first on something which was implicitly there already. Namely, that actors as independent agents of computation are by default distributed. Normally you run them just on different CPU's in the same system. But, there is nothing stopping you from running them on different network hosts, and we will do this in practice. This means, if you picture for example, people who are living on different continents that it takes some effort for them to agree on a common truth or a common decision. The same thing is true for actors and we call this eventual consistency. After that, we will talk about scalability and responsiveness and how you achieve these in an actor-based system. Rounding up all the four tenets of reactive programming, which were event-driven Scalable, resilient, and responsive.

在這reactive programming課程的最後一週,我們將會重點看一下已經暗自存在著的內容。也就是說,actor作為相互獨立的計算單元,預設是分散式的。通常,你會在一個系統的不同CPU上執行他們,但是,沒有什麼能阻止你把它們執行在網路中的不同主機上,我們接下來將實際這麼做一次。這(actor是分散式的)意味著,舉個栗子,拿生活在不同的大陸上的人們來說,他們需要花費一些努力才能夠就某個事實或者某個決定達成一致。這種情況對actor也一樣,我們把它叫做“最終一致性”。在那(介紹完最終一致性)之後,我們將介紹scalability和responsiveness以及如何在基於actor的系統中實現他們。圍紹著reactive programming的四個原則: event-driven, scalable, resilent, responsive

這裡發現得再理解下這四個tenets,於是找了篇文章翻譯了一下

 

The Impact of Network Communication

Compared to in-process communication:

  • data sharing only by value
  • lower bandwith
  • higher latency
  • partial failure
  • data corruption

Multiple processes on the same machine are quantitatively less impacted, but qualitatively the issues are the same.

 比較網路通訊和程式內通訊,是用來了解actor在分散式的方面能帶領我們走多遠。

  • 在網路通訊時,資料以值的方式被傳遞。物件需要被序列化,通過網路傳輸,反序列化,經過這些步驟,被傳輸後的物件和原始的物件就不是完全相同了(畢竟現在在不同的JVM裡)。之前講過,一個有狀態的物件,它的行為跟它的歷史有關係。但是一個有狀態的物件在經過網路傳輸以後,經過一段時間,網路兩邊的這兩個物件的狀態就可能會不同了。因此,只有共享不可變物件,才是有意義的。(意思應該是通過網路傳輸一個可變狀態的物件,然後想在網路兩端共享這個物件,是沒有意義的)。
  • 網路頻寬比一個機器內部資料的頻寬要小很多。
  • 所有通訊的延遲要高很多。你可以在一納秒內呼叫一個方法,但是不能在一納秒傳遞一個網路資料包。並且在網路通訊時,物件需要被序列化和反序列化,這比在程式內部傳遞引用要帶來更高的時延。
  • 除了這些量上的區別,還有新的情況發生。就是,當進行網路通訊時,有partial failure的風險, 或者你的一些訊息只有一部分到達了,並且在收到回覆之前你不知道哪些到達了。
  • 另一類failure是data corruption。從個人的經驗業看,通過TCP傳送資料時,大約每TB會有一個損壞事件。

Multiple processes on the same machine are quantitatively less impacted, but qualitatively the issues are the same.

Distributed computing breaks assumptions made by the synchronous programming model.

在同一個機器上執行多個程式,讓他們通過,比如localhost interface通訊,可以緩解上邊的一些問題。但是本質上的問題仍然存在。

The overarching description of the problem is that distributed computing breaks the core assumptions made by a synchronous programming model.

對於這個問題總的描述是分散式計算打破了同步程式設計模型的核心假設。

Actors are Distributed

Actor communication is asynchronous, one-way and not guaranteed.

Actor encapsulation makes them look the same, regardless where they live.

Actors are "Location Transparent", hidden behind ActorRef.

迄今,我們已經講了很多關於actor的知識,你們也知道了actor的所有通訊都是非同步的和單向的,並且不會保證可靠傳遞。 因此,actor實際上建模的東西就是網路給我們的東西. They model precisely what the network gives us. 可以認為,actor採取了與“把本地模型擴充套件到網路”相反的方式。actor模型審視了網路模型,然後把它用在本地機器上。

Actor的另一個特徵是他們如此獨立地執行,以至於從外部來看,他們都一樣。他們都是,ActorRef. 不管actor實際在哪,給他們發訊息都是一樣的,我們稱之為位置透明。

當前的Akka的actor模型所提供的特性集裡的所有語法都是嚴格地設定為所有東西都是遠端的。所以不能在這個環境中建模的特性都被移除。結果就是,使用actor來編寫一個分散式的程式就跟寫一個本地的同樣的程式有基本相同的工作量。程式碼本身沒有什麼大的區別喝,我們接下來將看到這點。

 

相關文章