背景
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通信协议和数据类型，很好的满足了业务方的业务需求。
原文链接:[http://wely.iteye.com/blog/2354275]
