Redis教程

一个键值数据库包含什么(来源redis核心技术与实战)

本文主要是介绍一个键值数据库包含什么(来源redis核心技术与实战),对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

可以存哪些数据

对于键值数据库而言,基本的数据模型是key-value模型。 例如,“hello”: “world”就是一个基本的KV对,其中,“hello”是key,“world”是value。SimpleKV也不例外。在SimpleKV中,key是String类型,而value是基本数据类型,例如String、整型等。

但是,SimpleKV毕竟是一个简单的键值数据库,对于实际生产环境中的键值数据库来说,value类型还可以是复杂类型。

不同键值数据库支持的key类型一般差异不大,而value类型则有较大差别。我们在对键值数据库进行选型时,一个重要的考虑因素是它支持的value类型。例如,Memcached支持的value类型仅为String类型,而Redis支持的value类型包括了String、哈希表、列表、集合等。Redis能够在实际业务场景中得到广泛的应用,就是得益于支持多样化类型的value。

 

可以对数据做什么操作

我们先来了解下SimpleKV需要支持的3种基本操作,即PUT、GET和DELETE。

  • PUT:新写入或更新一个key-value对;
  • GET:根据一个key读取相应的value值;
  • DELETE:根据一个key删除整个key-value对。

需要注意的是,有些键值数据库的新写/更新操作叫SET。新写入和更新虽然是用一个操作接口,但在实际执行时,会根据key是否存在而执行相应的新写或更新流程。

在实际的业务场景中,我们经常会碰到这种情况:查询一个用户在一段时间内的访问记录。这种操作在键值数据库中属于SCAN操作,即根据一段key的范围返回相应的value值。因此,PUT/GET/DELETE/SCAN是一个键值数据库的基本操作集合。

实际业务场景通常还有更加丰富的需求,例如,在黑白名单应用中,需要判断某个用户是否存在。如果将该用户的ID作为key,那么,可以增加EXISTS操作接口,用于判断某个key是否存在。对于一个具体的键值数据库而言,可以通过查看操作文档,了解其详细的操作接口。

因此,如何进行设计选择,我们通常需要考虑键值数据库的主要应用场景。比如,缓存场景下的数据需要能快速访问但允许丢失,那么,用于此场景的键值数据库通常采用内存保存键值数据。Memcached和Redis都是属于内存键值数据库。对于Redis而言,缓存是非常重要的一个应用场景。

为了和Redis保持一致,我们的SimpleKV就采用内存保存键值数据。接下来,我们来了解下SimpleKV的基本组件。

大体来说,一个键值数据库包括了访问框架、索引模块、操作模块和存储模块四部分(见下图)。接下来,我们就从这四个部分入手,继续构建我们的SimpleKV。

 

 

 

 

 

 

 

采用什么访问模式

访问模式通常有两种:一种是通过函数库调用的方式供外部应用使用,比如,上图中的libsimplekv.so,就是以动态链接库的形式链接到我们自己的程序中,提供键值存储功能;另一种是通过网络框架以Socket通信的形式对外提供键值对操作,这种形式可以提供广泛的键值存储服务。在上图中,我们可以看到,网络框架中包括Socket Server和协议解析。

不同的键值数据库服务器和客户端交互的协议并不相同,我们在对键值数据库进行二次开发、新增功能时,必须要了解和掌握键值数据库的通信协议,这样才能开发出兼容的客户端。

实际的键值数据库也基本采用上述两种方式,例如,RocksDB以动态链接库的形式使用,而Memcached和Redis则是通过网络框架访问。后面我还会给你介绍Redis现有的客户端和通信协议。

通过网络框架提供键值存储服务,一方面扩大了键值数据库的受用面,但另一方面,也给键值数据库的性能、运行模型提供了不同的设计选择,带来了一些潜在的问题。

举个例子,当客户端发送一个如下的命令后,该命令会被封装在网络包中发送给键值数据库

put hello world

键值数据库网络框架接收到网络包,并按照相应的协议进行解析之后,就可以知道,客户端想写入一个键值对,并开始实际的写入流程。此时,我们会遇到一个系统设计上的问题,简单来说,就是网络连接的处理、网络请求的解析,以及数据存取的处理,是用一个线程、多个线程,还是多个进程来交互处理呢?该如何进行设计和取舍呢?我们一般把这个问题称为I/O模型设计。不同的I/O模型对键值数据库的性能和可扩展性会有不同的影响。

举个例子,如果一个线程既要处理网络连接、解析请求,又要完成数据存取,一旦某一步操作发生阻塞,整个线程就会阻塞住,这就降低了系统响应速度。如果我们采用不同线程处理不同操作,那么,某个线程被阻塞时,其他线程还能正常运行。但是,不同线程间如果需要访问共享资源,那又会产生线程竞争,也会影响系统效率,这又该怎么办呢

如何定位键值对的位置

