JIMDB数据持久化实践

  1. 云栖社区>
  2. IXHONG>
  3. 博客>
  4. 正文

JIMDB数据持久化实践

行者武松 2017-07-03 15:55:00 浏览1554
展开阅读全文

背景

JIMDB是京东自主研发的基于Redis的分布式缓存与高速键值存储服务,支持大容量缓存,数据高可用,支持多种I/O策略,故障自动切换,支持动态扩容,目前服务于京东的几乎所有的业务系统,包括很多重要的业务系统,例如, 前台的商品详情页, 交易平台, 广告,搜索, 即时通讯等, 后台的订单履约, 库存管理, 派送和物流……。

 

Redis完全依赖内存,往往内存不够使用;Redis启动时需要把全部数据加载到内存,在数据量大时启动速度慢;规划总是赶不上业务发展,内存总量不断被突破,不断陷入扩容, 再扩容…的梦魇。有介于此,JIMDB引入RAM + SSD两级存储,在内存中存储热点数据,冷数据被自动交换到磁盘,解决内存不足的问题;启动时并不把所有数据加载入内存,而是在运行时根据需要加载,解决启动速度慢的问题;因为引入了二级存储,存储容量通常比较大,所以不需要频繁的扩容了。

 

我们选用LevelDB作为持久化存储引擎,LevelDB是Google开源的持久化KV单机数据库,具有很高的随机写,顺序读/写性能,非常适合用于存储小文件,以及一些需要持久化的索引和需要持久化的异步任务,很多开源项目就使用LevelDB作为底层存储引擎,例如:Chromium,淘宝的Tair,SSDB等。

 

 

技术方案

同步写or异步写

同步写要求Redis对key每一次修改都需要操作磁盘,尽管LevelDB的写性能很高,但是频繁的操作磁盘对性能影响仍然比较大。最终我们采用了异步写的方式,相比于同步写,异步写可以借助LevelDB提供的批量写功能获得更高的写性能,另外就是减少了操作磁盘的次数,进一步提高了性能。

 

磁盘内存数据交换

Redis查找一个key,首先会在内存中查找,只有在内存中找不到才会在磁盘中查找,如果仍然没有找到,则表明这个key不存在,如果在磁盘中找到了,会将这对KV添加到Redis的字典以加载到内存。

 

Redis修改一个key后,我们将这个key标记为dirty key,即将key的副本添加到专门用于保存dirty key的字典dirty dict中,为了节约空间,我们只存储了这个key(value为NULL)。我们在定时任务中周期性执行flush dirty key to disk任务,这个任务会将存储在dirty dict中的key写入磁盘,写磁盘时,我们需要对key的value进行序列化编码成二进制流,当dirty dict中的key都同步到磁盘上后,清空dirty dict。

 

 

主从同步

在两级存储场景下,兼容Redis的同步流程,只是数据库快照需要通过遍历磁盘生成,这就要求我们在生成快照之前需要把内存中的dirty key先全部同步到磁盘上。另外slave端接收到快照后,不再加载到内存,而是调用LevelDB写接口加载到磁盘上。

 

这里需要特别说明的是Redis生成数据库快照时,会单独启动一个后台进程处理,但是LevelDB存储引擎同时只允许一个进程访问,因此我们需要创建一个线程而不是进程去处理快照生成。

 

集群节点分裂/合并

Jimdb集群节点分裂/合并时,会将指定slot上的KV通过网络直接传输给目标Redis server(不同于Redis主从全量同步,需要生成数据库快照),目标Redis生成数据库快照,然后加载到内存。二级存储模式下,需要扫描磁盘,将指定slot上的KV通过网络传输给目标redis server,扫描之前,须先将内存中的dirty key同步到磁盘上。目标Redis将收到的数据库快照通过LevelDB的写接口加载到磁盘持久化。

 

遇到的问题与解决方法

在项目实践过程中我们遇到了许多问题,这里详细介绍一下其中核心的几个问题以及我们的解决思路。

 

内存不足

磁盘的空间一般比内存要大一个数量级,而所有的读写操作都会将磁盘上的数据加载到内存中,这样运行一段时间后就会出现内存不足的情况,虽然Redis对于每一个命令处理之前都会检查内存占用情况,当超过配置的最大内存时会按照配置的淘汰策略部分key,但是这并不能满足我们的需求,因此我们需要在发现内存不足时按照一定的策略淘汰一部分内存中key(dirty key不会被淘汰),以释放宝贵的内存资源。

 

我们根据当前内存占用率(mem_used/max_mem)所在的区间采用不同的内存淘汰策略:

 

内存占用率>85%时采用随机淘汰策略,随机淘汰部分key直到内存占用率降到75%以下。

