[redis] redis的安装，配置与简单操作

一、缓存的相关知识

1.1 缓存的概念

缓存是为了调节速度不一致的两个或多个不同的物质的速度，在中间对速度较慢的一方起到加速作用，比如CPU的一级、二级缓存是保存了CPU最近经常访问的数据，内存是保存CPU经常访问硬盘的数据，而且硬盘也有大小不一的缓存，甚至是物理服务器的raid 卡有也缓存，都是为了起到加速CPU 访问硬盘数据的目的，因为CPU的速度太快了，CPU需要的数据由于硬盘往往不能在短时间内满足CPU的需求，因此CPU缓存、内存、Raid 卡缓存以及硬盘缓存就在一定程度上满足了CPU的数据需求，即CPU 从缓存读取数据可以大幅提高CPU的工作效率。

1.2 系统缓存

buffer与cache：

• buffer： 缓冲也叫写缓冲，一般用于写操作，可以将数据先写入内存再写入磁盘，buffer 一般用于写缓冲，用于解决不同介质的速度不一致的缓冲，先将数据临时写入到里自己最近的地方，以提高写入速度，CPU会把数据先写到内存的磁盘缓冲区，然后就认为数据已经写入完成看，然后由内核在后续的时间在写入磁盘，所以服务器突然断电会丢失内存中的部分数据。
• cache： 缓存也叫读缓存，一般用于读操作，CPU读文件从内存读，如果内存没有就先从硬盘读到内存再读到CPU，将需要频繁读取的数据放在里自己最近的缓存区域，下次读取的时候即可快速读取。

1.3 缓存保存位置及分层结构

DNS缓存

浏览器的DNS缓存默认为60秒，即60秒之内在访问同一个域名就不在进行DNS解析。

应用层缓存

Nginx、PHP等web服务可以设置应用缓存以加速响应用户请求，另外有些解释性语言，比如：PHP/Python/Java不能直接运行，需要先编译成字节码，但字节码需要解释器解释为机器码之后才能执行，因此字节码也是一种缓存，有时候还会出现程序代码上线后字节码没有更新的现象。所以一般上线新版前,需要先将应用缓存清理,再上线新版。

另外可以利用动态页面静态化技术,加速访问,比如:将访问数据库的数据的动态页面,提前用程序生成静态页面文件html 电商网站的商品介绍,评论信息非实时数据等皆可利用此技术实现。

数据层缓存

分布式缓存服务：

• Redis
• Memcached

数据库：

• MySQL 查询缓存
• innodb缓存、MYISAM缓存

 硬件缓存

• CPU缓存（L1的数据缓存和L1的指令缓存）、二级缓存、三级缓存
• 磁盘缓存：Disk Cache
• 磁盘阵列缓存：Raid Cache，可使用电池防止断电丢失数据

二、关系型数据与非关系型数据库

2.1 关系型数据库

• 关系型数据库是一个结构化的数据库，创建在关系模型(二维表格模型)基础上，一般面向于记录。
• SQL语句（标准数据查询语言）就是一种基于关系型数据库的语言，用于执行对关系型数据库中数据的检索和操作。
• 主流的关系型数据库包括Oracle、 MySQL、SQL Server、Microsoft Access、 DB2、PostgreSQL 等。

以上数据库在使用的时候必须先建库建表设计表结构，然后存储数据的时候按表结构去存，如果数据与表结构不匹配就会存储失败。

2.2 非关系型数据库

• NoSQL（NoSQL=NotonlysQL），意思是“不仅仅是SQL"，是非关系型数据库的总称。
• 除了主流的关系型数据库外的数据库，都认为是非关系型。
• 不需要预先建库建表定义数据存储表结构，每条记录可以有不同的数据类型和字段个数(比如微信群聊里的文字、图片、视频、音乐等)。
• 主流的NOSQL 数据库有Redis、MongBD、 Hbase（分布式非关系型数据库，大数据使用）、Memcached、ElasticSearch（简称ES，索引型数据库）、TSDB（时续型数据库） 等。

2.3 关系型数据库和非关系型数据库区别：

（1）数据存储方式不同

关系型和非关系型数据库的主要差异是数据存储的方式。

