网站大量收购闲置独家精品文档,联系QQ:2885784924

分布式XMPPServer.ppt

  1. 1、本文档共32页,可阅读全部内容。
  2. 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
分布式 XMPP Server CN Erlounge III, Shanghai Tim Google talk: iso1600[at] Blog: /jabber Agenda XMPP简介及适合场合 分布式实现 与 Web, Mobile 结合 XMPP简介 开放的IM标准协议 Jeremie Miller 于1999 January the 4th, 把一种新的开放的IM协议取名Jabber the IETF accepted XMPP-related RFCs as Internet Drafts on 2004 october the 4th, 目前业界逐渐转向新名称 XMPP 优势 完整的开源产品线 Server Jabberd, ejabberd, openfire… Client Pidgin, Spark, Exodus, iChat Library Libjingle(c++), gloox(c++), smack(java), XIFF(flash), xmpp4r(ruby), xmpppy(python), agsxmpp(.net), xmpphp(php) and much more. 压力测试工具(Tsung, Java XMPP Test Client) XMPP适合新项目优势 无需投入成本制定协议 易于扩展 可迅速完成原型 适合各种容量系统,从100用户在线的系统到100万以上在线用户。 可扩展至 Web/Flash IM, Mobile IM 等各种场合,基本都有开源实现或Library。 PubSub与Microblogging RESTful API的流行及问题, twitter XMPP代替HTTP Pooling的趋势 OSCON day 1: Beyond REST? Building Data Services with XMPP PubSub /2008/07/oscon-day-1-beyond-rest-buildi.html Is XMPP the Future of Cloud Services? /news/2008/01/xmpp XMPP包含极其丰富的扩展 头像 (vCard-Based Avatars 目前广泛采用) 表情 正在输入信息 User Mood(XEP-0080, 个性签名), GeoLocation(XEP-0080), User Activity(XEP-108,如发表了一篇博文等), User Tune(XEP-118, 正在听音乐) 文件传输、语音、视频 (Stream Initiation, jingle) 更多 (/extensions/ ) XMPP 实现 Auth: SASL/TLS Bind resource Roster subscription Presence Message IQ S2S XEP XMPP bot Client bot 实现简便 不便实现大规模服务 Component bot 作为Component注册到主服务器,可以实现round robin load balance,可以实现大规模的服务 rabbiter S2S bot 可支持多服务器和负载均衡 但需增加额外的XMPP协议栈实现 Agenda XMPP简介及适合场合 分布式实现 与 Web, Mobile 结合 模型 大型XMPP Server面临的主要问题 大型XMPP服务器 指在线用户大于100万,用单台服务器无法满足运营需求。 面临的主要问题: 连接数, 100万以上面临的问题 内存, 逻辑服务器的主要瓶颈之一 Presence Message db 状态 状态: XMPP presence, 即online/away/busy… 集群系统的瓶颈,处理量是:O(平均好友数 * 在线用户峰值 * 变化频率) msg / sec 如 50 * 1000000 / 300 = 166,666 / s 面临的主要问题 – 状态 广播:每一个presence都需要投递给所有的服务器,很难优化或者做类似分区分片处理。 系统需要按峰值容量来设计。 突然大量的登录 特殊事件-大量的用户同时改变昵称或者心情签名 需要主动推送给好友,每一个presence需要引发几十台服务器做逻辑处理。 解决状态服务器的几种思路 不适合使用db来存放 使用Multicast, 只需发送一份,可跨机房 实现一个快速的pubsub模型 基于好友系统的快速PubSub Presence pubsub publish topic (可理解改变在线状态)生命周期可能极短,调用一次就结束(用户在本节点无好友在线);也可能很长 publish 数据实时广播即可,无需保存等

您可能关注的文档

文档评论(0)

wuyoujun92 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档