内存占用率>75%时采用LRU淘汰策略,这里参考了Redis的淘汰思路,采用随机采样然后按照LRU淘汰。

 

不过这两种淘汰策略都可能耗时比较长,如果直接放在原来Redis检查内存占用的地方,势必会影响单次请求的延时,所以我们将上述的淘汰策略放在定时任务中处理,同时原Redis的内存占用检查我们采用快速检查方案,即内存占用率>90%时,随机淘汰几个key。

 

Key的DB属性存储

Jimdb为了方便集群中key的分裂合并,对Redis进行了改造,划分16384个slot,只使用db 0。这样为了方便从磁盘上遍历指定slot上的key,我们对存储在levelDB中的key按照如下的格式编码:

 



 

 

其中第一个字节flag在后面讲,{slot_id}是slot的ID(0~16383),采用16进制编码成字符串,这样固定占用4个字节,因为只使用db 0,因此db_id不需要存储,后面才是真正的key。这样需要遍历指定的slot中的key时,就可以按照固定的前缀在levelDB中遍历key了(levelDB中存储的KV是按照key的排序存储的,因此固定前缀的key就可以顺序遍历)。

 

Key过期时间的存储

对于设置了过期时间的key存储时,因为LevelDB可以存储二进制安全的数据,因此我们将过期时间(类型long long)直接拼接到序列化后的value的后面,这样从LevelDB中get到KV后,反序列化value时就可以将过期时间一并解析,如果解析出过期时间,过期时间会添加到Redis的expire dict中。

 

Flush dirty key阻塞Redis

如果每次定时任务处理中都将所有的dirty key同步到磁盘中,当dirty key较多时,一次处理完会严重影响Redis的性能,因此我们采用时间片的方式缓慢处理,不过这里也做了一点儿优化,就是按照dirty key的数量和当前Redis dict的数量比率,动态调整时间片大小,如果比率较高,说明当前Redis中有很多dirty key需要同步,那么就分配较大的时间片,如果发现这个比率很高,就会强制将所有的dirty key同步到磁盘上,因为如果这中场景下仍然采用时间片方式,有可能造成内存占用率很高,但是因为大量的dirty key存在,使得内存得不到释放,影响Redis server可用性。

 

另外需要说明的是,当需要生成数据库快照,集群分裂/合并或者Redis server退出时,必须强制将所有的dirty key同步到磁盘以避免数据丢失。

 

扫描磁盘阻塞Redis

Redis某些动作会触发扫描磁盘,当磁盘上存储的数据量很大时,这样的操作会占用大量的CPU资源,影响Redis对其他客户端的响应,如果这种磁盘扫描耗时很久,会造成集群哨兵系统误报实例死亡,从而触发faileOver流程,因此我们对于磁盘扫描操作,允许扫描期间适当让渡出CPU,即调用aeProcessEvents(),这样Redis可以处理其他的event事件。

 

过期key扫描

当一个key设置了过期时间但只存储在磁盘上,如果这个key已经过期,但是仍然占用磁盘空间,造成磁盘空间的浪费,因此我们需要定期扫描磁盘上存储的设置了过期时间的key,如果发现超时,即时删除以释放磁盘空间。

 

前面章节中我们提到将key的过期时间拼接到序列化后的value的末尾,如果我们扫描所有的key,通过反序列化其value解析判断是否设置了过期时间,这样显然效率很低,于是我们将所有设置了过期时间的key再单独存储一份{ key,expiretime },上文中提到的key的存储格式中的第一个字节就派上用处了,我们约定”0”表示正常的KV,”1”表示设置过期时间的key,其中只存储过期时间,这样我们直接扫描前缀为”1”的key就可以快速判断其是否已经超时。

 

我们在定时任务中增加了一个定期扫描过期key的任务,因为这个任务并不是很紧急,因此两次扫描的间隔相对较大(目前是5秒钟扫描一次),每次扫描工作固定的时间片,时间到即退出扫描。

 

测试结果显示对于20G的过期key(只存储在磁盘中),只需要几分钟就可以全部从磁盘上删除。

 

性能

因为我们采用异步flush磁盘的方式,大部分操作只需要操作内存就可以完成,性能应该不会下降太多,实际的测试结果表明其性能与JIMDB基本持平,不过TP99(<10ms)略有增加,不过在可接受范围内(业务方要求在20ms内),项目整体上达到设计预期。

 


综述

两级存储方案极大的扩展了JIMDB的容量,节约了宝贵的内存资源,同时完全兼容Redis通信协议和数据类型,很好的满足了业务方的业务需求。


原文链接:[http://wely.iteye.com/blog/2354275]

网友评论

登录后评论
0/500
评论
行者武松
+ 关注
所属云栖号: IXHONG