专栏首页Java帮帮-微信公众号-技术文章全总结研究微信即时通讯的服务端、朋友圈、红包、推送等方案

研究微信即时通讯的服务端、朋友圈、红包、推送等方案

即时通信:前端获得消息发送到服务端,服务端处理后通过推送的方式,给到接收方;Android使用长连机制,联通网络长连十几分钟,电信仅五六分钟,因此需要根据测试的芯片类型,为了保活,可能要三四分钟就要去连一次,叫心跳机制;IOS通过APN机制推送。即时通讯是在一种平等、开放情况下的互动,这点很重要。

推送:采用增量推送的方式,设置一个sequence,服务端一个客户端一个,每次同步时客户端将cur_seq发给服务端,获得增量数据同步到本地。每个seq都是long型占8byte,考虑到微信用户6亿,Qps达到千万级别,则每秒要处理100兆的IO,相对来说比较大,如何降低呢,微信有一个AllocSvr和StoreSvr两个服务,分别来处理分配和存储,设计一个max_Seq和步长,将一定数量的用户比如连续ID一万个,设计在同一个Section,加上一个max_Seq,步长设为10000,此时可以10^3个等级的数据量,相对AllocSvr处理就简单一些,所以任何一个简单的事情在海量数据下,都会变成一个复杂的问题。另外添加步长,就涉及Old AllocSvr和New AllocSvr,需要根据已知配置文件,有哪些服务器可以切换,考虑到容灾还要做备份服务器,因此做互为备份是服务器能力不浪费的优秀设计;路由的切换也是根据seq的方式,使用路由表来切换的。

红包:活动前将资源通过消息的方式同步到客户端,防止活动当天同步资源造成浪费。每十万级的红包放一个包裹,加入票据,争取更多的资金能够进来,将分配规则写入客户端,然后将红包写入用户,异步对账后同步到账户里;要避免1、不存在的红包分配给用户2、红包分配金额有误 3、红包发给不存在的人 4、红包重复发给一个人 5、红包重复发给其他人6、防止黑客攻击,每个包裹写一个公私钥,同时可以手工屏蔽某些密钥对,保证其中一对密钥被盗,其他仍然可以正常使用。以及采用qos将请求主动失败,分两种系统失败可以重试,逻辑失败则失败 ;由于对大广告主如5000万以上的做过系统配合,但也要在参与用户少的时候,保证用户抢红包的流畅性,进行降低处理。

Android:刚开始业务为主,随着业务量增大,逐渐改为功能为主,然后规划多个dex,甚至将相应服务新开进程执行;秉承用户体验的观点,复杂的逻辑一般放在服务端做,客户端仅做展示功能;安全方面,每次登录给予一个票据,用于服务端检验发送的信息是否合法;将主业务与工具和后台业务分开,分多个进程处理,可以明显降低内存和电量的消耗。

斑马广告:采用对一群人画像如1万人,而不对1个人进行画像分析,每个人加入标签,如年龄、旅游、科技等,如果需要5000万定向客户,而实际标签不足时,需要通过lookalike系统查找潜在的和之前尚未分析出的客户,准确率达到16%左右;标签标的有:朋友圈发的消息、广告的点击和互动、公众号的类型、店家wifi的登入等,对聊天记录腾讯有天然的敏感性,不进行分析。

朋友圈:自己的timeline即自己发的信息,好友的timeline即公用区域发的信息,这个都以用户为单位,将timeline分两类,自己和好友,自己的直接显示,好友的插入自己的消息,这是实现的第一步;第二位是交互,好友发一条消息,第一:哪些人可见哪些人不可见,好友这边呢,操作是直接插入到可见好友的timleline,不可见好友收到的是相反的消息即不插入,第二:哪些是共同的好友,评论和点赞彼此收的到,实际出现三个对象,你、我、其他人,三者均需要一个消息推送(实际情况更复杂,多个直接跟你互相的人即是你,你的好友中非彼此好友的人即是其他人),最终采用增量推送的方式。

后端:消息分五类,红包,文本和语音,图片和视频、群消息、朋友圈,优先保证第一项服务可用,然后保证第二项服务可用,最后再保证朋友圈可用,这是消息优先级,在信息量巨大时可以人工触发开关处理;考虑到国内外通讯,中国香港地区延时100-200ms,欧美约300-500ms,国外的消息即就近处理,并且放在就近的服务器上,上海保证北方区,深圳保证南方区,中国香港保证东亚区,加拿大保证欧美区,这样一方面保证应用的国外战略得以实施,另一方面消息分流减轻服务器的压力;值得讲的一点是不同区之间的消息通讯,比如北方区的A和东南亚区的B,A发送消息,存储在上海服务器,然后推送到中国香港服务器,由中国香港区推送给B,减少https公网的等待时间,另外一点如果此人经常全球跑,则数据会漫游到国内数据中心处理,否则经常切换数据中心和服务备份,会浪费大量资源,增加系统冗余。

