Tag Archives: Redis

Redis

学习一个技术,通常只接触了零散的技术点,没有在脑海里建立一个完整的知识框架和架构体系,没有系统观。这样会很吃力,而且会出现一看好像自己会,过后就忘记,一脸懵逼。

跟着「码哥字节」一起吃透 Redis,深层次的掌握 Redis 核心原理以及实战技巧。一起搭建一套完整的知识框架,学会全局观去整理整个知识体系。

 

系统观其实是至关重要的,从某种程度上说,在解决问题时,拥有了系统观,就意味着你能有依据、有章法地定位和解决问题。

 

Redis 全景图
 

全景图可以围绕两个维度展开,分别是:

 

应用维度:缓存使用、集群运用、数据结构的巧妙使用

 

系统维度:可以归类为三高

 

  • 高性能:线程模型、网络 IO 模型、数据结构、持久化机制;
  • 高可用:主从复制、哨兵集群、Cluster 分片集群;
  • 高拓展:负载均衡

 

Redis 系列篇章围绕如下思维导图展开,这次从 《Redis 唯快不破的秘密》一起探索 Redis 的核心知识点。

 

吃透Redis

唯快不破的秘密
 

65 哥前段时间去面试 996 大厂,被问到「Redis 为什么快?」

 

65 哥:额,因为它是基于内存实现和单线程模型

 

面试官:还有呢?

 

65 哥:没了呀。

 

很多人仅仅只是知道基于内存实现,其他核心的原因模凌两可。今日跟着「码哥字节」一起探索真正快的原因,做一个唯快不破的真男人!

 

Redis 为了高性能,从各方各面都进行了优化,下次小伙伴们面试的时候,面试官问 Redis 性能为什么如此高,可不能傻傻的只说单线程和内存存储了。

 

唯快不破的秘密

 

根据官方数据,Redis 的 QPS 可以达到约 100000(每秒请求数),有兴趣的可以参考官方的基准程序测试《How fast is Redis?》,地址:https://redis.io/topics/benchmarks

 

基准测试

 

横轴是连接数,纵轴是 QPS。此时,这张图反映了一个数量级,希望大家在面试的时候可以正确的描述出来,不要问你的时候,你回答的数量级相差甚远!

 

完全基于内存实现
 

65 哥:这个我知道,Redis 是基于内存的数据库,跟磁盘数据库相比,完全吊打磁盘的速度,就像段誉的凌波微步。对于磁盘数据库来说,首先要将数据通过 IO 操作读取到内存里。

 

没错,不论读写操作都是在内存上完成的,我们分别对比下内存操作与磁盘操作的差异。

 

磁盘调用栈图

 

 
 

 

内存操作

 

 
 

内存直接由 CPU 控制,也就是 CPU 内部集成的内存控制器,所以说内存是直接与 CPU 对接,享受与 CPU 通信的最优带宽。

 

Redis 将数据存储在内存中,读写操作不会因为磁盘的 IO 速度限制,所以速度飞一般的感觉!

 

最后以一张图量化系统的各种延时时间(部分数据引用 Brendan Gregg)

 

 

高效的数据结构
 

65 哥:学习 MySQL 的时候我知道为了提高检索速度使用了 B+ Tree 数据结构,所以 Redis 速度快应该也跟数据结构有关。

 

回答正确,这里所说的数据结构并不是 Redis 提供给我们使用的 5 种数据类型:String、List、Hash、Set、SortedSet。

 

在 Redis 中,常用的 5 种数据类型和应用场景如下:

 

  • String:缓存、计数器、分布式锁等。
  • List:链表、队列、微博关注人时间轴列表等。
  • Hash:用户信息、Hash 表等。
  • Set:去重、赞、踩、共同好友等。
  • Zset:访问量排行榜、点击量排行榜等。

 

上面的应该叫做 Redis 支持的数据类型,也就是数据的保存形式。「码哥字节」要说的是针对这 5 种数据类型,底层都运用了哪些高效的数据结构来支持。

 

65 哥:为啥搞这么多数据结构呢?

 

当然是为了追求速度,不同数据类型使用不同的数据结构速度才得以提升。每种数据类型都有一种或者多种数据结构来支撑,底层数据结构有 6 种。

 

 

Redis hash 字典

 

 
 

Redis 整体就是一个 哈希表来保存所有的键值对,无论数据类型是 5 种的任意一种。哈希表,本质就是一个数组,每个元素被叫做哈希桶,不管什么数据类型,每个桶里面的 entry 保存着实际具体值的指针。

 

Redis 全局哈希表

 

整个数据库就是一个全局哈希表,而哈希表的时间复杂度是 O(1),只需要计算每个键的哈希值,便知道对应的哈希桶位置,定位桶里面的 entry 找到对应数据,这个也是 Redis 快的原因之一。

 

那 Hash 冲突怎么办?

 

当写入 Redis 的数据越来越多的时候,哈希冲突不可避免,会出现不同的 key 计算出一样的哈希值。

 

Redis 通过链式哈希解决冲突:也就是同一个 桶里面的元素使用链表保存。但是当链表过长就会导致查找性能变差可能,所以 Redis 为了追求快,使用了两个全局哈希表。用于 rehash 操作,增加现有的哈希桶数量,减少哈希冲突。

 

开始默认使用 hash 表 1 保存键值对数据,哈希表 2 此刻没有分配空间。当数据越来多触发 rehash 操作,则执行以下操作:

 

  • 给 hash 表 2 分配更大的空间;
  • 将 hash 表 1 的数据重新映射拷贝到 hash 表 2 中;
  • 释放 hash 表 1 的空间。

 

值得注意的是,将 hash 表 1 的数据重新映射到 hash 表 2 的过程中并不是一次性的,这样会造成 Redis 阻塞,无法提供服务。

 

