架构09 社交软件红包技术01
4.1、接入层
接入层是红包后台服务的大门，负责抽奖请求预处理，确保有效的请求才透传给后端服务。为保证自身高可用、高稳定，接入层还可实时控制手机 QQ 请求频率，避免海量请求压垮接入层，出现不可控局面。
在海量服务场景下，为避免网络开销，方便后端服务使用 cache 提升性能，接入层采用了一致性 Hash 寻址，保证同一个用户的请求只会落在同一台红包抽奖逻辑机器处理
4.2、抽奖系统
4.2.1基本介绍
抽奖系统作为 QQ 红包的核心系统，在承接用户抽奖请求，按设计合理的几率完成抽奖操作，将抽奖结果安全落地保存，并顺利发货等过程中，起到了关键作用。面对海量抽奖请求，如何及时作出响应，是抽奖系统面临的难题。
为了解决这些问题，我们采用了一些设计方法：
- 1）在接入层采用一致性 Hash 算法：同一用户的抽奖请求只会转发到相同的抽奖系统处理 ;
- 2）抽奖系统采用缓存机制：在加快抽奖过程的同时也减少了对存储层的访问压力；
- 3）奖品配额机制：平滑抽奖过程，各类奖品按比例有序抽中；
- 4）流水和对账机制：保证抽奖数据最终无差错发放到用户账户中
缓存机制
业务要求在每个刷一刷的活动中，能对用户中奖次数、参与时间（30 秒）进行限制。如果用户的每个抽奖请求到来时，先到存储层获取用户的中奖历史信息，再判定用户是否还有抽奖资格，在海量高并发的请求场景下，势必会对存储层造成巨大的压力。所以这里我们引入了本地内存缓存层，用于保存用户的中奖历史信息，每次请求到来时，会先到缓存层获取用户的中奖历史信息，如果在缓存层没找到，才会到存储层获取，这样就不会对存储层造成太大的压力，同时也能实现业务的需求。缓存层我们采用开源 Memcached 组件实现，也可以使用本地缓存
4.2.4协议处理模块
由于手机 QQ 后台既要处理客户端的二进制请求，也要处理其他 Web 系统的 HTTP 请求，所以协议处理模块的首要任务就是兼容各种格式的协议，给后端模块一个最简单的结构。为此我们制定了 Protobuf 格式的交互协议（兼容 JSON 格式，会统一转换成 Protobuf 处理），传给后端模块。
需要说明的是，只要是因为配额限制发放红包失败，我们都会继续尝试给用户发放其他奖品的红包，直到没有奖品可以发放，这样我们就能保证把奖品尽可能发放出去。
由于流水需要记录用户中奖的信息和领用的的情况，数据量巨大，所以抽奖逻辑层本地采用顺序写文件的方式进行记录。抽奖逻辑层会定期的把本地的流水文件同步到远程流水系统进行汇总和备份，同时，流水系统会对领用失败的流水进行重做，发送请求到抽奖逻辑层，抽奖逻辑层会调用发货系统的接口完成发货操作。
考虑这样一种场景，如果请求是在 1 秒的最开始全部涌到业务方，受限于业务方不同的架构实现，有可能会触发业务方的频率限制或者是过载保护。为此，我们将频限粒度调整到百毫秒，这样奖品就会在 1 秒内相对平均的发放，从而解决了上述问题。
4.3、QQ 红包发货系统
QQ 红包奖品包括现金和礼券两类，现金对接财付通，礼券又分腾讯公司内部虚拟物品和第三方礼券。最终礼品落地到用户的账户（QQ 钱包余额、QQ 卡券或第三方系统账户）中。虽然抽奖系统有作平滑处理，但持续长时间的大流量发货，也可能导致业务系统不能正常提供峰值下的服务能力。如何承上启下，既预防抽奖系统不能平滑地发货导致压跨发货系统（自身），又能保护后端业务系统的情况下，以较快的速度将奖品安全发放到账，是发货系统的设计要点。
发货系统设计遵循以下策略：
- 1）快慢分离；
- 2）异步削峰；
- 3）柔性处理；
- 4）保护业务系统；
- 5）最终一致性。
|
本文来自腾讯QQ技术团队工程师许灵锋、周海发的技术分享。 一、引言自 2015 年春节以来，QQ 春节红包经历了企业红包（2015 年）、刷一刷红包（2016 年）和 AR 红包（2017 年）几个阶段，通过不断创新玩法，活跃度节节攀升，成为春节一大玩点，给火红的春节带来一抹亮色。2017 年除夕，AR 红包、刷一刷红包再创新高，抢红包用户数达 3.42 亿，共刷出红包 37.77 亿个。 那么，QQ 红包的技术方案究竟是怎样的？其整体架构如何？重要的系统是如何设计的？为了保证用户的体验，手机 QQ 移动端做了哪些优化？今年的 QQ 红包又做了哪些新的尝试，遇到的问题是如何解决的呢？本文将从架构开始，到手机 QQ 移动端优化，再到个性化红包和 AR 新玩法，为大家全面解密 QQ 红包技术方案。 补充说明：QQ团队的另一篇分享《社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等》，从产品角度进行了不一样的讲述，可以一读。 二、关于作者
turboxu（许灵锋）：2006 年加入腾讯，会员体系后台负责人，从事过 MIS 系统、网络安全、滔滔（空间说说）、WAP 音乐、超 Q、会员等项目，对开源组件、虚拟化感兴趣，致力于推动 Docker 虚拟化和开源组件的应用和实践。 haifazhou（周海发）：2011 年加入腾讯，从事 IM 基础系统开发和运营，先后参与过 PTLogin 统一登录和消息漫游存储改造项目，连续三年参与并负责 QQ 春节红包后台系统架构设计，在海量分布式高性能系统设计方面积累了多年经验。 三、系列文章❶ 系列文章目录：
❷ 其它相关文章：
四、QQ 红包整体架构及重要系统QQ 春节红包以一个又一个的整点刷红包活动贯穿年三十，在除夕夜达到顶峰，是典型的海量用户秒杀场景，如何应对海量的用户刷红包洪流，保证刷得爽，红包安全到账，是 QQ 红包设计要解决的关键技术难点。另外，红包项目涉及手机 QQ 移动端、手机 QQQ 后台、QQ 钱包（财付通）系统、礼券系统、公众号等诸多业务系统，流程长且多，各系统性能吞吐量差异很大，如何保证各系统形成一个有机整体，协调高效提供服务，也是难点之一。 下图为简化后 QQ 红包的架构，包括：接入层、抽奖系统、存储系统、发货系统、公众号消息通知和 CDN 资源等几部分，请大家先有一个整体的认知，便于阅读下文。
本节将重点讲解接入层、抽奖系统和发货系统。 4.1、接入层接入层是红包后台服务的大门，负责抽奖请求预处理，确保有效的请求才透传给后端服务。为保证自身高可用、高稳定，接入层还可实时控制手机 QQ 请求频率，避免海量请求压垮接入层，出现不可控局面。 在海量服务场景下，为避免网络开销，方便后端服务使用 cache 提升性能，接入层采用了一致性 Hash 寻址，保证同一个用户的请求只会落在同一台红包抽奖逻辑机器处理。 4.2、抽奖系统4.2.1基本介绍抽奖系统作为 QQ 红包的核心系统，在承接用户抽奖请求，按设计合理的几率完成抽奖操作，将抽奖结果安全落地保存，并顺利发货等过程中，起到了关键作用。面对海量抽奖请求，如何及时作出响应，是抽奖系统面临的难题。 为了解决这些问题，我们采用了一些设计方法：
抽奖系统的架构如下图所示： 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 红包的抽奖算法其实并不复杂，但是能否满足产品需要非常重要。 我们的设计思路是至少需要满足如下需求：
为此，我们设计了如下的抽奖流程算法： 需要说明的是，只要是因为配额限制发放红包失败，我们都会继续尝试给用户发放其他奖品的红包，直到没有奖品可以发放，这样我们就能保证把奖品尽可能发放出去。 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 卡券或第三方系统账户）中。虽然抽奖系统有作平滑处理，但持续长时间的大流量发货，也可能导致业务系统不能正常提供峰值下的服务能力。如何承上启下，既预防抽奖系统不能平滑地发货导致压跨发货系统（自身），又能保护后端业务系统的情况下，以较快的速度将奖品安全发放到账，是发货系统的设计要点。 发货系统设计遵循以下策略：
发货系统架构如下图所示： 快慢分离： 现金和礼券后端的系统完全不同，现金通过 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 红包地图中的红包显示。
为了尽量不影响用户发红包体验，个性化红包在架构和运营上作了很多解藕和柔性设计。包括个性字体提前绘制，资源预加载，功能开关和容灾柔性处理等。
6.1.2 字体提前绘制
个性化红包支持所有简体与繁体汉字，并支持部分简体汉字转换成繁体汉字，为了改善使用“姓氏红包”用户的体验，我们把常用的 300 个姓氏，使用预生成的方式，在用户手机 QQ 空闲的时候生成常用的姓氏图片保存到本地。其他的非常用姓氏，在展示的时候合成，合成一次保存在本地，下次在本地读取。
手机 QQ 移动端在空闲时绘制好字体贴图，支持定时更新背景图和字体库，对非常用字，则启动个性化字体引擎生成对应的个性化贴图。
用户在发放或收到红包时，个性化背景和字体贴图已经生成好，不需要再生成，收发红包流畅体验无损。
资源预加载
个性化红包封素材提前制作好，上传到 CDN 网络，手机 QQ 在空闲时提前从 CDN 下载素材文件，并定时检查素材更新情况，及时更新。
功能开关
用户是否设置个性红包，选择的个性红包贴图样式，是否启用个性红包等信息，如果每次判断都从后台拉取，势必增加后台压力。用户对个性红包的设置信息，其实变化不大，并且访问红包商场实时设置的状态的结果在手机 QQ 移动端是存在的。因此我们设计将这些用户状态 FLAG 在手机 QQ 登录时，从后台拉取一次后保存在手机 QQ 移动端，在发红包的过程中将 FLAG 信息传递到下游服务中，通过红包商城设置的个性化红包标志，实时更新手机 QQ本地配置。
这样的设计有几个好处：
- 1）用户的个性化设置不再依赖于后台，发红包过程完全本地操作，没有任何延时，不影响红包的发放；
- 2）FLAG 标志可以作为容灾开关，如果临时取消个性红包，或后台故障，可以临时屏蔽个性红包功能，恢复为默认红包样式，保障任何时刻红包功能正常可用；
- 3）FLAG 标志可支持扩展，在红包后台可以根据扩展，支持付费红包样式（付费购买）、特权红包样式（如超会专享）等，支持红包商城扩展各种各样的个性化红包；
- 4）除了从后台拉取 FLAG，当业务有调整导致 FLAG 变化，红包后台可以向手机 QQ 移动端主动 push FLAG 状态，使得用户及时感知变化，进一步增强用户使用体验。
容灾柔性处理
相对于手机 QQ 平台功能，个性红包系统相对独立，运营和更新很快，系统各功能组件出现问题的几率可能较多，如果个性红包业务出现问题，而影响到正常红包发放或手机 QQ 功能的使用，会对 QQ 口碑造成很大负面影响。我们在系统中设计了多处容灾和柔性处理措施，在个性红包业务异常时，能降级提供服务，最差时取消个性红包功能。
- 柔性措施一：用户登录时拉取个性红包 FLAG 失败时，采用默认红包样式；
- 柔性措施二：红包后台向个性化红包后台拉取个性化设置鉴权详情（是否付费、是否会员专享等）时，如果拉取异常，采用默认红包样式；
- 柔性措施三：个性化红包由用户输入姓氏，指定显示文字，可能遇到敏感字或需要临时下线，可以通过向手机 QQ 下发 FLAG 标志，临时取消个性红包功能，恢复到默认红包样式。
AR 红包
6.2.1概述
AR 红包是“LBS+AR 天降红包”的简称，这个创新的玩法得到了用户的一致好评，参与用户 2.57 亿次，共计领取红包和礼券 20.5 亿个，获得了口碑和活跃的双丰收。
缓存设计
LBS+AR 红包与以往的红包最大的不同在于多了一重地理位置关联，全国有上千万的地理位置信息，结合活动的任务奖品数据产生了海量的配置数据，而这些数据都需要快速实时读取。这是系统设计的一大挑战。
配置数据有以下特点：
- 1）数据量很大（亿级），数据间有紧密的关联，我们采用 MySQL 数据库集群存储，并构建有 Web 可视化配置投放平台，实现自动容灾和备份的功能；
- 2）“一次配好，到处使用”，配置读量远高于写量，基本思想是设计开发一种缓存，放弃写性能，将读性能优化到极致。
上千兆的配置数据，如何供抽奖系统快速检索？考虑到业务使用场景、配置数据大小及 MySQL 性能，可以采用预先构建全量缓存并进行有序组织，由同步模块负责将构建好的配置数据同步到抽奖系统，供业务进程直接使用。为保证配置数据完整性，构建缓存采用双 Buffer 设计，只有构建或同步完成后才切换到最新配置。
架构09 社交软件红包技术01相关推荐
- 架构16 社交软件红包技术09
社交软件红包技术解密(九):谈谈手Q红包的功能逻辑.容灾.运维.架构等 b. 对账补送解决不少发的问题: 发货失败是不可避免的,诸如网络波动/游戏方发货接口故障之类的问题都可能导致调用发货接口失败.在 ...
- 架构17 社交软件红包技术10
社交软件红包技术解密(十):手Q客户端针对2020年春节红包的技术实践 1)入口配置: 包含活动入口吊坠.小程序入口Banner和一些控制开关等配置内容.春节红包活动横跨小年.除夕.大年初一,每天有4 ...
- 架构11 社交软件红包技术03
四.摇一摇红包系统组成 红包系统由三部分组成: 1)信息流: 2)业务流: 3)资金流. 这三部分在组织架构上由不同的后台团队完成: 1)信息流--微信后台: 2)业务流--微信支付后台: 3)资金流 ...
- 架构12 社交软件红包技术05
如上图所示,微信红包的业务包含包.发.抢.拆.查询发送红包和收红包数量,其中最关键的步骤是发红包和抢红包. 微信红包是微信支付的商户,微信红包这个商户出售的是钱.发红包用户在微信红包平台使用微信支付购 ...
- 即时通讯技术文集（第15期）：IM跨平台和社交软件红包技术 [共19篇]
为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第15 期. [- 1 -] IM跨平台技术学习(一):快速了解新一代跨平台桌面技术--Elec ...
- 微博红包技术探究：架构、防刷、监控和资源调度
编者按 每年的红包大战都是用户的现金盛宴,对于整个系统却是残酷的考验. 与传统意义上的红包相比,近两年火起来的"红包",似乎才是如今春节的一大重头戏.历经上千年时代传承与变迁,春节 ...
- 全面解密QQ红包技术方案：架构、技术实现、移动端优化、创新玩法等
本文来自腾讯QQ技术团队工程师许灵锋.周海发的技术分享. 一.引言 自 2015 年春节以来,QQ 春节红包经历了企业红包(2015 年).刷一刷红包(2016 年)和 AR 红包(2017 年)几个 ...
- 全面解密QQ红包技术方案：架构、技术实现、移动端优化、创新玩法等...
本文来自腾讯QQ技术团队工程师许灵锋.周海发的技术分享. 一.引言 自 2015 年春节以来,QQ 春节红包经历了企业红包(2015 年).刷一刷红包(2016 年)和 AR 红包(2017 年)几个 ...
- 【系统架构设计师】软考高级职称，一次通过，倾尽所有，2013年下半年系统架构设计师考试论文真题（论软件可靠性设计技术的应用）
[系统架构设计师]软考高级职称,一次通过,倾尽所有,看完这篇就够了,学习方法和技巧这里全都有. 2013年下半年系统架构设计师考试论文真题(论软件可靠性设计技术的应用) 论软件可靠性设计技术的应用 随 ...
最新文章
- NBT：超高速细菌基因组检索技术
- [php]如何做到高并发优化
- 【poj解题】1308
- awk和cut分割字符区别
- 手把手教你实现一个 JSON 解析器！
- 掌握Angular2的服务(service)
- 检索COM类工厂中CLSID为{000209FF-0000-0000-C000-000000000046}的组件时失败，原因是出现以下错误: 80070005...
- markdown表格在github/gitee中合并单元格
- REVERSE-PRACTICE-JarvisOJ-2
- 回归的误差服从正态分布吗_盘点10大回归类型：总有一款深得你心
- Window服务器可安装的live messager最新版本-20090826
- 项目实训第二周（车道线检测）
- python 实例化过程_python实例化对象的具体方法
- 不小心删除数据--利用MySQL的binlog恢复数据
- c语言银行排队系统链表,银行预约排队系统(数据结构问题)
- C# 在PPT幻灯片中创建图表
- 车路协同 智能路侧决策系统总体架构及应用
- c语言两位数码管动态显示,十天学会单片机和c语言编程数码管动态显示.pptx
- 预充电电路工作原理_课堂 | 为什么锂电池在充电过程中首先要进行预充电
- 创意云渲染农场与《熊出没》