CN106649530B - 云详单查询管理系统及方法 - Google Patents

Abstract

本发明提供一种云详单查询管理系统及方法，系统包括：详单文件管理模块、接口服务模块、数据路由模块和数据存储模块；接口服务模块，分别与所述详单文件管理模块以及外部详单查询系统对接，用于将详单写入请求下发到所述数据路由模块；或者，将详单查询请求下发到所述数据路由模块；数据路由模块，用于预制定数据路由策略，接收来自于所述接口服务模块的详单操作指令；然后，根据所述数据路由策略，将详单操作指令传输给相对应的数据存储模块；数据存储模块，用于接收来自于所述数据路由模块的详单操作指令，并执行对应的操作。优点为：能够提供高效的详单信息查询服务，具有用户详单更新速度快以及查询速度快的优点，全面提高用户查询体验。

Description

云详单查询管理系统及方法

技术领域

本发明属于详单管理查询技术领域，具体涉及一种云详单查询管理系统及方法。

背景技术

随着3G、4G技术的普及，运营商数据业务的飞速发展，移动终端时刻通过通信网络产生流量详单，详单规模较传统语音短信详单呈现爆炸式增长，如何精确而实时地记录详单信息，解决海量详单数据环境下的数据插入、更新、查询等操作的性能问题，提高用户满意度，已成为电信企业越来越严峻的考验。

目前，各运营商广泛采用传统的基于小型机+商业关系型数据库集群+集中存储的技术架构来存储和管理详单信息，此方案在2G时代可很好地支持语音及短信业务的详单信息管理查询。然而，在数据业务爆发的时代，传统的详单存储架构具有系统性能低下，查询效率低，硬件成本高等问题，且系统不具有横向扩展能力，致使无法满足业务的快速发展需求，降低了用户的查询体验。

为解决上述问题，部分省级运营商采用了互联网hadoop大数据技术，但hadoop本身为大数据分析计算而生，并不适合单纯的详单信息管理和查询，在数据导入等方式上，需定期执行集群运算，存在详单信息更新不及时等问题，且基于此类解决方案的系统管理维护非常复杂，无异于将传统解决方案的硬件成本转移到了维护成本上，出现问题难以解决，系统存在风险，亦非针对详单业务的最佳解决方案。

可见，如何有效解决当前存在的用户详单延时、查询速度慢等问题，向用户提供高效的详单信息查询服务，具有重要意义。

发明内容

针对现有技术存在的缺陷，本发明提供一种云详单查询管理系统及方法，可有效解决上述问题。

本发明采用的技术方案如下：

本发明提供一种云详单查询管理系统，包括：详单文件管理模块、接口服务模块、数据路由模块和数据存储模块；

详单文件管理模块，用于接收外部系统上传的新的详单文件，读取到所述新的详单文件的详单文件内容；然后，向所述接口服务模块发送数据写入指令；其中，所述数据写入指令中携带有所述详单文件内容；

接口服务模块，分别与所述详单文件管理模块以及外部详单查询系统对接，用于接收所述详单文件管理模块下发的数据写入指令，解析到需要被写入的详单文件内容；然后，根据所述详单文件内容生成详单写入请求，将所述详单写入请求下发到所述数据路由模块；

或者，用于接收所述外部详单查询系统发送的详单查询指令，从所述详单查询指令中解析到详单查询参数，根据所述详单查询参数生成详单查询请求，并将所述详单查询请求下发到所述数据路由模块；

数据路由模块，用于预制定数据路由策略，接收来自于所述接口服务模块的详单操作指令；其中，所述详单操作指令包括详单写入请求或详单查询请求；然后，根据所述数据路由策略，对所述详单操作指令中的数据进行数据特征提取，并根据数据特征查找到对应的数据存储模块，最后将详单操作指令传输给相对应的数据存储模块；

数据存储模块，用于接收来自于所述数据路由模块的详单操作指令，并执行对应的操作；即：当接收到来自于所述数据路由模块的详单写入请求时，写入并存储详单数据；当接收到来自于所述数据路由模块的详单查询请求时，根据所述详单查询参数，查询到对应的详单数据，并将查询到的详单数据返回给所述外部详单查询系统。

优选的，所述外部系统为详单计费系统。

优选的，所述接口服务模块还用于：在接收到所述详单文件管理模块下发的数据写入指令，或者，在接收到所述外部详单查询系统发送的详单查询指令时，首先进行安全性验证，只有安全验证通过后，再进行后续数据解析操作。

优选的，所述安全性验证包括两种：

第一种，对来源地址和身份进行合法性验证；

第二种，针对特定来源设定接口调用的频度限制，然后，验证特定来源接口调用的频度是否超过设定值，如果超过，则为频繁异常的调用，进行屏蔽处理；如果未超过，则通过验证。

优选的，所述详单文件管理模块、所述接口服务模块、所述数据路由模块和所述数据存储模块均可作为独立的服务运行于不同的服务器节点，也可支持部署在同一台服务器上；

所述详单文件管理模块、所述接口服务模块、所述数据路由模块和所述数据存储模块均可运行于物理x86服务器环境，也可运行于虚拟化/云服务器环境；

所述详单文件管理模块、所述接口服务模块、所述数据路由模块和所述数据存储模块均支持多节点同时部署运行，支持系统冗余备份；

所述详单文件管理模块、所述接口服务模块、所述数据路由模块和所述数据存储模块在进行多节点部署时，在前端配置负载均衡设备，负载均衡设备根据各个节点的负载，分发详单操作指令。

优选的，所述数据存储模块的静态主体结构包括内存表、不变内存表、log文件以及CCTable文件；其中，所述内存表和所述不变内存表位于内存中；所述log文件以及所述CCTable文件位于磁盘上；

所述数据存储模块采用以下方法写入数据：

(1)当所述数据存储模块需要写入一条Key:Value记录的时候，所述数据存储模块首先将所述Key:Value记录写入到所述log文件；

(2)所述内存表中KV对是根据Key大小有序存储的，因此，在将Key:Value记录成功写入到所述log文件后，所述数据存储模块再将所述Key:Value记录写入到所述内存表中的对应位置，以保证所述内存表中存储数据的有序性；

(3)如此不断循环，实现所述内存表和所述log文件的一致性；当所述内存表写入的数据占用内存到达设定界限后，所述数据存储模块生成新的Log文件和新的内存表；原先的内存表转为不变内存表，所述不变内存表指：只能进行读操作，不能进行写入操作或者删除操作；后续当需要写入新的Key:Value记录时，将新的Key:Value记录分别被写入所述新的Log文件和新的内存表；

