码迷,mamicode.com
首页 > 其他好文 > 详细

Redis 详解

时间:2019-12-02 18:57:32      阅读:75      评论:0      收藏:0      [点我收藏+]

标签:存储   eth   字符串转换   库文件   哨兵   大数   arch   恢复备份   提交   

 

来自:https://www.cnblogs.com/lixinjie/p/a-key-point-of-redis-in-interview.html

 

是数据结构而非类型

 


很多文章都会说,redis支持5种常用的数据类型,这其实是存在很大的歧义。redis里存的都是二进制数据,其实就是字节数组(byte[]),这些字节数据是没有数据类型的,只有把它们按照合理的格式解码后,可以变成一个字符串,整数或对象,此时才具有数据类型。

这一点必须要记住。所以任何东西只要能转化成字节数组(byte[])的,都可以存到redis里。管你是字符串、数字、对象、图片、声音、视频、还是文件,只要变成byte数组。

因此redis里的String指的并不是字符串,它其实表示的是一种最简单的数据结构,即一个key只能对应一个value。这里的key和value都是byte数组,只不过key一般是由一个字符串转换成的byte数组,value则根据实际需要而定。

在特定情况下,对value也会有一些要求,比如要进行自增或自减操作,那value对应的byte数组必须要能被解码成一个数字才行,否则会报错。

那么List这种数据结构,其实表示一个key可以对应多个value,且value之间是有先后顺序的,value值可以重复。

Set这种数据结构,表示一个key可以对应多个value,且value之间是没有先后顺序的,value值也不可以重复。

Hash这种数据结构,表示一个key可以对应多个key-value对,此时这些key-value对之间的先后顺序一般意义不大,这是一个按照名称语义来访问的数据结构,而非位置语义。

Sorted Set这种数据结构,表示一个key可以对应多个value,value之间是有大小排序的,value值不可以重复。每个value都和一个浮点数相关联,该浮点数叫score。元素排序规则是:先按score排序,再按value排序。

相信现在你对这5种数据结构有了更清晰的认识,那它们的对应命令对你来说就是小case了。

 

集群带来的问题与解决思路



集群带来的好处是显而易见的,比如容量增加、处理能力增强,还可以按需要进行动态的扩容、缩容。但同时也会引入一些新的问题,至少会有下面这两个。

一是数据分配:存数据时应该放到哪个节点上,取数据时应该去哪个节点上找。二是数据移动:集群扩容,新增加节点时,该节点上的数据从何处来;集群缩容,要剔除节点时,该节点上的数据往何处去。

上面这两个问题有一个共同点就是,如何去描述和存储数据与节点的映射关系。又因为数据的位置是由key决定的,所以问题就演变为如何建立起各个key和集群所有节点的关联关系。

集群的节点是相对固定和少数的,虽然有增加节点和剔除节点。但集群里存储的key,则是完全随机、没有规律、不可预测、数量庞多,还非常琐碎。

这就好比一所大学和它的所有学生之间的关系。如果大学和学生直接挂钩的话,一定会比较混乱。现实是它们之间又加入了好几层,首先有院系,其次有专业,再者有年级,最后还有班级。经过这四层映射之后,关系就清爽很多了。

这其实是一个非常重要的结论,这个世界上没有什么问题是不能通过加入一层来解决的。如果有,那就再加入一层。计算机里也是这样的。

redis在数据和节点之间又加入了一层,把这层称为槽(slot),因该槽主要和哈希有关,又叫哈希槽。

最后变成了,节点上放的是槽,槽里放的是数据。槽解决的是粒度问题,相当于把粒度变大了,这样便于数据移动。哈希解决的是映射问题,使用key的哈希值来计算所在的槽,便于数据分配。

可以这样来理解,你的学习桌子上堆满了书,乱的很,想找到某本书非常困难。于是你买了几个大的收纳箱,把这些书按照书名的长度放入不同的收纳箱,然后把这些收纳箱放到桌子上。