而是采用了渐进式 rehash,每次处理客户端请求的时候,先从 hash 表 1 中第一个索引开始,将这个位置的 所有数据拷贝到 hash 表 2 中,就这样将 rehash 分散到多次请求过程中,避免耗时阻塞。

 

SDS 简单动态字符

 

 
 

65 哥:Redis 是用 C 语言实现的,为啥还重新搞一个 SDS 动态字符串呢?

 

字符串结构使用最广泛,通常我们用于缓存登陆后的用户信息,key = userId,value = 用户信息 JSON 序列化成字符串。

 

C 语言中字符串的获取 「MageByte」的长度,要从头开始遍历,直到 「\0」为止,Redis 作为唯快不破的男人是不能忍受的。

 

C 语言字符串结构与 SDS 字符串结构对比图如下所示:

 

C 语言字符串与 SDS

 

SDS 与 C 字符串区别

 

 
 

1)O(1) 时间复杂度获取字符串长度

 

C 语言字符串布吉路长度信息,需要遍历整个字符串时间复杂度为 O(n),C 字符串遍历时遇到 ‘\0’ 时结束。

 

SDS 中 len 保存这字符串的长度,O(1) 时间复杂度。

 

2)空间预分配

 

SDS 被修改后,程序不仅会为 SDS 分配所需要的必须空间,还会分配额外的未使用空间。

 

分配规则如下:如果对 SDS 修改后,len 的长度小于 1M,那么程序将分配和 len 相同长度的未使用空间。举个例子,如果 len=10,重新分配后,buf 的实际长度会变为 10(已使用空间)+10(额外空间)+1(空字符)=21。如果对 SDS 修改后 len 长度大于 1M,那么程序将分配 1M 的未使用空间。

 

3)惰性空间释放

 

当对 SDS 进行缩短操作时,程序并不会回收多余的内存空间,而是使用 free 字段将这些字节数量记录下来不释放,后面如果需要 append 操作,则直接使用 free 中未使用的空间,减少了内存的分配。

 

4)二进制安全

 

在 Redis 中不仅可以存储 String 类型的数据,也可能存储一些二进制数据。

 

二进制数据并不是规则的字符串格式,其中会包含一些特殊的字符如 ‘\0’,在 C 中遇到 ‘\0’ 则表示字符串的结束,但在 SDS 中,标志字符串结束的是 len 属性。

 

zipList 压缩列表

 

 
 

压缩列表是 List 、hash、 sorted Set 三种数据类型底层实现之一。

 

当一个列表只有少量数据的时候,并且每个列表项要么就是小整数值,要么就是长度比较短的字符串,那么 Redis 就会使用压缩列表来做列表键的底层实现。

 

ziplist 是由一系列特殊编码的连续内存块组成的顺序型的数据结构,ziplist 中可以包含多个 entry 节点,每个节点可以存放整数或者字符串。

 

ziplist 在表头有三个字段 zlbytes、zltail 和 zllen,分别表示列表占用字节数、列表尾的偏移量和列表中的 entry 个数;压缩列表在表尾还有一个 zlend,表示列表结束。

 

struct ziplist<T> {
    int32 zlbytes; // 整个压缩列表占用字节数
    int32 zltail_offset; // 最后一个元素距离压缩列表起始位置的偏移量,用于快速定位到最后一个节点
    int16 zllength; // 元素个数
    T[] entries; // 元素内容列表,挨个挨个紧凑存储
    int8 zlend; // 标志压缩列表的结束,值恒为 0xFF
}

 

ziplist

 

如果我们要查找定位第一个元素和最后一个元素,可以通过表头三个字段的长度直接定位,复杂度是 O(1)。而查找其他元素时,就没有这么高效了,只能逐个查找,此时的复杂度就是 O(N)

 

双端列表

 

 
 

Redis List 数据类型通常被用于队列、微博关注人时间轴列表等场景。不管是先进先出的队列,还是先进后出的栈,双端列表都很好的支持这些特性。

 

 

Redis 的链表实现的特性可以总结如下:

 

  • 双端:链表节点带有 prev 和 next 指针,获取某个节点的前置节点和后置节点的复杂度都是 O(1)。

     

  • 无环:表头节点的 prev 指针和表尾节点的 next 指针都指向 NULL,对链表的访问以 NULL 为终点。

     

  • 带表头指针和表尾指针:通过 list 结构的 head 指针和 tail 指针,程序获取链表的表头节点和表尾节点的复杂度为 O(1)。

     

  • 带链表长度计数器:程序使用 list 结构的 len 属性来对 list 持有的链表节点进行计数,程序获取链表中节点数量的复杂度为 O(1)。

     

  • 多态:链表节点使用 void* 指针来保存节点值,并且可以通过 list 结构的 dup、free、match 三个属性为节点值设置类型特定函数,所以链表可以用于保存各种不同类型的值。

 

后续版本对列表数据结构进行了改造,使用 quicklist 代替了 ziplist 和 linkedlist。

 

quicklist 是 ziplist 和 linkedlist 的混合体,它将 linkedlist 按段切分,每一段使用 ziplist 来紧凑存储,多个 ziplist 之间使用双向指针串接起来。

 

 

这也是为何 Redis 快的原因,不放过任何一个可以提升性能的细节。

 

skipList 跳跃表

 

 
 

sorted set 类型的排序功能便是通过「跳跃列表」数据结构来实现。

 

跳跃表(skiplist)是一种有序数据结构,它通过在每个节点中维持多个指向其他节点的指针,从而达到快速访问节点的目的。

 

跳跃表支持平均 O(logN)、最坏 O(N)复杂度的节点查找,还可以通过顺序性操作来批量处理节点。

 

跳表在链表的基础上,增加了多层级索引,通过索引位置的几个跳转,实现数据的快速定位,如下图所示:

 

跳跃表

 

