Redis总结1

1. redis 和memcashed的区别  ？ 可以看https://blog.csdn.net/u013256816/article/details/51146314

（1）支持的数据类型 redis与memcached相比，比仅支持简单的key-value数据类型，同时还提供list,set,zset,hash等数据结构的存储

（2）memcached不支持内存数据的持久化操作，所有的数据都以in-memory的形式存储。 
      redis支持持久化操作

 （3）（内存管理）在Redis中，并不是所有的数据都一直存储在内存中的。这是和Memcached相比一个最大的区别。

 （4）（数据一致性）Memcached提供了cas命令，可以保证多个并发访问操作同一份数据的一致性问题。 Redis没有提供cas 命令，并不能保证这点，不过Redis提供了事务的功能，可以保证一串 命令的原子性，中间不会被任何操作打断。

（5）memcached是多线程，非阻塞IO复用的网络模型

edis使用单线程的IO复用模型，

2. redis数据结构

3. redis是单线程的吗

redis使用单线程的IO复用模型，自己封装了一个简单的AeEvent事件处理框架，主要实现了epoll, kqueue和select，对于单存只有IO操作来说，单线程可以将速度优势发挥到最大，但是redis也提供了一些简单的计算功能，比如排序、聚合等，对于这些操作，单线程模型施加会严重影响整体吞吐量，CPU计算过程中，整个IO调度都是被阻塞的。

4. redis 是如何存储一个String的

5. redis的部署方式 主从和集群

6. redis的哨兵模式  一个key如何再redis集群找到存储在哪里

7. redis持久化策略
8.redis的aof太大如何优化

AOF重写：
(1) 随着AOF文件越来越大，里面会有大部分是重复命令或者可以合并的命令（100次incr = set key 100）
(2) 重写的好处：减少AOF日志尺寸，减少内存占用，加快数据库恢复时间。

9.zset的底层数据结构,跳跃表如何实现
10.redis如何持久化RDB

 

（1）由于数据库持久化主要是面向磁盘，而磁盘的读写比较慢，在一般的系统上不存在高并发问题，

但是在互联网，如一些商品抢购的情况下，需要系统在很短的时间内完成千万次的读写操作，这个时候不是传统的数据库可以支撑的，极其容易造成数据库系统的瘫痪

Redis是一种基于内存的数据库，并提供一定的持久化能力。支持集群 分布式  每秒十几万次的读写操作 

还支持一定的事务能力 这在高并发访问的场景下保证数据安全和一致性特别有用

使用的时候？考虑三个方面

业务数据常用吗？

该业务读操作多还是写操作多   如果写操作多 就没必要使用缓存

业务数据大小怎么样？如果要存储上百兆的文件 会给缓存带来比较大的压力

（2）当第一次读取数据时 读取Redis的数据会失败，此时触发程序读取数据库，把数据读取出来  并且写入Redis

  第二次就是直接读取Redis

高并发场景下   请求--Redis---判断高速读写业务结束----批量写入数据库

 

 

1.  Redis的启动和安装

Redis是c语言开发的。

安装redis需要c语言的编译环境。如果没有gcc需要在线安装。yum install gcc-c++

安装步骤：

第一步：redis的源码包上传到linux系统。

第二步：解压缩redis。

第三步：编译。进入redis源码目录。make

第四步：安装。make install PREFIX=/usr/local/redis

PREFIX参数指定redis的安装目录。一般软件安装到/usr目录下

2. Redis的启动

前端启动：在redis的安装目录下直接启动redis-server

[root@localhost bin]# ./redis-server

后台启动：

把/root/redis-3.0.0/redis.conf复制到/usr/local/redis/bin目录下

[root@localhost redis-3.0.0]# cp redis.conf /usr/local/redis/bin/

修改配置文件

[root@localhost bin]# ./redis-server redis.conf

查看redis进程：

[root@localhost bin]# ps aux|grep redis

root      5190  0.1  0.3  33936  1712 ?        Ssl  18:23   0:00 ./redis-server *:6379   

root      5196  0.0  0.1   4356   728 pts/0    S+   18:24   0:00 grep redis

[root@localhost bin]#

[root@localhost bin]# ./redis-cli

默认连接localhost运行在6379端口的redis服务。

[root@localhost bin]# ./redis-cli -h 192.168.25.153 -p 6379

-h：连接的服务器的地址   -p：服务的端口号

关闭redis：[root@localhost bin]#  ./redis-cli shutdown

2.  Redis的数据类型

支持6种数据结构： String 字符串   List列表    Set集合   Hash哈希散列表   ZSet（有序列表） HyperLogLog 基数（作用是计算重复的值）

常用的命令：

3. Redis持久化

一种是RDB  一种是 AOF

RDB： 默认，该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘

优点：一旦使用，Redis数据库将只包含一个文件  这对于文件备份的，一旦系统出现灾难性的故障，容易恢复

    可以由子线程完成持久化的工作，，避免了在服务进程进行IO操作，性能比较好

 缺点： 高可用性较差，要保证高可用（即最大限度避免数据丢失），系统如果在定时持久化之前宕机了  之前的数据容易丢失

由于RDB是fork子线程来协助数据持久化的   当数据集较大时  可能导致服务器停止服务几百毫秒

AOF：优点：Redis提供了三种同步策略 每秒同步 每修改同步 不同步  每修改同步（同步持久化，每次发生的数据变化都被记录到磁盘）

可以带来更高的数据安全性

该机制对日志文件的写入是append模式， 即使写入过程出现宕机，也不会破坏原有的内容

如果日志过大

Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集 合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务 器。
Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。 

由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。那么这两种持久化方式有什么区别呢，改如何选择呢？网上看了大多数都是介绍这两种方式怎么配置，怎么使用，就是没有介绍二者的区别，在什么应用场景下使用。

2、二者的区别

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

 

AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

 

3、二者优缺点

RDB存在哪些优势呢？

1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。

2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB又存在哪些劣势呢？

1). 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

2). 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF的优势有哪些呢？

1). 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。

2). 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

3). 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。

4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

AOF的劣势有哪些呢？

1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。

4、常用配置

RDB持久化配置

Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：

save 900 1              #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。

save 300 10            #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。

save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

AOF持久化配置

在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always     #每次有数据修改发生时都会写入AOF文件。

appendfsync everysec  #每秒钟同步一次，该策略为AOF的缺省策略。

appendfsync no          #从不同步。高效但是数据不会被持久化。

3. 搭建Redis集群