这样就变成了,桌子上是收纳箱,收纳箱里是书籍。这样书籍移动很方便,搬起一个箱子就走了。寻找书籍也很方便,只要数一数书名的长度,去对应的箱子里找就行了。

其实我们也没做什么,只是买了几个箱子,按照某种规则把书装入箱子。就这么简单的举动,就彻底改变了原来一盘散沙的状况。是不是有点小小的神奇呢。

一个集群只能有16384个槽,编号0-16383。这些槽会分配给集群中的所有主节点,分配策略没有要求。可以指定哪些编号的槽分配给哪个主节点。集群会记录节点和槽的对应关系。

接下来就需要对key求哈希值,然后对16384取余,余数是几key就落入对应的槽里。slot = CRC16(key) % 16384。

以槽为单位移动数据,因为槽的数目是固定的,处理起来比较容易,这样数据移动问题就解决了。

使用哈希函数计算出key的哈希值,这样就可以算出它对应的槽,然后利用集群存储的槽和节点的映射关系查询出槽所在的节点,于是数据和节点就映射起来了,这样数据分配问题就解决了。

我想说的是,一般的人只会去学习各种技术,高手更在乎如何跳出技术,寻求一种解决方案或思路方向,顺着这个方向走下去,八九不离十能找到你想要的答案。

 

集群对命令操作的取舍

 


客户端只要和集群中的一个节点建立链接后,就可以获取到整个集群的所有节点信息。此外还会获取所有哈希槽和节点的对应关系信息,这些信息数据都会在客户端缓存起来,因为这些信息相当有用。

客户端可以向任何节点发送请求,那么拿到一个key后到底该向哪个节点发请求呢?其实就是把集群里的那套key和节点的映射关系理论搬到客户端来就行了。

所以客户端需要实现一个和集群端一样的哈希函数,先计算出key的哈希值,然后再对16384取余,这样就找到了该key对应的哈希槽,利用客户端缓存的槽和节点的对应关系信息,就可以找到该key对应的节点了。

接下来发送请求就可以了。还可以把key和节点的映射关系缓存起来,下次再请求该key时,直接就拿到了它对应的节点,不用再计算一遍了。

理论和现实总是有差距的,集群已经发生了变化,客户端的缓存还没来得及更新。肯定会出现拿到一个key向对应的节点发请求,其实这个key已经不在那个节点上了。此时这个节点应该怎么办?

这个节点可以去key实际所在的节点上拿到数据再返回给客户端,也可以直接告诉客户端key已经不在我这里了,同时附上key现在所在的节点信息,让客户端再去请求一次,类似于HTTP的302重定向。

这其实是个选择问题,也是个哲学问题。结果就是redis集群选择了后者。因此,节点只处理自己拥有的key,对于不拥有的key将返回重定向错误,即-MOVED key 127.0.0.1:6381,客户端重新向这个新节点发送请求。

所以说选择是一种哲学,也是个智慧。稍后再谈这个问题。先来看看另一个情况,和这个问题有些相同点。

redis有一种命令可以一次带多个key,如MGET,我把这些称为多key命令。这个多key命令的请求被发送到一个节点上,这里有一个潜在的问题,不知道大家有没有想到,就是这个命令里的多个key一定都位于那同一个节点上吗?

就分为两种情况了,如果多个key不在同一个节点上,此时节点只能返回重定向错误了,但是多个key完全可能位于多个不同的节点上,此时返回的重定向错误就会非常乱,所以redis集群选择不支持此种情况。

如果多个key位于同一个节点上呢,理论上是没有问题的,redis集群是否支持就和redis的版本有关系了,具体使用时自己测试一下就行了。

在这个过程中我们发现了一件颇有意义的事情,就是让一组相关的key映射到同一个节点上是非常有必要的,这样可以提高效率,通过多key命令一次获取多个值。