当需要查找 40 这个元素需要经历 三次查找。

 

整数数组(intset)

 

 
 

当一个集合只包含整数值元素,并且这个集合的元素数量不多时,Redis 就会使用整数集合作为集合键的底层实现。结构如下:

 

 

typedef struct intset{
//编码方式
uint32_t encoding;
//集合包含的元素数量
uint32_t length;
//保存元素的数组
int8_t contents[];
}intset;

 

contents 数组是整数集合的底层实现:整数集合的每个元素都是 contents 数组的一个数组项(item),各个项在数组中按值的大小从小到大有序地排列,并且数组中不包含任何重复项。length 属性记录了整数集合包含的元素数量,也即是 contents 数组的长度。

 

合理的数据编码

 

 
 

Redis 使用对象(redisObject)来表示数据库中的键值,当我们在 Redis 中创建一个键值对时,至少创建两个对象,一个对象是用做键值对的键对象,另一个是键值对的值对象。

 

例如我们执行 SET MSG XXX 时,键值对的键是一个包含了字符串“MSG“的对象,键值对的值对象是包含字符串”XXX”的对象。

 

redisObject

 

 

typedef struct redisObject{
//类型
unsigned type:4;
//编码
unsigned encoding:4;
//指向底层数据结构的指针
void *ptr;
//...
}robj;

 

其中 type 字段记录了对象的类型,包含字符串对象、列表对象、哈希对象、集合对象、有序集合对象。

 

对于每一种数据类型来说,底层的支持可能是多种数据结构,什么时候使用哪种数据结构,这就涉及到了编码转化的问题。

 

那我们就来看看,不同的数据类型是如何进行编码转化的:

 

String:存储数字的话,采用 int 类型的编码,如果是非数字的话,采用 raw 编码;

 

List:List 对象的编码可以是 ziplist 或 linkedlist,字符串长度 < 64 字节且元素个数 < 512 使用 ziplist 编码,否则转化为 linkedlist 编码;

 

注意:这两个条件是可以修改的,在 redis.conf 中:

 

 

list-max-ziplist-entries 512
list-max-ziplist-value 64

 

 

Hash:Hash 对象的编码可以是 ziplist 或 hashtable。

 

当 Hash 对象同时满足以下两个条件时,Hash 对象采用 ziplist 编码:

 

  • Hash 对象保存的所有键值对的键和值的字符串长度均小于 64 字节。
  • Hash 对象保存的键值对数量小于 512 个。

 

否则就是 hashtable 编码。

 

Set:Set 对象的编码可以是 intset 或 hashtable,intset 编码的对象使用整数集合作为底层实现,把所有元素都保存在一个整数集合里面。

 

保存元素为整数且元素个数小于一定范围使用 intset 编码,任意条件不满足,则使用 hashtable 编码;

 

Zset:Zset 对象的编码可以是 ziplist 或 zkiplist,当采用 ziplist 编码存储时,每个集合元素使用两个紧挨在一起的压缩列表来存储。

 

Ziplist 压缩列表第一个节点存储元素的成员,第二个节点存储元素的分值,并且按分值大小从小到大有序排列。

 

 

当 Zset 对象同时满足一下两个条件时,采用 ziplist 编码:

 

  • Zset 保存的元素个数小于 128。
  • Zset 元素的成员长度都小于 64 字节。

 

如果不满足以上条件的任意一个,ziplist 就会转化为 zkiplist 编码。注意:这两个条件是可以修改的,在 redis.conf 中:

 

 

zset-max-ziplist-entries 128
zset-max-ziplist-value 64

 

 

单线程模型
 

65 哥:为什么 Redis 是单线程的而不用多线程并行执行充分利用 CPU 呢?

 

我们要明确的是:Redis 的单线程指的是 Redis 的网络 IO 以及键值对指令读写是由一个线程来执行的。 对于 Redis 的持久化、集群数据同步、异步删除等都是其他线程执行。

 

至于为啥用单线程,我们先了解多线程有什么缺点。

 

多线程的弊端

 

 
 

使用多线程,通常可以增加系统吞吐量,充分利用 CPU 资源。

 

但是,使用多线程后,没有良好的系统设计,可能会出现如下图所示的场景,增加了线程数量,前期吞吐量会增加,再进一步新增线程的时候,系统吞吐量几乎不再新增,甚至会下降!

 

线程数与吞吐量

 

在运行每个任务之前,CPU 需要知道任务在何处加载并开始运行。也就是说,系统需要帮助它预先设置 CPU 寄存器和程序计数器,这称为 CPU 上下文。

 

这些保存的上下文存储在系统内核中,并在重新计划任务时再次加载。这样,任务的原始状态将不会受到影响,并且该任务将看起来正在连续运行。

 

切换上下文时,我们需要完成一系列工作,这是非常消耗资源的操作。

 

另外,当多线程并行修改共享数据的时候,为了保证数据正确,需要加锁机制就会带来额外的性能开销,面临的共享资源的并发访问控制问题。

 

引入多线程开发,就需要使用同步原语来保护共享资源的并发读写,增加代码复杂度和调试难度。

 

单线程的好处

 

 
 

  • 不会因为线程创建导致的性能消耗;
  • 避免上下文切换引起的 CPU 消耗,没有多线程切换的开销;
  • 避免了线程之间的竞争问题,比如添加锁、释放锁、死锁等,不需要考虑各种锁问题。
  • 代码更清晰,处理逻辑简单。

 

单线程是否没有充分利用 CPU 资源呢?

 

官方答案:因为 Redis 是基于内存的操作,CPU 不是 Redis 的瓶颈,Redis 的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现,而且 CPU 不会成为瓶颈,那就顺理成章地采用单线程的方案了。原文地址:https://redis.io/topics/faq。

 

I/O 多路复用模型
 

