m0_61802230的博客

Redis Big Key Hot Key

redis vm 机制

导读想象一下遇到下面的场景你会如何处理：手机号是否重复注册用户是否参与过某秒杀活动伪造请求大量 id 查询不存在的记录，此时缓存未命中,如何避免缓存穿透针对以上问题常规做法是：查询数据库，数据库硬扛，如果压力并不大可以使用此方法，保持简单即可。改进做法：用 list/set/tree 维护一个元素集合，判断元素是否在集合内，时间复杂度或空间复杂度会比较高。如果是微服务的话可以用 redis 中的 list/set 数据结构, 数据规模非常大此方案的内存容量要求可能会非常高。这些场景有个共同

哨兵的作用哨兵是redis集群架构中非常重要的一个组件，主要功能如下：集群监控：负责监控redis master和slave进程是否正常工作消息通知：如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员故障转移：如果master node挂掉了，会自动转移到slave node上配置中心：如果故障转移发生了，通知client客户端新的master地址哨兵的核心知识故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式

导读RDB 和 AOF 对比：持久化方式选择如果对数据安全性要求极高，应该同时使用两种持久化方式。如果可以承受若干时间内的数据丢失，可以只使用 RDB 持久化。不建议只使用 AOF 持久化，因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份，并且 RDB 恢复数据集的速度要比 AOF 恢复的速度要快。RDB 和 AOF 的恢复优先级如果 Redis 同时使用 RDB 和 AOF 持久化，Redis 会优先使用 AOF 进行恢复数据。在启动 Redis 时，如果已经存在了

RDB持久化触发机制手动触发手动触发分别对应save和bgsave命令：save命令：同步，在主线程中保存快照；阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用；bgsave命令：异步，Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。堵塞只发生在fork阶段，一般时间很短；BGSAVE命令是针对SAVE堵塞问题做的优化。因此Redis内部所有的设计RDB的操作都采用BGSAVE的方式，而sav

导读最近在学习Redis，那么首先需要了解的就是Redis的配置文件，弄懂其配置也是接下来学习Redis的基础。配置文件解析################################## INCLUDES(导入) ################################### # 引入其他配置文件include /path/to/local.conf ################################## MODULES(模块) ###############

导读乐观锁介绍：watch指令在redis事物中提供了CAS的行为。为了检测被watch的keys在是否有多个clients同时改变引起冲突，这些keys将会被监控。如果至少有一个被监控的key在执行exec命令前被修改，整个事物将会回滚，不执行任何动作，从而保证原子性操作，并且执行exec会得到null的回复。乐观锁工作机制：watch 命令会监视给定的每一个key，当exec时如果监视的任一个key自从调用watch后发生过变化，则整个事务会回滚，不执行任何动作。注意watch的key是对整个连

导读大家都知道 Redis 中的键会设置过期时间，当到达过期时间时会通过一定策略清除对应 key，但是 redis 内存是由上限的，当达到内存上限时，就要通过一定策略淘汰掉相应 kv 键值对。Redis 内存上限maxmemory 配置选项使用来配置 Redis 的存储数据所能使用的最大内存限制。可以通过在内置文件redis.conf中配置，也可在Redis运行时通过命令CONFIG SET来配置。例如，我们要配置内存上限是100M的Redis缓存，那么我们可以在 redis.conf 配置如下：m

导读今天在看Redis时看到其扩容，缩容机制用的是一致性Hash算法，今天就来谈论下一致性Hash，本文借鉴了小林coding公众号的部分理解与解读。大家如果想要深入了解，关注其公众号。一致性Hash解决的问题大多数网站背后肯定不是只有一台服务器提供服务，因为单机的并发量和数据量都是有限的，所以都会用多台服务器构成集群来对外提供服务。但是问题来了，现在有那么多个节点，要如何分配客户端的请求呢？考虑到每个节点的硬件配置有所区别，我们可以引入权重值，将硬件配置更好的节点的权重值设高，然后根据各个节点的

导读提起缓存，大家应该都不陌生，开始时，如果你的业务处于起步阶段，流量非常小，那无论是读请求还是写请求，直接操作数据库即可，这时你的架构模型是这样的：但随着业务量的增长，你的项目请求量越来越大，这时如果每次都从数据库中读数据，那肯定会有性能问题。这个阶段通常的做法是，引入「缓存」来提高读性能，架构模型就变成了这样：这时候就会处出现一个问题：缓存读写策略，即缓存的读写问题，之前只需要读写数据库即可，现在多了缓存，又该如何读写呢，怎么保证缓存一致性呢？下面主要讲解Redis常用的三种缓存策略。Ca

导语我们都知道，随着并发数量的上升，直接查询数据库是不现实的，因此有了Redis，用其来做缓存，这样可以减轻数据库的压力，不用所有的请求都打在数据库上。那为什么查询Redis要比数据库快呢？今天就和大家讨论一下这个问题，下面我总结几点我可以想到了，如果大家还有补充，可一列在讨论区里，谢谢指正！Redis为什么这么快?内存存储: Redis是使用内存(in-memeroy)存储，没有磁盘IO上的开销。数据存在内存中，类似于HashMap，HashMap 的优势就是查找和操作的时间复杂度都是O(1)。

安装redis之后在命令行窗口中输入 redis-server redis.windows.conf 启动redisredis作为windows服务启动方式：redis-server --service-install redis.windows.conf启动服务：redis-server --service-start停止服务：redis-server --service-stop...