那么问题来了,如何给这些key起名字才能让他们落到同一个节点上,难不成都要先计算个哈希值,再取个余数,太麻烦了吧。当然不是这样了,redis已经帮我们想好了。

可以来简单推理下,要想让两个key位于同一个节点上,它们的哈希值必须要一样。要想哈希值一样,传入哈希函数的字符串必须一样。那我们只能传进去两个一模一样的字符串了,那不就变成同一个key了,后面的会覆盖前面的数据。

这里的问题是我们都是拿整个key去计算哈希值,这就导致key和参与计算哈希值的字符串耦合了,需要将它们解耦才行,就是key和参与计算哈希值的字符串有关但是又不一样。

redis基于这个原理为我们提供了方案,叫做key哈希标签。先看例子,{user1000}.following,{user1000}.followers,相信你已经看出了门道,就是仅使用Key中的位于{和}间的字符串参与计算哈希值。

这样可以保证哈希值相同,落到相同的节点上。但是key又是不同的,不会互相覆盖。使用哈希标签把一组相关的key关联了起来,问题就这样被轻松愉快地解决了。

相信你已经发现了,要解决问题靠的是巧妙的奇思妙想,而不是非要用牛逼的技术牛逼的算法。这就是小强,小而强大。

最后再来谈选择的哲学。redis的核心就是以最快的速度进行常用数据结构的key/value存取,以及围绕这些数据结构的运算。对于与核心无关的或会拖累核心的都选择弱化处理或不处理,这样做是为了保证核心的简单、快速和稳定。

其实就是在广度和深度面前,redis选择了深度。所以节点不去处理自己不拥有的key,集群不去支持多key命令。这样一方面可以快速地响应客户端,另一方面可以避免在集群内部有大量的数据传输与合并。

 

单线程模型

 

 

redis集群的每个节点里只有一个线程负责接受和执行所有客户端发送的请求。技术上使用多路复用I/O,使用Linux的epoll函数,这样一个线程就可以管理很多socket连接。

除此之外,选择单线程还有以下这些原因:

1、redis都是对内存的操作,速度极快(10W+QPS)

2、整体的时间主要都是消耗在了网络的传输上

3、如果使用了多线程,则需要多线程同步,这样实现起来会变的复杂

4、线程的加锁时间甚至都超过了对内存操作的时间

5、多线程上下文频繁的切换需要消耗更多的CPU时间

6、还有就是单线程天然支持原子操作,而且单线程的代码写起来更简单

 

事务

 


事务大家都知道,就是把多个操作捆绑在一起,要么都执行(成功了),要么一个也不执行(回滚了)。redis也是支持事务的,但可能和你想要的不太一样,一起来看看吧。

redis的事务可以分为两步,定义事务和执行事务。使用multi命令开启一个事务,然后把要执行的所有命令都依次排上去。这就定义好了一个事务。此时使用exec命令来执行这个事务,或使用discard命令来放弃这个事务。

你可能希望在你的事务开始前,你关心的key不想被别人操作,那么可以使用watch命令来监视这些key,如果开始执行前这些key被其它命令操作了则会取消事务的。也可以使用unwatch命令来取消对这些key的监视。

redis事务具有以下特点:

1、如果开始执行事务前出错,则所有命令都不执行

2、一旦开始,则保证所有命令一次性按顺序执行完而不被打断

3、如果执行过程中遇到错误,会继续执行下去,不会停止的

4、对于执行过程中遇到错误,是不会进行回滚的

看完这些,真想问一句话,你这能叫事务吗?很显然,这并不是我们通常认为的事务,因为它连原子性都保证不了。保证不了原子性是因为redis不支持回滚,不过它也给出了不支持的理由。

不支持回滚的理由:

1、redis认为,失败都是由命令使用不当造成

2、redis这样做,是为了保持内部实现简单快速

3、redis还认为,回滚并不能解决所有问题

哈哈,这就是霸王条款,因此,好像使用redis事务的不太多


