redis缓存原理

redis缓存原理是sql语句时key值，查询结果resultSet是value，当同一个查询语句访问时（select from t_product），只要曾经查询过，调用缓存直接返回resultSet，节省了数据库读取磁盘数据的时间。

redis的存储分为内存存储、磁盘存储和log文件三部分，配置文件中有三个参数对其进行配置。

save seconds updates，save配置，指出在多长时间内，有多少次更新 *** 作，就将数据同步到数据文件。这个可以多个条件配合，比如默认配置文件中的设置，就设置了三个条件。

appendonly yes/no ，appendonly配置，指出是否在每次更新 *** 作后进行日志记录，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为redis本身同步数据文件是按上面的save条件来同步的，所以有的数据会在一段时间内只存在于内存中。

扩展资料

redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部 分场合可以对关系数据库起到很好的补充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端，使用很方便。

Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。

存盘可以有意无意的对数据进行写 *** 作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取 *** 作的可扩展性和数据冗余很有帮助。

redis的官网地址，redisio。（域名后缀io属于国家域名，是british Indian Ocean territory，即英属印度洋领地）

Redis-Sentinel是redis官方推荐的高可用性解决方案，
当用redis作master-slave的高可用时，如果master本身宕机，redis本身或者客户端都没有实现主从切换的功能。

而redis-sentinel就是一个独立运行的进程，用于监控多个master-slave集群，
自动发现master宕机，进行自动切换slave > master

每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令

如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。

如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。

当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线

在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令

当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次

若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。

若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

主观下线和客观下线

主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。
客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover

SDOWN适合于Master和Slave，只要一个 Sentinel 发现Master进入了ODOWN， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对下线的主服务器执行自动故障迁移 *** 作。

ODOWN只适用于Master，对于Slave的 Redis 实例，Sentinel 在将它们判断为下线前不需要进行协商， 所以Slave的 Sentinel 永远不会达到ODOWN。

Redis主从复制可将主节点数据同步给从节点，从节点此时有两个作用：

但是问题是：

那么这个问题，redis-sentinel就可以解决了

Redis的一个进程，但是不存储数据，只是监控redis

本实验是在测试环境下，因此只准备一台linux服务器用作环境！！

服务器环境，一台即可完成 *** 作

所有配置文件如下

总体redis配置文件如下，6379为master，6380和6381为slave

redis-6380conf slave配置文件详解，6381端口的配置文件，仅仅和6380端口不一样

在主节点上查看主从通信关系

在从节点上查看主从关系（6380、6379）

此时可以在master上写入数据，在slave上查看数据，此时主从复制配置完成

redis-sentinel-26379conf配置文件写入如下信息

redis-sentinel-26380conf和redis-sentinel-26381conf的配置仅仅差异是port(端口)的不同。
然后启动三个sentinel哨兵

此时查看哨兵是否成功通信

实例的思路

首先查看三个Redis的进程状态

第一个

第二个

第三个

直接干掉master，然后等待其他两个节点是否能自动被哨兵sentienl，切换为master节点

此时查看两个slave的状态

然后会发现slave节点成为master节点！！

1总的老说，优化方案中只有两种，一种是给查询的字段加组合索引。另一种是给在用户和数据库中增加缓存
2添加索引方案：面对1~2千的并发是没有压力的，在往上则限制的瓶颈就是数据库最大连接数了，在上面中我用show global status like 'Max_used_connections’查看数据库可以知道数据库最大响应连接数是5700多，超过这个数tomcat直接报错连接被拒绝或者连接已经失效
3缓存方案：在上面的测试可以知道，要是我们事先把数据库的千万条数据同步到redis缓存中，瓶颈就是我们的设备硬件性能了，假如我们的主机有几百个核心CPU，就算是千万级的并发下也可以完全无压力，带个用户很好的。
4索引+缓存方案：缓存事先没有要查询的数据，在一万的并发下测试数据库毫无压力，程序先通过查缓存再查数据库大大减轻了数据库的压力，即使缓存不命中在一万的并发下也能正常访问,在10万并发下数据库依然没压力，但是redis服务器设置最大连接数300去处理10万的线程，4核CPU处理不过来，很多redis连接不了。我用show global status like 'Max_used_connections'查看数据库发现最大响应连接数是388，这么低所以数据库是不会挂掉的。雷达下载更专业。
5使用场景：a几百或者2000以下并发直接加上组合索引就可以了。b不想加索引又高并发的情况下可以先事先把数据放到缓存中，硬件设备支持下可解决百万级并发。c加索引且缓存事先没有数据，在硬件设备支持下可解决百万级并发问题。d不加索引且缓存事先没有数据，不可取，要80多秒才能得到结果，用户体验极差。
6原理：其实使用了redis的话为什么数据库不会崩溃是因为redis最大连接数为300，这样数据库最大同时连接数也是300多，所以不会挂掉，至于redis为什么设置为300是因为设置的太高就会报错(连接被拒绝)或者等待超时(就算设置等待超时的时间很长也会报这个错)。

