redis必备知识点

作为it的界的泰山级别工具,在程序的世界里几乎也是无处不在,如此重要的它,你真的了解了么


1.redis在线练习
链接：http://try.redis.io/#run




3. redis大key问题
其一般指的是单个key存储的value值很大或者hash,set,zset,list等元素结构中存储很多的元素通常是指以万为单位的
解决大key,若是value过大，可以采用分段获取的方式,避免整存整取造成io开销过大；针对是数据结构很大的问题，可以采用元素分拆的方式
删除大key，在redis4.0版本之后,建议使用unlink命令,其实现原理是另外开一个线程进行处理，这样就避免了线上可能造成的阻塞等问题
* 尽量从业务上避免 Redis 大 Key，无论从性能角度（hash成本）还是过期删除成本角度，都会比较高
* 尽量使用 unlink 代替 del 删除大 key
* key 的自然过期和手动删除，都会阻塞 Redis

4.分布式锁
对于分布式锁一般实现方案有redis和zookeeper两种实现方案
针对利用 redis 实现常用的命令是 setex 与expire命令,使用二者注意点,需要保证任务执行的原子性，以避免服务失败造成的不可控现象

Redis更加高级分布式实现redlock或者redisson实现
针对分布式锁的实现重点在与其操作的互斥性,在任意一个时刻，只有一个客户端获取了锁
参考链接：https://juejin.im/post/5cc165816fb9a03202221dd5

执行逻辑：SET key-with-expire-time "hello" EX 10086，将key设置为value，当键不存在时，才能成功，若键存在，什么也不做，成功返回1，失败返回0
问题一：假入服务突然宕机，这个任务就会永远得不到释放,因此需要加入超时机制
问题二：假如加锁与释放锁之间的执行逻辑时间过长，导致锁的expire命令被执行，这时其余的线程就可以获取到这把锁，导致问题的产生
这里一般建议redis分布式锁不要用于执行周期过长的任务

注意：新版本的set 已经兼容了setnx与setex,在分布式中一般使用setex，因为其是一个原子操作



11.关于redis中的rehash,即字典扩容
这里一般指的是扩容的时候进行的操作步骤,在java中hashmap在扩容是会一次性将旧数组下面挂载的元素全部移到新数组下面,如果hashmap中的元素特别多，线程就会出现卡顿的现象,redis为了解决这个问题就采用了渐进式hash的操作
其操作原理是:它会同时保留新数组和旧数组,然后在定时任务中以及后续对hash的指定操作中渐渐的将旧数组的元素挂载到新数组的下面，但这也意味着对于在操作rehash中的字典，需要访问新旧两个数组，旧的找不到则去新的数组寻找，但其效率依旧可观



13.redis效率块的原因
Redis采用的就是单线程(nginx , node.js也是)避免了不必要的上下文切换和竞争条件,也不存在多进程多线程导致的切换而消耗cpu所有的运算都是内存级别的运算,所以正因为redis是单线程故应该避免出现复杂度oN的操作，
数据结构简单，redis中的数据结构是专门设计的
非阻塞io,以及时间轮询，多路i/o复用模型
底层通信方式不同,Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求
开多个实例对象，解决应用多核的问题






14.redis中的缓存雪崩
正常流程:客户端=>服务器=>web应用=>redis缓存=>数据库(redis缓存有数据直接返回,但是要是redis因为某某原因出了故障,所有的请求全部落在了mysql上面,此时就造成了缓存雪崩)


造成雪崩的场景主要有
Redis挂掉了;缓存过期时间设置相同，导致的

* 解决方法：在缓存的时候给过期时间加上一个随机值，这样就会大幅度的减少缓存在同一时间过期。

对于“Redis挂掉了，请求全部走数据库”这种情况，我们可以有以下的思路：
* 事发前：实现Redis的高可用(主从架构+Sentinel 或者Redis Cluster)，尽量避免Redis挂掉这种情况发生。

* 事发中：万一Redis真的挂了，我们可以设置本地缓存(ehcache)+限流(hystrix)，尽量避免我们的数据库被干掉(起码能保证我们的服务还是能正常工作的)

* 事发后：redis持久化，重启后自动从磁盘上加载数据，快速恢复缓存数据。


15.Redis过期时间操作策略
* 惰性删除(对CPU极度友好，对内存极度不友好)

    * 每次从键空间取值的时候，判断一下该键是否过期了，如果过期了就删除。(需要手动查询判断)