接下来聊几个服务端的点

数据接入-数据处理(逻辑处理-数据读写)-数据持久化(数据存储)

Qos:quality of service 服务质量,网络请求会分发到很多数据中心进行处理,而每个路由都有一个buffer,超过后则丢弃,否则数据积压导致各方数据均不能有效处理,而各种服务瘫痪;传输顺序出错和其他出错,需要有相关协议保证重试。

Cgi:common gateway interface 大量用户发送的请求,后台会有无数个cgi程序都保证正确处理,比如消息推送和消息同步

容灾:设计3的倍数个数据中心,保证每个数据中心有2/3的数据处理峰值,这样在其中1/3个中心瘫痪时,其他2/3的中心可以接收它的处理能力。

埋点:与测试团队沟通容易出错的地方,做key-value增加策略,key为关键点的id,value为关键点数据+1的值,在后台展示和处理,达到预警则及时处理,达到早发现、早处理的目的,这也是容灾的一部分;另一部分是与产品团队,共同开发出业务的使用频率,为后面的产品设计和架构设计提供良好的数据支撑。

RPC:同步处理的消息往往是有限的,异步可以大限度的压榨服务器的处理能力,如微信开发的SvrKit,用户发出请求后,交付中间件异步处理,并提供出错重试协议,保证消息被正确处理。

数据IO:读写在大量数据交互的应用上显示尤为重要,提供memcache防止频繁访问数据库,提供多Master-Slave提供数据读写服务,如海外A的消息存储在加拿大,国内B的消息存储在上海,这就是两个Master,两者通信通过RPC推送到对方数据中心即可,Slave用在Master出问题时的备用存储方案,事后要两者要互相同步。

图片:用户发送后放到CDN处理,返回大图和缩略图链接,加到消息对象中,返回客户端。

同步:采用seq增量下发消息的方式,对邮件、漂流瓶等进行key-value的判断拉取数据。

安全:每次登录都带有票据,票据用密钥对+ID来处理,可以随时定向失效密钥。

本文分享自微信公众号 - Java帮帮(javahelp)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-11-29

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • JavaWeb17-案例之ajax(Java真正的全栈开发)

    案例 & ajax 一.案例 1. 生成订单操作分析 先看下订单页面: 分析下订单表需要那些字段 id 收货人(receiverName) 收货地址(recei...

    Java帮帮
  • 一个 Java 程序员眼中的 Go 语言

    首先,我想做个免责声明,我不是 Go 语言专家。几周前我才开始学习,所以本文是我对 Go 的第一印象。文中我的一些主观看法可能是错的。以后我可能会发文再探讨本文...

    Java帮帮
  • Zookeeper实现参数的集中式管理【面试+工作】

    应用项目中都会有一些参数,一般的做法通常可以选择将其存储在本地配置文件或者内存变量中;对于集群机器规模不大、配置变更不是特别频繁的情况下,这两种方式都能很好的解...

    Java帮帮
  • CCAI 2017 | 蚂蚁金服人工智能部技术总监李小龙:蚂蚁金服智能金融实践

    用户1737318
  • 提取数据中的有效信息

    在对数据进行清洗之后,再就是从数据中提取有效信息。对于地址数据,有效信息一般都是分级别的,对于地址来说,最有效的地址应当是道路、小区与门牌和楼幢号信息了。所以地...

    数据处理与分析
  • Java 进阶面试问题列表

    大黄大黄大黄
  • RTB业务知识之2-Open-RTB全景

    openrtb是一套开源的竞价广告系统,来自IAB的贡献,非常好。有非常多的值得借鉴的地方,最近基于其所提供sdk api接口文档介绍,整理了相关的资料。主要...

    数据饕餮
  • Linux文件恢复利器 ext3grep

    介绍两款Linux文件恢复工具,ext3grep与extundelete,可能在关键时刻会有所帮助。ext3grep仅对ext3文件系统有效,extundele...

    py3study
  • Java Servlet工作原理问答

    本文来自stackoverflow的问答,讨论了Java Servlet的工作机制,如何进行实例化、共享变量和多线程处理。

    哲洛不闹
  • 基础篇-app上传小准备及上架后搜索不显示

            app上传中会需要准备一些文件,如 icon图标,launch Image ,itunes Contect 中还需要上传不同尺寸的屏幕截图等,下...

    進无尽

扫码关注云+社区

领取腾讯云代金券