(4)数据存储模块将所述不变内存表中存储的数据导出到所述磁盘并进行压缩操作后，形成一个新的CCTable文件；其中，所述CCTable文件为层级结构，第一层为Level 0、第二层为Level 1、依此类推，其层级逐渐增高；所述CCTable文件所存储的记录是根据记录的Key由小到大排列的；

所述数据存储模块采用以下方法查询数据：

(1)所述数据存储模块首先查看内存中的内存表，判断所述内存表中是否包含key及其对应的value，如果包含，则返回value值即可；如果不包含，则执行步骤(2)；

(2)所述数据存储模块查看内存中的不变内存表，判断所述不变内存表中是否包含key及其对应的value，如果包含，则返回value值即可；如果不包含，则执行步骤(3)；

(3)所述数据存储模块查看磁盘中的多个CCTable文件，对于每个CCTable文件，由于其为层级结构，因此，首先查找属于level 0的文件，如果查找到所需的key及其对应的value，则返回value值即可；如果未查找到，则查找属于level1的文件，如此循环往复，直到在某层CCTable文件中查找到所需要的key及其对应的value为止。

优选的，所述数据存储模块查询数据时，当所述内存表和所述不变内存表中均不存在需要查询的key及其对应的value时，采用以下方法查询：

(a)所述数据存储模块预建立Table缓存和Block缓存；其中，所述Block缓存用于缓存上一次返回给用户的key及其对应的value；所述Table缓存用于缓存分别指向CCTable文件中不同block区域的文件指针以及Block缓存的位置信息；

(b)当所述数据存储模块接收到用户发出的读取请求时，所述读取请求中携带有目标key；

(c)所述数据存储模块首先查询所述Block缓存，判断所述Block缓存中是否存在所述目标key，如果存在，则查找到与所述目标key对应的目标value，并向所述用户返回所述目标value，结束流程；如果不存在，则执行步骤d；

(d)所述数据存储模块查询所述Table缓存中的文件指针，获得包含所述目标key的文件指针，然后，根据所述文件指针的指向，查找到所述CCTable文件中对应的一个block区域数据；

然后，所述数据存储模块根据所述Table缓存中的Block缓存的位置信息，定位到Block缓存，再将所述block区域数据传输到所述Block缓存；

(e)所述数据存储模块查询所述Block缓存，判断所述Block缓存中是否存在所述目标key，如果存在，则查找到与所述目标key对应的目标value，并向所述用户返回所述目标value，结束流程；如果不存在，则执行步骤f；

(f)所述数据存储模块从磁盘的CCTable文件中查找与所述目标key对应的目标value，然后，将所述目标key及对应的所述目标value插入到Block缓存；

(g)返回步骤c。

本发明还提供一种云详单查询管理方法，包括数据存储流程和数据查询流程；

所述数据存储流程包括以下步骤：

步骤1.1，用户产生通信行为后，计费系统产生详单文件，并通过网络调用的方式向详单文件管理模块发送数据写入的通知消息；

步骤1.2，详单文件管理模块在接收到数据写入的通知消息时，读取计费系统产生的详单文件的详单文件内容；然后，向接口服务模块发送数据写入指令；其中，所述数据写入指令中携带有所述详单文件内容；

步骤1.3，接口服务模块在接收到所述数据写入指令时，首先进行安全性验证，在验证通过后，解析需要被写入的详单文件内容，生成详单数据关键参数；然后，将详单数据关键参数以及详细的详单文件内容以详单写入请求的方式发送给数据路由模块；

步骤1.4，数据路由模块预制定数据路由策略，接收来自于所述接口服务模块的详单数据关键参数以及详细的详单文件内容；然后，数据路由模块基于数据路由策略对所述详单数据关键参数进行分析，匹配到最佳的数据存储模块，并将所述详单文件内容发送到所述数据存储模块；

步骤1.5，所述数据存储模块保存详细的所述详单文件内容；

所述数据查询流程包括以下步骤：

步骤2.1，接口服务模块接收用户通过门户系统发送的用户详单查询指令；其中，所述用户详单查询指令中携带有详单查询参数；

步骤2.2，接口服务模块首先进行安全性验证，在验证通过后，根据所述详单查询参数生成详单查询请求，并将所述详单查询请求下发到所述数据路由模块；

步骤2.3，数据路由模块预制定数据路由策略，并对所述详单查询请求进行解析，得到详单查询参数和详单标识；然后，数据路由模块基于数据路由策略对所述详单查询参数和详单标识进行分析，匹配到存储有对应详单的数据存储模块，并将所述详单查询请求下发到对应的数据存储模块；

步骤2.4，所述数据存储模块提取符合本次详单查询条件的详单文件，并将提取到的详单文件返回给用户。

优选的，步骤1.5，所述数据存储模块保存详细的所述详单文件内容，具体为：

每个所述数据存储模块作为一个数据存储节点，从而构成轻量级分布式基于kv的Nosql数据存储体系；所述基于kv的Nosql数据存储体系的存储关键字为：用户标识、日期和详单类型；

步骤1.4中，所述详单数据关键参数为：用户标识、日期和详单类型；

步骤2.3中，所述详单标识为：用户标识、日期和详单类型。

优选的，步骤1.3和步骤2.2中，所述安全性验证包括两种：

第一种，对来源地址和身份进行合法性验证；

第二种，针对特定来源设定接口调用的频度限制，然后，验证特定来源接口调用的频度是否超过设定值，如果超过，则为频繁异常的调用，进行屏蔽处理；如果未超过，则通过验证。

本发明提供的云详单查询管理系统及方法具有以下优点：

本发明提供的云详单查询管理系统及方法，采用专门针对详单业务特点而设计的轻量级分布式Nosql数据存储体系，系统采用x86服务架构，无需商业数据库和集中存储支持，能够有效降低系统硬件成本，且能够在每天数十亿详单信息的快速插入的业务环境下，提供高效的详单信息查询服务，具有用户详单更新速度快以及查询速度快的优点，全面提高用户查询体验。

附图说明

图1为本发明提供的云详单查询管理系统的架构原理图；

图2为本发明提供的详单数据存储流程图；

图3为本发明提供的详单数据查询流程图；

图4为本发明提供的数据存储模块的结构图；

图5为本发明提供的日志文件的结构示意图；

图6为本发明提供的CCTable文件的文件结构示意图；

