笔记:redis基础

发布时间:2020-05-29 00:00:00 阅读:(566)

    启动redis

    启动redis时直接 redis-server就可以启动服务端了,也可以指定加载的配置文件

    redis-server ./***/redis.conf

    默认情况下 redis-server会以非守护进程(简单理解就是后台运行)的形式启动,指定配置文件后就可以实现以守护进程运行。

    redis数据类型

    redis是一种高级的key:redis存储系统,redis的value共支持五种数据类型

    字符串(strings),列表(lists),哈希散列(hashes),集合(sets),有序集合(sorted sets)

    strings

    字符串累行是二进制安全(可以存储用二进制表示的文件)。

    再遇到数值操作时,redis会将字符串类型转换成数值。

    由于INCR等指令本省就具有原子操作的特性,所以我们可以利用redis的INCR、INCRBY、DECR、DECRBY等指令来实现原子计数的效果。

    lists

    redis的lists在底层实现上并不是数组,而是链表,也就是说,lists具有链表所具有的优势,也具有链表所具有的劣势。

    lists的常用操作包括 LPUSH、RPUSH、LRANGE等。

    sets

    集合,是一种无序集合,元素没有先后顺序,但元素唯一

    集合操作,诸如添加新元素、删除已有元素、交集、并集、差集等

    sorted sets

    有序集合每个元素都关联一个序号(score),是排序的依据

    有时,也将redis的有序集合成为 zsets,因为在redis中,有序集合的操作都是z开头的,如 zrange、zadd、zrevrange、zrangebyscore等

    hashes

    hashes存储的是字符串和字符串值之间的映射。比如存储一个用户的姓名、年龄、联系方式等。

    redis持久化

    redis长时间挂载在内存上,但有时我们需要其将内容及时拷贝,这时,我们就需要redis的持久化功能

    redis提供两种持久化方式,分别是RDB(redis database)和AOF(append only file)

    RDB

    就是在不同的时间点,将redis存储的数据生成快照并存储到磁盘等介质上

    这是一种类似快照的持久化方法
    redis在进行数据持久化的过程中,会将数据先写入到一个临时文件中,等到持久化过程都结束了,才会用该临时文件替换上次持久化的文件。

    对于RDB方式,redis会单独创建(fork)一个子进程来进行持久化任务,而此时主进程是不会进行任何IO操作的,保证服务的正常高性能进行

    如果需要进行大规模数据的恢复,切对于数据恢复的完整性不是非常敏感,那RDB方式比AOF方式更加高效

    当数据完整性要求较好高时,redis发生故障,会有一段时间的数据没来得及进行快照,进而导致丢失

    AOF

    将redis执行过的所有指令记录下来,在下次启动时,只要将指令读入再执行一遍,数据就恢复了

    默认的AOF持久化策略是没秒 fsync(fsync指把缓存中的写指令记录到磁盘中),因为在这种情况下,redis仍可以保持很好的性能,即使redis故障,也只丢失了最近1秒的数据

    AOF方式的一个好处就是可以进行“情景再现”,若我们不小心清空了redis,当AOF文件还没被重写时,我们就可以修改AOF文件,重启redis在恢复数据

    在同样数据规模的情况下,AOF文件比RDB文件大得多,且AOF恢复速度要慢于RDB方式

    AOF重写

    在重写即将开始前,redis会创建(fork)一个重写子进程,该子进程会先读取现有的AOF文件,并将其包含的指令进行分析压缩并写入到一个临时文件中。

    与此同时,主进程会将新接收到的写指令一边积累到内存缓冲区中,一边继续写入到原有的AOF文件中。这样做保证原有的AOF文件的可用性,避免在重写过程中出现意外。

    当重写子进程完成重写任务后,他会给主进程发一个信号,主进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。

    当追加结束后,redis就会用心AOF文件来代替旧AOF文件,之后再有新的写指令,就会都追加到新的AOF文件中。

    主从用法

    像mysql一样,redis是支持主从同步的,也支持一主多从及多从结构

    主从结构,一是为了纯粹的冗余备份,二是为了提升读性能,如很消耗性能的操作可由从服务器承担

    redis的主从同步是异步进行的,意味着主从同步不会影响主逻辑,也不会降低redis的处理性能

    主从架构中,可以考虑关闭主服务器的数据持久化功能,只让从服务器进行持久化,可以进一步提高主服务器的处理性能

    主从架构中,从服务器通常被设置为只读模式,可以避免从服务器的数据被误改。但从服务器还是可以接受到config等指令,所以还是应该避免将从服务器直接暴露到不安全的网络环境中。

    主从同步原理

    从服务器会向主服务器发出sync(异步)指令,当主服务器接收到此指令后,就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作,也就是将主服务器的数据写入RDB文件中。在数据持久化期间,主服务器将执行的写指令都缓存在内存中

    在BGSAVE指令执行完成后,主服务器会将持久化好的RDB文件发送给从服务器,从服务器接收到此文件后会将其存储到磁盘上,然后再将棋读取到内存中。这个动作完成后,主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器

    即使有多个从服务器同时发来sync指令,主服务器也只会执行一次BGSAVE,然后把持久化好的RDB文件发给多个下游。

    主服务器会在内存中维护一个缓冲区,缓冲区中存储着将要发给从服务器的内容。从服务器在与主服务器出线网络瞬断之后,从服务器会尝试再次与主服务器连接,一点连接成功,从服务器就会把“希望同步的主服务器ID”和“希望请求的数据偏移位置”发送出去。主服务器接收到这样的同步请求后,首先会验证主服务器ID是否和自己的ID匹配,其次会检查“请求的偏移位置”是否存在于自己的缓冲区中,如果两者都满足的haul,主服务器就会向从服务器发送增量内容

    redis的事务处理

    事务是指“一个完整的动作,要么全部执行,要么全部不执行”
    redis事务处理:

    1. MULTI 用来组装一个事务
    2. EXEC 用来执行一个事务
    3. DISCARD 用来取消一个事务
    4. WATCH 用来监视一些key,一旦这些key在事务执行之前被改变,则取消事务的执行

    在用 MULTI 组装驶入时,每一个命令都会进入到内存队列中缓存起来,如果出现 QUEUED 则表示我们这个命令成功插入到缓存队列,在将来执行 EXEC 时,这些被 QUEUED 的命令会被组装成一个事务来执行

    有关事务,常见的两类错误:

    1. 调用EXEC之前错误
    2. 调用EXEC之后错误

    “调用EXEC之前错误”,有可能是由于语法有错误导致,也可能由于内存不足导致。只要出现某个命令无法成功写入缓冲队列的情况,redis都会进行记录,在客户端调用EXEC时,redis会拒绝执行这一事务。

    “调用EXEC之后错误”,redsi采取了不同的策略,即redis不会理睬这些错误,而是继续向下执行事务中的其他命令。因为,对于应用层的错误,并不是redis自身需要考虑处理的问题,故,一个事务中某一条命令执行失败,并不影响接下来的其他命令的执行。

    watch

    作用是“监视key是否被改动过”,且支持同时监视多个key,只要还没真正触发事务,WATCH 都会尽职尽责的监视,一旦发现某个key被修改了,在执行EXEC时就会返回 nil ,表示事务无法触发。

    redis配置文件

    redis配置文件分为几大区域:

    1. 通用(general)
    2. 快照(snapshotting)
    3. 复制(replication)
    4. 安全(security)
    5. 限制(limit)
    6. 追加模式(append only mode)
    7. LUA脚本(lua scripting)
    8. 慢日志(slow log)
    9. 事件通知(event notification)