redis 复制,持久化,事务

持久化(数据存储到硬盘)

  • 有两种方式:快照 snapshotting、追加文件AOF、
  • 快照

  1、执行 快照 的两种方式(命令)

   BGSAVE:redis调用fork来创建一个子进程将快照写入硬盘,父进程继续处理请求;

   (子进程是父进程的副本,它将获得父进程数据空间、堆、栈等资源的拷贝。父子进程之间不共享这些数据,但共享代码空间)

   fork子进程,会耗费内存,尤其是数据量比较大(如几十GB),BGSAVE会导致系统停顿;

   SAVE:直接创建快照,完毕之前不会响应任何请求,会阻塞响应;    

  2、当系统发生崩溃,快照持久化有可能会丢失一部分数据,即上次快照之后的;

  • AOF

  1、配置 appendonly yes ,打开AOF

  2、同步频率,指的是强制写入磁盘的时间设置, always(每个命令),everysec(每秒),no(让操作系统来决定);

复制(服务器之间数据拷贝)

事务(pipelining 流水线)

  • 以  MULTI开始事务  ------传入多个命令--------- 以EXEC提交执行;

1、命令没有分次提交到服务器,而会成批量的提交到服务器;

2、成批量的提交可以减少通信,提高执行效率;

3、只有在EXEC命令提交后,事务的命令才会执行,这与关系数据库的实现是有区别的,在关系数据库中,多个操作是分开执行的,前置的操作对后置的操作是可见的;

  • WATCH、UNWATCH、DISCARD 命令

1、WATCH命令 可以监视 键 的替换、更新、删除等操作,它只能监视到 键 这一层级;

2、WATCH可以看作是乐观锁,它不会锁定数据不让改变,它会在数据改变是 抛出异常(redis.exceptions.WatchError) 让程序做相应的处理;

3、UNWATCH 取消WATCH命令对所有key的监视;

4、DISCARD 取消事务,取消WATCH命令,并清空所有已入队的命令;

  • 非事务型流水线

1、pipe还可用来批量提交命令提高执行效率

时间: 2025-01-01 03:48:46

redis 复制,持久化,事务的相关文章

Redis实战(八)Redis的持久化

Redis相比Memcached的很大一个优势是支持数据的持久化, 通常持久化的场景一个是做数据库使用,另一个是Redis在做缓存服务器时,防止缓存失效. Redis的持久化主要有快照Snapshotting和AOF日志文件两种方式. 前者会根据配置的规则定时将内存中的数据持久化到硬盘上, 后者则是在每次执行写命令之后将命令记录下来. >>RDB方式 Redis是会以快照的形式将数据持久化到磁盘上. 默认会将快照文件存储在Redis当前进程的工作目录的dump.rdb文件中, 可以通过配置文件

浅析 Redis 复制

摘要 早期的 RDBMS 被设计为运行在单个CPU之上,读写操作都由经单个数据库实例完成,复制技术使得数据库的读写操作可以分散在运行于不同CPU之上的独立服务器上.Redis作为一个开源的.优秀的key-value缓存及持久化存储解决方案,也提供了复制功能,本文主要介绍Redis的复制原理及特性. Redis复制概论 数据库复制指的是发生在不同数据库实例之间,单向的信息传播的行为,通常由被复制方和复制方组成,被复制方和复制方之间建立网络连接,复制方式通常为被复制方主动将数据发送到复制方,复制方接

Redis复制与可扩展集群搭建【转】

本文会讨论一下Redis的复制功能以及Redis复制机制本身的优缺点以及集群搭建问题. Redis复制流程概述 Redis的复制功能是完全建立在之前我们讨论过的基于内存快照的持久化策略基础上的,也就是说无论你的持久化策略选择的是什么,只要用到了Redis的复制功能,就一定会有内存快照发生,那么首先要注意你的系统内存容量规划,原因可以参考我上一篇文章中提到的Redis磁盘IO问题. Redis复制流程在Slave和Master端各自是一套状态机流转,涉及的状态信息是: Slave 端: REDIS

(转)Redis复制与可扩展集群搭建

