极端事务处理模式：Write-behind缓存

极端事务处理模式：Write-behind缓存2010-10-28 infoq 翻译：张逸介绍

应用程序通常使用数据缓存来提高性能，尤其针对那些大量应用只读事务的应用程序更是如此。当数据发生变化时，这些应用程序会直接更新数据库。问题在于随着负载的增加，响应时间将随着更新的增长而延长。数据库并不擅于执行大量处理少量记录的并发事务。相对而言，处理批量事务才是数据库的强项。

实际上，随着额外负载的增加，响应时间急剧攀升，数据库就会耗用CPU或者磁盘。传统方式下，内存中缓存（in-memory caches）的存储会被限制，以满足JVM的空余内存空间。一旦我们需要缓存更多数量的数据，缓存就会不停地释放数据，从而为其他数据留出存储空间。而且，所需的记录必须被不停地读取，从而使得缓存无效，并将数据库直接暴露给完整的读操作负载。

目前已有多个可用的产品，包括IBM？ WebSphere？ eXtreme Scale，Oracle Coherence和Gigaspaces，它们均支持将一簇JVM的空闲内存作为缓存，而不是单个的JVM。这就使得合并JVM越多，缓存支持的规模就越大。如果这些JVM都是额外的具有CPU、存储器和网络的服务器，那么读请求的服务就是可伸缩的。通过使用write-behind技术，这些产品还提供更新请求的可伸缩服务。write-behind缓存的可伸缩性使得它可以解决极端事务处理（extreme transaction processing, XTP）场景。Gartner将XTP定义为：“一种应用风格，目的在于支持对分布式事务处理应用程序的设计、开发、部署、管理和维护，其特点在于对性能、可伸缩性、可用性、安全、可管理与可靠性的特别要求。”

本文将使用IBM WebSphere eXtreme Scale演示如何利用write-behind模式优化应用程序的性能。write-behind功能能够根据用户配置的间隔时间，异步地对后端数据库进行批量更新。这一方式具备的明显优势就是能够减少数据库调用，从而减少事务负载，更快地访问网格（grid）中的对象。它比write-through 缓存具有更快的响应时间，后者对缓存的更新会导致对数据库的及时更新。使用write-behind，不再要求事务等待数据库的写操作完成。此外，它能够避免应用程序出现数据库错误，因为write-behind缓冲通过内存复制单元来保持变化，直到它将其传输给数据库。

定义和配置关键概念

什么是“write-behind”缓存

在write-behind缓存中，数据的读取和更新通过缓存进行，与write-through缓存不同，更新的数据并不会立即传到数据库。相反，在缓存中一旦进行更新操作，缓存就会跟踪脏记录列表，并定期将当前的脏记录集刷新到数据库中。作为额外的性能改善，缓存会合并这些脏记录。合并意味着如果相同的记录被更新，或者在缓冲区内被多次标记为脏数据，则只保证最后一次更新。对于那些值更新非常频繁，例如金融市场中的股票价格等场景，这种方式能够很大程度上改善性能。如果股票价格每秒钟变化100次，则意味着在30秒内会发生30 x 100次更新。合并将其减少至只有一次。

在WebSphere eXtreme Scale中，脏记录列表会被复制，以保证JVM退出时仍然存在，用户可以通过设置同步和异步复制的数字，指定复制级别。同步复制意味着JVM退出时，没有数据丢失，但由于主进程必须等待获得变更信息的复制品，因此速度会慢一些。异步复制更快，但如果JVM在复制之前就退出，就会导致最近事务发生的变化可能会丢失。脏记录列表将使用大型的批事务写入到数据源中。如果数据源不可用，则网格会继续处理请求，之后再重新尝试。网格能够随着规模的变化提供更短的响应时间，因为变化会单独地提交到网格，即使数据库被停止，事务仍然能够提交。

Write-behind缓存并不能放之四海而皆准。write-behind的本质注定用户看到的变化，即使被提交也不会立即反映到数据库中。这种时间延迟被称为“缓存写延迟（cache write latency）”或“数据库腐败（database staleness）”；发生在数据库变更与更新数据（或者使得数据无效）以反映其变更的缓存之间的延迟则被称为“缓存读延迟（cache read latency）”或“缓存腐败（cache staleness）”。如果系统的每部分在访问数据时都通过缓存（例如，通过公共接口），那么，由于缓存总是保持最新的正确记录，采用write- behind技术就是值得的。可以预见，采用write-behind的系统，作出变更的唯一路径就只能是缓存。

不管是稀疏的缓存还是完整的缓存，都可以用于write-behind特性。稀疏缓存仅存储数据的子集，可以被延迟填充。它通常使用关键字进行访问，因为缓存中并非所有的数据都能够使用，使用缓存进行查询可能无法执行。完整缓存包含了所有的数据，但在首次加载的时候耗时更长。第三种可行之策则是兼取二者所长。首先在短时间内预装载数据的子集，然后延迟加载其余数据。预装载的子集数据大约在总数的20%，但它能够满足80%的请求。

采用这一方式使用缓存的应用程序适用的场景为：适用简单CRUD（创建，读取，更新和删除）模式的分区数据模型。

配置write-behind功能

对于WebSphere eXtrem Scale而言，在objectgrid.xml配置中，通过将writeBehind属性添加到backingMap元素，就启用了write- behind功能，如下所示。参数的值使用语法“"[T（time）][;][C（count）]"，用以指定数据库更新发生的时间。当到达设置的时间，或者队列集中的变化次数达到设定的count值，更新就会被写入到持久存储中。

列表1：write-behind配置的示例

<objectGrid name="UserGrid">

<backingMap name="Map" pluginCollectionRef="User" lockStrategy="PESSIMISTIC" writeBehind="T180;C1000"  />