管道



客户端和集群的交互过程是串行化阻塞式的,即客户端发送了一个命令后必须等到响应回来后才能发第二个命令,这一来一回就是一个往返时间。如果你有很多的命令,都这样一个一个的来进行,会变得很慢。

redis提供了一种管道技术,可以让客户端一次发送多个命令,期间不需要等待服务器端的响应,等所有的命令都发完了,再依次接收这些命令的全部响应。这就极大地节省了许多时间,提升了效率。

聪明的你是不是意识到了另外一个问题,多个命令就是多个key啊,这不就是上面提到的多key操作嘛,那么问题来了,你如何保证这多个key都是同一个节点上的啊,哈哈,redis集群又放弃了对管道的支持。

不过可以在客户端模拟实现,就是使用多个连接往多个节点同时发送命令,然后等待所有的节点都返回了响应,再把它们按照发送命令的顺序整理好,返回给用户代码。哎呀,好麻烦呀。


协议



简单了解下redis的协议,知道redis的数据传输格式。

发送请求的协议:

*参数个数CRLF$参数1的字节数CRLF参数1的数据CRLF...$参数N的字节数CRLF参数N的数据CRLF

例如,SET name lixinjie,实际发送的数据是:

*3\r\n$3\r\nSET\r\n$4\r\nname\r\n$8\r\nlixinjie\r\n

接受响应的协议:

单行回复,第一个字节是+

错误消息,第一个字节是-

整型数字,第一个字节是:

批量回复,第一个字节是$

多个批量回复,第一个字节是*

例如,

+OK\r\n

-ERR Operation against\r\n

:1000\r\n

$6\r\nfoobar\r\n

*2\r\n$3\r\nfoo\r\

1. Redis 概述

  1. Redis:远程字典服务器(REmote DIctionary Server);
  2. Redis 是一个高性能(key/value)分布式内存数据库,基于内存运行并支持持久化的NoSQL数据库;
  3. Redis 三个特点:
    • Redis 支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候,可以再次加载进行使用;
    • Redis 不仅仅支持简单的key-value类型的数据,同时还提供list,set,zset,hash等数据结构的存储;
    • Redis 支持数据的备份,即master-slave模式的数据备份;

2. Redis 数据类型

2.1 Redis 的五大数据类型

  • String(字符串)
  • Hash(哈希,类似java里的Map)
  • List
  • Set
  • Zset(sorted set: 有序集合)

2.2 Redis 键(key)

  • set 键名 键值: 向数据库中存储键值对;
  • keys *: 查看当前数据库所有键;
  • exits 键名: 判断某个key是否存在,存在,返回"1";不存在,返回"0";
  • move 键名 数据库(例如2): 将某个键剪切至2号数据库;
  • expire key 秒: 为指定的key设置过期时间;
  • ttl key: 查看该key,还有多少秒过期,-1表示永不过期, -2表示已过期;
  • type key: 查看key的类型;

2.3 Redis 字符串(String)

  • set/get/del 键名: 设置/获取/删除;
  • append 键名(key) 值: 向key所对应的value后面添加值;
  • strlen 键名(key): 获取某个key所对应的value的字符串长度;
  • incr/decr/incrby/decrby: 一定要是数字才能进行加减;
  • getrange k2 0 3: 表示获取k2所对应的value的前四个字符;
  • setrange: 设置指定区间范围内的值;
  • setex(set with expire) 秒: 设置过期时间;
  • setnx(set if not exist)
  • mset/mget/msetnx: 设置(获取)多个, 例,mset k2 v2 k3 v3 k4 v4;
  • getset: 先get再set;

