京东JIMDB（Jingdong In Memory DataBase，京东内存数据库）

特性、应用有点乱，了解下有什么功能，用于解决什么问题的就行

由来：

当一个网页被打开时，为了提供良好的用户体验，提高用户购买的转化率，往往一个纯静态的页面已无法满足业务的需要，后台会有几十上百个服务为这个页面提供动态的个性化的数据。比如根据用户过往的购买记录和上网的浏览信息帮他推荐感兴趣的商品，告诉用户这些商品购买比例如何，好评度怎么样，什么时间段可以送货到家，这个商品有没有促销，能不能用券，如果缺货需要提醒用户这个商品当前是预定状态，还有很多就不一一列举，这么多的服务需要调用，而且要在每秒成千上万次请求的情况下，毫秒级将结果展示在用户的显示屏中，除了良好的架构方案，缓存的极致使用是必不可少的。

缓存的规模越来越大，线上故障变得频繁起来，同时客户端实例数也在增加。一个具有以下能力的缓存平台对业务来说是非常需要的：

能够自动进行故障恢复（不用半夜人工介入手动重启配置）、可以在线扩容（不用停止服务重新部署）、自动负载均衡等，而且这些过程完全可以在客户端无感知的情况下完成。

 

JIMDB是Jingdong In Memory DataBase（京东内存数据库）的缩写，是对原生redis(2.8)的集群化方案；

特性总结A：

1、支持无缝自动伸缩

•  能够根据业务对集群的访问情况自动将集群调整到一个合适的规模

 2、自动故障检测、恢复

• 支持分片级别的并行故障恢复，大幅提升故障恢复速度

3、保证数据的高可靠性

• 支持跨机房热备
• 具有持久化机制

4、丰富的读策略配置

• 支持机房就近访问
• 支持不同客户端读不同的从组
• 支持多种读策略

5、防止集群间相互干扰

• 支持物理分区
• 提供实例级别的限速功能

6、丰富的自动化运维支持

• server自升级
• 自扩容
• 故障自恢复

7、支持多种复制方案

• 全量复制

 

发展阶段

　　阶段1、JIMDB 1.0

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

　　阶段2、JIMDB 2.0

　　功能包括：故障检测和自动切换；平滑纵向扩容和平滑横向扩容；基于内存+SSD的两级存储结构和自主研发存储引擎。

　　阶段3、JIMDB 3.0

　　包括了：自助接入和自动部署；容器化；全自动弹性调度。

 

特性总结B：

　　1、支持大容量缓存

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

　　2、数据的高可用性

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

　　3、支持多种I/O策略

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

　　4、哨兵服务和故障自动切换

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

　　5、支持动态扩容

　　可通过多种途径实现动态扩容：

　　第一种形式，通过在单个节点上预留内存，然后需要扩容时直接使用预留内存的方法达到扩容的目的。

　　第二种形式，通过数据迁移来实现扩容。(平滑纵向扩容)

　　第三种形式，通过增加分片数来实现扩容。(平滑横向扩容)

 

应用：

　　1、数据查询和维护

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

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

　    2、监控与报警

　　Pains（痛点）

　　例如：网络不佳的情况下可能发生误判； Redis单线程执行，在进行长任务时可能发生误判。

　　Solution（解决方案）

　　比如：在机房中不同区域部署多个Failure Detector；多个Failure Detector之间采用分布式选举算法，判断Redis实例的死活；连接健康度不佳时， 验证端口是否通畅。

　　3、迁移与扩容

　　Scaling Up – 纵向扩容

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

　　其次，纵向扩容时如果Redis实例所在计算机物理内存不够，就需要进行数据迁移。

　　再就是，数据迁移的同时，服务不能暂停

　　Scaling Out – 横向扩容

　　首先，单一分片的内存是不能无限扩容(纵向)的， 太大了会影响复制的效率；其次，在纵向扩容无法进行的情况下(单一分片内存已经很大，或者流量压力很大)，就需要进行横向扩容，即增加集群的分片数。再有，横向扩容的同时，服务不能暂停。

纵向扩容

　　横向扩容

　　Pains（痛点）

　　首先，纵向扩容并不增加分片数，简单修改JIMDB实例运行时参数可提高该实例可用内存上限，但在机器内存吃紧时，若要提高该分片内存上限，需要将该实例平滑迁移至一台内存资源更加充沛的机器。

　　其次，流量打满或者出现热点时， 需要加分片分散压力。 机器内存不够时， 有时也需要加分片

　　再次，Pre-sharding的方式， 在不影响服务的情况下增加分片有难度。

　　还有，可以通过定制开发引入bucket来进行横向扩容， 但线上还有2.4， 2.6， 2.8等既有版本，也有加分片的需求。

　　再有，避免主从数据不一致。

　　最后，服务不能暂停，平滑不影响业务。

　　Solution（解决方案）

　　首先，通过Filtered replication， 实现某个结点的分裂(split)

　　其次，开发一个支持Hold和Split的Proxy, 并通过一个流程控制器来协调客户端，服务结点，Proxy， 等相关各方。

　　横向扩容

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

　　4、冷热数据及二级存储

　　Pains

　　比如，Redis完全依赖于内存，往往内存不够使用；Redis启动时需要把全部数据加载到内存,在数据量大时启动速度慢； 规划总是赶不上业务发展， 内存总量不断被突破， 不断陷入扩容， 再扩容…的梦魇。

　　Solution

　　引入RAM + SSD两级存储，在内存中存储热点数据， 冷数据被自动交换到磁盘，解决了内存不足的问题；启动时并不把所有数据加载入内存，而是在运行时根据需要加载，解决了启动速度慢的问题； 因为引入了二级存储， 存储容量通常比较大， 所以不需要频繁的扩容了。

 

适用场景：

适合于所有需要加速的场景

 

转载自：

https://blog.csdn.net/MonkeyITBoy/article/details/80495831

https://www.sohu.com/a/123224661_494947