全面解密QQ红包技术方案：架构、技术实现、手机端优化、创新玩法等
本文来自腾讯QQ技术团队工程师许灵锋、周海发的技术分享。
一、引言
自 2015 年春节以来，QQ 春节红包经历了企业红包（2015 年）、刷一刷红包（2016 年）和 AR 红包（2017 年）几个阶段，通过不断创新玩法，活跃度节节攀升，成为春节一大玩点，给火红的春节带来一抹亮色。2017 年除夕，AR 红包、刷一刷红包再创新高，抢红包客户数达 3.42 亿，共刷出红包 37.77 亿个。
那么，QQ 红包的技术方案到底是怎么的？其整体架构如何？重要的系统是如何设计的？为了保证客户的体验，手机 QQ 手机端做了哪些优化？今年的 QQ 红包又做了哪些新的尝试，遇到的问题是如何处理的呢？本文将从架构开始，到手机 QQ 手机端优化，再到个性化红包和 AR 新玩法，为大家全面解密 QQ 红包技术方案。
学习交流：
– 即时通讯/推送技术开发交流4群：101279154?[推荐]
– 手机端IM开发入门文章：《新手入门一篇就够：从零开发手机端IM》
（本文同步发布于：http://www.52im.net/thread-2202-1-1.html）
二、关于作者
▲ 两位作者，许灵锋（图左者）和周海发（图右者）
turboxu（许灵锋）：2006 年加入腾讯，会员体系后端负责人，从事过 MIS 系统、网络安全、滔滔（空间说说）、WAP 音乐、超 Q、会员等项目，对开源组件、虚拟化感兴趣，致力于推动 Docker 虚拟化和开源组件的应用和实践。
haifazhou（周海发）：2011 年加入腾讯，从事 IM 基础系统开发和经营，先后参加过 PTLogin 统一登录和消息漫游存储改造项目，连续三年参加并负责 QQ 春节红包后端系统架构设计，在海量分布式高性能系统设计方面积累了多年经验。
三、相关文章
《技术往事：“QQ群”和“微信红包”是怎样来的？》
《QQ 18年：解密8亿月活的QQ后端服务接口隔离技术》
《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
《开源libco库：单机千万连接、支撑微信8亿客户的后端框架基石 [源码下载]》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《微信海量客户背后的后端系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后端处理方案》
《微信朋友圈海量技术之道PPT [附件下载]》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《快速裂变：见证微信强大后端架构从0到1的演进历程（一）》
《快速裂变：见证微信强大后端架构从0到1的演进历程（二）》
四、QQ 红包整体架构及重要系统
QQ 春节红包以一个又一个的整点刷红包活动贯穿年三十，在除夕夜达到顶峰，是典型的海量客户秒杀场景，如何应对海量的客户刷红包洪流，保证刷得爽，红包安全到账，是 QQ 红包设计要处理的关键技术难点。另外，红包项目涉及手机 QQ 手机端、手机 QQQ 后端、QQ 钱包（财付通）系统、礼券系统、公众号等诸多业务系统，流程长且多，各系统性能吞吐量差异很大，如何保证各系统形成一个有机整体，协调高效提供服务，也是难点之一。
下图为简化后 QQ 红包的架构，包括：接入层、抽奖系统、存储系统、发货系统、公众号消息通知和 CDN 资源等几部分，请大家先有一个整体的认知，便于阅读下文。
▲ 简化后的QQ红包系统架构
本节将重点讲解接入层、抽奖系统和发货系统。
4.1、接入层
接入层是红包后端服务的大门，负责抽奖请求预解决，确保有效的请求才透传给后台服务。为保证自身高可用、高稳固，接入层还可实时控制手机 QQ 请求频率，避免海量请求压垮接入层，出现不可控局面。
在海量服务场景下，为避免网络开销，方便后台服务使用 cache 提升性能，接入层采用了一致性 Hash 寻址，保证同一个客户的请求只会落在同一台红包抽奖逻辑机器解决。
4.2、抽奖系统
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.3、QQ 红包发货系统
QQ 红包奖品包括现金和礼券两类，现金对接财付通，礼券又分腾讯公司内部虚拟物品和第三方礼券。最终礼品落地到客户的账户（QQ 钱包余额、QQ 卡券或者第三方系统账户）中。尽管抽奖系统有作平滑解决，但持续长时间的大流量发货，也可能导致业务系统不能正常提供峰值下的服务能力。如何承上启下，既预防抽奖系统不能平滑地发货导致压跨发货系统（自身），又能保护后台业务系统的情况下，以较快的速度将奖品安全发放到账，是发货系统的设计要点。
发货系统设计遵循以下策略：
1）快慢分离；
2）异步削峰；
3）柔性解决；
4）保护业务系统；
5）最终一致性。
发货系统架构如下图所示：
快慢分离：
现金和礼券后台的系统完全不同，现金通过 QQ 钱包系统发放入财付通账户，要求实时到账不能推迟。而礼券对接的后台业务千差万别，服务容量和性能各不相同。为了不让慢速的礼券发放影响快速的现金发放，将现金通道与礼券通道分离，互不干扰。
异步削峰：
因为客户来抽奖的时机完全是随机的，抽奖系统并不能做到绝对平滑发货。任由抽奖系统将发货请求直接透传到业务系统，将出现不可预知的问题，严重时可能会导致业务系统雪崩，这是不能接受的。另外象游戏礼包类、滴滴券等第三方礼券，可能客户账户并不存在（客户并不玩该款游戏，或者客户并没有第三方账户），需要先引导客户创立账户才能发货，这就要求发货系统有暂存奖品信息，具有延后发货的能力。
发货系统采用开源的 RocketMQ 消息中间件作为异步消息队列，暂存发货请求，再由礼券发货板块根据各业务的限速配置均匀地调用业务接口进行发货。
柔性解决：
礼券类奖品通过异步方式发放到客户账户，在除夕高峰值可能发放速度跟不上抽奖速度，会延后少量时间才能到账，这对不明真相客户可能会造成困扰。因而在客户中奖信息页面中，会提醒客户 24 小时（或者 48 小时）到账。发货过程的每个步骤，都有可以异常失败，导致发货不成功，因而在物品详细页面的按钮支持屡次发起发货，在“礼券发货”板块根据发货状态，可以屡次尝试发货，并保证一个奖品只发放一次。
保护业务系统：
前面已经提过，发货系统通过异步消息队列，将抽奖系统与业务开发隔离开，抽奖洪峰不会直接影响业务系统，对业务系统起来隔离保护作用。
礼券发货板块针对每个业务单独配置限速阈值，对各业务的发货严格以不超过限速阈值的速度发放奖品，假如业务有超时或者提醒超速，再按肯定比较再减速。
礼券发货板块首先会到存储系统检查奖品能否真实有效，再到发货状态存储检查状态能否正常，只有真正需要的发货的奖品才向业务系统发起发货请求，确保发货的有效性，避免错发和多发。
最终一致性：
因为采用异步发货，抽奖时刻奖品不能保证立即发放到客户账户中。但客户的奖品不会丢失，通过在异步队列中暂存，礼券发货板块逐渐以合适的速度将奖品发放到客户账户中。
假如发货过程中有延时或者失败，客户可以通过屡次领取提起发货请求，系统支持屡次提交。
假如屡次发货依然失败，对账工具第 2 天会从流水系统中将客户抽奖数据与发货数据进行对账，对发货异常客户再次发起发货。假如对账依然失败，则提示管理人员介入解决。
五、手机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 红包地图中的红包显示。
六、红包创新玩法挑战
春节红包大战，从企业红包演变到刷一刷红包、个性化红包和 AR 红包，玩法不断创新，客户体验更好，活跃度提升，参加人数也从 2 亿增长到 17 年春节的 3.42 亿。
6.1、个性化红包
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.2、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 缓存来处理该问题，一个进程负责将采集到的数据写到缓存，另一组进程提供查询服务。另外，还可以根据存储层的压力，适当地调整采集的频率，使得统计数据尽可能实时。
七、本文小结
自 2015 年起，历年除夕当天 QQ 红包收发情况如下表所示，可以看出，参加人数和红包首发总个数都是节节升高。
QQ 红包业务复杂，海量访问，涉及业务多，流程长，项目的成功离不开相关兄弟部门的大力支持和能力合作，特别感谢即通产品部、财付通、即通平台部、SNG 市场部、SNG 商业广告中心、增值渠道部、社交客户体验设计部、集团市场与公关部、增值产品部、社交与效果广告部、网络质量部、即通综合部、架构平台部、社交平台部、网络经营部等 15 个兄弟部门相关同事的付出和给力支持。
附录：更多相关文章
[1] QQ、微信团队原创技术文章：
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》
《微信团队分享：微信手机端的全文检索多音字问题处理方案》
《腾讯技术分享：Android版手机QQ的缓存监控与优化实践》
《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》
《微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》
《腾讯技术分享：Android手Q的线程死锁监控系统技术实践》
《微信团队原创分享：iOS版微信的内存监控系统技术实践》
《让互联网更快：新一代QUIC协议在腾讯的技术实践分享》
《iOS后端唤醒实战：微信收款到账语音提示技术总结》
《腾讯技术分享：社交网络图片的带宽压缩技术演进之路》
《微信团队分享：视频图像的超分辨率技术原理和应用场景》
《微信团队分享：微信每日亿次实时音视频聊天背后的技术解密》
《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《腾讯团队分享：手机QQ中的人脸识别酷炫动画效果实现详解》
《腾讯团队分享 ：一次手Q聊天界面中图片显示bug的追踪过程分享》
《微信团队分享：微信Android版小视频编码填过的那些坑》
《微信移动端的本地数据全文检索优化之路》
《企业微信用户端中组织架构数据的同步升级方案优化实战》
《微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉》
《QQ 18年：解密8亿月活的QQ后端服务接口隔离技术》
《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
《以手机QQ为例讨论手机端IM中的“轻应用”》
《一篇文章get微信开源手机端数据库组件WCDB的一切！》
《微信用户端团队负责人技术访谈：如何着手用户端性能监控和优化》
《微信后端基于时间序的海量数据冷热分级架构设计实践》
《微信团队原创分享：Android版微信的臃肿之困与板块化实践之路》
《微信后端团队：微信后端异步消息队列的优化更新实践分享》
《微信团队原创分享：微信用户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《微信Mars：微信内部正在使用的网络层封装库，即将开源》
《如约而至：微信自用的手机端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万连接、支撑微信8亿客户的后端框架基石 [源码下载]》
《微信新一代通信安全处理方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后端保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后端保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《微信海量客户背后的后端系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后端处理方案》
《微信朋友圈海量技术之道PPT [附件下载]》
《微信对网络影响的技术实验及分析（论文全文）》
《一份微信后端技术架构的总结性笔记》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《快速裂变：见证微信强大后端架构从0到1的演进历程（一）》
《快速裂变：见证微信强大后端架构从0到1的演进历程（二）》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《全面总结iOS版微信更新iOS9遇到的各种“坑”》
《微信团队原创资源混淆工具：让你的APK立减1M》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《Android版微信安装包“减肥”实战记录》
《iOS版微信安装包“减肥”实战记录》
《手机端IM实践：iOS版微信界面卡慢监测方案》
《微信“红包照片”背后的技术难题》
《手机端IM实践：iOS版微信小视频功能技术方案实录》
《手机端IM实践：Android版微信如何大幅提升交互性能（一）》
《手机端IM实践：Android版微信如何大幅提升交互性能（二）》
《手机端IM实践：实现Android版微信的智能心跳机制》
《手机端IM实践：WhatsApp、Line、微信的心跳策略分析》
《手机端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《手机端IM实践：iOS版微信的多设施字体适配方案讨论》
《信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑》
《腾讯信鸽技术分享：百亿级实时消息推送的实战经验》
《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》
《IPv6技术详解：基本概念、应用现状、技术实践（下篇）》
《腾讯TEG团队原创：基于MySQL的分布式数据库TDSQL十年锻造经验分享》
《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
《理解iOS消息推送一文就够：史上最全iOS Push技术详解》
《腾讯技术分享：微信小程序音视频技术背后的故事》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《微信多媒体团队梁俊斌访谈：聊一聊我所理解的音视频技术》
《腾讯音视频试验室：使用AI黑科技实现超低码率的高清实时视频聊天》
《腾讯技术分享：微信小程序音视频与WebRTC互通的技术思路和实践》
《手把手教你读取Android版微信和手Q的聊天记录(仅作技术研究学习)》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《腾讯技术分享：GIF动图技术详解及手机QQ动态表情压缩技术实践》
《微信团队分享：Kotlin渐被认可，Android版微信的技术尝鲜之旅》
《全面解密QQ红包技术方案：架构、技术实现、手机端优化、创新玩法等》
>>?更多同类文章 ……
[2] 有关QQ、微信的技术故事：
《技术往事：微信估值已超5千亿，雷军曾有机会收编张小龙及其Foxmail》
《QQ和微信凶猛成长的背后：腾讯网络基础架构的这些年》
《闲话即时通讯：腾讯的成长史本质就是一部QQ成长史》
《2017微信数据报告：日活跃客户达9亿、日发消息380亿条》
《腾讯开发微信花了多少钱？技术难度真这么大？难在哪？》
《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》
《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》
《技术往事：“QQ群”和“微信红包”是怎样来的？》
《开发往事：深度讲述2010到2015，微信一路风雨的背后》
《开发往事：微信千年不变的那张闪屏图片的由来》
《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》
《一个微信实习生自述：我眼中的微信开发团队》
《初次揭秘：QQ实时视频聊天背后的神秘组织》
《为什么说即时通讯社交APP创业就是一个坑？》
《微信七年回顾：历经多少质疑和差评，才配拥有今天的强大》
《前创始团队成员分享：盘点微信的前世今生——微信成功的必然和偶然》
《即时通讯创业必读：解密微信的产品定位、创新思维、设计法则等》
《QQ的成功，远没有你想象的那么顺利和轻松》
《QQ现状深度剖析：你还认为QQ已经被微信打败了吗？》
《[技术脑洞] 假如把14亿中国人拉到一个微信群里技术上能实现吗？》
《QQ和微信止步不前，意味着即时通讯社交应用创业的第2春已来？》
《那些年微信开发过的鸡肋功能，及其带给我们的思考》
《读懂微信：从1.0到7.0版本，一个主流IM社交工具的进化史》
>>?更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-2202-1-1.html）
1. 本站所有资源来源于用户上传和网络，如有侵权请邮件联系站长！
2. 分享目的仅供大家学习和交流，您必须在下载后24小时内删除！
3. 不得使用于非法商业用途，不得违反国家法律。否则后果自负！
4. 本站提供的源码、模板、插件等等其他资源，都不包含技术服务请大家谅解！
5. 如有链接无法下载、失效或广告，请联系管理员处理！
6. 本站资源售价只是摆设，本站源码仅提供给会员学习使用！
7. 如遇到加密压缩包，请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » 全面解密QQ红包技术方案：架构、技术实现、手机端优化、创新玩法等
