全面解密QQ红包技术方案：架构、技术实现、移动端优化、创新玩法等
本文来自腾讯QQ技术团队工程师许灵锋、周海发的技术分享。php
1、引言
自 2015 年春节以来，QQ 春节红包经历了企业红包（2015 年）、刷一刷红包（2016 年）和 AR 红包（2017 年）几个阶段，经过不断创新玩法，活跃度节节攀升，成为春节一大玩点，给火红的春节带来一抹亮色。2017 年除夕，AR 红包、刷一刷红包再创新高，抢红包用户数达 3.42 亿，共刷出红包 37.77 亿个。html
那么，QQ 红包的技术方案到底是怎样的？其总体架构如何？重要的系统是如何设计的？为了保证用户的体验，手机 QQ 移动端作了哪些优化？今年的 QQ 红包又作了哪些新的尝试，遇到的问题是如何解决的呢？本文将从架构开始，到手机 QQ 移动端优化，再到个性化红包和 AR 新玩法，为你们全面解密 QQ 红包技术方案。程序员
学习交流：算法
- 即时通信/推送技术开发交流4群：101279154 [推荐]数据库
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》小程序
（本文同步发布于：http://www.52im.net/thread-2202-1-1.html）后端
2、关于做者
▲ 两位做者，许灵锋（图左者）和周海发（图右者）微信小程序
turboxu（许灵锋）：2006 年加入腾讯，会员体系后台负责人，从事过 MIS 系统、网络安全、滔滔（空间说说）、WAP 音乐、超 Q、会员等项目，对开源组件、虚拟化感兴趣，致力于推进 Docker 虚拟化和开源组件的应用和实践。缓存
haifazhou（周海发）：2011 年加入腾讯，从事 IM 基础系统开发和运营，前后参与过 PTLogin 统一登陆和消息漫游存储改造项目，连续三年参与并负责 QQ 春节红包后台系统架构设计，在海量分布式高性能系统设计方面积累了多年经验。安全
3、相关文章
《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
《开源libco库：单机千万链接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万链接背后的后台解决方案》
4、QQ 红包总体架构及重要系统
QQ 春节红包以一个又一个的整点刷红包活动贯穿年三十，在除夕夜达到顶峰，是典型的海量用户秒杀场景，如何应对海量的用户刷红包洪流，保证刷得爽，红包安全到帐，是 QQ 红包设计要解决的关键技术难点。另外，红包项目涉及手机 QQ 移动端、手机 QQQ 后台、QQ 钱包（财付通）系统、礼券系统、公众号等诸多业务系统，流程长且多，各系统性能吞吐量差别很大，如何保证各系统造成一个有机总体，协调高效提供服务，也是难点之一。
下图为简化后 QQ 红包的架构，包括：接入层、抽奖系统、存储系统、发货系统、公众号消息通知和 CDN 资源等几部分，请你们先有一个总体的认知，便于阅读下文。
▲ 简化后的QQ红包系统架构
本节将重点讲解接入层、抽奖系统和发货系统。
4.一、接入层
接入层是红包后台服务的大门，负责抽奖请求预处理，确保有效的请求才透传给后端服务。为保证自身高可用、高稳定，接入层还可实时控制手机 QQ 请求频率，避免海量请求压垮接入层，出现不可控局面。
在海量服务场景下，为避免网络开销，方便后端服务使用 cache 提高性能，接入层采用了一致性 Hash 寻址，保证同一个用户的请求只会落在同一台红包抽奖逻辑机器处理。
4.二、抽奖系统
4.2.1 基本介绍
抽奖系统做为 QQ 红包的核心系统，在承接用户抽奖请求，按设计合理的概率完成抽奖操做，将抽奖结果安全落地保存，并顺利发货等过程当中，起到了关键做用。面对海量抽奖请求，如何及时做出响应，是抽奖系统面临的难题。
为了解决这些问题，咱们采用了一些设计方法：
1）在接入层采用一致性 Hash 算法：同一用户的抽奖请求只会转发到相同的抽奖系统处理 ;
2）抽奖系统采用缓存机制：在加快抽奖过程的同时也减小了对存储层的访问压力；
3）奖品配额机制：平滑抽奖过程，各种奖品按比例有序抽中；
4）流水和对帐机制：保证抽奖数据最终无差错发放到用户帐户中。
抽奖系统的架构以下图所示：
4.2.2 缓存机制
业务要求在每一个刷一刷的活动中，能对用户中奖次数、参与时间（30 秒）进行限制。若是用户的每一个抽奖请求到来时，先到存储层获取用户的中奖历史信息，再断定用户是否还有抽奖资格，在海量高并发的请求场景下，势必会对存储层形成巨大的压力。因此这里咱们引入了本地内存缓存层，用于保存用户的中奖历史信息，每次请求到来时，会先到缓存层获取用户的中奖历史信息，若是在缓存层没找到，才会到存储层获取，这样就不会对存储层形成太大的压力，同时也能实现业务的需求。缓存层咱们采用开源 Memcached 组件实现。
4.2.3 一致性 hash 寻址
红包抽奖系统是一个分布式的系统，所以为了使缓存机制生效，咱们在手机 QQ 接入层使用了一致性 hash 的路由算法进行寻址，保证同一个用户（uin）的请求总会落在同一台逻辑机器进行处理。
4.2.4 协议处理模块
因为手机 QQ 后台既要处理客户端的二进制请求，也要处理其余 Web 系统的 HTTP 请求，因此协议处理模块的首要任务就是兼容各类格式的协议，给后端模块一个最简单的结构。为此咱们制定了 Protobuf 格式的交互协议（兼容 JSON 格式，会统一转换成 Protobuf 处理），传给后端模块。
4.2.5 配额管理模块
手机 QQ 春节红包是经过不少场定时“活动”来发放红包的。每场活动里面能发放多少现金，能发放多少虚拟物品，发放的比例如何，这些都是配额数据。
更进一步，咱们要作到精确控制现金和虚拟物品的发放速度，使得不管什么时候用户来参加活动，都有机会得到红包，而不是全部红包在前几分钟就被用户横扫一空。
配额信息由配额管理工具负责检查和修改，每次修改都会生成新的 SeqNo。一旦配额 agent 发现 SeqNo 发生变化，则会更新本地共享内存。因为 agent 采用双 buffer 设计，因此更新完成前不会影响当前业务进程。
4.2.6 抽奖模块
聚焦到抽奖，QQ 红包的抽奖算法其实并不复杂，可是可否知足产品须要很是重要。
咱们的设计思路是至少须要知足以下需求：
1）能够在秒级别控制现金和每种物品的发放速度；
2）能够方便调整现金和每种物品的发放比例；
3）尽可能保证红包所有发放出去。
为此，咱们设计了以下的抽奖流程算法：
须要说明的是，只要是由于配额限制发放红包失败，咱们都会继续尝试给用户发放其余奖品的红包，直到没有奖品能够发放，这样咱们就能保证把奖品尽量发放出去。
4.2.7 流水系统设计
流水系统用于保存活动过程当中的抽奖流水记录，在活动后对奖品发放和领用进行统计和对帐。该系统还定时对领用失败的请求进行重作和对帐，确保奖品发放到用户帐户里。
流水系统架构以下：
因为流水须要记录用户中奖的信息和领用的的状况，数据量巨大，因此抽奖逻辑层本地采用顺序写文件的方式进行记录。抽奖逻辑层会按期的把本地的流水文件同步到远程流水系统进行汇总和备份，同时，流水系统会对领用失败的流水进行重作，发送请求到抽奖逻辑层，抽奖逻辑层会调用发货系统的接口完成发货操做。
4.2.8 存储层选型
存储层的设计向来都是后台架构设计中的重点和难点。目前腾讯公司内部较成熟的 NoSQL 存储系统有 CKV、Grocery，通过一番对比咱们选择使用 Grocery，主要缘由有如下几点。
1）强大的带条件判断的分布式原子算数运算：
抽奖逻辑里须要对每一个奖品进行计数，避免多发少发，因此一个高效可靠的分布式原子加计数器显得格外重要，Grocery 支持带条件判断的原子加计数器，调用一次接口就能完成奖品计数值与配额的判断以及奖品计数值的增长。
2）灵活的数据类型：
Grocery 支持 Key-Key-Row 类型的数据存储格式，能够灵活的存储用户的红包中奖信息，为获取用户单个红包或者红包列表提供了丰富的接口。
3）部署、扩容方便：
Grocery 有专门的团队支持，易于部署和扩容。
4）平滑限频设计：
每一种奖品，对应的业务都有他们本身的容量能力，且各业务的能力也不尽相同（如黄钻 4w/s，京东 2k/s 等）。为保证红包活动持续进行，抽奖系统必须严格按业务控制派发峰值。派发峰值支持实时可调，避免因为业务方评估不足引发过载。
考虑这样一种场景，若是请求是在 1 秒的最开始所有涌到业务方，受限于业务方不一样的架构实现，有可能会触发业务方的频率限制或者是过载保护。为此，咱们将频限粒度调整到百毫秒，这样奖品就会在 1 秒内相对平均的发放，从而解决了上述问题。
4.三、QQ 红包发货系统
QQ 红包奖品包括现金和礼券两类，现金对接财付通，礼券又分腾讯公司内部虚拟物品和第三方礼券。最终礼品落地到用户的帐户（QQ 钱包余额、QQ 卡券或第三方系统帐户）中。虽然抽奖系统有做平滑处理，但持续长时间的大流量发货，也可能致使业务系统不能正常提供峰值下的服务能力。如何承上启下，既预防抽奖系统不能平滑地发货致使压跨发货系统（自身），又能保护后端业务系统的状况下，以较快的速度将奖品安全发放到帐，是发货系统的设计要点。
发货系统设计遵循如下策略：
1）快慢分离；
2）异步削峰；
3）柔性处理；
4）保护业务系统；
5）最终一致性。
发货系统架构以下图所示：
快慢分离：
现金和礼券后端的系统彻底不一样，现金经过 QQ 钱包系统发放入财付通帐户，要求实时到帐不能延迟。而礼券对接的后端业务千差万别，服务容量和性能各不相同。为了避免让慢速的礼券发放影响快速的现金发放，将现金通道与礼券通道分离，互不干扰。
异步削峰：
因为用户来抽奖的时机彻底是随机的，抽奖系统并不能作到绝对平滑发货。任由抽奖系统将发货请求直接透传到业务系统，将出现不可预知的问题，严重时可能会致使业务系统雪崩，这是不能接受的。另外象游戏礼包类、滴滴券等第三方礼券，可能用户帐户并不存在（用户并不玩该款游戏，或用户并无第三方帐户），须要先引导用户建立帐户才能发货，这就要求发货系统有暂存奖品信息，具有延后发货的能力。
发货系统采用开源的 RocketMQ 消息中间件做为异步消息队列，暂存发货请求，再由礼券发货模块根据各业务的限速配置均匀地调用业务接口进行发货。
柔性处理：
礼券类奖品经过异步方式发放到用户帐户，在除夕高峰值可能发放速度跟不上抽奖速度，会延后一些时间才能到帐，这对不明真相用户可能会形成困扰。所以在用户中奖信息页面中，会提示用户 24 小时（或 48 小时）到帐。发货过程的每一个步骤，都有能够异常失败，致使发货不成功，所以在物品详细页面的按钮支持屡次发起发货，在“礼券发货”模块根据发货状态，能够屡次尝试发货，并保证一个奖品只发放一次。
保护业务系统：
前面已经提过，发货系统经过异步消息队列，将抽奖系统与业务开发隔离开，抽奖洪峰不会直接影响业务系统，对业务系统起来隔离保护做用。
礼券发货模块针对每一个业务单独配置限速阈值，对各业务的发货严格以不超过限速阈值的速度发放奖品，若是业务有超时或提示超速，再按必定比较再减速。
礼券发货模块首先会到存储系统检查奖品是否真实有效，再到发货状态存储检查状态是否正常，只有真正须要的发货的奖品才向业务系统发起发货请求，确保发货的有效性，避免错发和多发。
最终一致性：
因为采用异步发货，抽奖时刻奖品不能保证当即发放到用户帐户中。但用户的奖品不会丢失，经过在异步队列中暂存，礼券发货模块逐步以合适的速度将奖品发放到用户帐户中。
若是发货过程当中有延时或失败，用户能够经过屡次领取提起发货请求，系统支持屡次提交。
若是屡次发货仍然失败，对帐工具第 2 天会从流水系统中将用户抽奖数据与发货数据进行对帐，对发货异经常使用户再次发起发货。若是对帐仍然失败，则提醒管理人员介入处理。
5、手机QQ移动端的优化策略
普通用户不会关心 QQ 红包的后台有多复杂，他们在手机QQ移动端抢红包时的体验直接决定着用户对 QQ 红包的评价。对用户来讲，看到红包后可否顺畅的抢和刷，是最直接的体验痛点，所以须要尽量下降延迟以消除卡顿体验，甚至在弱网环境下，也要能有较好的体验。为了实现该目标，手机QQ移动端采起了如下优化策略：
1）资源预加载：
QQ 红包中用到的不常常变化的静态资源，如页面，图片，JS 等，会分发到各地 CDN 以提升访问速度，只有动态变化的内容，才实时从后台拉取。然而即便全部的静态资源都采用了 CDN 分发，若是按实际流量评估，CDN 的压力仍然没法绝对削峰。由于同时访问红包页面的人数比较多，按 83 万 / 秒的峰值，一个页面按 200K 评估，约须要 158.3G 的 CDN 带宽，会给 CDN 带来瞬间很大的压力。为减轻 CDN 压力，QQ 红包使用了手机 QQ 离线包机制提早把红包相关静态资源预加载到手机QQ移动端，这样可大大下降 CDN 压力。
目前手机 QQ 离线包有两种预加载方式：
a. 将静态资源放入预加载列表：用户从新登陆手机 QQ 时监测离线包是否有更新并按需加载（1 天能覆盖 60%，2 天能覆盖 80%，适合预热放量状况）；
b. 主动推送离线包：向当前在线用户推送离线包。（2 个小时能够完成推送，覆盖总量的 40% 左右，适合紧急状况）经过离线包预加载后，除夕当天的 CDN 流量并无出现异常峰值，比较平稳。
2）缓存和延时：
2.59 亿用户同时在线，用户刷一刷时的峰值高达 83 万 / 秒，若是这些用户的操做请求所有同时拥向后台，即便后台能抗得住，须要的带宽、设备资源成本也是天文数字。为了尽量减轻后台服务器压力，根据用户刷一刷的体验，用户每次刷的操做都向后台发起请求是没有必要的，所以手机 QQ 在移动端对用户刷一刷的操做进行计数，定时（1~3 秒）异步将汇总数据提交到后台抽奖，再将抽奖结果回传到手机 QQ 移动端显示。这样既保证了“刷”的畅快体验，也大大减轻后台压力，抽奖结果也在不经意间生产，用户体验彻底无损。
3）错峰：
对用户进行分组，不一样组的用户刷一刷红包（企业明星红包、AR 红包等）的开始时间并不相同，而是错开一段时间（1~5 分钟），这样经过错开每一轮刷红包的开始时间，能够有效平滑用户刷一刷的请求峰值。
4）动态调整：
手机 QQ 移动端和后台并非两个孤立的系统，而是一个总体。手机 QQ 系统搭建有一整套的负载监控体系，当后台负载升高到警惕线时，手机 QQ 移动端能够根据后台负载状况，动态减小发向后台的请求，以防止后台出现超载而雪崩。
5）总量限制和清理：
在刷一刷红包和 AR 红包过程当中，当用户已经抽中的奖品数达到一个限值（例如 5 个），用户不能再中奖，这时用户的抽奖请求再也不向后台发送，而是移动端直接告知用户“未中奖，请稍后再试”，和清除 AR 红包地图中的红包显示。
6、红包创新玩法挑战
春节红包大战，从企业红包演变到刷一刷红包、个性化红包和 AR 红包，玩法不断创新，用户体验更好，活跃度提高，参与人数也从 2 亿增加到 17 年春节的 3.42 亿。
6.一、个性化红包
6.1.1 基本状况
QQ 个性红包是在红包外观上的一次大胆尝试，借助该功能，用户可以使用霸气的书法体将本身的姓氏／或其余文字（提供自动简繁体转换）镌刻在红包封皮上。此外，咱们还提供了具备新年氛围的贺岁红包、与腾讯 IP 紧密结合的 QQ family、游戏形象、动漫形象等卡通红包，大大提升了 QQ 红包的趣味性与观赏性。个性红包功能上线后，有超过 30% 的红包用户选择使用个性红包。在 2016 年春节期间共有 1500 万用户使用该功能，2016 年除夕当晚突破 8 千万的个性红包发送量。
个性红包在普通基础上，容许用户修改红包封皮，展现个性，应合场景，所以设计的要点是使用户操做顺畅，既保持发、抢红包的流畅体验，又能显示个性和有趣好玩。
个性化红包流程架构以下图所示：
从上图能够看出，简化后的红包的发放过程经历红包移动端 -> 财付通 -> 红包后台 -> 手机 QQ AIO（聊天交互窗口）-> 拆（抢）红包页面等过程，流程较长（忽略了一些细节，实际流程更复杂），在这些步骤过程当中若是每一步都走后台判断个性化红包状态，必然影响到红包的发放流畅性。
为了尽可能不影响用户发红包体验，个性化红包在架构和运营上做了不少解藕和柔性设计。包括个性字体提早绘制，资源预加载，功能开关和容灾柔性处理等。
6.1.2 字体提早绘制
个性化红包支持全部简体与繁体汉字，并支持部分简体汉字转换成繁体汉字，为了改善使用“姓氏红包”用户的体验，咱们把经常使用的 300 个姓氏，使用预生成的方式，在用户手机 QQ 空闲的时候生成经常使用的姓氏图片保存到本地。其余的很是用姓氏，在展现的时候合成，合成一次保存在本地，下次在本地读取。
手机 QQ 移动端在空闲时绘制好字体贴图，支持定时更新背景图和字体库，对很是用字，则启动个性化字体引擎生成对应的个性化贴图。
用户在发放或收到红包时，个性化背景和字体贴图已经生成好，不须要再生成，收发红包流畅体验无损。
6.1.3 资源预加载
个性化红包封素材提早制做好，上传到 CDN 网络，手机 QQ 在空闲时提早从 CDN 下载素材文件，并定时检查素材更新状况，及时更新。
6.1.4 功能开关
用户是否设置个性红包，选择的个性红包贴图样式，是否启用个性红包等信息，若是每次判断都从后台拉取，势必增长后台压力。用户对个性红包的设置信息，其实变化不大，而且访问红包商场实时设置的状态的结果在手机 QQ 移动端是存在的。所以咱们设计将这些用户状态 FLAG 在手机 QQ 登陆时，从后台拉取一次后保存在手机 QQ 移动端，在发红包的过程当中将 FLAG 信息传递到下游服务中，经过红包商城设置的个性化红包标志，实时更新手机 QQ本地配置。
这样的设计有几个好处：
1）用户的个性化设置再也不依赖于后台，发红包过程彻底本地操做，没有任何延时，不影响红包的发放；
2）FLAG 标志能够做为容灾开关，若是临时取消个性红包，或后台故障，能够临时屏蔽个性红包功能，恢复为默认红包样式，保障任什么时候刻红包功能正常可用；
3）FLAG 标志可支持扩展，在红包后台能够根据扩展，支持付费红包样式（付费购买）、特权红包样式（如超会专享）等，支持红包商城扩展各类各样的个性化红包；
4）除了从后台拉取 FLAG，当业务有调整致使 FLAG 变化，红包后台能够向手机 QQ 移动端主动 push FLAG 状态，使得用户及时感知变化，进一步加强用户使用体验。
6.1.5 容灾柔性处理
相对于手机 QQ 平台功能，个性红包系统相对独立，运营和更新很快，系统各功能组件出现问题的概率可能较多，若是个性红包业务出现问题，而影响到正常红包发放或手机 QQ 功能的使用，会对 QQ 口碑形成很大负面影响。咱们在系统中设计了多处容灾和柔性处理措施，在个性红包业务异常时，能降级提供服务，最差时取消个性红包功能。
柔性措施一：用户登陆时拉取个性红包 FLAG 失败时，采用默认红包样式；
柔性措施二：红包后台向个性化红包后台拉取个性化设置鉴权详情（是否付费、是否会员专享等）时，若是拉取异常，采用默认红包样式；
柔性措施三：个性化红包由用户输入姓氏，指定显示文字，可能遇到敏感字或须要临时下线，能够经过向手机 QQ 下发 FLAG 标志，临时取消个性红包功能，恢复到默认红包样式。
6.二、AR 红包
6.2.1 概述
AR 红包是“LBS+AR 天降红包”的简称，这个创新的玩法获得了用户的一致好评，参与用户 2.57 亿次，共计领取红包和礼券 20.5 亿个，得到了口碑和活跃的双丰收。
6.2.2 缓存设计
LBS+AR 红包与以往的红包最大的不一样在于多了一重地理位置关联，全国有上千万的地理位置信息，结合活动的任务奖品数据产生了海量的配置数据，而这些数据都须要快速实时读取。这是系统设计的一大挑战。
配置数据有如下特色：
1）数据量很大（亿级），数据间有紧密的关联，咱们采用 MySQL 数据库集群存储，并构建有 Web 可视化配置投放平台，实现自动容灾和备份的功能；
2）“一次配好，处处使用”，配置读量远高于写量，基本思想是设计开发一种缓存，放弃写性能，将读性能优化到极致。
上千兆的配置数据，如何供抽奖系统快速检索？考虑到业务使用场景、配置数据大小及 MySQL 性能，能够采用预先构建全量缓存并进行有序组织，由同步模块负责将构建好的配置数据同步到抽奖系统，供业务进程直接使用。为保证配置数据完整性，构建缓存采用双 Buffer 设计，只有构建或同步完成后才切换到最新配置。
6.2.3 地图打点与查点
基于 LBS 的红包活动离不开地理位置相关的业务交互。在 AR 红包中，用户打开地图会按期向后台上报坐标，后台须要根据坐标获取周围可用的活动任务投放点，投放点事先都会进行安全筛查，去掉具备安全隐患的区域，避免给用户带来人身安全问题，本节主要介绍如何管理这些投放点。
地图格子：
将整个二维平面根据坐标分红边长相等的正方形格子，根据用户的坐标用简单的数学运算便可获取相应的格子 ID，时间复杂度 O(1)。一个格子是一次查询的最小粒度。每次查询会返回以用户为中心周围 5*5 共计 25 个格子的任务点。
打点：
红包是以任务维度投放的，每一个任务关联一个 POI 集合，每一个 POI 集合中包含几个到上百万不等的 POI 点，每一个 POI 点都有一个经纬度信息。
打点便是事先创建格子到任务列表的映射。全部格子数据有序组织并存储在共享内存里，使用二分查找提高读性能。
查点流程：
1） 客户端上报经纬度；
2） 根据经纬度计算中心格子 ID；
3） 根据中心格子 ID 及半径配置，获取周围格子列表；
4） 在打点系统中得到此片区域所有 POI 和任务信息；
5） 检查任务状态后返回给客户端。
6.2.4 采集系统
采集系统主要负责汇总各行政区红包发放状态数据，主要提供如下功能：
1）实时返回区级行政区红包计数；
2）实时接受主逻辑的查询，返回奖品发放状态；
3）返回活动预告以及参数配置等辅助信息。
因为红包是按行政区进行投放的，每一个行政区约投放 10 个任务，每一个任务又关联多种类型的红包，若是每次查询区级红包余量时，都实时计算和汇总红包状态数据，扩散带来的包量开销会比较大，为此，咱们仍是采用双 Buffer 缓存来解决该问题，一个进程负责将采集到的数据写到缓存，另外一组进程提供查询服务。另外，还能够根据存储层的压力，适当地调整采集的频率，使得统计数据尽量实时。
7、本文小结
自 2015 年起，历年除夕当天 QQ 红包收发状况以下表所示，能够看出，参与人数和红包首发总个数都是节节升高。
QQ 红包业务复杂，海量访问，涉及业务多，流程长，项目的成功离不开相关兄弟部门的大力支持和能力合做，特别感谢即通产品部、财付通、即通平台部、SNG 市场部、SNG 商业广告中心、增值渠道部、社交用户体验设计部、集团市场与公关部、增值产品部、社交与效果广告部、网络质量部、即通综合部、架构平台部、社交平台部、网络运营部等 15 个兄弟部门相关同事的付出和给力支持。
附录：更多相关文章
[1] QQ、微信团队原创技术文章：
《腾讯技术分享：腾讯是如何大幅下降带宽和网络流量的(图片压缩篇)》
《腾讯技术分享：腾讯是如何大幅下降带宽和网络流量的(音视频技术篇)》
《腾讯技术分享：Android版手机QQ的缓存监控与优化实践》
《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》
《微信团队分享：iOS版微信是如何防止特殊字符致使的炸群、APP崩溃的？》
《腾讯技术分享：Android手Q的线程死锁监控系统技术实践》
《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《腾讯团队分享 ：一次手Q聊天界面中图片显示bug的追踪过程分享》
《微信团队分享：微信Android版小视频编码填过的那些坑》
《微信团队披露：微信界面卡死超级bug“15。。。。”的前因后果》
《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》
《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提高移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万链接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通讯安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万链接背后的后台解决方案》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《移动端IM实践：Android版微信如何大幅提高交互性能（一）》
《移动端IM实践：Android版微信如何大幅提高交互性能（二）》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《信鸽团队原创：一块儿走过 iOS10 上消息推送(APNS)的坑》
《腾讯TEG团队原创：基于MySQL的分布式数据库TDSQL十年锻造经验分享》
《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
《了解iOS消息推送一文就够：史上最全iOS Push技术详解》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《腾讯音视频实验室：使用AI黑科技实现超低码率的高清实时视频聊天》
《腾讯技术分享：微信小程序音视频与WebRTC互通的技术思路和实践》
《手把手教你读取Android版微信和手Q的聊天记录(仅做技术研究学习)》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《腾讯技术分享：GIF动图技术详解及手机QQ动态表情压缩技术实践》
《微信团队分享：Kotlin渐被承认，Android版微信的技术尝鲜之旅》
《全面解密QQ红包技术方案：架构、技术实现、移动端优化、创新玩法等》
>> 更多同类文章 ……
[2] 有关QQ、微信的技术故事：
《技术往事：微信估值已超5千亿，雷军曾有机会收编张小龙及其Foxmail》
《2017微信数据报告：日活跃用户达9亿、日发消息380亿条》
《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》
《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》
《开发往事：深度讲述2010到2015，微信一路风雨的背后》
《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》
《前创始团队成员分享：盘点微信的前世此生——微信成功的必然和偶然》
《即时通信创业必读：解密微信的产品定位、创新思惟、设计法则等》
《[技术脑洞] 若是把14亿中国人拉到一个微信群里技术上能实现吗？》
《QQ和微信止步不前，意味着即时通信社交应用创业的第2春已来？》
《读懂微信：从1.0到7.0版本，一个主流IM社交工具的进化史》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-2202-1-1.html）
- 1. 全面解密QQ红包技术方案：架构、技术实现、移动端优化、创新玩法等 ...
- 2. QQ红包技术方案全解密
- 3. QQ 红包技术方案全解密 （二）
- 4. QQ红包技术方案全解密（一）
- 5. Hadoop技术创新方案
- 6. 技术-技术方案优化策略--数据库层面
- 7. 技术-技术方案优化策略--代码层面
- 8. 技术-技术方案优化策略--缓存层面
- 9. Hadoop技术创新解决方案
- 10. 技术-技术方案优化策略--JVM调优
- 更多相关文章...
- • XML 相关技术 - XML 教程
- • Hibernate的快照技术 - Hibernate教程
- • Docker容器实战(一) - 封神Server端技术
- • 三篇文章了解 TiDB 技术内幕——说存储
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. Window下Ribbit MQ安装
- 2. Linux下Redis安装及集群搭建
- 3. shiny搭建网站填坑战略
- 4. Mysql8.0.22安装与配置详细教程
- 5. Hadoop安装及配置
- 6. Python爬虫初学笔记
- 7. 部署LVS-Keepalived高可用集群
- 8. keepalived+mysql高可用集群
- 9. jenkins 公钥配置
- 10. HA实用详解