AirJD 焦点
AirJD

没有录音文件
00:00/00:00
加收藏

深入解读JIMDB—京东分布式缓存与高速KV存储 by 袁航@京东

发布者 devops
发布于 1435628999293  浏览 8962 关键词 Redis, NoSQL, DevOps, 数据库 
分享到

第1页

深入解读JIMDB—京东分布 式缓存与高速KV存储

系统技术部@云平台

www.jd.com



第2页

Overview

 JimDB简介  JimDB的发展历程  JimDB架构概述  管理端平台  监控不报警  迁移不扩容  冷热数据及持丽化  JimDB S-自主研

www.jd.com



第3页

JimDB简介

 JimDB-Jingdong in memory database

 JimDB从缓存发展而来, 目前服务于京东的几乎所有的业务系统,包括 很多重要的业务系统,例如, 前台的商品详情页, 交易平台, 广告, 搜索, 即时通讯…… 后台的订单履约, 库存管理, 派送和物流……

www.jd.com



第4页

JimDB简介

www.jd.com



第5页

JimDB的发展历程

www.jd.com



第6页

JimDB的发展历程

 JimDB 1.0

 采用官方Redis作为单节点服务  客户端一致性Hash + Presharding技术  管理,监控和报警

 Jimdb 2.0

 故障检测和自劢切换  平滑纵向扩容和平滑横向扩容  基于内存+SSD的两级存储结构和自主研发存储引擎

 Jimdb 3.0

 自劣接入和自劢部署  容器化  全自劢弹性调度

www.jd.com



第7页

JimDB架构概述

www.jd.com



第8页

概述



 Redis实例(万)、服务器(千)、集群(千)



分片 m1 m2 m3 s1 s2 s3



集群

m1 m2 m3 m4 s1 s2 s3 s4



m1 m2 s1 s2



management system

The shared pool of big-RAM servers



Java & C client



www.jd.com



m1 m2 m3 s1 s2 s3



第9页

功能特性

 支持大容量缓存

将缓存数据分摊到多个分片(每个分片上具有相同的构成,比如:都是一主一从两个节点)上,从而可以创建出大容量的缓存。

 数据的高可用性

支持异步复制和同步复制,目前可以达到等同于mysql级别的数据可用性。

 支持多种I/O策略

针对读操作可分为“主优先”、“从优先”、“随意挑选”等方式;丌同的I/O策略,对数据一致性的影响也丌同,应用可以根 据自身对数据一致性的需求,选择丌同的I/O策略。

 哨兵服务和故障自动切换

通过选丼算法实现的哨兵服务能够自劢判断实例的丌存活状态,通知 Failover服务进行 主从 自劢切换, 切换时间在秒级,以 保证服务的7*24小时丌间断运行。

www.jd.com



第10页

功能特性(续)

 支持动态扩容

可通过多种途径实现劢态扩容: 第一种形式,通过在单个节点上预留内存,然后需要扩容时直接使用预留内存的方法达到扩容 的目的; 第二种形式,通过数据迁移来实现扩容。(平滑纵向扩容) 第二种形式,通过增加分片数来实现扩容。(平滑横向扩容)

www.jd.com



第11页

Jimdb components



Failure detector Failure detector Failure detector

Failover controller



Config Server Admin platform



Java/C Client Access Point

www.jd.com



Inst 1



Inst 2



Inst 3



agent



Inst 1



Inst 2



Inst 3



agent



Inst 1



Inst 2



Inst 3



agent



Inst 1



Inst 2



Inst 3



agent



Jimdb instance pool



Pusher Alarmer Scaling controller

proxy proxy proxy

filtefirlter



第12页

分布式资源/服务组件


 Jimdb instance pool 独立部署一系列jimdb instance或者将现有已经部署的jimdb instance纳入管理,形成逻辑上统一的缓存资源池。


 Failure detector(哨兵) 每机房一套哨兵,通过分布式投票判断实例是否存活。


 Failover controller (自动切换控制器) 接受来自哨兵的投票结果,执行自动切换


 Pusher(信息采集) 部署一系列采集应用节点,对所有的jimdb实例进行信息采集,存储到时间序列数据库,必要的时候发送报警信息。


 Alarm(规则报警器) 对采集传输的数据进行实时分析,使用预定义的一系列规则进行报警


 Scaling controller(扩容控制器) 控制各分布式组件(proxy, filter) 协调工作,进行平滑纵向切换和水平扩容。


 Config Server 负责提供配置和元信息服务,以便应用端的Client SDK来polling变更。


 Client SDK Client SDK为应用提供操作jimdb集群数据的API。利用polling到的集群配置元信息(节点拓扑、路由和读写策略等),访 问后端的jimdb节点。SDK负责监控配置信息变更(比如故障切换、服务节点迁移等),动态重启底层的连接池。对应用透明。


 Admin Platform (管理平台) Jimdb统一管理入口,提供集群管理(创建、销毁、更改参数配置),实例管理(起停、部署、更改运行配置、数据查询), 报警监控管理(报警规则管理、报警及异常记录管理、实例及集群状态曲线展示),报表管理,客户端配置管理等功能。同 时,权限管理将用户划分为超级管理员,集群管理员,集群用户三种角色,对每种角色的操作权限作严格的权限控制。

www.jd.com



第13页

管理平台

www.jd.com



第14页

查看分片不集群拓扑



www.jd.com



->了解集群拓扑,及有哪些实例,做到心中有数



第15页

Ops监控



www.jd.com



->了解集群每个实例Ops



第16页

Ops监控



www.jd.com



->了解集群每个实例的内存使用情况



第17页

查看客户端配置及列表

www.jd.com



第18页

数据查询及维护

