了解etcd（三）

下面我们了解一下etcd中的压缩机制
在etcd我们可以手动压缩，也可以配置自动压缩机制，自动压缩中支持两种压缩方式，时间周斯性压缩，版本号压缩，压缩在mvcc的compact接口执行压缩，它首先会压缩treeindex模块中的keyindex，然后遍历boltdb中的key,删除已经废弃的key，压缩的本质是回收历史版本，目标对象是历史版本，不会删除最新的数据，etcd提供了两个参数来决定使用那种压缩方式，auto-compaction-mode为periodic表示使用周期性压缩，retention为保留的周期，参数为revision的时候是版本压缩，当使用周斯性压缩的时候，etcd server会创建periodic compactor，它会异步的获取记录过去一段时间的版本号，periodic compactor组件获取你设置的压缩时间参数1h,划分10个区间，每个区间六分钟，每隔6分钟，他会通过etcd mvcc模块的接口获取当前server版本号，追加到rev数组中，时间间隔如果大于1小时它会取出rev数组的首元素周期，发起压缩操作，版本号压缩又是怎么样的呢，etcd启动后会根据你的压缩模式revision，创建revision compactor，revision compactor会根据你设置的保留的版本号数，每隔5分钟定时获取当前server的最大版本号，减去你想保留的历史版本数，然后通过compact接口发起压缩操作，在压缩过程中，compact检查rev是否被压缩过，如果是，返回errcompacted错误，如果rev大于当前etcd server 的最大版本号，返回errfuturerev错误，压缩的本质就是压缩treeindex模块中的各个key的历史版本，已经删除的版本，然后删除boltdb中的废弃的历史版本数据，为什么压缩后db大小不减少呢，当boltdb删除大量的key后，在事务提交后B+tree经过分裂，平衡会释放出若干branch/leaf page页面，然而boltdb并不会将其释放给磁盘，因为调整db大小操作是昂贵的，对性能有很大的影响。

基于raft算法的etcd集群还有可能导致数据不一致，当出现数据不一致的时候可能出现下面的问题，etcd集群出现脑裂，raft日志同步异常，apply模块出现了问题，treeindex子模块会不会出现了bug，有没有可能boltdb出现了极端异常，使用命令 etcdctl endpoints status --cluster -w json｜python -m json.tool 如果集群cluster id一致就表明没有发生脑裂，raftappliedindex相差很小，可能不是raft同步的问题，最好使用wal工具验证一下，然后看看revision的差值是否很大，我们可以在etcd中put一个数据，用etcd-dump-logs工具看看是否三个节点都同步了key，数据不一致最有可能出现在apply模块，版本升级也有可能出现数据不一致的情况，我们开启etcd的数据毁坏检测功能，我们也可以在应用层检测数据不一致，实现巡检功能定时去统计各个节点的key数，统计节点数的时候要加上withcountonly参数，提高性能，还可以基于endpoints各个节点的revision信息做监控，一般情况下差异小，我们可以基于etcd的mvcc的metrics指标来监控，比如mvcc_put_total，我们要定时做好备份数据，一般三十分钟备份一次，重要的业务可以考虑5到10分钟，可以采用etcdoperator中的backup-operator保存到公有云的对象存储服务里面，一定要确保集群各个节点的版本号一致，使用最新版本的etcd

为什么etcd的db大小不建议超过8G，大db首先会影响etcd启动耗时，因为etcd需要打开db文件，初始化db对象，并遍历boltdb中的所有key-value重建内存treeindex，其次较大的db文件会导致etcd依赖更高配置的节点内存规格，etcd通过mmap将db文件映射到内存中，etcd启动后正常情况下读etcd过程？不涉及磁盘IO，若节点内存不够，可能导致缺页中断，引起延时抖动，服务性能下降，当db文件过大后，boltdb本身连续空闲页的申请，释放，存储都会存在一定的开销，db文件过大后，count only,limit,大包查询等expensive request对集群稳定性也有很大影响，db过大对快照也有很大的影响