服务注册中心etcd

已于 2023-07-26 08:59:03 修改
阅读量654 收藏
点赞数
文章标签： etcd 数据库 后端 服务器
于 2023-07-25 17:14:26 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/congchp/article/details/131922327
版权

etcd简介

etcd官方描述
A distributed, reliable key-value store for the most critical data of a distributed system.
etcd is a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines. It gracefully handles leader elections during network partitions and can tolerate machine failure, even in the leader node.

etcd提供一个分布式，高可用、强一致性的kv数据存储服务；
用于读多写少的场景，用于存储少量数据；

etcd诞生于CoreOS公司，基于go语言实现，主要用于共享配置和服务发现；

etcd v2和v3版本比较

  • v2版本使用http1.1+json通信，v3版本使用grpc(http2.0)+protobuf；v3也支持http+json；
  • v2是简单的kv内存数据库；v3支持事务和多版本并发控制(一致性非锁定读)的磁盘数据库；
  • v3使用lease(租约)替换key ttl自动过期机制；
  • v3是扁平的kv结构；v2是类文件系统的存储结构，是树状的，跟zookeeper类似；

etcd架构

image.png

grpc Server：etcd集群节点间以及clent与etcd节点间都是通过grpc进行通信；
Raft协议：etcd通过raft协议来管理集群；
wal(write ahead log)：预写式日志，执行写操作前先写wal日志，磁盘顺序写，提升写性能；类似mysql的redo log和rocksdb的wal日志；
snapshot快照数据：用于其他节点同步主节点数据从而达到一致性的状态；类似redis的rdb，用于主从同步；
boltdb：是一个单机的支持事务的kv数据库，etcd的事务是基于boltdb的事务实现的；boltdb为每一个key都创建一个B+树，该B+树存储了key所对应的版本数据；

etcd操作命令

设置

# Puts the given key into the store
PUT key val
--ignore-lease[=false] #updates the key using its current lease
--ignore-value[=false] #updates the key using its current value
--lease="0" #lease ID (in hexadecimal) to attach to the key
--prev-kv[=false] #return the previous key-value pair before modification

删除

# Removes the specified key or range of keys [key, range_end)
DEL key
DEL keyfrom keyend
--from-key[=false] #delete keys that are greater than or equal to the given key using byte compare
--prefix[=false] #delete keys with matching prefix
--prev-kv[=false] #return deleted key-value pairs

获取

# Gets the key or a range of keys
GET key
GET keyfrom keyend
--consistency="l" #Linearizable(l) or Serializable(s)
--count-only[=false] #Get only the count
--from-key[=false] #Get keys that are greater than or equal to the given key using byte compare
--keys-only[=false] #Get only the keys
--limit=0 #Maximum number of results
--order="" #Order of results; ASCEND or DESCEND(ASCEND by default)
--prefix[=false] #Get keys with matching prefix
--print-value-only[=false] #Only write values when using the "simple" output format
--rev=0 #Specify the kv revision
--sort-by="" #Sort target; CREATE, KEY, MODIFY, VALUE, or VERSION
-w json

监听

# Watches events stream on keys or prefixes
WATCH key
-i, --interactive[=false] #Interactive mode
--prefix[=false] #Watch on a prefix if prefix is set
--prev-kv[=false] #get the previous key-value pair before the event happens
--progress-notify[=false] #get periodic watch progress notification from server
--rev=0 #Revision to start watching

事务

保证多个操作的原子性；

# Txn processes all the requests in one transaction
TXN if/ then/ else ops
-i, --interactive[=false] #Input transaction in interactive mode

在这里插入图片描述

租约

lease grant # 创建一个租约
lease keep-alive # 续约
lease list # 枚举所有的租约
lease revoke # 销毁租约
lease timetolive # 获取租约信息

raft共识算法

raft是一种分布式一致性算法；

tikv server通过raft算法保证数据的强一致性；pd server也是通过raft来保证数据的一致性；

Raft下读写是如何工作的？
读写都是通过leader；follower只有选举和备份的作用，读写都不经过follower；learner只有复制的作用，没有选举权；

leader选举(leader election)

两个超时控制选举：

  1. election timeout, 选举超时，就是follower等待成为candidate的时间，是150ms到300ms的随机值；
  2. heartbeat timeout，心跳超时，要小于150ms，即小于election timeout；

