系统性能调优必知必会
陶辉
智链达 CTO,前阿里云 P8 高级技术专家
36367 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 47 讲
系统性能调优必知必会
15
15
1.0x
00:00/00:00
登录|注册

26 | 应用层多播:如何快速地分发内容?

应用
工作原理
优势
工作原理
控制分发策略
提高传输带宽
避免流量打爆
无需改变组网环境
引入功能复杂的主机
传输路径变长
网络效率下降
应用层多播
网络层多播
传统单播协议
产业协作上的难点
市场上的问题
管理上的困难
功能上的缺失
未来多播协议的发展
Gossip协议
蜻蜓
应用层多播的优点
应用层多播的缺点
文件分发场景
IP多播功能的问题
思考题
实例
优缺点
应用
问题
应用层多播

该思维导图由 AI 生成,仅供参考

你好,我是陶辉。
[第 7 讲] 我们曾介绍了网络层的 IP 协议是如何支持多播的,这节课我们再来从应用层看看如何实现多播功能。
当你的分布式集群只有十多个节点时,每次发布版本时,尽可以从发布服务器,将新版本的安装包通过 ftp、scp、wget 等工具分发到各个节点中。可是,一旦集群规模达到成千上万个节点时,再这么做就会带来很大的问题,文件分发的时长高达几个小时,甚至会打挂文件源终止分发流程。在微服务环境中这点尤为明显, 毕竟每个 Docker 镜象的体积动辄就在数百兆字节以上。
虽然网络层的 IP 协议允许通过路由器、交换机实现高效的多播,但 IP 层很难实现文件的可靠传输,而且跨越多个局域网时路由器等网络设备对 IP 多播的支持也不好。此时,通过应用层的接力传播,就能通过多播思想大幅提升系统的传输效率,解决上述问题。
除了分发文件场景外,应用层多播协议也常用于完全去中心化的分布式系统,特别是在管理成千上万个节点的状态时非常有用。比如 Gossip 就是这样一个多播协议,[第 22 讲] 介绍过的 Cassandra 数据库使用它来同步节点间的状态,比特币通过它传输账本数据,Redis 集群也使用它同步 Redis 进程间的状态。
那么这节课我们就重点介绍应用层中的多播协议,并以阿里的蜻蜓、Cassandra 中的 Gossip 协议为例,看看它们的工作原理。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

应用层多播协议是解决大规模集群文件分发和状态同步的有效方式。相比网络层IP多播,应用层多播避免了质量控制、可靠性传输等问题,同时无需改变组网环境和管理组播IP地址。在大规模集群下,应用层多播能避免单一发布源被流量打爆的问题,提高传输带宽,控制分发策略,减少高成本网络的数据传输量,提升经济性。尽管相对于IP多播,应用层多播存在一定的缺点,但在实际应用中,其优势随着集群规模的增大而凸显。文章还介绍了应用层多播的工作原理,并以阿里的蜻蜓、Cassandra中的Gossip协议为例,展示了多播协议的实现与应用。 应用层多播协议通过在分布式集群中实现节点间的接力转发,提升传输效率。阿里的蜻蜓通过中心化的集群服务节点和dfget进程实现文件分发,避免了传统方式下分发客户端增多导致的总分发时长增加的问题。另外,去中心化的Gossip协议通过节点间的有限传输实现数据同步,被广泛应用于大规模分布式集群中的节点状态同步。 未来,随着5G设备层的组网完成和基础协议层的重构,类似华为NewIP的基础协议层将在VPN逻辑链路层实现IPv4无法在公网中推广的多播功能。这将为未来多播协议的发展带来新的机遇和挑战,为读者提供了一个思考的话题。 总之,应用层多播协议在提升传输效率、避免单一发布源被流量打爆等方面具有显著优势,而未来的发展趋势将受到新技术和协议的影响,为多播协议的应用和实现带来新的可能性。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《系统性能调优必知必会》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(6)

  • 最新
  • 精选
  • wjsay
    好文章,我可算明白了P5协议论文中为何一会儿说网络拓扑是单播的一会儿又说是多播的。原来是IP层单播,应用层多播。如上所说“应用层多播主要是指一种P2P(Peer to Peer)网络传输思想”

    作者回复: ^_^

    2020-11-02
    1
  • 骨汤鸡蛋面
    老师,我在公司负责落地容器化。公司测试环境内网拉一次镜像要1分钟以上(java项目镜像,一般war包100M+)。基础镜像早就缓存好了,因为测试环境build频繁,镜像的war包那一层每次要重新拉取。从您介绍的Dragonfly的原来看,Dragonfly只是降低镜像仓库的下行压力, 对减少镜像war包的拉取速度应该帮助不大吧?

    作者回复: Dragonfly主要是解决1对多分发时导致的问题,从你的描述我没看明白。如果不属于1对多分发导致的问题,那需要从网络、多线程下载、缓存的优化做起了。

    2020-07-13
    2
    1
  • rfyiamcool
    好文章,我们以前那个周期就会把几个G的区块打包文件传输到三百台服务器,通过封装bt实现的。😄
    2020-08-21
    4
  • trllllllll
    原来p2p就是应用层多播
    2022-06-21
  • 程序员老王
    在完全去中心化的分布式集群中,每个节点都没有准确的全局信息,此时可以使用 Gossip 流言协议,通过仅向有限的相邻节点发送消息,完成整个集群的数据同步,实现最终一致性。因此,Gossip 协议常用于大规模分布集群中的节点状态同步。
    2021-07-08
  • Ken
    SuperNode利用Zookeeper能分布式后就不是中央结点了吧?
    2020-07-15
收起评论
显示
设置
留言
6
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部