• 关系型数据天然就是表格式的，因此存储在数据表的行和列中。数据表可以彼此关联协作存储，也很容易提取数据。
• 与其相反，非关系型数据不适合存储在数据表的行和列中，而是大块组合在一起。非关系型数据通常存储在数据集中，就像文档、键值对或者图结构。你的数据及其特性是选择数据存储和提取方式的首要影响因素。（很容易切换数据类型，一个数据集当中有多种数据类型）

（2）扩展方式不同

SQL和NoSQL数据库最大的差别可能是在扩展方式上，要支持日益增长的需求当然要扩展。

• 要支持更多并发量，SQL数据库是纵向扩展，也就是说提高处理能力，使用速度更快速的计算机，这样处理相同的数据集就更快了。因为数据存储在关系表中，操作的性能瓶颈可能涉及很多个表，这都需要通过提高计算机性能来克服。虽然SQI数据库有很大打展空间，但最终肯定会达到纵向扩展的上限。（数据一般存储在本地的文件系统中。读可以通过读写分离、负载均衡来分摊性能，但读写仍然很消耗IO性能）
• 而NoSQL数据库是横向扩展的。因为非关系型数据存储天然就是分布式的，NoSQL数据库的扩展可以通过给资源池添加更多普通的数据库服务器(节点)来分担负载。（数据分布存储在不同服务器上，可以并发地读写，加快效率）

• 横向扩展：加服务器。（比较便宜）

• 纵向扩展：提高硬件配置，比如换更高性能的CPU、加CPU核数、硬盘、磁盘IO、内存条。（除硬盘外，其他需要停机才能加）

（3）对事务性的支持不同

• 如果数据操作需要高事务性或者复杂数据查询需要控制执行计划，那么传统的SQL数据库从性能和稳定性方面考虑是你的最佳选择。SQL数据库支持对事务原子性细粒度控制，并且易于回滚事务。
• 虽然NoSQL数据库也可以使用事务操作，但稳定性方面没法和关系型数据库比较，所以它们真正闪亮的价值是在操作的扩展性和大数据量处理方面。
• 非关系型数据库在事务的处理和稳定性方面，不如关系型数据库。但读写性能好、易于扩展，处理大数据方面占优势。

关系型数据库：特别适合高事务性要求和需要控制执行计划的任务，事务细粒度控制更好。

非关系型数据库：事务控制会稍显弱势，其价值点在于高扩展性和大数据量处理方面。

2.4 非关系型数据库产生背景

可用于应对Web2.0纯动态网站类型的三高问题。

（1）High performance —— 对数据库高并发读写需求。

（2）Hugestorage——对海量数据高效存储与访问需求。

（3）HighScalability&&HighAvailability——对数据库高可扩展性与高可用性需求。

关系型数据库和非关系型数据库都有各自的特点与应用场景，两者的紧密结合将会给web2.0的数据库发展带来新的思路。让关系型数据库关注在关系上和对数据的一致性保障，非关系型数据库关注在存储和高效率上。例如，在读写分离的MySQI数据库环境中，可以把经常访问的数据（即高热数据）存储在非关系型数据库中，提升访问速度。

2.5 NOSQL 与 SQL的数据记录对比

关系型数据库:

• 实例-->数据库-->表(table)-->记录行(row)、数据字段(column)

非关系型数据库:

• 实例-->数据库-->集合(collection) -->键值对(key-value)
• 非关系型数据库不需要手动建数据库和集合(表)。

三、redis的相关知识

3.1 redis的简介

Redis是一个开源、基于内存、使用C语言编写的key-value数据库，并提供了多种语言的API。它的数据结构十分丰富，主要可以用于数据库、缓存、分布式锁、消息队列等...

Redis服务器程序是单进程模型，也就是在一台服务器上可以同时启动多个Redis进程，Redis的实际处理速度则是完全依靠于主进程的执行效率。

• 若在服务器上只运行一个Redis进程，当多个客户端同时访问时，服务器的处理能力是会有一定程度的下降；
• 若在同一台服务器上开启多个Redis进程，Redis在提高并发处理能力的同时会给服务器的CPU造成很大压力。

3.2 redis的五大数据类型

基础数据类型包括：string（字符串）、list（列表，双向链表）、hash（散列，键值对集合）、set（集合，不重复）和sorted set也可以称为Zset（有序集合）。

