Redis的字典扩容与ConcurrentHashMap的扩容策略比较

本文介绍Redis的字典(是种Map)扩容与ConcurrentHashMap的扩容策略,并比较它们的优缺点。

(不讨论它们的实现细节)

首先Redis的字典采用的是一种‘’单线程渐进式rehash‘’,这里的单线程是指只有一个线程在扩容,

而在扩容的同时其他的线程可以并发的进行读写。

Redis系统后台会定时给予扩容的那个线程足够的运行时间,这样不会导致它饿死。

大致过程是这样的:

ht[0],是存放数据的table,作为非扩容时容器。

ht[1],只有正在进行扩容时才会使用,它也是存放数据的table,长度为ht[0]的两倍。

扩容时,单线程A负责把数据从ht[0] copy到ht[1] 中。如果这时有其他线程

进行读操作:会先去ht[0]中找,找不到再去ht[1]中找。

进行写操作:直接写在ht[1]中。

进行删除操作:与读类似。

当然这过程中会设计到一系列的锁来保证同步性,不过这并不是本文的重点。

而ConcurrentHashMap采用的扩容策略为: "多线程协同式rehash"。

这里的多线程指的是,有多个线程并发的把数据从旧的容器搬运到新的容器中。

扩容时大致过程如下:

线程A在扩容把数据从oldTable搬到到newTable,这时其他线程

进行get操作:这个线程知道数据存放在oldTable或是newTable中,直接取即可。

进行写操作:如果要写的桶位,已经被线程A搬运到了newTable。

那么这个线程知道正在扩容,它也一起帮着扩容,扩容完成后才进行put操作。

进行删除操作:与写一致。

两者对比:

1.扩容所花费的时间对比:

一个单线程渐进扩容,一个多线程协同扩容。在平均的情况下,是ConcurrentHashMap快。这也意味着,扩容时所需要

花费的空间能够更快的进行释放。

2.读操作,两者的性能相差不多。

3.写操作,Redis的字典返回更快些,因为它不像ConcurrentHashMap那样去帮着扩容(当要写的桶位已经搬到了newTable时),等扩容完才能进行操作。

4.删除操作,与写一样。

所以是选择单线程渐进式扩容还是选择多线程协同式扩容,这个就具体问题具体分析了。

1.如果内存资源吃紧,希望能够进行快速的扩容方便释放扩容时需要的辅助空间,且那么选择后者。

2.如果对于写和删除操作要求迅速,那么可以选择前者。

个人觉得ConcurrentHashMap的扩容策略更让人惊艳,效果也不错。

本文转自:http://blog.csdn.net/jiji1995/article/details/64127460

原文地址:https://www.cnblogs.com/nizuimeiabc1/p/8353612.html

时间: 2024-10-12 08:01:22

Redis的字典扩容与ConcurrentHashMap的扩容策略比较的相关文章

基于twemproxy和vip实现redis集群的无感知弹性扩容

目标是实现redis集群的无感知弹性扩容 关键点 1.是无感知,即对redis集群的用户来说服务ip和port保持不变 2.弹性扩容,指的是在需要时刻可以按照业务扩大redis存储容量. 1.业务场景 1.redis集群某个业务容量不足,需要扩容 2.redis集群需要一个为一个新业务分配存储容量 3.redis集群在扩容的时候服务不是停止的,而是服务中,即无感知 最好的解决方式 对客户端无感知,即客户端不需要任何操作就实现了redis集群的扩容 2.最朴素的twemproxy+redis集群架

[转载]RAID磁盘阵列扩容 DELL 服务器阵列扩容&nbs

原文地址:RAID磁盘阵列扩容 DELL 服务器阵列扩容 和 RAID 级别迁移 (RLM)作者:DELL服务器 我们可通过扩充容量和 / 或改变 RAID 级别的方式来重新配置联机虚拟磁盘. 注: 跨接式虚拟磁盘 (如 RAID 10. 50 和 60)无法重新配置. 注: 重新配置虚拟磁盘时一般会对磁盘性能有所影响,直到重新配置完成后为止. 联机容量扩充 (OCE) 可通过两种方法实现. 如果磁盘组中只有一个虚拟磁盘,而且还有可用空间可供使用,则可在可用空间的范围内扩充虚拟磁盘的容量. 如果

