Redis
键值设计

KEY名设计

可读性和客观理性

- 以业务名（或数据库名）为前缀（防止key冲突），用冒号分隔，比如业务名:表明:id(ugc:video:1)

简洁性

- 保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视，例如： - user:{uid}:friends:messages:{mid}简化为u:{uid}:fr:m:{mid}

不要包含特殊字符

- 反例：包含空格、换行、单双引号、以及其他转义字符

VALUE设计

拒绝BIGKEY

 - 防止网卡流量、慢查询，String类型控制在10kb以内，hash、list、set、zset元素个数不要超过5000；- 非字符串的bigkey，不要使用del删除，使用hscan、sscan、zscan方式渐进式删除，同时要注意防止bigkey过期时间自动删除问题（例如一个200万的zset设置1小时过期，会触发del操作，造成阻塞，而且该操作不会不出现在慢查询中（latency可查）），查找方法和删除方法。

• 选择适合的数据类型
• 实体类型(要合理控制和使用数据结构内存编码优化配置,例如ziplist，但也要注意节省内存和性能之间的平衡)
• 控制key的声明周期
• redis不是垃圾桶，建议使用expire设置过期时间(条件允许可以打散过期时间，防止集中过期)，不过期的数据重点关注idletime。

命令使用

1.O(N)命令关注n的数量

例如hgetall、lrange、smembers、zrange、sinter等并非不能使用，但是需要明确N的值。有遍历的需求可以使用hscan、sscan、zscan代替。

2.禁止命令

禁止线上使用keys、flushall、flushdb等，通过redis的rename机制禁掉命令，或者使用scan的方式渐进式处理。

3.合理使用select

redis的多数据库较弱，使用数字进行区分，很多客户端支持较差，同时多业务用多数据库实际还是单线程处理，会有干扰。

4.使用批量操作提高效率

原生命令：例如：mget、mset

非原生命令：可以使用pipeline提高效率

注意控制一次批量操作的元素个数（例如500以内，实际也和元素字节数有关）

注意两者不同：原生的原子操作，pipeline是非原子操作pipeline可以打包不同的命令，原生做不到

pipeline需要客户端和服务端同时支持

5.不建议过多使用redis事务功能

redis的事务功能较弱（不支持回滚），而且集群版本（自研和官方）要求一次事务操作的key必须在一个slot上（可以使用hashtag功能解决）

6.redis集群版本在使用lua上有特殊要求

1.所有的key都应该由keys数组来传递，redis.call/pcall里面调用的redis命令，key的位置，必须是keys array，否则直接返回error，’err bab lua script for redis cluster,all the keys that the script uses should be passed using the keys arrayrn’

2.所有key，必须在1个slot上，否则直接返回error，”-err eval/evalsh command keys must in same slotrn”

7.monitor命令

必要情况下使用monitor命令时，要注意不要长时间使用。

• 淘汰策略
• 根据自身业务类型，选好maxmemory-policy(最大内存淘汰策略)，设置好过期时间。
• 默认策略是volatile-lru，即超过最大内存后，在过期键中使用lru算法进行key的剔除，保证不过期数据不被删除，但是可能会出现OOM问题。
• 其他策略如下：
• allkeys-lru：根据LRU算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止。
• allkeys-random：随机删除所有键，直到腾出足够空间为止。
• volatile-random:随机删除过期键，直到腾出足够空间为止。
• volatile-ttl：根据键值对象的ttl属性，删除最近将要过期数据。如果没有，回退到noeviction策略。
• noeviction：不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息”(error) OOM command not allowed when used memory”，此时Redis只响应读操作。

四、相关工具

• 1、数据同步
• redis间数据同步可以使用：redis-port
• 2、big key搜索
• redis大key搜索工具
• 3、热点key寻找
• 内部实现使用monitor，所以建议短时间使用facebook的redis-faina
• 阿里云Redis已经在内核层面解决热点key问题

REDIS: REMOTE DICTIONARY SERVER 远程字典服务器