图7为本发明提供的CCTable文件的逻辑布局示意图；

图8为本发明提供的写入操作示意图；

图9为本发明提供的读操作示意图。

具体实施方式

为了使本发明所解决的技术问题、技术方案及有益效果更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

本发明涉及电信服务的详单管理技术，特别是针对百亿级海量详单信息的云化架构管理系统及方法。采用本发明提供的支持云化架构的详单信息管理、高并发查询系统及方法，可解决现有详单数据量爆炸式增长环境下系统操作效率的问题。

为方便对本发明理解，首先对与本发明主题最相关的术语解释：

详单：运营商根据用户使用情况产生的包括语音、短信、数据流量等业务的费用清单；

云详单：通过云化架构设计实现的详单系统，实时性及扩展性显著高于传统详单系统实现方式，且性能更好，成本更低；

详单查询：用户通过营业厅、电话、短信、网厅、自助终端等方式对详单进行实时检索；

详单系统：管理和存储详单信息的系统，对外提供详单数据的插入、更新、删除、查询等能力。

参考图1，本发明提供的云详单查询管理系统，包括：详单文件管理模块、接口服务模块、数据路由模块和数据存储模块。

(一)详单文件管理模块

详单文件管理模块，用于接收外部系统，例如，计费系统上传的新的详单文件，读取到所述新的详单文件的详单文件内容；然后，向所述接口服务模块发送数据写入指令，满足系统间的数据交互需要；其中，所述数据写入指令中携带有所述详单文件内容。

(二)接口服务模块

接口服务模块，对外提供操作接口，分别与所述详单文件管理模块以及外部详单查询系统对接，用于接收所述详单文件管理模块下发的数据写入指令，解析到需要被写入的详单文件内容；然后，根据所述详单文件内容生成详单写入请求，将所述详单写入请求下发到所述数据路由模块；

或者，用于接收所述外部详单查询系统发送的详单查询指令，从所述详单查询指令中解析到详单查询参数，根据所述详单查询参数生成详单查询请求，并将所述详单查询请求下发到所述数据路由模块。

此外，接口服务模块还支持身份验证、频率控制等安全功能，即：在接收到所述详单文件管理模块下发的数据写入指令，或者，在接收到所述外部详单查询系统发送的详单查询指令时，首先进行安全性验证，只有安全验证通过后，再进行后续数据解析操作。所述安全性验证包括两种：第一种，对来源地址和身份进行合法性验证；第二种，针对特定来源设定接口调用的频度限制，然后，验证特定来源接口调用的频度是否超过设定值，如果超过，则为频繁异常的调用，进行屏蔽处理；如果未超过，则通过验证。

(三)数据路由模块

数据路由模块，用于预制定数据路由策略，接收来自于所述接口服务模块的详单操作指令；其中，所述详单操作指令包括详单写入请求或详单查询请求；然后，根据所述数据路由策略，对所述详单操作指令中的数据进行数据特征提取，并根据数据特征查找到对应的数据存储模块，最后将详单操作指令传输给相对应的数据存储模块。

(四)数据存储模块

作为海量详单数据的支撑管理查询平台，数据存储模块包括一套存储核心系统以及在这套存储系统上提供的操作接口。在整个系统正在运行过程中(不断插入删除读取数据)，给数据存储模块照相，从照片可以看到之前系统的数据在内存和磁盘中是如何分布的，处于什么状态。

数据存储模块，用于接收来自于所述数据路由模块的详单操作指令，并执行对应的操作；即：当接收到来自于所述数据路由模块的详单写入请求时，写入并存储详单数据；当接收到来自于所述数据路由模块的详单查询请求时，根据所述详单查询参数，查询到对应的详单数据，并将查询到的详单数据返回给所述外部详单查询系统。

数据存储模块用于存储和管理具体的详单数据，支持保存多个字段信息以满足用户详单查询的需求。

具体的，参考图4，为数据存储模块的结构图。所述数据存储模块的静态主体结构包括内存表、不变内存表、log文件以及CCTable文件；其中，所述内存表和所述不变内存表位于内存中；所述Current文件、所述Manifest文件、所述log文件以及所述CCTable文件位于磁盘上；

数据存储模块的静态结构的包括4个主要部分：内存表、不变内存表、log文件以及CCTable文件。还可以进一步包括Current文件和Manifest文件。其中，所述内存表和所述不变内存表位于内存中；所述Current文件、所述Manifest文件、所述log文件以及所述CCTable文件位于磁盘上；数据存储模块除了以上六个主要部分，还具有其他一些辅助的文件，但是以上六个文件和数据结构是数据存储模块的主体构成元素。

(4.1)日志文件

其中，Log文件和内存表是一致的，当应用写入一条Key:Value记录的时候，数据存储模块会首先向log文件里写入，写入成功后，再将记录插进内存表中，这样基本就算完成了写入操作，因为一次写入操作只涉及一次磁盘顺序写和一次内存写入，所以，数据存储模块写入速度非常快。

Log文件(日志文件)在系统中的作用主要是：用于系统崩溃恢复而不丢失数据。数据存储模块在写入内存前，首先将操作记录到Log文件中，然后再记入内存中。因此，即使系统崩溃，内存表中的数据没有来得及转存到磁盘的CCTable文件，数据存储模块也可以根据log文件恢复内存的内存表数据结构内容，不会造成系统丢失数据。如图5所示，为日志文件的结构示意图。

在具体实现上，对于一个log文件，数据存储模块会将其切割成以32K为单位的物理Block，每次读取的单位以一个Block作为基本读取单位，在图5中，log文件由3个Block构成，所以从物理布局来讲，一个log文件就是由连续的32K大小Block构成的。

在应用的视野里是看不到这些Block的，应用看到的是一系列的Key:Value对，在数据存储模块内部，会将一个Key:Value对看做一条记录的数据，另外在这个数据前增加一个记录头，用来记载一些管理信息，以方便内部处理。

(4.2)CCTable文件

数据存储模块中存在不同层级的很多CCTable文件，所有CCTable文件内部布局都是一样的。CCTable文件内部是根据记录的Key由小到大排列的。每个Block分为三个部分，如图6所示，为CCTable文件的文件结构示意图。包括：数据存储区、Type区和CRC区；其中，Type区用于标识数据存储区是否采用了数据压缩算法，CRC部分则是数据校验码，用于判别数据是否在生成和传输中出错。