* 定时删除(折中)

    * 将过期的key放入字典里,每隔一段时间去遍历来删除到期的key，注意这里会限制删除的执行时长(25ms)和频率，以保证不会出现线程卡死的状态

Redis的从库删除策略是被动的，它只接受主库存在AOF里的指定，来进行操作

Redis采用的是惰性删除+定时删除两种策略，所以说，在Redis里边如果过期键到了过期的时间了，未必被立马删除的
如果定期删除漏掉了很多过期key，也没及时去查(没走惰性删除)，大量过期key堆积在内存里，导致redis内存块耗尽了，咋整？
我们可以设置内存最大使用量，当内存使用量超出时，会施行数据淘汰策略，也就是保存热点数据，实行LRU淘汰

LRU算法的实现大致为(必须有的key,value，链表)，链表中的元素会按照一定的顺序进行排序，当空间满的时候，会踢掉尾部的元素，当字典中的某个元素被访问时,其会被移动到链表的表头,位于尾部不被利用的元素就被删除了

注意：redis采用的是近似LRU算法(数据结构大致为,key，value,每个key会有一个指定的时间戳,采用惰性删除原则,每次内存容量不够了才会在内存中随机出一部分元素,然后进行时间戳判断,进行删除,但注意如果内存依然不够,依旧会进行上一步的操作)




16.关于redis的缓存穿透
常指的是请求的数据在缓存大量不命中，导致请求走数据库(比如有人故意请求一个id为-1的数据,这个数据在缓存不存在，所以每次都会走数据库)

解决方案：将这个空对象也存入缓存，过期时间根据业务判断来，接口层面的校验也很重要，参数不合法直接返回，nginx设置ip每秒访问次数超出阀值拉黑；利用布隆过滤器进行拦截，不合法的请求无法请求数据库

在开发程序的时候，我们应该需要有一颗不信任的心,因此在开发接口中任何可能得参数都用该考虑，做一个不相信接口调用者的人
（问题，故意高速请求分页很大的数据，怎么处理）


17.关于redis的缓存击穿
与缓存雪崩不同点是,雪崩是大面积失效,击穿则是针对一个或者多个key非常热点,导致数据库无法承受

缓存击穿设置热点数据很长时间才过期或者不过期，加上互斥锁，但不建议,影响效率


17.统计网站pv,uv

统计pv,使用hash  hset key field value
Hset index.html 112 1   field随机就可以，不需要去重,每点击一次写入一次数据库
key可以选择URI与对应的日期进行拼凑，field可以使用用户的id或者随机标识，value可以简单设置为1
最后，hlen key 得到数据总量
缺点：占用内存过大。随着key的增多，性能也会下降

使用：setbit index 12 1  每个字段的设置可以参考hset
统计总量bitcount index

统计uv,需要去重采用，HyperLogLog 提供不精确的去重计数方案，虽然不精确但是也不是非常不精确，标准误差是 0.81%
命令设置值 pfadd uv user1 ，pfadd uv user1
统计总数pfcount uv

pfadd uv1 user1

合并两个统计
pfmerge database uv uv1
pfcount database



18.redis的高级命令
Geo命令：可以实现附近的人，经纬度计算，摇一摇等功能
Pub/Sub命令：常用于发布与订阅一次产生多次消费，可能会存在消息丢失的情况
cl.throttle模块，需要进行单独安装配置,可以用于接口限流
BloomFilter命令：常用于新闻推送的过滤，原理实现,在向布隆过滤器添加key时,会使用多个hash函数对key进行hash，每个hash函数算的一个整数索引值，然后对数组长度取模运算得到一个位置，最后进行add操作，也就是将这个空间置为1，判断元素是否存在逻辑处理方式一样，只要hash出来操作后有为0的即不存在，全为1大概率存在，原理链接https://juejin.im/post/5db69365518825645656c0de,布隆比较鸡肋的是，无法删除，来了就永远有痕迹，随着数量越来越大，其占用的空间也会越来越大，因此可以采用布谷鸟过滤器试试，参考链接https://mp.weixin.qq.com/s/XxY3b5FoVXCvHJWMxQH29g
HyperLogLog：常用于网站的uv统计等，其实现是提供不精确的去重
Redis Module：除了redis本身提供的功能，module还可以进行额外的扩展
Redisearch：类似于es,可用于搜索功能，也是一个需要安装的扩展模块
Redis-ML:实现实时机器学习
关于BloomFilter与HyperLogLog区别https://zhuanlan.zhihu.com/p/112405834