切库：select ? ?的值1-16

模糊查询：keys key

清除当前数据：flushdb
清空：flushall
判断是否存在：exists key
移至对应的DB库：move key db
查看还有多久过期：ttl key -1 永不过期，-2已经过期
为指定key设置过期时间：expire key 秒 过期的key不会存在
查看key数据类型：type key

STRING

SET

HASH

ZSET(SORTED SET)

listlpush key value1 value2 value3  左插入lrange key 0 -1 取值rpush key value1 value2 value3	右插入lpop key    清除最顶位 rpop key	清除最低位lindex key 0 0代表索引   llen key 	key的长度lrem key num content  num代表个数，content要删的数据 删除n个valueltrim key start end   start开始位置，end结束位置   截取指定范围的值后再赋值给key  比如值为  0 1 2 3 4 5 6   截取为0到3  最后key值为0 1 2 3 rpoplpush key1 key2 清除key1最低位给key2lset key index value 给指定位换值linset key before value1 value2  在指定的key指定的value前加数据linset key after value1 value2  在指定的key指定的value后加数据list是一个字符串链表，left、right都可以插入添加如果键不存在，创建新的链表如果已存在，新增内容如果值全部移除，对应的键也就消失了链表的操作无论是头和尾效率都极高，但假如是对中间元素进行操作，效率就很惨淡了

REDIS的配置文件（REDIS.CONF）

includes(包含)

• general（通用配置）
• daemonize no 改为yes redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程
• pidfile 进程文件
• port 端口
• tcp-backlog 设置tcp的backlog，backlog是一个连接队列 511
• bind 端口 绑定端口
• timeout 客户端闲置多长时间后关闭连接，如果指定为0，表示一直连着
• tcp-keepalive 检测
• loglevel 日志级别，redis支持四种：debug、verbose、notice、warning，默认是verbose
• logfile 日志名字
• Syslog-enabled 是否把日志输出到syslog中
• Syslog-ident 指定syslog里的日志标志
• Syslog-facility 指定syslog设备，值可以是User或Local0-local7
• database 默认数据库 16

SECURITY(安全)

• config get requirepass 获取redis密码
• config set requirepass pass 设置密码
  auth password

limits限制

- Maxclients 最大连接 - Maxmemory - Maxmemory-policy 过期策略 默认永不过期noeviction(volatile-lru:使用lru算法移除key，只对设置了过期时间的键 - 、allkeys-lru：使用lru算法移除key、volatile-random：在国企集合中移除随机的key，只对设置了过期时间的键 - 、allkeys-random：移除随机的key、volatile-ttl：移除那些ttl值最小的key，即那些最近要过期的key、) - Maxmemory-samples 样例 默认5个

Redis持久化RDB和AOF

RDB:在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的snapshot快照，它恢复时是将快照文件直接读到内存里
redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那么RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

FORK：fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

RDB 默认以DUMP.RDB文件保存

• 更改策略
• 900秒改动一次
• 300秒改动10次
• 60秒改动10000万次
• shutdown 后才会更新文件 需要提前复制一份rdb文件才能恢复
• RDB禁用：如果想禁用rdb持久化的策略，只要不设置任何save指令，或者给save传入一个空字符串参数也可以
• rdb模式 规定秒数内没有改动规定次数 执行save即可
• save：save时只管保存，其他不管，全部阻塞
• bgsave:redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间
• 执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义。
• stop-writes-on-bgsave-errorr 默认值yes :如果配置成no，表示你不在乎数据不一致或者其他的手段发生和控制
• rdbcompression 默认值yes :对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。
• rdbchecksum 默认值yes : 在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
• 如何恢复文件： 备份最好用备用机
• 优势： 适合大规模的数据恢复、对数据完整性和一致性要求不高
• 劣势： 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
• 如何停止rdb备份： 动态所有停止rdb保存规则的方法：redis-cli config set save “” 不建议

RDB模式总结：

