焦作做网站公司,佛山网约车驾驶员资格证网上报名,物流网站建设方案权限管理,网页游戏交易网站ETCD高可用架构涉及常用功能整理 1. etcd的高可用系统架构和相关组件1.1 Quorum机制1.2 Raft协议 2. etcd的核心参数2.1 常规配置2.2 特殊优化配置2.2.1 强行拉起新集群 --force-new-cluster2.2.2 兼容磁盘io性能差2.2.3 etcd存储quota 3. etcd常用命令3.1 常用基础命令3.1.1 列… ETCD高可用架构涉及常用功能整理 1. etcd的高可用系统架构和相关组件1.1 Quorum机制1.2 Raft协议 2. etcd的核心参数2.1 常规配置2.2 特殊优化配置2.2.1 强行拉起新集群 --force-new-cluster2.2.2 兼容磁盘io性能差2.2.3 etcd存储quota 3. etcd常用命令3.1 常用基础命令3.1.1 列出特定前缀的key和value3.1.1 重新设置value3.1.1 删除key 3.2 常用运维命令3.2.1 检查集群member信息3.2.2 检查集群member增加、删除3.2.3 检查节点状态3.2.4 检查集群状态3.2.5 数据备份还原 4. 事务性4.1 数据写流程4.2 数据读流程4.3 MVCC机制4.3.1 并发读写事务的问题4.3.2 锁机制4.3.3 MVCC进行事务隔离4.3.4 etcd中MVCC实现 5. 疑问和思考5.1 etcd不擅长处理哪些场景5.2 etcd和zk有什么异同 6. 参考文档 探讨etcd的系统架构以及以及整体常用的命令和系统分析本文主要探讨高可用版本的etcd集群并基于日常工作中的沉淀进行思考和整理。更多关于分布式系统的架构思考请参考文档关于常见分布式组件高可用设计原理的理解和思考 1. etcd的高可用系统架构和相关组件
etcd在产品设计上面对的存储数据量比较小一台etcd机器就能够满足数据的存储需求因此在集群的架构设计上使用镜像模式进行数据高可用通过Raft 协议进行选举leader从而满足集群的高可用和数据一致性要求。
etcd的系统架构如下
相关核心的组件和角色作用如下
角色数量角色作用备注Leader有且必须只有1个它会发起并维护与各Follwer及Observer间的心跳所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器通过内部选举选择出leaderFollower多个会响应Leader的心跳可直接处理并返回客户端的读请求同时会将写请求转发给Leader处理并且负责在Leader处理写请求时对请求进行投票和Observer统称为LearnerLearner多个作用跟Follow相同但是没有投票权和Follower统称为Learner 1.1 Quorum机制
Quorum机制有效个数模式指分布式系统的每一次修改都要在大多数超过半数实例上通过来确定修改通过。
产生Quorum机制有效个数的背景如下
分布式系统的LC矛盾 在一个分布式存储系统中用户请求会发到一个实例上。通常在一个实例上面执行的修改需要复制到其他的实例上这样可以保证在原实例挂了的情况下用户依然可以看到这个修改。这就涉及到一个问题究竟复制到多少个其他实例上之后用户请求才会返回成功呢如果复制的实例个数过多那么请求响应时间就会更长如果复制的实例过少则这个修改可能会丢失。取得这个平衡性很重要这也是分布式 PACELC 中的 LLatency 与 CConsistency 的取舍。
解决方案 当一个修改被集群中的大部分节点假设个数为N通过之后这个修改也就被这个集群所接受。这个 N 就是有效个数。假设集群数量为 n那么 N n/2 1.例如 n 5则 N 3从而应运而生Quorum机制有效个数
1.2 Raft协议
etcd 集群使用 Raft 协议保障多节点集群状态下的数据一致性。etcd 是使用 Go 语言对 Raft 协议一种实现方式。
在 Raft 体系中有一个强 Leader由它全权负责接收客户端的请求命令并将命令作为日志条目复制给其他服务器在确认安全的时候将日志命令提交执行。当 Leader 故障时会选举产生一个新的 Leader。在强 Leader 的帮助下Raft将一致性问题分解为了三个子问题
Leader 选举当已有的leader故障时必须选出一个新的leader。日志复制leader接受来自客户端的命令记录为日志并复制给集群中的- 其他服务器并强制其他节点的日志与leader保持一致。安全 safety 措施通过一些措施确保系统的安全性如确保所有状态机按照相同顺序执行相同命令的措施。 解这三个子问题的过程保障了数据的一致。
2. etcd的核心参数
2.1 常规配置
etcd常用配置 - --advertise-client-urlshttps://xx.xx.xx.xx:2379- --cert-file/etc/kubernetes/pki/etcd/server.crt- --client-cert-authtrue- --data-dir/data/var/lib/etcd- --initial-advertise-peer-urlshttps://xx.xx.xx.xx:2380# 所有集群节点- --initial-clusterxx.xx.xx.xxhttps://xx.xx.xx.xx:2380,xx.xx.xx.xxhttps://xx.xx.xx.xx:2380,xx.xx.xx.xxhttps://xx.xx.xx.xx:2380,xx.xx.xx.xxhttps://xx.xx.xx.xx:2380,xx.xx.xx.xxhttps://xx.xx.xx.xx:2380- --initial-cluster-statenew- --key-file/etc/kubernetes/pki/etcd/server.key- --listen-client-urlshttps://127.0.0.1:2379,https://xx.xx.xx.xx:2379- --listen-metrics-urlshttp://0.0.0.0:2381- --listen-peer-urlshttps://xx.xx.xx.xx:2380- --namexx.xx.xx.xx- --peer-cert-file/etc/kubernetes/pki/etcd/peer.crt- --peer-client-cert-authtrue- --peer-key-file/etc/kubernetes/pki/etcd/peer.key- --peer-trusted-ca-file/etc/kubernetes/pki/etcd/ca.crt- --snapshot-count10000- --quota-backend-bytes8589934592- --trusted-ca-file/etc/kubernetes/pki/etcd/ca.crt- --cipher-suitesTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA更多参数可以参考文档 etcd 配置标记
2.2 特殊优化配置
2.2.1 强行拉起新集群 --force-new-cluster
强行启动一个etcd集群只有在集群崩溃的应急恢复时使用配合2个参数
–initial-clusterxx.xx.xx.xxhttps://xx.xx.xx.xx:2380只能设置1个节点–initial-cluster-statenew 一起使用可以拉起一个单节点集群。后续通过member add的方式将节点加入集群进行应急恢复具体操作可以参考 ETCD单节点故障应急恢复
2.2.2 兼容磁盘io性能差
如果磁盘的io性能很差etcd集群可能会由于读写过慢导致集群崩溃可以通过调整如下2个参数进行兼容
--heartbeat-interval5000
--election-timeout300002.2.3 etcd存储quota
etcd 默认默认设置了2GB 的存储配额大概能够支撑存储两百万文件的元数据可以通过 --quota-backend-bytes 选项进行调整官方建议不要超过8GB。 当数据量达到配额导致无法写入时可以通过手动压缩 etcdctl compact 和整理碎片 etcdctl defrag 的方式来减少容量。
--quota-backend-bytes85899345923. etcd常用命令
利用etcd安装包中自带的etcdCli.sh命令能够链接到etcd中并进行相关的操作
# 连接本地etcd
./etcdCli.sh# 远程连接etcd
./etcdCli.sh -server xx.xx.xx.xx:21813.1 常用基础命令
整理日常操作etcd常用的命令便于针对etcd的数据操作。由于etcd版本问题目前主流使用的版本都是etcdv2和etcdv3两个版本。通常主流的命令都是使用v3版本在本文中主要介绍v3版本的日常操作
3.1.1 列出特定前缀的key和value
# 列出所有的key
ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 --cacert/etc/kubernetes/pki/etcd/ca.crt --cert/etc/kubernetes/pki/etcd/server.crt --key/etc/kubernetes/pki/etcd/server.key get / --prefix --keys-only# 列出所有的keyvalue
ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 --cacert/etc/kubernetes/pki/etcd/ca.crt --cert/etc/kubernetes/pki/etcd/server.crt --key/etc/kubernetes/pki/etcd/server.key get / --prefix# 列出前缀为/xx的所有key
ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 --cacert/etc/kubernetes/pki/etcd/ca.crt --cert/etc/kubernetes/pki/etcd/server.crt --key/etc/kubernetes/pki/etcd/server.key get /xxx --prefix --keys-only# 列出前缀为xx的所有keyvalue
ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 --cacert/etc/kubernetes/pki/etcd/ca.crt --cert/etc/kubernetes/pki/etcd/server.crt --key/etc/kubernetes/pki/etcd/server.key get /xxx--prefix3.1.1 重新设置value
# 设置对应的key和value
ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 --cacert/etc/kubernetes/pki/etcd/ca.crt --cert/etc/kubernetes/pki/etcd/server.crt --key/etc/kubernetes/pki/etcd/server.key put /xxx xxxx3.1.1 删除key
# 设置对应的key和value
ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 --cacert/etc/kubernetes/pki/etcd/ca.crt --cert/etc/kubernetes/pki/etcd/server.crt --key/etc/kubernetes/pki/etcd/server.key del /xxx3.2 常用运维命令
用于日常运维命令便于进行服务运维提升系统稳定性。
3.2.1 检查集群member信息
ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 --cacert/etc/kubernetes/pki/etcd/ca.crt --cert/etc/kubernetes/pki/etcd/server.crt --key/etc/kubernetes/pki/etcd/server.key --write-outtable member list3.2.2 检查集群member增加、删除
增加节点信息
ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 --cacert/etc/kubernetes/pki/etcd/ca.crt --cert/etc/kubernetes/pki/etcd/server.crt --key/etc/kubernetes/pki/etcd/server.key --write-outtable member add xx.xx.xx.xx --peer-urlshttps://xx.xx.xx.xx:2380删除节点信息
ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 --cacert/etc/kubernetes/pki/etcd/ca.crt --cert/etc/kubernetes/pki/etcd/server.crt --key/etc/kubernetes/pki/etcd/server.key --write-outtable member remove ${memberid}3.2.3 检查节点状态
ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 --cacert/etc/kubernetes/pki/etcd/ca.crt --cert/etc/kubernetes/pki/etcd/server.crt --key/etc/kubernetes/pki/etcd/server.key --write-outtable endpoint health–endpoints 列出所有需要检查的节点
3.2.4 检查集群状态
ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 --cacert/etc/kubernetes/pki/etcd/ca.crt --cert/etc/kubernetes/pki/etcd/server.crt --key/etc/kubernetes/pki/etcd/server.key --write-outtable endpoint status–endpoints 列出所有节点
3.2.5 数据备份还原
备份数据备份的数据不包含节点信息
ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 --cacert/etc/kubernetes/pki/etcd/ca.crt --cert/etc/kubernetes/pki/etcd/server.crt --key/etc/kubernetes/pki/etcd/server.key --write-outtable snapshot save snapshot.db恢复数据并基于恢复的数据启动一个单节点集群
ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 --cacert/etc/kubernetes/pki/etcd/ca.crt --cert/etc/kubernetes/pki/etcd/server.crt --key/etc/kubernetes/pki/etcd/server.key --write-outtable snapshot save snapshot.dbETCDCTL_API3 etcdctl snapshot restore snapshot.db --name xx.xx.xx.xx --initial-cluster xx.xx.xx.xxhttps://xx.xx.xx.xx:2380 --initial-advertise-peer-urls https://xx.xx.xx.xx:2380 --data-dir /data/var/lib/etcd–data-dir 是数据的保存目录跟etcd的启动参数保持一致
4. 事务性
4.1 数据写流程
etcd的数据写流程整体流程如下。
客户端发送写请求通过负载均衡算法选取合适的 etcd 节点发起 gRPC 调用。etcd server 的 gRPC Server 收到这个请求经过 gRPC 拦截器拦截实现 Metrics 统计和日志记录等功能。Quota 模块配额检查 db 的大小如果超过会报etcdserver: mvcc: database space exceeded的告警通过 Raft 日志同步给集群中的节点 db 空间不足同时告警也会持久化到 db 中。etcd 服务端拒绝写入对外提供只读的功能。配额检查通过KVServer 模块经过限速、鉴权、包大小判断之后生成唯一的编号这时才会将写请求封装为提案消息提交给 Raft 模块。写请求的提案只能由 Leader 处理如果客户端链接到Follower会进行路由到Leader获取到 Raft 模块的日志条目之后Leader 会广播提案内容。WAL 模块完成 Raft 日志条目内容封装当集群大多数节点完成日志条目的持久化即将提案的状态变更为已提交可以执行提案内容。Apply 模块用于执行提案首先会判断该提案是否被执行过如果已经执行则直接返回结束未执行过的情况下将会进入 MVCC 模块执行持久化提案内容的操作。MVCC 模块中的 treeIndex 保存了 key 的历史版本号信息treeIndex 使用 B-tree 结构维护了 key 对应的版本信息包含了全局版本号、修改次数等属性。版本号代表着 etcd 中的逻辑时钟启动时默认的版本号为 1。键值对的修改、写入和删除都会使得版本号全局单调递增。写事务在执行时首先根据写入的 key 获取或者更新索引如果不存在该 key则会给予当前最大的 currentRevision 自增得到 revision否则直接根据 key 获取 revision。根据从 treeIndex 中获取到 revision 、修改次数等属性以及 put 请求传递的 key-value 信息作为写入到 boltdb 的 value而将 revision 作为写入到 boltdb 的 key。同时为了读请求能够获取最新的数据etcd 在写入 boltdb 时也会同步数据到 buffer。因此上文介绍 etcd 读请求的过程时会优先从 buffer 中读取读取不到的情况下才会从 boltdb 读取以此来保证一致性和性能。为了提高吞吐量此时提案数据并未提交保存到 db 文件而是由 backend 异步 goroutine 定时将批量事务提交。Server 通过调用网络层接口返回结果给客户端。
总的来说这个过程为客户端发起写请求由 Leader 节点处理经过拦截器、Quota 配额检查之后KVServer 提交一个写请求的提案给 Raft 一致性模块经过 RaftHTTP 网络转发集群中的其他节点半数以上持久化成功日志条目提案的状态将会变成已提交。接着 Apply 通过 MVCC 的 treeIndex、boltdb 执行提案内容成功之后更新状态机。
整体的流程机制上跟zk的类似具体可以参考ZK高可用架构涉及常用功能整理。
4.2 数据读流程
相比写数据流程读数据流程就简单得多因为每台server中数据一致性都一样所以随便访问哪台server读数据就行没有写数据流程中请求转发、数据同步、成功通知这些步骤。
4.3 MVCC机制
4.3.1 并发读写事务的问题
我们知道数据库并发场景有三种分别为读-读、读-写和写-写。 读-读没有问题不存在线程安全问题因此不需要并发控制 读-写和写-写都存在线程安全问题读-写可能遇到脏读幻读不可重复读写-写可能会存在更新丢失问题。 脏读读取未提交数据无效数据的读出是指在数据库访问中事务T1将某一值修改然后事务T2读取该值此后T1因为某种原因撤销对该值的修改这就导致了T2所读取到的数据是无效的。值得注意的是脏读一般是针对于update操作的通常解决的方式是使用行级锁。 不可重复读前后多次读取数据内容不一致事务A在执行读取操作由整个事务A比较大前后读取同一条数据需要经历很长的时间 。而在事务A第一次读取数据比如此时读取了小明的年龄为20岁事务B执行更改操作将小明的年龄更改为30岁此时事务A第二次读取到小明的年龄时发现其年龄是30岁和之前的数据不一样了也就是数据不重复了系统不可以读取到重复的数据成为不可重复读。值得注意的是不可重复读一般是针对于update操作的通常解决的方式是使用行级锁。 幻读前后多次读取数据总量不一致事务A在执行读取操作需要两次统计数据的总量前一次查询数据总量后此时事务B执行了新增数据的操作并提交后这个时候事务A读取的数据总量和之前统计的不一样就像产生了幻觉一样平白无故的多了几条数据成为幻读。值得注意的是幻读一般是针对于针对insert和delete操作通常解决的方式是使用表级锁。
总结下来这3种并发控制的问题都是事务A执行更新操作时事务B内多次读的结果不一致从而导致违背了事务的ACID原则。
4.3.2 锁机制
为了解决如上问题通常是通过锁机制实现常用的是悲观锁和乐观锁 悲观锁和乐观锁。 悲观锁 为了保证事务的隔离性就需要一致性锁定读。读取数据时给加锁其它事务无法修改这些数据。修改删除数据时也要加锁其它事务无法读取这些数据。 乐观锁相对悲观锁而言乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销特别是对长事务而言这样的开销往往无法承受。乐观锁大多是基于数据版本 Version 记录机制实现。
MVCC是一种乐观锁
4.3.3 MVCC进行事务隔离
曾经也一度困恼我MVCC为什么能够解决这个问题MVCC使用多版本记录数据值但是如果读事务需要读取最新的数据时通过MVCC也不是不能解决在一次读事务中多次读的不一致问题吗
没错如果一个读事务一定要求多次读都必须读取到最新的数据MVCC地区不能解决这个问题因为这不是MVCC能够作用的范围
后来我重新学习和理解了事务的ACID原则具体的内容如下
ACID是指数据库管理系统DBMS在写入或更新资料的过程中为保证交易transaction是正确可靠的所必须具备的四个特性原子性atomicity或称不可分割性、一致性consistency、隔离性isolation又称独立性、持久性durability。
这里并没有提到读取的数据一定是最新的只是要求一个读事务每次的结果都是可靠正确的所以这就是MVCC的作用范围。读事务只需要读取到已经提交的历史最新版本即可以保证事务的ACID
事实上在MySQL中MVCC只在REPEATABLE READ和READ COMMITTED两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容因为READ UNCOMMITTED总是读取最新的数据行而不是符合当前事务版本的数据行而SERIALIZABLE会对所有读取到的行都加锁。etcd的实现有些差异但是整体上是一致的etcd中没有mysql这样复杂的事务选择因此能够通过MVCC解决读写并发的问题。
参考mysql的mvcc事务并发过程如下 假设当前有个正在执行事务99数据行的历史版本为事务id901,1。
按照事务的开启时间分别递增分配了100,101,102三个事务IDtrx id在SQL语句执行之前事务A生成一致性视图【99,100】事务B生成一致性视图【99,100,101】事务C生成一致性视图【99,100,101,102】SQL语句的执行之前生成undo log通过undo log可以生成历史版本数据快照上图右侧历史版本数据。事务A的查询执行时当前数据版本为trx id:101跟一致性视图【99,100】进行比较101大于高水位不可见通过undo log回退到trx id:102版本102也大于高水位不可见再回退一个版本到trx id:9090低于低水位可见所以事务A读取到的数据为1.1。
4.3.4 etcd中MVCC实现
这里不再赘述可以参考 MVCC 在 etcd 中的实现
5. 疑问和思考
5.1 etcd不擅长处理哪些场景
etcd擅长处理kv小量数据v一般不能超过1M基于etcd进行分布式锁、选主、服务发现等均有比较好的应用和实践。但是etcd不擅长处理大量数据的存储通常需要注意不能在etcd路径下写入过多数据。事实上etcd的官方建议默认配置的是2G的Quotao最大不能超过8G的数据存储。
5.2 etcd和zk有什么异同
说实话etcd和zk这两款产品实在太雷同了基本上两者面对的使用场景基本上都是一致的因此两个产品在是线上其实非常贴近。差异是etcd更贴近容器平台zk更贴近大数据平台。其他的差别并太大从使用方的角度来看差别并不太大。值得一提的是zk的对运维同学的友好度要比etcd友好一些节点增加、剔除等步骤要简单很多。
6. 参考文档
etcd 配置标记MVCC 在 etcd 中的实现etcd官方文档
