CSP模型：Communicating Sequential Processes(formal language for describing patterns of interaction in concurrent systems)
processes share a “channel”
at this time they are limited to the current runtime and cannot be distributed, even between two runtimes on the same physical box
CSP does not support fault tolerance in a meaningful way, so you as the developer have to figure out how to handle failure that can occur on both sides of channels, and such logic ends up getting strewn about all over the application
CSP强调通信，channel可以被多个生产者和消费者共享，但是消息是否被消费了？unbuffered?
actor: involve entities that have their own mailbox. They are asynchronous by nature, and have location transparency that spans runtimes and machines
也有共享的机制，通过eventbus部分？
Actors have another very nice feature - fault tolerance. By organizing actors into a supervision hierarchy per the OTP specification devised inErlang, you can build a domain of failure into your application.
Actors are also a concurrency paradigm, where the actor can have mutable state inside of it and a guarantee of no multithreaded access to the state, unless the developer building an actor-based system accidentally introduces it, for example by registering the Actor as a listener for a callback, or going asynchronous inside the actor via Futures.(actor的状态不变性)
The only similarity (aside the nitpicking) is they both have to do with concurrency and message passing. But that is where the similarity ends.
Actors help things to be “worry free distributed”
Where a “worry free” piece is usually associated with terms such as: fault tolerance, resiliency, availability, etc..
Goroutines help to reason about concurrency sequentially
参考quora1
Go has a select statement for choosing between alternatives (the CSP choice) which may include channels, timers or simply skipping on to the next thing. This allows what one might call “waiting faster” by picking up from whichever channel is available first. But remember that whilst a goroutine is waiting on the channels (CSP calls them guards) in a select, it consumes no CPU and very little memory.
Akka implements a fixed kind network (of variable topology) in CSP terms. One feature of this kind of network is that there is no explicit flow control because no write rendezvous is ever needed on an infinite buffer. The model is fully asynchronous.
downsides to the actor model
- There are cases where flow control is needed. Although these can be implemented in Akka using handshake dialogues, the code gets messy and it’s not efficient any more
- There is no ability of an actor to refuse to communicate. When a message arrives, it has to be processed or, perhaps, put into a buffer to be dealt with later. 消息ignore机制
- Akka places full reliance on the infinite input buffers never running out of memory - but this is not guaranteed.
downside to the csp:
- Any network of goroutines that has some mutual dependency may deadlock. The developer must be aware of this and code so that deadlock is eliminated; this involves identifying mutual dependencies and altering them in some way (there are several well-known techniques, the easiest of these being to use a pure client-server pattern, which is known to be deadlock-free).
The main difference is that a message exchange is synchronous in CSP (i.e. a “touch point” of the execution of two processes where they hand over the message) whereas it is completely decoupled in the Actor model, with message delivery being unconfirmed to the sender and taking an arbitrary amount of time