rdb

原文链接： 深入学习Redis（2）：持久化 Redis的5种对象类型（字符串、哈希、列表、集合、有序集合） 查看内存方法：info memory 内存碎片 是Redis在分配、回收物理内存过程中产生的。例如，如果对数据的更改频繁，而且数据之间的大小相差很大，可能导致redis释放的空间在物理内存中并没有释放，但redis又无法有效利用，这就形成了内存碎片。内存碎片不会统计在used_memory中。 内存碎片的产生与对数据进行的操作、数据的特点等都有关；此外，与使用的内存分配器也有关系：如果内存分配器设计合理，可以尽可能的减少内存碎片的产生。后面将要说到的jemalloc便在控制内存碎片方面做的很好。 解决内存碎片： 如果Redis服务器中的内存碎片已经很大，可以通过 安全重启的方式减小内存碎片 ：因为重启之后，Redis重新从备份文件中读取数据，在内存中进行重排，为每个数据重新选择合适的内存dan元，减小内存碎片。 jemalloc作为Redis的默认内存分配器，在减小内存碎片方面做的相对比较好。jemalloc在64位系统中，将内存空间划分为小、大、巨大三个范围；每个范围内又划分了许多小的内存块单位；当Redis存储数据时，会选择大小最合适的内存块进行存储。 jemalloc划分的内存dan元如下图所示： 在Redis中，实现高可用的技术主要包括持久化、复制、哨兵和集群

Redis主要有哪些功能？ 1.哨兵（Sentinel）和复制（Replication） Redis服务器毫无征兆的罢工是个麻烦事，如何保证备份的机器是原始服务器的完整备份呢？这时候就需要哨兵和复制。 Sentinel可以管理多个Redis服务器，它提供了监控，提醒以及自动的故障转移的功能，Replication则是负责让一个Redis服务器可以配备多个备份的服务器。 Redis也是利用这两个功能来保证Redis的高可用的 2.事务 很多情况下我们需要一次执行不止一个命令，而且需要其同时成功或者失败。redis对事务的支持也是源自于这部分需求，即支持一次性按顺序执行多个命令的能力，并保证其原子性。 3.LUA脚本 在事务的基础上，如果我们需要在服务端一次性的执行更复杂的操作（包含一些逻辑判断），则lua就可以排上用场了 4.持久化 redis的持久化指的是redis会把内存的中的数据写入到硬盘中，在redis重新启动的时候加载这些数据，从而最大限度的降低缓存丢失带来的影响。 5.集群（Cluster） 单台服务器资源的总是有上限的，CPU资源和IO资源我们可以通过主从复制，进行读写分离，把一部分CPU和IO的压力转移到从服务器上，这也有点类似mysql数据库的主从同步。 在Redis官方的分布式方案出来之前，有twemproxy和codis两种方案

Redis主要有哪些功能？ 1.哨兵（Sentinel）和复制（Replication） Redis服务器毫无征兆的罢工是个麻烦事，如何保证备份的机器是原始服务器的完整备份呢？这时候就需要哨兵和复制。 Sentinel可以管理多个Redis服务器，它提供了监控，提醒以及自动的故障转移的功能，Replication则是负责让一个Redis服务器可以配备多个备份的服务器。 Redis也是利用这两个功能来保证Redis的高可用的 2.事务 很多情况下我们需要一次执行不止一个命令，而且需要其同时成功或者失败。redis对事务的支持也是源自于这部分需求，即支持一次性按顺序执行多个命令的能力，并保证其原子性。 3.LUA脚本 在事务的基础上，如果我们需要在服务端一次性的执行更复杂的操作（包含一些逻辑判断），则lua就可以排上用场了 4.持久化 redis的持久化指的是redis会把内存的中的数据写入到硬盘中，在redis重新启动的时候加载这些数据，从而最大限度的降低缓存丢失带来的影响。 5.集群（Cluster） 单台服务器资源的总是有上限的，CPU资源和IO资源我们可以通过主从复制，进行读写分离，把一部分CPU和IO的压力转移到从服务器上，这也有点类似mysql数据库的主从同步。 在Redis官方的分布式方案出来之前，有twemproxy和codis两种方案

