JD的JIMDB教程

最新推荐文章于 2024-07-02 17:50:11 发布
最新推荐文章于 2024-07-02 17:50:11 发布
阅读量7.6k 收藏 9
点赞数 3
分类专栏： 企业型开发
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/MonkeyITBoy/article/details/80495831
版权

                                                                                                JimDB                                                                                                                                                                

简介

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

1、支持无缝自动伸缩

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

 2、自动故障检测、恢复

  • 支持分片级别的并行故障恢复，大幅提升故障恢复速度
3、保证数据的高可靠性
  • 支持跨机房热备
  • 具有持久化机制
4、丰富的读策略配置
  • 支持机房就近访问
  • 支持不同客户端读不同的从组
  • 支持多种读策略
5、防止集群间相互干扰
  • 支持物理分区
  • 提供实例级别的限速功能
6、丰富的自动化运维支持
  • server自升级
  • 自扩容
  • 故障自恢复
7、支持多种复制方案
  • 全量复制

寻根问源：什么是JIMDB?

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

　　JIMDB发展历程主要有三个阶段

　　阶段1、JIMDB 1.0

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

　　阶段2、JIMDB 2.0

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

　　阶段3、JIMDB 3.0

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

　　JIMDB功能特性

　　1、支持大容量缓存

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

　　2、数据的高可用性

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

　　3、支持多种I/O策略

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

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

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

　　5、支持动态扩容

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

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

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

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




IMDB技术的应用体现在：

　　1、数据查询和维护

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

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

　    2、监控与报警

　　Pains（痛点）

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

　　Solution（解决方案）

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

　　3、迁移与扩容

　　Scaling Up – 纵向扩容

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

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

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

　　Scaling Out – 横向扩容

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

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

纵向扩容

　　横向扩容

　　Pains（痛点）

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

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

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

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

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

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

　　Solution（解决方案）

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

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

　　横向扩容

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

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

　　4、冷热数据及二级存储

　　Pains

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

　　Solution

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

　　京东私有云技术体系包括：

　　1、存储

　　JFS：京东文件系统，提供统一的文件/对象/块存储服务

　　JIMDB：京东分布式缓存与高速KV存储，兼容Redis协议

　　2、中间件

　　SAF：服务框架，SOA之基石

　　JMQ：消息队列，The Datacenter Pipes!

　　3、弹性计算

　　JDOS：软件定义数据中心 = 软件定义计算单元(VM & Container)+ 软件定义网络(自研SDN)+ 软件定义存储(JFS & JIMDB)。

　　CAP: 弹性计算云 = 软件定义数据中心 + 自动化容器集群调度。

 



适用场景

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

系统架构

系统的基础架构图如下：

 

1.4.5相比1.4.4在API上没有变化，其Changelog为:

  • 支持jimUrl形式配置
  • 支持自动扩容
  • 通过com.jd.jim.cli.compat.ReloadableJimClientFactoryBean兼容configId+token配置形式


其中，超时时间、连接池以及读写分离的情形可以通过点击以下界面按钮自行设置：



公共测试环境：

1.4.5客户端除支持configId和token的配置方式外，还支持jimUrl的简化配置方式，在测试机上配置hosts：192.168.150.61 cfs.jim.jd.local，以下测试环境的jimUrl可任选其一来用：

 

1

jim://1803528818953446384/1

2

jim://1803528671997086613/2

3jim://2809907038999011671/4
4jim://2809907022807591111/5

  如果不喜欢上面这种方式，可继续按照老的configId+token的方式使用以前提供的测试环境（公用configId和token现有8个）。

自已可控的专有测试环境：

第一步:    jim://2870414099454224775/3

第二步:   配置host

192.168.150.61 cfs.jim.jd.local

<redis实例所在的IP> redis.local

第三步：部署redis实例:

  1.  最新版本（055e848cb62e1f4dac31a542d0e67688  jimdb-3.2.24.tgz ）
    执行步骤如下：

    mkdir -p /export/Data/redis_data/6379
    mkdir -p /export/Logs/redis/
    mkdir -p /export/servers/
    tar -zxvf jimdb-3.2.24.tgz -C  /export/servers
    nohup /export/servers/jimdb-3.2.24/src/redis-server /export/servers/jimdb-3.2.24/conf/redis_6379.conf &

  2. 在部署服务器通过redis-cli 连接redis实例
    /export/servers/jimdb-3.2.24/src/redis-cli  -h <redis实例所在的IP>  -p   <redis实例端口> 

