服务注册中心etcd

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树,而不是红黑树呢?从磁盘B+树中,可以一次copy一页(16k)到内存B树中,插入效率更快;

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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
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、付费专栏及课程。

余额充值