1.背景
缓存是介于应用程序和物理数据源之间，其作用是为了降低应用程序对物理数据源访问的频次，从而提高了应用的运行性能。缓存内的数据是对物理数据源中的数据的复制，应用程序在运行时从缓存读写数据，在特定的时刻会同步缓存和物理数据源的数据。我们可以这么理解缓存——用于加速数据交换，达到用时即取。
之前了解到的缓存机制，比如：Redis、Memcache、J2Cache等。先说一下个人对这些缓存机制的理解。
Redis和具体应用相结合，其读取数据流程如下：
应用读取数据时，Redis缓存中没有，就会去数据库查询。若交易高并发访问时，查询的数据在缓存中一直不存在，就会一直去查询数据库，这就会给DB造成很大的压力。
Memcache读取数据的过程和Redis有相似之处，即把数据库查询的结果保存到Memcache中，下次访问时直接从Memcache中读取，而不再进行数据库查询操作。流程如下图所示：
和Redis一样，Memcache中也存在缓存穿透的问题。接下来我们再说一下
红薯的J2Cache吧。J2Cache借助于Ehcache和Redis实现了两级缓存的机制，数据读取流程如下：
从其数据读取流程中可以看到，J2Cache也可能会有缓存穿透问题，而且J2Cache无法对各级缓存进行统计(HITS/MISSED等)。那缓存的访问次数和使用情况我们是无法知道的，对于开发和运维来说，这是比较痛苦的。
没有什么方案是万能的，只能针对自己的应用场景，寻找适合自己的解决方案。
我们在实际应用中使用的配置表较多，访问频率很高，但修改频率很低。简单使用类似于Redis、Memcache、J2Cache缓存机制，会增加系统结构复杂度，并可能产生缓存穿透问题。
那有没有一种更适合我们的缓存机制，能够比较有效的解决上述问题？
这就是接下来要为大家介绍的高并发金融交易系统的二级缓存机制，处理流程如下：
高并发金融交易系统的二级缓存机制是在数据库访问层中实现的，叫做DBI（DATABASEINTERFACE），包含基础层和应用层。基础层提供最基本的管理和抽象功能，应用层在基础层上面开发具体的表接口和表应用。
数据库访问的层次划分如下图所示：
本次给大家带来的是关于缓存部分的专题分享，后续会将完整的DBI设计思路与实践全面展开。
2.缓存体系设计的基本原则
2.1不增加系统外缓存节点
所有的缓存均在DBI中根据上层的应用需求进行配置。应用程序使用时，在进程内创建所需缓存对象，不需增加系统外缓存节点，部署简单。
2.2允许以消耗内存为代价来进行多副本缓存
应用程序使用时，每个进程都缓存自己使用到的数据库中的物理表数据。如果有多个进程，多个进程之间避免不了的会重复缓存某些物理表，这样就会消耗内存，但内存的消耗是有限的，在可控范围内的。所以，在我们的二级缓存机制中，允许以消耗内存为代价来进行多副本缓存。
2.3降低应用层对于缓存的感知