鑫红包实现原理以下内容来自QCon某高可用架构群后台聊天记录：朋友咨询微信红包架构，从讲解中得到以下内容和官方或非官方同学的讨论在讨论过程中，很多同学发了红包来测试现网算法。当有人给群里N个人发了一个红包，总金额为M元，后台发生的情况如下：1.红包后台操作：在数据库中添加一条红包记录，存入CKV中.设置过期时间；在Cache中添加一条记录（可能是腾讯内部的kv数据库，基于内存，带登陆，带内核态网络处理模块，以内核模块的形式提供服务）用来存储抢红包人数N2.抢红包后台操作：抢红包分为抢红包和拆红包。抓取操作在Cache层完成，通过原子减法操作减少红包数量。当它到达0时，意味着所有的红包都被抢走了。说到底，后台实际拆解操作量并不大。通过操作分离，直接在Cache层外Block无效请求。这里的原子减法操作并不是真正意义上的原子减法操作，而是其Cache层提供的CAS。通过比较版本号，不断尝试，存在一定程度的冲突。冲突的用户会让它进入下一步。操作，这也解释了为什么有的用户抢了之后发现已经收完了。红包的拆解是在数据库中完成的。通过对数据库的交易操作，累计收到红包的个数和金额，并在账户中插入一张收据，属于异步操作。这也解释了为什么春节期间领取红包后余额中看不到红包的原因。拆解时会实时计算金额，金额为剩余平均值的1点到2倍之间的随机数，总金额为M元的红包，最佳红包为M*2/N（且不会超过M），当红包被打开时，会更新剩余金额和数量。财付通准备每秒处理20万笔交易，但实际速度仅为每秒8万笔。FAQ既然抓的时候有原子减少，难道抓了就不能拆了吗？这里的原子减法并不是真正意义上的原子操作，而是Cache层提供的CAS，通过比较版本号不断尝试。如果缓存和数据库关闭怎么办？主备+对账有没??有红包数没了，余额还在的情况？不，程序***会有一个takeall操作和一个异步协调保证。为什么要把抢和拆分开呢？总体思路是设置多层过滤器，逐层过滤，逐层降低流量和压力。这样设计本来是因为抢操作是业务层，拆是入账操作。一次操作量太大，中断率高。从接口来看，第一个接口是纯缓存操作，压力能力强。一个简单的查询Cache屏蔽了大部分用户，第一遍过滤，所以大部分人会看到抢购已售罄的提示。.有没有抢到后发红包或者提现的攻略？大额优先入场攻略数据证明每个红包的概率是否相等？不是绝对相等，只是简单的拍脑袋算法。拍脑袋算法，会不会有两个***？会有相同的数量，但只有一张幸运票，即先得到的那张。发红包的人的钱会被冻结吗？直接实时扣款，不冻结。使用实时计算量有哪些注意事项？实时更有效率，预算效率低下。预算还包括额外的存储空间。因为红包只占用一条记录，有效期也只有几天，所以不需要太多的空间。即使压力很高，水平缩放机器也是如此。
