因為公司在 Q：2696584379
活動(dòng)的大體情況是這樣的，在微信網(wǎng)頁(yè)環(huán)境下打開(kāi)，主要頁(yè)面的功能就是展示，登記，分享。展示包括各種活動(dòng)信息，比如抽獎規則，獎品，參與的朋友以及獲獎名單，登記就是用戶(hù)參與這個(gè)活動(dòng)，并獲得獎券，用來(lái)最終的抽獎。然后用戶(hù)還可以將這個(gè)活動(dòng)分享到朋友圈或者微信好友，而且他的好友可以通過(guò)這個(gè)鏈接參與活動(dòng)。
大家初看起來(lái)可能覺(jué)得這個(gè)非常簡(jiǎn)單，但在實(shí)際實(shí)現上并不是那么簡(jiǎn)單，首先，用戶(hù)授權，活動(dòng)的主體公眾號必須要獲得用戶(hù)的授權，這個(gè)前端通過(guò)調用微信的接口活動(dòng) code，然后將這個(gè) code 傳給后端，然后后端帶上 app_key,app_secret 等參數獲得用戶(hù)的 open_id，以此來(lái)唯一標識用戶(hù)，這個(gè)調試過(guò)程有可能不會(huì )很順利，因此需要先打好日志，獲得用戶(hù)授權以后，那么前后端在每一次交互的時(shí)候如何確定用戶(hù)的身份呢？總不能所有請求帶上裸露的 open_id 吧，這樣太危險了，我這邊的做法時(shí)，在先進(jìn)次授權的時(shí)候拿到用戶(hù) open_id, 然后使用 AES 和 RSA 加密算法加密 open_id，并傳回給前端作為 ticket，然后以后前端在每一次和我交互的時(shí)候都要在 headers 里面加上這個(gè) ticket，這樣可以極大地提高安全性，因為如果有人修改了這個(gè) ticket ，那么加密算法是解不出來(lái)的，就會(huì )拒絕這次請求，并且這些操作都是在基類(lèi)進(jìn)行的，根本都來(lái)不到具體的業(yè)務(wù)層，然后就是獎券的生成，這個(gè)一開(kāi)始我是準備用毫秒級別的時(shí)間戳作為基準來(lái)實(shí)現，但是發(fā)現好像如果并發(fā)量很大，這個(gè)時(shí)間戳也會(huì )重復，這樣是不符合這次活動(dòng)的，兩個(gè)人不能有同樣的券碼，然后我想到了 redis 的 incr ，它是一個(gè)單線(xiàn)程原子操作，不會(huì )出現重復，并且這個(gè)值可以重建整個(gè)獲獎券碼，在抽獎的時(shí)候不需要全量 load 券碼，還有一個(gè)問(wèn)題就是當別的用戶(hù)是通過(guò)其他人的鏈接進(jìn)來(lái)的時(shí)候，我們會(huì )把這種情況稱(chēng)為助力，這時(shí)候就需要唯一區分鏈接，就是在分享的時(shí)候修改鏈接，將用戶(hù)的 ticket 作為 url 的一級放到 url 上面，這樣就能唯一區分了。數據庫我建立了四個(gè)表，抽獎表記錄每一次抽獎活動(dòng)的信息，并且有一個(gè)特殊的 lottery_id 可以表示某次抽獎，并且這個(gè) lottery_id 是貫穿于整個(gè)數據庫和代碼的，這樣就可以支持活動(dòng)并行了，獎券表，記錄每個(gè)人獲得的獎券，助力表記錄助力情況，參與表記錄每一次活動(dòng)的參與情況。并且這個(gè)活動(dòng)涉及到復雜的數據庫操作，所以需要使用事務(wù)。
一些棘手的問(wèn)題解決以后，剩下的問(wèn)題就好弄了，整個(gè)的架構是前后端分離的，通過(guò)接口來(lái)進(jìn)行交互。大體有這樣一些接口，授權接口，助力和參與接口，主頁(yè)接口等。并且為了支持活動(dòng)并行，前端也是進(jìn)行組件化開(kāi)發(fā)。這次的活動(dòng)主要是我一個(gè)人設計編碼的，我覺(jué)得還比較有意義，所以在此記錄，要是能幫到某些人就更好了。
以上就是小編為大家講述的微信代運營(yíng)相關(guān)內容和服務(wù)，希望大家能夠對這些內容有一定的了解，也相信會(huì )給您帶來(lái)一定的幫助。如果您想了解更多有關(guān)微信代運營(yíng)的知識，可隨時(shí)選擇巨推科技-巨推傳媒進(jìn)行咨詢(xún)，咨詢(xún)電話(huà)是400-606-5558，我們會(huì )有專(zhuān)業(yè)人員為您服務(wù)。
巨推傳媒：www.sixiiii-i.com
扣/微：2696584379
