Redis本身内容繁杂,何分要是构设上来就研究一细节点,如连接池、何分数据结构,构设虽可直接学到某个点的何分详尽源码内容,甚至尽快解决一些事故,构设但容易溺死在细节汪洋,何分无法整体把控Redis。
最好是先建立起“架构”。想精通Redis,须能领略其总体架构,再深入具体技术点。
构造Redis 这种 KV DB,首要考虑:
能存什么数据?如用户信息(用户ID、name、age、sex等),通常用 MySQL,在一个用户ID对应一个用户信息集合的场景下,就是KV DB的数据模型之一,也能满足这类存储需求。
可以怎么操作数据?如计算多个用户的avg年龄,KV DB则无法胜任。因其只提供了简单的操作接口,并不支持复杂聚合计算。
所以,先搞懂数据模型和操作接口,才能物尽其用。
数据模型
KV DB,最基本数据模型就是KV模型。选型KV DB时,一大因素就是其支持的V类型:
操作接口
无论什么DB,基本操作都逃不开 crud:
内存 or 外存?
因此,需根据KV DB应用场景来选型。
如缓存场景下的数据需要能快速访问但允许丢失,则采用内存保存KV数据。
访问模式选型
如libsimplekv.so,就是以动态链接库的形式链接到我们自己的程序,提供KV存储功能,如RocksDB。
如Memcached和Redis。
通过网络框架提供KV存储服务:
比如,当客户端发送如下命令,该命令会被封装在网络包中发送给KV DB:
- PUT java edge
KV DB网络框架接收到网络包,并按照相应的协议进行解析后,可知客户端想写入一个键值对,并开始实际写入。
I/O模型设计
网络连接的处理、解析客户端的请求及数据存取的处理,应该选择怎样的线程模型?
所以,这里也还需精心设计。
KV对的定位
知道了要进行的KV对操作,就得查找所要操作的KV对是否存在,这就依赖KV DB的索引模块:让KV DB据key找到相应V的存储位置。
不同KV DB采用的索引:
一般内存KV DB(如Redis)采用哈希表作为索引,主要因其KV基本都保存在内存,而内存高性能随机访问特性与哈希表O(1)复杂度匹配。
Redis的V支持多种类型,当通过索引找到一个K所对应V,仍需从V的复杂结构(如set或list)中进一步找到想要数据,该操作的效率本身就依赖其实现结构。而Redis便采用一些高效的索引结构作为某些V类型的底层数据结构。
各操作的具体逻辑
不同操作找到V的存储位置后的操作:
根据V的存储位置返回V值
为该KV对分配内存空间
删除KV对,并释放内存空间,该过程由分配器完成
重启后快速提供服务
KV DB的KV对大小不一,分配器在处理随机的大小内存块分配时,表现不好的话,一旦KV对数据规模过大,可能导致严重内存碎片。
所以分配器是KV DB中的关键。对内存存储为主的Redis更重要。Redis的内存分配器提供了多种选择,分配效率也不同。
KV DB虽依赖内存保存数据,提供快速访问,但也希望KV DB重启后能快速重新提供服务,所以,在其存储模块增加持久化功能。
因为磁盘管理比内存管理复杂,KV DB直接采用文件形式,将KV数据通过调用本地文件系统的操作接口保存在磁盘。
此时,KV DB只需考虑何时将内存中的KV数据保存到文件:
所以,Redis提供了持久化功能,还有多种执行机制和性能优化点。
KV DB - Redis 架构
本文转载自微信公众号「JavaEdge」,可以通过以下二维码关注。转载本文请联系JavaEdge公众号。
责任编辑:武晓燕 来源: JavaEdge Redis架构设计
(责任编辑:知识)
中国中冶(601618)融资余额12.39亿元 融券余额1509.92万元(03