qq_39093474的博客

Prometheus（普罗米修斯）是一套开源的监控&报警&时间序列数据库的组合，起始是由SoundCloud公司开发的。随着发展，越来越多公司和组织接受采用Prometheus，社会也十分活跃，他们便将它独立成开源项目，并且有公司来运作。Google SRE的书内也曾提到跟他们BorgMon监控系统相似的实现是Prometheus。现在最常见的Kubernetes容器管理系统中，通常会搭配Prometheus进行监控。

Stream弥补了Redis作为MQ（message queue）技术选型上的不足之处；Redis 5.0发布的Stream相比Pub/Sub模块，Stream支持消息持久化，结合sentinel或cluster使其成为了一个比较可靠的消息队列。尽管我认为它很难成为公司MQ的技术选型产品，但是关于Stream的使用和特性（消费组），仍值得一探究竟。消息顺序存储消息ID序列化规则生成消息的遍历消息阻塞/非阻塞获取客户端分组消费消息消息确认机制消息异常机制消息队列监控。

Bitmaps 称为位图，它不是一种数据类型。网上很多视频教程把Bitmaps称为数据类型，应该是不正确的。Bitmaps 是Redis提供给使用者用于操作位的“数据类型”。Bitmaps 不是数据类型，底层就是字符串（key-value），byte数组。我们可以使用普通的get/set直接获取和设值位图的内容，也可以通过Redis提供的位图操作getbit/setbit等将byte数组看成“位数组”来处理Bitmaps 的“位数组”每个单元格只能存储0和1，数组的下标在Bitmaps中称为偏移量。

程序员设计了一个在每分钟内只允许访问1000次的限流方案，如下图01:00s-02:00s之间只允许访问1000次，这种设计最大的问题在于，请求可能在01:59s-02:00s之间被请求1000次，02:00s-02:01s之间被请求了1000次，这种情况下01:59s-02:01s间隔0.02s之间被请求2000次，很显然这种设计是错误的。从测试输出的数据可以看出，起到了限流的效果，从第11次以后的请求操作都是失败的，但是这个和我们允许的5次误差还是比较大的。指定时间T内，只允许发生N次。

主从复制奠定了Redis分布式的基础，但是普通的主从复制并不能达到高可用的状态。在普通的主从复制模式下，如果主服务器宕机，就只能通过运维人员手动切换主服务器，很显然这种方案并不可取。针对上述情况，Redis官方推出了可抵抗节点故障的高可用方案——Redis Sentinel（哨兵）。Redis Sentinel（哨兵）：由一个或多个Sentinel实例组成的Sentinel系统，它可以监视任意多个主从服务器，当监视的主服务器宕机时，自动下线主服务器，并且择优选取从服务器升级为新的主服务器。

在1000个节点的时候仍能表现得很好并且可扩展性是线性的。没有合并操作（多个节点不存在相同的键），这样在 Redis 的数据模型中最典型的大数据值中也能有很好的表现。写入安全，那些与大多数节点相连的客户端所做的写入操作，系统尝试全部都保存下来。但是Redis无法保证数据完全不丢失，异步同步的主从复制无论如何都会存在数据丢失的情况。可用性，主节点不可用，从节点能替换主节点工作。关于Redis集群的学习，如果没有任何经验的弟兄们建议先看下这三篇文章（中文系列）： Redis集群教程。

主从复制是Redis分布式的基石，也是Redis高可用的保障。在Redis中，被复制的服务器称为主服务器（Master），对主服务器进行复制的服务器称为从服务器（Slave）。配置文件——redis.conf文件中，配置slaveof ip port命令——进入Redis客户端执行slaveof ip port启动参数—— ./redis-server --slaveof ip port。

LRU有一个明显的缺点，它无法正确的表示一个Key的热度，如果一个key从未被访问过，仅仅发生内存淘汰的前一会儿被用户访问了一下，在LRU算法中这会被认为是一个热key。例如如下图，keyA与keyB同时被set到Redis中，在内存淘汰发生之前，keyA被频繁的访问，而keyB只被访问了一次，但是这次访问的时间比keyA的任意一次访问时间都更接近内存淘汰触发的时间，如果keyA与keyB均被Redis选中进行淘汰，keyA将被优先淘汰。

