Python手机微信红包优化算法案例

#!/usr/bin/env python

# coding: utf-8

import random

# m : 红包个数

# n : 红包人数

# packet : 本次抢到的金额 , 所有金额以分为计算

def redEnvelope(m,n):

remain = m*100 #剩余金额

nn = n #剩余人数

for i in range(1,n):

if remain == 0 :

print('已经全部发完了')

else :

packet = random.randint(1,int(remain/nn*2))

nn -= 1

remain -= packet

print('第%d位成员红包的金额为%.2f元 , 余额为%.2f , 剩余%d人未领红包'%(i,packet/100,remain/100,nn))

print('最后一个成员红包金额为%.2f元'%(remain/100))

Python启用方式

redEnvelope(100,4)

运作結果

第1位成员红包的金额为45.65元 , 账户余额为54.35 , 剩余3人未领红包

第2位成员红包的金额为16.10元 , 账户余额为38.25 , 剩余2人未领红包

第3位成员红包的金额为20.98元 , 账户余额为17.27 , 剩余1人未领红包

最后一个成员红包金额为17.27元

概述：2014年手机微信红包应用数据库查询抵抗全部总流量，2015年应用cache抗总流量。

手机微信的金额何时算？

答：手机微信金额是拆的那时候即时算出去，并不是事先分派的，选用的是纯运行内存测算，不用费用预算室内空间储存。。

采用即时测算金额的考虑到：费用预算必须占储存，即时高效率很高，费用预算才高效率低。

实用性：为何本来抢到红包，打开后发觉沒有？

答：2014年的红包一点开就了解金额，分2次实际操作，先抢到金额，随后再转帐。

2015年的红包的拆和抢是分离出来的，必须点2次，因而会出現抢到红包了，但打开后告之红包早已被领完的情况。进到到第一个网页不意味着抢到，只表达那时候红包也有。

分派：红包里的金额咋算？为何出現每个红包金额相距挺大？

答：任意，信用额度在0.01和剩余均值*2中间。

比如：发100元钱，一共10个红包，那麼均值是10元钱一个，那麼传出来的红包的信用额度在0.01元～20元中间起伏。

当前边3个红包一共被领了40元钱时，剩余60元钱，一共7个红包，那麼这7个红包的信用额度在：0.01～(60/7*2)=17.14中间。

留意：这儿的优化算法是每被抢一个后，剩余的会再度实行上边的那样的优化算法(Tim教师也感觉所述优化算法太繁杂，不知道根据哪些的考虑到)。 那样算下去，会超出最初的所有金额，因而来到最终面假如不足那么算，那麼会采用以下优化算法：确保剩余客户能取得最少1一分钱就可以。 假如前边的人手气好不太好，那麼后边的账户余额越大，红包信用额度也就会越多，因而具体几率一样的。

红包的设计方案

答：手机微信从qq钱包获取金额信息郭莱，转化成数量/红包种类/金额放进redis群集里，app端将红包ID的恳求放进恳求序列中，假如发觉超出红包的数量，立即回到。依据红包的裸祭解决取得成功获得令牌恳求，则由qq钱包开展一致性启用，根据像BTC一样，两侧储存交易明细，买卖后交到第三方服务项目财务审计，假如交易方式中出現不一致就强制性重归。

发性解决：红包怎样测算被抢完？

答：cache会抵御失效恳求，将失效的恳求过虑掉，具体进到到后台管理的量并不大。cache纪录红包数量，原子操作开展数量下降，到0表达被抢空。qq钱包依照20万笔每秒钟入帐提前准备，但具体还不上8万每秒钟。

通怎样维持8w每秒钟的载入？

答：多主sharding，水准拓展设备。

据容积是多少？

答：一个红包只占一条纪录，有效期限只能几日，因而不用过多室内空间。

询红包分派，压力太大不？

答：抢到红包的总数和红包都会一条cache纪录上，沒有很大的查寻工作压力。

一个红包一个序列？

答：沒有序列，一个红包一条信息，信息上带一个电子计数器字段名。

有木有从信息上证实每一红包的几率是否平等？

答：并不是絕對平等，就是说一个简易的拍脑壳优化算法。

拍脑壳优化算法，是否会出現2个最好？

答：会出現金额一样的，可是手气好最好只能一个，先抢到的哪个最好。

每领一个红包就升级信息么？

答：每抢到一个红包，就cas升级剩余金额和红包数量。

红包怎样进库入帐？

数据库查询会累积早已领到的数量与金额，插进一条领到纪录。入帐则是后台管理多线程实际操作。