• RDB是一个非常紧凑的文件
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全程由子进程来做，父进程不需要在做其他IO操做，所以RDB持久化方式可以最大化redis的性能
• 与AOF相比，在恢复大的数据集的时候，RDB方式会快一些。
• 数据丢失风险大
• RDB需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能会导致redis在一些毫秒级不能响应客户端请求。

AOF

• 以日志的形式来记录每个写操作，将redis执行过的所有写指令记录下来（读操作不记录），只允许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
• appendonly no默认是关掉的
• 如何修复aof
• redis-check-aof –fix appendonly.aof
  appendfsync

always: 同步持久化，每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好

everysec: 出厂默认推荐，异步操作，每秒记录 如果一秒内宕机，有数据丢失

no

• no-appendfsync-on-rewrite：重写时是否可以运用appendfsync,用默认no即可，保证数据安全性。
• auto-aof-rewrite—min-size:设置重写的基准点
• auto-aof-rewrite-percentage：设置重写的基准点

• rewrite 是什么：aof采用文件追加方式，文件会越来越大 为避免出现此种情况，新增了重写机制，当aof文件的大小超过所设定的阈值时，redis就会启动aof文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof

重写原理：aof文件持续增加而过大，会fork出一条进程来讲文件重写（也是先写临时文件最后再rename），遍历新进程的内存中数据，每条记录有一条的set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写一个新的aof文件，这点和快照有点类似。

触发机制：redis会记录上次重写时的aof大小，默认配置是当aof文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

优势：每秒同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好

每修改同步:appendfsync everysec 异步操作，每秒记录，如果一秒内宕机，有数据丢失

不同步：appendfsync no 从不同步

劣势：相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb

aof运行效率慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同

小总结：aof文件时一个只进行追加的日志文件

1.redis可以在aof文件体积变得过大时，自动地在后台对aof进行重写

2.aof文件有序地保存了对数据库执行的所有写入操作，这些写入操作以redis协议的格式保存，因此aof文件的内容非常容易被人读懂，对文件进行分析也很轻松。

3.对于相同的数据来说，aof文件的体积通常要大于rdb文件的体积

4.根据所使用的fsync策略，aof的速度可能会慢于rdb

大总结：rdb持久化方式能够在指定的四件间隔能对你的数据进行快照存储

- aof持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，aof命令以redis协议追加保存每次写的操作到文件末尾，redis还能对aof文件进行后台重写，使得aof文件的体积不至于过大。

- 同时开启两种持久化方式：在这种情况下，当redis重启的时候会优先载入aof文件来恢复原始的数据，因为在通常情况下aof文件保存的数据集比rdb文件保存的数据集要完整。

- rdb的数据不实时，同时使用两者时服务器重启也只会找aof文件。那要不要只使用aof呢

- 不建议，因为rdb更适合用于备份数据库（aof在不断变化不好备份），快速重启，而且不会有aof可能潜在的bug，留着作为一个万一的手段。

性能建议：因为rdb文件只用作备用途，建议只在slave上持久化rdb文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

如果Enable aof，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的aof文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少aof rewrite 的频率，aof重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

如果不Enable AOF,仅靠master-slave replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果master\slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较master\slave中的rdb文件，载入较新的那个。

redis的事务

是什么：可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行 执行而不会被其它命令插入，不许加塞。

能干什么：一个队列，一次性、顺序性、排他性的执行一系列

命令常用命令：

discard:取消事务，放弃执行事务块内所有命令。

exec：执行所有事务块内命令。

multi：标记一个事务块的开始。

unwatch：取消watch命令对所有key的监视。

watch key [key …]:监视一个（或多个）key，如果在事务执行之前这个（或这些）key被其他命令所改动，那么事务将被打断。

redis部分执行事务 两种一种在执行时报错，一种是自增时报错

悲观锁：（pessimistic lock）顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直接到它拿到锁。传统的关系数据库里边就用到了很多这种锁机制，比如行锁，表锁，读锁，写锁等，都是在操作之前先上锁。

乐观锁：（OPtimistic lock）顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此之间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。（乐观锁策略：提交版本必须大于记录当前版本才能执行更新）