Redis 采用 I/O 多路复用技术,并发处理连接。采用了 epoll + 自己实现的简单的事件框架。epoll 中的读、写、关闭、连接都转化成了事件,然后利用 epoll 的多路复用特性,绝不在 IO 上浪费一点时间。

 

65 哥:那什么是 I/O 多路复用呢?

 

在解释 IO 多虑复用之前我们先了解下基本 IO 操作会经历什么。

 

基本 IO 模型

 

 
 

一个基本的网络 IO 模型,当处理 get 请求,会经历以下过程:

 

  • 和客户端建立建立 accept;
  • 从 socket 种读取请求 recv;
  • 解析客户端发送的请求 parse;
  • 执行 get 指令;
  • 响应客户端数据,也就是 向 socket 写回数据。

 

其中,bind/listen、accept、recv、parse 和 send 属于网络 IO 处理,而 get 属于键值数据操作。既然 Redis 是单线程,那么,最基本的一种实现是在一个线程中依次执行上面说的这些操作。

 

关键点就是 accept 和 recv 会出现阻塞,当 Redis 监听到一个客户端有连接请求,但一直未能成功建立起连接时,会阻塞在 accept() 函数这里,导致其他客户端无法和 Redis 建立连接。

 

类似的,当 Redis 通过 recv() 从一个客户端读取数据时,如果数据一直没有到达,Redis 也会一直阻塞在 recv()。

 

 

阻塞的原因由于使用传统阻塞 IO ,也就是在执行 read、accept 、recv 等网络操作会一直阻塞等待。如下图所示:

 

阻塞IO

 

IO 多路复用

 

 
 

多路指的是多个 socket 连接,复用指的是复用一个线程。多路复用主要有三种技术:select,poll,epoll。epoll 是最新的也是目前最好的多路复用技术。

 

它的基本原理是,内核不是监视应用程序本身的连接,而是监视应用程序的文件描述符。

 

当客户端运行时,它将生成具有不同事件类型的套接字。在服务器端,I / O 多路复用程序(I / O 多路复用模块)会将消息放入队列(也就是 下图的 I/O 多路复用程序的 socket 队列),然后通过文件事件分派器将其转发到不同的事件处理器。

 

简单来说:Redis 单线程情况下,内核会一直监听 socket 上的连接请求或者数据请求,一旦有请求到达就交给 Redis 线程处理,这就实现了一个 Redis 线程处理多个 IO 流的效果。

 

select/epoll 提供了基于事件的回调机制,即针对不同事件的发生,调用相应的事件处理器。所以 Redis 一直在处理事件,提升 Redis 的响应性能。

 

高性能 IO 多路复用

 

Redis 线程不会阻塞在某一个特定的监听或已连接套接字上,也就是说,不会阻塞在某一个特定的客户端请求处理上。正因为此,Redis 可以同时和多个客户端连接并处理请求,从而提升并发性。

 

唯快不破的原理总结
 

65 哥:学完之后我终于知道 Redis 为何快的本质原因了,「码哥」你别说话,我来总结!一会我再点赞和分享这篇文章,让更多人知道 Redis 快的核心原理。

 

  • 纯内存操作,一般都是简单的存取操作,线程占用的时间很多,时间的花费主要集中在 IO 上,所以读取速度快。
 

  • 整个 Redis 就是一个全局 哈希表,他的时间复杂度是 O(1),而且为了防止哈希冲突导致链表过长,Redis 会执行 rehash 操作,扩充 哈希桶数量,减少哈希冲突。并且防止一次性 重新映射数据过大导致线程阻塞,采用 渐进式 rehash。巧妙的将一次性拷贝分摊到多次请求过程后总,避免阻塞。

 

  • Redis 使用的是非阻塞 IO:IO 多路复用,使用了单线程来轮询描述符,将数据库的开、关、读、写都转换成了事件,Redis 采用自己实现的事件分离器,效率比较高。

 

  • 采用单线程模型,保证了每个操作的原子性,也减少了线程的上下文切换和竞争。

 

  • Redis 全程使用 hash 结构,读取速度快,还有一些特殊的数据结构,对数据存储进行了优化,如压缩表,对短数据进行压缩存储,再如,跳表,使用有序的数据结构加快读取的速度。

 

  • 根据实际存储的数据类型选择不同编码。

 

作者丨MageByte技术团队
来源丨公众号:码哥字节(ID:MageByte)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn

How to install redis server on CentOS

In this tutorial we will learn, how to install redis server on CentOS 7 / RHEL 7 . The abbreviation of redis is REmote DIctionary Server. It is one the of the most popular open source,advanced key-value cache and store.

Project URL : http://redis.io/

Follow the given below steps to install redis server on CentOS 7 and Red Hat Enterprise Linux 7.

Install wget utility

Install wget command

yum install wget

Install EPEL repo

First we will install the EPEL repo. For more detail on EPEL repo, we suggest you to read our this post.

Because our system has x86_64 Operating System architecture, we will use only epel repo package for x86_64 . Search epel repo package as per your Operating System architecture(EPEL URL)

wget -r --no-parent -A 'epel-release-*.rpm' http://dl.fedoraproject.org/pub/epel/7/x86_64/e/

rpm -Uvh dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-*.rpm

It will create two epel’s repo file inside /etc/yum.repos.d
These are –
1. epel.repo
2.epel-testing.repo

[root@localhost ~]# ls -l /etc/yum.repos.d/
total 28
-rw-r--r--. 1 root root 1612 Jul  4 07:00 CentOS-Base.repo
-rw-r--r--. 1 root root  640 Jul  4 07:00 CentOS-Debuginfo.repo
-rw-r--r--. 1 root root 1331 Jul  4 07:00 CentOS-Sources.repo
-rw-r--r--. 1 root root  156 Jul  4 07:00 CentOS-Vault.repo
-rw-r--r--. 1 root root  957 Sep  2 12:14 epel.repo
-rw-r--r--. 1 root root 1056 Sep  2 12:14 epel-testing.repo
[root@localhost ~]#