生产环境：

 生产环境的jimUrl（或configId、token），在垂直运维处理完你的集群申请后，系统会发送邮件通知。


客户端使用配置：建议直接demo下载

(JimDB client 1.4.5 demo下载 兼容老的配置风格)

 

 

通过maven引入jar包
  
<dependency>
    <groupId>com.jd.jim.cli</groupId>
    <artifactId>jim-cli-jedis</artifactId>
    <version>1.4.5-SNAPSHOT</version>
</dependency>
<dependency>
    <groupId>com.jd.jim.cli</groupId>
    <artifactId>jim-cli-api</artifactId>
    <version>1.4.5-SNAPSHOT</version>
</dependency>

 

 

 

 

 

 

 

jimUrl风格配置形式

 

 

Spring环境下配置使用：

注意：在系统退出时，要确保销毁spring容器上下文

project/src/main/resources/spring-conf.xml 
<bean id="jimClient" class="com.jd.jim.cli.ReloadableJimClientFactoryBean">
    <property name="jimUrl" value="jim://1803528671997086613/2" />
</bean>
java代码： 
@Resource(name = "jimClient")
private Cluster jimClient;
 
public String getByKey(String key){
    return jimClient.get(key);
}

 

 

非Spring环境配置使用：
注意：在系统退出时，调用ReloadableJimClientFactory的clear()方法。 
package com.jd.jim.cli.demo;

import com.jd.jim.cli.Cluster;
import com.jd.jim.cli.ReloadableJimClientFactory;


public class JimClientDemo {
    public void close() {
        JimClientFactory.close();
    }

    public String getByKey(String key) {
        return JimClientFactory.getJimClient().get(key);
    }

    private static class JimClientFactory {
        private static final ReloadableJimClientFactory clientFactory;                                                                  
        private static final Cluster CLIENT_INSTANCE;

        static {
            clientFactory = new ReloadableJimClientFactory();
            clientFactory.setJimUrl("jim://1803528671997086613/2");

            CLIENT_INSTANCE = clientFactory.getClient();
        }

        public static Cluster getJimClient() {
            return CLIENT_INSTANCE;
        }

        public static void close() {
            if (clientFactory != null) {
                clientFactory.clear();
            }
        }
    }
}

 

 

Spring Cache注解方式：

spring-conf.xml

 
<bean id="configClient" class="com.jd.jim.cli.config.client.ConfigLongPollingClientFactoryBean">
    <property name="serviceEndpoint" value="http://cfs.jim.jd.local"></property>
</bean>

<bean id="jimClient" class="com.jd.jim.cli.ReloadableJimClientFactoryBean">
    <property name="configClient" ref="configClient"></property><!-- configured to your needs -->
    <property name="jimUrl" value="jim://1803528818953446384/1" />
</bean>

<bean id="cacheManager" class="com.jd.jim.cli.springcache.JimCacheManager">
    <property name="caches">
        <list>
            <bean class="com.jd.jim.cli.springcache.JimStringCache">
                <!-- key前缀 -->
                <property name="keyPrefix" value="cachetest_" />
                <!-- 客户端对象 -->
                <property name="jimClient" ref="jimClient" />
                <!-- TTL时间(以'秒'为单位) -->
                <property name="entryTimeout" value="60" />
                <!-- 值的序列化器 -->
                <property name="valueSerializer">
                    <bean class="com.jd.jim.cli.serializer.DefaultStringSerializer" />
                </property>
            </bean>
        </list>
    </property>
</bean>

<cache:annotation-driven cache-manager="cacheManager" />

 
 

java代码：

 
@Cacheable(value = "cachetest_", key = "#key")
public String getMessage(String key) {
    System.out.println("miss, get from db...");
    return "msg";
}

@CachePut(value = "cachetest_", key = "#key")
public String setMessage(String key, String message) {
    return message;
}

@Caching(evict = { @CacheEvict(value = "cachetest_", key = "#key") })
public boolean delete(String key) {
    return true;
}

 

 

 

 

 

 

 

 

 

 
1.4.5新旧机房相同配置方式说明：
兼容旧的配置方式

(访问新旧机房配置方式都相同)

