前面我们已经讨论了CQRS-Reader-Actor的基本工作原理,现在是时候在之前那个POS例子里进行实际的应用示范了. 假如我们有个业务系统也是在cassandra上的,那么reader就需要把从日志读出来的事件恢复成cassandra表里的数据行row.首先,我们需要在cassandra上创建相关的keyspace和table.下面是在scala中使用cassandra-java-driver的例子: import com.datastax.driver.core._ import akk…

我们在这篇通过一个具体CQRS-Reader-Actor的例子来示范akka-persistence的query端编程和应用.在前面的博客里我们设计了一个CQRS模式POS机程序的操作动作录入过程,并示范了如何实现CQRS的写端编程.现在我们可以根据这个例子来示范如何通过CQRS的读端reader-actor读取由writer-actor所写入的操作事件并将二进制格式的事件恢复成数据库表的行数据. 首先看看reader是如何从cassandra数据库里按顺序读出写入事件的:cassandra-p…

在开始讨论Akka中对Actor的生命周期管理前,我们先探讨一下所谓的Actor编程模式.对比起我们习惯的行令式(imperative)编程模式,Actor编程模式更接近现实中的应用场景和功能测试模式.这是因为Actor是靠消息来驱动的,每种消息代表一项功能的运算指令.由于消息驱动式的程序是松散耦合的,每项功能都是在独立的线程中运算,互不干扰依赖,所以我们可以很自然的分开来实现各项功能以及独立测试每项功能.虽然Akka同时提供了Java和Scala两种API,但可能由于Akka本身是用Scala…

许多开发者在创建和维护多线程应用程序时经历过各种各样的问题,他们希望能在一个更高层次的抽象上进行工作,以避免直接和线程与锁打交道.为了帮助这些开发者,Arun Manivannan编写了一系列的博客帖子,在目前总共六篇帖子中,他通过大量的图片及一些简单的Akka示例,解释了Actor模型的原理,并进一步探索了Akka工具所提供的各种特性. Arun首先从整体上对Actor进行了介绍,他在示例中将Actor比作了一群人: 你可以将Actor当作是一群人,他们互相之间不会面对面地交流,而只是通过邮件…

Akka是由各种角色和功能的Actor组成的,工作的主要原理是把一项大的计算任务分割成小环节,再按各环节的要求构建相应功能的Actor,然后把各环节的运算托付给相应的Actor去独立完成.Akka是个工具库(Tools-Library),不是一个软件架构(Software-Framework),我们不需要按照Akka的框架格式去编写程序,而是直接按需要构建Actor去异步运算一项完整的功能,这样让用户在不知不觉中自然的实现了多线程并发软件编程(concurrent programming).按这…

实验——async什么时候提高吞吐 async是一个语法糖,用来简化异步编程,主要是让异步编程在书写上接近于同步编程.总的来收,在await的时候,相当于附加上了一个.ContinueWith(). 至于为什么async能够提高吞吐,是因为通过async方法返回一个Task对象,IIS缩减了工作线程的处理时间长短(切换到了其他线程,且没有阻塞当前线程),从而提高了单位时间的处理量.这里还有其他的一些细节,详情见这篇博文: [http://www.cnblogs.com/rosanshao/p/3…

在上一篇讨论中我们谈到了监管:在Akka中就是一种直属父子监管树结构,父级Actor负责处理直属子级Actor产生的异常.当时我们把BackoffSupervisor作为父子监管方式的其中一种.实际上BackoffSupervisor与定义了supervisorStrategy的Actor有所不同.我们应该把BackoffSupervisor看作是一个一体化的Actor.当然,它的实现方式还是由一对父子Actor组成.监管策略(SupervisorStrategy)是在BackoffSuperv…

前言........ 这一篇文章主要是讲解Akka persistence的核心设计理念,也是CQRS(Command Query Responsibility Segregation)架构设计的典型应用,就让我们来看看为什么Akka persistence会采用CQRS架构设计. CQRS 很多时候我们在处理高并发的业务需求的时候,往往能把应用层的代码优化的很好,比如缓存,限流,均衡负载等,但是很难避免的一个问题就是数据的持久化,以致数据库的性能很可能就是系统性能的瓶颈,我前面的那篇文章也讲到…

CQRS The CQRS pattern and event sourcing are not mere simplistic solutions to the problems associated with large-scale, distributed systems. 从1000万用户并发修改用户资料的假设场景开始 每次修改操作耗时200ms,每秒5个操作 MySQL连接数在5K,分10个库 5 *5k *10=25万TPS 1000万/25万=40s 在秒杀场景中,由于对乐观锁/悲…

在常用的三层架构中,通常都是通过数据访问层来修改或者查询数据,一般修改和查询使用的是相同的实体.在一些业务逻辑简单的系统中可能没有什么问题,但是随着系统逻辑变得复杂,用户增多,这种设计就会出现一些性能问题.虽然在DB上可以做一些读写分离的设计,但在业务上如果在读写方面混合在一起的话,仍然会出现一些问题. 本文介绍了命令查询职责分离模式(Command Query Responsibility Segregation,CQRS),该模式从业务上分离修改 (Command,增,删,改,会对系统状态进…