当SimpleKV解析了客户端发来的请求,知道了要进行的键值对操作,此时,SimpleKV需要查找所要操作的键值对是否存在,这依赖于键值数据库的索引模块。索引的作用是让键值数据库根据key找到相应value的存储位置,进而执行操作。

索引的类型有很多,常见的有哈希表、B+树、字典树等。不同的索引结构在性能、空间消耗、并发控制等方面具有不同的特征。如果你看过其他键值数据库,就会发现,不同键值数据库采用的索引并不相同,例如,Memcached和Redis采用哈希表作为key-value索引,而RocksDB则采用跳表作为内存中key-value的索引。

一般而言,内存键值数据库(例如Redis)采用哈希表作为索引,很大一部分原因在于,其键值数据基本都是保存在内存中的,而内存的高性能随机访问特性可以很好地与哈希表O(1)的操作复杂度相匹配。

SimpleKV的索引根据key找到value的存储位置即可。但是,和SimpleKV不同,对于Redis而言,很有意思的一点是,它的value支持多种类型,当我们通过索引找到一个key所对应的value后,仍然需要从value的复杂结构(例如集合和列表)中进一步找到我们实际需要的数据,这个操作的效率本身就依赖于它们的实现结构。

Redis采用一些常见的高效索引结构作为某些value类型的底层数据结构,这一技术路线为Redis实现高性能访问提供了良好的支撑。

不同操作的具体逻辑是怎样的

SimpleKV的索引模块负责根据key找到相应的value的存储位置。对于不同的操作来说,找到存储位置之后,需要进一步执行的操作的具体逻辑会有所差异。SimpleKV的操作模块就实现了不同操作的具体逻辑:

  • 对于GET/SCAN操作而言,此时根据value的存储位置返回value值即可;
  • 对于PUT一个新的键值对数据而言,SimpleKV需要为该键值对分配内存空间;
  • 对于DELETE操作,SimpleKV需要删除键值对,并释放相应的内存空间,这个过程由分配器完成。

不知道你注意到没有,对于PUT和DELETE两种操作来说,除了新写入和删除键值对,还需要分配和释放内存。这就不得不提SimpleKV的存储模块了。

如何实现重启后快速提供服务

SimpleKV采用了常用的内存分配器glibc的malloc和free,因此,SimpleKV并不需要特别考虑内存空间的管理问题。但是,键值数据库的键值对通常大小不一,glibc的分配器在处理随机的大小内存块分配时,表现并不好。一旦保存的键值对数据规模过大,就可能会造成较严重的内存碎片问题。

因此,分配器是键值数据库中的一个关键因素。对于以内存存储为主的Redis而言,这点尤为重要。Redis的内存分配器提供了多种选择,分配效率也不一样,后面我会具体讲一讲这个问题。

SimpleKV虽然依赖于内存保存数据,提供快速访问,但是,我也希望SimpleKV重启后能快速重新提供服务,所以,我在SimpleKV的存储模块中增加了持久化功能。

不过,鉴于磁盘管理要比内存管理复杂,SimpleKV就直接采用了文件形式,将键值数据通过调用本地文件系统的操作接口保存在磁盘上。此时,SimpleKV只需要考虑何时将内存中的键值数据保存到文件中,就可以了。

一种方式是,对于每一个键值对,SimpleKV都对其进行落盘保存,这虽然让SimpleKV的数据更加可靠,但是,因为每次都要写盘,SimpleKV的性能会受到很大影响。

另一种方式是,SimpleKV只是周期性地把内存中的键值数据保存到文件中,这样可以避免频繁写盘操作的性能影响。但是,一个潜在的代价是SimpleKV的数据仍然有丢失的风险。

和SimpleKV一样,Redis也提供了持久化功能。不过,为了适应不同的业务场景,Redis为持久化提供了诸多的执行机制和优化改进,后面我会和你逐一介绍Redis在持久化机制中的关键设计考虑。

小结

 

 

从这张对比图中,我们可以看到,从SimpleKV演进到Redis,有以下几个重要变化:

  • Redis主要通过网络框架进行访问,而不再是动态库了,这也使得Redis可以作为一个基础性的网络服务进行访问,扩大了Redis的应用范围。
  • Redis数据模型中的value类型很丰富,因此也带来了更多的操作接口,例如面向列表的LPUSH/LPOP,面向集合的SADD/SREM等。在下节课,我将和你聊聊这些value模型背后的数据结构和操作效率,以及它们对Redis性能的影响。
  • Redis的持久化模块能支持两种方式:日志(AOF)和快照(RDB),这两种持久化方式具有不同的优劣势,影响到Redis的访问性能和可靠性。
  • SimpleKV是个简单的单机键值数据库,但是,Redis支持高可靠集群和高可扩展集群,因此,Redis中包含了相应的集群功能支撑模块。

 

这篇关于一个键值数据库包含什么(来源redis核心技术与实战)的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!