Install redis server

Now use yum command to install redis server

yum install redis

Two important redis server configuration file’s path
1. /etc/redis.conf
2. /etc/redis-sentinel.conf

Now start the redis server after this.

systemctl start redis.service

Check the running status of redis server

systemctl status redis.service

To test the installation of Redis, use below given command

redis-cli ping

If the response output is PONG, it means installation is completed successfully.

[root@localhost ~]# redis-cli ping
PONG
[root@localhost ~]#

Start/Stop/Restart/Status and Enable redis server

To start redis server

systemctl start redis.service

To stop redis server

systemctl stop redis.service

To restart redis server

systemctl restart redis.service

To get running status of redis server

systemctl status redis.service

To enable redis server at system’s booting time.

systemctl enable redis.service

To disable redis server at system’s booting time.

systemctl disable redis.service

Listening Port Of Redis Server

Redis Server listens by default at port number 6379. Use below given ss command. (To learn more about ss command)

[root@localhost ~]# ss -nlp|grep redis
tcp    LISTEN     0      128            127.0.0.1:6379                  *:*      users:(("redis-server",19706,4))
[root@localhost ~]#

Note: On minimal installed CentOS 7/ RHEL 7,you wont get netstat command. Instead of netstat command, use ss command which is by default available on system.

Learn Redis : http://redis.io/documentation

Who is using redis: Who is using Redis

Redis配置文件参数说明

from:http://sharadchhetri.com/2014/10/04/install-redis-server-centos-7-rhel-7/

Redis 备份、容灾及高可用实战

一、Redis简单介绍

Redis是一个高性能的key-value非关系型数据库,由于其具有高性能的特性,支持高可用、持久化、多种数据结构、集群等,使其脱颖而出,成为常用的非关系型数据库。

此外,Redis的使用场景也比较多。

  1. 会话缓存(Session Cache)
    Redis缓存会话有非常好的优势,因为Redis提供持久化,在需要长时间保持会话的应用场景中,如购物车场景这样的场景中能提供很好的长会话支持,能给用户提供很好的购物体验。
  2. 全页缓存
    在WordPress中,Pantheon提供了一个不错的插件wp-redis,这个插件能以最快的速度加载你曾经浏览过的页面。
  3. 队列
    Reids提供list和set操作,这使得Redis能作为一个很好的消息队列平台来使用。我们常通过Reids的队列功能做购买限制。比如到节假日或者推广期间,进行一些活动,对用户购买行为进行限制,限制今天只能购买几次商品或者一段时间内只能购买一次。也比较适合适用。
  4. 排名
    Redis在内存中对数字进行递增或递减的操作实现得非常好。所以我们在很多排名的场景中会应用Redis来进行,比如小说网站对小说进行排名,根据排名,将排名靠前的小说推荐给用户。
  5. 发布/订阅
    Redis提供发布和订阅功能,发布和订阅的场景很多,比如我们可以基于发布和订阅的脚本触发器,实现用Redis的发布和订阅功能建立起来的聊天系统。

此外还有很多其它场景,Redis都表现的不错。

二、Redis使用中单点故障问题

正是由于Redis具备多种优良特新,且应用场景非常丰富,以至于Redis在各个公司都有它存在的身影。那么随之而来的问题和风险也就来了。Redis虽然应用场景丰富,但部分公司在实践Redis应用的时候还是相对保守使用单节点部署,那为日后的维护带来了安全风险。

在2015年的时候,曾处理过一个因为单点故障原因导致的业务中断问题。当时的Redis都未采用分布式部署,采用单实例部署,并未考虑容灾方面的问题。

当时我们通过Redis服务器做用户购买优惠商品的行为控制,但后来由于未知原因Redis节点的服务器宕机了,导致我们无法对用户购买行为进行控制,造成了用户能够在一段时间内多次购买优惠商品的行为。

这种宕机事故可以说已经对公司造成了不可挽回的损失了,安全风险问题非常严重,作为当时运维这个系统的我来说有必要对这个问题进行修复和在架构上的改进。于是我开始了解决非分布式应用下Redis单点故障方面的研究学习。

三、非分布式场景下Redis应用的备份与容灾

Redis主从复制现在应该是很普遍了。常用的主从复制架构有如下两种架构方案。

常用Redis主从复制

  • 方案一

Redis这是最常见的一种架构,一个Master节点,两个Slave节点。客户端写数据的时候是写Master节点,读的时候,是读取两个Slave,这样实现读的扩展,减轻了Master节点读负载。

  • 方案二

Maste

  • 这种架构同样是一个Master和两个Slave。不同的是Master和Slave1使用keepalived进行VIP转移。Client连接Master的时候是通过VIP进行连接的。避免了方案一IP更改的情况。

Redis主从复制优点与不足

  • 优点
  1. 实现了对master数据的备份,一旦master出现故障,slave节点可以提升为新的master,顶替旧的master继续提供服务
  2. 实现读扩展。使用主从复制架构, 一般都是为了实现读扩展。Master主要实现写功能,  Slave实现读的功能
  • 不足
    架构方案一
    当Master出现故障时,Client就与Master端断开连接,无法实现写功能,同时Slave也无法从Master进行复制。

架构

此时需要经过如下操作(假设提升Slave1为Master):

  1. 在Slave1上执slaveof no one命令提升Slave1为新的Master节点。
  2. 在Slave1上配置为可写,这是因为大多数情况下,都将slave配置只读。
  3. 告诉Client端(也就是连接Redis的程序)新的Master节点的连接地址。
  4. 配置Slave2从新的Master进行数据复制。

