京东技术 www.toutiao.im
背景
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中。
如果每次定时任务处理中都将所有的dirty key同步到磁盘中,当dirty key较多时,一次处理完会严重影响Redis的性能,因此我们采用时间片的方式缓慢处理,不过这里也做了一点儿优化,就是按照dirty key的数量和当前Redis dict的数量比率,动态调整时间片大小,如果比率较高,说明当前Redis中有很多dirty key需要同步,那么就分配较大的时间片,如果发现这个比率很高,就会强制将所有的dirty key同步到磁盘上,因为如果这中场景下仍然采用时间片方式,有可能造成内存占用率很高,但是因为大量的dirty key存在,使得内存得不到释放,影响Redis server可用性。
另外需要说明的是,当需要生成数据库快照,集群分裂/合并或者Redis server退出时,必须强制将所有的dirty key同步到磁盘以避免数据丢失。
Redis某些动作会触发扫描磁盘,当磁盘上存储的数据量很大时,这样的操作会占用大量的CPU资源,影响Redis对其他客户端的响应,如果这种磁盘扫描耗时很久,会造成集群哨兵系统误报实例死亡,从而触发faileOver流程,因此我们对于磁盘扫描操作,允许扫描期间适当让渡出CPU,即调用aeProcessEvents(),这样Redis可以处理其他的event事件。
当一个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通信协议和数据类型,很好的满足了业务方的业务需求。
以上内容为微信公众号IPDCHAT原创,如需转载,请注明出处~
相关推荐
JIMDB是一款兼容Redis协议的内存型K-V存储系统,其设计目标是实现在线弹性伸缩,并且所有数据都存储在内存中,因此它的读写性能非常高,但数据的持久化不是其主要考虑的因素。为了确保高可用性,JIMDB采用了服务器...
JMQ支持消息的持久化、高吞吐量和低延迟,它还提供了消息顺序保证、事务消息、消息过滤等功能,支持不同业务场景下的消息分发需求。通过消息中间件,京东能够实现系统间的解耦,保证了业务的独立性和扩展性。 京东...
轴类零件加工工艺设计.zip
资源内项目源码是来自个人的毕业设计,代码都测试ok,包含源码、数据集、可视化页面和部署说明,可产生核心指标曲线图、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果、标签分布图。都是运行成功后才上传资源,毕设答辩评审绝对信服的保底85分以上,放心下载使用,拿来就能用。包含源码、数据集、可视化页面和部署说明一站式服务,拿来就能用的绝对好资源!!! 项目备注 1、该资源内项目代码都经过测试运行成功,功能ok的情况下才上传的,请放心下载使用! 2、本项目适合计算机相关专业(如计科、人工智能、通信工程、自动化、电子信息等)的在校学生、老师或者企业员工下载学习,也适合小白学习进阶,当然也可作为毕设项目、课程设计、大作业、项目初期立项演示等。 3、如果基础还行,也可在此代码基础上进行修改,以实现其他功能,也可用于毕设、课设、作业等。 下载后请首先打开README.txt文件,仅供学习参考, 切勿用于商业用途。
seaborn基本绘图人力资源数据集
移动机器人(sw三维)
自制html网页源代码查看器
3吨叉车的液压系统设计().zip
1_实验三 扰码、卷积编码及交织.ppt
北京交通大学软件学院自命题科目考试大纲.pdf
雅鲁藏布江流域 shp矢量数据 (范围+DEM).zip
基于RUST的数据结构代码示例,栈、队列、图等
NIFD:2024Q1房地产金融报告
详细介绍及样例数据:https://blog.csdn.net/li514006030/article/details/146916652
【工业机器视觉定位软件Vision-Detect】基于C#的WPF与Halcon开发的工业机器视觉定位软件(整套源码),开箱即用 有用户登录,图片加载,模板创建,通讯工具,抓边抓圆,良率统计,LOG日志,异常管理,九点标定和流程加载保存等模块,功能不是很完善,适合初学者参考学习。 资源介绍请查阅:https://blog.csdn.net/m0_37302966/article/details/146912206 更多视觉框架资源:https://blog.csdn.net/m0_37302966/article/details/146583453
内容概要:本文档详细介绍了Java虚拟机(JVM)的相关知识点,涵盖Java内存模型、垃圾回收机制及算法、垃圾收集器、内存分配策略、虚拟机类加载机制和JVM调优等内容。首先阐述了Java代码的编译和运行过程,以及JVM的基本组成部分及其运行流程。接着深入探讨了JVM的各个运行时数据区,如程序计数器、Java虚拟机栈、本地方法栈、Java堆、方法区等的作用和特点。随后,文档详细解析了垃圾回收机制,包括GC的概念、工作原理、优点和缺点,并介绍了几种常见的垃圾回收算法。此外,文档还讲解了JVM的分代收集策略,新生代和老年代的区别,以及不同垃圾收集器的工作方式。最后,文档介绍了类加载机制、JVM调优的方法和工具,以及常用的JVM调优参数。 适合人群:具备一定Java编程基础的研发人员,尤其是希望深入了解JVM内部机制、优化程序性能的技术人员。 使用场景及目标:①帮助开发人员理解Java代码的编译和执行过程;②掌握JVM内存管理机制,包括内存分配、垃圾回收等;③熟悉类加载机制,了解类加载器的工作原理;④学会使用JVM调优工具,掌握常用调优参数,提升应用程序性能。 其他说明:本文档内容详尽,适合用作面试准备材料和技术学习资料,有助于提高开发人员对JVM的理解和应用能力。
Android项目原生java语言课程设计,包含LW+ppt
戴德梁行&中国房地产协会:2021亚洲房地产投资信托基金研究报告
Android项目原生java语言课程设计,包含LW+ppt
Thinkphp6.0+vue个人虚拟物品发卡网站源码 支持码支付对接 扫码自动发货 源码一共包含两个部分thinkphp6.0后端文件,以及vue前端文件.zip