如图7所示，为CCTable文件的逻辑布局示意图。从大的方面讲，可以将CCTable文件划分为数据存储区和数据管理区，其中，数据存储区存放实际的Key:Value数据，数据管理区则提供一些索引指针等管理数据，目的是更快速便捷的查找相应的记录。两个区域都是在上述的分块基础上的，就是说，文件的前面若干块实际存储KV数据，后面数据管理区存储管理数据。管理数据又分为四种不同类型：Meta Block、MetaBlock索引和数据索引块以及一个文件尾部块。

(4.3)内存表和不变内存表

数据存储模块，所有KV数据都是存储在内存表、不变内存表和CCTable中的，不变内存表从结构上讲和内存表是完全一样的，区别仅仅在于其是只读的，不允许写入操作，而内存表则是允许写入和读取的。

当内存表写入的数据占用内存到达指定数量，则自动转换为不变内存表，等待转存到磁盘中，系统会自动生成新的内存表供写操作写入新数据。

数据存储模块的内存表提供了将KV数据写入、删除以及读取KV记录的操作接口，但是事实上，内存表并不存在真正的删除操作，删除某个Key的Value在内存表内是作为插入一条记录实施的，但是会打上一个Key的删除标记。

数据存储模块的内存表中KV对是根据Key大小有序存储的，在系统插入新的KV时，数据存储模块要把这个KV插到合适的位置上以保持这种Key有序性。

因此，当内存表插入的数据占用内存到了一个界限后，需要将内存的记录导出到外存文件中，数据存储模块会生成新的Log文件和内存表，原先的内存表就成为不变内存表，只能读不能写入或者删除。新到来的数据被记入新的Log文件和内存表，数据存储模块后台调度会将不变内存表的数据导出到磁盘，形成一个新的CCTable文件。CCTable文件就是由内存中的数据不断导出并进行压缩操作后形成的，而且CCTable的所有文件是一种层级结构，第一层为Level 0，第二层为Level 1，层级逐渐增高。

(4.4)Current文件

Current文件：用于记载当前的manifest文件名。因为在数据存储模块的运行过程中，随着压缩的进行，CCTable文件会发生变化，会有新的文件产生，老文件被废弃，Manifest也会跟着反映这种变化，此时新生成Manifest文件用于记载这种变化，而Current文件则用来指出哪个Manifest文件才是我们关心的那个Manifest文件。

(五)写入和删除操作设计

插入一条KV记录或者删除一条KV记录。数据存储模块的更新操作速度是非常快的，源于其内部机制决定了这种更新操作的简单性。

如图8所示，为写入操作示意图。所述数据存储模块采用以下方法写入数据：

(1)当所述数据存储模块需要写入一条Key:Value记录的时候，所述数据存储模块首先将所述Key:Value记录写入到所述log文件；

(2)所述内存表中KV对是根据Key大小有序存储的，因此，在将Key:Value记录成功写入到所述log文件后，所述数据存储模块再将所述Key:Value记录写入到所述内存表中的对应位置，以保证所述内存表中存储数据的有序性；

(3)如此不断循环，实现所述内存表和所述log文件的一致性；当所述内存表写入的数据占用内存到达设定界限后，所述数据存储模块生成新的Log文件和新的内存表；原先的内存表转为不变内存表，所述不变内存表指：只能进行读操作，不能进行写入操作或者删除操作；后续当需要写入新的Key:Value记录时，将新的Key:Value记录分别被写入所述新的Log文件和新的内存表；

(4)数据存储模块将所述不变内存表中存储的数据导出到所述磁盘并进行压缩操作后，形成一个新的CCTable文件；其中，所述CCTable文件为层级结构，第一层为Level 0、第二层为Level 1、依此类推，其层级逐渐增高；所述CCTable文件所存储的记录是根据记录的Key由小到大排列的。

在具体实现上，对于一个写入操作，包含两个具体步骤：首先是将这条KV记录以顺序写的方式追加到之前介绍过的log文件末尾，这是一个磁盘读写操作，文件的顺序追加写入效率是很高的，所以并不会导致写入速度的降低；第二个步骤是：保障写入log文件成功，将这条KV记录插入内存中的内存表中，内存表只是一层封装，其内部其实是一个Key有序的列表，先查找合适的插入位置，然后修改相应的链接指针将新记录插入。完成这一步，写入记录就完成了，一个插入记录操作涉及一次磁盘文件追加写和内存插入操作，因此，数据存储模块写入速度非常高效。

(六)读取操作设计

如图9所示，为读取操作示意图。

所述数据存储模块采用以下方法查询数据：

(1)所述数据存储模块首先查看内存中的内存表，判断所述内存表中是否包含key及其对应的value，如果包含，则返回value值即可；如果不包含，则执行步骤(2)；

(2)所述数据存储模块查看内存中的不变内存表，判断所述不变内存表中是否包含key及其对应的value，如果包含，则返回value值即可；如果不包含，则执行步骤(3)；

(3)所述数据存储模块查看磁盘中的多个CCTable文件，对于每个CCTable文件，由于其为层级结构，因此，首先查找属于level 0的文件，如果查找到所需的key及其对应的value，则返回value值即可；如果未查找到，则查找属于level1的文件，如此循环往复，直到在某层CCTable文件中查找到所需要的key及其对应的value为止。

其中，所述数据存储模块查询数据时，当所述内存表和所述不变内存表中均不存在需要查询的key及其对应的value时，采用以下方法查询：

(a)所述数据存储模块预建立Table缓存和Block缓存；其中，所述Block缓存用于缓存上一次返回给用户的key及其对应的value；所述Table缓存用于缓存分别指向CCTable文件中不同block区域的文件指针以及Block缓存的位置信息；

(b)当所述数据存储模块接收到用户发出的读取请求时，所述读取请求中携带有目标key；

(c)所述数据存储模块首先查询所述Block缓存，判断所述Block缓存中是否存在所述目标key，如果存在，则查找到与所述目标key对应的目标value，并向所述用户返回所述目标value，结束流程；如果不存在，则执行步骤d；

(d)所述数据存储模块查询所述Table缓存中的文件指针，获得包含所述目标key的文件指针，然后，根据所述文件指针的指向，查找到所述CCTable文件中对应的一个block区域数据；

然后，所述数据存储模块根据所述Table缓存中的Block缓存的位置信息，定位到Block缓存，再将所述block区域数据传输到所述Block缓存；

