理论：NoSQL（非关系数据库）之Redis配置与优化

一、简介

1.1 非关系数据库产生背景

■ High performance-——对数据库高并发读写需求
■ Huge Storage———对海量数据高效存储与访问需求
■ High Scalability && High Availability——对数据库高可扩展性与高可用性需求

1.2 Redis简介

■ Redis 是完全开源的，遵守 BSD 协议，是一个高性能的 key-value 数据库。

■ Redis 与其他 key - value 缓存产品有以下三个特点：

• Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
• Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
• Redis支持数据的备份，即master-slave模式的数据备份。

1.3 Redis优势

• 性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。
• 丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。
• 原子 – Redis的所有操作都是原子性的，意思就是要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过MULTI和EXEC指令包起来。
• 丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。
• 支持数据库备份
  

二、Redis数据类型

Redis支持五种数据类型: string(字符串)最常规的基础类型，hash(哈希)用来存储对象的（对象又包含多个属性和参数），list(列表)存的都是字符串的集合，set(集合）及zset(sorted set：有序集合)。

2.1 String (字符串)

• string 是redis最基本的类型，你可以理解成与Memcached一模一样的类型，一个key对应一个value。
• string类型是二进制安全的。
• redis的string 可以包含任何数据。比如jpg图片或者序列化的对象。
• string类型是Redis最基本的数据类型，string类型的值最大能存储512MB.

2.2 Hash(哈希字典)

• Redis hash是一个键值(key = > value)对集合。
• Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。
• 每个hash可以存储2的32次方 -1 键值对。
  //作用场景:
  键值对集合,即编程语言中的Map类型 适合存储对象,并且可以像数据库中update一个属性一样只修改某一项属性值

2.3 List(列表)

• Redis列表是简单的字符串列表，按照插入顺序排序，可以重复。可以添加一个元素到列表的头部（左边）或者尾部(右边)。
• 列表最多可存储2的32次方 -1 元素。
  /作用场景:
  增删快,提供了操作某一段元素的APl 1,最新消息排行等功能(比如朋友圈的时间线)2,消息队列

2.4 set(无序集合)

• Redis的Set是string类型的无序集合。不能存储重复数据

• 集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 0或1
  //作用场景:
  1、共同好友 2、利用唯一性,统计访问网站的所有独立ip 3、好友推荐时,根据tag求交集,大于某个阈值就可以推荐

2.5 zset(sorted set:有序集合)

• Redis zset和set一样也是string类型元素的集合,且不允许重复的成员。
• 不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。
• zset的成员是唯一的,但分数(score)却可以重复。
  //作用场景:
  将Set中的元素增加一个权重参数score,元素按score有序排列
  数据插入集合时,已经进行天然排序 1、排行榜2、带权重的消息队列

三、多数据库概念

• Redis支持多个数据库，并且每个数据库的数据是隔离的不能共享，并且基于单机才有，如果是集群就没有数据库的概念。

• Redis是一个字典结构的存储服务器，而实际上一个Redis实例提供了多个用来存储数据的字典，
  客户端可以指定将数据存储在哪个字典中。这与我们熟知的在一个关系数据库实例中可以创建多个数据库类似，所以可以将其中的每个字典都理解成一个独立的数据库。

• 每个数据库对外都是一个从0开始的递增数字命名，Redis默认支持16个数据库（可以通过配置文件支持更多，无上限)，可以通过配置databases来修改这一数字。客户端与Redis建立连接后会自动选择0号数据库，
  不过可以随时使用SELECT命令更换数据库

四、Redis持久化

4.1 Redis持久化

■ 持久化概述

• Redis是运行在内存中，内存中的数据断电丢失
• 为了能够重用Redis数据，或者防止系统故障，需要将Redis中的数据写入到磁盘空间中，即持久化

■ 持久化分类

• RDB方式:创建快照的方式获取某一时刻Redis中所有数据的副本
• AOF方式:将执行的写命令写到文件的末尾，以日志的方式来记录数据的变化

注意：

• RDB是默认方式：创建快照的方式，在两个快照之间，出现断电中间那部分数据就会丢失（弊端：不连续）
• AOF方式：以日志方式来记录数据的变化（连续性）

两者不可相互替代，要相互相成。

4.2 RDB持久化-1

■ Redis的默认持久化方式
■ 默认文件名dump.rdb
■ 触发条件

• 在指定的时间间隔内，执行指定次数的写操作（配置文件控制)
• 执行save或者是bgsave(异步)命令
• 执行flushall命令，清空数据库所有数据
• 执行shutdown命令，保证服务器正常关闭且不丢失任何数据

■ 优缺点

• 适合大规模的数据恢复
• 如果业务对数据完整性和一致性要求不高，RDB是很好的选择
• 数据的完整性和一致性不高
• 备份时占用内存

4.3 RDB持久化-2

■ 通过RDB文件恢复数据

• 将dump.rdb文件拷贝到redis的安装目录的bin目录下，重启redis服务即可

■ 配置文件选项