相同的com.jd.jim.cli.compat.ReloadableJimClientFactoryBean，相同的工厂com.jd.jim.cli.compat.ReloadableJimClientFactory，相同的配置项configId、token，相同的api。

 

Spring环境下配置使用：
<bean id="objectSerializer" class="com.jd.jim.cli.demo.CustomObjectSerializer">
    <property name="enableCompress" value="false"></property><!-- 关闭byte[]类型的value压缩,如果无特殊需求不要这个bean也行 -->
</bean>

<!-- 黄村 -->
<bean id="jimClientHC" class="com.jd.jim.cli.compat.ReloadableJimClientFactoryBean">
    <!-- <property name="objectSerializer" ref="objectSerializer" /> -->
    <property name="configId" value="/redis/cluster/19" />
    <property name="token" value="1417632068813" />
</bean>

<!-- 廊坊 -->
<bean id="jimClientLF" class="com.jd.jim.cli.compat.ReloadableJimClientFactoryBean">
    <!-- <property name="objectSerializer" ref="objectSerializer" /> -->
    <property name="configId" value="jim://1803528671997086613/2" />
    <property name="token" value="jim://1803528671997086613/2" />
</bean>  

 

 

 

非Spring环境配置使用：
package com.jd.jim.cli.demo;

import com.jd.jim.cli.Cluster;
import com.jd.jim.cli.compat.ReloadableJimClientFactory;


public class JimClientDemo {
    public void close() {
        JimClientFactory.close();
    }

    public String getByKey(String key) {
        return JimClientFactory.getJimClient().get(key);
    }

    private static class JimClientFactory {
        private static final ReloadableJimClientFactory clientFactory;
        private static final Cluster CLIENT_INSTANCE;

        static {
            clientFactory = new ReloadableJimClientFactory();
            clientFactory.setConfigId("jim://1803528671997086613/2");                                                                  
            clientFactory.setToken("jim://1803528671997086613/2");
            CLIENT_INSTANCE = clientFactory.getClient();
        }

        public static Cluster getJimClient() {
            return CLIENT_INSTANCE;
        }

        public static void close() {
            if (clientFactory != null) {
                clientFactory.clear();
            }
        }
    }
}

 

                                                                   Jimdb S功能特性                                   

   

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         

   
                      
   
       
  •                            

                   

  •                        

                      

  •                    
            
                       
                          

Jimdb S是一个完全兼容redis协议的大容量高速NoSQL数据库，存储大容量数据的同时提供高性能和低延迟, 用SSD持久化数据。使用Jimdb S以后可以保存全量数据，把缓存+数据库的两层架构用一层架构取代，提供更低的延迟，同时简化应用逻辑，不需要再关心缓存更新和失效的问题，避免数据不一致的风险。

 

主要特性：

1） 可靠性：
Jimdb S可以保证即使操作系统崩溃或断电的情况下，最多丢失30毫秒内写入的数据。

如果配置了主从复制，可以用同步命令的方式保证数据写入多个副本后才返回成功，保证成功写入的数据即使发生意外也不会丢失。

 

2）可扩展性：

Jimdb S支持平滑的迁移和扩展，可以通过增加分片承担更大的访问压力和更大的数据容量，理论上单集群可以支持上百TB的数据。

 

3）单实例读性能：
Jimdb S的读可以分为两种情况：

A，数据在内存命中；

B，数据磁盘文件中，需要硬盘IO。

A的性能和原生redis是相同的，ops可以达到十万以上，延迟低于1ms。B 的延迟基本在2ms - 20ms之间，大多数情况下小于10ms，并发越多，延迟会越高，总的ops在3万左右。

所以实际应用场景的读性能取决于读请求中属于A, B 两种情况的比例。热点数据越集中，性能越好。

 

4）单实例写性能：
Jimdb S的写性能在value 1KB的情况下tps可以达到3万左右，延迟小于1ms。读写混合时，读IO（前面提到的B情况下）和写IO之和在3万左右。

 

5）范围查询功能：
Jimdb S提供一个范围查询命令，可以以字典序查询指定范围内的key，格式如下：