(e)所述数据存储模块查询所述Block缓存，判断所述Block缓存中是否存在所述目标key，如果存在，则查找到与所述目标key对应的目标value，并向所述用户返回所述目标value，结束流程；如果不存在，则执行步骤f；

(f)所述数据存储模块从磁盘的CCTable文件中查找与所述目标key对应的目标value，然后，将所述目标key及对应的所述目标value插入到Block缓存；

(g)返回步骤c。

上述设计的原理为：

当需要读取数据时，数据存储模块首先会去查看内存中的内存表，如果内存表中包含key及其对应的value，则返回value值即可；如果在内存表没有读到key，则接下来到同样处于内存中的不变内存表中去读取，如果读到就返回，若是没有读到，从磁盘中的大量CCTable文件中查找。由于CCTable数量较多，而且分成多个Level。总的读取原则是：首先从属于level 0的文件中查找，如果找到则返回对应的value值，如果没有找到，那么到level1中的文件中去找，如此循环往复，直到在某层CCTable文件中找到这个key对应的value为止。

由于内存表存储的是最新鲜的KV对；不变内存表中存储的KV数据对的新鲜程度次之；而所有CCTable文件中的KV数据新鲜程度一定不如内存中的内存表和不变内存表的。对于CCTable文件来说，如果同时在level L和Level L+1找到同一个key，level L的信息一定比level L+1的要新。列出的查找路径就是按照数据新鲜程度排列出来的，越新鲜的越先查找。

CCTable文件很多，level 0和其它level中查找某个key的过程是不一样的。因为level 0下的不同文件可能key的范围有重叠，数据存储模块的策略是先找出level 0中哪些文件包含这个key，之后按照文件的新鲜程度排序，新的文件排在前面，之后依次查找，读出key对应的value。

数据存储模块中引入了两个不同的Cache：Table Cache和Block Cache。在TableCache中，key值是CCTable的文件名称，Value部分包含两部分，一个是指向磁盘打开的CCTable文件的文件指针，这是为了方便读取内容；另外一个是指向内存中这个CCTable文件对应的Block Cache结构指针，table结构在内存中，保存了CCTable的index内容以及用来指示block cache用的cache_id。其中，Block缓存是可以根据用户需要，选配组件，即在配置文件中指定是否打开这个功能。

数据存储模块一般会先在内存中的Block Cache中查找是否包含这个文件的缓存记录，如果包含，则从缓存中读取；如果不包含，则打开CCTable文件，同时将这个文件的索引部分加载到内存中并放入Block Cache中。这样Block Cache里面就有了这个CCTable的缓存项，但是只有索引部分在内存中，之后数据存储模块根据索引可以定位到哪个内容Block会包含这条key，从文件中读出这个Block的内容，在根据记录一一比较，如果找到则返回结果，如果没有找到，那么说明这个level的CCTable文件并不包含这个key，所以到下一级别的CCTable中去查找。

在读取操作中，数据存储模块确定了key在某个level下某个文件A的keyrange范围内，那么需要判断是不是文件A真的包含这个KV。此时，数据存储模块会首先查找TableCache，看这个文件是否在缓存里，如果找到了，那么根据index部分就可以查找是哪个block包含这个key。如果没有在缓存中找到文件，那么打开CCTable文件，将其index部分读入内存，然后插入Cache里面，去index里面定位哪个block包含这个Key。如果确定了文件哪个block包含这个key，那么需要读入block内容，这是第二次读取。

Block Cache是为了加快这个过程的，其中的key是文件的cache_id加上这个block在文件中的起始位置block_offset。而value则是这个Block的内容。

数据存储模块发现这个block在block cache中，那么可以避免读取数据，直接在cache里的block内容里面查找key的value就行，如果没找到，那么读入block内容并把它插入block cache中。数据存储模块就是这样通过两个cache来加快读取速度的。

本发明中，参考图1，为云详单查询管理系统的架构图，所述详单文件管理模块、所述接口服务模块、所述数据路由模块和所述数据存储模块均可作为独立的服务运行于不同的服务器节点，也可支持部署在同一台服务器上；

所述详单文件管理模块、所述接口服务模块、所述数据路由模块和所述数据存储模块均可运行于物理x86服务器环境，也可运行于虚拟化/云服务器环境；

所述详单文件管理模块、所述接口服务模块、所述数据路由模块和所述数据存储模块均支持多节点同时部署运行，支持系统冗余备份；

所述详单文件管理模块、所述接口服务模块、所述数据路由模块和所述数据存储模块在进行多节点部署时，在前端配置负载均衡设备，负载均衡设备可采用现有负载均衡硬件设备，或采用Linux负载集群方案，负载均衡设备根据各个节点的负载，分发详单操作指令。

本发明还提供一种云详单查询管理方法，以满足数据分片存储和高并发查询的需求，包括数据存储流程和数据查询流程；

所述数据存储流程包括以下步骤：

步骤1.1，用户产生通信行为后，计费系统产生详单文件，并通过网络调用的方式向详单文件管理模块发送数据写入的通知消息，通知详单文件管理模块进行详单文件的解析和数据录入；

步骤1.2，详单文件管理模块在接收到数据写入的通知消息时，读取计费系统产生的详单文件的详单文件内容；然后，调用接口服务模块发送数据写入指令；其中，所述数据写入指令中携带有所述详单文件内容；

步骤1.3，接口服务模块在接收到所述数据写入指令时，首先进行安全性验证，在验证通过后，解析需要被写入的详单文件内容，生成详单数据关键参数；然后，将详单数据关键参数以及详细的详单文件内容以详单写入请求的方式发送给数据路由模块；

步骤1.4，数据路由模块预制定数据路由策略，接收来自于所述接口服务模块的详单数据关键参数以及详细的详单文件内容；然后，数据路由模块基于数据路由策略对所述详单数据关键参数进行分析，匹配到最佳的数据存储模块，并将所述详单文件内容发送到所述数据存储模块；

步骤1.5，所述数据存储模块保存详细的所述详单文件内容。具体为：数据存储模块将详单信息持久化到本地nosql存储中，并向上层反馈操作结果信息，整个详单写入操作完成。

所述数据查询流程包括以下步骤：

步骤2.1，接口服务模块接收用户通过门户系统发送的用户详单查询指令；其中，所述用户详单查询指令中携带有详单查询参数；门户系统包括但不限于：电话、短信、人工座席、网厅、智能终端等系统。

步骤2.2，接口服务模块首先进行安全性验证，在验证通过后，根据所述详单查询参数生成详单查询请求，并将所述详单查询请求下发到所述数据路由模块；