架构方案二
当master出现故障后,Client可以连接到Slave1上进行数据操作,但是Slave1就成了一个单点,就出现了经常要避免的单点故障(single point of failure)。

 

之后需要经过如下操作:

  1. 在Slave1上执行slaveof no one命令提升Slave1为新的Master节点
  2. 在Slave1上配置为可写,这是因为大多数情况下,都将Slave配置只读
  3. 配置Slave2从新的Master进行数据复制

可以发现,无论是哪种架构方案都需要人工干预来进行故障转移(failover)。需要人工干预就增加了运维工作量,同时也对业务造成了巨大影响。这时候可以使用Redis的高可用方案-Sentinel

四、Redis Sentinel介绍

Redis Sentinel为Redis提供了高可用方案。从实践方面来说,使用Redis Sentinel可以创建一个无需人为干预就可以预防某些故障的Redis环境。
Redis Sentinel设计为分布式的架构,运行多个Sentinel进程来共同合作的。运行多个Sentinel进程合作,当多个Sentinel同一给定的master无法再继续提供服务,就会执行故障检测,这会降低误报的可能性。

五、Redis Sentinel功能

Redis Sentinel在Redis高可用方案中主要作用有如下功能:

  • 监控
    Sentinel会不断的检查master和slave是否像预期那样正常运行
  • 通知
    通过API,Sentinel能够通知系统管理员、程序监控的Redis实例出现了故障
  • 自动故障转移
    如果master不像预想中那样正常运行,Sentinel可以启动故障转移过程,其中的一个slave会提成为master,其它slave会重新配置来使用新的master,使用Redis服务的应用程序,当连接时,也会被通知使用新的地址。
  • 配置提供者
    Sentinel可以做为客户端服务发现的认证源:客户端连接Sentinel来获取目前负责给定服务的Redis master地址。如果发生故障转移,Sentinel会报告新的地址。

六、Redis Sentinel架构

Redis

七、Redis Sentinel实现原理

Sentinel集群对自身和Redis主从复制进行监控。当发现Master节点出现故障时,会经过如下步骤:

  • 1)Sentinel之间进行选举,选举出一个leader,由选举出的leader进行failover
  • 2)Sentinel leader选取slave节点中的一个slave作为新的Master节点。对slave选举需要对slave进行选举的方法如下:a) 与master断开时间
    如果与master断开的时间超过down-after-milliseconds(sentinel配置) * 10秒加上从sentinel判定master不可用到sentinel开始执行故障转移之间的时间,就认为该slave不适合提升为master。b) slave优先级
    每个slave都有优先级,保存在redis.conf配置文件里。如果优先级相同,则继续进行。c) 复制偏移位置
    复制偏移纪录着从master复制数据复制到哪里,复制偏移越大表明从master接受的数据越多,如果复制偏移量也一样,继续进行选举

    d) Run ID
    选举具有最小Run ID的Slave作为新的Master
    流程图如下:

  • 3)  Sentinel leader会在上一步选举的新master上执行slaveof no one操作,将其提升为master节点
  • 4)Sentinel leader向其它slave发送命令,让剩余的slave成为新的master节点的slave
  • 5)Sentinel leader会让原来的master降级为slave,当恢复正常工作,Sentinel leader会发送命令让其从新的master进行复制
    以上failover操作均有sentinel自己独自完成,完全无需人工干预。

总结

使用sentinel实现了Redis的高可用,当master出现故障时,完全无需人工干预即可实现故障转移。避免了对业务的影响,提高了运维工作效率。
在部署sentinel的时候,建议使用奇数个sentinel节点,最少三个sentinel节点。

写在最后

由于sentinel知识点比较多,这里仅给大家进行介绍,让大家有个了解,想了解更多可与我联系。谢谢。

from:http://www.yunweipai.com/archives/22663.html

Redis2.4.13 安装部署

1 Redis 介绍

Redis是Remote Dictionary Server的缩写。他本质上一个Key/Value数据库,与Memcached类似的NoSQL型数据库,但是他的数据可以持久化的保存在磁盘上,解决了服务重启后数据不丢失的问题,他的值可以是string(字符串)、list(列表)、sets(集合)或者是ordered sets(被排序的集合),所有的数据类型都具有push/pop、add/remove、执行服务端的并集、交集、两个sets集中的差别等等操作,这些操作都是具有原子性的,Redis还支持各种不同的排序能力

2Redis功能简介

l Redis的Sharding:目前,redis server没有提供类似mongodb那样的shard功能,只能在client端,通过一致性hash算法实现,当前Redis不支持故障冗余,在集群中不能在线增加或删除Redis

l Redis的master/slave复制:

n 一个master支持多个slave

n Slave可以接受其他slave的连接来替代他连接master

n 复制在master、在slave都是非阻塞的。

n 复制被利用来提供可扩展性,在slave端只提供查询功能及数据的冗余

l Redis的Virtual Memory功能:

u 因性能问题,2.4版本 VM机制彻底废弃

u redis的vm模式在实践中存在一些问题.

u 我使用过redis2.0.2, 发现当vm模式打开的时候, 并发连 接数在1500以上时, redis latency会大大增加.平均每个请求的latency会超过4000ms, 观察redis的进程cpu占用率, 会超过100%. 最后迫于无奈,关掉了redis的vm功能. 此时并发连接不变的情况下,redis的latency下降到2ms以下. cpu占用率下降到1%.

l Redis的附加档案(AOF)功能:Redis通过配置的策略将数据集保存到aof中,当Redis挂掉后能够通过aof恢复到挂掉前的状态

l 提供批量写入功能

l 事务:允许让一组命令进入队列一次性执行,在执行的过程中不穿插其它命令(Redis的单线程保证)。

l 管道:一次性提交多个命令(如果只是进行一些设置,命令之间不需要依赖前置命令结果的话,可以提高不少效率)。

3 Redis机构示意图

