1.Redis是什么?为什么要用Redis (或noSql)?
NoSQL是Not only SQL的缩写,大意为“不只是SQL”,说明这项技术是传统关系型数据库的补充而非替代。在整个NoSQL技术栈中MemCache、Redis、MongoDB被称为NoSQL三剑客。
Redis 是一个开源(BSD许可)的,内存中的数据结构存储系统,它可以用作数据库、缓存和消息中间件。 它支持多种类型的数据结构,如 字符串(strings), 散列(hashes), 列表(lists), 集合(sets), 有序集合(sorted sets) 与范围查询, bitmaps, hyperloglogs 和 地理空间(geospatial) 索引半径查询。 Redis 内置了 复制(replication),LUA脚本(Lua scripting), LRU驱动事件(LRU eviction),事务(transactions) 和不同级别的 磁盘持久化(persistence), 并通过 Redis哨兵(Sentinel)和自动 分区(Cluster)提供高可用性(high availability)。
2.Redis的基本操作
启动/usr/local/redis/bin/redis-server
停止服务/usr/local/redis/bin/redis-cli shutdown
准备配置文件cp /opt/redis-4.0.2/redis.conf /usr/local/redis/
redis-server文件路径 redis.conf文件路径
/usr/local/redis/bin/redis-server /usr/local/redis/redis.conf
(1)连接数据库:切换数据库select、清空当前库、查看数据库个数、通杀数据库
(2)key的操作:Redis中以key-value键值对为基本存储方式,其中key为字符串
(3)常用五大数据类型:String、List、Set、hash、zset
字符串、可重复集合、不可重复集合、类似Map<String,String>、带分数的set
(4)String操作
Redis中最基本的类型,它是key对应的一个单一值。二进制安全,不必担心由于编码等问题导致二进制数据变化。所以redis的string可以包含任何数据,比如jpg图片或者序列化的对象。Redis中一个字符串值的最大容量是512M。
(5)List操作
Redis 列表是简单的字符串列表,按照插入顺序排序。你可以添加一个元素到列表的头部(左边)或者尾部(右边)。说明它的底层是基于链表实现的,所以它操作时头尾效率高,中间效率低。
(6)Set操作
Redis的set是string类型的无序集合。它是基于哈希表实现的。
(7)Hash操作
本身就是一个键值对集合。可以当做Java中的Map<String,Object>对待。
(8)zset操作
Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。
不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。zset的成员是唯一的,但分数(score)却可以重复。
3.配置Redis
单位说明:1k和1kb是不同的:单位的大小写不敏感
include:可以将公共的配置放入到一个公共配置文件中,然后通过自配置文件引入父配置文件中的内容。将配置按照模块分开。
network:bind限定访问的主机地址
general:
其他:
4.什么是持久化?
Redis工作时数据都存储在内存中,万一服务器断电,则所有数据都会丢失。针对这种情况,Redis采用持久化机制来增强数据安全性。
5.RDB详解
RDB机制:每隔一定的时间把内存中的数据作为一个快照保存到硬盘上的文件中。Redis默认开启RDB机制。
6.AOF详解
AOF机制:根据配置文件中指定的策略,把生成数据的命令保存到硬盘上的文件中。
AOF重写
两组命令执行后对于count来说最终的值是一致的,但是进行AOF重写后省略了中间过程,可以让AOF文件体积更小。而Redis会根据AOF文件的体积来决定是否进行AOF重写。参考的配置项如下:
实际工作中不要进行频繁的AOF重写,因为CPU资源和硬盘资源二者之间肯定是CPU资源更加宝贵,所以不应该过多耗费CPU性能去节省硬盘空间。
7.RDB与AOF的取舍
①RDB
[1]优势
适合大规模的数据恢复,速度较快
[2]劣势
会丢失最后一次快照后的所有修改,不能绝对保证数据的高度一致性和完整性。Fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑,但上述成立有条件,Linux也有优化手段
②AOF
[1]优势
选择appendfsync always方式运行时理论上能够做到数据完整一致,但此时性能又不好。文件内容具备一定可读性,能够用来分析Redis工作情况。
[2]劣势
持久化相同的数据,文件体积比RDB大,恢复速度比RDB慢。效率在同步写入时低于RDB,不同步写入时与RDB相同。
③RDB和AOF并存
Redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢?作者建议不要,因为RDB更适合用于备份数据库(AOF在不断变化不好备份)、快速重启,而且不会有AOF可能潜在的bug,留着作为一个万一的手段。
④使用建议
如果Redis仅仅作为缓存可以不使用任何持久化方式。
其他应用方式综合考虑性能和完整性、一致性要求。
RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留save 900 1这条规则。
如果Enalbe AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
只要硬盘许可,应该尽量减少AOF rewrite的频率,AOF重写的基础大小默认值64M太小了,可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。如果不开启AOF,仅靠Master-Slave Replication 实现高可用性能也不错。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉,会丢失十几分钟的数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个。新浪微博就选用了这种架构。
8.备份建议
如何看待数据“绝对安全”?
Redis 作为内存数据库从本质上来说,如果不想牺牲性能,就不可能做到数据的“绝对”安全。 RDB 和 AOF 都只是尽可能在兼顾性能的前提下降低数据丢失的风险,如果真的发生数据丢失问题,尽可能 减少损失。
在整个项目的架构体系中,Redis 大部分情况是扮演“二级缓存”角色。
二级缓存适合保存的数据
经常要查询,很少被修改的数据。
不是非常重要,允许出现偶尔的并发问题。
不会被其他应用程序修改。
如果 Redis 是作为缓存服务器,那么说明数据在 MySQL 这样的传统关系型数据库中是有正式版本的。数据 最终以 MySQL 中的为准。
官方推荐两个都用;
如果对数据不敏感,可以选单独用 RDB;不建议单独用 AOF,因为可能出现Bug;
如果只是 做纯内存缓存,可以都不用