1.缓存的相关知识
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缓存,操作系统DNS缓存客户端
代理层：CDN,反向代理缓存
Web层：Web服务器缓存
应用层：页面静态化
数据层：分布式缓存,数据库
系统层：操作系统cache
物理层：磁盘cache, Raid Cache
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.关系型数据与非关系型数据库
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)
非关系型数据库不需要手动建数据库和集合(表)。
3 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 等数据类型操作。
（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比较
4.redis的安装配置
4.1 redis的源码编译安装
#关闭防火墙
systemctl stop firewalld
setenforce 0
#安装环境依赖包
yum install -y gcc gcc-c++ make
#上传软件包并解压
cd /opt/
tar zxvf redis-5.0.7.tar.gz -C /opt/
cd /opt/redis-5.0.7/
#开2核编译安装，指定安装路径为/usr/local/redis
make -j2 && make PREFIX=/usr/local/redis install
#由于Redis源码包中直接提供了Makefile 文件，所以在解压完软件包后，不用先执行./configure 进行配置，可直接执行make与make install命令进行安装。
#执行软件包提供的install_server.sh 脚本文件，设置Redis服务所需要的相关配置文件
cd /opt/redis-5.0.7/utils
./install_server.sh
.......#一直回车
Please select the redis executable path [] /usr/local/redis/bin/redis-server
#这里默认为/usr/local/bin/redis-server，需要手动修改为/usr/local/redis/bin/redis-server，注意要一次性正确输入
---------------------- 虚线内是注释 ----------------------------------------------------
Selected config:
Port: 6379 #默认侦听端口为6379
Config file: /etc/redis/6379.conf #配置文件路径
Log file: /var/log/redis_6379.log #日志文件路径
Data dir : /var/lib/redis/6379 #数据文件路径
Executable: /usr/local/redis/bin/redis-server #可执行文件路径
Cli Executable : /usr/local/bin/redis-cli #客户端命令工具
-----------------------------------------------------------------------------------
#当install_server.sh 脚本运行完毕，Redis 服务就已经启动，默认监听端口为6379
netstat -natp | grep redis
#把redis的可执行程序文件放入路径环境变量的目录中便于系统识别
ln -s /usr/local/redis/bin/* /usr/local/bin/
4.2 redis的启动配置
#Redis服务控制
/etc/init.d/redis_6379 stop #停止
/etc/init.d/redis_6379 start #启动
/etc/init.d/redis_6379 restart #重启
/etc/init.d/redis_6379 status #查看状态
#编辑配置文件，参数
vim /etc/redis/6379.conf
......
70 bind 127.0.0.1 192.168.73.105 #监听的IP地址，同时是一种指定远程登录的方式
93 port 6379 #监听端口
137 daemonize yes #使用守护进程的方式启动，即后台启动
159 pidfile /var/run/redis_6379.pid #Redis的进程号保存位置
172 logfile /var/log/redis_6379.log #日志保存的位置
187 databases 16 #监听库的数量（编号0-15）
/etc/init.d/redis_6379 restart #重启redis服务
Redis中bind的正确的理解
bind：是绑定本机的IP地址，（准确的是：本机的网卡对应的IP地址，每一个网卡都有一个IP地址），而不是redis允许来自其他计算机的IP地址。
如果指定了bind，则说明只允许来自指定网卡的Redis请求。如果没有指定，就说明可以接受来自任意一个网卡的Redis请求。
将本机访问保护模式开启了，那么在没有设定bind ip且没有设密码的情况下，Redis只允许接受本机的响应
bind 127.0.0.1的解释：（为什么只有本机可以连接，而其他不可以连接）
我们从ifconfig可以看出：lo网卡（对应127.0.0.1IP地址）：是一个回环地址（Local Loopback），也就是只有本地才能访问到这个回环地址，而其他的计算机也只能访问他们自己的回环地址。
那么来自这个lo网卡的计算机只有本机，所以只有本机可以访问，而其他计算机不能访问。
bind 0.0.0.0代表服务器上的所有物理网卡地址
5.redis的命令工具
5.1 redis-cli：Redis 命令行工具
redis-cli -h host -p port [-a password]
-h：指定远程主机机
-p：指定Redis服务的端口号
-a：指定密码，未设置数据库密码可以省略-a选项
#-a选项若不添加任何选项表示使用127.0.0.1:6379连接本机上的Redis数据库
#登录本机
redis-cli
#远程登录
redis-cli -h 192.168.72.60 -p 6379 [-a 密码]
5.2 redis-benchmark 测试工具
redis-benchmark是官方自带的Redis性能测试工具，可以有效的测试Redis服务的性能。
基本的测试语法：redis-benchmark [选项] [选项值]
-h：指定服务器主机名。
-p：指定服务器端口。
-s：指定服务器 socket
-c：指定并发连接数。
-n：指定请求数。
-d：以字节的形式指定SET/GET值的数据大小。
-k：l=keep alive 0=reconnect
-r：SET/GET/INCR 使用随机key,SADD使用随机值
-P：通过管道传输<numreg>请求
-q：强制退出redis，仅显示query/sec值
--csv：以CSV格式输出
-l：生成循环,永久执行测试
-t：仅运行以逗号分隔的测试命令列表
-I：Idle模式，仅打开N个idle连接并等待
(1)并发连接与100000 个请求处理性能测试
redis-benchmark -h 192.168.73.105 -p 6379 -c 100 -n 100000
（2）数据包的存取的性能测试
redis-benchmark -h 192.168.73.105 -p 6379 -q -d 100
（3） 键值对的创建速度测试
redis-benchmark -t set,lpush -n 100000 -q
6.redis的简单操作
6.1 redis键值对的存取
set：存放数据，命令格式为 set key value
get：获取数据，命令格式为 get key
6.2 redis键值列表的获取
键值的设置：
192.168.73.105:6379> set v1 1
OK
192.168.73.105:6379> set v2 2
OK
192.168.73.105:6379> set v3 4
OK
192.168.73.105:6379> set k1 5
OK
192.168.73.105:6379> set k2 6
OK
192.168.73.105:6379> set k3 7
OK
192.168.73.105:6379> set k4 8
OK
（1）获取全部列表
keys *
（2）获取以某字符为开头任意长度的键
keys v*
keys k*
（3）获取以某字符为开头，后面为指定长度的键
添加测试数据：
192.168.73.105:6379> set v123 123
OK
192.168.73.105:6379> set v11 11
OK
192.168.73.105:6379> set v1124 1124
6.3 判断键是否存在
exists 键
#返回结果 为0 则为不存在，返回为1即为存在
6.4 删除键
del 键
6.5 查看键存储的数据类型
6.6 rename 重命名
使用rename命令进行重命名时，无论目标key是否存在都会进行重命名，且源key的值会覆盖目标key的值。
在实际使用过程中，建议先用exists命令查看目标key 是否存在，然后再决定是否执行rename 命令，以避免覆盖重要数据。
命令格式： rename 源key 目标key
6.7 renamenx 重命名
——会检查目标键名是否已存在
renamenx 命令的作用是对已有key进行重命名，并检测新名是否存在，如果目标key存在则不进行重命名。（不覆盖）
renamenx 源key 目标key
6.8 dbsize查看键数目
dbsize
6.9 设置和清空密码
设置和查看密码
#设置redis的登录密码
config set requirepass password
#查看redis的密码
config get requirepass
清空密码
#清空密码
config set requirepass ''
7.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的数据库
127.0.0.1:6379[0]>
7.2 多数据库间移动数据
move 键值 序号（库的序号）
7.3 清除数据库内数据
FLUSHDB：清空当前数据库数据
FLUSHALL：清空所有数据库的数据，
8. redis的常见错误与解决方案
8.1 Redis常见运维故障
使用 keys* 把库堵死。——建议使用别名把这个命令改名。
超过内存使用后,部分数据被删除。——这个有删除策略的,选择适合自己的即可。
没开持久化，却重启了实例,数据全掉。——记得非缓存的信息需要打开持久化。
RDB的持久化需要 Vm.overcommit_memory=1 ，否则会持久化失败。
没有持久化情况下,主从,主重启太快,从还没认为主挂的情况下,从会清空自己的数据，人为重启主节点前,先关闭从节点的同步。
8.2 Redis故障排查
结合Redis 监控查看QPS、缓存命中率、内存使用率等信息。
确认机器层面的资源是否有异常。
故障时及时上机，使用 redis-cli monitor 打印出操作日志，然后分析（事后分析此条失效）。
和研发沟通，确认是否有大Key在堵塞（大Key也可以在日常的巡检中获得） 和组内同事沟通，确实是否有误操作。
和运维同事、研发一起排查流量是否正常，是否存在被刷的情况。