4 Redis安装

Shell>wget http://redis.googlecode.com/files/redis-2.4.13.tar.gz #下载程序

Shell >tar –zxvf redis-2.4.13.tar.gz #解压程序包

Shell > cd redis-2.4.13 #进入解压目录

Shell> make #进行编译安装

Shell > make test #测试是否成功

该版本安装不需要configure 和make install ,make编译安装后SRC目录下会多几个文件

redis-server #Redis 服务器启动命令

redis-benchmark #Redis服务启动后查看相关服务信息命令

redis-check-aof

redis-check-dump

redis-cli #Redis 命令行操作工具

为了部署规范管理方便操作如下:

· shell>mkdir -p bin

· shell>mkdir -p conf

· shell>mkdir -p logs

· shell>mkdir -p data

· shell>cd src

· shell>cp redis-server redis-cli redis-benchmark redis-stat ../bin

· shell>cd ..

shell·>cp redis.conf conf

调整配置文件调整

daemonize yes #后台运行

pidfile /opt/redis-2.4.13/bin/redis.pid #pid路径

port6379 #监听端口

logfile /opt/redis-2.4.13logs/stdout.log #日志文件路径

dbfilename /opt/redis-2.4.13/data/dump.rdb #数据库文件路径
5 Redis服务启动与停止

Shell>bin/redis-server /opt/redis-2.4.13/conf/redis.conf #服务启动,直接运行在后台

Shell>ps -ef |grep redis #查看是否有进程

Shell>netstat –ntlp |grep 6379 #查看默认监听端口

Shell>bin/ redis-benchmark #性能测试工具,测试该系统下读写性能

Shell>bin/redis-cli #命令行工具,测试是否正常

Shell >bin/redis-cli shutdown #关闭Redis服务
6 Redis配置文件详解

配置文件参数说明:

1. Redis默认不是以守护进程的方式运行,可以通过该配置项修改,使用yes启用守护进程

i. daemonize no

2. 当Redis以守护进程方式运行时,Redis默认会把pid写入/var/run/redis.pid文件,可以通过pidfile指定

i. pidfile /var/run/redis.pid

3. 指定Redis监听端口,默认端口为6379,作者在自己的一篇博文中解释了为什么选用6379作为默认端口,因为6379在手机按键上MERZ对应的号码,而MERZ取自意大利歌女Alessia Merz的名字

i. port 6379

4. 绑定的主机地址

i. bind 127.0.0.1

5. 当客户端闲置多长时间后关闭连接,如果指定为0,表示关闭该功能

i. timeout 300 #

如果应用中使用了连接池,最好设置为0,表示不使用服务器自动断开的功能,否则容易出现 java.net.SocketTimeoutException: Read timedout 或者是 It seems like server has closedthe connection 这样的异常,应用中千万要控制住连接数,打开的连接一定要关闭

6. 指定日志记录级别,Redis总共支持四个级别:debug、verbose、notice、warning,默认为verbose

i. loglevel verbose

7. 日志记录方式,默认为标准输出,如果配置Redis为守护进程方式运行,而这里又配置为日志记录方式为标准输出,则日志将会发送给/dev/null

i. logfile stdout

8. 设置数据库的数量,默认数据库为0,可以使用SELECT <dbid>命令在连接上指定数据库id

i. databases 16

9. 指定在多长时间内,有多少次更新操作,就将数据同步到数据文件,可以多个条件配合

i. save <seconds> <changes>

ii. Redis默认配置文件中提供了三个条件:

iii. save 900 1

iv. save 300 10

v. save 60 10000

vi. 分别表示900秒(15分钟)内有1个更改,300秒(5分钟)内有10个更改以及60秒内有10000个更改。

10. 指定存储至本地数据库时是否压缩数据,默认为yes,Redis采用LZF压缩,如果为了节省CPU时间,可以关闭该选项,但会导致数据库文件变的巨大

i. rdbcompression yes

11. 指定本地数据库文件名,默认值为dump.rdb

i. dbfilename dump.rdb

12. 指定本地数据库存放目录

i. dir ./

13. 设置当本机为slav服务时,设置master服务的IP地址及端口,在Redis启动时,它会自动从master进行数据同步

i. slaveof <masterip> <masterport>

14. 当master服务设置了密码保护时,slav服务连接master的密码

i. masterauth <master-password>

15. 设置Redis连接密码,如果配置了连接密码,客户端在连接Redis时需要通过AUTH <password>命令提供密码,默认关闭

i. requirepass foobared

16. 设置同一时间最大客户端连接数,默认无限制,Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数,如果设置 maxclients 0,表示不作限制。当客户端连接数到达限制时,Redis会关闭新的连接并向客户端返回max number of clients reached错误信息

i. maxclients 128

17. 指定Redis最大内存限制,Redis在启动时会把数据加载到内存中,达到最大内存后,Redis会先尝试清除已到期或即将到期的Key,当此方法处理 后,仍然到达最大内存设置,将无法再进行写入操作,但仍然可以进行读取操作。Redis新的vm机制,会把Key存放内存,Value会存放在swap区

i. maxmemory <bytes>

18. 指定是否在每次更新操作后进行日志记录,Redis在默认情况下是异步的把数据写入磁盘,如果不开启,可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的,所以有的数据会在一段时间内只存在于内存中。默认为no

i. appendonly no

19. 指定更新日志文件名,默认为appendonly.aof

i. appendfilename appendonly.aof

20. 指定更新日志条件,共有3个可选值:

i. no:表示等操作系统进行数据缓存同步到磁盘(快)

ii. always:表示每次更新操作后手动调用fsync()将数据写到磁盘(慢,安全)

iii. everysec:表示每秒同步一次(折衷,默认值)

iv. appendfsync everysec

