memeory image内存映像

这是MF站点的一篇新文章：MemoryImage内存映像，主要说明我们以后要改变过去和数据库打交道方式，直接和内存中领域模型打交道。鉴于这个观点我以前反复强调这种改变，老外这篇文章可能更加有说服力。

当人们开始一个企业应用时，首先第一个问题是：我如何和数据库打交道呢？这段时间有了另外一个问题：我应该使用什么样的数据库呢？关系数据库或NoSQL一种？但是另外一个问题同时在考虑：我们一定要使用数据库吗？

企业应用的一个显著特点就是需要保存长期的数据，这样导致人们去访问数据库，持久所有数据是数据库主要的工作，如果使用内存映像memory image 将是另外一种持久的路由方式，这种方式并不包括数据库。

memory image主要因素是因为使用event sourcing, 这就意味着导致应用状态的每次变化都被记录到持久存储库中，将来更远来看，那就意味着你能够通过这些事件重放来重构应用系统的所有状态 。

借助于event sourcing，memory images 的主要好处是：它意味着再也不需要将应用系统的状态保存在一个时刻更新的持久化存储系统，而是你应该让应用状态保持在主内存中，当处理发生冲突崩溃，你可以从Event事件开始重新构建。

使用memory image能够让你获得高性能，因为每件东西都在内存中，没有IO，没有远程数据库调用，更重要的是可以帮助你克服掉数据库的ORM映射代码，更不要担心需要在in-memory状态和数据库 state之间进行同步。

当然另外一个需要保证的是：你需要能够确保保存这些事件然后处理他们(banq注：关于EventSourceing的胡思乱想谈及了)，你也需要写代码保存和加载这些快照snapshots，然后分辨出如何快速地恢复他们，以便能够足够快地保证正常业务服务不被打断。数据库也提供事务性的并发，这样你必须搞清楚并发相关知识。

还有，你必须让内存大小要超过你的数据，内存大小要不断扩展。(内存是便宜的)

[该贴被banq于2011-10-29 11:01修改过]

一个最重要的案例是LMAX. LMAX是一个高性能的交易系统，能够在单个JVM线程中处理600万 TPS， . memory image高性能特点已经是一个显然的事实，但是他们发现了一个简化的编程模型也许更重要，他们并不担心一个线程的并发，为了实现高可用性，他们运行着多个memory image拷贝，如果其中一个当机他们能够彼此切换，以保证整体应用不当机不中断。

很多年前作者也写了一个EventPoster架构. 这个系统提供一个基于In-memeory模型的读访问，用来供很多分析界面使用，多个UI界面意味着多个线程，但是只有一个写入者(the event processor) ，这样就简化了并行场景。

最老的例子是Smalltalk 的开发环境，大多数开发工具依赖文件系统中的文本文件，比如需要编译或解释时，Smalltalk将这些源码和编译方法保存在内存的一个Image中. 每次你执行的命令作为事件被保存在一个日志中，如果需要比如你做了蠢事，你能够从这个日志恢复到一个稳定的方式。

象其他新想法一样，这种内存映像的想法虽然已经被实践了多次，但是还没有成为主流，使用数据库Hold住持久数据一直是更普通的方式。

一个难点是使用一个可序列化数据结构来封装事件日志，但是它又不能适应不断变化的事件格式，创建一个特定的事件类来持久比较难，最好使用通用数据结构：maps and lists.

另外一个重点是要保持事件和模型的松耦合，也许需要一些自动映射框架来通过事件来恢复成模型状态，但是这又耦合了事件格式和模型，如果将来迁移模型，还要处理老的事件格式。

当然迁移事件老的格式到新的格式在有的情况下是值得的，但需要经历比较长演绎演进过程。

很长时间以来，最大争论是内存大小问题，但是现在最普通服务器都使用更大的内存，考虑到NoSQL运动，它重新让人们思考他们的持久化选择(banq注：其实NoSQL根本本质是In-memeory + 定时持久或事件持久)。