切换事务日志文件的时机，实际是生成快照文件的时机 ZK 的数据与存储中，有几个特别关注点： 内存数据 与 磁盘数据 间的关系： 内存数据，是真正提供服务的数据 磁盘数据，作用： 恢复内存数据，恢复现场 数据同步：集群内，不同节点间的数据同步（另，内存中的提议缓存队列 proposals） 磁盘数据，为什么同时包含：快照、事务日志？出于数据粒度的考虑 如果只包含快照，那恢复现场的时候，会有数据丢失， 因为生成快照的时间间隔太大，即，快照的粒度太粗了 事务日志，针对每条提交的事务都会 flush 到磁盘， 因此粒度很细，恢复现场时，能够恢复到事务粒度上 快照生成的时机：基于阈值，引入随机因素 解决的关键问题：避免所有节点同时 dump snapshot， 因为 dump snapshot 耗费大量的 磁盘 IO、CPU， 所有节点同时 dump 会严重影响集群的对外服务能力 countLog > snapCount/2 + randRoll ，其中： countLog 为累计执行事务个数 snapCount 为配置的阈值 randRoll 为随机因素（取值：0～snapCount/2） ZK 的 快照文件是 Fuzzy 快照，不是精确到某一时刻的快照，而是某一时间段内的快照 ZK 使用「异步线程」生成快照： 线程之间共享内存空间，导致 Fuzzy 快照 这就要求 ZK

昨天下午刚到公司，开发告诉我有个页面打不开。后面经过排查排除代码的问题，开始怀疑是不是redis出问题了，后面尝试着重启了一下redis，结果问题解决了。当时因为redis没有配日志文件，所以。。。 等到今天早上又出现同样的问题了，不过依然没有日志，所以后面我在服务器里配置了日志，然后就不停对坐在我对面的开发说：马丹，服务器怎么还不出问题...... 刚刚（2017-01-12 16：42）终于又出现这个问题了，我本着无比鸡冻的眼神看了眼日志 13718:M 12 Jan 14:21:30.150 # Background saving error 13718:M 12 Jan 14:21:36.064 * 1 changes in 900 seconds. Saving... 13718:M 12 Jan 14:21:36.064 * Background saving started by pid 18396 18396:C 12 Jan 14:21:36.065 # Failed opening .rdb for saving: Permission denied 13718:M 12 Jan 14:21:36.165 # Background saving error 13718:M 12 Jan 14:21:42.078 * 1 changes in 900

一、介绍 之前我们讲解了Redis的结构与指令，其实很简单，我也没有过多的讲解，这次我们讲解一下Redis连接客户端以及持久化方案。 1、上文中我们针对redis的数据操作都是在服务器中使用命令执行的，当然这个也是非常安全的处理方式，那么在开发的阶段为了方便我们可是使用可视化界面连接redis， 比如RedisDesktopManager 这个软件等，方便我们快速的操作数据，下面的介绍也是依据这个软件进行的。 2、 针对与Redis 大家肯定也知道，redis的数据是保存在内存的，但是一旦把redis关闭则数据就会丢失，为了防止数据丢失，那么我就需要数据持久化到硬盘上，在此提供了两种持久化方案： 第一种是 RDB 快照的形式，第二种是 AOF 类似日志追加的方式。 那么我就快速的带大家了解一下 二、Redis客户端连接 1、前提说明一下：此方案只允许测试的时候配置，其他情况禁止使用 2、我们进入Redis的文件夹中，新建一个redis配置文件，文件名为： redis.custom.conf，然后在里面如下内容： 配置中的bind 代表绑定 本服务器的IP，在生产环境中禁止使用 0.0.0.0 ，此IP代表服务器内所有的IP都可以被外网进行连接；在生产环境中我们推荐使用绑定具体的内网IP，如我的IP为：192.168.250.132 daemonize yes port 6666

