"Principles of Reactive Programming" 之<Actors are Distributed> （1）
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来编写一个分布式的程序就跟写一个本地的同样的程序有基本相同的工作量。代码本身没有什么大的区别喝，我们接下来将看到这点。
