沉迷写代码的程序猿的博客

Redis常用的数据结构为String，List，Hash，Set，Sorted Set。但这只是我们在用的时候键值对的表现形式，他们底层真正使用的数据结构为简单动态字符串，双向链表，压缩列表，哈希表，跳表和整数数组在 Redis 3.0 版本中 List 对象的底层数据结构由「双向链表」或「压缩表列表」实现，但是在 3.2 版本之后，List 数据类型底层数据结构是由 quicklist 实现的；

想要实现MySQL与Redis数据同步，常见的方式有以下三种：这里介绍的是第三种，异步通知。异步通知又可以使用MQ或者Canal来实现。（1）基于MQ的异步通知核心：这样在更新数据的操作中，仍然会有少量代码的侵入（2）基于Canal的通知核心：canal，译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费。GitHub的地址：https://github.com/alibaba/canalCanal是基于MySQL的主从同步来实现的，MySQL主从同步的原理如下：

有了这些信息后，哨兵就会记住这些节点的拓扑信息，在后续发生故障时，选择合适的slave节点进行故障恢复。如图，在7001这个节点执行set a 1时，对a做hash运算，对16384取余，得到的结果是15495，因此要存储到103节点。这是基于redis提供的发布（pub）/订阅（sub）机制完成的，客户端可以从哨兵订阅消息，故障转移后，客户端会收到订阅消息。:hello"频道发送自己的信息（IP 和端口），其他订阅了该频道的哨兵节点就会获取到该哨兵节点信息，从而哨兵节点之间互知。

slave原本是一个master，有属于自己的replid和offset，当第一次变成slave与master建立连接的时候，发送的是原本自己的replid和offset。当master执行bgsave命令的时候，如果这是对master有操作，会将命令记录保留在一个repl_baklog的缓冲区中。接下来，master执行bgsave命令，生成RDB文件，在后台执行，没有占用主线程，接着将生成的RDB文件发送给slave。棕色框中的红色部分，就是尚未同步，但是却已经被覆盖的数据。

Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。Redis是基于内存的缓存机制，如果Redis突然出现宕机，内存的数据就很有可能出现丢失的情况。Redis也会在触发阈值时自动去重写AOF文件。这个命令执行后会开启独立进程完成RDB，主进程可以持续处理用户请求，不受影响。都是对num的操作，第二次会覆盖第一次的值，因此第一个命令记录下来没有意义。RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会。save命令是主线程执行的，所以该命令会使得其他命令被阻塞。

BIgMap是一种实现对位的操作的数据结构，但是其实它本身并不是数据结构，底层其实是字符串，是借助字符串进行位操作的。但是BigMap在Redis中使用却和字符串不太一样，可以理解为这是一个以位为单位的数组，数组的每个单元格存放的是1或者0，数组的下标在BitMaps中被称为偏移量。BigMap在Redis中最大上限是512M，转换为bit则是 2^32个bit位。Redis中的HyperLogLog是一种基于基数估算的算法，所谓基数估算就是在一批数据中不重复的元素个数有多少个。

当我们关注了用户后，这个用户发了动态，那么我们应该把这些数据推送给用户，这个需求，其实我们又把他叫做Feed流，关注推送也叫做Feed流，直译为投喂。为用户持续的提供“沉浸式”的体验，通过无限下拉刷新获取新的信息。传统模式的内容解锁主要是依靠用户通过搜索或者是其他方式解锁想看的内容。对于新型的Feed流的的效果：不需要我们用户再去推送信息，而是系统分析用户到底想要什么，然后直接把内容推送给用户，从而使用户能够更加的节约时间，不用主动去寻找。

Redis不仅可以作为缓存中间件，还可以做为消息队列。消息队列：存储和管理消息，也被称为消息代理（Message Broker）生产者：发送消息到消息队列消费者：从消息队列获取消息并处理消息使用消息队列的好处方便就在于可以解耦。消息队列使用得最普遍的场景莫过于秒杀业务。用户下单之后，利用redis进行校验下单条件，再通过消息队列将消息发送出去，随后启动一个线程去消费这个消息。这一过程中，不仅仅完成了解耦，而且在秒杀过程中，可以”省去“写订单进数据库的事件，提高了响应速度。

在前面【Redis】3.详解分布式锁解决了误删锁和原子性的问题但是不难发现，还存在一个问题，会导致锁不住。当锁的过期时间到了时候，锁就会被释放掉。这时候如果线程1因为阻塞还未向数据库插入订单数据，锁就被释放了，线程2就会获取锁，进行业务逻辑，这就导致锁不住。因此，当过期时间到了之后，业务逻辑还没执行完的时候，我们应该给这把锁续费，就不会出现这种问题了，这个续费问题该怎么解决呢？这就需要用到Redisson了。

分布式锁是指分布式系统或者不同系统之间共同访问共享资源的一种锁实现，其是互斥的，多个线程均可见。分布式锁的核心是大家都用同一个锁，不同服务之间锁是一样的，那么就能锁得住进程，不让进程进入锁住的代码块中。为什么会使用分布式锁呢？使用ReentrantLock或synchronized不行吗？ReentrantLock和synchronized在分布式情况下，每个服务的锁对象都不一样，因为每个服务的锁对象都是不一样的，所以无法锁住不同服务的线程。

缓存穿透就是指用户不断发起请求查询不存在的数据(如id为-1或者id非常非常大)，这样子缓存永远不要生效，这些请求都会被打到数据库中，导致数据库中有很大压力。缓存雪崩是指在某一个时刻，大量key同时失效或者redis宕机，导致请求直接到达数据库，给数据库带来了巨大的压力。缓存击穿也成为热点key问题，是指缓存中没有但数据库中有的数据(一般是因为缓存过期)，这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。

缓存更新策略是Redis的为了节省内存而设计出来的一种东西，主要是因为内存数据宝贵，当我们向redis插入数据过多，或导致内存中缓存的数据太多，所以redis会对部分数据进行更新，或者把它叫为淘汰更合适。常见的缓存更新策略有以下三种内存淘汰超时剔除主动更新内存淘汰超时剔除主动更新说明内存淘汰是Redis内部的一种淘汰机制，当内存不足的时候自动淘汰部分数据。这种机制不需要自己维护，被淘汰的数据在下次查询的时候更新缓存。给缓存数据添加TT了时间，到期后Redis自动删除缓存数据。