Redis提供了info指令，它会返回关于Redis服务器的各种信息和统计数值。在使用Redis时，时常会遇到一些疑难杂症需要我们去排查，这个时候我们可以通过info指令来获取Redis的运行状态，然后进行问题的排查。server: Redis服务器的一般信息clients: 客户端的连接部分memory: 内存消耗相关信息persistence: RDB和AOF相关信息stats: 一般统计replication: 主/从复制信息cpu: 统计CPU的消耗。

跳表全称叫做跳跃表，简称跳表。跳表是一个随机化的数据结构，实质就是一种可以进行二分查找的有序链表。跳表在原有的有序链表上面增加了多级索引，通过索引来实现快速查找。跳表不仅能提高搜索性能，同时也可以提高插入和删除操作的性能。Skip List(跳跃列表)这种随机的数据结构，可以看做是一个二叉树的变种，它在性能上与红黑树、AVL树很相近；但是Skip List(跳跃列表)的实现相比前两者要简单很多，目前Redis的zset实现采用了Skip List(跳跃列表)（其它还有LevelDB等也使用了跳跃列表）。

Lua是一种用C语言编写而成的轻量级的脚本语言。

Redis是我们Java开发中，使用频次非常高的一个nosql数据库，数据以key-value键值对的形式存储在内存中。redis的常用使用场景，可以做缓存，分布式锁，自增序列等，使用redis的方式和我们使用数据库的方式差不多，首先我们要在自己的本机电脑或者服务器上安装一个redis的服务器，通过我们的java客户端在程序中进行集成，然后通过客户端完成对redis的增删改查操作。

Redis是一种基于客户端-服务端模型以及请求/响应的TCP服务。客户端发起一个（查询/插入）请求，并监听socket返回，通常情况都是阻塞模式等待Redis服务器的响应服务端处理命令，并且返回处理结果给客户端客户端接收到服务的返回结果，程序从阻塞代码处返回Redis客户端和服务端之间通过网络连接进行数据传输，这个连接可以很快（loopback接口）或很慢（建立了一个多次跳转的网络连接）。

如果你是面试或者为了了解知识来学习这一知识点，我觉得是有必要的；但是如果你是作为公司的技术负责人或者项目技术选型来使用Redis的Pub/Sub做消息的发布订阅，如果你不是走投无路了，那么你可能值得斟酌一下。Redis的Pub/Sub发布订阅，是Redis一步步完善消息队列功能的一个进步点，虽然现在没人用Pub/Sub做消息队列，但是它的思想和功能也是值得玩一下的，这个就是我写这篇文章的主要原因。

是什么：Redis事务可以一次执行多个命令，本质是一组命令的组合，一个事务中的所有命令都会序列化，按顺序地串行化执行，执行中不会被其他命令插入，不许加塞。能干嘛：一个队列中，一次性，顺序性，排他性的执行一系列命令。Redis类似大多数成熟的数据库系统一样，提供了事务机制。Redis的事务机制非常简单，它没有严格的事务模型，无法像关系型数据库一样保证操作的原子性。Redis事务最大的作用是保证多个指令的串行执行。

假设产品经理让你设计一个模块，来统计PV（Page View页面的访问量），那么你会怎么做？我想很多人对于PV（Page View页面的访问量）的统计会很快的想到使用Redis的incr、incrby指令，给每个网页配置一个独立Redis计数器就可以了，把这个技术区的key后缀加上当它的日期，这样一个请求过来，就可以通过执行incr、incrby指令统计所有PV。此时当你完成这个需求后，产品经理又让你设计一个模块，统计UV（Unique Visitor，独立访客），那么你又会怎么做呢？

Redis有序集合跟集合一样也是String类型元素的集合，且不允许重复的成员不同的是每个元素都会关联一个double类型的分数，Redis正是通过这个分数来为集合中的元素进行从小到大的排序有序集合的成员是唯一的，但是分数（score）是可以重复的集合是通过哈希表实现的，集合中最大的成员数为2的32次方-1，可以存储40多亿个成员，Zset集合是有序不可重复的。

Hash类型是String类型的filed和value的映射表，或者说是一个String集合，hash特别适合存储对象，相对比较而言，将一个对象类型存储在hash类型要比存储在String类型里占用更少的内存空间，并对整个对象的存取，可以看成具有key和value的map容器，该类型非常适合于存储值对象的信息，如uname，upass，age等，该类型的数据仅占用很少的磁盘空间（相比于JSON）。Redis中每个hash可以存储2的32次方-1的键值对（40多亿）

