日前可比盛行的缓存本领确实是Memcached和Redis,Redis提供了八种数据构造

图片 5

Redis之所以执行速度很快,主要依赖于以下几个原因:

从图中可以看到,每种数据结构其底层实现都有2种或3种编码实现,这样设计有以下好处:

不同之处:

(二)单线程操作,避免了不必要的上下文切换和竞争条件,也不存在多进程或者多线程导致的切换而消耗
CPU,不用去考虑各种锁的问题,不存在加锁释放锁操作,没有因为可能出现死锁而导致的性能消耗;

前言:最近实习工作比较忙,业余时间在看付磊的《Redis开发与运维》,并结合以前的学习总结,整理这一系列学习笔记,希望小伙伴能有所收益,感谢阅读~

Redis使用动态分配,由于C语言没有自带的GC,所以Redis的实现中封装了C的malloc,calloc,realloc和free函数来对自己的内存进行管理,这些实现都在zmalloc.h和zmalloc.c中。在Redis中,并不是所有的数据一直存储在内存中。当物理内存用完时,Redis可以将一些很久没用的Value交换到磁盘。Redis只会缓存所有的key,当Redis发现内存的使用量超过了一个阀值,将触发Swap操作,Redis根据“swappability

age*log(size_in_memory)”计算出哪些key对应的value需要swap到磁盘。然后再将这些key对应的value持久化到磁盘中,同时在内存中清除。这种特性使得Redis可以保持超过其机器本身内存大小的数据。当然,机器本身的内存必须要能够保持所有的key,毕竟这些数据是不会进行swap操作的。同时由于Redis将内存中的数据swap到磁盘中的时候,提供服务的主线程和进行swap操作的子线程会共享这部分内存,所以如果更新需要swap的数据,Redis将阻塞这个操作,直到子线程完成swap操作后才可以进行修改。当从Redis中读取数据的时候,如果读取的key对应的value不在内存中,那么Redis就需要从swap文件中加载相应数据,然后再返回给请求方。
这里就存在一个I/O线程池的问题。在默认的情况下,Redis会出现阻塞,即完成所有的swap文件加载后才会相应。这种策略在客户端的数量较小,进行批量操作的时候比较合适。但是如果将Redis应用在一个大型的网站应用程序中,这显然是无法满足大并发的情况的。所以Redis运行我们设置I/O线程池的大小,对需要从swap文件中加载相应数据的读取请求进行并发操作,减少阻塞的时间。

三、数据类型

    
Memcached仅支持简单的key-value结构的数据,Redis支持的数据类型要丰富得多。常用的由五种:String、Hash、List、Set和Sorted
Set。Redis内部使用一个redisObject对象来表示所有的key和value。

四:集群管理

    
Memcached本身并不支持分布式,只能在客户端通过一致性hash这样的分布式算法来实现Memcached的分布式存储。
Redis更偏向服务端构建分布式存储,Redis
Cluster是一个实现了分布式且允许单点故障的Redis高级版本,去中心化,具有线性可伸缩的功能。节点与节点之间通过二进制协议进行通信,节点与客户端之间通过ascii协议进行通信。在数据的放置策略上,Redis
Cluster将整个key的数值域分成4096个哈希槽,每个节点上可以存储一个或多个哈希槽,也就是说当前Redis
Cluster支持的最大节点数就是4096。Redis
Cluster使用的分布式算法也很简单:crc16( key ) % HASH_SLOTS_NUMBER。

五:数据持久化

    
Memcached不支持数据持久化。Redis支持两种数据持久化RDB快照和AOF日志。

     Redis
Cluster引入了master-slave模式,每一个master都对应两个slave节点。

 整体上说,两者的性能都很好,不必为哪个性能更高而纠结。不过,redis提供的持久化和数据同步机制,这些都是memcached没有的,所以如果你想要持久化,就只能用redis了。另外,memcached足以应付简单的键值存储,不过你要是想用更高级的数据结构,比如hash,list,set,zset之类的,redis提供了这些类型,用着更方便。 

灵活多样的数据结构。

2、I/O多路复用模型

通常来说,单线程的处理能力要比多线程差,那么为什么单线程的Redis仍然可以那么快呢?可以归结为以下几点:

  • 第一,纯内存访问,Redis将所有数据放在内存中,内存的响应时长大约为100纳秒,这是Redis达到每秒万级别访问的基础;

  • 第二,非阻塞I/0,Redis使用epoll作为I/O多路复用技术的实现,再加上Redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件,不在网络I/O上浪费过多的时间,见下图;

  • 第三,单线程避免了线程切换和竞态产生的消耗;