2.4 Redis 列表(List)

  • LPUSH list01 1 2 3 4 5: 存储list; "LPUSH(Left push)"
  • LRANGE list01: 获取,"5,4,3,2,1";
  • RPUSH list02 1 2 3 4 5
  • LRANGE list02: 获取, "1 2 3 4 5"
  • LPOP/RPOP
  • LINDEX: 按照索引下标获得元素(从上到下);
  • LLEN: 获取list集合的长度;
  • RUPUSH list03 1 1 1 2 2 2 3 3 3 4 4 4 5 6 7
    LREM list03 2 3: 删除list03集合中两个3(LREM, left remove);
  • LTRIM list03 0 4: 截取指定范围(0~4)的值,然后赋值给list03;
  • RPOPLPUSH 源列表 目的列表
  • LSET list03 1 x: 将list03中的下标为1的键的值设置为"x";
  • LINSERT list03 before(after) x java: 在"x"的前面(或后面)插入"java";

2.5 Redis 集合(Set)

  • SADD set01 1 1 2 2 3 3: 向set01中插入值,只会插入"1 2 3",即不允许重复;
  • SMEMBERS set01: 获取set01集合中的值
  • SISMEMBER set01 1: 判断"1"是否为集合set01成员; 如果是,返回1;不是,返回0;
  • SCARD: 获取集合里面元素个数;
  • SREM key member[memeber...]:移除集合key中的一个或多个memeber元素;
  • SRANDMEMEBER set01 3: 从set01集合中随机取三个值;
  • SPOP set01:从set01集合中,随机移除一个元素,并返回该元素;
  • SMOVE source destination memeber: 将 memeber 元素从source集合移动到destination集合;
  • SDIFF: 差集;
  • SINTER: 交集;
  • SUNION: 并集;

2.6 Redis 哈希(Hash)

  • 类似于 Map<String,Object>;
  • KV模式不变,但V是一个键值对;
  • hset user gender male: 将 user 哈希表中的gender值设为male;
  • hget user gender: 获取;
  • hmset customer id 11 name zhangsan age 22:同时将多个field-value(域-值)对设置到哈希表customer中
  • hmget customer id name age: 获取多个值;
  • hgetall customer: 获取所有的域和值;
  • hdel customer id name: 删除哈希表中的id和name域;
  • hlen customer:获取哈希表的长度;
  • hexists customer id: 查看哈希表customer中是否存在id域;
  • hkeys customer: 获取哈希表customer中的所有域;
  • hvalues customer: 获取哈希表customer中的所有域的值;
  • hincryby key field increment: 为哈希表key中的域field的值加上增量increment;
  • hincrbyfloat
  • hsetnx key field value: 当域field不存在时,将该域field的值设置为value;

