Redis缓存
什么是Redis?
redis是内存中的数据结构存储系统，一个key-value类型的非关系型数据库，可持久化的数据库，相对于关系型数据库（数据主要存在硬盘中），性能高，因此我们一般用redis来做缓存使用；并且redis支持丰富的数据类型，比较容易解决各种问题，因此redis可以用来作为注册中心，数据库、缓存和消息中间件。Redis的Value支持5种数据类型，string、hash、list、set、zset（sorted set）;
- String类型：一个key对应一个value
- Hash类型：它的key是string类型，value又是一个map（key-value），适合存储对象。
- List类型：按照插入顺序的字符串链表（双向链表），主要命令是LPUSH和RPUSH，能够支持反向查找和遍历
- Set类型：用哈希表类型的字符串序列，没有顺序，集合成员是唯一的，没有重复数据，底层主要是由一个value永远为null的hashmap来实现的。
- zset类型：和set类型基本一致，不过它会给每个元素关联一个double类型的分数（score），这样就可以为成员排序，并且插入是有序的。
你还用过其他的缓存吗？这些缓存有什么区别？都在什么场景下去用？
对于缓存了解过redis和memcache
Memcache和redis的区别：
- 数据支持的类型：redis不仅仅支持简单的k/v类型的数据，同时还支持list、set、zset、hash等数据结构的存储；memcache只支持简单的k/v类型的数据，key和value都是string类型
- 可靠性：memcache不支持数据持久化，断电或重启后数据消失，但其稳定性是有保证的；redis支持数据持久化和数据恢复，允许单点故障，但是同时也会付出性能的代价
- 性能上：对于存储大数据，memcache的性能要高于redis
应用场景：
- Memcache：适合多读少写，大数据量的情况（一些官网的文章信息等）
- Redis：适用于对读写效率要求高、数据处理业务复杂、安全性要求较高的系统
案例：分布式系统，存在session之间的共享问题，因此在做单点登录的时候，我们利用redis来模拟了session的共享，来存储用户的信息，实现不同系统的session共享；
对redis的持久化了解不？
redis的持久化方式有两种：
RDB（半持久化方式）：按照配置不定期的通过异步的方式、快照的形式直接把内存中的数据持久化到磁盘的一个dump.rdb文件（二进制的临时文件）中，redis默认的持久化方式，它在配置文件（redis.conf）中。
- 优点：只包含一个文件，将一个单独的文件转移到其他存储媒介上，对于文件备份、灾难恢复而言，比较实用。
- 缺点：系统一旦在持久化策略之前出现宕机现象，此前没有来得及持久化的数据将会产生丢失
RDB持久化配置：
Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：
- save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
- save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
- save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。
AOF（全持久化的方式）：把每一次数据变化都通过write()函数将你所执行的命令追加到一个appendonly.aof文件里面，Redis默认是不支持这种全持久化方式的，需要在配置文件（redis.conf）中将appendonly no改成appendonly yes
- 优点：数据安全性高，对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机问题，也不会破坏日志文件中已经存在的内容；
- 缺点：对于数量相同的数据集来说，aof文件通常要比rdb文件大，因此rdb在恢复大数据集时的速度大于AOF；
AOF持久化配置:
在Redis的配置文件中存在三种同步方式，它们分别是：
- appendfsync always #每次有数据修改发生时都会都调用fsync刷新到aof文件，非常慢，但是安全；
- appendfsync everysec #每秒钟都调用fsync刷新到aof文件中，很快，但是可能丢失一秒内的数据，推荐使用，兼顾了速度和安全；
- appendfsync no #不会自动同步到磁盘上，需要依靠OS（操作系统）进行刷新，效率快，但是安全性就比较差；
二种持久化方式区别：
- AOF在运行效率上往往慢于RDB，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效；
- 如果缓存数据安全性要求比较高的话，用aof这种持久化方式（比如项目中的购物车）；
- 如果对于大数据集要求效率高的话，就可以使用默认的。而且这两种持久化方式可以同时使用。
做过redis的集群吗？你们做集群的时候搭建了几台，都是怎么搭建的？
- Redis的数据是存放在内存中的，不适合存储大数据，大数据存储一般公司常用hadoop中的Hbase或者MogoDB。redis主要用来处理高并发的，用我们的项目来说，电商项目如果并发大的话，一台单独的redis是不能足够支持我们的并发，这就需要我们扩展多台设备协同合作，即用到集群。
- Redis搭建集群的方式有多种，例如：客户端分片、Twemproxy、Codis等，但是redis3.0之后就支持redis-cluster集群，这种方式采用的是无中心结构，每个节点保存数据和整个集群的状态，每个节点都和其他所有节点连接。如果使用的话就用redis-cluster集群。集群这块是公司运维搭建的，具体怎么搭建不是太了解。
- 我们项目中redis集群主要搭建了6台，3主（为了保证redis的投票机制）3从（高可用），每个主服务器都有一个从服务器，作为备份机。所有的节点都通过PING-PONG机制彼此互相连接；客户端与redis集群连接，只需要连接集群中的任何一个节点即可；Redis-cluster中内置了16384个哈希槽，Redis-cluster把所有的物理节点映射到【0-16383】slot上，负责维护。
Redis有事务吗？
Redis是有事务的，redis中的事务是一组命令的集合，这组命令要么都执行，要不都不执行，保证一个事务中的命令依次执行而不被其他命令插入。redis的事务是不支持回滚操作的。redis事务的实现，需要用到MULTI（事务的开始）和EXEC（事务的结束）命令 ;
缓存穿透
缓存查询一般都是通过key去查找value，如果不存在对应的value，就要去数据库中查找。如果这个key对应的value在数据库中也不存在，并且对该key并发请求很大，就会对数据库产生很大的压力，这就叫缓存穿透。
解决方案：
- 对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃。
- 将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
- 如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。
缓存雪崩
当缓存服务器重启或者大量缓存集中在一段时间内失效，发生大量的缓存穿透，这样在失效的瞬间对数据库的访问压力就比较大，所有的查询都落在数据库上，造成了缓存雪崩。 这个没有完美解决办法，但可以分析用户行为，尽量让失效时间点均匀分布。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。
解决方案：
- 在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
- 可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存
- 不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀
- 做二级缓存，或者双缓存策略。A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期。
redis的安全机制（你们公司redis的安全这方面怎么考虑的？）
漏洞介绍：redis默认情况下，会绑定在bind 0.0.0.0:6379，这样就会将redis的服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在访问目标服务器的情况下，未授权就可访问redis以及读取redis的数据，攻击者就可以在未授权访问redis的情况下可以利用redis的相关方法，成功在redis服务器上写入公钥，进而可以直接使用私钥进行直接登录目标主机；
解决方案：
- 禁止一些高危命令。修改redis.conf文件，用来禁止远程修改DB文件地址，比如 rename-command FLUSHALL "" 、rename-command CONFIG"" 、rename-command EVAL “”等；
- 以低权限运行redis服务。为redis服务创建单独的用户和根目录，并且配置禁止登录；
- 为redis添加密码验证。修改redis.conf文件，添加requirepass mypassword；
- 禁止外网访问redis。修改redis.conf文件，添加或修改 bind 127.0.0.1，使得redis服务只在当前主机使用；
- 做log监控，及时发现攻击；
redis的哨兵机制（redis2.6以后出现的）：
- 监控：监控主数据库和从数据库是否正常运行；
- 提醒：当被监控的某个redis出现问题的时候，哨兵可以通过API向管理员或者其他应用程序发送通知；
- 自动故障迁移：主数据库出现故障时，可以自动将从数据库转化为主数据库，实现自动切换；
具体的配置步骤参考的网上的文档。要注意的是，如果master主服务器设置了密码，记得在哨兵的配置文件（sentinel.conf）里面配置访问密码
redis中对于生存时间的应用
Redis中可以使用expire命令设置一个键的生存时间，到时间后redis会自动删除；
应用场景：
- 设置限制的优惠活动的信息；
- 一些及时需要更新的数据，积分排行榜；
- 手机验证码的时间；
- 限制网站访客访问频率；
能讲下redis的具体使用场景吗？使用redis存储长期不改变的数据完全可以使用也看静态化，那么你们当时是为什么会使用redis？
redis在项目中应用：
- 主要应用在门户网站首页广告信息的缓存。因为门户网站访问量较大，将广告缓存到redis中，可以降低数据库访问压力，提高查询性能。
- 应用在用户注册验证码缓存。利用redis设置过期时间，当超过指定时间后，redis清理验证码，使过期的验证码无效。
- 用在购物车模块，用户登陆系统后，添加的购物车数据需要保存到redis缓存中。
使用redis主要是减少系统数据库访问压力。从缓存中查询数据，也提高了查询性能，挺高用户体验度。
Redis分布式锁理解
获取锁的时候，使用setnx加锁，并使用expire命令为锁添加一个超时时间，超过该时间则自动释放锁，锁的value值为一个随机生成的UUID，通过此在释放锁的时候进行判断。
- 获取锁的时候还设置一个获取的超时时间，若超过这个时间则放弃获取锁。
- 释放锁的时候，通过UUID判断是不是该锁，若是该锁，则执行delete进行锁释放。
- SETEX:如果 key 已经存在， SETEX 命令将覆写旧值。
- SETNX:若给定的 key 已经存在，则 SETNX 不做任何动作。
Redis怎么设置过期的？
设置过期：this.redisTemplate.expire("max",tempTime,TimeUnit.SECONDS);
讲到redis缓存的时候说不清楚
redis中项目中的使用场景：
- 主要应用在门户网站首页广告信息的缓存。因为门户网站访问量较大，将广告缓存到redis中，可以降低数据库访问压力，提高查询性能。
- 应用在用户注册验证码缓存。利用redis设置过期时间，当超过指定时间后，redis清理验证码，使过期的验证码无效。
- 用在购物车模块，用户登陆系统后，添加的购物车数据需要保存到redis缓存中。
技术角度分析：
- Redis如何实现负载的？采用Hash槽来运算存储值，使用CRC16算法取模运算，来保证负载问题。
- Redis缓存穿透问题？将数据查询出来如果没有强制设置空值，并且设置过期时间，减少频繁查询数据库。
- 使用redis主要是减少系统数据库访问压力。从缓存中查询数据，也提高了查询性能，挺高用户体验度。
Redis中对一个key进行自增或者自减操作，它是原子性的吗？
是原子性的。对于Redis而言，命令的原子性指的是：一个操作的不可以再分，操作要么执行，要么不执行。Redis的操作之所以是原子性的，是因为Redis是单线程的。对Redis来说，执行get、set以及eval等API，都是一个一个的任务，这些任务都会由Redis的线程去负责执行，任务要么执行成功，要么执行失败，这就是Redis的命令是原子性的原因。Redis本身提供的所有API都是原子操作，Redis中的事务其实是要保证批量操作的原子性。
项目添加Redis缓存后，持久化具体怎么实现的。
- RDB：保存存储文件到磁盘；同步时间为15分钟，5分钟，1分钟一次，可能存在数据丢失问题。
- AOF：保存命令文件到磁盘；安全性高，修改后立即同步或每秒同步一次。
上述两种方式在我们的项目中都有使用到，在广告轮播的功能中使用了redis缓存，先从redis中获取数据，无数据后从数据库中查询后保存到redis中。采用默认的RDB方式。
怎么提高redis缓存利用率？
- 从业务场景分析，预计会高频率用到的数据预先存放到redis中，
- 可以定时扫描命中率低的数据，可以直接从redis中清除。
Redis宕机之后，购物车中的数据如何处理？如何缓解mysql压力？
用redis保存的*.rdb文件恢复即可。另外redis还有AOF功能，启动时可以自动恢复到前一条查询。这样做在一定程度上减少数据丢失。但重启redis会需要从关系型数据库中读取数据，增大mysql的压力。依据实际情况，如果redis之前有主从复制，则可在其他节点redis上拿到数据。如果公司没钱，则只能暂时限制客户端访问量，优先恢复redis数据。
Redis和mysql数据同步，是先删除redis的数据还是先删除Mysql的数据？
不管是先写库，再删除缓存；还是先删缓存，再写库，都有可能出现数据不一致的情况。因为写和读是并发的，没法保证顺序，如果删了缓存，还没有来得及写库，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。如果先写了库，再删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。 如果是redis集群，或者主从模式，写主读从，由于redis复制存在一定的时间延迟，也有可能导致数据不一致。这时候，考虑先删除数据库内容，再删redis。因为在库存等实时数据都是直接在数据库中读取，从业务逻辑上来说，我们允许查询时的数据缓存误差，但是不允许结算时的数据存在误差。
Redis中watch机制和原理
我们常用redis的watch和multi来处理一些涉及并发的操作，redis的watch+multi实际是一种乐观锁。watch命令描述：WATCH命令可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行。监控一直持续到EXEC命令（事务中的命令是在EXEC之后才执行的，所以在MULTI命令后可以修改WATCH监控的键值）
讲讲缓存的设计和优化，缓存和数据库一致性同步解决方案
- 降低后端负载：对于高消耗的SQL：join结果集、分组统计结果；对这些结果进行缓存。
- 加速请求响应
- 大量写合并为批量写：如计数器先redis累加再批量写入DB
- 超时剔除：例如expire
- 主动更新：开发控制生命周期（最终一致性，时间间隔比较短）
- 缓存空对象
- 布隆过滤器拦截
- 命令本身的效率：例如sql优化，命令优化
- 网络次数：减少通信次数
- 降低接入成本:长连/连接池,NIO等。
- IO访问合并
目的：要减少缓存重建次数、数据尽可能一致、减少潜在危险。
解决方案：
互斥锁setex,setnx：
- 如果 set(nx 和 ex) 结果为 true，说明此时没有其他线程重建缓存，那么当前线程执行缓存构建逻辑。
- 如果 setnx(nx 和 ex) 结果为 false，说明此时已经有其他线程正在执行构建缓存的工作，那么当前线程将休息指定时间 ( 例如这里是 50 毫秒，取决于构建缓存的速度 ) 后，重新执行函数，直到获取到数据。
永远不过期：
热点key，无非是并发特别，重建缓存时间比较长，如果直接设置过期时间，那么时间到的时候，巨大的访问量会压迫到数据库上，所以要给热点key的val增加一个逻辑过期时间字段，并发访问的时候，判断这个逻辑字段的时间值是否大于当前时间，大于了说明要对缓存进行更新了，那么这个时候，依然让所有线程访问老的缓存，因为缓存并没有设置过期，但是另开一个线程对缓存进行重构。等重构成功，即执行了redis set操作之后，所有的线程就可以访问到重构后的缓存中的新的内容了
- 从缓存层面来看，确实没有设置过期时间，所以不会出现热点 key 过期后产生的问题，也就是“物理”不过期。
- 从功能层面来看，为每个 value 设置一个逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去构建缓存。
一致性问题：
- 先删除缓存，然后在更新数据库，如果删除缓存失败，那就不要更新数据库，如果说删除缓存成功，而更新数据库失败，那查询的时候只是从数据库里查了旧的数据而已，这样就能保持数据库与缓存的一致性。
- 先去缓存里看下有没有数据，如果没有，可以先去队列里看是否有相同数据在做更新，发现队列里有一个请求了，那么就不要放新的操作进去了，用一个while（true）循环去查询缓存，循环个200MS左右再次发送到队列里去，然后同步等待缓存更新完成。