小结：watch指令，类式乐观锁，事务提交时，如果key的值已被别的客户端改变，比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行。

通过watch命令在事务执行之前监控了多个keys，倘若在watch之后有任何key的值发生了变化，exec命令执行的事务都将被放弃，同时返回nullmulti-bulk应答已通知调用者事务执行失败。

redis事务三阶段：开启（以multi开始一个事务）

入队（将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等执行的事务队列里面）

执行（由exec命令触发事务）

三个特性：单独的隔离操作：事务中所有命令都会序列化、按顺序地执行。事务在执行过程中，不会被其他客户端发送来的命令请求所打断。

没有隔离级别的概念：队列中的命令没有提交之前都不会实际地被执行，因为事务提交前任何指令都不会被实际执行，也就不存在“事务内的查询要看到事务里的更新，在事务外查询不能看到“这个让人万分头痛的问题。

不保证原子性：redis同一个事务如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。

redis 发布和订阅

• 是什么：进程间的一种消息通信模式:发送者（pub）发送消息，订阅者（sub）接收消息
• 命令：psubscribe pattern[pattern] :订阅一个或者多个符合给定模式的频道
• pubsub subcommand [argument [argument…]] : 查看订阅与发布系统状态
• publish channel messages : 将信息发送到指定的频道
• punsubscribe [pattern [pattern…]]: 退订所有给定模式的频道
• subscribe channel[channel …]:订阅给定一个或多个频道的信息
• unsubscribe[channel[channel…]]:指退订给定的频道

主从复制

• 配从不配主
• 从库配置；slaveof 主库IP主库端口
• 一个配置文件复制多个（修改端口、日志）
• info replication 查看属于主还是从
• 设置了主从 从机不做入库会报错
• 主机挂了 从机原地待命（除非设置）
• 主机复活后 继续按照之前的操作
• 从机挂了之后复活 需要重新连接 slaveof 主库IP主库端口
• 烽火相传：（a传b 传c）上一个Slave可以是下一个slave的master，Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master，可以有效减轻master的写压力。

中途变更转向：会清除之前的数据，重新建立拷贝最新的。

Slaveof 新主库IP新主库端口

• 反客为主：slaveof no one 使当前数据库停止与其他数据库的同步，转成主数据库。
• 复制原理：Slave 启动成功连接到master后会发送一个sync命令

1.Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，以完成一次完全同步。

2.全量复制：而slave服务在接收数据库文件数据后，将其存盘并加载到内存中。

3.增量复制：master继续将新的所有收集到的修改命令依次传给slave，完成同步但是只要是重新连接master，一次完全同步（全量复制）将被自动执行。

• 哨兵模式（sentienl）用作监控主从：
• 反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
• 自定义文件新建sentinel.conf 文件，名字绝不能错。
• 配置哨兵，填写内容：sentinel monitor 被监控数据库名字（自己起名字127.0.0.1 6379 1）
• 上面最后一个数字1，表示主机挂掉slave投票看让谁接替成为主机，得票数多少后成为主机。
• 启动哨兵：redis-sentinel /redis/sentinel.conf (上述目录依照各自的实际情况配置，可能目录不同)
• 原有master挂掉
• 投票新选
• 重新主从继续开工，info replication
• 问题：如果之前的master重启回来，会不会双master冲突？不会
• 一组sentinel能同时监控多个master
• 复制的缺点：复制延迟
• 由于所有的写操作都是现在master上操作，然后同步更新到slave上，所以从master同步到slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加重，Slave机器数量的增加也会使这个问题更加严重。
• redis的事务
• 日常：Transaction tran = jedis.multi();
• tran.exec();
• tran.discard();
• 加锁 watch监控、线程等待
• 主从复制
• 预备两主
• 然后选择从去复制主
• jedis_m jedis_s
• jedis_s.slaveof(主);
• 内存比硬盘快（可能出现第一次查不到）

欢迎大家提议、分享、交流、共同学习进步