qq_39225271的博客

如下的所有运维管理都是在操作etcd的存储空间，存储空间的配额用于控制etcd数据空间的大小，如果etcd的节点磁盘空间不足了，配额会触发告警，然后etcd系统将进入操作受限的维护模式。etcd集群对于磁盘I/O的延时非常敏感，因为etcd必须持久化它的日志，当其他IO密集型的进行也在占用磁盘IO的带宽时，会导致fsync延时非常高。etcd网关监听一个固定的本地地址，每个应用程序都与它的本地etcd网关相连，这样只有etcd网关需要更新其后端服务器列表，对应用来说，后端服务器端的更新是透明的。

如果不希望未授权就获取或修改etcd的数据，那么guest角色可以被持有root角色的用户在任何时间进行修改，撤销甚至删除该角色，以减少未经授权的用户的能力。在etcd中，角色主要分为三类：root角色，guest角色和普通角色。root角色具有对所有键值资源的完整权限，而且只有root角色具有管理用户资源和配置资源的权限，root角色是内置的，不需要被创建而且不能被篡改，但是可以授予任务用户相同的权限。root角色，默认创建root用户即创建了root角色，并为其绑定了该角色，该角色拥有所有权限；

v2是一个key-value数据库，只保存key的最新的value，之前的value直接覆盖，但是会维护1000个所有key的变更记录，如果在短时间频繁写操作，那么变更记录会很快超过1000，如果watch过慢就会无法得到之前的变更，带来后果就是watch丢失事件。v2 是在每个key上设置TTL，v3是租约机制，然后key绑定租约，如果需要更新key的过期时间，可以直接更新租约（lease），多个key绑定到一个租约上，需要更新每个key的过期时间时，v3减少了客户端请求数量。

现代键值（Key - Value）存储系统，ZooKeeper是历史最悠久的项目，起源于Hadoop。这里ETCD与Zk对比。ETCD相比与ZK，更加简单，安装部署和使用更加容易，etcd的某些功能是ZK没有的。etcd更加稳定可靠在服务发现的实现上，etcd使用的是节点租约，并支持多group；而zk使用的是临时节点，临时节点存在很多问题etcd支持稳定的watchetcd支持MVCC（多版本并发控制），因为有协同系统需要无锁操作。

但是在分布式系统内，实际上P是必然的，如果不选P，一旦发生分区错误，整个分布式系统完全无法使用了，这是不符合需要的，所以对于分布式系统，我们只能考虑当分区发生错误时，如果选择一致性和可用性。所以最后只有CP和AP系统了。