Actor vs CSP 并发模型随笔

- 1 min

Akka/Erlang 的 Actor 模型与 Go 语言的协程 Goroutine 与通道 Channel 代表的 CSP模型(Communicating Sequential Processes)区别

Actor 模型描述了一组为了避免并发编程常见问题的公理

Channel 模型

Actor vs Channel

Actor 模型

Actor对没接触过这个概念的人可能不太好理解,Actor的概念其实和OO里的对象类似,是一种抽象。面对对象编程对现实的抽象是对象=属性+行为(method),但当使用方调用对象行为(method)的时候,其实占用的是调用方的CPU时间片,是否并发也是由调用方决定的。这个抽象其实和现实世界是有差异的。现实世界更像Actor的抽象,互相都是通过异步消息通信的。

Actor 特征

Actor 遵循规则

Actor 的目标

Actor 的实现

Goroutine 调度器

Goroutine很大程度上降低了并发的开发成本,是不是我们所有需要并发的地方直接 go func 就搞定了呢? Go通过Goroutine的调度解决了CPU利用率的问题。但遇到其他的瓶颈资源如何处理?比如带锁的共享资源,比如数据库连接等。互联网在线应用场景下,如果每个请求都扔到一个Goroutine里,当资源出现瓶颈的时候,会导致大量的Goroutine阻塞,最后用户请求超时。这时候就需要用Goroutine池来进行控流,同时问题又来了:池子里设置多少个Goroutine合适?

所以这个问题还是没有从更本上解决。

Akka

定义 Actors 和 Messages

创建 Actors

异步通信

Running

事件溯源 Event Sourcing

「事件溯源」保证了数据状态的变换都以一系列的事件的形式存储在数据库中。所以,我们不仅可以获取每个变换的事件,而且可以通过过去的事件来组合出过去任意时刻的数据状态!

注意,有一点很重要,我们不能更改已经保存的事件以及它们的序列 —— 也就是说,事件存储是只能添加而不能删除的,并且需要不可变。是不是感觉和数据库事务日志的原理差不多呢?

在微服务架构中,事件溯源模式可以带来以下的好处:

理解 CQRS

CQRS 目前在 DDD 领域使用广泛,甚至可以称为一种架构风格,可以取得与 MapReduce、Rest 同等的地位。

CQRS: Command Query Responsibility Seperation(命令查询职责分离),命令与查询的分离,可以更好的控制请求者的操作。查询操作不会造成数据变更,属于一种幂等操作,可以提供缓存,提高查询性能。

从请求响应的角度看,查询操作需要同步请求,实时返回结果;命令操作则不然,我们并不期待命令操作必须实时返回结果,可以采用 free-and-forget 方式,这种方式是运用异步操作的前提。

CQRS 模式风格就是基于事件的异步状态机模型,核心概念是 Command 和 Event。

comments powered by Disqus
rss github weibo twitter instagram pinterest facebook linkedin stackoverflow reddit quora mail