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

核心提示： 定义和配置关键概念什么是“write-behind”缓存在write-behind缓存中，数据的读取和更新通过缓存进行，极端事务处理模式：Write-behind缓存(2)，与write-through缓存不同，更新的数据并不会立即传到数据库，可以预见，采用write-b

定义和配置关键概念

什么是“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的系统，作出变更的唯一路径就只能是缓存。