vim letc/redis/6379.conf  //900秒之内至少—次写操作、300秒之内至少发生10次写操作、60秒之内发生至少10000次写操作,只要满足其一都会触发快照操作，注释所有的save项表示关闭RDB
save 900 1  //RDB文件名称
save 300 10save 60 10000  //RDB文件夹路径
dbfilename dump.rdb	//RDB文件路径
dir /var/lib/redis/6379  //是否进行压缩
rdbcompression yes

4.4 AOF持久化-1

■ Redis默认不开启
■ 弥补RDB的不足(数据的不一致性)
■ 采用日志的形式来记录每个写操作，并追加到文件中Redis重启会■ 根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

4.5 AOF持久化-2

■ 根据AOF文件恢复数据

• 将appendonly.aof文件拷贝到Redis的安装目录的bin目录下，重启Redis服务即可

■ 配置文件选项

vim letc/redis/6379.conf
appendonly yes
开启AOF持久化
appendfilename "appendonly.aof "
AOF文件名称
appendfsync always
appendfsync everysec
always:同步持久化,每次发生数据变化会立刻写入磁盘
everysec:默认推荐,每秒异步记录一次（默认值)
no:不同步,交给操作系统决定如何同步
#appendfsync no
aof-load-truncated yes
忽略最后一条可能存在问题的指令

4.6 AOF持久化-3

■ AOF的重写机制

• AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多
• 当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩

■ AOF重写的原理

• Redis会fork出一条新进程，读取内存中的数据(并没有读取l日文件)，并重新写到一个临时文件中，最后替换l旧的aof文件

4.7 AOF持久化-4

■ AOF的重写配置

vim /etc/redis/6379.conf
#在日志进行BGREWRITEAOF时，如果设置为yes表示新写操作不进行同步fsync，只是暂存在缓冲区里，避免造成磁盘IO操作冲突，等重写完成后在写入。Redis中默认为no
no-appendfsync-on-rewrite no
#当前AOF文件大小是上次日志重写时AOF文件大小两倍时，发生BGREWRITEAOF操作
auto-aof-rewrite-percentage 100
#当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF
auto-aof-rewrite-min-size 64mb

4.8 Redis性能管理-1

■ 查看Redis内存使用

[root@localhost bin]# redis-cli
127.0.0.1:6379> info memory
Memory
used_memory:2594360
used_memory_human:2.47M     ##内存使用总量
used_memory_rss:14864384
used_memory_rss_human:14.18M
used_memory_peak:2635264
used_memory_peak_human:2.51M
used_memory_peak_perc:98.45%
used_memory_overhead:2565042
used_memory_startup:1449664
used_memory_dataset:29318
used_memory_dataset_perc:2.56%
allocator_allocated:3041488
allocator_active:3358720
allocator_resident:10420224
total_system_memory:3958075392
total_system_memory_human:3.69G
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.10
allocator_frag_bytes:317232
allocator_rss_ratio:3.10
allocator_rss_bytes:7061504
rss_overhead_ratio:1.43
rss_overhead_bytes:4444160
mem_fragmentation_ratio:5.82      ##内存碎片率
mem_fragmentation_bytes:12311048
mem_not_counted_for_evict:114
mem_replication_backlog:1048576
mem_clients_slaves:16922
mem_clients_normal:49694
mem_aof_buffer:114
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0

4.9 Redis性能管理-2

■ 内存碎片率

• 操系统分配的内存值used_memory_rss除以Redis使用的内存值used_memory计算得出
• 内存碎片是由操作系统低效的分配/回收物理内存导致的
  ◆不连续的物理内存分配
• 跟踪内存碎片率对理解Redis实例的资源性能是非常重要的
  ◆ 内存碎片率稍大于1是合理的，这个值表示内存碎片率比较低
  ◆内存碎片率超过1.5，说明Redis消耗了实际需要物理内存的150%，其中50%是内存碎片率
  ◆内存碎片率低于1的，说明Redis内存分配超出了物理内存，操作系统正在进行内存交换

4.10 Redis性能管理-3

■ 内存使用率

• redis实例的内存使用率超过可用最大内存，操作系统将开始进行内存与swap空间交换
• 避免内存交换
  ◆针对缓存数据大小选择
  ◆尽可能的使用Hash数据结构
  ◆设置key的过期时间

4.11 Redis性能管理-4

■ 回收key

• 保证合理分配redis有限的内存资源
• 当达到设置的最大阀值时，需选择—种key的回收策略
  ◆ 默认情况下回收策略是禁止删除
  ◆redis.conf配置文件中修改maxmemory-policy属性值
  □ volatile-lru:使用LRU算法从已设置过期时间的数据集合中淘汰数据.
  □ volatile-ttl:从已设置过期时间的数据集合中挑选即将过期的数据淘汰
  □ volatile-random:从已设置过期时间的数据集合中随机挑选数据淘汰
  □ allkeys-Iru:使用LRU算法从所有数据集合中淘汰数据
  □ allkeys-random:从数据集合中任意选择数据淘汰
  □ no-enviction:禁止淘汰数据

推荐使用volatile-ttl方式