图片 1多路复用模型.png

             3.按照Growth Factor因子生成指定大小的slab,而某slab
id根本未被使用时,会出现内存浪费

redis内部使用一个redisObject对象来表示所有的key和value。redisObject主要的信息包括数据类型、编码方式、数据指针、虚拟内存等。它包含String,Hash,List,Set,Sorted
Set五种数据类型,针对不同的场景使用对应的数据类型,减少内存使用的同时,节省网络流量传输。

图片 2Redis数据结构.png

   2.

试想单线程是否就无法发挥多核CPU
性能,其实不然,我们可以通过在单机开多个redis实例来完善。单一线程只能用到一个CPU核心,所以可以在同一个多核的服务器中,启动多个实例,组成master-master或者master-slave的形式,耗时的读命令可以完全在slave进行,充分发挥redis的作用。

Redis提供了五种数据结构,分别是:String、hash、list、set、zset,其数据类型及其内部编码如下图:

         2.
内存使用率:Memcached简单的key-value存储,内存利用率更高,而如果Redis采用hash结构来做Key-value存储,由于组合式的压缩,内存利用率更高。

更多Redis相关技术文章,请访问Redis教程栏目进行学习!

  • 可以改进内部编码,而对外的数据结构和命令没有影响;例如,Redis3.2提供了quicklist,结合了ziplist与linkedlist两者的优势,为列表类型提供了一种更为优秀的内部编码实现,而对外部用户来说基本感知不到其变化。

  • 多种内部编码实现可以在不同场景下发挥各自的优势;例如,ziplist节省内存,但是在列表元素较多的情况下,性能会有所下降,这时候Redis会根据配置选项将列表类型的内部实现转换为linkedlist。

前言:

(一)纯内存操作,避免大量访问数据库,减少直接读取磁盘数据,redis
将数据储存在内存里面,读写数据的时候都不会受到硬盘 I/O
速度的限制,所以速度快;

3、总结

单线程能带来以下好处:

  • 单线程可以简化数据结构和算法的实现,而并发数据结构实现起来较为困难,而且测试也比较麻烦;

  • 单线程避免了线程上下文切换和竞态产生的消耗,对于服务端开发而已,锁和线程切换是性能杀手。

单线程存在的问题:对于每个命令的执行时间是有要求的。如果执行时间过长,则会造成其他命令的阻塞,对于Redis的高性能服务来说这是致命的问题,因此Redis是面向快速执行场景的数据库。

根据以上知识可以继续深入理解Redis的底层实现,总结如下:

1、Redis的线程结构:

1)、I/O业务单线程:

Redis的单线程结构是指其主线程是单线程的,包括I/O时间的处理,以及I/O对应的相关请求的业务处理,此外主线程还负责过期键的处理、复制协调、集群协调等等,这些除了I/O事件(内存数据库无IO事件)之外的逻辑会被封装成周期性任务由主线程周期性地处理。因为单线程的设计,对于客户端的所有读写请求,都由一个主线程串行处理,不存在并发问题,避免了频繁的上下文切换和锁竞争,且在网络上使用epoll,利用epool的非阻塞多路复用特性,不需要在IO上付出代价

2)、异步化组件:

RDB文件、持久化AOF文件等操作不放在主线程里面处理,Redis会在适当时候fork子进程来异步处理这些任务,其线程体系结构如下:

图片 3线程体系.png

main eventloop:主线程child
process:子进程,用于处理RDB持久化及AOF持久化等任务job thread
:异步任务处理线程:BIO组件

BIO组件:在Redis中,异步任务处理线程组被封装在BIO组件中,源文件为bio.h和bio.c。bio异步线程启动时在main方法调用,会生成BIO_NUM_OPS个线程,线程函数为bioProcessBackgroundJobs。BIO线程包括三个线程,分别处理三类任务文件句柄关闭任务:

  1. 文件句柄的释放对于操作系统来说是一个比较重的操作,在Redis中,当需要重新创建新的文件句柄,废弃的文件句柄失效的时候,这个废弃的文件句柄将由异步任务处理线程来关闭。

  2. AOF持久化任务:Redis对于AOF文件的持久化有三种策略

    1. 关闭AOF功能
    2. aof_fsync_everysec策略,即每秒一次,实际上并不是一定一秒钟一次
    3. aof_fsync_always策略,即每次IO事件处理完毕,都将AOF持久化