19.redis的异步队列
Lpush生产消息,lpop消费消息（这个实现模式为栈,后进先出）,若果lpop没有消息，可以sleep一会，也可以用blpop aw 10阻塞10秒这种操作


20.redis实现延时队列信息
ZSET有序集合实现,命令zadd命令来实现，zadd my score value 将任务的执行时间作为score,要执行的数据作为value
用一个进程定时查询zset的score分数最小的元素,score可以用时间戳,得到最小的元素ZRANGEBYSCORE key -inf +inf limit 0 1 withscores
链接：https://juejin.im/post/5caf45b96fb9a0688b573d6c








21.redis持久化机制
Redis支持两种持久化的方式
RDB全量备份，是内存数据的二进制序列化形式;AOF日志增量备份，记录redis所有命令行来实现的，所以AOF长时间运行会变得很大，每次重启都需要加载AOF命令重放，时间会变得很长，所以需要定期重写，进行日志瘦身

快照备份原理：在服务线上请求的时候，redis还需要进行内存快照，而内存快照必须涉及到文件的io操作，但文件的io操作是无法进行多路复用的，并且线上环境的数据可能在随时进行改变，针对这些问题redis采用了操作系统的多进程COW（Copy On Write）机制来实现RDB持久化

Redis在RDB持久化的时候会调用glibc的函数fork一个子进程，这是父进程负责处理客户端的正常请求，子进程负责快照备份,注意，在子进程刚刚产生是，其和父进程会共享内存数据，在父进程需要更改数据时，操作系统的COW就起作用了（对数据段进行页面分离）,并且将当前共享的页数据copy一份，这样子进程的数据就不会有影响了

AOF原理：在客户端执行命令时，先进性参数语法等校验，若没有问题就会立即将该指定存到AOF日志里面，然后在进行指定执行，这样就算服务突然宕机影响也不大，但是前面说到，宕机重启会进行AOF日志重放，导致很长的启动时间

AOF瘦身:redis提供了bgrewriteaof 指定对日志进行瘦身,原理就是新增一个子进程对内存进行遍历并转换成redis的操作指定,序列化到一个新的AOF文件里面,序列化完成之后，再将操作期间的增量AOF日志追加到新的AOF日志中就可以，完成后替代旧的AOF，瘦身完成，注意如果不进行瘦身，redis就会进行覆盖操作，也就是当内存满了的时候，redis就会从头开始覆盖之前前面的内容


AOF可能存在的数据丢失问题:AOF是程序对日志文件的写操作，内容写到内核缓存=>内核异步将数据刷新到磁盘，注意这个步骤就有可能导致小量的数据丢失，在linux中提供了fsync函数可以将制定文件的内容强制从内核缓存刷到磁盘,只要redis进程实时调用fsync函数就可以保证日志不丢失,但是文件写磁盘是一个耗时操作，效率即成为瓶颈
所以在生产环境中一般都是1s左右执行一次fsync函数（该函数是一个异步操作），保证相对的效率与安全（前面不会丢失是每一个命令执行一次），注意这个的1s是可以进行手动配置的（其还有一种机制，就是用不执行fsync，让操作系统决定何时同步磁盘，不安全）

在做持久化的操作中，一般建议采用从库进行处理


Redis4.0版本引入了混合持久化，重启redis时，将RDB文件的内容和增量的AOF日志文件存在一起，这里的AOF日志不是指全量AOF日志,而是某段时间内的增量AOF日志，如此便达到了效率的提升

在CAP理论下，redis是丢弃了一致性原则的，它保证的是可用性以及最终一致性

tip：两种机制全部开启的时候，Redis在重启的时候会默认使用AOF去重新构建数据，因为AOF的数据是比RDB更完整的


在redis2.8版本后redis开始支持无盘复制：操作原理就是主节点遍历内存，并将内容发送到从节点,这个就省去了复制所带来的开销




22.redis实现主从同步机制
你启动一台slave 的时候，他会发送一个psync命令给master ，如果是这个slave第一次连接到master，他会触发一个全量复制。master就会启动一个线程，生成RDB快照，还会把新的写请求都缓存在内存中，RDB文件生成后，master会将这个RDB发送给slave的，slave拿到之后做的第一件事情就是写进本地的磁盘，然后加载进内存，然后master会把内存里面缓存的那些新命名都发给slave。




