這是我最近剛弄完上線的一套比較有意思的比較大型的系統，因此特意記錄一下。
先說這套玩意獲得的效果：競品的投放團隊運營團隊就算有一百個人，天天996，007加班不睡覺，投放效率也沒有我們四五個人的高，這個是人工成本的一次大縮減。在效果反饋和素材投放效果的實時性準確性上，肯定也不及專門定製的系統根據各項指標排序展示準確，這個是實用性價值方面，其餘的還有創意素材管理…人羣定向管理…批量組合邏輯…等等等等～非常慶幸自己有機會坐擁公司提供的這麼多資源，纔能有這麼有價值的產出～
具體功能詳述：
騰訊手握大量用戶數據（我們註冊時的性別/年齡/住址/姓名/學歷/消費能力），又有微信QQ公衆號朋友圈等等社交媒體，又有大量的遊戲，收集了我們這些數據，能提供很精準的廣告投放功能。所以他們有一套廣告平臺。
這套東西是收費的廣告投放系統，在交了“入場費”後，我們就可以進去填寫我們的投放計劃，我們的廣告落地頁，我們的廣告圖，廣告文案，創意設計等等，以及我們自己填寫的出價策略+日預算來增加曝光度等等一大堆複雜的功能。
我公司做的線上教育嘛，爲了跟猿輔導，作業幫，學而思那些競品瓜分市場大蛋糕，自然也要藉助這麼好用的一個工具，將廣告打到家長們的朋友圈，QQ動態，公衆號，網頁插圖等等地方（類似下面）。
其實這個跟公衆號運營一樣，你可以直接在騰訊提供的後臺操作，但是就比較多限制，不夠人性化，不能滿足公司特殊的業務需求，比如這個廣告平臺，圖文素材上傳問題就是每個投手都有一個賬號一套，素材不共享，投放批次無法區分，溝通成本大，一次只能選擇單圖文單定向，無法批量創建，投手們和設計師們苦不堪言。於是作爲負責對外招生線的後端開發同學們，就有事可做來。
這裏有幾個概念簡單說明一下：
（1）推廣計劃：其實就是整個廣告的投放推廣的計劃，是最大的一層，包含了投放時間段和計劃預算（預算金額高的騰訊會增加該計劃的曝光量），所有後序操作都必須基於推廣計劃才能繼續做。
（2）廣告創意：其實就是設計師們做出來的圖，還有投手們運營們絞盡腦汁想出來的廣告臺詞文案拼接成的，還包含你的落地頁鏈接，下單也鏈接，支持商城小程序和商城網頁等等。
（3）廣告組：一個推廣計劃下會有1～10個廣告組，廣告組也有預算，有它各自的定向類型，擴量，投放目標類型等等一大堆參數。
（4）廣告：記錄了廣告組ID，創意ID，計劃ID，只有創建完畢廣告，整個計劃纔算創建完整。
（5）投手賬號：開通了能新建廣告功能權限的投手的微信賬號。
（6）定向：分爲人羣定向和地域定向，人羣定向其實是限定人的年齡區間，性別，受教育程度，消費能力等等一堆數據，比如你不可能推送一個遊戲的廣告給那些老年人，不可能推送賣房子的廣告給小學生吧？地域定向就是經緯度，生活的城市地區，畢竟你不可能推送賣泳衣的給撒哈拉沙漠地區人民，推薦防曬霜給四川人民，推薦廣州的房地產廣告給黑龍江人民吧？
（7）素材：分爲文案素材和圖片素材和視頻素材。有各自的規格，大小多少M，多少像素，800*680…等等，騰訊很多複雜的組合限制。
簡單介紹完概念，如果是有需要的同學可以再詳細看騰訊的接口文檔：https://developers.e.qq.com/docs/start?version=1.1（友情提示：右下角有人工客服，點開輸入人工就可以問問題，它很多文檔的參數寫的都是錯的）
下面開始具體說說踩的坑：
（1）做了60%才發現整個流程缺少了一大塊！
我們完全按照騰訊的格式，分層建表，在素材管理那一塊，我們做了一套類似高級文件夾功能的系統讓投手們共享素材，再也不怕溝通不到位的問題了，大家都知道現在投放線的最新素材版本。然而，我們創建創意的時候，發現所有的素材不能存在我們的資源服務器上，而是要上傳到騰訊那邊的資源庫，然後他們返回一個ID，我們創建廣告時候拿的其實是這個ID。於是我們又改了流程，要在上傳後將返回的ID全部共享到全部投手賬號下，也就是每個賬號都上傳一遍。
（2）循環邏輯太複雜了吧？！
由於投手們飽受騰訊限定的一條一條創建的苦，他們必須不斷重複毫無意義的重複創建工作。所以它們要求能批量創建，但是這個批量功能，複雜程度遠超乎我的想象！
功能點一：能多選文案和圖片素材/視頻素材。
功能點二：能夠多選人羣定向和多個地域定向進行組合。
功能點三：能夠自己輸入創建N份推廣計劃，而不用一條條輸入創建。
功能點四：能夠自己輸入創建N份廣告組，而不是創建一條再創建一條。
這樣的話，順序其實跟騰訊那邊是相反的，騰訊的順序是現有計劃，再有創意，再有廣告組，最後有廣告，我們這邊卻要根據用戶輸入和多選的素材組合和定向組合來確定要創建多少條計劃！！
例：
現在有 圖片素材A 圖片素材B 文案素材T1 文案素材T2
人羣定向 P1 P2 地域定向 廣州 G 深圳S
問：一共生成多少條計劃？
答： 圖文結合： AT1 ， AT2 ， BT1 ，BT2 。人羣地域結合：P1G , P1S , P2 G , P2S.
計劃參數組合：
AT1-P1G , AT1-P1S , AT1-P2G …好了你們懂我意思了吧？
其實就是組合套組合，循環套循環而已，那我們就先走我們自己的批量邏輯計算出具體會有多少條組合，再通過騰訊接口去依次創建，剩下就是接口對接，上百個參數的對接，枚舉類型的定義。
（3）上面的還不算重頭戲，重頭戲其實在這裏：
我花了兩天左右時間，把接口調通了，創建流程全部走通，我們這邊的分批次分層級入庫也沒問題了，開心得雅痞！我忽然想起投手們還能自己輸入要創建複製同批次的推廣計劃份數，於是弱弱的問了一句，他們原話：最少一次也複製幾百條吧，不然幾條几條的沒意義啊。
我凌亂了，爲什麼？！請聽分析：
正如我上面最簡單的兩圖兩文組合，兩地域兩人羣組合，已經能生成：2222 = 16條計劃（以及後序創建計劃下面的三個層級），他們假如輸入“幾百條”複製數量，那我以300爲例子，那就是：16300 = 4800條，那麼依次創建三個層級，也就是 4800 * 3 = 14400 次接口請求，然後它們還會輸入“複製1～10條廣告組的條數”，那就是：14400*10 = 144000.
沒問題啊老鐵，十四萬次接口調用，只爲了創建一個投手單次操作的廣告。我們有上百個投手，嗯，上面的計算量我還是按照最小的數量來進行的，他們如果選擇8圖8文甚至更多，輕鬆上百萬次接口請求。
那麼，假設忽略網絡延遲的情況下，我算做你0.1秒請求響應一個接口，不出故障。那也要：14400秒
也就是說，這個投手一次創建的廣告，（不出故障，全部創建成功，網絡穩定情況下，騰訊接口不針對我做限制情況下）耗時4小時。
真好，我用的是Node，單線程，炸爆服務器。
真好，前端一直轉圈圈，用戶在四個小時後就能得到創建結果，這四小時可以下班回家煮個飯。
好個球啊！！這很明顯是不行的，這已經是存在重大的設計缺陷了！！
中間跟產品撕逼的過程我也不說了，直接給解決方案！！
這種瞬間爆炸數據量得不到即時響應的場景，是不是像秒殺之類，我回憶起自己之前做的一個外包項目的秒殺，就是採用了延時策略。
於是：
創建時候不去請求騰訊接口，只會在我們自己的數據庫先進行入庫操作，同時爲了緩解瞬間大量寫入更新造成的壓力，我們先將創建請求的參數，對象，通過序列化存在Redis中，後序再通過Linux的CronTab定時任務獲取出來，反序列化還原回對象，再進行入庫操作，操作成功後記得把該條記錄的Key覆蓋掉刪掉。
把創建流程改爲全部先入庫，概念從傳入單個的“廣告條件”，改爲傳入“廣告條件參數包”，將兩萬個計劃和兩萬個單條創建參數（從前端傳入的條件參數包中循環組合拆分出來）組合先insert進數據庫，待騰訊返回ID字段留空，並且模仿騰訊廣告的層級關係依次創建後續的創意，廣告組，廣告先入庫。然後再通過CronTab定時任務（1分鐘）依次從數據庫拿status爲0的未創建的計劃和對應的計劃參數和旗下的全部子層級出來，再通過計劃的參數依次調用騰訊創建接口，把獲得的ID再放到下一層級創建參數中依次循環創建，如果其中一層級失敗，記錄相關的錯誤信息（層級+騰訊返回的錯誤原因）到計劃表，整條廣告計劃創建失敗。
用戶在運營後臺雖然不會等待太久，但是其實我們這邊的創建申請，可能要幾個小時甚至更久才輪詢到再調用騰訊創建接口創建，纔會出現在騰訊計劃列表，失去了實時性，失敗原因得不到及時反饋，緊急情況下不能立即進行修改重投。
協商過後，其實這個已經是最好的解決方案了，這也是沒辦法的事情，投手們因爲已經是批量了，不可能馬上能得到反饋，但是我們能夠優化它的體驗，給個創建進度條給他們看，及時記錄失敗原因，方便他們修改後重試。
通過這一套大型系統（四套子系統：投手賬號管理系統，素材管理系統，定向管理系統，投放管理系統）的創建，真的是非常有意思，但是工期實在太緊張（3星期），搞得壓力真的很大。
當然，這還不是結束，這還僅僅是開始，後期還有動態商品類型迭代（包含商品庫和商品目錄等關係子系統），還有一堆又一堆的新需求迭代～把它打造得更完善～
PS：剛上線一個月就有顧客聞訊而來希望買這套系統，這對於作爲父親的我來說，真是莫大的幸福～