步骤2.3，数据路由模块预制定数据路由策略，并对所述详单查询请求进行解析，得到详单查询参数和详单标识；然后，数据路由模块基于数据路由策略对所述详单查询参数和详单标识进行分析，匹配到存储有对应详单的数据存储模块，并将所述详单查询请求下发到对应的数据存储模块；

步骤2.4，所述数据存储模块提取符合本次详单查询条件的详单文件，并将提取到的详单文件返回给用户，整个查询完毕。

其中，步骤1.5，所述数据存储模块保存详细的所述详单文件内容，具体为：每个所述数据存储模块作为一个数据存储节点，从而构成轻量级分布式基于kv的Nosql数据存储体系；所述基于kv的Nosql数据存储体系的存储关键字为：用户标识、日期和详单类型；步骤1.4中，所述详单数据关键参数为：用户标识、日期和详单类型；步骤2.3中，所述详单标识为：用户标识、日期和详单类型。

下面介绍本发明一个具体实施例：

如图1所示，本发明提供的云详单查询管理系统，包括：详单文件管理模块、接口服务模块、数据路由模块和数据存储模块。其中，该系统所有模块均可支持多个节点同时部署，每个模块均采用无状态化服务设计，可更好地适应前端负载分发来的请求。

(1)接口服务模块

接口服务模块对外提供REST接口，以JSON为数据交互格式，使用基于TOKEN的安全验证，并可针对特定来源设定接口调用的频度限制，对频繁异常的调用进行屏蔽处理。

(2)数据路由模块

数据路由模块负责提取详单数据特征，并根据详单数据特征进行数据存储结点的分配。

具体地，详单数据特征主要通过用户标识+日期+详单类型这几个关键信息来实现；

其中：用户标识主要采用用户的MSISDN号码，详单类型采用特殊字符指代具体的语音、短信、数据、增值服务等类型。

(3)数据存储模块

数据存储模块使用基于kv的nosql存储技术，在本系统中，key的形式与数据路由模块的详单数据特征相匹配。

如：数据存储模块的key为+8613900000001:SMS:201502XXXXXXXXXXX，通过使用这种标识技术，可快速地在多个数据存储节点中定位用户所需的详单数据，将数据分布于多个数据节点中，减轻单个节点的数据存储量，因此数据写入或查询效率非常高。

(4)详单文件管理模块

详单文件管理模块负责原始详单信息的监控、数据采集及数据存储工作，支持通过FTP、TCP等多种方式进行详单文件的推送接收，满足现有计费系统的对接需求。

参考图2，详单信息写入流程为：

(1)用户产生通信行为后，计费系统及时生成详单文件，并通知云详单查询管理系统的详单文件管理模块。

具体的，每个详单文件的大小默认为1MB，且支持配置，当有新的详单文件生成时，系统通过FTP的方式将详单文件上传至详单文件管理模块；

为了提高运转效率，系统支持TCP通知的方式激活详单文件更新操作。

此外，详单信息按照详单类型进行分类保存，并通过详单文件名进行区分。

(2)详单文件管理模块在接收到计费系统的通知后，读取详单文件内容，并调用接口服务模块REST接口，将数据提交至详单查询管理系统的接口服务模块处理。

(3)接口服务模块接收到上述请求，并对来源地址和身份进行合法性验证，然后解析详单数据中每个字段数据，并生成详单数据key，格式为：MSISDN:TYPE:TIME，并将详单数据key及对应详单数据传递给数据路由模块。

(4)数据路由模块查询接受到的详单数据key，并根据路由策略将数据传递给后端具体的数据存储模块。

(5)后端数据存储模块保存详单数据。

参考图3，详单查询流程包括：

(1)当用户需要查询详单信息时，用户在门户完成身份认证并进行详单查询，查询条件可包括：详单类型(语音、短信、增值服务、数据服务等)、查询日期区间等；

(2)门户将用户请求转至接口服务模块；

(3)接口服务模块接收详单查询请求，并进行安全性和频度策略检测后，根据用户查询条件生成查询请求，并将查询请求转至数据路由模块。

具体地，数据查询请求参数应针对用户输入生成首尾两个key，如用户13900000001查询2015年3月的短信详单，则接口服务模块生成的查询参数为：param1＝13900000001:SMS:20150301000000000，param2＝13900000001:SMS:20150331999999999，并将param1和param2传送至数据路由模块；

(4)数据路由模块根据数据查询请求参数确定数据路由策略，选择保存有该数据的数据存储模块节点，并将请求发送至该节点；

(5)数据存储模块提取所查询到的数据并返回，用户看到详单数据。

本发明中，云详单查询管理系统采用x86架构，采用专门为详单系统特性而设计的分布式key value数据存储系统，可支持快速插入、实时更新和高并发查询功能，而非大数据解决方案所擅长的数据统计运算。

具体的，本发明采用MSISDN:TYPE:DATETIME的形式作为详单数据标识；采用MSISDN:TYPE:DATETIME的形式制定数据路由，决定数据分片存储的对应节点；采用MSISDN:TYPE:DATETIMESTART～MSISDN:TYPE:DATETIMESTOP进行数据集的划分，通过此方式支持任意时间段的详单查询。

本发明提供的云详单查询管理系统及方法，具有以下优点：

1、云详单查询管理系统采用x86架构，且无需集中存储资源，相对传统小型机+集中存储+Oracle RAC的解决方案，有效降低了成本，提高了查询效率；

2、使用分布式云化架构设计，可实现灵活通过添加服务器节点，从而提升系统性能，满足系统横向扩展的需求；

3、使用专门针对详单系统业务特性设计的Nosql存储技术，相对hadoop大数据解决方案，数据入库和实时查询性能更好、延迟更低、维护性更好，最重要的是，解决了数据不能更新的问题；

4、采用独特的用户标识+日期+详单类型的数据标识方法及数据路由策略，完美解决海量数据分片存储和查询的问题；

5、能够支持十亿级别的数据量处理，在这个数量级别下可以保持非常高的性能；

6、模块间操作接口简单，主要基础操作包括写记录，读记录和删除记录，支持多个操作组合的原子操作。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视本发明的保护范围。

Claims (1)

1.一种云详单查询管理系统，其特征在于，包括：详单文件管理模块、接口服务模块、数据路由模块和数据存储模块；

详单文件管理模块，用于接收外部系统上传的新的详单文件，读取到所述新的详单文件的详单文件内容；然后，向所述接口服务模块发送数据写入指令；其中，所述数据写入指令中携带有所述详单文件内容；