23.redis五种数据类型的以及应用场景举例
五种数据结构,至于字符串与list其部分命令开始不是以S或者L开头的,其余都是对应类型开头的
string：存储session,分布式锁
List：异步队列，分页存储
set:自动去重功能，无序
Zset:去重,并且可以排序，可以用来做延时任务，微博热搜版等
Hash：可用于统计网站pv,但存储空间较大,不建议hset key field value




24.redis中的管道
易错知识:redis中的管道命令跟服务器是没有关系的，其实现本质上是由客户端提供的，其效率高的关键原因是将多个命令合并成一个命令,减少了每执行一个命令就有一次网络来回的消耗，因此管道中命令越多，效果越好

深入理解管道本质
使用管道命令时,其读写的实现分别是
Write：write操作只负责将数据写到本地操作系统内核的发送缓冲然后就返回了，剩下的事务交给操作系统内核异步将数据送到目标机器,但是如果发送区缓冲满了，那么就需要等待缓冲空出空闲空间来，这个就是写io操作的真正耗时

Read:read操作只负责将数据冲本地的操作系统内核接收缓冲区取出来就完事了，但是如果缓冲区，那么就需要等待数据到来,这个就是读操作的io的真正耗时，但是读取相对会比write耗时，因为它要等待消息经过网络路由到目标机器处理后的响应消息,但是其响应也只会有一次网络消耗


25.关于redis事务
Redis本身是不支持事务的,因为其无法保证原子性（要么全部成功,要么全部失败）,也无法提供回滚机制,但是其可以通过乐观锁的方式来解决部分场景

回顾mysql事务:begin=>sql语句=>（成功commit,失败rollback）（mysql的sql语句有多条，某一条失败了,其余命令都可以回滚不执行,没有错误才用commit进行提交）
Redis事务:multi=>redis 命令=>exec（假如redis有多条命令,其中一条是失败的,但不会影响到其余命令的执行,并且exec之后是没有回滚的,exec执行便提交了）

解决办法,引入redis的乐观锁机制,也就是是watch机制，在事务开始之前才用watch对一个或多个变量进行监听,在执行exec指定是，其会进行监听变量检查，若有改动，其就会返回null，这个时候在程序里面可以选择进行重试等操作


27.关于redis与Memcached对比
Redis 相比 Memcached 来说，拥有更多的数据结构，能支持更丰富的数据操作。如果需要缓存能够支持更复杂的结构和操作， Redis 会是不错的选择。
Redis 原生支持集群模式：
在 redis3.x 版本中，便能支持 Cluster 模式，而 Memcached 没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据。
性能对比：
由于 Redis 只使用单核（创建多个实例可以使用多核），而 Memcached 可以使用多核，所以平均每一个核上 Redis 在存储小数据时比 Memcached 性能更高。而在 100k 以上的数据中，Memcached 性能要高于 Redis，虽然 Redis 最近也在存储大数据的性能上进行优化，但是比起 Remcached，还是稍有逊色
另外，使用 Memcached 有一些限制，这些限制在现在的互联网场景下很致命，成为大家选择Redis、MongoDB的重要原因：
* key 不能超过 250 个字节；
* value 不能超过 1M 字节；
* key 的最大失效时间是 30 天；
* 只支持 K-V 结构，不提供持久化和主从同步功能。




29。redis的内存回收机制
Redis并不总是可以将空闲的内存立即归还给操作系统；假如某一时刻删除了1GB的key,这个时候你去观察内存，你会发现，其实并没有很大的变化,原因是操作系统回收内存是以页为单位的，如果该页中还有一个key在使用，那么就无法进行回收，redis删除了1GB的key，这个key获取都分配在不同的页中，因此是无法立即回收的，但你如果执行了flushdb就会一次性被回收,为了解决这个问题，redis采用了重用操作，就好像电影院，redis是座位空了后，我还可以再次使用，操作系统的逻辑是直接把座位都搬走了


30.高并发场景下的限流，降级，熔断，隔离
限流，顶不住就挡一部分出去但是不能说不行，降级，降级了还是被打挂了，熔断，至少不要影响别的系统，隔离，你本身就独立的，但是你会调用其他的系统嘛，你快不行了你别拖累兄弟们啊。
降级:当某些业务流程代码执行速度太过缓慢，自动放了该业务代码的执行，熔断和降级两个概念极为接近

