Redis简介Redis是一个远程内存数据库、非关系型数据库（non-relational database）：
可以存储键（key）与5种不同类型的值（value）之间的映射（mapping）
可以将存储在内存的键值对数据持久化到硬盘
可以使用复制特性来扩展读性能
还可以使用客户端分片来扩展写性能。关键点：非关系型数据库、五种不同类型的值、持久化到硬盘的方式、复制特性（主从复制）、客户端
转载
2024-10-16 11:31:29
19阅读
1、 ack命令在（21）中分析了服务器在运行时的同步数据的方式，但是这只是主服务器向从服务器发送命令，主服务器不能确定从服务器是否接受到命令并成功执行。为了解决这个问题redis是用来ack命令。从服务器在运行的时候会向主服务器发送一个ack命令命令如下：REPLCONF ACK offset这个命令会向主服务器发送它自身的偏移量，主服务器可以根据这个偏移量来判断命令是否发送成功。 发送ACK命
转载
2023-07-04 16:06:29
182阅读
前言我们从一个问题引入今天的主题。在日常业务开发中，我们可能经常听到 DBA 对我们说“不要”（注意：不是禁止）使用 join，那么为什么 DBA 对 join 这么抵触呢？是 join 本身有问题，还是我们使用的方式不对。其实这涉及到 join 语句在 MYSQL 内部到底是怎么执行的。这就是我们今天要讲的内容。1. CAP 的由来要理解 CAP，首先我们要清楚，为何会有人提出 CAP？他提出
转载
2024-09-06 07:45:29
12阅读
之前总结过redis的持久化机制：深度剖析Redis持久化机，持久化机制主要解决redis数据单机备份问题；redis的高可用需要考虑数据的多机备份，多机备份通过主从复制来实现，这是redis高可用的基石。本文将详细介绍redis主从复制的实现原理，在使用过程中应该注意的问题和相关配置。1. CAP理论CAP理论是分布式领域的牛顿定律，所有的分布式存储中间件都要使用它作为理论基石。如下
转载
2023-08-07 22:38:35
69阅读
文章目录前言listpack 数据结构级联更新总结 前言Redis 在 5.0 引入了一个新的数据结构 listpack，它是对 ziplist 结构的改进，在存储空间上会更加节省，而且结构上也比 ziplist 要精简。listpack 数据结构struct listpack<T> {
int32 total_bytes;// 占用的总字节数
int16 size; // 元素
转载
2024-09-03 18:59:08
27阅读
简介 Stream是Redis 5.0引入的一种新数据类型，允许消费者等待生产者发送的新数据，还引入了消费者组概念，组之间数据是相同的(前提是设置的偏移量一样)，组内的消费者不会拿到相同数据。这种概念和kafka很雷同。在某些特定场景可以使用redis的stream代替kafka等消息队列，减少系统复杂性，增强系统的稳定性特点 1.如果使用xrang
转载
2023-08-02 16:31:25
40阅读
# Redis Pub/Sub Acknowledgement
## Introduction
Redis is an open-source, in-memory data structure store that is commonly used as a database, cache, and message broker. One of the key features of Red
原创
2024-06-16 04:53:38
13阅读
前言是的，我又来了。这篇文章主要解析一下 Set 这个数据结构，也是 Redis 系列的第七篇了。概述Set 类型也是用来保存多个的字符串元素，但和列表（List）类型不一样的是，集合中不允许有重复元素，并且集合中的元素是无序的，不能通过索引下标获取元素。还记得 JAVA (别怪我只用 JAVA 举例，其他的我也不会呀)中的 Set 吗，是不是也是这样的呢？好哥哥们，看图说话（请叫我灵魂画手）。1
虽然 reuse port 是在 linux 3.9 才被合并进来，但有 backport 到更早之前的版本（至少我们在使用的 2.6.32 是有的），很多博客在这点上有些误导。另外，在 reload 时候也不能简单将老的监听关闭，会导致 tcp backlog 里面这些三次握手成功但未 accept 的连接丢失，业务在这些连接上发送数据则会收到 rst 包。我们解决这个问题的方式是让监听连接都在
# 教你如何实现Redis订阅模式ACK
## 一、整体流程
首先，我们来看一下整个Redis订阅模式ACK的流程：
```mermaid
journey
title Redis订阅模式ACK流程
section 订阅者
订阅消息 --> 收到消息
收到消息 --> 发送ACK
end
section 发布者
原创
2024-07-11 05:53:40
51阅读
# Spring Boot 与 Redis 队列与 ACK 实现指南
在微服务架构或者分布式系统中，队列是一种常见的消息传递机制。`Spring Boot`与`Redis`结合可以简单地实现队列的功能，并处理消息的确认（ACK）。本文将详细讲解如何在`Spring Boot`中使用`Redis`实现消息队列以及ACK的流程。
## 流程概述
我们使用以下步骤实现`Spring Boot`与`
原创
2024-09-23 07:08:39
71阅读
Java Redis ACK机制
## 简介
在使用Redis作为分布式缓存时，往往会遇到读写一致性的问题。为了保证数据的一致性，Redis引入了ACK机制。ACK是Acknowledgement的简称，意味着确认。
ACK机制主要用于保证写操作的一致性。在写入数据到Redis时，Redis会返回一个ACK，表示写操作已经成功执行。客户端可以根据收到的ACK来确认写操作的结果，并根据需要做出
原创
2024-01-16 04:12:35
103阅读
文章目录容量问题Z轴拆分1. modula（hsah + 取模）：2. random:应用3. ketama（一致性hash）:redis的连接成本很高redis自带的拆分：cluster存取数据twemproxy搭建过程predixy搭建过程cluster操作演示 容量问题单机redis在使用的时候会碰到三个问题：单点故障、容量不足、访问压力。因此我们可以对redis进行AKF拆分，站在x轴的
转载
2024-10-01 14:22:02
15阅读
# Redis Stream Ack 机制详解
Redis 作为一个高性能的键值数据库，提供了丰富的数据结构和功能。其中，Redis Streams 是 Redis 5.0 版本引入的一项重要功能，支持数据的流式处理。在使用 Redis Streams 时，ACK 机制是保证消息可靠处理的关键部分。本文将详细介绍 Redis Stream 的 ACK 机制，并带有相应的代码示例。
## 1.
# Redis消息队列ACK
## 什么是Redis消息队列ACK
在使用Redis作为消息队列时，消息的确认机制（ACK）是非常重要的一部分。ACK的作用是确保消息在消费者处理完成后才被认为已经成功消费，防止消息丢失或重复消费。
## Redis消息队列ACK的工作原理
当消费者接收到消息后，需要对消息进行处理。处理完成后，需要向Redis发送一个确认消息的请求，告诉Redis这条消息已
原创
2024-04-30 04:45:36
190阅读
Redis 持久化机制 文章目录打爆面试官：Redis 持久化机制前言1.2 RDB执行流程1.3 RDB的优缺点2、AOF（append only file）日志2.1 开启方式2.2 重写（rewrite）机制2.3 触发机制2.4 AOF的优缺点3、Redis 4.0 混合持久化 前言redis是一个内存数据库，为了防止数据丢失以及服务重启时能够恢复数据，Redis支持数据的持久化，主要分为
转载
2023-08-03 15:26:47
98阅读
CAP原则一致性（Consistency）：读操作总是能读取到之前完成的写操作结果，系统每时每刻每个节点上的同一份数据都是一致如Mysql数据库与Redis缓存的数据应当一致可用性（Availability）：非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）对与系统，某个节点坏了不会影响其他节点，任何时候系统都能提供读写业务（不需要数据一致），高可用性 99.9999%，即全年允许
转载
2023-11-25 17:37:32
50阅读
Redis 的消息队列不是专业的消息队列，它没有非常多的高级特性，没有 ack 保证，如果对消息的可靠性有着极致的追求，那么它就不适合使用，对于那些只有一组消费者的消息队列，使用 Redis 就可以非常轻松的搞定。异步消息队列Redis的list常用来作为异步消息队列使用，使用``rpush/lpush操作入队列，使用lpop/rpop`来出队列。> rpush stack 1 2 3
(i
转载
2023-06-07 11:21:34
266阅读
现在用的消息队列主要有kafka，rabbitmq和redis。相比另外两个，用redis做消息队列的优点是吞吐量高，延迟低，简单易用，易于部署和运维。缺点是没有ACK机制，可靠性方面不足。 本次用swoole + redis 来模拟个消息推送系统。思路1. 某个业务调用消息接口，将内容和对应的uid存入redis列表中，key为msg。 2. 用户连接swoole后，会有个fd来标识这个会话，
转载
2023-08-01 14:33:16
138阅读
重复消费问题：为了解决消费端因为种种原因而造成的消息丢失问题，我们都知道根源在于因为RabbitMQ的自动ack机制，所以为了避免以上问题，我们会选中手动ack，以确保消息不会因为某些原因而丢失。但随之而来的也有一个问题：如果忘记ack，或者又因为种种原因消费者端没能给RabbitMQ对应ack，无法确认消息已经被消费完了，那这条未被“约束”的消息也许就会被另一个消费者消费，就会造成重复消费问题如
转载
2023-08-15 15:47:52
122阅读
