qq_60271706的博客

Redis之所以性能强，最主要的原因就是基于内存存储。然而单节点的Redis其内存大小不宜过大，会影响持久化或主从同步性能。当内存使用达到上限时，就无法存储更多数据了。

因此客户端发送命令的格式、服务端响应结果的格式必须有一个规范，这个规范就是通信协议。而在Redis中采用的是RESP（Redis Serialization Protocol）协议：1. Redis 1.2版本引入了RESP协议。2. Redis 2.0版本中成为与Redis服务端通信的标准，称为RESP2。3. Redis 6.0版本中，从RESP2升级到了RESP3协议，增加了更多数据类型并且支持6.0的新特性--客户端缓存。

select模式存在的三个问题：1. 能监听的FD最大不超过10242. 每次select都需要把所有要监听的FD都拷贝到内核空间3. 每次都要遍历所有FD来判断就绪状态poll模式的问题：-- poll利用链表解决了select中监听FD上限的问题，但依然要遍历所有FD，如果监听较多，性能会下降。epoll模式中如何解决这些问题的？1. 基于epoll实例中的红黑树保存要监听的FD，理论上无上限，而且增删改查效率都非常高。

String是Redis中最常见的数据存储类型：-- 其基本编码方式是RAW，基于简单动态字符串（SDS）实现，存储上限为512mb。-- 如果存储的SDS长度小于44字节，则会采用EMBSTR编码，此时object head与SDS是一段连续空间。申请内存时只需要调用一次内存分配函数，效率更高。-- 如果存储的字符串是整数值，并且大小在LONG_MAX范围内，则会采用INT编码：直接将数据保存在RedisObject的ptr指针位置（刚好8字节），不再需要SDS了。

问题1：ZipList虽然节省内存，但申请内存必须是连续空间，如果内存占用较多，申请内存效率很低。怎么办？为了缓解这个问题，我们必须限制ZipList的长度和entry大小。问题2：但是我们要存储大量数据，超出了ZipList最佳的上限该怎么办？我们可以创建多个ZipList来分片存储数据。问题3：数据拆分后比较分散，不方便管理和查找，这多个ZipList如何建立联系？Redis在3.2版本引入了新的数据结构QuickList，它是一个双端链表，只不过链表中的每个节点都是一个ZipList。

Dict的结构：-- 类似java的HashTable，底层是数组加链表来解决哈希冲突-- Dict包含两个哈希表，ht[0]平常用，ht[1]用来rehashDict的伸缩：1、当LoadFactor大于5或者LoadFactor大于1并且没有子进程任务时，Dict扩容2、当LoadFactor小于0.1时，Dict收缩3、扩容大小为第一个大于等于used + 1的2^n4、收缩大小为第一个大于等于used 的2^n。

我们都知道Redis中保存的Key是字符串，value往往是字符串或者字符串的集合。可见字符串是Redis中最常用的一种数据结构。不过Redis没有直接使用C语言中的字符串，因为C语言字符串存在很多问题：1、获取字符串长度的需要通过运算2、非二进制安全3、不可修改Redis构建了一种新的字符串结构，称为简单动态字符串（Simple Dynamic String），简称SDS。那么Redis将在底层创建两个SDS，其中一个是包含“name”的SDS，另一个是包含“jack”的SDS。

Redis的持久化虽然可以保证数据安全，但也会带来很多额外的开销。

一次命令的响应时间 = 1次往返的网络传输耗时 + 1次Redis执行命令耗时。

BigKey通常以Key的大小和Key中成员的数量来综合判定，例如：-- Key本身的数据量过大：一个String类型的Key，它的值为5 MB。-- Key中的成员数过多：一个ZSET类型的Key，它的成员数量为10,000个。-- Key中成员的数据量过大：一个Hash类型的Key，它的成员数量虽然只有1,000个但这些成员的Value（值）总大小为100 MB。推荐值： 单个key的value小于10KB；

