etcd和redis的比较和日常使用场景

最新推荐文章于 2025-07-08 19:23:52 发布
原创 最新推荐文章于 2025-07-08 19:23:52 发布 · 3.2w 阅读 · 21 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文探讨了etcd与redis两种流行的k-v存储系统的主要差异。etcd专注于提供可靠的服务发现及事务管理功能，适用于容器服务部署等场景；redis则以其强大的读写能力和丰富的数据类型，在缓存和持久化存储方面表现出色。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

个人观点：etcd的红火来源于kurbernetes用etcd做服务发现，而redis的兴起则来源于memcache缓存本身的局限性。
etcd是一种分布式存储，更强调的是各个节点之间的通信，同步，确保各个节点上数据和事务的一致性，使得服务发现工作更稳定，本身单节点的写入能力并不强。
redis更像是内存型缓存，虽然也有cluster做主从同步和读写分离，但节点间的一致性主要强调的是数据，并不在乎事务，因此读写能力很强，qps甚至可以达到10万+

两者都是k-v存储，但redis支持更多的存储模式，包括KEY，STRING，HMAP，SET，SORTEDSET等等，因此redis本身就可以完成一些比如排序的简单逻辑。而etcd则支持对key的版本记录和txn操作和client对key的watch，因此适合用做服务发现。

日常使用中，etcd主要还是做一些事务管理类的，基础架构服务用的比较多，容器类的服务部署是其主流。而redis广泛地使用在缓存服务器方面，用作mysql的缓存，通常依据请求量，甚至会做成多级缓存，当然部分情况下也用做存储型redis做持续化存储。

之后会介绍一下两者在代码里的使用