Redis简介 REmote DIctionary Server(Redis) Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。通常被称为数据结构服务器，值（value）可以是 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有序集合(sorted sets)等类型。支持主从模式的数据备份。拥有极高的读写性能，丰富的数据类型，原子性操作，还支持pub/sub，通知，key过期等特性。 与其他k-v存储的区别，redis有更为复杂的数据结构并且对他们提供原子性操作，redis运行在内存但支持持久化，持久化是以追加的方式产生的。 Redis是一个开源的高性能键值对数据库.它通过提供多种键值数据类型来适应不同场景下的存储需求,并且借助许多高层级的接口使其可以胜任,如缓存、队列系统的不同角色.将键值对数据类型存放在内存中的一个数据库。 单机安装 #挂载ISO操作系统光盘 [root@MySQLNODE02 /]# mount -t iso9660 /dev/cdrom /mnt/ #确认是否挂载成功 [root@MySQLNODE02 /]# df -h Filesystem Size Used Avail Use% Mounted on /dev

1. 认识主从复制 1. 单机部署Redis的问题：首先是如果机器故障（突然断电或者机器宕机），那么数据就会大量丢失；其次就是单机Redis的容量会有瓶颈，受限于机器的内存空间；每秒的请求处理数也会受到单机Redis的限制，尽管Redis每秒的请求处理数可以很高，但在大型应用中仍然是远远不够的。为了解决这些问题，实现高可用，Redis提供了一个主从复制的功能，来实现集群式部署Redis 2. 简单了解主从复制的模型：主从复制，会有一个主节点和多个从节点，每一个节点都是一个Redis，而且每一个Redis节点都能给客户端提供Redis的服务，主从复制就是从主Redis节点中复制数据到从Redis节点，如果主节点进行一个数据更新操作，那么从节点也会进行一个相同的操作。主从复制通过RDB文件来实现。 3. 主从复制的作用： 数据副本：避免单机部署中机器故障造成的数据丢失，而且如果主节点宕机，从节点就会提供支援代替主节点向客户端提供服务。 扩展性能：读写操作分离，大量的对主节点进行读写操作会造成很大的性能负担，可以将读操作分流到多个从节点中，这样就可以极大的提升读操作的性能。 4. 主从复制的特点： 只能一个主节点对于多个从节点，一对多的关系 数据只能从主节点复制到从节点，数据流是单向的 2. 主从复制的实现配置 1. 有两种实现方式：分别是通过运行命令来实现

Redis 和 Memcache 都是基于内存的数据存储系统。Memcached是高性能分布式内存缓存服务；Redis是一个开源的key-value存储系统。与Memcached类似，Redis将大部分数据存储在内存中，支持的数据类型包括：字符串、哈希 表、链表等数据类型的相关操作。下面我们来进行来看一下redis和memcached的区别。 权威比较 Redis的作者Salvatore Sanfilippo曾经对这两种基于内存的数据存储系统进行过比较： Redis支持服务器端的数据操作：Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作，通常在Memcached里，你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。所以，如果需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。 内存使用效率对比：使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。 性能对比：由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高

背景 Redis 作为一款简洁、高效的开源K/V数据库，可以被用于内存缓存、持久化存储等不同场景，大量服务于各类互联网应用。同时也提供了丰富的功能配置，客户可以根据各自业务需求，在读写性能、缓存容量、数据可靠性等方面作出灵活的选择。 Redis提供了RDB和AOF两种持久化方式供选择，4.0中更是引入了RDB-AOF混合持久化的方式，整合RDB和AOF的优势，提供更实时的数据持久化保证、更快的恢复速度和更紧凑的空间使用。针对AOF的写入， Redis 提供了两种选项供选择： • always：aoflog实时写入落盘，保证写入数据的安全性，但写入性能下降严重。 • everysec：buffer写入aoflog，后台定期刷盘，可以很好的保证写入性能，但在failure场景下，需要承担秒级新写入数据丢失的风险。 这两种模式需要用户在性能和数据安全性之间做出取舍，鱼和熊掌无法兼得。对一些对数据安全性有更高要求的场景，需要应用层协同来保证数据安全，会给系统设计和实现带来一定的复杂度。另一方面，在Redis发生failover的时候，会有一个缓存预热重建的过程，期间对应用会有一个可感知的不可服务时间、以及访问延时抖动。 关于上述问题，很重要的一个原因在于目前DRAM和SSD（请忽略HDD）之间巨大的性能鸿沟。近几年，备受学术界和工业界关注的NVM（ Non-volatile Memory