58同城Webim实现与优化.PDFVIP

58同城Webim实现与优化 沈剑 shenjian@58.com 关于我-58沈剑  前百度-高级工程师  58同城-高级架构师  58同城-技术委员会执行主席  58同城-技术学院优秀讲师  58同城-业界技术分享嘉宾  58同城-C2C技术部负责人  58同城-程序员一枚 关于58im及Webim-58帮帮  日请求量：十亿级别（哪些请求量最大？）  数据库量：亿级别  日消息量：千万级别  同时在线：百万级别  机器数量：50左右 目录-58Webim实现与优化  Webim实现难点  Webim架构简介  Webim如何实现消息推送  58Webim消息实时性优化  58Webim消息可达性优化 （1 ）个人消息 （2 ）离线消息 （3 ）群消息  58Webim状态一致性优化  58Webim匿名聊天不熟客识别  58Webim多TAB同步优化 一、Webim难点  基于推送的系统  消息实时性  消息可达性  状态一致性  匿名登录，熟客识别  多TAB同步 二、Webim架构简述  Web接入层  逻辑处理层  消息路由层 （哪里和传统系统架构丌一样？）  数据存储层 三、Webim如何实现消息推送  WebSocket  FlashSocket  Http长轮询 （今天重点讲解） 四、58Webim消息实时性优化  WebSocket ，FlashSocket实时  为什么人们会误解Http长轮询丌实时？ （1 ）什么是轮询？ （2 ）轮询存在什么问题？ （3 ）缩短轮询时间能否解决时延问题？  什么是真正的Http长轮询？  什么是消息连接？  特性一：夯住  特性二：超时后再起发起 四、58Webim消息实时性优化  特性三：消息到达，实时返回，再次发起  特性四：无连接则入消息池，有连接后实时返回，再次发起 四、58Webim消息实时性优化  结论 （1 ）webim的实时性不是通过缩短轮询时间来保证的 （2 ）webim的实时性是通过夯住http消息连接来保证的 五、58Webim消息可达性优化（单人聊天）  Webim是基于通知的系统，3种报文类型  普通消息投递流程  存在的问题？ （1 ）发送方收到msg:R包丌代表接收方收到消息 （2 ）msg:N包有可能丢失 五、58Webim消息可达性优化（单人聊天）  58Webim消息可达性优化  优化一：应用层ACK保证可达性  核心技术：一条消息发送的6个请求  存在的问题？ （1 ）msg:N包可能丢失？ （2 ）ack:N包可能丢失？ 五、58Webim消息可达性优化（单人聊天）  没有收到ack:N意味着什么？  优化二：发送方等待ack队列，ack超时时消息重传  “因为网络原因，消息发送失败”意味着什么？  超时不重传存在的问题？  存在的问题？ （1 ）消息的重复 （2 ）目标用户丌在线ack怎么办？  优化三：接收方去重 五、58Webim消息可达性优化（单人聊天）  总结 （1 ）im系统是通过超时、重传、应用层确认、去重的机制来保证消息的可靠投递，丌丢丌重 （2 ）im系统的消息丌重复，只是业务层的丌重复，系统层的丌可能丌重复 （3 ）切记，一个“你好”的发送，包含上半场msg:R/A/N不下半场ack:R/A/N的6个报文 五、58Webim消息可达性优化（离线消息）  离线消息拉取的过程：返回并删除离线消息  存在的问题？ （1 ）离线消息返回过程中丢包  优化方案：增加应用层拉取离线消息的ack  新的问题？ （1 ）拉取离线消息的ack丢失，会拉取到重复的离线消息  优化方案：业务层离线消息去重  结论：通过应用层ack和应用层去重保证离线消息拉取的可达性 五、58Webim消息可达性优化（群聊天）  什么是群聊？1 - N  群聊的难点？ （1 ）能直接应用层ack么？ （2 ）能让发送方重发么？ （3 ）能让服务器重发么？服务器需要记录状态么？  群聊如何保证可达性，两种方案： （1 ）基于登录时间 （2 ）基于ack ，并降低ack频率 （2.1 ）基于时间降频 （2.2 ）基于消息条数降频