Redis的set是String类型的无序集合，集合成员是唯一的，这就意味着集合中不能出现重复的数据，Redis中的集合是通过哈希表实现的，set是通过hashTable实现的。集合中的最大成员数为2的32次方-1（每个集合可以存储40多亿个元素），类似于java中的hashTable集合。

List类型是一个链表结构的集合，其主要功能有push，pop，获取元素等，更详细的说，List类型是一个双端链表的结构，我们可以通过相关的操作进行集合的头部或者尾部添加或删除元素，List的设计非常灵巧，既可以作为栈，也可以作为队列，满足大多数要求。按照插入顺序排序，你可以添加一个元素到列表的头部（左边）或者尾部（右边）一个列表最多可以包含2的32次方-1（每个列表超过40亿个元素），类似于JAVA的LinkedList。

String类型是Redis最基本的数据类型，一个键最大能存储512MBString数据结构是简单的key-value类型，value不仅是String类型，也可以是数字，是包含很多种类型的特殊类型。String类型是二进制安全的，意思是Redis的String可以包含任何数据，比如序列号的对象存储，比如一张图片存储，比如一个简单的字符串，数值等待。

是官方自带的Redis性能测试工具，用来测试Redis在当前环境下的读写性能。在使用Redis的时候，服务器的硬件配置、网络状况、测试环境都会对Redis的性能有所影响，我们需要对Redis实时测试以确定Redis的实际性能。语法格式：redis-benchmark [参数] [参数值]参数列表：参数描述默认值-h指定服务器主机名127.0.0.1-p指定服务器端口6379-s指定服务器 socket-c指定并发连接数50-n指定请求数10000-d。

这篇文章聊一聊关于「分布式锁」的问题。Redis 分布式锁的话题，很多文章已经写烂了，那为什么还要写这篇文章呢？因为我发现网上 99% 的文章，并没有把这个问题真正讲清楚。导致很多读者看了很多文章，依旧云里雾里。例如下面这些问题，你能清晰地回答上来吗？基于 Redis 如何实现一个分布式锁？Redis 分布式锁真的安全吗？Redis 的 Redlock 有什么问题？一定安全吗？业界争论 Redlock，到底在争论什么？哪种观点是对的？分布式锁到底用 Redis 还是 Zookeeper。

即使采用了后续讲解的高可用机制，slave node 可以自动接管 master node，但也可能 sentinel 还没检测到 master failure，master node 就自动重启了，还是可能导致上面所有的 slave node 数据被清空。，不建议用 slave node 作为 master node 的数据热备，因为那样的话，如果你关掉 master 的持久化，可能在 master 宕机重启的时候数据是空的，然后可能一经过复制， slave node 的数据也丢了。

【代码】RedisTemplate redis缓存的基本使用。

在 实践应用：Spring Boot轻松搞定重复提交（本地锁） 一文中介绍了单机版的重复提交解决方案，在如今这个分布式与集群横行的世道中，那怎么够用呢，所以本章重点来了…单机版中我们用的是，但是这玩意存在集群的时候就凉了，所以我们还是要借助类似、 之类的中间件实现分布式锁。利用 自定义注解、、 实现分布式锁，你想锁表单锁表单，想锁接口锁接口….在 中添加上 、、 的依赖即可属性配置在 资源文件中添加 redis 相关的配置项CacheLock 注解创建一个 注解，本章内容都是实战使用过的，所以

如果Redis中数据非常多，将服务器中的内存都耗尽，这样就会出现内存溢出的情况，Redis开发组考虑到了这种问题，使用数据淘汰策略可以解决这个问题。可以设置内存最大使用量，当内存使用量超出时，会施行数据淘汰策略。作为内存数据库，出于对性能和内存消耗的考虑，Redis 的淘汰算法实际实现上并非针对所有 key，而是抽样一小部分并且从中选出被淘汰的 key。Redis 4.0 引入了和淘汰策略，LFU 策略通过统计访问频率，将访问频率最少的键值对淘汰。您需要根据系统的特征，来选择合适的淘汰策略。

