etcdraft vs kafka

db大小会对那些方面造成影响:

treeIndex模块维护了用户key与boltdb key的映射关系,boltdb的key、value有包含了构建treeIndex的所需的数据,etcd启动的时候,会启动不同角色的

goroutine并完成treeIndex构建。

遍历boltdb获取所有key-value的数据,并将其反序列化成etcd的mvccpbKeyValue结构。核心原理是基于etcd存储在boltdb中的key数据有序性,按版本号

从1开始批量遍历,每次查询1000条key-value记录,直到查询数据为空。

从主goroutine获取mvccpbKeyValue数据,基于key、版本号、是否带删除表示等信息,构建keyIndex对象,插入到treeIndex模块的B-tree中。

etcd启动时只有一个构建treeIndex的goroutine。

etcd启动时,调用boltdb Open API的时候,设置了mmap的MAP_POPULATE flag,告诉内核预读文件,将db文件内容全部从磁盘加载到物理内存中

(通过mmap机制将db文件映射到内存中)。如果节点内存小于treeIndex内存之和,会触发缺页中断,导致读延时抖动、QPS下降。

boltdb事务提交的四个核心流程:B+ tree的重平衡、分裂,持久化dirty page、持久化freelist以及持久化meta data。

事务提交延时抖动的原因主要是在B+Tree树的重平衡和分裂过程中,需要从freeList中申请若干连续的page存储数据,或者释放空闲个的freelist。

freeList后端实现在boltdb中是array。如果db文件较大,又存在大量的碎片空闲页,很可能导致超时。同时事务提交过程中,也可能会释放若干个page给

freelist,因此需要合并到freelist的数组中,此 *** 作时间复杂度是O(NlogN)。为了优化boltdb事务提交的性能,etcd实现了基于HashMap来管理freelist。

通过引入三个map数据结构(freemaps的key是连续的页数, value是以空闲页的起始页pgid集合,forwardmap和backmap用于释放的时候快速合并页),

将申请和释放时间复杂度降低到O(1),同时支持事务提交时,不持久化freelist,而是通过重启时扫描page重建,以提升etcd写性能、降低db大小。

那些expensive read请求会导致etcd不稳定性:

快照会影响db备份文件生成速度、Leader发送快照给Follower节点的资源开销、Follower节点通过快照重建恢复的速度。

以上就是关于etcdraft vs kafka全部的内容，包括:etcdraft vs kafka、(一) etcd3-server-API、Raft在etcd中的实现（二）节点发送消息和接收消息流程等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！