网页桌面共享短连接 cdn p2p zookeeper

最新推荐文章于 2023-01-15 15:24:12 发布

Super_Anna

最新推荐文章于 2023-01-15 15:24:12 发布

阅读量1.2k

点赞数

分类专栏：文艺青年

本文链接：https://blog.csdn.net/super_anna/article/details/52335792

版权

文艺青年专栏收录该内容

1 篇文章 0 订阅

订阅专栏

http://collabedit.com/tgaa2

使用collabedit引发的思考。

1.为啥链接这么短？
2.浏览器，http协议为什么不能够进行长连接那么怎么做到桌面共享？
3.数据的持久化。

短连接

短链接，通俗来说，就是将长的URL网址，通过程序计算等方式，转换为简短的网址字符串。
1.为啥要用短连接，链接很短只能代表一定量的数据量，是否能够容纳下所有的数据量
2.怎么实现生成短连接

长的url首先会占用一定的字数（比如微博规定的输入字数为140 ，带长的url占用太多的字数并不合理，这样用户发微博信息的字数就会变少），所以要变为短连接。并且对于链接定时失效。
可以采用hash的方式来得到，又因为hash是一个不可逆的过程，所以可能会把相应的数据 hash对应的真正网址持久化，并且会定期删除（保证不占用那么多的数据量）。（我的猜想：对于不具有特殊信息的）

桌面共享？

浏览器，http协议为什么不能够进行长连接那么怎么做到桌面共享？
1.A修改了桌面内容，B就能及时收到桌面信息。但由于AB之间不能建立长连接，那B怎么收到A的内容？
2.采用长轮询的机制，A改动信息，就相当于发送一次post请求到服务器，放到消息队列当中，B不断向服务器发送请求信息，服务器hold住请求，直到消息队列当中有消息可以消费。（类似于metaq采用长轮询的pull方式达到和notify的push模式相同的实时性）

直播平台引发的思考

主播推流（通过cdn进行分发）–服务器端处理–客户端拉流

cdn

CDN的全称是Content Delivery Network，即内容分发网络。CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。

一般的CDN的基本功能是将全网IP分为若干个IP段组，分组的依据通常是运营商或者地域，目的是让相同网络环境中的用户聚集到相同的组内，然后再依据CDN服务器们的网络和容量，确定哪些CDN服务器适合服务哪些IP段组，再让用户去匹配适合他的服务器得到服务。说白了，就是根据用户不同的来源 IP把用户请求重定向到不同的CDN服务器上去。

PeerToPeer

各个看直播的客户端之间可以说是对等的，可以相互之间提供服务。从服务器端（cdn服务器拿到第一份数据），可以与其他节点共享，减少主服务器的压力，利用起来空闲节点的计算能力存储空间，负载均衡。

“Peer”在英语里有“对等者”和“伙伴”的意义。P2P可以理解为对等互联网。国内的媒体一般将P2P翻译成“点对点”或者“端对端”，学术界则统一称为对等计算。P2P可以定义为：网络的参与者共享他们所拥有的一部分硬件资源（处理能力、存储能力、网络连接能力、打印机等），这些共享资源通过网络提供服务和内容，能被其它对等节点(Peer)直接访问而无需经过中间实体。在此网络中的参与者既是资源（服务和内容）提供者（Server），又是资源获取者（Client）。

P2P打破了传统的Client/Server (C/S)模式，在网络中的每个结点的地位都是对等的。每个结点既充当服务器，为其他结点提供服务，同时也享用其他结点提供的服务。

P2P详解

聊天互动礼物平台（弹幕，聊天，礼物）

聊天室和群聊功能类似，但聊天室的消息是不需要分发给不在线的用户的，历史消息也不需要查看，用户只有进入聊天室后才能查看聊天消息和群成员信息。面对复杂多变的网络状况，还需要根据用户位置就近选择近对应运营商的单线机房接入弹幕消息服务，让弹幕更及时。

zookeeper

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

zookeeper实现mastersalve选举业务

使用场景：

有一个向外提供的服务，，机器在线率（24小时在线）有较高要求的场景，能够快速对集群中机器变化作出响应，不能有单点故障。所以采用集群的方式，采用master、slave的结构。一台主机多台备机。主机向外提供服务，备机负责监听主机的状态，一旦主机宕机，备机要迅速接代主机继续向外提供服务。从备机选择一台作为主机，就是master选举。

实现原理：

这样的场景中，往往有一个监控系统，实时检测集群机器是否存活。
ZooKeeper有两个特性（读可监控，临时节点），就可以实现一种集群机器存活性监控系统：
1. 客户端在节点 x 上注册一个Watcher，都会订阅zookeeper中master节点的删除事件。那么如果x的子节点变化了，会通知该客户端。
2. 创建EPHEMERAL类型的节点，（保存自己的基本信息），以便于应用程序读取当前可用的服务器列表（如过master挂了选择）。一旦客户端和服务器的会话结束或过期，那么该节点就会消失。

利用这两个特性，可以分别实现对客服端的状态变化、上下线进行监控。
例如，监控系统在 /Monitor 节点上注册一个Watcher，以后每动态加机器，那么就往 /Monitor 下创建一个 EPHEMERAL类型的节点：/Monitor/{hostname}. 这样，监控系统就能够实时知道机器的增减情况，至于后续处理就是监控系统的业务了。

选主原理

　　zookeeper的节点有两种类型，持久节点跟临时节点。临时节点有个特性，就是如果注册这个节点的机器失去连接(通常是宕机)，那么这个节点会被zookeeper删除。选主过程就是利用这个特性，在服务器启动的时候，去zookeeper特定的一个目录下注册一个临时节点(这个节点作为master，谁注册了这个节点谁就是master)，注册的时候，如果发现该节点已经存在，则说明已经有别的服务器注册了(也就是有别的服务器已经抢主成功)，那么当前服务器只能放弃抢主，作为从机存在。同时，抢主失败的当前服务器需要订阅该临时节点的删除事件，以便该节点删除时(也就是注册该节点的服务器宕机了或者网络断了之类的)进行再次抢主操作。从机具体需要去哪里注册服务器列表的临时节点，节点保存什么信息，根据具体的业务不同自行约定。选主的过程，其实就是简单的争抢在zookeeper注册临时节点的操作，谁注册了约定的临时节点，谁就是master。
zookeeper流程图