可以通过修改配置参数解决，工作中，曾遇到redis连接数一直不释放，导致请求阻塞甚至挂掉的问题。重启redis后，短暂性恢复正常，过一会又会异常。后来查阅相关文档了解到，对于此异常现象可以参考通过修改配置参数解决。
timeout 是指客户端和Redis服务端的连接超时时间，默认是0，表示永不超时；
tcp-keepalive 如果值非0，单位是秒，表示将周期性的使用SO_KEEPALIVE检测客户端是否还处于健康状态，避免服务器一直阻塞，官方给出的建议值是60。

1、缓存。 缓存现在几乎是所有中大型网站都在用的必杀技，合理的利用缓存不仅能够提升网站访问速度，还能大大降低数据库的压力。Redis提供了键过期功能，也提供了灵活的键淘汰策略，所以，现在Redis用在缓存的场合非常多。（推荐：《 Redis视频教程 》）
2、排行榜。 很多网站都有排行榜应用的，如京东的月度销量榜单、商品按时间的上新排行榜等。Redis提供的有序集合数据类构能实现各种复杂的排行榜应用。
3、计数器。 什么是计数器，如电商网站商品的浏览量、视频网站视频的播放数等。为了保证数据实时效，每次浏览都得给+1，并发量高时如果每次都请求数据库 *** 作无疑是种挑战和压力。Redis提供的incr命令来实现计数器功能，内存 *** 作，性能非常好，非常适用于这些计数场景。
4、分布式会话。 集群模式下，在应用不多的情况下一般使用容器自带的session复制功能就能满足，当应用增多相对复杂的系统中，一般都会搭建以Redis等内存数据库为中心的session服务，session不再由容器管理，而是由session服务及内存数据库管理。
5、分布式锁。 在很多互联网公司中都使用了分布式技术，分布式技术带来的技术挑战是对同一个资源的并发访问，如全局ID、减库存、秒杀等场景，并发量不大的场景可以使用数据库的悲观锁、乐观锁来实现，但在并发量高的场合中，利用数据库锁来控制资源的并发访问是不太理想的，大大影响了数据库的性能。可以利用Redis的setnx功能来编写分布式的锁，如果设置返回1说明获取锁成功，否则获取锁失败，实际应用中要考虑的细节要更多。

长期把Redis做缓存用，总有一天Redis内存会满的，怎么处理呢？
​
在Redis的配置文件 redisconf 文件中，配置 maxmemory 的大小参数如下所示：
​

​
倘若实际的存储中超出了Redis的配置参数的大小时，Redis中有 淘汰策略 ，把 需要淘汰的key给淘汰掉，整理出干净的一块内存给新的key值使用 。
​
Redis提供了 6种的淘汰策略 ，其中默认的是 noeviction ，这6中淘汰策略如下：
​

​

​
LRU(Least Recently Used) 即表示最近最少使用，也就是在最近的时间内最少被访问的key，算法根据数据的历史访问记录来进行淘汰数据。
​
它的核心的思想就是： 假如一个key值在最近很少被使用到，那么在将来也很少会被访问 。
​
实际上Redis实现的LRU并不是真正的LRU算法，也就是名义上我们使用LRU算法淘汰键，但是实际上被淘汰的键并不一定是真正的最久没用的。
​
Redis使用的是近似的LRU算法， 通过随机采集法淘汰key，每次都会随机选出5个key，然后淘汰里面最近最少使用的key 。
​
这里的5个key只是默认的个数，具体的个数也可以在配置文件中进行配置，在配置文件中的配置如下图所示：
​

