Redis+KV存储：-应对海量数据超过内存需要落盘保存.docx

《Redis+KV存储：-应对海量数据超过内存需要落盘保存.docx》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、Redis+KV存储：应对海量数据超过内存需要落盘保存本文章来自于阿里云云栖社区当海量数据超过内容从大小需要落盘保存应如何解决？如何对KV存储进行封装融合进Redis？Redis编码如何实现？Redis是目前NoSQL领域的当红炸子鸡，它象一把瑞士军刀，小巧、锋利、实用，特别适合解决一些使用传统关系数据库难以解决的问题。Redis作为内存数据库,所有的数据全部都存在内存...当海量数据超过内容从大小需要落盘保存赢如何解决？如何对KV存储进行封装融合进redis？Redis编码如何实现？Redis是目前NoSQL领域的当红炸子鸡，本文涉及的Ardb

2、就是一个完全兼容Redis协议的NoSQL的存储服务。其存储基于现有成熟的KV存储引擎实现，理论上任何类似B-Tree/LSMTree实现的KV存储实现均可作为Ardb的底层存储实现，目前Ardb支持LevelDB/RocksDB/LMDB.本文以Ardb为例，介绍Redis与KV存储之间融合时编解码层的实现。编码方式Redis与KV存储的融合方案中，编解码层是一个很重要的环节。通过编解码层，我们可以屏蔽了各种kv存储实现的不同，可以在任意一个简单的kv存储引擎上，封装实现Redis中string，hash，list，set，sortedset等

3、复杂类型的数据结构。对于String类型，很显然可以与KV存储中的一个KV对一一对应;对于其它的容器类型，我们需要·一个KV来存储其整个Key的元信息（比如List的成员个数，过期时间等）；·每一个成员需要一个KV来保存成员的名称和值；对于sortedset，其每个成员有score和rank两个属性，所以需要：·一个KV保存整个Key的元信息·每一个成员需要一个KV保存score信息·每一个成员需要一个KV保存每个成员对应rank信息Key的编码格式对于所有的Key，包含同样的前缀，编码格式定义如下：[]

4、>namespace用于支持类似redis中的库概念,可以为任意字符串,不限制必须为数字;key则是一个变长二进制字符串type用于定义一个简单key-value的类型，此类型隐含表明key的数据结构类型;一个字节meta信息的key中type固定为KEY_META；具体类型将在value中定义（参考下一节）除以上三部分外，不同类型的key可能有附加字段；如Hash的key可能需要附加field字段Value的编码格式内部Value则比较复杂，编码均以type开始，type取值即上节定义的KeyType

5、ment...>后续格式根据各种类型定义不同.各类型数据编码方式各类型数据的编码方式如下:ns代表namespaceKeyObjectValueObjectString[]KEY_METAKEY_STRINGHash[]KEY_METAKEY_HASH[]KEY_HASH_FIELDKEY_HASH_FIELDSet[]KEY_METAKEY_SET[]

6、ey>KEY_SET_MEMBERKEY_SET_MEMBERList[]KEY_METAKEY_LIST[]KEY_LIST_ELEMENTKEY_LIST_ELEMENTSortedSet[]KEY_METAKEY_ZSET[]KEY_ZSET_SCOREKEY_ZSET_SCORE[]KEY_ZSET_SORT

7、ore>KEY_ZSET_SORTZSet编码实例这里以最复杂的SortedSet来做实例。假设有个SortedSet为A:{member=frist,score=1},{member=second,score=2}。其在Ardb中的存储方式如下：KeyA的存储编码为：//伪代码中的

8、代表域的分割，不代表实际存储为"

9、"。实际序列化的时候每个域是按照特定位置序列化的.键为：ns

10、1

11、A(1代表是KEY_META元信息类型)值为：元信息编码（redis数据类型/zset，过期时间，成员个数，最大最小score等）成员first的sc

12、ore信息存储编码为:键为：ns

13、11

14、A

15、first(11代表类型为KEY_ZSET_SCORE)值为：11

16、1(11代表类型KEY_