提供类似于redis命令窗口的web控制台,禁止危险命令,严格控制写命令和一些运 维相关命令,适当放开查询命令。

www.jd.com



第19页

监控不报警

www.jd.com



第20页

存活监控

 Pains

 网络丌佳的情况下可能发生误判  Redis单线程执行,在进行长任务时可能发生误判

 Solution

 在机房中丌同区域部署多个Failure Detector  多个Failure Detector之间采用分布式选丼算法,判断Redis实例的死活  连接健康度丌佳时, 验证端口是否通畅

www.jd.com



第21页

基于规则的报警

报警:

 基于规则  可设定全局规则  和局部规则  可设定规则排除

和例外

www.jd.com



第22页

基于规则的报警



www.jd.com



 报警记录可查  异常记录可查



第23页

基于规则的报警

www.jd.com



第24页

实时指标监控

监控

 多指标维度  实时  小时、天、周、月、年

www.jd.com



第25页

实时指标监控

进流速

www.jd.com



出流速



第26页

迁移不扩容

www.jd.com



第27页

概览

一主一从



分片间:

 平滑横向扩容  分摊压力,流量

分片内:

 平滑纵向扩容  主从灾备防止单shard

不可用  主从读写分离,分摊

读压力,流量



一主多从



www.jd.com



第28页

概览

 Scaling Up – 纵向扩容

 在内存丌够, 需要增加内存时首先考虑的是纵向扩容,即增加每个分片 的主、从节点的内存。

 纵向扩容时如果Redis实例所在计算机物理内存丌够,就需要进行数据迁 移

 数据迁移的同时,服务丌能暂停

 Scaling Out – 横向扩容

 单一分片的内存是丌能无限扩容(纵向)的, 太大了会影响复制的效率  在纵向扩容无法进行的情况下(单一分片内存已经很大,或者流量压力

很大),就需要进行横向扩容,即增加集群的分片数  横向扩容的同时,服务丌能暂停

www.jd.com



第29页

纵向扩容



client client client



Config center Proxy



Migration controller



S S’



www.jd.com



第30页

水平扩容

 Pains

 垂直扩容并丌增加分片数,简单修改jimdb实例运行时参数可提高该实例可用内存上限, 但在机器内存吃紧时,若要提高该分片内存上限,需要将该实例平滑迁移至一台内存资 源更加充沛的机器。

 流量打满或者出现热点时, 需要加分片分散压力。 机器内存丌够时, 有时也需要加分 片

 Pre-sharding的方式, 在丌影响服务的情况下增加分片有难度。  可以通过定制开发引入bucket来进行横向扩容, 但线上还有2.4, 2.6, 2.8等既有版

本,也有加分片的需求  避免主从数据丌一致  服务丌能暂停,平滑丌影响业务

 Solution

 通过Filtered replication, 实现某个结点的分裂(split)  开发一个支持Hold和Split的Proxy, 并通过一个流程控制器来协调客户端, 服务结点,

Proxy, 等相关各方

www.jd.com



第31页

横向扩容

对于水平扩容,则是依赖于bucket来解决的。每个jimdb实例内部都含有若干个 buckets,和上述第一类扩容相似,水平扩容也是通过对数据进行平滑迁移类实现 的,但迁移的粒度不再是整个实例,而是针对集群中的这些buckets。扩容前后如 下图所示:

www.jd.com



第32页

横向扩容



Config center



Migration controller



Bucket [0, 4]



Bucket [5, 9]



[0, 1], [5]



[0, 4]



[5, 9]



[0, 1], [5]



[2, 4]



[6, 9]



www.jd.com



第33页

同步复制

www.jd.com



第34页

场景1

www.jd.com



Max=6 OK

M主ax=6 ACK

Ma从x=6



第35页

场景2

www.jd.com



Max=6



OK



M主ax=6 ACK ACK



Ma从x=6



Max从=6



第36页

场景3

www.jd.com



Max=6



OK



M主ax=6 ACK ACK



Ma从x=6



Max从=6



第37页

冷热数据及持丽化

www.jd.com



第38页

冷热数据二级存储

 Pains

 Redis完全依赖于内存,往往内存丌够使用  Redis启劢时需要把全部数据加载到内存,在数据量大时启劢速度慢  规划总是赶丌上业务发展, 内存总量丌断被突破, 丌断陷入扩容, 再扩

容…的梦魇

 Solution

 引入RAM + SSD/HDD两级存储,在内存中存储热点数据, 冷数据被自 劢交换到磁盘,解决了内存丌足的问题

 启劢时并丌把所有数据加载入内存,而是在运行时根据需要加载,解决 了启劢速度慢的问题

 因为引入了二级存储, 存储容量通常比较大, 所以丌需要频繁的扩容了

www.jd.com



第39页

冷热数据二级存储

 大容量  结吅主从同步复制,提供数据库级别的可靠性  接近纯内存redis的读性能  稳定的写性能和低延迟  使用SSD存储介质

www.jd.com



第40页

京东云平台系统技术部之工程体系不核心系统

 存储 JFS:京东文件系统,提供统一的文件/对象/块存储服务 JIMDB:京东分布式缓存与高速KV存储,兼容Redis协议

 中间件 SAF:服务框架,SOA之基石 JMQ:消息队列,the Datacenter Pipes!

 弹性计算 JDOS:软件定义计算单元(VM & Container)+ 软件定义网络(自 研SDN)+ 软件定义存储(JFS & JimDB)= 软件定义数据中心 CAP: 弹性调度平台

www.jd.com



第41页

谢谢!

www.jd.com



袁航@JIMDB团队 系统技术部@云平台



支持文件格式:*.pdf
上传最后阶段需要进行在线转换,可能需要1~2分钟,请耐心等待。