我做了大量的自学习编码,获得了一些并行编程模型的经验:参与者,软件事务内存,数据流。
当我试图将这些体系结构应用到实际生活中时--在高负载的web应用程序中--任何模型都不支持数据的持久性和持久性。实际任务需要在结束时保存数据。这意味着,我仍然必须使用DB和捕获DB同步,可能的可扩展性瓶颈等。
有谁知道使用Akka Actors或软件事务内存并最终实现持久性的架构(src或文本、图表或蓝图)的好例子吗?
在实际应用程序中,任何用于事务内存、Actors、Dataflow、Tuple空间的好示例/想法都是受欢迎的。
发布于 2012-05-26 00:58:56
参与者/ STM模型和数据库持久化在某种程度上是正交的--您可以很容易地拥有一个而不是另一个,我认为这两个模型都有混淆的危险。
在事务设置中,实现持久性(在ACID中的D)是极其复杂的,尤其是在分布式环境中,通过消息传递来协调参与者/进程。你会遇到像拜占庭将军问题这样棘手的问题。
因此,我认为总是会有某种程度的裁剪解决方案来满足您的专业持久性需求。没有“一刀切”的解决方案。
值得一看(Clojure透视图):
发布于 2012-05-26 02:28:22
参与者模型非常适用于命令/查询责任隔离(CQRS),因为执行数据操作的参与者的消息可以作为“命令”等价物使用。
那么,这与你的持久性问题有什么关系呢?好的,您需要处理内存,并将所有命令写入日志,这是一种更便宜的操作,因为它只是附加操作,并不时地转储快照,以便在必要时减少重新加载数据库所需的时间(此外,还可以恢复日志所使用的空间)。
这是一种很普通的技术。请看VoltDB和Redis,以获得更多的灵感。
发布于 2012-05-27 13:27:20
里奇有一个全新的创意,叫做数据经济学。这是一种用于持久性、解耦存储、事务管理和查询的新方法。它基于不可变的记录,并使用一种名为Datalog的查询语言(与Prolog共享特性)。关键的目标是允许简单的分发和云部署。它依赖于作为服务的存储(所以不是一个具体的实现,而是通过跨线API松散耦合)。
在Clojure中,我们有STM,它给了我们ACI,D缺失。数据体增加了D.
https://softwareengineering.stackexchange.com/questions/150315
复制相似问题