Redis深入学习

荒废的技术。。。这边没环境学习，在线可以练习下

http://try.redis.io/

 

本地安装 brew install redis

启动 redis-server

安装完毕参考以下博客

https://www.cnblogs.com/huaxingtianxia/p/11736928.html

 

二、使用redis的常用命令
1.启动redis服务

brew services start redis
2.关闭redis服务

brew services stop redis
3.重启redis服务

brew services restart redis
4.打开图形化界面

redis-cli
 三、一些常用的配置
1.开机启动redis命令

ln -sfv /usr/local/opt/redis/*.plist ~/Library/LaunchAgents
2.使用配置文件启动redis-server

redis-server /usr/local/etc/redis.conf
3.停止redis服务

redis-cli shutdown
4. redis配置文件位置

/usr/local/etc/redis.conf
 5.卸载redis

brewuninstallredis rm ~/Library/LaunchAgents/homebrew.mxcl.redis.plist
6.允许远程访问

vim /usr/local/etc/redis.conf
注释bind，默认情况下 redis不允许远程访问，只允许本机访问。

#bind 127.0.0.1
注：在redis3.2之后，redis增加了protected-mode，在这个模式下，即使注释掉了bind 127.0.0.1，再访问redisd时候还是报错，需要把protected-mode yes改为protected-mode no

 

这篇文章写得不错  https://www.cnblogs.com/dijia478/p/8058775.html

 

命令行学习  https://www.runoob.com/redis/redis-install.html

 

Redis为什么那么快？

• 纯内存KV操作
• 内部是单程实现的（不需要创建/销毁线程，避免上下文切换，无并发资源竞争的问题）
• 异步非阻塞的I/O（多路复用）
   

  ---

  相关资源

  Redis 官网：https://redis.io/

  Redis 在线测试：http://try.redis.io/

  Redis 命令参考：http://doc.redisfans.com/

 

---

---

1. 为什么redis缓存速度快？
2. 缓存穿透问题？
3. 缓存雪崩问题？
4. 缓存击穿问题？
5. 数据结构及使用场景

为什么redis缓存速度快

redis到底有多快

        Redis采用的是基于内存的采用的是单进程单线程模型的 KV 数据库，由C语言编写，官方提供的数据是可以达到100000+的QPS（每秒内查询次数）。这个数据不比采用单进程多线程的同样基于内存的 KV 数据库 Memcached 差！

redis为什么这么快

       redis速度快的原因主要有以下几点：

• 完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。
• 数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的。
• 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗。
• 采用了非阻塞I/O多路复用机制。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作，从而提高效率。

缓存穿透

什么是缓存穿透

        业务系统查询的数据不存在，导致查询缓存和查询数据库返回都是空。如果存在海量请求查询压根就不存在的数据，那么这些海量请求都会落到数据库中，数据库压力剧增，可能会导致系统崩溃。

缓存穿透的解决方案

BloomFilter

        在缓存之前再加一道屏障，里面存储目前数据库中存在的所有key。当业务系统有查询请求的时候，首先去BloomFilter中查询该key是否存在。若不存在，则说明数据库中也不存在该数据，因此缓存都不要查了，直接返回null。若存在，则继续执行后续的流程，先前往缓存中查询，缓存中没有的话再前往数据库中的查询。这种方法适用于数据命中不高，数据相对固定实时性低（通常是数据集较大）的应用场景，代码维护较为复杂，但是缓存空间占用少。

        适用场景：空数据的key各不相同、key重复请求概率低

缓存空数据

      将数据库查询结果为空的key也存储在缓存中，当后续又出现该key的查询请求时，缓存直接返回null，而无需查询数据库。

     适用场景：空数据的key数量有限、key重复请求概率较高

 

互斥锁

       当第一个数据库查询请求发起后，就将缓存中该数据上锁；此时到达缓存的其他查询请求将无法查询该字段，从而被阻塞等待；当第一个请求完成数据库查询，并将数据更新值缓存后，释放锁；此时其他被阻塞的查询请求将可以直接从缓存中查到该数据。

 

数据结构及使用场景

• String：缓存、计数器、分布式锁等。

• List：链表、队列、微博关注人时间轴列表等。

• Hash：用户信息、Hash 表等。
• Set：去重、赞、踩、共同好友等。
• Zset：访问量排行榜、点击量排行榜等。