2.7 Redis 有序集合(Zset,sorted set)

  • Zset 在set基础上,加上一个score值;之前set集合是:k1 v1 v2 v3,现在,Zset是k1 score1 v1 score2 v2
  • zadd key score1 mem1 score2 mem2:将一个或多个memeber元素及其score的值加入到有序集key当中;
  • zrangebyscore key 开始min 结束max: 返回有序集key中,所有score介于min和max之间;
  • zrangebysroce zset (1 5: 返回所有符合条件 1<score<=5 的成员;
  • zrem key memeber: 移除有序集key中的一个或多个成员;
  • zcard key: 返回有序集合key的基数;
  • zcount key min max: 返回有序集key中,score值在min和max之间的成员数量;
  • zrank key member: 返回有序集key中成员memeber的下标;
  • zscore key member: 返回有序集key中,成员memeber对应的score值;
  • zrevrank key member: 逆序获得成员member下标值;
  • zrevrange key 0 -1: 逆序获得有序集key的所有的member成员;
  • zrevrangebyscore

3. Redis 的持久化

  • RDB(Redis DataBase)
  • AOF(Append Only File)

3.1 RDB(Redis DataBase)

3.1.1 RDB 概述
  1. RDB: 在指定的时间间隔内,将内存中的数据集快照(snapshot)写入磁盘,它恢复时,是将快照文件直接读到内存里;
  2. Redis 会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,
    在用这个临时文件替换上次持久化好的文件;
  3. 整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能;
  4. 如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加高效;
  5. RDB 的缺点: 最后一次持久化后的数据可能丢失;
  6. RDB 保存的是 dump.rdb;
  7. RDB 是整个内存压缩过的Snapshot, RDB持久化策略,与快照触发条件一样,默认值
    • 1分钟内修改了1万次;
    • 5分钟内修改了10次;
    • 15分钟内修改了1次;
3.1.2 Fork
  • Fork的作用: 是复制一个与当前进程一样的进程;新进程的所有数据(变量,环境变量,程序计数器等)数值都和原进程
    一致,但是是一个全新的进程,并作为原进程的子进程;
3.1.3 触发RDB快照的方式(三种)
  • 配置文件中默认的快照配置,冷拷贝以后重新使用(即备份文件和要恢复备份的机器不是同一台);
  • savebgsave命令,立刻生成dump.rbd文件;
    • save时,只管保存,其他不管,全部阻塞;
    • bgsave:Redis 会在后台异步执行快照操作,快照的同时还可以响应客户端请求;可以通过lastsave命令
      获取最后一次成功执行快照的时间;
  • 执行flushall命令,也会产生dump.rdb文件,但里面是空的,无意义;
3.1.4 恢复备份文件
  • 将备份文件(dump.rdb)移动到redis安装目录并启动服务即可;
3.1.5 RDB优缺点
  • 优势:
    • 适合大规模的数据恢复;
    • 对数据完整型和一致性要求不高;
  • 劣势
    • 在一定间隔时间做一次备份,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改;
    • Fork 的适合,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑;

3.2 AOF(Append Only File)

3.2.1 AOF 概述
  1. 以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只需追加文件但不可以改写文
    件, redis启动之初会读取该文件,重新构建数据,换言之,redis重启的话,就根据日志文件的内容将写指令从前到后执行一
    次以完成数据的恢复工作;
  2. redis.conf中的配置appendonly no,即该种持久化方式默认为关闭;
  3. redis.conf中的配置appendfsync=everysec,出厂默认值,异步操作,每秒记录,若一秒内宕机,有数据丢失;
    • appendfsync=always: 同步持久化,每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好;
3.2.2 Rewrite
  1. AOF 采用文件追加方式,文件会越来越大,为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,
    Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集,可以使用命令bgrewriteaof;
  2. 重写原理:AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),遍历新进
    程的内存中数据;重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一
    个新的aof文件,这点和快照有点类似;
  3. 触发机制:Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发;
3.2.3 AOF 优势和劣势
  • 优势:
    • 同步持久化,appendfsync=always;
    • 每修改同步,appendfsync=everysec;
  • 劣势:
    • 相同数据集的数据而言,aof文件要远大于rdb文件,恢复速度慢于rdb;
    • AOF运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同;

3.3 RDB 和 AOF

  1. RDB 持久化方式能够在指定的时间间隔,对数据进行快照存储;
  2. AOF 持久化方式记录每次对服务器写的操作,当服务器重启的时候,会重新执行这些命令来恢复原始的数据,AOF 命令
    以redis协议追加保存每次写的操作到文件末尾,Redis 还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大;
  3. 同时开启两种持久化方式:
    • 在这种情况下,当redis重启的时候,会优先加载AOF文件来恢复原始的数据,因为在通常情况下,AOF文件保存的数
      据集要比RDB文件保存的数据集完整;

4. Redis 的事务

4.1 事务
- 事务本质上是一组命令的集合;一个事务中的所有命令都会序列化,按顺序地串行化执行而不会被其他命令插入,不许加塞;
4.2 常用命令
- MULTI: 标记一个事务块的开始;
- EXEC: 执行所有事务块内的命令;
- DISCARD: 取消事务,放弃执行事务块内的所有命令;
- WATCH: 监控一个(或多个)key,如果在事务执行之前,这个(或这些)key被其他命令所改动,那么事务将被打断;
- UNWATCH: 取消WATCH命令对所有key的监视;