Redis也有命令可以支持限流操作，好像是指定时间可以执行多少次之类的概念
前端限流：这个很简单，一般秒杀不会让你一直点的，一般都是点击一下或者两下然后几秒之后才可以继续点击，这也是保护服务器的一种手段。
后端限流：秒杀的时候肯定是涉及到后续的订单生成和支付等操作，但是都只是成功的幸运儿才会走到那一步，那一旦100个产品卖光了，return了一个false，前端直接秒杀结束，然后你后端也关闭后续无效请求的介入了。



30.怎么分析redis中OPS过高的问题
redis中的OPS 即operation per second 每秒操作次数
redis-cli --host 192.168.x.x --port 6379 monitor
https://mp.weixin.qq.com/s/eSx4aL7iaMZlW0cPZswghA





31.redis怎么解决查找到热key，以及解决方案

凭借业务经验,进行预估哪些是热key，比如该商品在做秒杀，就可以知道该商品是热key，缺点，并非所有的业务都可以预估哪些key为热key

在客户端进行收集，缺点对业务造成了入侵，但也是目前业内的大部分解决方案

在代理层做收集

解决方案,利用二级缓存策略，将热key在本地缓存，每次请求先经过本地的判断

备份热key,不让所有的key走同一台redis就可以了
链接：https://www.cnblogs.com/rjzheng/p/10874537.html




41.redis的集群与分片实现
一：redis  sentiner 这是redis最初解决redis 主从复制可能带来的问题方案，毕竟两个节点是有限的，主挂了还需要手动去操作从,在这个背景下，redis 哨兵诞生了,它可以根据需要创建多个节点，做到三地五中心,并且其还有自动的监听方案,某一节点挂点，自动升级主节点等

二:但上诉方案的主要问题是，每台机器的存储空间是有上限的,就相当于一个实例多个对象一样，其每台机器存储的内容是相同的，这个时候 诞生了 codis ,它的主要功能是分片,也就是将数据分配的多台机器上面，解决当个机器的内存不足的问题，并且其支持动态增加机器（codis是由国人用go语言开发,其原理都是依赖客户端进行一系列的操作来完成的，并且其是有图形化操作界面的，但因为不是redis官方项目，其命运也是比较担忧的，因为其无法与redis的版本迭代进行同步）

三：redis cluster ,redis自己的亲儿子,也是目前的主流集群分片方案
Redis cluster默认会对key进行crc32算法进行hash得到一个整数值，然后利用这个整数值对16384进行取模得到具体的槽位，注意，redis是支持将key指定槽位的
跳转：当客户端向一个错误的节点发送了指定，该槽位会发现指定key并不归自己的槽位管理,这是他会向客户端发送一个特殊的指定携带目标节点地址，高速客户端去此节点获取数据
迁移:redis 提供了redis-trib(ruby语言开发)工具，可以让操作者手动调整槽位的分配情况
容错:使用分片时，可以为每个主节点设置若干个从节点，当出现单点故障是，自动会有从节点升级为主节点
网络抖动:在网络世界中网络抖动是一种很常见的现象，也就是某一时间段突然无法访问，但是过段时间又恢复正常的情况,在redis中，会采用timeout机制，当超过设定时间时，才会认定该节点挂了,才会进行主从切换(避免了网络频繁抖动就进行主从切换的开销等问题)
节点下线机制:一个节点的失联并不代表所有的节点都认为其失联了，因此redis会有一个协商的机制,当某一节点认为某节点挂掉了会立即使用gossip协议进行集群广播进行信息传递，这是当大多数节点都无法感知到挂掉的节点时，其就会认为该节点已经挂掉,并且进行广播，强制进行下线





43.redis五种数据结构底层实现
Zset：底层实现采用跳跃表与hash实现，利用hash来存储value和score的关系，利用跳跃表来维护score的关系
具体实现:https://mp.weixin.qq.com/s/NOsXdrMrWwq4NTm180a6vw
String:redis的字符串储存方式并没有简单的采取一种类型,而是会根据值的大小等因素进行取值然后存到内存，这样可以保证其内存使用的最大效率化
List:实现方式是一个双端链表，其既可以实现队列，又可以实现栈,在早期的版本中元素较少时使用的是ziplist,元素多时采用的的linkedlist，但直接采用上面两种数据结构对内存的消耗是很大的，需要维护前后双向指针,所以改成了quicklist结构类型,是上面两种数据结构的混合体
链接：https://mp.weixin.qq.com/s/MT1tB2_7f5RuOxKhuEm1vQ

