费尽洪荒之力集齐五福，并在1月28日通过与1亿6千7百多万人进行厮杀，最后取得的战果如下，显然在营销背后666元的幸运者只能属于极少数人。
截止到1月28号，支付宝蚂蚁森林的用户已经超过2亿，种下的真实树木已经超过99万棵。五福效应，带动了蚂蚁森林用户的成倍增长，这可以总结为一场广告费用极低、覆盖范围极广、宣传产品丰富的营销活动。
显然在这次红包争夺战中，绝大多数人深深的感到受伤了，这样的结局其实我们早就预料到了的。我们之所以执意要去集齐五福，并参与分红包，是因为抢红包已经成了春节不可或缺的习俗。
说起红包，我们不得不提微信红包，或许我们在在支付宝VR红包中受伤的心，可以在微信红包中得到抚慰，毕竟微信红包相对根深苗正。让我们看看春节期间微信红包的分发数据统计，图片数据来源于大众网和数据分析和数据挖掘公众号。
微信1月28日发布的除夕大数据报告显示，除夕全天微信红包收发量共计142亿个，较猴年增长75%多。1月28日(初一)零点整。红包收发达到76万个每秒，为当日峰值。
从年龄层而言,数据显示，2016年全年80后发给80后、90后发给90后、70后发给70后，成为红包流向最热门的三条线路。
下面我们从技术角度简单看一下发抢红包整个过程，假设当有人在群里发了一个N人的红包，总金额M元，后台大概发生的事情如下 (该部分内容整理自编程学习网)。
一、发红包后台操作：
在数据库中增加一条红包记录，存储到腾讯CKV海量分布式数据平台，设置过期时间。值得一提的是，CKV是腾讯自主研发的高性能、低延时、持久化、分布式KV存储服务。在腾讯的微信平台、开放平台、腾讯云、腾讯游戏和电商平台广泛使用，日访问量超过万亿次。
在Cache（推测是腾讯内部KV数据库，基于内存，有内核态网络处理模块，以内核模块形式提供服务）中增加一条记录，存储抢红包的人数N。
二、抢红包后台操作：
抢红包分为抢和拆，抢操作在Cache层完成，通过原子减操作进行红包数递减，到0就说明抢光了，最终实际进入后台拆操作的量不大，通过操作的分离将无效请求直接挡在Cache层外面。这里的原子减操作并不是真正意义上的原子减操作，是其Cache层提供的CAS，通过比较版本号不断尝试，存在一定程度上的冲突，冲突的用户会放行，让其进入下一步拆的操作，这也解释了为啥有用户抢到了拆开发现领完了的情况。
拆红包在数据库完成，通过数据库的事务操作累加已经领取的个数和金额，插入一条领取流水，入账为异步操作，这也解释了为啥在春节期间红包领取后在余额中看不到。拆的时候会实时计算金额，其金额为1分到剩余平均值2倍之间随机数，一个总金额为M元的红包，最大的红包为 M * 2 /N（且不会超过M），当拆了红包后会更新剩余金额和个数。财付通按20万笔每秒入账准备，实际只到8万每秒。
分离抢和拆操作的总思路是设置多层过滤网，层层筛选，层层减少流量和压力。这个设计最初是因为抢操作是业务层，拆是入账操作，一个操作太重了，而且中断率高。 从接口层面看，第一个接口纯缓存操作，搞压能力强，一个简单查询Cache挡住了绝大部分用户，做了第一道筛选，所以大部分人会看到已经抢完了的提示。请搜索“ICT_Architect”关注“架构师技术联盟”公众号，获取更多精彩内容。