4.3 事务的执行情况:
- 正常执行
- 放弃事务
- 全体连坐:不管命令正确错误,都不执行;
- 冤头债主:错误的命令不执行,正确的命令执行;
- watch监控

4.4 Redis 事务的三阶段
- 开启: 以MULTI开始一个事务;
- 入队: 将多个命令入队到事务中,接到这些命令并不会立即执行,而是放到等待执行的事务队列里面;
- 执行: 以EXEC命令触发事务;

4.5 Redis 事务的三个特性
- 单独的隔离操作:事务中的所有命令都会序列化,按顺序地执行;事务在执行的过程中,不会被其他客户端发送来的命令请求所打断;
- 没有隔离级别的概念:队列中的命令,在没有提交之前不会实际的被执行,因为事务提交前任何指令都不会被实际执行,
也就不存在"事务内的查询要看到事务里的更新,在事务外查询不能看到"这个让人万分头痛的问题;
- 不保证原子性:redis同一个事务中,如果有一条命令执行失败,其他的命令仍然会被执行,没有回滚;

5. Redis 的发布/订阅

  • Redis 的发布/订阅:进程间的一种信息通信模式,发送者(pub)发送消息,订阅者(sub)接收消息;

6. Redis 主从复制(Master/Slave)

6.1 概述
  • 主从复制: 主机数据更新后,根据配置和策略,自动同步到备机的master/slave机制,Master以写为主,Slave以读为主;
6.2 应用
  1. 读写分离
  2. 容灾备份
6.3 使用方法
  1. 配从(库)不配主(库);
  2. 从库配置: slaveof 主库IP 主库端口
    • 每次与master断开之后,都需要重新连接,除非配置进redis.conf文件;
    • info replication: 查看当前库的状态;
  3. 修改配置文件
    • 拷贝多个 redis.conf 文件;
    • 设置 daemonize yes, Pid 文件名字, 指定端口, Log文件的名字, Dump.rbd名字;
  4. 常用3招
    • 一主二从(一个Master,两个Slave)
    • 薪火相传
      • 上一个Slave可以是下一个Slave的Master,Slave同样可以接收其他Slaves的连接和同步请求,那么,该
        Slave就是下一个Slave的Master,这样,可以有效减轻master的写压力;
      • 中途变更转向:会清除之前的数据,重新建立拷贝最新的; slaveof 新主库IP 新主库端口;
    • 反客为主
      • slaveof no one
      • 使当前数据库停止与其他数据库的同步,转成主数据库;
  5. 复制原理
    • slave 成功连接到master后,会发送一个sync命令;
    • Master 接到命令,启动后台的存盘进程,同时,收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后,
      master 将传送整个数据文件到slave,以完成一次完全同步;
    • 全量复制:slave 服务在接收到数据库文件数据后,将其存盘并加载到内存中;
    • 增量复制:Master继续将新的所有收集到的修改命令依次传给slave,完成同步;
    • 但是,只要是重新连接master,一次完全同步(全量复制)将被自动执行;
    • 复制的缺点:复制的延时;由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步
      到slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重;
  6. 哨兵模式(Sentinel)
    • "反客为主"的自动版,能够后台监控主机是否故障,如果发生故障,根据投票数自动将从库转换为主库;
    • 使用步骤
    • 一个sentinel能同时监控多个Master;

7. Jedis 使用

7.1 导 jar 包
  • Commons-pool-1.6.jar
  • Jedis-2.1.0.jar
7.2 编写测试类
// TestJedis.java
public class TestJedis{

    public static void main(String[] args){

        // 建立连接
        Jedis jedis = new Jedis("127.0.0.1",6379);

        // 1. 测试连通性
        System.out.println(jedis.ping());

        // 2. Redis 常用API
        // 执行添加操作
        jedis.set("k1","v1");
        jedis.set("k2","v2");
        jedis.set("k3","v3");

        // 获取
        System.out.println(jedis.get("k1"));

        // 获取所有
        Set<String> sets = jedis.keys("*"))
        System.out.println(sets);

