55555的博客

记录一次线上redis占用过大的排查过程，供后续参考。

最近线上的一个状态修改功能出现了问题，一开始是运营找了过来，运营告知某条数据的状态已经开启了的，但是实际使用起来还是没有生效，于是拿到这个问题后，首先就去数据库查了这条数据，发现确实如他所说，状态数据是已经更改过的。但是为什么没有生效呢？于是再次查看了获取数据的方法，发现是优先获取的缓存，于是查询缓存里的数据，发现了问题所在，缓存里并没有将这条数据的状态更改过来，也就是缓存数据不一致问题。继续追查状态修改的方法，发现采用的更新方式是先更新数据库，然后删除缓存。

如上，我们关于redis客户端jedis的操作演示就结束了，更多关于jedis接口的使用需要我们自己去摸索，将其封装为工具类，下一期，我们继续讲解其他redis客户端。

前几期我们讲解了如何安装redis，redis的主从、哨兵模式，但还是没有触及到redis的真正核心竞争力——集群模式。前一阵出品的Dragonfly经评测性能秒杀redis，但实际上仅仅只是单核服务器下的性能对比，而在redis主推的多核集群模式下，Dragonfly仍然被甩一大截。所以我们今天来看看如何搭建redis集群。

至此，我们哨兵模式的搭建就完成了，希望大家可以借此更加深入理解redis原理，下一期，我们继续讲解redis的集群模式，实现真正的redis高可用。

至此，我们的主从架构就搭建完成了，实际上我们只需要一个replicaof 主节点IP 端口就能实现主从同步，非常简单。需要注意的是，实际操作过程中注意开启对应的redis端口或者关闭防火墙（生产环境不建议关闭）下期继续带大家实操redis哨兵模式。

canal是阿里开源的数据同步工具，基于bin log可以将数据库同步到其他各类数据库中，目标数据库支持mysql,postgresql,oracle,redis,MQ,ES等canal分成服务端deployer和客户端adapter，我们可以部署多个，同时为了方便管理还提供了一个管理端admincanal的数据同步流程如下图所示因为目前canal还不能直接通过配置就实现对redis的数据同步，因此我们需要自定义一下canal客户端，通过服务端将数据同步到客户端后，由客户端自定义操作同步到redis。

什么是IO多路复用器首先这里的IO指的是网络IO，也就是网络连接，如果把一个IO想象成一条路，这些路是连接到内核的，就程序自身而言它是不知道这些路上有没有数据到达的。为了知道这一点，程序就得遍历每一条路，并且这个遍历还要基于用户态内核态的切换才能实现，因此便利的成本是比较高的。如果有一种方法，能够实现一次遍历进程就能知道它关注的路有没有数据到达，那就能很大程度上节约资源提高性能了，多路复用器就是用来实现这个的。也就是多路复用器可以让单个进程监控多个连接，一旦某一个连接有数据来了，就能够通知程序进

对于双写一致性问题，主要矛盾就在于：（1）更新完数据库是更新缓存还是删除缓存（2）就删除缓存而言，是先删缓存还是先更新数据库解决方案：缓存设置过期时间【方案1】：缓存设置过期时间是保持最终一致性的方案，但并不能保证强一致性。缓存过期后，再次获取缓存时会走数据库，获取到后再更新缓存接下来讨论下述三种情况（1）先更新数据库，再更新缓存这种做法实际上是不可取的，因为不能保证线程安全。比如现在线程A更新了数据库，还没更新缓存时，线程B更新了同一数据，并且更新了缓存，之后线程A又把缓存更新为A的了，从

如果了解删除策略和淘汰策略可直接跳过看最后的答案redis提供了两种删除策略用来清空过期的key：（1）主动删除/定期删除：每隔一段时间就扫描一定数据的设置了过期时间的key，并清除其中已过期的keys，大家也注意到了，这里说的是一定数量而不是全部，具体是多少呢？这也是redis亮点之一：基于贪心算法的清除a、判断随机抽取的N个key是否过期b、删除所有已经过期的keyc、如果有多于25%的key过期，重复上述两步为什么不一下子全部删完呢？操作是要消耗性能的，数据量少的情况不会有什么影响，一旦数

redis为什么使用单线程redis本身是基于内存的，所以redis的性能瓶颈更多的是在于内存和网络带宽，而不是CPU。而单线程的实现更加简单和经济采用单线程，可以使指令串行，不用额外维护锁机制，避免了不必要的上下文切换和竞争条件，减少了CPU的消耗redis单线程是如何承担大量并发请求的？首先redis可以承担Redis读的速度是110000次/s,写的速度是81000次/s ，也就是说redis的qps大概在10W量级上，这个量是很大的，那么redis是如何做到能够这么快的呢？1、基于内存r

首先要理解这3个问题的概念，比较容易记混的是穿透和击穿，个人认为这是个名字而已，更重要的是概率。当然分享一下个人记忆的一个小技巧：透，透明，表示本来就没有的东西，所以缓存穿透指数据库本来就没有这些key，但是又有大量请求打来导致直接访问到数据库上了。缓存穿透：本来就没有的key因为数据库中本来就没有这些key,但又有大量的这些key请求访问过来，导致穿过了redis打到数据库上了解决： 布隆过滤器（过滤器还有其他几种，之间的差异可以自行了解）缓存击穿：少量key被大量请求某些key过期或者被清除掉

引言最近研究redis的相关底层知识，查阅了一些资料、博客，发现对于redis工作原理的说明不够用全面，同时针对“redis为什么这么快”的解答发现了一些问题。故基于这些文章结合自己的理解做了如下整理redis工作原理要聊redis的工作原理，那就要从工作流程出发，逐步分析：1、首先redis采用了epoll I/O多路复用器：经过网络数据传输，大量的连接请求通过epoll接收并且监控，有数据的连接才放到redis中进行读写处理，所以首先就要聊聊epoll2、请求数据进入到redis中后，redi