Redis-基本概念(四)

本文介绍了Redis的基本概念,包括其作为非关系型数据库的特点与优势,支持的主要数据类型,以及在实际项目中的应用。探讨了Redis的高性能原因,如内存操作、单线程设计与非阻塞IO等,并解释了它在缓存、计数器和消息队列等功能上的应用场景。

概念介绍
Redis是远程服务器的缩写,是目前最火热的非关系型数据库。单线程,默认端口6379

主要优点:

1.key-value存储结构

2.持久化

3.可以设置过期时间

平时项目使用Jedis连接,或使用redisTemplate。

Redis的主要数据类型?

string、hash、list、set及zset(sorted set:有序集合)

Redis能够做什么?
Redis能够做缓存、计数器、简单的消息队列等等

为什么要用Redis?Redis为什么能这么快?

速度快,完全基于内存,数据结构简单,单线程,网络层使用非阻塞IO解决高并发问题

(1) 使用C语言实现,速度快

(2) 完全基于内存,执行效率高

(3) 数据结构简单,对数据操作也简单

(4) 采用单线程,避免线程切换与多线程开销问题

(5) 使用多路IO复用模型,非阻塞IO。采用的IO多路复用的函数有:select/epoll等,优先选择时间复杂度为O(1)的函数作为底层实现,以时间复杂度O(n)的select作为保底。

1、什么是Redis?简述它的优缺点?

Redis本质上是一个Key-Value类型的内存数据库,很像memcached,整个数据库统统加载在内存当中进行操作,定期通过异步操作把数据库数据flush到硬盘上进行保存。

因为是纯内存操作,Redis的性能非常出色,每秒可以处理超过 10万次读写操作,是已知性能最快的Key-Value DB。

Redis的出色之处不仅仅是性能,Redis最大的魅力是支持保存多种数据结构,此外单个value的最大限制是1GB,不像 memcached只能保存1MB的数据,因此Redis可以用来实现很多有用的功能。

比方说用他的List来做FIFO双向链表,实现一个轻量级的高性 能消息队列服务,用他的Set可以做高性能的tag系统等等。

另外Redis也可以对存入的Key-Value设置expire时间,因此也可以被当作一 个功能加强版的memcached来用。 Redis的主要缺点是数据库容量受到物理内存的限制,不能用作海量数据的高性能读写,因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。

2、Redis相比memcached有哪些优势?

(1) memcached所有的值均是简单的字符串,redis作为其替代者,支持更为丰富的数据类型

(2) redis的速度比memcached快很多

(3) redis可以持久化其数据

3、Redis支持哪几种数据类型?

String、List、Set、Sorted Set、hashes

4、Redis主要消耗什么物理资源?

内存。

6、Redis有哪几种数据淘汰策略?

noeviction:返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令(大部分的写入指令,但DEL和几个例外)

allkeys-lru: 尝试回收最少使用的键(LRU),使得新添加的数据有空间存放。

volatile-lru: 尝试回收最少使用的键(LRU),但仅限于在过期集合的键,使得新添加的数据有空间存放。

allkeys-random: 回收随机的键使得新添加的数据有空间存放。

volatile-random: 回收随机的键使得新添加的数据有空间存放,但仅限于在过期集合的键。

volatile-ttl: 回收在过期集合的键,并且优先回收存活时间(TTL)较短的键,使得新添加的数据有空间存放。

7、Redis官方为什么不提供Windows版本?

因为目前Linux版本已经相当稳定,而且用户量很大,无需开发windows版本,反而会带来兼容性等问题。

8、一个字符串类型的值能存储最大容量是多少?

512M

9、为什么Redis需要把所有数据放到内存中?

Redis为了达到最快的读写速度将数据都读到内存中,并通过异步的方式将数据写入磁盘。

所以redis具有快速和数据持久化的特征。如果不将数据放在内存中,磁盘I/O速度为严重影响redis的性能。