Redis中有个设置时间过期的功能，即对存储在 redis 数据库中的值可以设置一个过期时间。作为一个缓存数据库，这是非常实用的。如我们一般项目中的 token 或者一些登录信息，尤其是短信验证码都是有时间限制的，按照传统的数据库处理方式，一般都是自己判断过期，这样无疑会严重影响项目性能。我们set key的时候，都可以给一个，就是过期时间，通过过期时间我们可以指定这个 key 可以存活的时间。：对于散列表这种容器，只能为整个键设置过期时间（整个散列表），而不能为键里面的单个元素设置过期时间。

Redis 是内存型数据库，为了之后（比如重启机器、机器故障之后回复数据），或者是为了防止系统故障而将数据备份到一个远程位置，需要将内存中的数据持久化到硬盘上。Redis 提供了RDB和AOF两种持久化方式。默认是只开启RDB，当Redis重启时，它会优先使用AOF文件来还原数据集。

Redis功能强大，数据类型丰富，再快的系统，也经不住疯狂的滥用。通过禁用部分高风险功能，并挂上开发的枷锁，业务更能够以简洁、通用的思想去考虑问题，而不是绑定在某种实现上。Redis 根据不同的用途，会有不同的持久化策略和逐出策略，所以，在使用和申请 Redis 集群前，请明确是用来做缓存还是存储。redis 的集群有主从和 cluster 两种模式，各有优缺点。以下规范不区分集群模式，我们分别从使用场景和操作限制两方面说明。

为了在节点数目发生改变时尽可能少的迁移数据将所有的存储节点排列在收尾相接的Hash环上，每个key在计算Hash后会顺时针找到临近的存储节点存放。而当有节点加入或退出时仅影响该节点在Hash环上顺时针相邻的后续节点。优点加入和删除节点只影响哈希环中顺时针方向的相邻的节点，对其他节点无影响。缺点数据的分布和节点的位置有关，因为这些节点不是均匀的分布在哈希环上的，所以数据在进行存储时达不到均匀分布的效果。

作为一名后端工程师，工作中你肯定和 Redis 打过交道。Redis 为什么快，这点想必你也知道，至少为了面试也做过准备。很多人知道 Redis 快仅仅因为它是基于内存实现的，对于其它原因倒是模棱两可。数据都存储在内存里，减少了一些不必要的 I/O 操作，操作速率很快。

我们先来看下 Redis 官网对分布式锁的说法：而 Java 版的 分布式锁的框架就是 Redisson。推荐大家去看一下人家github的文档，Redisson 官方Github文档在实战之前，我们先来看下使用 Redisson 的原理。下面的代码是单节点 Redis 的配置。// 配置 Config config = new Config();

布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数，布隆过滤器可以用来检索一个元素是否在一个集合中，它的优点是空间效率和查询时间都比一般算法要好得多，缺点是有一定的误识别率和删除困难。上面这句介绍比较全面的描述了什么是布隆过滤器，如果还是不太好理解的话，就可以把布隆过滤器理解为一个set集合，我们可以通过add往里面添加元素，通过contains来判断是否包含某个元素。

现如今 Redis 变得越来越流行，几乎在很多项目中都要被用到，不知道你在使用 Redis 时，有没有思考过，Redis 到底是如何稳定、高性能地提供服务的？我使用 Redis 的场景很简单，只使用单机版 Redis 会有什么问题吗？我的 Redis 故障宕机了，数据丢失了怎么办？如何能保证我的业务应用不受影响？为什么需要主从集群？它有什么优势？什么是分片集群？我真的需要分片集群吗？如果你对 Redis 已经有些了解，肯定也听说过数据持久化主从复制哨兵。

缓存击穿，就是说某个 key 非常热点，访问非常频繁，处于集中式高并发访问的情况，当这个 key 在失效的瞬间，大量的请求就击穿了缓存，直接请求数据库，就像是在一道屏障上凿开了一个洞。这几个概念在后端开发过程中非常常见，如果对这几个概念不了解，听着会感觉太高大上，至少笔者刚开始是这么觉得，本文就用一分钟时间来做一个大致的科普好了，更主要的是认识和认知吧。大约在 几 年前，国内比较知名的一个互联网公司，曾因为缓存事故，导致雪崩，后台系统全部崩溃，事故从当天下午持续到晚上凌晨 3~4 点，公司损失了几千万。