3.3 redis的优缺点

（1）具有极高的数据读写速度： 数据读取的速度最高可达到110000 次/s，数据写入速度最高可达到81000次/s。

（2）支持的数据结构： key-value，支持丰富的数据类型：Strings、 Lists、Hashes、 Sets 及Sorted Sets 等数据类型操作。

• Strings 字符串型
• Lists 列表型
• Hashes 哈希（散列）
• Sets 无序集合
• Sorted Sets 有序集合（或称zsets）

（redis也可以做消息队列，可以通过Sorted Sets实现）

（3）支持数据的持久化： 可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。

（4）原子性： Redis所有操作都是原子性的。（支持事务，所有操作都作为事务）

（5）支持数据备份： 即 master-salve 模式的数据备份。（支持主从复制）

Redis缺点

• 缓存和数据库双写一致性问题
• 缓存雪崩问题
• 缓存击穿问题
• 缓存的并发竞争问题

3.4 Redis的适用场景

• Redis作为基于内存运行的数据库，是一个高性能的缓存，一般应用在session缓存、 队列、排行榜、计数器、最近最热文章、最近最热评论、发布订阅等。
• Redis适用于数据实时性要求高、数据存储有过期和淘汰特征的、不需要持久化或者只需要保证弱一致性、逻辑简单的场景。

3.5 Redis采用单线程的原因

首先要明确的是Redis单线程指的是网络IO和键值对读写是由一个线程来完成的，但Redis持久化、集群数据等是由额外的线程执行的。了解Redis使用单线程之前可以先了解一下多线程的开销。

通常情况下，使用多线程可以增加系统吞吐率或者可以增加系统扩展性，但多线程通常会存在同时访问某些共享资源，为了保证访问共享资源的正确性，就需要有额外的机制进行保证，这个机制首先会带来一定的开销。其实对于多线程并发访问的控制一直是一个难点问题，如果没有精细的设计，比如说，只是简单地采用一个粗粒度互斥锁，就会出现不理想的结果。即使增加了线程，大部分线程也在等待获取访问共享资源的互斥锁，并行变串行，系统吞吐率并没有随着线程的增加而增加。

此外：

值得注意的是在Redis6.0中引入了多线程。在Redis6.0之前，从网络IO处理到实际的读写命令处理都是由单个线程完成的，但随着网络硬件的性能提升，Redis的性能瓶颈有可能会出现在网络IO的处理上，也就是说单个主线程处理网络请求的速度跟不上底层网络硬件的速度。针对此问题，Redis采用多个IO线程来处理网络请求，提高网络请求处理的并行度，但多IO线程只用于处理网络请求，对于读写命令，Redis仍然使用单线程处理！

3.6 redis运行速度快的原因

• Redis是基于内存的，绝大部分请求都是内存操作，十分的迅速。
• Redis具有高效的底层数据结构，为优化内存，对每种类型基本都有两种底层实现方式。

主要执行过程是单线程，避免了不必要的上下文切换和资源竞争，不存在多线程导致的CPU切换和锁的问题。

•  IO多路复用机制：使其在网络IO操作中能并发处理大量的客户端请求从而实现高吞吐率。

IO多路复用机制是指一个线程处理多个IO流，也就是常说的select/epoll机制。在Redis运行单线程的情况下，该机制允许内核中同时存在多个监听套接字和已连接套接字。内核会一直监听这些套接字上的连接请求或数据请求。一旦有请求到达，就会交给Redis线程处理，这就实现了一个Redis线程处理多个IO流的效果，进而提升并发性。

3.7  Redis与memcached比较

四、redis的安装配置

4.1 redis的源码编译安装

//环境准备
systemctl stop firewalld
systemctl disable firewalld
setenforce 0
sed -i 's/enforcing/disabled/' /etc/selinux/config

#修改内核参数
vim /etc/sysctl.conf
vm.overcommit_memory = 1
net.core.somaxconn = 2048

sysctl -p


//安装redis
yum install -y gcc gcc-c++ make

tar zxvf /opt/redis-7.0.13.tar.gz -C /opt/
cd /opt/redis-7.0.13/
make
make PREFIX=/usr/local/redis install
#由于Redis源码包中直接提供了 Makefile 文件，所以在解压完软件包后，不用先执行 ./configure 进行配置，可直接执行 make 与 make install 命令进行安装。

