你所不知道的微信红包(四)——后台分析

4后台

4.1 数据库

以下关系型数据库设计的字段是基于少量请求下,我们模拟红包系统的可行方案,并没有考虑高并发、分库分表以及缓存的情况,关于这部分内容可以查看本文4.4部分整理一些大神的回答作为了解。

(1)用户信息数据表user_info

userID、红包ID、祝福语、红包类型、红包个数、红包金额、超时

(2)用户钱包数据表user_wallet

userID、money、银行卡ID等其他字段

(3)发送红包数据表red_send

红包ID、senderID、红包个数、红包金额、祝福语、最佳手气、发出时间

(4)接收红包数据表red_receive

红包ID、receiver、接收时间、接收金额

4.2 随机算法

很多人说红包序列是预先在手机发出去的时候已经产生好随机序列,其实这样会产生大量的数据库读写操作,内存读的速度以DDR3-2400为例,能达到17G/s,写的速度达到18G/s(参考文献:http://m.it168.com/article_1410707_p5.html)。而硬盘数据库的读写速度最多达到133MB/s。可见大量的从硬盘读写数据不但容易使硬盘损坏,更达不到高并发的读写需求。所以预先生成随机序列写入数据库,用户抢的时候再读出红包金额并将用户信息写入数据库并不科学。所以采用内存实时计算随机序列并异步写入硬盘数据库储存的方法。基于内存的随机序列是伪随机序列,他并不是真正的随机,而是根据种子通过一定的算法计算出来的值,只要种子不变,每次计算出来的值的序列是一致的。也就是说当红包指纹(ID或者ID+时间戳或者其他算法生成)一定时,计算出来的序列是一致的,这样子就不用储存在数据库,而是实时计算,第一次取序列的第一个值,第二次取序列的第二个值,如此类推。(更详细的说明可以参考http://www.open-open.com/lib/view/open1430473257443.html)。具体步骤如下(代码以python举例子,没办法知道人家后台用什么语言写的):

以红包ID为种子

>>>red_ID = 1775509988475009

>>>random.seed(red_ID)

群手气红包的最小值为0.01,摇一摇红包的最小值为2.00

>>>min = 1.00

>>>if (红包为群手气红包):

min = 0.01

else(红包为摇一摇红包):

min = 2.00

群手气红包的最大值为剩余红包总额和个数的商的2倍(你可以在群里不停地发红包做回归,记得叫上我去拿红包,哈哈)。

>>>max = (remain_money/remain_num)*2

而摇一摇红包官方给出的计算公式是剩余金额/剩余红包数*n

n主观猜测也是等于2,在这公式基础上再人为控制概率。

方案一:

人为干扰概率的,有人拿到京东618元的红包,动脑子想想,京东店庆是618,这个金额绝对不是随机出来的,而是设定好金额,然后每个金额范围都有一定的概率。

比如说2元—5元概率为85%;5元—20元概率为10%,20元—50元概率为4.99%,618元概率为0.01%。(概率仅作参考,因为样本量太大,官方也没提供数据,这里只是提供其中一种可行的方案,以下代码也只是提供思路,与实际可运行的代码略有差别)

>>>a = random.uniform(0,1)

>>>b,_max,_min = 0

>>>if a < 0.85:

_min = 2.00

_max = 5.00

>>>elif a < 0.95 & a >= 0.85:

_min = 5.00

_max = 20.00

>>>elif a < 0.9999 & a >= 0.95:

_min = 20.00

_max = 50.00

>>>elif a > 0.9999:

_min = 618.00

_max = 618.00

>>>random.uniform(min,max)

方案二:

_min = 2.00

_max = 剩余金额/剩余红包数*n

人为放出618元的彩蛋红包,并且用上述方法设置概率为0.0001%

4.3 红包发出去那一刻发生了什么?

这一部分由于个人的水平限制,未能给出有深度的简介,这里为了文章的完整性,借用胖胖的文章作为说明(胖胖的博客为www.phppan.com)

(1)发红包后台操作:

在数据库中增加一条红包记录,存储到CKV,设置过期时间;

在Cache(可能是腾讯内部kv数据库,基于内存,有落地,有内核态网络处理模块,以内核模块形式提供服务))中增加一条记录,存储抢红包的人数N

(2)抢红包后台操作:

抢红包分为抢和拆,抢操作在Cache层完成,通过原子减操作进行红包数递减,到0就说明抢光了,最终实际进入后台拆操作的量不大,通过操作的分离将无效请求直接挡在Cache层外面。这里的原子减操作并不是真正意义上的原子减操作,是其Cache层提供的CAS,通过比较版本号不断尝试,存在一定程度上的冲突,冲突的用户会放行,让其进入下一步拆的操作,这也解释了为啥有用户抢到了拆开发现领完了的情况。

