coherence mysql_Coherence Step by Step 第三篇 缓存（四） 缓存数据源（翻译）

本章介绍了用Coherence作为临时的system-of-record来缓存数据源。本篇包含了例子和实现的注意事项。

1 缓存数据源概述

Coherence 支持透明的读/写任何数据源的缓存，包含数据库，web服务，套装软件和文件系统；然而，数据库是最常用的用例。简要的说，数据库是用来描述任何back-end数据源。有效果的缓存必须都支持密集的只读和读写操作，并且对于读写操作，缓存和数据库必须保持完全同步。为了完成数据源的缓存，Coherence支持 Read-Through, Write-Through, Refresh-Ahead and Write-Behind 缓存。

NOTE：Read-through/write-through缓存(和变体) 是只用在Partitioned(Distributed) cache拓扑(和货站的，Near Cache)，Local caches支持这功能的自己。Replicated和Optimistic 缓存不能被使用。

1.1 Pluggable Cache Store

CacheStore 是一个指定应用的适配器，用来连接一个缓存到基本数据源。CacheStore的实现通过使用一个数据访问机制来获取数据源(例如,Hibernate,Toplink Essentials, JPA, application-specific JDBC calls, another application, mainframe, another cache, 等)。CacheStore知道如何创建一个java对象来实现从数据源检索数据，映射和写一个对象到数据源，从数据源擦出一个对象。

数据源连接策略和数据源-应用-对象的映射信息是针对数据源架构，应用程序类布局，和操作环境。因此，映射信息必须由应用开发者来提供，以CacheStore实现的形式。

1.2 Read-Through Caching

当应用程序想缓存请求一条entry，例如key x,并且x不在缓存中，Coherence 会自动委托给CacheStore，请求它来从基础数据源中加载x。如果x在数据源中存在，CacheStore加载它，返回给Coherence，然后Coherence将它放在缓存中为将来使用，最后返回x给请求它的应用程序的代码。这个叫做Read-Through缓存。Refresh-Ahead Cache功能可以更加提升读取性能(通过减少感知延迟)。

1.3 Write-Through Caching

Coherence用两种不同的方式来处理更新到数据源，第一个是Write-Through。这个例子，当应用程序更新一条在缓存中的数据(是调用put(...)来改变缓存entry)，直到Coherence运行了CacheStore并成功存储数据到基础数据源才算操作完成。这个完全不会提升写的性能，因为你仍然使用有延时的方式写数据源。提升写的性能建议使用Write-Behind Cache 功能。

1.4 Write-Behind Caching

在Write-Behind的场景中，修改缓存条目是在配置的延迟值后异步的写入数据源，可能是10秒，20分钟，一天，一个星期或者是更久。注意，这个只用于对缓存的插入和更新。缓存条目从数据源移除是同步的。Write-Behind缓存，Coherence维护者一个需要在数据源执行更新的write-behind数据队列。当应用程序更新缓存中的X，X被添加在write-behind队列(如果不存在；否则就替换它)，然后在指定的write-behind延迟以后，COherence调用了CacheStore，用最新的X的状态来更新基础数据源，注意write-behind延迟是相对于第一个一系列的修改--换句话说，在数据源的数据从未落后于缓存超过wirte-behind延迟的这个时间。

结果是"一次读取和在配置好的时间间隔写"的场景，有四个主要的益处，对于这个架构体系的类型：

应用程序提升了性能，因为用户不用等待数据写入基础数据源。(数据延迟写入，并且通过其他线程)

应用程序经历了彻底降低数据库的负载：由于减少了大量的读和写操作，数据库的负载也是同样。和其他缓存方法一样，通过缓存，读取变少了。写，这个通常是最昂贵的操作，也减少了，因为针对同一个对象的多个变化使用write-behind是合并并且只写一次到数据源  ("write-coalescing")。此外，对多个缓存条目的写可能被合并成一个数据库事务 ("write-combining")。如果用CacheStore.storeAll()方法。

应用程序多少有点隔绝数据库失效的情况：Write-Behind特性能够被这样配置，失败的写入导致对象重新被请求写。如果应用程序正在使用的数据时在Coherence的缓存里，那么应用程序能够继续操作，而不用数据库是up状态的。使用Coherence Partitioned Cache，这很容易做到，只要将所有的缓存分区到所有的participating cluster 节点(开启了local-storage)，允许庞大的缓存。

线性可扩展：要应用程序处理更多的并发用户，你只需要增加cluster的节点即可；影响数据库的负载可以用增加write-behind间隔来调节。

1.4.1 Write-Behind Requirements

要启用write-behind缓存只是一个简单的设置配置的调整，确保write-behind如期望的那样工作要根复杂。特别的，应用程序的设计必须解决几个预先设计问题。

Write-Behind缓存的最直接的含义是发生在缓存事务之外的数据库更新；就是缓存的事务通常在数据库事务开始之前完成。这意味着数据库事务永远不是失败；如果不能保存，那么必须保证可以回滚。

write-behind可能重新请求数据库更新，参照完整性约束必须允许无序的更新。概念上的，这类似于使用ISAM-style storage的数据库(基于主键的访问，保存没有更新冲突)。如果其他的应用程序共享数据库，这将引入新的挑战--没有其他方式保证write-behind事务和外部的更新不发生冲突。这意味着write-behind冲突必须通过人家的操作来启发式的处理或者手动调整来增强。

根据鹰眼，映射每个缓存条目更新到逻辑数据库的事务的比较理想的，这能保证简单的数据库事务。

因为write-behind 有效的使得缓存system-of-record(直到write-behind 队列被写进磁盘)，业务规则必须允许cluster-durable(而不是disk-durable)，数据存储和事务。

1.5 Refresh-Ahead Caching

在Refresh-Ahead 的场景，Coherence允许开发者配置缓存，能够在它失效之前自动和异步的从cache loader重载最近访问过的缓存条目。结果是一个平凡被访问的条目进入缓存后，应用程序没有感觉到对于一个千载的减慢cache store的读取的影响，当这个条目由于过期而重新加载时。异步的属性只会在足够接近它的国企时间时候被访问时触发--如果对象在它的过期时间之后，Coherence会从cache store执行同步的读取来刷新他的值。

refresh-ahead 时间表示的是条目的过期时间的百分比例如，假设cache中设置的条目的过期时间是60秒，refresh-ahead因素设置为0.5.如果cache对象在60秒后被访问，Coherence从cache store执行同步读取来刷新值。然后，如果对于一个条目的请求执行是超过30小于60秒，cache中现在的值会被返回，并且coherence 调度一个异步的从cache store中重新加载。