JRANGE [{start} ({end} LIMIT <offset> <limit>

其中’[’代表开区间，’(‘代表闭区间，LIMIT是可选项，后面跟两个参数。

 

JRANGE [key001 (key005

会返回 key001, key002, key003, key004;

JRANGE [key001 (key005 LIMIT 1 2

会返回 key002, key003。

 

6）主从复制:
Jimdb S的复制采用与redis兼容的rdb模式，这种方式兼容性最好，缺点是速度比较慢，100G的数据可能需要几十分钟才能复制完成。

 

7）启动时间:

redis如果配置了持久化，启动时会把所有数据从硬盘载入内存，如果数据量大，会需要几十秒到几分钟的时间，而Jimdb S启动时先从索引文件中载入索引，通常索引文件远小于数据文件，因而加快了启动速度，如果索引没有保存才会从数据文件中读取数据创建索引。

 

8）数据统计:

Jimdb S除了支持redis已有的统计数据之外，还添加了网络流量统计和延迟统计，在客户端遇到高延迟的问题时，更容易定位问题的原因。

 

注意事项：

1） Jimdb S目前不支持大数据结构，最大限制为1024，如果元素个数超过这个值，性能会有下降。建议将这部分数据分离出来单独存储。

2） Jimdb S单实例的数据大小最好不要超过100GB，太大的实例会导致主从复制的时间太长。

3） Jimdb S会将全量索引保存在内存中，如果数据的value都很小，则需要比较多的内存。

 

设计和实现:

 

1）写入逻辑：

当Jimdb S在内存里完成写操作时，不会立即执行写cycledb操作，而是把修改过的key放入dirtyKeys map里，在每30毫秒执行的时间任务里，把脏数据写入cycledb。

在前台执行写入cycledb时，会在内存中更新索引和元数据，然后再触发一次磁盘文件的顺序写，性能很高。数据会在30毫秒的周期内持久化在硬盘上，即使系统崩溃，最多丢失30毫秒的数据。

redis的数据结构类型有5种，string/list/hash/set/zset，在Jimdb S里，这5种类型在写入cycledb时会统一用序列化rdb的方式生成一个string，默认使用redis自带的LZF的压缩算法进行压缩，LZF是一种高速的压缩算法，即使数据是已经压缩过的，再压缩一遍开销也是很低的。

 

2）内存硬盘数据交换逻辑：

当Jimdb S接收到一个请求时，首先需要算出这个命令里涉及到的key有哪些，在执行这个命令之前，我们需要保证这些key都已经载入内存，Jimdb S会在内存里查找这些key,如果这些key在内存里都有，那就会立即执行这个命令，如果有的key在内存找不到，就需要查询cycledb，并把cycledb里的数据载入内存，这个函数名loadKeyValues。

如果我们在主线程执行读cycledb的命令，那么主线程很可能会阻塞几毫秒，因为redis是单线程模型，这会严重影响性能，所以读取cycledb的操作需要在后台线程完成。而直接把后台读取cycledb得到的数据载入内存会带来一个问题，就是数据不一致，有可能导致旧数据覆盖新数据。Jimdb S的解决方案是, 第一次执行loadKeyValues的时候，遇到需要读取cycledb的时候，创建后台任务读取cycledb， 这个后台任务的作用实际上并不是读取，而是预热，读到数据后并不把结果载入内存，执行完成后，前台主线程会重新执行一次loadKeyValues，这次直接在前台读取cycledb并载入内存，因为这个key刚刚被读取过一次，所以一定会被操作系统缓存，第二次读不会有硬盘IO，所以不会阻塞，操作瞬间完成。

当Jimdb S的内存达到配置的maxmemory时，会用随机的lru算法淘汰内存里较久没有访问过的key，保证内存使用量在maxmemory之内，因为数据在硬盘上全量保存，所以即使key被淘汰，数据也不会丢失。

 

3）主从复制逻辑：

原生redis在复制时需要fork一个后台进程dump RDB文件，如果没有设置overcommit_memory，有可能会fork失败。而Jimdb S完全不需要fork后台进程，所有操作都在一个进程内完成，通过后台线程生成数据快照。

当Jimdb S接收到从发来的复制请求时，会启动后台线程遍历cycledb里的数据，保存在一个rdb文件里，这个过程消耗的时间跟数据文件中的数据量有关，数据量越大耗时会越久，完成之后，Jimdb S会把这个rdb文件发送给从，传输的速度会受到网卡和硬盘读写速度的限制。当Jimdb S作为从接收到rdb文件后会读取并载入内存，并持续地把新写入的脏数据写入cycledb，这个过程也会消耗很长时间。

由于一个Jimdb S实例会保存几十G到上百G的数据，主从全量复制的代价很高，如果一块硬盘上多个实例同时复制，很可能导致硬盘写满，或者占用大量网卡带宽，所以jimdb加入了全量复制锁save-lock，在同一台主机上，同一时间只有一个实例会保存快照，如果多个实例同时接受到从发来的全量同步请求，只有获取文件锁的那个实例才会执行复制操作，其他的实例会定期重试。

 

未来的开发计划：

1） 智能动态的调整内部参数配置，减少需要人工调整的配置项，预防配置失误的风险。

2） 支持多种存储引擎。

 

           

 

MonkeyITBoy
关注
专栏目录
代码精简执行过程
京东科技开发者
03-13 629
因此定期进行代码缩减，清理腐化的代码，对代码进行优化升级，提升代码工程的可维护性与可理解性，是十分有必要的。重复代码检查，使用CPD检查重复超过**行的代码，检查结果作为一个参考，帮助我们找到代码库中疑似重复的代码，然后通过人工甄别，判断该重复代码是否可以进一步抽象，抽象成公共的方法，供多处调用。•jdo-***，线上工程，代码行数20005，通过pmd检查后，可删除400行左右（包括未使用的私有方法，未使用的私有变量、重复引入、无效引用、未使用的本地变量），占比2%左右。
chatglm2-6b模型在9n-triton中部署并集成至langchain实践 | 京东云技术团队
JDDTechTalk的博客
08-16 1053
本文将介绍我利用集团9n-triton工具部署ChatGLM2-6B过程中踩过的一些坑，希望可以为有部署需求的同学提供一些帮助。
分布式锁的详细解析
最新发布
夜尽天明
07-02 1033
当前问题：项目中会使用到分布式锁用于定时任务、接口幂等性处理，但是分布式锁的实现较简单，会出现执行超时、加解锁失败等场景。分布式锁都有哪些实现，他们的优劣势是什么呢？
代码精简的治理方案和工具
京东科技开发者
03-19 674
在大型软件系统中，随着业务的发展和变迁，部分代码线上已经废弃或者出现冗余，由于种种原因没有被及时删除和治理，随之而来的是代码维护成本提升。代码精简的价值如上图所示，并由此成为服务治理的一个重要方向，在业界头部企业也有对应的治理项目谷歌【死神】项目，用机器人大规模删除代码：二十多年积累了数十亿行，已删除 5%C++ 代码, 其主要思路是通过程序自动识别代码否正在运行，并将识别结果和原因提交给工程师处理。
京东JIMDB（Jingdong In Memory DataBase，京东内存数据库）
qqq2018的博客
11-11 3559
特性、应用有点乱，了解下有什么功能，用于解决什么问题的就行 由来： 当一个网页被打开时，为了提供良好的用户体验，提高用户购买的转化率，往往一个纯静态的页面已无法满足业务的需要，后台会有几十上百个服务为这个页面提供动态的个性化的数据。比如根据用户过往的购买记录和上网的浏览信息帮他推荐感兴趣的商品，告诉用户这些商品购买比例如何，好评度怎么样，什么时间段可以送货到家，这个商品有没有促销，能不能用券，如果缺货需要提醒用户这个商品当前是预定状态，还有很多就不一一列举，这么多的服务需要调用，而且要在每秒成千上万次请
深入解读JIMDB—京东分布式缓存与高速KV存储(袁航演讲稿)
10-26
深入解读JIMDB—京东分布式缓存与高速KV存储(袁航演讲稿)
JIMDB基础知识
u012472945的博客
05-10 4506
项目简介1 项目背景1.1 当前缓存的使用现状及问题缓存云（统一Redis平台）来源于对缓存资源进行统一管理的需求，该需求最初从自动部署解决方案的讨论中衍生出来，解决运维的问题。目前，公司内部对缓存的使用存在如下问题和特点：各个项目组单独部署缓存系统，有些项目组资源利用率不高；各个项目组需要专人维护缓存系统的正常运行，这些人需要对缓存有很深的了解才能维护好这些系统；各个项目组对缓存的使用方式不尽相...
京东云缓存JIMDB建设之路
武汉红喜
01-13 2991
[京东技术]声明：本文转载自微信公众号“IPDCHAT”，转载务必声明。   缓存的大背景   缓存在软件应用特别是在互联网应用中无处不在，从数据库到应用服务、再到前端的页面每一层都会使用缓存进行加速，即使是硬件产品比如CPU、磁盘、网卡等也都会有相应的缓存或缓冲区。   当一个网页被打开时，为了提供良好的用户体验，提高用户购买的转化率，往往一个纯静态的页面已无
深入解读JIMDB—京东分布式缓存与高速KV存储
chengying332
04-24 2776
深入解读JIMDB—京东分布式缓存与高速KV存储 京东作为中国电子商务领域的重要一员，已经被广为熟知。但是，京东也是不折不扣的技术型公司，通过技术为用户带来便捷用户体验。例如，针对电商业务中海量小文件、大文件等数据分布式存储与管理的实际需求，京东从2013年7月开始着手自主研发分布式文件系统JFS，以及分布式的缓存与高速键值存储服务JI... 详细解读 和小伙伴们一起来吐槽
JIMDB数据持久化实践
weixin_33841503的博客
08-26 170
2019独角兽企业重金招聘Python工程师标准>>> ...
京东分布式K-V存储设计与挑战.pdf
10-14
京东的分布式K-V存储系统主要由两个核心组件构成，即非持久化存储JIMDB和持久化存储FBASE。这两个系统针对不同的应用场景和需求进行了优化。 JIMDB是一款兼容Redis协议的内存型K-V存储系统，其设计目标是实现在线...
对开发来讲，业务重要还是技术重要？
热门推荐
安晓辉生涯——聚焦程序员的职业规划与成长
01-11 1万+
很多开发者为天天写业务代码无暇提升技术而焦虑、苦恼，比如： 又如： 又如： 再如： 那么，作为开发者，到底该怎么面对“写业务代码”这件事呢？ 今天我们就从以下几个方面聊聊这个话题： 什么是业务 业务和技术的关系 业务和因解决业务而衍生的业务 对业务的态度因你在团队中的角色而不同 如何从写业务代码中跳出来，做你所谓的有技术含量的工作 我们先来看看，什么是业务。
JIMDB 大KEY治理
一条大河
01-09 629
Redis大KEY 治理
前端本地存储的 cookie 和 localstorage 的对比
桃子阿桃
09-29 1170
传统 cookie session H5 的本地存储: localstorage 和 sessionstorage cookie: http 无状态 不持久 前端和后端进行数据交互的时候, 是用 http 请求, 但是 http 是一种无状态的协议, 无状态的意思就是收到一个请求, 返回一个相应, 而不关心请求者的身份. http 也不是一种持久性的链接, 对于请求来说, 记住某用户的身份比较困难. 然后就出现了 cookie, 就是为了在用户端保存用户身份, 浏览器会在操作系统里开辟一个文件, 专门存放
Local Storage JavaScript库 - 简化Web应用程序的本地存储
gitblog_00007的博客
03-06 349
Local Storage JavaScript库 - 简化Web应用程序的本地存储 本文将向您介绍一个非常有用的JavaScript库 - local-storage-js。它可以帮助您轻松地处理Web应用程序的本地数据存储。 什么是Local Storage JavaScript库？ local-storage-js是一个轻量级的JavaScript库，它提供了一个简单易用的API来操作浏览...
【JavaScript】数据存储 Storage（session、local）
懂得一千零一种,赋予你失败的方法！
05-20 2909
文章目录Storage一、sessionStorage作用函数作用的范围二、localStorage Storage 一、sessionStorage 作用 1.浏览器彻底关闭才会销毁 2.临时的数据共享 （登陆状态） 3.键值对形式存储 函数 setItem() 设置 getItem() 获取 removeItem() 删除 clear() 清空 作用的范围 只要当前会话不关闭，sessionStorage就不会消失； 当前会话的跳转、刷新均存在； 一旦新建会话全部消失！！！ .
web浏览器数据本地存储
厚渡
08-21 5867
在浏览器中存储主要分为以下三种方式 localstorage 2、sessionStorage 3、cookie localStorage 生命周期永久，除非用户清除浏览器中的localStorage信息，否则永远存在； 存放数据大小一般为5MB； 仅在浏览器中保存，不参与服务器通信； API调用： localStorage.setItem("key","value");//以“key”为名称存储一个值“value” localStorage.getItem("key");//获取名称为“ke
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值