这三种策略分别对应不同的业务场景和用户需求,默认的策略为aof_fsync_everysec,这个时候对于aof缓冲区内容持久化工作会交给异
步任 务处理线程来处理

  1. 内存的释放:释放的空间包括:

    1. 对象空间的释放
    2. DB空间的异步释放
    3. slots-leys空间释

3、redis阻塞原因:

内因:不合理使用API和数据结构

CPU饱和持久化阻塞:fork阻塞、AOF刷盘阻塞、HugePage写操作阻塞

  • fork阻塞:fork操作发生在RDB和AOF重写时,Redis主线程调用fork操作产生共享内存的子进程,由子进程完成持久化文件重写工作,如果fork操作本身耗时很长,必然会导致主线程阻塞。

  • AOF刷盘阻塞:在开启AOF持久化功能时,文件刷盘一般采用一秒一次,后台线程每秒对AOF文件做fsync操作,当硬盘压力过大时,fsync操作需要等待,直到写入完成。如果主线程发现距离上一次的fsync成功超过2秒,为了数据安全性它会阻塞直到后台线程执行fsync操作完成。

  • 子进程在执行重新期间利用linux写时复制技术降低内存开销,因此只有写操作时Redis才复制需要修改的内存页,对于开启Transparent
    HugePages的操作系统,每次写命令引起的复制内存页单位由4K变为2M,放大了512倍,会拖慢写操作的执行时间,导致大量写操作慢查询。

外因:CPU竞争、内存交换、网络问题

应用场景分析:Hash、LSM、B+树实际应用开发中,根据需求的不同进行数据存储技术的选型,常见的存储实现有redis、mysql、Hbase,其底层实现的数据结构分别是:hash、B+树、LSM树,各自的特性如下:

  • 哈希存储引擎是哈希表的持久化实现,支持增、删、改以及随机读取操作,但不支持顺序扫描,对应的存储系统为key-value存储系统。对于key-value的插入以及查询,哈希表的复杂度都是O,明显比树的操作O快,如果不需要有序的遍历数据,哈希表就是最佳选举。

  • B树存储引擎是B树的持久化实现,不仅支持单条记录的增、删、读、改操作,还支持顺序扫描(B+树的叶子节点之间的指针),对应的存储系统就是关系数据库。

  • LSM树(Log-Structured Merge
    Tree)存储引擎和B树存储引擎一样,同样支持增、删、读、改、顺序扫描操作。而且通过批量存储技术规避磁盘随机写入问题。当然凡事有利有弊,LSM树和B+树相比,LSM树牺牲了部分读性能,用来大幅提高写性能,hbase和levelDB的内部实现数据结构就是LSM树。

1、《Redis开发与运维》付磊、张益军[著]

2、个人学习总结

         1.
Memcached和Redis都属于In-Memory、Key-Value数据存储方案,同属于NoSQL家族,都选择将全部数据存储在内存中。

多路复用原理:

1、线程模型:

Redis线程模型采用的是单线程架构,并使用I/O多路复用模型来共同实现高性能的内存数据库服务;Redis客户端与服务端的模型可以简化为下图:

图片 4redis请求过程.png

Redis客户端与服务端通过RPC通信,其内部设计了一套专用的文本通讯协议
RESP:Redis Serialization
Protoco;Redis客户端调用都会经历发送命令、执行命令、返回结果三个过程;其中第二步是需要重点关注的。

Redis采用单线程来处理命令,所以一条命令从客户端发送到服务端不会立即被执行,所以的命令都会进入一个队列中,然后逐个被执行;因此,如果多个客户端同执行命令时,其命令的执行顺序是不确定的,但可以确定的是不会有两天命令被同时执行,因此不存在并发问题。

 图片 5

(三)采用了非阻塞I/O多路复用机制

       Slab
Allocation的原理:将分配的内存分割成各种尺寸的块(chunk),并把尺寸相同的块分成组,每一组被称为slab。Memcached的内存分配以Page为单位,Page默认值为1M,可以在启动时通过-I参数来指定。Slab是由多个Page组成的,Page按照指定大小切割成多个chunk。memcached在启动时通过-f选项可以指定
Growth
Factor因子。该值控制slab之间的差异,chunk大小的差异。默认值为1.25。其结构图如下:

相关文章

You can leave a response, or trackback from your own site.

Leave a Reply

网站地图xml地图