Python手機(jī)微信紅包優(yōu)化算法案例

#!/usr/bin/env python

# coding: utf-8

import random

# m : 紅包個(gè)數(shù)

# n : 紅包人數(shù)

# packet : 本次搶到的金額 , 所有金額以分為計(jì)算

def redEnvelope(m,n):

remain = m*100 #剩余金額

nn = n #剩余人數(shù)

for i in range(1,n):

if remain == 0 :

print('已經(jīng)全部發(fā)完了')

else :

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

nn -= 1

remain -= packet

print('第%d位成員紅包的金額為%.2f元 , 余額為%.2f , 剩余%d人未領(lǐng)紅包'%(i,packet/100,remain/100,nn))

print('最后一個(gè)成員紅包金額為%.2f元'%(remain/100))

Python啟用方式

redEnvelope(100,4)

運(yùn)作結(jié)果

第1位成員紅包的金額為45.65元?,?賬戶余額為54.35?,?剩余3人未領(lǐng)紅包

第2位成員紅包的金額為16.10元?,?賬戶余額為38.25?,?剩余2人未領(lǐng)紅包

第3位成員紅包的金額為20.98元?,?賬戶余額為17.27?,?剩余1人未領(lǐng)紅包

最后一個(gè)成員紅包金額為17.27元

概述：2014年手機(jī)微信紅包應(yīng)用數(shù)據(jù)庫查詢抵抗全部總流量，2015年應(yīng)用cache抗總流量。

手機(jī)微信的金額何時(shí)算？

答：手機(jī)微信金額是拆的那時(shí)候即時(shí)算出去，并不是事先分派的，選用的是純運(yùn)行內(nèi)存測算，不用費(fèi)用預(yù)算室內(nèi)空間儲(chǔ)存。。

采用即時(shí)測算金額的考慮到：費(fèi)用預(yù)算必須占儲(chǔ)存，即時(shí)高效率很高，費(fèi)用預(yù)算才高效率低。

實(shí)用性：為何本來搶到紅包，打開后發(fā)覺沒有？

答：2014年的紅包一點(diǎn)開就了解金額，分2次實(shí)際操作，先搶到金額，隨后再轉(zhuǎn)帳。

2015年的紅包的拆和搶是分離出來的，必須點(diǎn)2次，因而會(huì)出現(xiàn)搶到紅包了，但打開后告之紅包早已被領(lǐng)完的情況。進(jìn)到到第一個(gè)網(wǎng)頁不意味著搶到，只表達(dá)那時(shí)候紅包也有。

分派：紅包里的金額咋算？為何出現(xiàn)每個(gè)紅包金額相距挺大？

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

比如：發(fā)100元錢，一共10個(gè)紅包，那麼均值是10元錢一個(gè)，那麼傳出來的紅包的信用額度在0.01元～20元中間起伏。

當(dāng)前邊3個(gè)紅包一共被領(lǐng)了40元錢時(shí)，剩余60元錢，一共7個(gè)紅包，那麼這7個(gè)紅包的信用額度在：0.01～(60/7*2)=17.14中間。

留意：這兒的優(yōu)化算法是每被搶一個(gè)后，剩余的會(huì)再度實(shí)行上邊的那樣的優(yōu)化算法(Tim教師也感覺所述優(yōu)化算法太繁雜，不知道根據(jù)哪些的考慮到)。?那樣算下去，會(huì)超出最初的所有金額，因而來到最終面假如不足那么算，那麼會(huì)采用以下優(yōu)化算法：確保剩余客戶能取得最少1一分錢就可以。?假如前邊的人手氣好不太好，那麼后邊的賬戶余額越大，紅包信用額度也就會(huì)越多，因而具體幾率一樣的。

紅包的設(shè)計(jì)方案

答：手機(jī)微信從qq錢包獲取金額信息郭萊，轉(zhuǎn)化成數(shù)量/紅包種類/金額放進(jìn)redis群集里，app端將紅包ID的懇求放進(jìn)懇求序列中，假如發(fā)覺超出紅包的數(shù)量，立即回到。依據(jù)紅包的裸祭解決取得成功獲得令牌懇求，則由qq錢包開展一致性啟用，根據(jù)像BTC一樣，兩側(cè)儲(chǔ)存交易明細(xì)，買賣后交到第三方服務(wù)項(xiàng)目財(cái)務(wù)審計(jì)，假如交易方式中出現(xiàn)不一致就強(qiáng)制性重歸。

發(fā)性解決：紅包怎樣測算被搶完？

答：cache會(huì)抵御失效懇求，將失效的懇求過慮掉，具體進(jìn)到到后臺(tái)管理的量并不大。cache紀(jì)錄紅包數(shù)量，原子操作開展數(shù)量下降，到0表達(dá)被搶空。qq錢包依照20萬筆每秒鐘入帳提前準(zhǔn)備，但具體還不上8萬每秒鐘。

通怎樣維持8w每秒鐘的載入？

答：多主sharding，水準(zhǔn)拓展設(shè)備。

據(jù)容積是多少？

答：一個(gè)紅包只占一條紀(jì)錄，有效期限只能幾日，因而不用過多室內(nèi)空間。

詢紅包分派，壓力太大不？

答：搶到紅包的總數(shù)和紅包都會(huì)一條cache紀(jì)錄上，沒有很大的查尋工作壓力。

一個(gè)紅包一個(gè)序列？

答：沒有序列，一個(gè)紅包一條信息，信息上帶一個(gè)電子計(jì)數(shù)器字段名。

有木有從信息上證實(shí)每一紅包的幾率是否平等？

答：并不是絕對平等，就是說一個(gè)簡易的拍腦殼優(yōu)化算法。

拍腦殼優(yōu)化算法，是否會(huì)出現(xiàn)2個(gè)最好？

答：會(huì)出現(xiàn)金額一樣的，可是手氣好最好只能一個(gè)，先搶到的哪個(gè)最好。

每領(lǐng)一個(gè)紅包就升級(jí)信息么？

答：每搶到一個(gè)紅包，就cas升級(jí)剩余金額和紅包數(shù)量。

紅包怎樣進(jìn)庫入帳？

數(shù)據(jù)庫查詢會(huì)累積早已領(lǐng)到的數(shù)量與金額，插進(jìn)一條領(lǐng)到紀(jì)錄。入帳則是后臺(tái)管理多線程實(shí)際操作。

總結(jié)

以上是生活随笔為你收集整理的python 发红包import random用redenv,Python微信发红包编码案例 微信发红包的架构模式 - push博客...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。