Redis的字典(dict)rehash过程源码解析

Redis的内存存储结构是个大的字典存储,也就是我们通常说的哈希表.Redis小到可以存储几万记录的CACHE,大到可以存储几千万甚至上亿的记录(看内存而定),这充分说明Redis作为缓冲的强大.Redis的核心数据结构就是字典(dict),dict在数据量不断增大的过程中,会遇到HASH(key)碰撞的问题,如果DICT不够大,碰撞的概率增大,这样单个hash 桶存储的元素会越来愈多,查询效率就会变慢.如果数据量从几千万变成几万,不断减小的过程,DICT内存却会造成不必要的浪费.Redis的d

Redis基本数据类型、数据持久化、过期策略及淘汰机制

一点技术.技术乐享!!! 如果有人问你:Redis这么快,他的“多线程模式”你了解吗? 请回答他:您是想问Redis这么快,为什么还是单线程模式吗? redis是什么 简单来说redis是C语言开发的一个开源的(遵从BSD协议)高性能键值对(key-value)的内存数据库,可以用作数据库.缓存.消息中间件等. 性能优秀,数据在内存中,读写速度非常快,支持并发10W QPS. 单进程单线程,是线程安全的,采用Io多路复用机制. 丰富的数据类型,支持字符串(string).散列(hash).列表(

HashMap的扩容机制, ConcurrentHashMap和Hashtable主要区别

源代码查看,有三个常量, static final int DEFAULT_INITIAL_CAPACITY = 16; static final int MAXIMUM_CAPACITY = 1 << 30; static final float DEFAULT_LOAD_FACTOR = 0.75f; 三个常量中可以看出,默认的容器大小是16,最大长度是2的30次方,load factor默认是0.75,扩充的临界值是16*0.75=12 当我们往HashMap中put元素的时候,先根据k

Redis的字典(dict)rehash过程源代码解析

Redis的内存存储结构是个大的字典存储,也就是我们通常说的哈希表.Redis小到能够存储几万记录的CACHE,大到能够存储几千万甚至上亿的记录(看内存而定),这充分说明Redis作为缓冲的强大.Redis的核心数据结构就是字典(dict),dict在数据量不断增大的过程中.会遇到HASH(key)碰撞的问题,假设DICT不够大,碰撞的概率增大,这样单个hash 桶存储的元素会越来愈多,查询效率就会变慢.假设数据量从几千万变成几万,不断减小的过程.DICT内存却会造成不必要的浪费.Redis的d

lvm 通过扩容本身磁盘容量扩容

场景:sdb之前是3G容量,现在扩容了sdb的容量到8G.现在把新扩容的5G容量扩展到现有的逻辑卷中 [[email protected] ~]# pvresize /dev/sdb  Physical volume "/dev/sdb" changed  1 physical volume(s) resized / 0 physical volume(s) not resized [[email protected] ~]# pvdisplay   --- Physical volu

redis学习-字典

1.字典作用 实现数据库键空间(key space): 用作 Hash 类型键的底层实现之一: 2.字典实现的数据结构 typedef struct dict { // 特定于类型的处理函数 dictType *type; // 类型处理函数的私有数据 void *privdata; // 哈希表(2 个) dictht ht[2]; // 记录 rehash 进度的标志,值为 -1 表示 rehash 未进行 int rehashidx; // 当前正在运作的安全迭代器数量 int itera

还不懂 ConcurrentHashMap ?这份源码分析了解一下

上一篇文章介绍了 HashMap 源码,反响不错,也有很多同学发表了自己的观点,这次又来了,这次是 ConcurrentHashMap 了,作为线程安全的HashMap ,它的使用频率也是很高.那么它的存储结构和实现原理是怎么样的呢? 1. ConcurrentHashMap 1.7 1. 存储结构 Java 7 中 ConcurrentHashMap 的存储结构如上图,ConcurrnetHashMap 由很多个 Segment 组合,而每一个 Segment 是一个类似于 HashMap 的