dragonfly 1.0.5 架构学习

dragonfly 1.0.5 架构学习

2.1 学习之前的认知困惑

dragonfly 使用的基于http p2p是如何实现的

  • 主要是文件的如何进行分割的?
  • supernode 的数据是否有重复?
  • 最终下载完毕了合并流程是什么样的。

supernode 在面临突发大流量请求是如何调度的。

比如 A,B,C 同时请求到supernode1上,这时supernode 没有数据源,需要回源请求。最终是同时给A,B,C 是三个实例下发,还是先下发给A,然后B,C 去A拉取。

答案:supernode会进行调度优化,只会给前N个peer进行CDN下载,下载完后进行做种,防止所有的beeget客户端同时下载,失去p2p的意义

supernode 的高可用

答案:目前supernode 的元数据并没有做集群存储,都是分别存储在各自内存map 维护。当一台实例出现故障,目前是通过一致性哈希来取下一台,会增加最大双倍的分发延迟。

2.2 dragonfly 的整体逻辑

2.3 dragonfly的缺点

supernode 在大流量中会是一个瓶颈,并且没有看到高可用方案

在小文件分发中,频繁调度会增加延迟。

2.3.1 kraken 对dragonfly的评价

Dragonfly cluster has one or a few “supernodes” that coordinates the transfer of every 4MB chunk of data in the cluster.

While the supernode would be able to make optimal decisions, the throughput of the whole cluster is limited by the processing power of one or a few hosts, and the performance would degrade linearly as either blob size or cluster size increases.

Kraken’s tracker only helps orchestrate the connection graph and leaves the negotiation of actual data transfer to individual peers, so Kraken scales better with large blobs. On top of that, Kraken is HA and supports cross-cluster replication, both are required for a reliable hybrid cloud setup.

This entry was posted in 云原生. Bookmark the permalink.

发表评论