接口服务模块，分别与所述详单文件管理模块以及外部详单查询系统对接，用于接收所述详单文件管理模块下发的数据写入指令，解析到需要被写入的详单文件内容；然后，根据所述详单文件内容生成详单写入请求，将所述详单写入请求下发到所述数据路由模块；

或者，用于接收所述外部详单查询系统发送的详单查询指令，从所述详单查询指令中解析到详单查询参数，根据所述详单查询参数生成详单查询请求，并将所述详单查询请求下发到所述数据路由模块；

数据路由模块，用于预制定数据路由策略，接收来自于所述接口服务模块的详单操作指令；其中，所述详单操作指令包括详单写入请求或详单查询请求；然后，根据所述数据路由策略，对所述详单操作指令中的数据进行数据特征提取，并根据数据特征查找到对应的数据存储模块，最后将详单操作指令传输给相对应的数据存储模块；

数据存储模块，用于接收来自于所述数据路由模块的详单操作指令，并执行对应的操作；即：当接收到来自于所述数据路由模块的详单写入请求时，写入并存储详单数据；当接收到来自于所述数据路由模块的详单查询请求时，根据所述详单查询参数，查询到对应的详单数据，并将查询到的详单数据返回给所述外部详单查询系统；

所述数据存储模块的静态主体结构包括读写内存表、只读内存表、log文件以及CCTable文件；其中，所述读写内存表和所述只读内存表位于内存中；所述log文件以及所述CCTable文件位于磁盘上；

所述数据存储模块采用以下方法写入数据：

（1）当所述数据存储模块需要写入一条Key:Value记录的时候，所述数据存储模块首先将所述Key:Value记录写入到所述log文件；

（2）所述读写内存表中Key:Value对是根据Key大小有序存储的，因此，在将Key:Value记录成功写入到所述log文件后，所述数据存储模块再将所述Key:Value记录写入到所述读写内存表中的对应位置，以保证所述读写内存表中存储数据的有序性；

（3）如此不断循环，实现所述读写内存表和所述log文件的一致性；当所述读写内存表写入的数据占用内存到达设定界限后，所述数据存储模块生成新的Log文件和新的读写内存表；原先的读写内存表转为只读内存表，所述只读内存表指：只能进行读操作，不能进行写入操作或者删除操作；后续当需要写入新的Key:Value记录时，将新的Key:Value记录分别被写入所述新的Log文件和新的读写内存表；

（4）数据存储模块将所述只读内存表中存储的数据导出到所述磁盘并进行压缩操作后，形成一个新的CCTable文件；其中，所述CCTable文件为层级结构，第一层为Level 0、第二层为Level 1、依此类推，其层级逐渐增高；所述CCTable文件所存储的记录是根据记录的Key由小到大排列的；

所述数据存储模块采用以下方法查询数据：

（1）所述数据存储模块首先查看内存中的读写内存表，判断所述读写内存表中是否包含key及其对应的value，如果包含，则返回value值即可；如果不包含，则执行步骤（2）；

（2）所述数据存储模块查看内存中的只读内存表，判断所述只读内存表中是否包含key及其对应的value，如果包含，则返回value值即可；如果不包含，则执行步骤（3）；

（3）所述数据存储模块查看磁盘中的多个CCTable文件，对于每个CCTable文件，由于其为层级结构，因此，首先查找属于level 0的文件，如果查找到所需的key及其对应的value，则返回value值即可；如果未查找到，则查找属于level1的文件，如此循环往复，直到在某层CCTable文件中查找到所需要的key及其对应的value为止；

所述数据存储模块查询数据时，当所述读写内存表和所述只读内存表中均不存在需要查询的key及其对应的value时，采用以下方法查询：

（a）所述数据存储模块预建立Table缓存和Block缓存；其中，所述Block缓存用于缓存上一次返回给用户的key及其对应的value；所述Table缓存用于缓存分别指向CCTable文件中不同block区域的文件指针以及Block缓存的位置信息；

（b）当所述数据存储模块接收到用户发出的读取请求时，所述读取请求中携带有目标key；

（c）所述数据存储模块首先查询所述Block缓存，判断所述Block缓存中是否存在所述目标key，如果存在，则查找到与所述目标key对应的目标value，并向所述用户返回所述目标value，结束流程；如果不存在，则执行步骤d；

（d）所述数据存储模块查询所述Table缓存中的文件指针，获得包含所述目标key的文件指针，然后，根据所述文件指针的指向，查找到所述CCTable文件中对应的一个block区域数据；

然后，所述数据存储模块根据所述Table缓存中的Block缓存的位置信息，定位到Block缓存，再将所述block区域数据传输到所述Block缓存；

（e）所述数据存储模块查询所述Block缓存，判断所述Block缓存中是否存在所述目标key，如果存在，则查找到与所述目标key对应的目标value，并向所述用户返回所述目标value，结束流程；如果不存在，则执行步骤f；

（f）所述数据存储模块从磁盘的CCTable文件中查找与所述目标key对应的目标value，然后，将所述目标key及对应的所述目标value插入到Block缓存；

（g）返回步骤c；

其中，所述外部系统为详单计费系统；

其中，所述接口服务模块还用于：在接收到所述详单文件管理模块下发的数据写入指令，或者，在接收到所述外部详单查询系统发送的详单查询指令时，首先进行安全性验证，只有安全验证通过后，再进行后续数据解析操作；

其中，所述安全性验证包括两种：

第一种，对来源地址和身份进行合法性验证；

第二种，针对特定来源设定接口调用的频度限制，然后，验证特定来源接口调用的频度是否超过设定值，如果超过，则为频繁异常的调用，进行屏蔽处理；如果未超过，则通过验证；

其中，所述详单文件管理模块、所述接口服务模块、所述数据路由模块和所述数据存储模块均作为独立的服务运行于不同的服务器节点，或者部署在同一台服务器上；

所述详单文件管理模块、所述接口服务模块、所述数据路由模块和所述数据存储模块均可运行于物理x86服务器环境或者虚拟化/云服务器环境；

所述详单文件管理模块、所述接口服务模块、所述数据路由模块和所述数据存储模块均支持多节点同时部署运行，支持系统冗余备份；

所述详单文件管理模块、所述接口服务模块、所述数据路由模块和所述数据存储模块在进行多节点部署时，在前端配置负载均衡设备，负载均衡设备根据各个节点的负载，分发详单操作指令；