在内存越来越便宜的今天,redis将会越来越受欢迎。 如果设置了最大使用的内存,则数据已有记录数达到内存限值后不能继续插入新值。
持久化
分为两种:

1.RDB:数据完整的生成一个快照,以二进制的格式保存在硬盘上,后缀为.rdb。

2.AOF:所有数据更新语句都记录在日志上。(AOF重写)

复制
旧版:同步,主节点更新状态给从节点,全部打包,效率低

新版:同步,完整重同步,部分重同步

取决条件是运行ID+复制偏移量+复制积压缓冲区

哨兵(sentinel
投票选举leader,和选举主节点

<think>好的,我现在需要回答用户关于Helm部署Redis集群时生成的两个服务(redis-redis-cluster和redis-redis-cluster-headless)的作用及区别,以及它们的端口配置对客户端连接的影响。首先,我需要回顾一下Kubernetes中Service和Headless Service的基本概念,以及它们在Redis集群部署中的具体应用。 用户之前的问题是关于Helm部署Redis主从时连接地址的配置,现在转向了Redis集群的情况,所以需要明确集群模式下的服务配置。用户提到的两个服务:redis-redis-cluster和redis-redis-cluster-headless,我需要解释它们各自的作用。 首先,参考用户提供的引用,特别是引用[3]提到Headless Service没有Cluster IP,用于StatefulSet的Pod发现,而另一个Service用于外部访问和负载均衡。引用[4]中使用了dig命令来解析Pod的DNS记录,这说明Headless Service为每个Pod提供了独立的DNS记录,方便直接访问。引用[1]中的例子显示服务有EXTERNAL-IP,可能是指LoadBalancer类型的服务,用于外部访问。 接下来,我需要确定在Redis集群部署中,这两个服务各自承担的角色。通常,Redis集群需要节点之间的直接通信,因为每个节点都知道其他节点的地址,所以Headless Service在这里用于提供Pod的直接DNS解析,使节点能够互相发现和通信。而普通Service(如redis-redis-cluster)可能用于客户端的入口,提供负载均衡,但需要注意Redis集群客户端通常需要直接连接各个节点,而不是通过一个统一的入口,因为客户端需要知道所有节点来处理重定向和分片。 但是,用户的问题中提到的是Helm部署Redis集群后生成的两个服务,我需要确认Helm chart的具体配置。例如,Bitnami的Redis集群Helm chart可能会创建两个服务:一个Headless Service用于内部Pod通信,另一个是ClusterIP或LoadBalancer类型的Service用于外部访问。需要明确这两个服务的类型、端口配置以及它们如何影响客户端连接方式。 另外,用户提到这两个服务的端口配置对客户端的影响。例如,如果普通Service暴露了6379端口,客户端可能通过该Service的Cluster IP或DNS名称来连接,但实际上在集群内部,客户端可能需要使用Headless Service来直接连接到各个Pod,特别是在需要发现所有节点的情况下,比如使用CLUSTER NODES命令或客户端自动发现。 同时,需要注意Redis集群的客户端库通常需要所有节点的地址来正确初始化连接,这时候Headless Service提供的每个Pod的DNS记录就非常重要。而普通Service可能只提供一个入口点,不适合这种需要多个节点地址的场景。 还需要参考用户之前的回答,其中提到主从模式下的服务配置,现在扩展到集群模式。可能需要比较两者的异同,确保回答准确。 最后,总结两个服务的作用:Headless Service用于Pod之间的直接通信和节点发现,普通Service用于客户端的统一接入(但可能不适用于所有客户端情况),并解释端口配置如何影响客户端是否需要直接连接Pod或通过Service访问。</think>以下是对 Helm 部署 Redis 集群时生成的两个服务及其影响的详细解析: --- ### 一、核心服务功能对比 | 服务名称 | 类型 | 作用场景 | 连接方式示例 | 典型端口配置 | |---------------------------------|------------------|--------------------|-----------------------------|--------------------------| | `redis-redis-cluster` | ClusterIP/LoadBalancer | **客户端统一接入** | `redis-cluster:6379` | 6379 (数据端口) | | `redis-redis-cluster-headless` | Headless Service | **节点间直接通信** | `redis-cluster-0.redis-headless:6379` | 6379 + 16379 (集群总线) | --- ### 二、服务作用深度解析 #### 1. redis-redis-cluster (普通服务) **核心功能**: - 提供虚拟 IP 负载均衡(ClusterIP 类型时)[^3] - 对外暴露统一接入点(LoadBalancer 类型时)[^1] - 通过标签选择器关联所有 Redis 节点 Pod **连接影响**: ```python # Python 客户端示例(仅适用于简单场景) import redis r = redis.Redis( host='redis-redis-cluster', # 服务名称 port=6379, password='yourpassword', decode_responses=True ) print(r.ping()) # 可能返回 False,因为集群模式需要特殊处理 ``` *注意*:这种连接方式 **不适用于原生集群模式客户端**,会导致 MOVED 重定向错误[^4] #### 2. redis-redis-cluster-headless (Headless 服务) **核心功能**: - 为每个 Pod 生成独立 DNS 记录[^2] - 暴露集群总线端口 (16379) 用于节点通信 - 支持 StatefulSet 的有序网络标识 **关键 DNS 解析格式**: ```bash # 查看具体节点的解析结果(引用[4]示例) dig +short redis-redis-cluster-0.redis-redis-cluster-headless.default.svc.cluster.local # 输出示例:10.244.1.23 ``` --- ### 三、端口配置差异对比 | 服务类型 | 6379 端口用途 | 16379 端口用途 | 客户端影响 | |------------------|----------------------------|---------------------------|--------------------------------------------------------------------------| | 普通服务 | 数据读写入口 | 无 | 需要客户端支持集群自动发现,否则会出现重定向问题 | | Headless 服务 | 节点级数据访问 | 集群总线通信 | 客户端必须使用全部节点地址初始化连接,例如:<br>`redis-cluster-{0..5}.redis-headless:6379` | --- ### 、生产环境连接方案 #### 方案 1:智能客户端连接(推荐) ```java // Jedis 集群客户端配置示例 Set<HostAndPort> nodes = new HashSet<>(); for (int i = 0; i < 6; i++) { nodes.add(new HostAndPort( String.format("redis-redis-cluster-%d.redis-redis-cluster-headless", i), 6379 )); } JedisCluster cluster = new JedisCluster(nodes, 5000, 5000, 5, "password"); ``` #### 方案 2:DNS 自动发现 ```bash # 使用 SRV 记录自动发现节点(需预先配置) dig SRV _redis._tcp.redis-redis-cluster-headless.default.svc.cluster.local ``` --- ### 五、配置验证方法 1. **检查端点分布**: ```bash kubectl get endpoints redis-redis-cluster # 应显示所有节点 IP:6379 ``` 2. **验证 Headless 解析**: ```bash kubectl exec -it redis-cluster-0 -- nslookup redis-redis-cluster-headless # 应返回所有 Pod IP(引用[2]方法) ``` 3. **集群状态检查**: ```bash kubectl exec redis-cluster-0 -- redis-cli -a $REDIS_PASSWORD --cluster check 127.0.0.1:6379 ``` --- ### 六、故障排查指南 | 现象 | 检查点 | 解决方案 | |--------------------------|-------------------------------|------------------------------------------------------------------------| | 客户端频繁重定向 | 是否使用 Headless 服务地址 | 改用 Pod 级直接连接或启用客户端集群模式 | | 集群节点无法发现对方 | 16379 端口连通性 | 检查网络策略是否允许集群总线通信 | | 部分节点不可用 | Headless 服务的 DNS 解析完整性 | 确认 StatefulSet 副本数与服务配置匹配 | ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值