21. 指定是否启用虚拟内存机制,默认值为no,简单的介绍一下,VM机制将数据分页存放,由Redis将访问量较少的页即冷数据swap到磁盘上,访问多的页面由磁盘自动换出到内存中(在后面的文章我会仔细分析Redis的VM机制)

i. vm-enabled no

22. 虚拟内存文件路径,默认值为/tmp/redis.swap,不可多个Redis实例共享

i. vm-swap-file /tmp/redis.swap

23. 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0

i. vm-max-memory 0

24. Redis swap文件分成了很多的page,一个对象可以保存在多个page上面,但一个page上不能被多个对象共享,vm-page-size是要根据存储的 数据大小来设定的,作者建议如果存储很多小对象,page大小最好设置为32或者64bytes;如果存储很大大对象,则可以使用更大的page,如果不 确定,就使用默认值

i. vm-page-size 32

25. 设置swap文件中的page数量,由于页表(一种表示页面空闲或使用的bitmap)是在放在内存中的,,在磁盘上每8个pages将消耗1byte的内存。

i. vm-pages 134217728

26. 设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的,可能会造成比较长时间的延迟。默认值为4

i. vm-max-threads 4

27. 设置在向客户端应答时,是否把较小的包合并为一个包发送,默认为开启

i. glueoutputbuf yes

28. 指定在超过一定的数量或者最大的元素超过某一临界值时,采用一种特殊的哈希算法

i. hash-max-zipmap-entries 6

ii. hash-max-zipmap-value 512

29. 指定是否激活重置哈希,默认为开启(后面在介绍Redis的哈希算法时具体介绍)

a) activerehashing yes

30. 指定包含其它的配置文件,可以在同一主机上多个Redis实例之间使用同一份配置文件,而同时各个实例又拥有自己的特定配置文件

include /path/to/local.conf
7 多端口运行的配置

redis是单进程的服务,所以咱得根据CPU的数目,确定究竟该运行几个实例,这样才能最好的发挥性能优势,比如服务器是8core的,那最好能够运行8个实例,这里只以第一个作为举例

1. 假设redis的安装目录在/opt/redis下面,即这个目录下包含了redis-benchmark redis-cli redis-server这几个可执行文件,现在在下面新建一个servers的文件夹,存放所有的实例

mkdir -p /opt/redis/servers/0/
mkdir -p /opt/redis/servers/0/conf
mkdir -p /opt/redis/servers/0/data
mkdir -p /opt/redis/servers/0/run
mkdir -p /opt/redis/servers/0/logs

2. 然后我们需要拷贝一份配置文件到该实例的路径下

cp redis.conf /opt/redis/servers/0/conf

3. 修改配置文件中的下列内容

pidfile /opt/redis/servers/0/run/redis.pid
port 6380
logfile /opt/redis/servers/0/logs/stdout.log
dbfilename /opt/redis/servers/0/data/dump.rdb

4. 启动停止

./redis-server /opt/redis/servers/0/conf/redis.conf #启动服务

./redis-cli -p 6380shutdown #停止服务
8 Redis维护常用命令

1、../bin/redis-cli keys\* #查看所有键值信息

[root@monitordata]# ../bin/redis-cli keys \*

1)”name”

2)”name1″

2、../bin/redis-cli info #查看redis运行状态

[root@monitordata]# ../bin/redis-cli info

redis_version:2.4.13

redis_git_sha1:00000000

redis_git_dirty:0

arch_bits:64

multiplexing_api:epoll

gcc_version:4.4.6

process_id:2738

uptime_in_seconds:6888

uptime_in_days:0

lru_clock:1508888

used_cpu_sys:0.08

used_cpu_user:0.02

used_cpu_sys_children:0.01

used_cpu_user_children:0.00

connected_clients:2

connected_slaves:0

client_longest_output_list:0

client_biggest_input_buf:0

blocked_clients:0

used_memory:734976

used_memory_human:717.75K

used_memory_rss:7323648

used_memory_peak:726504

used_memory_peak_human:709.48K

mem_fragmentation_ratio:9.96

mem_allocator:jemalloc-2.2.5

loading:0

aof_enabled:0

changes_since_last_save:0

bgsave_in_progress:0

last_save_time:1336293648

bgrewriteaof_in_progress:0

total_connections_received:8

total_commands_processed:19

expired_keys:0

evicted_keys:0

keyspace_hits:9

keyspace_misses:2

pubsub_channels:0

pubsub_patterns:0

latest_fork_usec:1679

vm_enabled:0

role:master

db0:keys=2,expires=0

from:http://hi.baidu.com/webwatch/item/47c7e3df6f4a37f592a97456

ubuntu安装启动redis2.4.15

1、下载安装

cd /tmp
tar -zxf redis-2.4.15.tar.gz
cd redis-2.4.15
make
sudo make install

如果是新安装的操作系统,在make的时候会报找不到gcc命令,那么先执行

sudo apt-get install build-essential

这时Redis 的可执行文件被放到了/usr/local/bin

2、下载配置文件和init启动脚本:

sudo mv redis-server /etc/init.d/redis-server
sudo chmod +x /etc/init.d/redis-server
sudo mv redis.conf /etc/redis.conf

3、初始化用户和日志路径

第一次启动Redis前,建议为Redis单独建立一个用户,并新建data和日志文件夹

sudo useradd redis
sudo mkdir -p /var/lib/redis
sudo mkdir -p /var/log/redis
sudo chown redis.redis /var/lib/redis
sudo chown redis.redis /var/log/redis

4、设置开机自动启动,关机自动关闭

sudo update-rc.d redis-server defaults

5、启动Redis:

sudo /etc/init.d/redis-server start

 在启动时,因默认的配置启用虚拟内存支持会报错。把vi命令修改配置项vm-enabled no,然后再启动。

6、启动client客户端连接:

$ redis-cli
redis> set foo bar
OK
redis> get foo
"bar"