#创建redis工作目录
mkdir /usr/local/redis/{conf,log,data}

cp /opt/redis-7.0.13/redis.conf /usr/local/redis/conf/

useradd -M -s /sbin/nologin redis
chown -R redis.redis /usr/local/redis/

#环境变量
vim /etc/profile 
PATH=$PATH:/usr/local/redis/bin		#增加一行

source /etc/profile

 4.2 修改配置文件

vim /usr/local/redis/conf/redis.conf
bind 127.0.0.1 192.168.136.190					#87行，添加 监听的主机地址
protected-mode no					#111行，将本机访问保护模式设置no。如果开启了，那么在没有设定bind ip且没有设密码的情况下，Redis只允许接受本机的响应
port 6379										#138行，Redis默认的监听6379端口
daemonize yes									#309行，设置为守护进程，后台启动
pidfile /usr/local/redis/log/redis_6379.pid		#341行，指定 PID 文件
logfile "/usr/local/redis/log/redis_6379.log"	#354行，指定日志文件
dir /usr/local/redis/data						#504行，指定持久化文件所在目录
requirepass abc123								#1037行，增加一行，设置redis密码

​​​​​

4.3 定义systemd服务管理脚本

vim /usr/lib/systemd/system/redis-server.service
[Unit]
Description=Redis Server
After=network.target

[Service]
User=redis
Group=redis
Type=forking
TimeoutSec=0
PIDFile=/usr/local/redis/log/redis_6379.pid
ExecStart=/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis.conf
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

#启动服务
systemctl start redis-server
systemctl enable redis-server

netstat -lntp | grep 6379

五、Redis 命令工具

5.1 redis-cli：Redis 命令行工具

-----redis-cli 命令行工具-----
语法：redis-cli -h host -p port [-a password]
-h ：指定远程主机
-p ：指定 Redis 服务的端口号
-a ：指定密码，未设置数据库密码可以省略-a 选项
若不添加任何选项表示，则使用 127.0.0.1:6379 连接本机上的 Redis 数据库

redis-cli -h 192.168.136.190 -p 6379 -a 'abc123'  

5.2 redis-benchmark 测试工具

redis-benchmark 是官方自带的 Redis 性能测试工具，可以有效的测试 Redis 服务的性能。
基本的测试语法：redis-benchmark [选项] [选项值]。
-h ：指定服务器主机名。
-p ：指定服务器端口。
-s ：指定服务器 socket
-c ：指定并发连接数。 
-n ：指定请求数。
-d ：以字节的形式指定 SET/GET 值的数据大小。
-k ：1=keep alive 0=reconnect 。
-r ：SET/GET/INCR 使用随机 key, SADD 使用随机值。
-P ：通过管道传输<numreq>请求。
-q ：强制退出 redis。仅显示 query/sec 值。
--csv ：以 CSV 格式输出。
-l ：生成循环，永久执行测试。
-t ：仅运行以逗号分隔的测试命令列表。
-I ：Idle 模式。仅打开 N 个 idle 连接并等待。

#向 IP 地址为 192.168.136.190、端口为 6379 的 Redis 服务器发送 100 个并发连接与 100000 个请求测试性能
redis-benchmark -h 192.168.136.190 -a abc123 -p 6379 -c 100 -n 100000

#测试存取大小为 100 字节的数据包的性能
redis-benchmark -h 192.168.136.190 -a abc123 -p 6379 -q -d 100

#测试本机上 Redis 服务在进行 set 与 lpush 操作时的性能
redis-benchmark -t set,lpush -n 100000 -q

六、Redis 数据库常用命令

6.1 redis键值对的存取

set：存放数据，命令格式为 set key value
get：获取数据，命令格式为 get key

6.2 redis键值列表的获取

# keys 命令可以取符合规则的键值列表，通常情况可以结合*、？等选项来使用。
127.0.0.1:6379> set k1 1
127.0.0.1:6379> set k2 2
127.0.0.1:6379> set k3 3
127.0.0.1:6379> set v1 4
127.0.0.1:6379> set v5 5
127.0.0.1:6379> set v22 5