STREAM类型消息队列的XREADGROUP命令特点：-- 消息可回溯-- 可以多消费者争抢消息，加快消费速度-- 可以阻塞读取-- 没有消息漏读的风险-- 有消息确认机制，保证消息至少被消费一次。

不可重入Redis分布式锁：- 原理：利用setnx的互斥性；利用ex避免死锁；释放锁时判断线程标示- 缺陷：不可重入、无法重试、锁超时失效可重入的Redis分布式锁：- 原理：利用hash结构，记录线程标示和重入次数；利用watchDog延续锁时间；利用信号量控制锁重试等待- 缺陷：redis宕机引起锁失效问题Redisson的multiLock：- 原理：多个独立的Redis节点，必须在所有节点都获取重入锁，才算获取锁成功- 缺陷：运维成本高、实现复杂。

基于Redis的分布式锁实现思路：- 利用set nx ex获取锁，并设置过期时间，保存线程标示- 释放锁时先判断线程标示是否与自己一致，一致则删除锁特性：- 利用set nx满足互斥性- 利用set ex保证故障时锁依然能释放，避免死锁，提高安全性- 利用Redis集群保证高可用和高并发特性。

缓存更新策略的最佳实践方案：低一致性需求：使用Redis自带的内存淘汰机制高一致性需求：主动更新，并以超时剔除作为兜底方案读操作：缓存命中则直接返回缓存未命中则查询数据库，并写入缓存，设定超时时间写操作：先写数据库，然后再删除缓存要确保数据库与缓存操作的原子性。

Redis事务（Transaction）通过将多个Redis操作封装为一个原子性的操作序列，确保在事务执行过程中，不会受到其他客户端的干扰。从而在保证数据一致性的同时，协调并发，提高数据操作的效率和性能。Redis 事务实际开发中使用的非常少，功能比较鸡肋，不要将其和我们平时理解的关系型数据库的事务混淆了。除了不满足原子性和持久性之外，事务中的每条命令都会与 Redis 服务器进行网络交互，这是比较浪费资源的行为。