​
当近似LRU算法取值越大的时候就会越接近真实的LRU算法，可以这样理解，因为 取值越大那么获取的数据就越全，淘汰中的数据的就越接近最近最少使用的数据 。
​
那么为了实现根据时间实现LRU算法，Redis必须为每个key中额外的增加一个内存空间用于存储每个key的时间，大小是3字节。
​
在Redis 30中对近似的LRU算法做了一些优化，Redis中会维护大小是 16 的一个候选池的内存。
​
当第一次随机选取的采样数据，数据都会被放进候选池中，并且候选池中的数据会根据时间进行排序。
​
当第二次以后选取的数据，只有 小于候选池内的最小时间 的才会被放进候选池中。
​
当某一时刻候选池的数据满了，那么时间最大的key就会被挤出候选池。当执行淘汰时，直接从候选池中选取最近访问时间最小的key进行淘汰。
​
这样做的目的就是选取出最近似符合最近最少被访问的key值，能够正确的淘汰key值，因为随机选取的样本中的最小时间可能不是真正意义上的最小时间。
​
但是LRU算法有一个弊端：就是假如一个key值在以前都没有被访问到，然而最近一次被访问到了，那么就会认为它是热点数据，不会被淘汰。
​
然而有些数据以前经常被访问到，只是最近的时间内没有被访问到，这样就导致这些数据很可能被淘汰掉，这样一来就会出现误判而淘汰热点数据。
​
于是在Redis 40的时候除了LRU算法，新加了一种LFU算法， 那么什么是LFU算法算法呢？
​

​
LFU(Least Frequently Used) 即表示最近频繁被使用，也就是最近的时间段内，频繁被访问的key，它以最近的时间段的被访问次数的频率作为一种判断标准。
​
它的核心思想就是：根据key最近被访问的频率进行淘汰，比较少被访问的key优先淘汰，反之则优先保留。
​
LFU算法反映了一个key的热度情况，不会因为LRU算法的偶尔一次被访问被认为是热点数据。
​
在LFU算法中支持 volatile-lfu 策略和 allkeys-lfu 策略。
​

​
在Redis种有三种删除的 *** 作此策略，分别是：
​

​
在Redis中持久化的方式有两种 RDB 和 AOF
​
在RDB中是以快照的形式获取内存中某一时间点的数据副本，在创建RDB文件的时候可以通过 save 和 bgsave 命令执行创建RDB文件。
​
这两个命令都不会把过期的key保存到RDB文件中 ，这样也能达到删除过期key的效果。
​
当在启动Redis载入RDB文件的时候， Master 不会把过期的key载入，而 Slave 会把过期的key载入。
​
在AOF模式下，Redis提供了Rewite的优化措施，执行的命令分别是 REWRITEAOF 和 BGREWRITEAOF ， 这两个命令都不会把过期的key写入到AOF文件中，也能删除过期key 。
​

​
RDB 是一种快照存储持久化方式，具体就是将 Redis 某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为 dumprdb ，而在 Redis 服务器启动时，会重新加载 dumprdb 文件的数据到内存当中恢复数据。
​
开启RBD持久化方式
​
开启 RDB 持久化方式很简单，客户端可以通过向 Redis 服务器发送 save 或 bgsave 命令让服务器生成 rdb 文件，或者通过服务器配置文件指定触发 RDB 条件。
​

​
save 命令是一个同步 *** 作。
​

​

​
当客户端向服务器发送 save 命令请求进行持久化时，服务器会阻塞 save 命令之后的其他客户端的请求，直到数据同步完成。
​

​
与 save 命令不同， bgsave 命令是一个异步 *** 作。
​

​
​
​

