国人自拍av片_无码观看激情视频_欧美日韩不卡中文网_黑人大群XXXX

因?yàn)楣驹?Q：2696584379

活動(dòng)的大體情況是這樣的，在微信網(wǎng)頁環(huán)境下打開，主要頁面的功能就是展示，登記，分享。展示包括各種活動(dòng)信息，比如抽獎(jiǎng)規(guī)則，獎(jiǎng)品，參與的朋友以及獲獎(jiǎng)名單，登記就是用戶參與這個(gè)活動(dòng)，并獲得獎(jiǎng)券，用來最終的抽獎(jiǎng)。然后用戶還可以將這個(gè)活動(dòng)分享到朋友圈或者微信好友，而且他的好友可以通過這個(gè)鏈接參與活動(dòng)。

大家初看起來可能覺得這個(gè)非常簡單，但在實(shí)際實(shí)現(xiàn)上并不是那么簡單，首先，用戶授權(quán)，活動(dòng)的主體公眾號(hào)必須要獲得用戶的授權(quán)，這個(gè)前端通過調(diào)用微信的接口活動(dòng) code，然后將這個(gè) code 傳給后端，然后后端帶上 app_key,app_secret 等參數(shù)獲得用戶的 open_id，以此來唯一標(biāo)識(shí)用戶，這個(gè)調(diào)試過程有可能不會(huì)很順利，因此需要先打好日志，獲得用戶授權(quán)以后，那么前后端在每一次交互的時(shí)候如何確定用戶的身份呢？總不能所有請(qǐng)求帶上裸露的 open_id 吧，這樣太危險(xiǎn)了，我這邊的做法時(shí)，在先進(jìn)次授權(quán)的時(shí)候拿到用戶 open_id, 然后使用 AES 和 RSA 加密算法加密 open_id，并傳回給前端作為 ticket，然后以后前端在每一次和我交互的時(shí)候都要在 headers 里面加上這個(gè) ticket，這樣可以極大地提高安全性，因?yàn)槿绻腥诵薷牧诉@個(gè) ticket ，那么加密算法是解不出來的，就會(huì)拒絕這次請(qǐng)求，并且這些操作都是在基類進(jìn)行的，根本都來不到具體的業(yè)務(wù)層，然后就是獎(jiǎng)券的生成，這個(gè)一開始我是準(zhǔn)備用毫秒級(jí)別的時(shí)間戳作為基準(zhǔn)來實(shí)現(xiàn)，但是發(fā)現(xiàn)好像如果并發(fā)量很大，這個(gè)時(shí)間戳也會(huì)重復(fù)，這樣是不符合這次活動(dòng)的，兩個(gè)人不能有同樣的券碼，然后我想到了 redis 的 incr ，它是一個(gè)單線程原子操作，不會(huì)出現(xiàn)重復(fù)，并且這個(gè)值可以重建整個(gè)獲獎(jiǎng)券碼，在抽獎(jiǎng)的時(shí)候不需要全量 load 券碼，還有一個(gè)問題就是當(dāng)別的用戶是通過其他人的鏈接進(jìn)來的時(shí)候，我們會(huì)把這種情況稱為助力，這時(shí)候就需要唯一區(qū)分鏈接，就是在分享的時(shí)候修改鏈接，將用戶的 ticket 作為 url 的一級(jí)放到 url 上面，這樣就能唯一區(qū)分了。數(shù)據(jù)庫我建立了四個(gè)表，抽獎(jiǎng)表記錄每一次抽獎(jiǎng)活動(dòng)的信息，并且有一個(gè)特殊的 lottery_id 可以表示某次抽獎(jiǎng)，并且這個(gè) lottery_id 是貫穿于整個(gè)數(shù)據(jù)庫和代碼的，這樣就可以支持活動(dòng)并行了，獎(jiǎng)券表，記錄每個(gè)人獲得的獎(jiǎng)券，助力表記錄助力情況，參與表記錄每一次活動(dòng)的參與情況。并且這個(gè)活動(dòng)涉及到復(fù)雜的數(shù)據(jù)庫操作，所以需要使用事務(wù)。

一些棘手的問題解決以后，剩下的問題就好弄了，整個(gè)的架構(gòu)是前后端分離的，通過接口來進(jìn)行交互。大體有這樣一些接口，授權(quán)接口，助力和參與接口，主頁接口等。并且為了支持活動(dòng)并行，前端也是進(jìn)行組件化開發(fā)。這次的活動(dòng)主要是我一個(gè)人設(shè)計(jì)編碼的，我覺得還比較有意義，所以在此記錄，要是能幫到某些人就更好了。