选举超时后，follower成为candidate，开始新一轮选举，election term(任期)加一；follower给自己投上一票，然后向其它节点拉票；如果其他节点还没有投票，那么就投给这个candidate；收到拉票请求后，其它节点重置它的选举超时；candidate获得大多数的选票的时候，就成为leader。leader在心跳超时(heartbeat timeout)内，向其它节点同步自身的变化，follower节点收到通知后给leader回复；当前选举周期一直持续到某个follower节点收不到heartbeat，从而成为candidate。

follower成为candidate后，需要做以下事情：

  1. election term加一；
  2. 给自己投一票；
  3. 重置election timeout；

follower收到拉票请求后，需要做以下事情：

  1. 重置election timeout；
  2. election term加一
  3. 只会给第一个拉票的candidate投票；

收到heartbeat也需要重置election timeout；

日志复制(log replication)

所有的写操作，都需要通过leader节点；leader先将写操作写入log(WAL日志)，并没有提交；之后将log发送给follower节点，follower节点会写入自己的WAL日志，之后回复leader节点；leader节点获得大多数节点的应答后，再进行提交，之后将结果回复给client；最后再通知follwer节点落盘；

网络分区(network partitions, 脑裂)

比如集群一共有5个节点，由于网络故障，分成两个分区A, B；A有3个节点，B有2个节点，原先的leader节点在B中，A会重新选举出一个新的leader；对于A的写操作，由于大多数原则，最终会commit；对于B，因为不满足大多数原则，所以不会commit。

网络恢复后，raft如何恢复一致性？
网络恢复后，B会回滚未提交的日志，并且会同步A的数据；主要是因为A的election term比B大，最终A中的leader会成为整个集群的leader；

election term的作用？
解决网络分区问题；

etcd存储原理

数据版本号机制

  • raft_term:

leader任期，没进行一轮选举term加一；全局递增，64bits;

  • revision:

etcd 全局key空间版本号，只要有key发生变更，则revision加一；

revision机制是etcd实现MVCC的基础；

  • kv中的revision：
    • create_revision

创建key数据时，对应的revision；

  • mod_revision

修改key的value数据时，对应的revision；

  • version

key的当前版本号；表示该key的value被修改了多少次；

etcd存储

image.png

etcd为每个key创建一个索引；在磁盘中，使用B+树存储，一个索引对应一棵B+树；B+树的key为revision，value为key对应的值；B+树存储key的revision，从而实现了etcd的MVCC；etcd不会存储所有的revision，会通过定期compaction来清理历史revision，只保留较新的部分revision；

为了提高索引的效率，etcd在内存中维持一棵B树；为什么使用Ｂ树，而不是红黑树呢？从磁盘B+树中，可以一次copy一页（16k）到内存Ｂ树中，插入效率更快；

mysql通过undolog实现MVCC；mysql内存使用自适应hash

etcd应用

服务发现

etcd作为注册中心；服务提供者向etcd进行注册，即put key value；服务使用者watch对应的key；

image.png

负载均衡

多个服务提供者向etcd进行注册，put不同的key，使用同样的prefix；etcd通过心跳检测，确定各个服务提供者的状态，进行负载均衡；

image.png

分布式锁

redis可以通过setnx实现非公平分布式锁；etcd可以实现平台锁；
第一个创建key的客户端先获取锁；其他客户端监听版本号刚好小于自己的对象的删除信息；

image.png