​
​
​
当客户端发服务发出 bgsave 命令时， Redis 服务器主进程会 forks 一个子进程来数据同步问题，在将数据保存到rdb文件之后，子进程会退出。
​
所以，与 save 命令相比， Redis 服务器在处理 bgsave 采用子线程进行IO写入，而主进程仍然可以接收其他请求，但 forks 子进程是同步的，所以 forks 子进程时，一样不能接收其他请求，这意味着，如果forks一个子进程花费的时间太久(一般是很快的)，bgsave命令仍然有阻塞其他客户的请求的情况发生。
​

​
除了通过客户端发送命令外，还有一种方式，就是在 Redis 配置文件中的 save 指定到达触发RDB持久化的条件，比如多少秒内至少达到多少写 *** 作就开启 RDB 数据同步。
​
例如我们可以在配置文件redisconf指定如下的选项：
​

​
之后在启动服务器时加载配置文件。
​

​
这种通过服务器配置文件触发RDB的方式，与bgsave命令类似，达到触发条件时，会forks一个子进程进行数据同步，不过最好不要通过这方式来触发RDB持久化，因为设置触发的时间太短，则容易频繁写入rdb文件，影响服务器性能，时间设置太长则会造成数据丢失。
​

​
介绍了三种让服务器生成rdb文件的方式，无论是由主进程生成还是子进程来生成，其过程如下：
​

​

​

​

​
Redis 的另外一个持久化方式： AOF(Append-only file) 。
​
与 RDB 存储某个时刻的快照不同， AOF 持久化方式会记录客户端对服务器的每一次写 *** 作命令，并将这些写 *** 作以 Redis 协议追加保存到以后缀为 aof 文件末尾，在Redis服务器重启时，会加载并运行 aof 文件的命令，以达到恢复数据的目的。

​

​
Redis默认不开启AOF持久化方式，我们可以在配置文件中开启并进行更加详细的配置，如下面的redisconf文件：
​

​

​
在上面的配置文件中，我们可以通过 appendfsync 选项指定写入策略,有三个选项
​

​

​
客户端的每一个写 *** 作都保存到 aof 文件当，这种策略很安全，但是每个写请注都有IO *** 作，所以也很慢。
​

​
appendfsync 的默认写入策略，每秒写入一次 aof 文件，因此，最多可能会丢失1s的数据。
​

​
Redis 服务器不负责写入 aof ，而是交由 *** 作系统来处理什么时候写入 aof 文件。更快，但也是最不安全的选择，不推荐使用。
​

​
AOF将客户端的每一个写 *** 作都追加到 aof 文件末尾，比如对一个key多次执行incr命令，这时候， aof 保存每一次命令到aof文件中，aof文件会变得非常大。
​

​
aof文件太大，加载aof文件恢复数据时，就会非常慢，为了解决这个问题，Redis支持aof文件重写，通过重写aof，可以生成一个恢复当前数据的最少命令集，比如上面的例子中那么多条命令，可以重写为：
​

​

​
通过在redisconf配置文件中的选项no-appendfsync-on-rewrite可以设置是否开启重写，这种方式会在每次fsync时都重写，影响服务器性能，因此默认值为no，不推荐使用。
​

​
客户端向服务器发送bgrewriteaof命令，也可以让服务器进行AOF重写。
​

​
AOF重写方式也是异步 *** 作，即如果要写入aof文件，则Redis主进程会forks一个子进程来处理，如下所示：
​
​
​

​

​

​
在写入aof日志文件时，如果Redis服务器宕机，则aof日志文件文件会出格式错误，在重启Redis服务器时，Redis服务器会拒绝载入这个aof文件，可以通过以下步骤修复aof并恢复数据。
​

​

​
AOF只是追加日志文件，因此对服务器性能影响较小，速度比RDB要快，消耗的内存较少。
​

​

​
我们可以从几个方面对比一下RDB与AOF,在应用时，要根本自己的实际需求，选择RDB或者AOF，其实，如果想要数据足够安全，可以两种方式都开启，但两种持久化方式同时进行IO *** 作，会严重影响服务器性能，因此有时候不得不做出选择。
​

​
当RDB与AOF两种方式都开启时，Redis会优先使用AOF日志来恢复数据，因为AOF保存的文件比RDB文件更完整。

---