拆红包在数据库完成,通过数据库的事务操作累加已经领取的个数和金额,插入一条领取流水,入账为异步操作,这也解释了为啥在春节期间红包领取后在余额中看不到。拆的时候会实时计算金额,其金额为1分到剩余平均值2倍之间随机数,一个总金额为M元的红包,最大的红包为 M * 2 /N(且不会超过M),当拆了红包后会更新剩余金额和个数。财付通按20万笔每秒入账准备,实际只到8万每秒。

4.4 Q&A若干整理

(这一部分是网上整理的,不知道如何分类比较好就放在一起了)

① 既然在抢的时候有原子减了就不应该出现抢到了拆开没有的情况?

这里的原子减并不是真正意义上的原子操作,是Cache层提供的CAS,通过比较版本号不断尝试。

② cache和db挂了怎么办?

主备 +对账

③ 有没有红包个数没了,但余额还有情况?

没有,程序最后会有一个take all操作以及一个异步对账保障。

④ 为什么要分离抢和拆?

总思路是设置多层过滤网,层层筛选,层层减少流量和压力。这个设计最初是因为抢操作是业务层,拆是入账操作,一个操作太重了,而且中断率高。 从接口层面看,第一个接口纯缓存操作,搞压能力强,一个简单查询Cache挡住了绝大部分用户,做了第一道筛选,所以大部分人会看到已经抢完了的提示。

⑤ 抢到红包后再发红包或者提现,这里有什么策略吗?

大额优先入账策略

⑥ 有没有从数据上证明每个红包的概率是不是均等?

不是绝对均等,就是一个简单的拍脑袋算法。官方已经在产品经理大会上说明这是个拍脑袋的算法了。

⑦发红包人的钱会不会冻结?

是直接实时扣掉,不是冻结。

⑧ 采用实时算出金额是出于什么考虑?

实时效率更高,预算才效率低下。预算还要占额外存储。因为红包只占一条记录而且有效期就几天,所以不需要多大空间。就算压力大时,水平扩展机器是。详见本文4.2的说明。

⑨ 实时性:为什么明明抢到红包,点开后发现没有?

答:2014年的红包一点开就知道金额,分两次操作,先抢到金额,然后再转账。

2015年的红包的拆和抢是分离的,需要点两次,因此会出现抢到红包了,但点开后告知红包已经被领完的状况。进入到第一个页面不代表抢到,只表示当时红包还有。详见本文Jinkey在第五部分的说明。

⑩ 红包的设计

答:微信从财付通拉取金额数据过来,生成个数/红包类型/金额放到redis集群里,app端将红包ID的请求放入请求队列中,如果发现超过红包的个数,直接返回。根据红包的逻辑处理成功得到令牌请求,则由财付通进行一致性调用,通过像比特币一样,两边保存交易记录,交易后交给第三方服务审计,如果交易过程中出现不一致就强制回归。

? 并发性处理:红包如何计算被抢完?

答:cache会抵抗无效请求,将无效的请求过滤掉,实际进入到后台的量不大。cache记录红包个数,原子操作进行个数递减,到0表示被抢光。财付通按照20万笔每秒入账准备,但实际还不到8万每秒。

? 如何保持8w每秒的写入?

答:多主sharding,水平扩展机器。

? 查询红包分配,压力大不?

答:抢到红包的人数和红包都在一条cache记录上,没有太大的查询压力。

? 一个红包一个队列?

答:没有队列,一个红包一条数据,数据上有一个计数器字段。

? 每领一个红包就更新数据么?

答:每抢到一个红包,就cas更新剩余金额和红包个数。

? 红包如何入库入账?

数据库会累加已经领取的个数与金额,插入一条领取记录。入账则是后台异步操作。

? 入帐出错怎么办?比如红包个数没了,但余额还有?

答:最后会有一个take all操作。另外还有一个对账来保障。

下一篇:你所不知道的微信红包(五)——交互分析

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,905评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,140评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,791评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,483评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,476评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,516评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,905评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,560评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,778评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,557评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,635评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,338评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,925评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,898评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,142评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,818评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,347评论 2 342

推荐阅读更多精彩内容

  • 国家电网公司企业标准(Q/GDW)- 面向对象的用电信息数据交换协议 - 报批稿:20170802 前言: 排版 ...
    庭说阅读 10,849评论 6 13
  • 雪压苍松横梗瘦,风怜劲柏竖枝惊。 霜天落叶飘无意,银岭丛峦静有声。 炉火厅堂温旧酒,雀飞楼槛迎新晴。 炊烟袅袅呼肴...
    山上人家123阅读 457评论 9 18
  • 生活中,有两种人,一种是内向性格,善于向内寻找快乐;一种是外向性格,善于向外界寻求认可……不管是什么性格,我们都需...
    未竹阅读 269评论 1 4
  • 小时候家里除了没有钱,啥吃的都有,有菜有水果有鱼有肉有骨头,邻居小孩经常拿着碗等在我家门口,如果有什么我不想吃的,...
    暖笑如云阅读 495评论 0 2