所谓原子操作是指不会被线程调度机制打断的操作;这种操作一旦开始,就一直运行到结束,中间不会有任何 context switch (切换到另一个线程)。
(1) 在单线程中, 能够在单条指令中完成的操作都可以认为是" 原子操作",因为中断只能发生于指令之间。
(2)在多线程中,不能被其它进程(线程)打断的操作就叫原子操作。
Redis单命令的原子性主要得益于Redis的单线程
· 是Reddis最基本的类型,你可以理解成语Memcached一模一样的类型。一个key对应一个value。
· String类型是二进制安全的。 意味着Redis的String可以包含任何数据,
· String类型是Redis最基本的数据类型,一个Redis字符串value最多可以是512M。
get |
查询对应键值 |
set |
添加键值对 |
append |
将给定的 |
strlen |
获得值得长度 |
setnx |
只有在key不存在时设置key值 |
incr |
将key中存储的数字增1; 只能对2数字值操作,如果为空,新增值为 1 |
decr |
将key中存储的数字减 1 ; 只能对2数字值操作,如果为空,新增值为 -1 |
incrby / decrby |
将key中存储的数字值增减,自定义步长 |
mset |
同时设置一个或多个key-value对 |
mget |
同时获取一个或多个value |
msetnx |
同时设置一个或多个key-value对,当且仅当所有给定key都不存在 |
getrange |
获得值得范围,类似Java中的substring |
setrange |
用 |
setex |
设置键值的时间,设置过期时间,单位秒 |
getset |
以新换旧,设置了新值同时获取旧值 |
· 单键多值
· Redis列表是最简单的字符串列表,按照插入的顺序排序。我们可以添加一个元素列表的头部(左边)或者尾部(右边)。
· 他的底层实现是个双向链表,对两端的操作性能很高,通过索引小标的操作中间的节点性能会比较差。
lpush / rpush |
从左边 / 右边 插入一个或多个值 |
lpop / rpop |
从左边 / 右边 吐出一个值 值在键在 , 值亡键亡 |
rpoplpush |
从key1列表中吐出一个值,插入到key2列表的左边 |
lrange |
按照索引下标获得元素(从左到右) |
llen |
获得列表长度 |
linsert |
在 value 前面 / 后面 插入新值 newvalue |
· 对外提供的功能与list类似是一个列表功能,特殊之处在于set可以自动排重。当需要存储一个列表且不希望有重复数据出现时,set是一个很好的选择。
· set是String的无序集合,他底层其实是一个value为null的hash表,所以添加、删除、查找的复杂度都是O(1).
sadd |
将一个或多个member元素加入到集合key当中,已经存在于集合的member元素将被忽略 |
smembers |
取出该集合的所有值 |
sismember |
判断集合 |
scard |
返回该集合的元素个数 |
srem |
删除集合中的某个元素 |
spop |
随机从该集合中吐出一个值 |
srandmember |
随机从该集合中取出 n 个值 不会删除集合中的元素 |
sinter |
返回两个集合的交集元素 |
sunion |
返回两个集合的并集元素 |
sdiff |
返回两个集合的差集元素 |
· 是一个键值对集合
· 是一个String类型的field和value的映射表,hash特别适合用于存储对象。
· 类似Java里面的Map
· Redis有序集合zset与普通集合set非常相似。是一个没有重复元素的字符集合。
· zset的所有成员都关联了一个评分(score),这个score被用来按照从最低到最高分的方式排序集合中的成员。
· 集合的成员是唯一的,但是评分可以是重复的。
· 因为元素是有序的, 所以你也可以很快的根据评分(score)或者次序(position)来获取一个范围的元素。访问有序集合的中间元素也是非常快的,因此你能够使用有序集合作为一个没有重复成员的智能列表。
zadd |
将一个或多个member元素及其score值加入到有序集key当中 |
zrange |
返回有序集key中,下标在 带WITHSCORES,可以让分数一起和值返回到结果集。 |
zrangebyscore key min max [withscores][limit offset count] | 返回有序集key中,所有score值介于min和max之间,有序集成员按score值递增次序排序。 |
zrevrangebyscore key max min [withscores] [limit offset count] |
返回有序集key中,所有score值介于min和max之间,有序集成员按score值递减次序排序。 |
zincrby |
为元素的score加上增量 |
zrem |
删除该集合下,指定值的元素 |
zcount |
统计该集合,分数区间内的元素个数 |
zrank |
返回该值在集合中的排名,从0开始。 |
· Redis事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。
· Redis事务的主要作用就是串联多个命令防止别的命令插队
· 从输入Multi命令开始,输入的命令都会依次进入命令队列中,但不会执行,至到输入Exec后,Redis会将之前的命令队列中的命令依次执行。
· 组队的过程中可以通过discard来放弃组队。
· 组队中某个命令出现了报告错误,执行时整个的所有队列会都会被取消
· 如果执行阶段某个命令报出了错误,则只有报错的命令不会被执行,而其他的命令都会执行,不会回滚。
· 悲观锁
顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。
传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。
· 乐观锁
顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,
可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。
WATCH key [key ...] |
在执行multi之前,先执行watch key1 [key2],可以监视一个(或多个) key ,如果在事务执行之前这个(或这些) key 被其他命令所改动,那么事务将被打断。 |
unwatch | 取消 WATCH 命令对所有 key 的监视。 如果在执行 WATCH 命令之后, EXEC 命令或 DISCARD 命令先被执行了的话,那么就不需要再执行 UNWATCH 了。 |
· 单独的独立操作
事务中的所有命令都会序列化、按顺序的执行。事务在执行的过程中,不会被其他客户端发送来的请求所打断。
· 没有隔离级别的概念
队列中的命令没有提交之前都不会实际的被执行,因为事务提交前任何指令都不会被实际执行,也就不存在“事务内的查询要看到事务里的更新,
在事务外查询不能看到”这个让人万分头痛的问题
· 不保证原子性
Redis同一个事务中如果有一条命令执行失败,其后的命令仍然会被执行,没有回滚
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。
· 备份的执行方式
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。
整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式
更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
· 关于fork
在Linux程序中,fork()会产生一个和父进程完全相同的子进程,但子进程在此后多会exec系统调用,出于效率考虑,Linux中引入了“写时复制技术”,
一般情况父进程和子进程会共用同一段物理内存,只有进程空间的各段的内容要发生变化时,才会将父进程的内容复制一份给子进程。
· RDB的保存策略
· 手动保存快照
· 命令save:只管保存,其他的不管,全部阻塞。
· save vs bgsave
stop-writes-on-bgsave-error yes
当Redis无法写入磁盘的话,直接关掉Redis的写操作
rdbcompression yes
进行rdb保存时,将文件压缩
rdbchecksum yes
在存储快照后,还可以让Redis使用CRC64算法来进行数据校验,但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能
· RDB的备份
· 先通过config get dir 查询rdb文件的目录
· 将*.rdb的文件拷贝到别的地方
· RDB的恢复
· 关闭Redis
· 先把备份的文件拷贝到工作目录下
· 启动Redis, 备份数据会直接加载
以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,Redis启动之初会读取该文件重新构建数据,
换言之,Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
· AOF默认不开,需要进行手动配置
1、AOF文件故障备份
AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样,都是拷贝备份文件,需要恢复时再拷贝到Redis工作目录下,启动系统即加载。
2、AOF和RDB同时开启,系统默认取AOF的数据
3、AOF文件故障恢复
· AOF文件的保存路径,同RDB的路径一致。
· 如遇到AOF文件损坏,可通过
redis-check-aof --fix appendonly.aof 进行恢复
4、AOF同步频率设置
· 始终同步,每次Redis的写入都会立刻记入日志
· 每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失。
· 把不主动进行同步,把同步时机交给操作系统。
5、Rewrite
AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,
只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof。
6、Redis如何实现重写?
AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),遍历新进程的内存中数据,每条记录有一条的Set语句。
重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。
· 如何重写
重写虽然可以节约大量磁盘空间,减少恢复时间。但是每次重写还是有一定的负担的,因此设定Redis要满足一定条件才会进行重写。
系统载入时或者上次重写完毕时,Redis会记录此时AOF大小,设为base_size,如果Redis的AOF当前大小>= base_size +base_size*100% (默认)
且当前大小>=64mb(默认)的情况下,Redis会对AOF进行重写。
|
RDB |
AOF |
优点 |
1、节省磁盘空间 2、恢复速度快 |
1、备份机制更稳健,丢失数据概率更低。 2、可读的日志文本,通过操作AOF稳健,可以处理误操作。 |
缺点 |
1、虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。 2、在备份周期在一定间隔时间做一次备份,所以如果Redis意外down掉的话,就会丢失最后一次快照后的所有修改。 |
1、比起RDB占用更多的磁盘空间。 2、恢复备份速度要慢。 3、每次读写都同步的话,有一定的性能压力。 4、存在个别Bug,造成恢复不能。 |
1、概念:
主从复制,就是主机数据更新后根据配置和策略,自动同步到备机的master/slaver机制,Master以写为主,Slave以读为主
2、用处:
· 读写分离,性能扩展
· 容灾快速恢复
3、复制原理
· 每次从机联通后,都会给主机发送sync指令
· 主机立刻进行存盘操作,发送RDB文件,给从机
· 从机收到RDB文件后,进行全盘加载
· 之后每次主机的写操作,都会立刻发送给从机,从机执行相同的命令
4、薪火相传
· 上一个slave可以是下一个slave的Master,slave同样可以接收其他slaves的连接和同步请求,那么该slave作为了链条中下一个的master,
可以有效减轻master的写压力,去中心化降低风险。
· 用 slaveof
· 中途变更转向:会清除之前的数据,重新建立拷贝最新的
· 风险是一旦某个slave宕机,后面的slave都没法备份
5、反客为主
· 当一个master宕机后,后面的slave可以立刻升为master,其后面的slave不用做任何修改
· 用 slaveof no one 将从机变为主机
6、哨兵模式(sentinel)
· 反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库.
7、故障恢复
· 容量不够,redis如何进行扩容
· 并发写操作,redis如何分摊
1、什么是集群
· Redis 集群实现了对Redis的水平扩容,即启动N个redis节点,将整个数据库分布存储在这N个节点中,每个节点存储总数据的1/N。
· Redis 集群通过分区(partition)来提供一定程度的可用性(availability): 即使集群中有一部分节点失效或者无法进行通讯, 集群也可以继续处理命令请求。
2、集群环境搭建
· 安装ruby环境
· 执行 yum install ruby
· 执行 yum install rubygems
· 拷贝redis-3.2.0.gem到/opt目录下
· 执行在opt目录下执行 gem install --local redis-3.2.0.gem
· 配置
· cluster-enabled yes 打开集群模式
· cluster-config-file nodes-6379.conf 设定节点配置文件名
· cluster-node-timeout 15000 设定节点失联时间,超过该时间(毫秒),集群自动进行主从切换。