congchp
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
分布式注册中心-etcd
hahackeris的专栏
07-10 532
etcd 分布式
ETCD的注册中心实现
Java技术干货
09-14 644
etcd是一个分布式的键值存储，它可以用于服务的注册和发现，以及配置的共享和同步。• 服务提供者在启动时，在etcd中创建一个以服务名为路径的目录，并在该目录下创建一个以自己的地址为键的子目录或键，并设置TTL为一定时间间隔（例如30秒）。• 服务消费者在启动时，在etcd中创建一个watcher，监听服务名对应的目录，并获取该目录下所有子目录或键的数据，作为可用的服务列表。• 服务提供者在运行时，定期向etcd发送心跳请求，更新自己的子目录或键的TTL，以维持自己在etcd中的存活状态。
【Web框架】4.GRPC基于etcd做服务注册与发现
最新发布
lixiaonan0318的博客
04-27 531
客户端首先取得服务端的节点 endpoint 列表，基于一定的负载均衡策略选择到特定的 endpoint，直连发起请求.grpc负载均衡策略：pick_first选第一个（默认）；round_robin轮询。常用的负载均衡策略：随机、轮询、加权随机、加权轮询、源地址哈希法、最小连接数法。
CentOS7安装ETCD
YunWisdom
02-07 2458
CentOS7安装ETCD 从Github上下载并解压安装包 wget https://github.com/coreos/etcd/releases/download/v3.4.10/etcd-v3.4.10-linux-amd64.tar.gz tar xzvf etcd-v3.4.10-linux-amd64.tar.gz mv etcd-v3.4.10-linux-amd64 /opt/etcd 解压后是一些文档和两个二进制文件etcd和etcdctl。etcd是server端，et.
注册中心原理和选型：Zookeeper、Eureka、Nacos、Consul和Etcd
IT学习小镇
04-14 1462
讲解5种常用的注册中心，对比其流程和原理，无论是面试还是技术选型，都非常有帮助。对于注册中心，在写这篇文章前，我其实只对ETCD有比较深入的了解，但是对于Zookeeper和其它的注册中心了解甚少，甚至都没有考虑过ETCD和Zookeeper是否适合作为注册中心。经过近2周的学习，原来注册中心除了ETCD和Zookeeper，常用的还有Eureka、Nacos、Consul，下面我们就对这些常用的...
go语言分布式中间件之etcdv2和v3对比
SMILY12138的博客
05-19 352
Etcd 是一个重要的分布式系统组件，用于服务发现和配置共享。在 Go 语言中，Etcd v2 和 v3 是两个主要版本，它们各自具有不同的特点和优缺点。选择哪个版本取决于您的应用程序需求以及对稳定性和性能的要求。如果您需要一个稳定、易用且经过多年验证的版本，并且您的应用程序较为简单，则可以选择 Etcd v2；而如果您需要更高级的功能、更好的性能以及更多的可扩展性，则可以选择 Etcd v3。无论哪个版本，都需要花费一些时间来学习和理解其使用方法，以便更好地将其集成到您的应用程序中。
go 进阶 注册中心: 一. etcd 入门
qq_29799655的博客
05-09 1386
etcd 是一款用go语言编写的分布式存储中间件,采用Raft算法保证分布式系统数据的强一致性,通过分布式锁、leader选举和写屏障(write barriers)，来实现可靠的分布式协作应用场景服务发现（Service Discovery）消息发布与订阅负载均衡分布式通知与协调分布式锁、分布式队列集群监控与Leader竞选etcd满足了cap理论中的cp指标(c:一致性, a可用性, p分区容错性)
微服务之注册中心
热门推荐
haponchang的博客
06-24 1万+
相关文章 服务描述 https://blog.csdn.net/haponchang/article/details/90746408 注册中心 https://blog.csdn.net/haponchang/article/details/93467008 服务框架 https://blog.csdn.net/haponchang/article/details/934680...
利用etcd实现服务注册和服务发现
03-31
`etcd` 是一个高度可用的键值存储系统，常被用作分布式协调服务，包括服务注册和服务发现。本篇文章将深入探讨如何利用 `etcd` 实现这一功能，并结合提供的 `go_server` 和 `go_client` 示例代码进行解析。 首先，...
90分钟搞懂分布式注册服务中心etcd2.png
09-04
更多完整视频https://ke.qq.com/course/417774?flowToken=1013299
微服务etcd配置中心.zip
08-17
1. **服务注册与发现**：每个微服务在启动时向Etcd注册自己的地址和元数据，其他服务可以通过查询Etcd来找到需要依赖的服务实例。 2. **动态配置**：微服务可以从Etcd获取并监听配置变化，无需重启即可实现配置更新...
go语言构建一个基于etcd的服务注册与发现系统.zip
05-26
服务注册是服务发现的第一步，即服务启动后将自己的元信息（如服务名、地址、端口等）注册到服务注册中心（如Etcd）。Go语言可以通过HTTP或gRPC客户端与Etcd交互，将服务信息写入Etcd的特定key中，例如`/services/{...
etcd manager
05-24
- **服务发现**: 各个服务可以在 etcd 中注册和发现其他服务，实现服务间的自动发现和负载均衡。 - **分布式锁**: 利用 etcd 的原子操作特性，可以实现分布式锁，保证多节点间的并发操作安全。 - **状态存储**: ...
Etcd V2与V3存储差异
sHuXnHs
11-01 1570
Etcd V2与V3存储差异 在Etcd v2与v3两个版本中，使用的存储方式完全不同，所以两个版本的数据并不兼容，对外提供的接口也是不一样的，不同版本的数据是相互隔离的，只能使用对应的版本去存储与获取。 V2——基于内存的存储 在v2版本中，数据是以树形结构完全存储在内存中的，只有进行持久化的时候才会将数据以JSON格式存储进磁盘。 v2的watch机制 在v2版本中，存在着一个EventHistory表，EventHistory表是有长度限制的，默认是1000. v2中存在一个全局的版本cu
架构之微服务-分布式注册服务中心(etcd)
anzhenxi3529的博客
12-05 752
1. ETCD是什么 ETCD是用于共享配置和服务发现的分布式，一致性的KV存储系统。该项目目前最新稳定版本为2.3.0. 具体信息请参考[项目首页]和[Github]。ETCD是CoreOS公司发起的一个开源项目，授权协议为Apache。 提供配置共享和服务发现的系统比较多，其中最为大家熟知的是[Zookeeper]（后文简称ZK），而ETCD可以算得上是后起之秀了。在项目实现，一致性协议易理解性，运维，安全等多个维度上，ETCD相比Zookeeper都占据优势。 2. E...
分布式注册服务中心——ETCD
bingshanzhu的专栏
10-24 211
etcd简介，觉得写的不错
05服务发现：引入etcd服务注册中心
做兴趣使然的Hero
02-18 872
etcd是一种强一致性的分布式键值存储组件，使用Raft算法，由于CAP理论，没有一种服务注册中心能够完全兼顾C、A、P，只能偏向于CP或AP，etcd作为偏向CP的分布式服务注册中心，利用Go语言编写，它提供了一种可靠的方式来存储需要由分布式系统或机器集群访问的数据。它在网络分区期间优雅地处理领导者选举，并且可以容忍机器故障，即使在领导者节点中也是如此。
微服务注册中心 ETCD Go/Python/Node调用
qq_38269333的博客
05-18 817
微服务注册中心ETCD简介 Go/python/node调用
ETCD API V3
qq_39225271的博客
06-24 1100
v2是一个key-value数据库，只保存key的最新的value，之前的value直接覆盖，但是会维护1000个所有key的变更记录，如果在短时间频繁写操作，那么变更记录会很快超过1000，如果watch过慢就会无法得到之前的变更，带来后果就是watch丢失事件。v2 是在每个key上设置TTL，v3是租约机制，然后key绑定租约，如果需要更新key的过期时间，可以直接更新租约（lease），多个key绑定到一个租约上，需要更新每个key的过期时间时，v3减少了客户端请求数量。
dubbo的etcd注册中心
01-31
Dubbo 是一种开源的分布式服务框架，可以实现高性能的 RPC 调用和服务治理。etcd 是一个分布式键值存储系统，也是一个强大的服务注册和发现中心，可以提供高可用性和可靠性的服务注册与发现功能。 在 Dubbo 中，etcd 可以作为一种注册中心来使用。注册中心的作用是让服务提供者将自己的服务注册到其中，同时让服务消费者从中发现并调用所需的服务。etcd 提供了简单而强大的 API，可以让 Dubbo 通过注册中心来实现服务的发布与订阅。 使用 etcd 作为 Dubbo 的注册中心有以下好处： 1. 可靠性：etcd 的分布式特性和高可用性保证了注册中心的稳定性和可靠性，即使某个节点出现故障，也不会影响整个注册中心的正常运行。 2. 高性能：etcd 的设计和实现使得其能够提供高效的服务注册和发现功能，可以支持大规模的服务治理场景。 3. 灵活性：etcd 支持多种语言的客户端 API，使得使用 Dubbo 的团队可以根据自身的技术栈和偏好选择合适的语言进行开发和集成。 4. 弹性伸缩：etcd 支持数据的强一致性和分布式架构，可以根据应用的负载和规模进行横向扩展，以满足高并发和大规模的服务注册与发现需求。 总的来说，Dubbo 的 etcd 注册中心能够提供可靠、高性能、灵活和弹性伸缩的服务注册和发现功能，为 Dubbo 在分布式环境中的服务治理提供了有力的支持。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值