Kubernetes相关的名词解释ETCD组件（5）
luohaitao的专栏
04-20 1141
etcd 是 Kubernetes 的“大脑”，负责存储和维护集群的所有关键状态。它的稳定性和性能直接影响整个集群的可靠性。理解 etcd 的作用和运维方法，是管理 Kubernetes 集群的重要基础。
【云原生网关】Apache ShenYu 使用详解
congge
06-07 4441
apache shenyu使用总结
延时队列如何实现？ETCD vs Redis
csdnYF的博客
05-05 1236
前言 日常开发中，我们经常会碰到有延时任务的场景，譬如30分钟后关闭订单、在指定时间上架某个活动等，如果是最简单的场景，不考虑服务水平扩容、服务宕机等因素，可能内部用github.com/robfig/cron加MYSQL存储延时信息即可。当然，一般线上服务，不可能不考虑道这些因素的影响，所以才有很多任务调度框架，比如：Quartz、xxl-job、Temporal等。但这次这里想讨论的是中间情况，也就是，既想保证服务能水平扩容、服务宕机任务不丢失，又不想使用那些调度框架（毕竟有部署成本和学习成本）。 延时
redis与etcd的对比
wyx的博客
04-17 1973
1.1 字符串（strings）1.2 字符串列表（lists）1.3 字符串集合（sets）1.4 有序字符串集合（sorted sets）1.5 哈希（hashes）2.redis的持久化：RDB（Redis Database）和AOF（Append Only File）RDB：在不同的时间点，将redis存储的数据生成快照，并且存储到磁盘等介质上。
微服务架构
最新发布
weixin_49199313的博客
07-08 1006
微服务架构是一种将的软件设计方法，每个服务围绕特定业务能力构建，通过轻量级通信机制协同工作。
etcd和mysql_etcd和redis比较
weixin_42314846的博客
01-26 900
尽管etcd和redis都是键值存储，随着技术的演进，二者在功能上也有逐渐相似的趋势，但二者在许多方面都有很大区别。etcd的红火来源于k8s用etcd做服务发现，而redis的兴起则来源于memcache缓存本身的局限性。etcd的重点是利用raft算法做分布式一致性，强调各个节点之间的通信、同步，确保各节点数据和事务的一致性，使得服务发现工作更稳定；redis也可以做主从同步和读写分离，但节点...
etcd和redis 区别和对比
王安的博客
05-17 4084
redis更像是内存型缓存，虽然也有cluster做主从同步和读写分离，但节点间的一致性主要强调的是数据，并不在乎事务，因此读写能力很强，qps甚至可以达到10万+。redis支持更多的存储模式，包括KEY，STRING，HMAP，SET，SORTEDSET等等，因此redis本身就可以完成一些比如排序的简单逻辑。etcd是一种分布式存储，更强调的是各个节点之间的通信，同步，确保各个节点上数据和事务的一致性，使得服务发现工作更稳定，本身单节点的写入能力并不强。
etcd 和 Redis 的对比：特点与适用场景
小桥流水 的专栏
03-19 3394
对比etcd和redis的特点
redis使用场景_一日一技：这个使用场景，etcd 比 Redis 强。
weixin_39750854的博客
12-04 446
摄影：产品经理跟着产品经理到处浪我们说，要评判一个东西的好坏，一定要说明具体在什么业务场景。脱离业务谈好坏是没有意义的。Redis 非常强大，我出版过一本书专门介绍 Redis 的各种用法。但这并不是说 Redis 在各种方面都没有对手。至少在分布式系统的配置更新这个场景上面，我认为 etcd 做得更好。要解释这个问题，我们来看一个具体的业务场景：在 Redis 中有一个列表 sente...
Codis和Redis-cluster对比
BAKI的博客
11-27 8128
Codis和Redis-cluster对比及性能测试 架构对比 redis cluster redis 4.0版本的集群是去中心化的结构，集群元数据信息分布在每个节点上，主备切换依赖于多个节点协商选主。 redis 提供了redis-trib 工具做部署集群及运维等操作。 客户端访问散列的db节点需依赖smart client，也就是客户端需要对redis返回的节点信息做判断选择路由等操作。例如...
Etcd整理
weixin_35821291的博客
02-25 1505
1. etcd是什么？[] A highly-available key value store for shared configuration and service discovery. 多个节点之间通过 Raft 一致性算法的完成分布式一致性协同 键值对存储：数据存储在分层组织的目录中，类似于我们日常使用的文件系统。 存储方式，采用类似目录结构。 只有叶子节点才能真正存储数据，相当于文件。 叶子节点的父节点一定是目录，目录不能存储数据。 etcd 的场景默认处理的数据都是系统
分布式锁 Redis vs etcd
dengjiayue的博客
01-09 2571
当我们不需要很强的一致性,但是需要比较高的性能的时候,大量并发获取锁的情景下我们可以选择 Redis 的分布式锁如果我们需要强一致,高性能,高并发的场景的话我们可以使用 Redis 的 redlock 模式如果我们需要强一致,但是性能不需要太高,并且并发数量并不高的情况,可以选择使用 etcd 的分布式锁。
etcd和redis的对比
柠是柠檬的檬的博客
08-18 2278
etcd和redis的对比
【etcd】ubuntu22安装，与redis对比的区别
m0_74282926的博客
02-15 1080
更新软件包列表： 安装 etcd： 启动 etcd 服务： 验证安装： 如果输出类似以下内容，表示安装成功： 设置开机自启（可选）： 方法 2：通过二进制文件安装（推荐，支持最新版本） 适用于需要最新版本或自定义配置的场景。下载 etcd 二进制文件： 解压文件： 移动文件到系统路径： 创建 etcd 配置和数据目录： 创建 systemd 服务文件： 写入以下内容（按需修改配置）： 启动 etcd 服务： 验证服务状态： 输出应显示 。测试 etcd：
Etcd 与Redis 业务应用场景差异
pfm685757的专栏
03-01 1646
Redis特点 1. 丰富的数据类型 (string, hash, set ,zset, list 等) 2. 读写性能优异 3. 单线程原子性 4. 可持久化 aof/rdb 5. 支持pub/sub 订阅发布模式 高可用方案：哨兵机制 分布式一致性：redis主从为异步复制模式，一致性无法保证 (多节点数据一致性强依赖网络延迟) 主要适用场景：队列, 缓存，分布式session，等非强...
分布式锁实现原理与实战：Redis vs ZooKeeper vs Etcd
2401_88760782的博客
03-13 1071
Redis适合高性能要求的场景锁操作频繁但持有时间短的场景可以容忍极端情况下锁失效的场景运维资源有限的团队ZooKeeper适合对数据一致性要求极高的场景需要复杂锁类型(如公平锁、读写锁)的场景长时间持有锁的场景有专业运维团队的大型组织Etcd适合云原生架构与Kubernetes生态集成的场景需要强一致性但又希望API简洁的场景对性能要求适中的场景分布式锁是分布式系统中的关键组件，选择合适的实现对系统的可靠性和性能至关重要。
etcd vs redis方案对比
热门推荐
zhonglg3的博客
05-19 1万+
尽管etcd和redis都是键值存储，随着技术的演进，二者在功能上也有逐渐相似的趋势，但二者在许多方面都有很大区别。 etcd的红火来源于k8s用etcd做服务发现，而redis的兴起则来源于memcache缓存本身的局限性。 etcd的重点是利用raft算法做分布式一致性，强调各个节点之间的通信、同步，确保各节点数据和事务的一致性，使得服务发现工作更稳定； redis也可以做主从同步和读写分离，但节点一致性强调的是数据，不是事务。redis的注册和发现只能通过pub和sub实现，安全性不能保证（断线
Java开发高级工程师面试，etcd：一款比Redis更骚的分布式锁的实现方式
m0_60732427的博客
08-07 618
Watch 机制支持 Watch 某个固定的 key，也支持 Watch 一个范围（前缀机制）。 当被 Watch 的 key 或范围发生变化，客户端将收到通知；在实现分布式锁时，如果抢锁失败， 可通过 Prefix 机制返回的 Key-Value 列表获得 Revision 比自己小且相差最小的 key（称为 pre-key）， 对 pre-key 进行监听，因为只有它释放锁，自己才能获得锁，如果 Watch 到 pre-key 的 DELETE 事件， 则说明 pre-key 已经释放，自己将持有锁。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值