127.0.0.1:6379> KEYS *                #查看当前数据库中所有键

127.0.0.1:6379> KEYS v*                #查看当前数据库中以 v 开头的数据

127.0.0.1:6379> KEYS v?                #查看当前数据库中以 v 开头后面包含任意一位的数据

127.0.0.1:6379> KEYS v??                #查看当前数据库中以 v 开头 v 开头后面包含任意两位的数据

6.3 判断键是否存在

# exists 命令可以判断键值是否存在。
127.0.0.1:6379> exists teacher		#判断 teacher 键是否存在
(integer) 1							# 1 表示 teacher 键是存在
127.0.0.1:6379> exists tea
(integer) 0							# 0 表示 tea 键不存在

6.4 删除键

# del 命令可以删除当前数据库的指定 key。
127.0.0.1:6379> keys *
127.0.0.1:6379> del v5
127.0.0.1:6379> get v5

6.5 查看键存储的数据类型

# type 命令可以获取 key 对应的 value 值类型。
127.0.0.1:6379> type k1
string

6.6 expire 命令 key 设置过期时间

#expire 命令可以为给定的 key 设置过期时间
127.0.0.1:6379> expire k1 10		#设置 k1 键的过期时间为 10 秒

#ttl 命令可以查看 key 还有多少秒过期，-1表示永不过期，-2表示已过期
127.0.0.1:6379> ttl k1

6.7 rename 重命名

• 使用rename命令进行重命名时，无论目标key是否存在都会进行重命名，且源key的值会覆盖目标key的值。
• 在实际使用过程中，建议先用exists命令查看目标key 是否存在，然后再决定是否执行rename 命令，以避免覆盖重要数据。

命令格式： rename 源key 目标key

 6.8 renamenx 重命名

# renamenx 命令的作用是对已有 key 进行重命名，并检测新名是否存在，如果目标 key 存在则不进行重命名。（不覆盖）
命令格式：renamenx 源key 目标key

6.9 dbsize查看键数目  

6.x 设置和清空密码

#设置redis的登录密码
config set requirepass password
#查看redis的密码
config get requirepass 

#清空密码
config set requirepass '' 

 七、Redis 多数据库常用命令

Redis 支持多数据库，Redis默认情况下包含16个数据库，数据库名称是用数字0-15来依次命名的。

使用redis-cli连接Redis数据库后，默认使用的是序号为0的数据库。

多数据库相互独立，互不干扰。

7.1 多数据库间切换select

#多数据库间切换
命令格式：select 序号
使用 redis-cli 连接 Redis 数据库后，默认使用的是序号为 0 的数据库。

127.0.0.1:6379> select 10			#切换至序号为 10 的数据库

127.0.0.1:6379[10]> select 15		#切换至序号为 15 的数据库

127.0.0.1:6379[15]> select 0			#切换至序号为 0 的数据库

7.2 多数据库间移动数据

#多数据库间移动数据
格式：move 键值 序号

7.3 清除数据库内数据

FLUSHDB ：清空当前数据库数据
FLUSHALL ：清空所有数据库的数据，慎用！

补充：redis的常见错误与解决方案 

Redis常见运维故障

1. 使用 keys* 把库堵死。——建议使用别名把这个命令改名。
2. 超过内存使用后,部分数据被删除。——这个有删除策略的,选择适合自己的即可。
3. 没开持久化，却重启了实例,数据全掉。——记得非缓存的信息需要打开持久化。
4. RDB的持久化需要 Vm.overcommit_memory=1 ，否则会持久化失败。
5. 没有持久化情况下,主从,主重启太快,从还没认为主挂的情况下,从会清空自己的数据，人为重启主节点前,先关闭从节点的同步。

Redis故障排查

1. 结合Redis 监控查看QPS、缓存命中率、内存使用率等信息。
2. 确认机器层面的资源是否有异常。
3. 故障时及时上机，使用 redis-cli monitor 打印出操作日志，然后分析（事后分析此条失效）。
4. 和研发沟通，确认是否有大Key在堵塞（大Key也可以在日常的巡检中获得） 和组内同事沟通，确实是否有误操作。
5. 和运维同事、研发一起排查流量是否正常，是否存在被刷的情况。