hash:通过hash实现,当hash出现冲突是通过数组+链接法解决hash冲突的和java的hashMap一样,python采用的是外链法解决hash冲突的
关于外键与链接优缺点https://zhuanlan.zhihu.com/p/33496977 


Set:无序的,唯一，其底层机构跟字典是一样的,唯一区别就是其value为null,

针对list与hash:其在redis3.2版本之前并且数据量较小的时候都是采用压缩列表来实现最小存储单元的，压缩列表是 一块连续的内存空间，元素之间紧挨着存储，没有任何冗余空隙，后来 Redis 新版本3.2对列表数据结构进行了改造，使用 quicklist 代替了 ziplist 和 linkedlist
具体实现：https://zhuanlan.zhihu.com/p/102422311






44.使用redis缓存的考虑
使用内存进行数据存储开销很大，高成本,因此redis最好只存储一些常用和主要的数据；
如果数据命中率很低,也没必要写入缓存,少量请求数据完全能够抵挡，不香么
如果数据是频繁的写入数据，也没必要使用缓存
数据量太大，没必须要使用缓存


45.Redis的优缺点
优点：
* 读写性能优异， Redis能读的速度是 110000 次/s，写的速度是 81000 次/s。

* 支持数据持久化，支持 AOF 和 RDB 两种持久化方式。

* 支持事务，Redis 的所有操作都是原子性的，同时 Redis 还支持对几个操作合并后的原子性执行。

* 数据结构丰富，除了支持 string 类型的 value 外还支持 hash、set、zset、list 等数据结构。

* 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。

缺点
* 数据库 容量受到物理内存的限制，不能用作海量数据的高性能读写，因此 Redis 适合的场景主要局限在较小数据量的高性能操作和运算上。

* Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的 IP 才能恢复。

* 主机宕机，宕机前有部分数据未能及时同步到从机，切换 IP 后还会引入数据不一致的问题，降低了 系统的可用性。

* Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。




46.redis为什么使用单线程
官方解释
因为 Redis 是基于内存的操作，CPU 不是 Redis 的瓶颈，Redis 的瓶颈最有可能是 机器内存的大小 或者 网络带宽。既然单线程容易实现，而且 CPU 不会成为瓶颈，那就顺理成章地采用单线程的方案了。

个人总结:
1. 使用单线程模型能带来更好的 可维护性，方便开发和调试；

2. 使用单线程模型也能 并发 的处理客户端的请求；(I/O 多路复用机制)

3. Redis 服务中运行的绝大多数操作的 性能瓶颈都不是 CPU；




47.什么是redis的压缩列表
同整数集合一样压缩列表也不是基础数据结构，而是 Redis 自己设计的一种数据存储结构。它有点儿类似数组，通过一片连续的内存空间，来存储数据。不过，它跟数组不同的一点是，它允许存储的数据大小不同
链接:https://mp.weixin.qq.com/s?__biz=MzU3OTk1MjMyMA==&mid=2247483700&idx=1&sn=8613dcc63a6419af2b941a64c2c58534&scene=21#wechat_redirect




49.redis的info指定
这个是redis的一个常用指定，经常用来查看服务器运行参数，CPU，内存，主从复制，主从同步，redis连接了多少客户端，每秒执行了多少次指定等信息


50.redis安全问题
1.对类似flushdb,flushall,keys等类指定进行禁用
2.指定ip访问,密码访问
3.一用户身份启动redis
4.使用ssl代理加密,加入跨机房了那么数据传输就相当于对外暴露了,这是对传输数据加密是比较好的方法, redis官方推荐的工具是spiped



52.redis中的hash攻击
如果hash函数存在偏向性,黑客就可能利用偏向性对服务器进行攻击,存在偏向性的hash函数在特定模式下的输入会导致hash第二链表长度极为不均匀,甚至所有的元素都集中在个别链表里面,导致redis的性能急剧下降,这就是hash攻击(redis采用的是siphash，可以避免这种情况)

备注:此图并非个人总结,来源于:https://github.com/AobingJava/JavaFamily/blob/master/docs/redis/%E8%AF%BE%E4%BB%A3%E8%A1%A8%E6%80%BB%E7%BB%93.md