Zookeeper,Etcd和Redis做微服务中间件的特点
本文最后更新于:2024年4月29日 下午
前言
在微服务架构中,中间件是非常重要的一环,它可以帮助我们解决服务注册、服务发现、服务调用、负载均衡、熔断降级、配置管理等问题(其实主要是有个面试问了这个)。在中间件时候,Zookeeper、Etcd和Redis是非常常见的中间件(同时也被问到过他们之中的优缺点)。同时,在手写的玩具RPC框架中,三者都可以做为注册中心,本文也会对这三种中间件在注册中心中的使用进行对比分析。
Redis
Redis的做项目时候的使用基本上是作为缓存使用的,但是Redis也可以作为注册中心使用。Redis的优点是性能高,他的数据都是存储在内存中的,所以读写速度非常快。但是Redis的缺点也很明显,因为数据都是存储在内存中的,所以数据量不能太大,否则会导致内存溢出,同时也不具备想Zookeeper和Etcd类似的功能。所以Redis只适合做一些小型的注册中心。
主要的应用
- 缓存(大头)
- 分布式中同步数据
- 分布式锁
- 任务队列
优点
- 性能高
- 支持多种数据结构
- 支持持久化
Zookeeper
ZooKeeper 是一个开源的分布式协调服务,它的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集,并以一系列简单易用的接口提供给用户使用。
主要的应用
核心其实就是分布式协调,处理复杂且容易出错的分布式一致性服务
主要的特点
- 顺序一致性:从同一客户端发起的事务请求,最终将会严格地按照顺序被应用到 ZooKeeper 中去。
- 原子性: 所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的,也就是说,要么整个集群中所有的机器都成功应用了某一个事务,要么都没有应用。
- 单一系统映像: 无论客户端连到哪一个 ZooKeeper 服务器上,其看到的服务端数据模型都是一致的。
- 可靠性: 一旦一次更改请求被应用,更改的结果就会被持久化,直到被下一次更改覆盖。
- 实时性: 一旦数据发生变更,其他节点会实时感知到。每个客户端的系统视图都是最新的。
- 集群部署:3~5 台(最好奇数台)机器就可以组成一个集群,每台机器都在内存保存了 ZooKeeper 的全部数据,机器之间互相通信同步数据,客户端连接任何一台机器都可以。
- 高可用:如果某台机器宕机,会保证数据不丢失。集群中挂掉不超过一半的机器,都能保证集群可用。比如 3 台机器可以挂 1 台,5 台机器可以挂 2 台。
Zookeeper的使用场景
- 命名服务:可以通过 ZooKeeper 的顺序节点生成全局唯一 ID。
- 数据发布/订阅:通过 Watcher 机制 可以很方便地实现数据发布/订阅。当你将数据发布到 ZooKeeper 被监听的节点上,其他机器可通过监听 ZooKeeper 上节点的变化来实现配置的动态更新。
- 分布式锁:通过创建唯一节点获得分布式锁,当获得锁的一方执行完相关代码或者是挂掉之后就释放锁。分布式锁的实现也需要用到 Watcher 机制 ,当锁释放时,其他等待锁的机器可以收到通知(这点Redis实现的分布式锁不同,Redis分布式锁需要依靠看门狗机制来解决)。
ZooKeeper建议使用奇数个节点
因为ZooKeeper的选举机制是基于Paxos算法的,所以ZooKeeper集群中的节点数最好是(2n+1)个,这样才能保证选举出来的Leader是唯一的。例如4个节点的集群,如果有一个节点宕机,剩下的3个节点无法选出Leader,集群就无法正常工作了。同样的,如果有3个节点的集群,如果有一个节点宕机,剩下的2个节点可以选出Leader,这样的集群容错性与4个相同,所以ZooKeeper建议使用奇数个节点。
Etcd
Etcd 是一个高可用的键值存储系统,主要用于共享配置和服务发现。Etcd 是由 CoreOS 开发并维护的,它的设计受到了 ZooKeeper 和 Doozer 的启发,但是在 Raft 上实现了一些不同的设计。
主要的应用
- 服务发现
- 配置中心
- 分布式锁
(Etcd的应用场景和Zookeeper有很多重合的地方,但是Etcd的设计更加简单,性能更好)
在K8s中,Etcd是K8s的数据存储后端,用于存储K8s的集群状态,比如存储Pod、Service、Namespace等信息。
主要的特点
- 简单: Etcd 的 API 设计简单,易于使用。
- 安全: Etcd 支持 SSL 安全访问,保证数据传输的安全。
- 快速: Etcd 使用 Raft 一致性算法,保证分布式系统的一致性,同时保证高可用。
- 可靠: Etcd 使用 Raft 一致性算法,保证分布式系统的一致性,同时保证高可用。
- 分布式: Etcd 是一个分布式系统,支持多个节点,保证系统的高可用。
优缺点对比
三者做注册中心的对比
- Zookeeper: 适合做注册中心,因为Zookeeper是一个分布式协调服务,处理复杂且容易出错的分布式一致性服务。Zookeeper的数据是存储在磁盘上的,所以可以存储大量的数据,适合做大型的注册中心。
- Redis: 我认为更适合做缓存,因为Redis的数据是存储在内存中的,同时不具备有看门狗类似的功能,在性能上相较于其他两项略差,所以只适合做一些小型的注册中心。
- Etcd: 适合做注册中心,因为Etcd是一个高可用的键值存储系统,主要用于共享配置和服务发现。相较于Zookeeper,Etcd的设计更加简单,性能更好,实现的功能需求更好。