Canal [kə'næl]，译意为水道/管道/沟渠。canal是阿里巴巴旗下的一款开源项目，基于Java开发。基于数据库增量日志解析，提供增量数据订阅&消费。GitHub的地址：https://github.com/alibaba/canalCanal是基于mysql的主从同步来实现的。MySQL主从同步的原理1. MySQL master 将数据变更写入二进制日志( binary log），其中记录的数据叫做binary log events。

大多数情况下，浏览器查询到的都是缓存数据，如果缓存数据与数据库数据存在较大差异，可能会产生比较严重的后果。所以我们必须保证数据库数据、缓存数据的一致性，这就是缓存与数据库的同步。

冷启动：服务刚刚启动时，Redis中并没有缓存，如果所有商品数据都在第一次查询时添加缓存，可能会给数据库带来较大压力。缓存预热：在实际开发中，我们可以利用大数据统计用户访问的热点数据，在项目启动时将这些热点数据提前查询并保存到Redis中。我们数据量较少，可以在启动时将所有数据都放入缓存中。

请求地址是localhost，端口是80，就被windows上安装的Nginx服务给接收到了。OpenResty的很多功能都依赖于其目录下的Lua库，需要在nginx.conf中指定依赖库的目录，并导入依赖。windows上的nginx用来做反向代理服务，将前端的查询商品的请求代理到OpenResty集群。我们需要在OpenResty中编写业务，查询商品数据并返回到浏览器。但是这次，我们先在OpenResty接收请求，返回假的商品数据。在lua文件夹下，新建文件：item.lua。

OpenResty® 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。OpenResty® 通过汇聚各种设计精良的 Nginx 模块（主要由 OpenResty 团队自主开发），从而将 Nginx 有效地变成一个强大的通用 Web 应用平台。

function 函数名( argument1, argument2..., argumentn)-- 函数体return 返回值end例如：定义一个函数（打印数组）endend。

利用Caffeine实现下列需求：1、给根据id查询商品的业务添加缓存，缓存未命中时查询数据库2、给根据id查询商品库存的业务添加缓存，缓存未命中时查询数据库3、缓存初始大小为1004、缓存上限为10000。

Caffeine是一个基于Java8开发的，提供了近乎最佳命中率的高性能的本地缓存库。Caffeine相当于一个缓存工厂，可以创建出多个缓存实例 Cache。这些缓存实例都继承了 Caffeine 的参数配置，Caffeine 是如何配置的，这些缓存实例就具有什么样的特性和功能。Caffeine 是目前性能最好的本地缓存，目前Spring内部的缓存使用的就是Caffeine。GitHub地址：https://github.com/ben-manes/caffeine。

传统的缓存策略一般是请求到达Tomcat后，先查询Redis，如果未命中则查询数据库，存在下面的问题：1、请求要经过Tomcat处理，Tomcat的性能成为整个系统的瓶颈。2、Redis缓存失效时，会对数据库产生冲击。

Redis会把每一个master节点映射到0~16383共16384个插槽（hash slot）上。

Redis 分片集群是一种将 Redis 数据库分散到多个节点上的方式，以提供更高的性能和可伸缩性。在分片集群中，数据被分为多个片段，每个片段存储在不同的节点上，这些节点可以是物理服务器或虚拟服务器。Redis 分片集群的主要目的是将数据分布在多个节点上，以便可以通过并行处理来提高读写吞吐量。每个节点负责处理一部分数据，并且在需要时可以进行扩展以适应更多的负载。此外，分片集群还提供了故障容错和高可用性的功能，即使其中一个节点发生故障，其他节点仍然可以继续工作。

搭建三个节点形成sentinel集群，来监控redis集群。

当哨兵服务监测到master下线或宕机，哨兵会自动选举一个slave作为新的master，然后通过发布订阅模式通知其他所有的从节点，修改配置文件，让它们切换主机。哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

主从第一次同步是全量同步。master如何判断slave是不是第一次来同步数据？Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid。offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

1. 数据丢失问题Redis是内存存储，服务重启可能会丢失数据。2.并发能力问题单节点Redis并发能力虽然不错，但也无法满足如双11这样的高并发场景。3.故障恢复问题如果Redis宕机，则服务不可用，需要一种自动的故障恢复手段。4.存储能力问题Redis基于内存，单节点能存储的数据量难以满足海量数据需求。

hash类型，也叫散列，其value是一个无序字典。string结构是将对象序列化为json字符串后存储，当需要修改对象某个字段时很不方便。hash结构可以将对象中的每个字段独立存储，可以针对单个字段做crud。

也就是字符串类型，是redis中最简单的存储类型。string：普通字符串。int：整数类型，可以做自增、自减操作。float：浮点类型，可以做自增、自减操作。不管是那种格式，底层都是字节数组成形式存储，只不过是编码方式不同。字符串类型的最大空间都不能超过512m。

redis默认有16个数据库，默认使用的是第0个。

redis是单线程的。redis是基于内存操作，cpu不是redis性能瓶颈，redis的瓶颈是根据机器的内存和网络带宽。

Redis Desktop Manager (RDM) 是一个开源的图形化 Redis 数据库管理工具，是Redis可视化工具，支持 Windows、macOS 和 Linux 平台。Redis桌面管理器（又名RDM） - 是一个用于Windows，Linux和MacOS的快速开源Redis数据库管理应用程序。它提供了一系列的功能，如连接管理、数据浏览、编辑和调试等，帮助用户管理和操作 Redis 数据库。适用于多种操作系统，使用 RDM 分析您的 Redis服务器内存使用情况，并批量删除过时数据。

Redis 是完全开源的，遵守 BSD 协议，是一个高性能的 key-value 数据库。Redis是一种键值型的NoSql数据库，这里有两个关键字：- 键值型- NoSql其中**键值型**，是指Redis中存储的数据都是以key、value对的形式存储，而value的形式多种多样，可以是字符串、数值、甚至json。Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。