Redis

223 阅读6分钟

原文链接:blog.csdn.net/ThinkWon/ar…

1.Redis为什么这么快

原文链接:https://blog.csdn.net/ThinkWon/article/details/103522351/
1、完全基于内存,绝大部分请求是纯粹的内存操作,非常快速。数据存在内
存中,类似于 HashMap,HashMap 
的优势就是查找和操作的时间复杂度都是O(1);
2、数据结构简单,对数据操作也简单,Redis 
中的数据结构是专门进行设计的;
3、采用单线程,避免了不必要的上下文切换和竞争条件,也不存在多进程或
者多线程导致的切换而消耗 
CPU,不用去考虑各种锁的问题,不存在加锁释放锁操作,没有因为可能出现
死锁而导致的性能消耗;
4、使用多路 I/O 复用模型,非阻塞 IO;
5、使用底层模型不同,它们之间底层实现方式以及与客户端之间通信的应用
协议不一样,Redis 直接自己构建了 VM 机制 
,因为一般的系统调用系统函数的话,会浪费一定的时间去移动和请求;

2.redis过期策略

Redis的过期键的删除策略
我们都知道,Redis是key-value数据库,我们可以设置Redis中缓存的key的过
期时间。Redis的过期策略就是指当Redis中缓存的key过期了,Redis如何处理。
过期策略通常有以下三种:
一、定时过期:每个设置过期时间的key都需要创建一个定时器,到过期时间就会立即清除。该
策略可以立即清除过期的数据,对内存很友好;但是会占用大量的CPU资源去处理过期的数据,
从而影响缓存的响应时间和吞吐量。
二、惰性过期:只有当访问一个key时,才会判断该key是否已过期,过期则清除。该策略可以最
大化地节省CPU资源,却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问,
从而不会被清除,占用大量内存。
三、定期过期:每隔一定的时间,会扫描一定数量的数据库的expires字典中一定数量的key,并
清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次
扫描的限定耗时,可以在不同情况下使得CPU和内存资源达到最优的平衡效果。(expires字典会
保存所有设置了过期时间的key的过期时间数据,其中,key是指向键空间中的某个键的指针,
value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有
键。)

3 Redis 主从架构

单机的 redis,能够承载的QPS大概就在上万到几万不等。对于缓存来说,一
般都是用来支撑读高并发的。因此架构做成主从(master-slave)架构,一主多
从,主负责写,并且将数据复制到其它的slave节点,从节点负责读。所有的
读请求全部走从节点。这样也可以很轻松实现水平扩容,支撑读高并发。

4 哨兵模式

4.1哨兵的介绍

sentinel,中文名是哨兵。哨兵是redis集群机构中非常重要的一个组件,主要有以下功能:
集群监控:负责监控 redis master 和 slave 进程是否正常工作。
消息通知:如果某个redis实例有故障,那么哨兵负责发送消息作为报警通知给管理员。
配置中心:如果故障转移发生了,通知 client 客户端新的 master 地址。
故障转移时,判断一个masternode是否宕机了,需要大部分的哨兵都同意才行
,涉及到了分布式选举的问题。即使部分哨兵节点挂掉了,哨兵集群还是能正
常工作的,因为如果一个作为高可用机制重要组成部分的故障转移系统本身是
单点的,那就很坑爹了。
故障转移:如果 master node 挂掉了,会自动转移到 slave node 上。
哨兵用于实现 redis集群的高可用,本身也是分布式的,作为一个哨兵集群去
运行,互相协同工作。
哨兵的核心知识
哨兵至少需要 3 个实例,来保证自己的健壮性。
哨兵 + redis 主从的部署架构,是不保证数据零丢失的,只能保证 redis 集群的高可用性。
对于哨兵 + redis主从这种复杂的部署架构,尽量在测试环境和生产环境,都
进行充足的测试和演练

5 redis 系统介绍

   转至:
   https://blog.csdn.net/qmqm33/category_9889328.html
   sorted_set直播项目哪个房间人多
RDB存储的弊端
    存储数据量较大,效率较低——基于快照思想,每次读写都是全部数据,当数据量巨
    大时,效率非常低大数据量下的IO性能较低基于fork创建子进程,内存产生额外消
    耗宕机带来的数据丢失风险
AOF写数据三种策略
    always(每次)
    每次写入操作均同步到AOF文件中,数据零误差,性能较低
    everysec(每秒)
    每秒将缓冲区中的指令同步到AOF文件中,数据准确性高,性能较高
    再系统突然当即的情况下丢失1秒内的数据
    no(系统控制)
    由操作系统每次同步到AOF文件的周期,整体过程不可控
AOF重写
    随着命令的不断写入AOF,文件会越来越大,为了解决这个问题,Redis引入AOF重写机制压缩文件体积,AOF文件重写是将Redis进程内的数据转换为写命令同步到新AOF文件的过程,简单说就是将同样一个数据的若干个命令执行结果转换为最终结果数据对应的指令进行记录

mutil  exec discard 

一颗老鼠屎坏了一锅粥 来描述 数据有没有有变化

超卖是解决会不会同时来修改(秒杀到最后才担心会不会同时修改)像同步锁

常见的是秒杀场景,订单服务部署了多个实例。如秒杀商品有4个,第一个用
户购买3个,第二个用户购买2个,理想状态下第一个用户能购买成功,第二个
用户提示购买失败,反之亦可。而实际可能出现的情况是,两个用户都得到库
存为4,第一个用户买到了3个,更新库存之前,第二个用户下了2个商品的订
单,更新库存为2,导致出错。

缓存情况:

https://blog.csdn.net/qmqm33/article/details/105938725