数据存储模块的静态主体结构还包括Current文件和Manifest文件；所述Current文件和所述Manifest文件位于磁盘上；

（4.1）日志文件

日志文件在系统中用于系统崩溃恢复时不丢失数据；数据存储模块在写入内存前，首先将操作记录到Log文件中，然后再记入内存中；因此，即使系统崩溃，读写内存表中的数据没有来得及转存到磁盘的CCTable文件，数据存储模块也根据log文件恢复内存的读写内存表数据结构内容，不会造成系统丢失数据；

对于一个log文件，数据存储模块会将其切割成以32K为单位的物理Block，每次以一个Block作为基本读取单位，log文件由3个Block构成，在物理布局上，一个log文件由连续的32K大小Block构成；

在应用中看不到Block，看到的是一系列的Key:Value对，在数据存储模块内部，会将一个Key:Value对看做一条记录的数据，在这个数据前增加一个记录头，用来记载管理信息，以方便内部处理；

（4.2）CCTable文件

数据存储模块中存在不同层级的CCTable文件，所有CCTable文件内部布局都是一样的；CCTable文件内部是根据记录的Key由小到大排列的；每个Block分为三个部分，包括：数据存储区、Type区和CRC区；其中，Type区用于标识数据存储区是否采用了数据压缩算法，CRC区是数据校验码，用于判别数据是否在生成和传输中出错；

将CCTable文件划分为数据存储区和数据管理区，其中，数据存储区存放实际的Key:Value数据，数据管理区则提供索引指针管理数据，以查找相应的记录；数据存储区和数据管理区都是基于分块原理进行存储数据；索引指针管理数据分为四种不同类型： MetaBlock、 MetaBlock 索引和数据索引块以及一个文件尾部块；

（4.3）读写内存表和只读内存表

数据存储模块，所有Key:Value数据都是存储在读写内存表、只读内存表和CCTable中的，只读内存表从结构上讲和读写内存表是完全一样的，区别在于只读内存表是只读的，不允许写入操作，而读写内存表则是允许写入和读取的；

当读写内存表写入的数据占用内存到达指定数量，则自动转换为只读内存表，等待转存到磁盘中，系统会自动生成新的读写内存表供写操作写入新数据；

数据存储模块的读写内存表提供了将Key:Value数据写入、删除以及读取Key:Value记录的操作接口，读写内存表并不存在真正的删除操作，删除某个Key的Value在读写内存表内是作为插入一条记录实施的，但是会打上一个Key的删除标记；

数据存储模块的读写内存表中Key:Value对是根据Key大小有序存储的，在系统插入新的Key:Value时，数据存储模块要把这个Key:Value插到合适的位置上以保持这种Key有序性；

当读写内存表插入的数据占用内存达到预设界限后，将内存的记录导出到外存文件中，数据存储模块会生成新的Log文件和读写内存表，原先的读写内存表就成为只读内存表，只能读不能写入或者删除；新到来的数据被记入新的Log文件和读写内存表，数据存储模块后台调度会将只读内存表的数据导出到磁盘，形成一个新的CCTable文件；CCTable文件就是由内存中的数据不断导出并进行压缩操作后形成的，而且CCTable的所有文件是一种层级结构，第一层为Level 0，第二层为Level 1，层级逐渐增高；

（4.4）Current文件

Current文件：用于记载当前的manifest文件名；因为在数据存储模块的运行过程中，随着压缩的进行，CCTable文件会发生变化，会有新的文件产生，老文件被废弃，Manifest也会跟着反映这种变化，此时新生成Manifest文件用于记载这种变化，而Current文件用来指出目标Manifest文件；

由于读写内存表存储的是最新鲜的Key:Value对；只读内存表中存储的Key:Value数据对的新鲜程度次之；而所有CCTable文件中的Key:Value数据新鲜程度低于内存中的读写内存表和只读内存表的Key:Value数据新鲜程度；如果同时在level L和Level L+1找到同一个key，level L的信息比level L+1的更新；查找数据的路径顺序按照数据新鲜程度由高到低排列；

CCTable文件很多，level 0和其它level中查找某个key的过程是不一样的；因为level0下的不同文件存在key的范围有重叠，数据存储模块的策略是找出level 0中包含目标key的文件，之后按照文件的新鲜程度排序，新的文件排在前面，之后依次查找，读出key对应的value；

在Table缓存中，key值是CCTable的文件名称，Value部分包含两部分，一个是指向磁盘打开的CCTable文件中不同block区域的文件指针，以读取内容；另外一个是指向内存中CCTable文件对应的Block缓存的结构指针，在内存中配置table结构， table结构保存CCTable文件的index内容以及用来指示Block缓存用的cache_id ；其中，table结构是根据用户需要进行的选配组件，即在配置文件中指定是否打开采用table结构的功能；

数据存储模块会先在只读内存中的Block缓存中查找是否包含CCTable文件的缓存记录，如果包含，则从Block缓存中读取；如果不包含，则打开CCTable文件，同时将CCTable文件的索引部分加载到内存中并放入Block缓存中；这样Block缓存里面就有了CCTable的缓存记录，只有索引部分在只读内存中，之后数据存储模块根据索引定位到CCTable文件，从CCTable文件中读出Block的内容，再根据缓存记录，将从CCTable文件中读出的Block内容与缓存记录进行逐个比较，如果找到则返回结果，如果没有找到，则本级别CCTable文件不包含需要查找的CCTable文件，到下一级别的CCTable文件中去查找；

在读取操作中，数据存储模块确定了需要查找的key在某个级别下某个CCTable文件A的key range范围内，那么需要判断是不是CCTable文件A真的包含需要查找的Key:Value；此时，数据存储模块首先查找Table缓存，看CCTable文件是否在Table缓存里，如果找到，那么根据index部分就查找到包含该key的目标block；如果没有在Table缓存中找到CCTable文件，那么打开CCTable文件，将其index部分读入内存，然后插入Block缓存，去index里面定位包含该key的目标block；如果确定CCTable文件的block包含需要查找的key，那么需要读取定位到的block内容，这是第二次读取；

其中的key是CCTable文件的cache_id加上block在CCTable文件中的起始位置block_offset；而value则是Block的内容；

数据存储模块发现block在Block缓存中，那么避免读取数据，直接在Block缓存里的block内容里面查找key的value就行，如果没找到，那么读入block内容并把它插入Block缓存中，以加快读取速度。

Images