        // 3. 事务操作
        // 开启事务
        Transaction transaction = jedis.multi();

        transaction.set("k11","v11");
        transaction.set("k12","v12");

        // 提交事务: transaction.exec();
        // 回滚事务:
        transaction.discard();

        // 3.1 事务加锁(watch 命令)
        // watch 命令就是标记一个键,如果标记了一个键,在提交事务前,如果该键被别人修改过,那事务
        // 就会失败,这种情况通常可以在程序中重新再尝试一次;
        TestJedis test = new TestJedis();
        boolean retValue = test.transMethod();
        System.out.println("事务执行情况:"+retValue);

        // 4. 主从复制(主写,从读)
        Jedis jedis_M = new Jedis("127.0.0.1",6380);
        Jedis jedis_S = new Jedis("127.0.0.1",6381);

        jedis_S.slaveof("127.0.0.1",6380);

        jedis_M.set("name","zhangsan");
        System.out.println(jedis_S.get("name"));
    }

    // 3.1 事务中调用的方法
    public boolean transMethod(){
        Jedis jedis = new Jedis("127.0.0.1",6379);
        int balance; //可用余额
        int debt; // 欠额
        int amtToSubtract = 10; // 实刷额度

        // watch 监控
        jedis.watch("balance");
        balace = Integer.parseInt(jedis.get("balance"));
        if(balance < amtToSubtract){
            jedis.unwatch();
            System.out.println("余额不足,请充值");
            return false;
        } else {
            System.out.println("#############transaction 开始");
            Transaction transaction = jedis.multi();
            transaction.decrBy("balance",amtToSubtract);
            transaction.incrBy("debt",amtToSubtract);
            transaction.exec();
            balance = Integer.parseInt(jedis.get("balance"));
            debt = Integer.parseInt(jedis.get("debt"));

            System.out.println("########"+balace);
            System.out.println("##########"+debt);
            return true;
        }
    }
}
7.3 JedisPool
// JedisPoolUtil.java
public class JedisPoolUtil{

    // 连接池,单例设计模式
    private static volatile JedisPool jedisPool = null;

    private JedisPoolUtil(){};

    public static JedisPool getJedisPoolInstance(){

        if(null == jedisPool){
            // 同步代码块
            synchronized(jedisPoolUtil.class){
                if(null == jedisPool){
                    // 连接池配置
                    JedisPoolConfig poolConfig = new JedisPoolConfig();
                    poolConfig.setMaxActive(1000);
                    poolConfig.setMaxIdle(32);
                    poolConfig.setMaxWait(100*1000);

                    // 获得一个jedis实例的时候,是否检查连接可用性
                    poolConfig.setTestOnBorrow(true);

                    jedisPool = new JedisPool(poolConfig,‘127.0.0.1‘,6379);
                }
            }
        }

        return jedisPool;
    }

    // 将连接归还连接池
    public static void release(JedisPool jedisPool,Jedis jedis){
        if(null != jedis){
            jedisPool.returnResourceObject(jedis);
        }
    }
}

// 测试类
public class TestPool{
    public static void main(String[] args){

        JedisPool jedisPool = JedisPoolUtil.getJedisPoolInstance();
        Jedis jedis = null;

        try{
            jedis = jedisPool.getResrouce();
            jedis.set("name","lisi");

        }catch(Exception e){
            e.printStackTrace();
        }finally{
            // 释放连接
            jedisPoolUtil.release(jedisPool,jedis);
        }
    }
}


参考资料

n$3\r\nbar\r\n

可见redis的协议设计的非常简单。

Redis 详解

标签:存储   eth   字符串转换   库文件   哨兵   大数   arch   恢复备份   提交   

原文地址:https://www.cnblogs.com/abdm-989/p/11972473.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!