Redis 功能原理分析

左手的ㄟ右手 2022-10-02 00:37 149阅读 0赞

[2019独角兽企业重金招聘Python工程师标准>>> ][2019_Python_] ![hot3.png][]

过期时间设置

*  EXPIRE key seconds
    
     *  EXPIRE命令的seconds命令必须是整数，所以最小单位是1秒
     *  PEXPIRE命令的单位是毫秒
        
         *  PTTL以毫秒单位获取键的剩余有效时间
 *  一个键还有多久时间被删除，可以使用TTL命令
    
     *  TTL key
        
         *  当键不存在时，TTL命令会返回-2
         *  没设置过期时间，-1

过期删除的原理

*  消极方法（passive way）
    
     *  主键被访问时如果发现它已经失效，那么就删除它
 *  积极方法（active way）
    
     *  周期性地从设置了失效时间的主键中**选择一部分**失效的主键删除
 *  Redis每秒会进行10次操作，具体的流程：
    
     *  随机测试 20 个带有timeout信息的key；
     *  删除其中已经过期的key；
     *  如果超过25%的key被删除，则重复执行步骤1；
     *  这是一个简单的概率算法（trivial probabilistic algorithm），
        
         *  基于假设我们随机抽取的key代表了全部的key空间。

Redis发布订阅

*  Redis提供了一组命令可以让开发者实现“发布/订阅”模式(publish/subscribe)
 *  值得注意的是消息发送出去不会持久化，
    
     *  如果发送之前没有订阅者，
     *  那么后续再有订阅者订阅该频道，之前的消息就收不到了
 *  结构图
    
     *  channel分两类，
        
         *  一个是普通channel、
         *  另一个是pattern channel（规则匹配），
         *  producer1发布了一条消息【publish abc hello】,
            
             *  redis server发给abc这个普通channel上的所有订阅者，
             *  同时abc也匹配上了pattern channel的名字，
             *  所以这条消息也会同时发送给pattern channel \*bc上的所有订阅者
     *  ![bb83687a58d2919e352af05ae5a8f2da5a9.jpg][]

Redis内存回收策略

*  Redis中提供了多种内存回收策略，当内存容量不足时，
    
     *  就不得不淘汰内存中的一些对象，释放这些对象占用的空间
 *  默认的策略为noeviction策略，
    
     *  当内存使用达到阈值的时候，所有引起申请内存的命令**会报错**
 *  allkeys-lru：从数据集（server.db\[i\].dict）中挑选最近最少使用的数据淘汰
    
     *  适合的场景： 如果我们的应用对缓存的访问都是**相对热点数据**，那么可以选择这个策略
 *  allkeys-random：随机移除某个key。
    
     *  适合的场景：如果我们的应用对于缓存key的**访问概率相等**，则可以使用这个策略
 *  volatile-random：从已设置过期时间的数据集（server.db\[i\].expires）中
    
     *  任意选择数据淘汰。
 *  volatile-lru：从已设置过期时间的数据集（server.db\[i\].expires）中挑选
    
     *  最近最少使用的数据淘汰。
 *  volatile-ttl：从已设置过期时间的数据集（server.db\[i\].expires）中挑选
    
     *  将要过期的数据淘汰
 *  适合场景：这种策略使得我们可以向Redis提示哪些key更适合被淘汰，我们可以自己控制

总结

*  实际上Redis实现的LRU并不是可靠的LRU
    
     *  如果需要在所有的数据中搜索最符合条件的数据，那么一定会增加系统的开销，
        
         *  Redis是单线程的，所以耗时的操作会谨慎一些
     *  早期的Redis版本是基于采样的LRU
        
         *  Redis3.0版本之后，Redis作者对于基于采样的LRU进行了一些优化
         *  目的是在一定的成本内让结果更靠近真实的LRU。

Redis是单进程单线程？性能为什么这么快

*  Redis采用了一种非常简单的做法
    
     *  Redis把任务封闭在一个线程中从而避免了线程安全问题；
 *  redis为什么是单线程？
    
     *  官方的解释是，CPU并不是Redis的瓶颈所在，
     *  Redis的瓶颈主要在机器的**内存**和**网络的带宽**。
 *  那么Redis能不能处理高并发请求呢？
    
     *  当然是可以的，至于怎么实现的，我们来具体了解一下。
        
         *  【注意并发不等于并行，
            
             *  并发性I/O流意味着能够让一个计算单元来处理来自多个客户端的流请求。
             *  并行性，意味着服务器能够同时执行几个事情，具有多个计算单元】
 *  多路复用
    
     *  Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，
        
         *  但是由于读写操作等待**用户输入或输出都是阻塞的**，
         *  所以 I/O 操作在一般情况下往往不能直接返回，
         *  这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，
         *  而 **I/O 多路复用**就是为了解决这个问题而出现的。

几种I/O模型

*  同步阻塞IO（Blocking IO）：即传统的IO模型。
 *  同步非阻塞IO（Non-blocking IO）：
    
     *  默认创建的socket都是阻塞的，
     *  非阻塞IO要求socket被设置为NONBLOCK。
 *  IO多路复用（IO Multiplexing）：
    
     *  即经典的Reactor设计模式，也称为异步阻塞IO，
     *  Java中的Selector和Linux中的epoll都是这种模型。
 *  异步IO（Asynchronous IO）：即经典的Proactor设计模式，也称为异步非阻塞IO。
 *  **同步和异步**，指的是用户线程**和内核的交互方式**
 *  **阻塞和非阻塞**，指用户线程**调用内核IO操作**的方式是阻塞还是非阻塞

转载于:https://my.oschina.net/u/3847203/blog/3023049

[2019_Python_]: https://my.oschina.net/u/2663968/blog/3061697
[hot3.png]: /images/20220113/ea81123acc37455b9f1026fd603302b2.png
[bb83687a58d2919e352af05ae5a8f2da5a9.jpg]: /images/20220113/eb0e57afefc247e8b731e85e8978c84c.png