ETCD的一些机制

ETCD已经用了挺久了，之前主要用到了它的Watch机制，觉得不错。订阅模型比轮询模型编程实现更方便。

树形存储结构也很方便，现实中很多东西就是用目录存储的，比如用户和资源，这种存储设计方式跟ldap的树形有些类似。

最近读了些文章，发现ETCD还有不少特性我没有利用起来，也不明白其中原理。

首先是它的Lease机制，ETCD的一个KV值，可以与一个租约对象关联，租约到期后服务器将kv删除。租约通过keepalive机制实现续约保活。

这样一套机制，很适于处理一些与时间和保活相关的任务，比如服务发现中服务状态的监控。服务异常时无法发送keepalive，租约到期关联的key值被删除，再由watch机制通知到client。完成client对服务异常的感知。

然后是ETCD的事务机制，事务通常是关系型数据库才能见到的东西，nosql数据库中实现事务的很少。

事务的作用，主要是保证一组操作的原子性，一致性，隔离性，持久性 这四种特性，即ACID。事务在编程中是非常实用的，常用C/C++的人都知道并发编程中锁的问题是多么 让人头疼，事务就是把加锁操作封装在在数据库操作内部。使得使用者不必自己去处理繁琐的并发细节，就可以安全的并发操作数据。

ETCD也实现了事务操作，可以使用txn原子执行一组etcd操作。不过ETCD的txn与传统数据库事务机制有所不同。它是基于CAS的非阻塞的，可能失败，需要客户端自己实现失败重试。而关系数据库的txn是基于锁进行阻塞的，如果已经有另一个客户端在访问数据，会阻塞当前操作。直到操作可以执行，使用者无需自己实现失败重试。

最后是ETCD的高可用机制，很早就知道ETCD使用raft算法实现高可用和高一致性。也知道要实现ETCD高可用集群至少需要三台机器。但是为什么是三台？raft比主备模型好在哪里？

原因要从分布式领域的CAP理论说起，通俗点说，就是两台机器在网络故障时，无法兼得高一致性和高可用性。而raft算法通过一种多副本状态机机制，可以实现半数节点故障时的高一致性和高可用性。raft算法依赖一种多数投票机制，两台无法满足这一机制。

还有数据版本管理机制等不再展开。

与Redis的对比

首先是应用场景，得益于其强一致性和高可用性，etcd多用在服务发现和集群配置同步方面，也可实现同步式锁。比如kubernetes的配置存储和服务状态发现。而Redis则有所不同，它的优势在于丰富的数据类型与操作以及高效的读写速度。主要用在分布式缓存领域。 总的来说，一个是稳，一个是快。

而两者也有些相同点，首先两者都是noSQL，不支持SQL和索引等机制。但kv存储胜在简单直接。第二，两者都实现了kV存储的TTL机制，使得数据有时效性。第三，两者都支持订阅发布机制，适用于分布式领域。在高并发访问服务领域，集群和分布式是必然选择，所以这两者也大行其道。