讨论了Redis的常用数据类型与存储机制,本文会讨论一下Redis的复制功能以及Redis复制机制本身的优缺点以及集群搭建问题. Redis复制流程概述 Redis的复制功能是完全建立在之前我们讨论过的基于内存快照的持久化策略基础上的,也就是说无论你的持久化策略选择的是什么,只要用到了Redis的复制功能,就一定会有内存快照发生,那么首先要注意你的系统内存容量规划,原因可以参考我上一篇文章中提到的Redis磁盘IO问题. Redis复制流程在Slave和Master端各自是一套状态机流转,涉及的

Redis的持久化-AOF

Redis的持久化AOF模式,以日志的形式记录服务器所处理的每一个写操作,在Redis服务启动之初会读取该文件来重新构建数据库,以保证启动后数据库中的数据是完整的. AOF的优点: 1.可以带来更高的数据安全性. 2.由于对日志文件的写入操作采用的是append模式,因此在写入过程汇总即使出现宕机,也不会破坏日志文件中已经存在的内容,然而如果我们本次操作写入一半数据就出现系统崩溃,可以在Redis下一次启动之前,通过redis-check-aof工具帮助解决数据一致性的问题. 3.如果日志过大,

Redis复制与可扩展集群搭建

抄自:http://www.infoq.com/cn/articles/tq-redis-copy-build-scalable-cluster 讨论了Redis的常用数据类型与存储机制,本文会讨论一下Redis的复制功能以及Redis复制机制本身的优缺点以及集群搭建问题. Redis复制流程概述 Redis的复制功能是完全建立在之前我们讨论过的基于内存快照的持久化策略基础上的,也就是说无论你的持久化策略选择的是什么,只要用到了Redis的复制功能,就一定会有内存快照发生,那么首先要注意你的系统

Redis教程6--Redis事务

redis对事务的支持目前还比较简单.redis只能保证一个client发起的事务中的命令可以连续的执行,而中间不会插入其他client的命令. 由于redis是单线程来处理所有client的请求的所以做到这点是很容易的.一般情况下redis在接受到一个client发来的命令后会立即处理并 返回处理结果,但是当一个client在一个连接中发出multi命令有,这个连接会进入一个事务上下文,该连接后续的命令并不是立即执行,而是先放到一 个队列中.当从此连接受到exec命令后,redis会顺序的执行

redis使用基础(五) ——Redis数据持久化

redis使用基础(五) --Redis数据持久化 (转载请附上本文链接--linhxx) 当服务器突然发生问题,或者redis重启,如果希望将数据持久化在硬盘中,下次开启redis还有数据时,redis提供了两种方案,一个叫做RDB(通过内存快照(Snapshotting)实现),另一个叫做AOF(日志追加(Append-only file)).通常结合两种方式来实现redis的持久化. 1.RDB RDB通过内存快照实现,会将redis当前的全部数据以快照的方式写入二进制文件中.实现快照有以

Redis的持久化策略

Redis的持久化策略 Redis的持久化策略主要有两种,下面主要对每种策略的特点及应用简要总结. ○ RDB § RDB:是redis的默认持久化机制.相当于照快照.保存的不是数据,保存的是一种状态.20G数据----> 几kb快照 § 优点:快照保存数据速度极快,还原数据速度极快:适用于灾难备份,复制其中的dump.rdb文件即可. § 缺点:小内存机器不适合使用.RDB机制符合要求就会照快照.(随时随地启动),会占用一部分系统资源(突然的,就是在将大文件压缩过程中,会突然占用一部分内存),

细说Redis(二)之 Redis的持久化

原文:细说Redis(二)之 Redis的持久化 前言 在上一篇文章[细说Redis(一)之 Redis的数据结构与应用场景]中,主要介绍了Reids的数据结构. 对于redis的执行命令,这里不做介绍,因为网上搜索一堆,无必要再做介绍. AOF&RDB Redis的有两种持久化,分别是AOF.RDB. AOF是文件增量存储.RDB是文件快照.AOF是存储的是redis的每个步骤增删改的命令. 区别 在Redis内部机制来说,RDB模式首先产生一个子进程,调用fork().然后用子线程写到一个临