一个简单Table Cache的实现
文章目录
前言
在数据存储中，比较常见的一种存储形式是以表的形式进行数据的存储。表由一条条的数据记录所构成。当然，我们也会对表内的数据做各种维度的分析或者更新处理等等。而在这些过程中，我们免不了会对这些表做出大量的读写请求操作。当数据的面向用户变得更为繁多的时候，无疑对于实际表的访问压力也将不断地增长。因此有的时候我们要在客户端用户和存储DB表中间做一层中间处理来做缓冲。本文笔者将要谈的是一个简单的缓存处理，Table Cache，意为表缓存。下面笔者来简单聊聊这个Table Cache的概念以及如何实现一个简单的Table Cache来提高系统的性能。
Table Cache的作用
Table Cache的一个直接作用体现在以下两点：
- 第一点，减轻客户端请求对于后台系统服务的压力
- 第二点，缩短客户端请求响应的耗时
上述两点，一个是针对服务端角度的，另一个是针对客户端角度的。
Table Cache的核心要点：数据访问的一致性
Table Cache作为表缓存的角色，它最最重要的一点要求是要保证自身缓存数据和实际DB数据的一致性。这里的一致性包括有以下几个情况：
- Cache有A数据，DB表有A数据。
- Cache有A数据，DB表暂无A数据，但是过一段时间后，DB表也会同步A数据，此表现为最终一致性的效果。
- DB清除掉了A数据，Cache也将会清除A数据
- DB表A数据记录更新了，Cache表也将会更新A数据记录
用一句话来概括上述的4点，客户端从Cache中查询的数据结果和最终查询真实表的数据结果必须保持完全一致。
Table Cache的样例实现
下面我们来聊聊如何实现一个简单的Table Cache功能。
对于Table Cache的使用方式来说，不同的使用方式对应的还有不同的略微方面的差异， 比如以下两类：
- Full Table Cache，全表Cache。全表Cache意为Table Cache将会cache住表的所有数据。简单地理解，就是一张表的所有数据会被load到内存中或者其它缓存介质中。
- Partial Table Cache，局部表Cache。局部表Cache只会cache住部分的表数据，这个局部的数据的定义可以根据实际具体的场景需要来设定何为”局部数据“的规则，比如未持久化的DB数据，最近访问最频繁的数据等等。
Full Table Cache的实现
这里我们先来说说全表Cache的实现。因为Full Table Cache是针对单表内的所有数据做cache处理，它的做法比较地简单、直接，主要为如下步骤：
1)Cache初始化时，执行真实全表记录查询操作，将数据load到Cache内。
2)当发生表数据的写操作(update、insert或者delete操作)记录时，将操作同时应用到Table Cache和DB表中。不过这里的DB表的更新可以优化为异步后台处理。因为客户端请求面向的将会是Table Cache而不是后台DB。
3)实际数据的读请求指向Table Cache。
Partial Table Cache的实现
下面我们来看看局部Table Cache的实现。考虑到某些大表进行全表cache处理会消耗大量的系统资源，所以我们有些场景内是需要进行局部的数据缓存的。
这里笔者将阐述的局部表的“局部”数据指那些未被持久化到DB的数据。为什么要cache这类数据呢？这个其实很好理解，客户端在执行数据请求操作时，大部分时间是消耗在后头DB的处理时间中的。假设我们将数据提取保存在了Cache中，然后快速返回结果给客户端。直到缓存中的数据被真正写出到DB之后，再进行Cache的清除。这样不就做到了更高效的数据写请求的处理了嘛。此过程的细节过程如下：
1)客户端发起A数据写请求
2)系统将A数据插入到Table Cache中，并立即返回客户端成功执行的返回结果。
3)客户端后续涉及到A数据的查询请求，都从Table Cache中进行查询。
4)后台线程持久化Cache中的A记录到后台DB内，持久化成功后，将A记录从Cache中清除出去。
5)客户端对于数据A的请求将指向实际的后台DB表。
从上述的过程我们可以看到，这里的Table Cache扮演的更像是一个临时表存储的角色。
下面是一个Table Cache的样例流程图：
上图中Table Cache内部自带了清理线程池来做clean up操作。
以上就是本文所描述的关于Table Cache的内容了。
引用
[1].https://issues.apache.org/jira/browse/HDDS-1499 . OzoneManager Cache
