先上張圖整體了解Flink中的異步io

 

阿里貢獻給flink的，優點就不說了嘛，官網上都有，就是寫庫不會柱塞性能更好

然後來看一下， Flink 中異步io主要分為兩種

　　一種是有序Ordered

　　一種是無序UNordered

主要區別是往下游output的順序（注意這裏順序不是寫庫的順序既然都異步了寫庫的順序自然是無法保證的），有序的會按接收的順序繼續往下游output發送，無序就是誰先處理完誰就先往下游發送

兩張圖了解這兩種模式的實現

 

有序：record數據會通過異步線程寫庫，Emitter是一個守護進程，會不停的拉取queue頭部的數據，如果頭部的數據異步寫庫完成，Emitter將頭數據往下游發送，如果頭元素還沒有異步寫庫完成，柱塞      

無序：record數據會通過異步線程寫庫，這裡有兩個queue,一開始放在uncompleteedQueue，當哪個record異步寫庫成功后就直接放到completedQueue中，Emitter是一個守護進程，completedQueue只要有數據，會不停的拉取queue數據往下游發送 

    

可以看到原理還是很簡單的，兩句話就總結完了，就是利用queue和java的異步線程，現在來看下源碼

這裏AsyncIO在Flink中被設計成operator中的一種，自然去OneInputStreamOperator的實現類中去找

於是來看一下AsyncWaitOperator.java

　　

看到它的open方法（open方法會在taskmanager啟動job的時候全部統一調用，可以翻一下以前的文章）

這裏啟動了一個守護線程Emitter,來看下線程具體做了什麼

 

 1處拉取數據，2處就是常規的將拉取到的數據往下游emit，Emitter拉取數據，這裏先不講因為分為有序的和無序的

 這裏已經知道了這個Emitter的作用是循環的拉取數據往下游發送

 回到AsyncWaitOperator.java在它的open方法初始化了Emitter,那它是如何處理接收到的數據的呢，看它的ProcessElement（）方法

 

    

 

 其實主要就是三個個方法

先是！！！將record封裝成了一個包裝類StreamRecordQueueEntry，主要是這個包裝類的構造方法中,創建了一個CompleteableFuture(這個的complete方法其實會等到用戶代碼執行的時候用戶自己決定什麼時候完成）

1處主要就是講元素加入到了對應的queue,這裏也分為兩種有序和無序的

 

這裏也先不講這兩種模式加入數據的區別

接着2處就是調用用戶的代碼了，來看看官網的異步io的例子

 

 給了一個Future作為參數，用戶自己起了一個線程（這裏思考一下就知道了為什麼要新起一個異步線程去執行，因為如果不起線程的話，那processElement方法就柱塞了，無法異步了）去寫庫讀庫等，然後調用了這個參數的complete方法（也就是前面那個包裝類中的CompleteableFuture）並且傳入了一個結果

看下complete方法源碼

 

 這個resultFuture是每個record的包裝類StreamRecordQueueEntry的其中一個屬性是一個CompletableFuture

 那現在就清楚了，用戶代碼在自己新起的線程中當自己的邏輯執行完以後會使這個異步線程結束，並輸入一個結果

 那這個幹嘛用的呢

 

最開始的圖中看到有序和無序實現原理，有序用一個queue,無序用兩個queue分別就對應了

OrderedStreamElementQueue類中

 

 UnorderedStreamElementQueue類中

 

回到前面有兩個地方沒有細講，一是兩種模式的Emitter是如何拉取數據的，二是兩種模式下數據是如何加入OrderedStreamElementQueue的

有序模式：

1.先來看一下有序模式的，Emitter的數據拉取，和數據的加入

　　　　其tryPut（）方法

　　　　  

 　　　  

 　　　　onComplete方法

　　　　　　　

       onCompleteHandler方法

　　　　  　　

　　這裏比較繞，先將接收的數據加入queue中，然後onComplete()中當上一個異步線程getFuture() 其實就是每個元素包裝類裏面的那個CompletableFuture,當他結束時（會在用戶方法用戶調用complete時結束）異步調用傳入的對象的 accept方法，accept方法中調用了onCompleteHandler（）方法，onCompleteHandler方法中會判斷queue是否為空，以及queue的頭元素是否完成了用戶的異步方法，當完成的時候，就會將headIsCompleted這個對象signalAll（）喚醒

 

2.接着看有序模式Emitter的拉取數據

       

   這裡有序方式拉取數據的邏輯很清晰，如果為空或者頭元素沒有完成用戶的異步方法，headIsCompleted這個對象會wait住（上面可以知道，當加入元素的到queue且頭元素完成異步方法的時候會signalAll（））然後將頭數據返回，往下游發送

 

這樣就實現了有序發送，因為Emitter只拉取頭元素且已經完成用戶異步方法的頭元素

 

無序模式： 

　　這裏和有序模式就大同小異了，只是變成了,接收數據后直接加入uncompletedQueue，當數據完成異步方法的時候就，放到completedQueue裏面去並signalAll（），只要completedqueue裏面有數據，Emitter就拉取往下發

 

這樣就實現了無序模式，也就是異步寫入誰先處理完就直接放到完成隊列裏面去，然後往下發，不用管接收數據的順序

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

在我們寫程序的時候，經常會遇到各色各樣的問題，在國內，小夥伴們經常去知乎、CSDN、博客園、思否、安卓巴士等地方提問並獲得答案。

這些地方彙集了很多優秀的、愛分享的國內資源。小編比較自豪的一件事情就是：當初學習dubbo期間，因為一個數據關閉錯誤一直找不到正確的解決方式，就順手把自己解決問題的步驟寫下，並附上參考資料中的方法，算是把那類問題做了一個增強版的總結，沒想過幾個月後，有位粉絲專門找上來感謝我，幫他解決了疑惑。

技術人，就是那麼容易得到滿足。得到別人的一句謝謝，開心的像個傻瓜。前行路上，愛分享、把資源提供給更多的人，是最開心和愉快的事情。

現在是移動互聯網的時代，倘若我們能鏈接到更多的人，倘若我們來連接的不僅僅有國內，還有國外，那豈不是更好？那麼如何在國外得到自己想要的答案？我們不妨去Stack Overflow這個平台去試試，優秀的問答平台，你們懂的。

但是提問也是一門藝術，所以趕緊來看看他們的總結，助你更好地在平台上提問。

原文地址：https://medium.com/better-programming/how-to-ask-a-question-that-gets-answered-on-stack-overflow-45f87f1a2fef

作者：Nabil Nalakath

時間：2019.11.12

當有人告訴我他們在開發中遇到的問題時，在大多數情況下，我的直接答覆是：“您在Stack Overflow上發現了什麼？”

但是，很多開發者會給出奇怪的答案，例如：“我不知道如何使用它，我因提出較差的問題而被禁止，人們總是不贊成我的帖子，或者給我有關如何提問的鏈接，”等。

Stack Overflow是互聯網上最有用，訪問最多的網站之一，但它也是互聯網上最殘酷的平台之一。

如果您犯了一個錯誤或提出了一個愚蠢的問題，人們不會理財你，這就是該平台自成立以來一直保持其標準的方式。因此，別指望有什麼收穫。

相反，我們需要習慣它並改變提問的方式。夠了，讓我們來看看您在提問時要注意哪些重要事項。

發布問題時要注意的事項

1. 標題要具體（不要在標題中張貼整個問題或廣泛的問題）

2. 使用正確的標籤（這對於快速獲得答案非常重要）

3. 張貼代碼的相關部分，並在問題編輯器中使用代碼標籤將其格式化為代碼（如果代碼不是整齊的，大多數人都不會去回答）

4. 如果您要解釋運行時出現的問題，請嘗試發布屏幕截圖

5. 如果有日誌的話，發布正確的錯誤日誌（特別是在應用崩潰的情況下）

6. 如果您的部分輸出沒有錯誤，並且想要對輸出進行特定的修改，而且您似乎無法弄清楚如何，將問題分為兩部分，在問題中清楚提及：

• 你現在有什麼
• 你需要達到的目標

1. 如果與UI相關，請發布線框屏幕截圖，如果不可用，請嘗試在現有的UI屏幕截圖中使用諸如Paint之類的簡單工具標記所需的內容或您要進行的更改

2. 如果您認為版本代碼可能與解決問題有關，請發布版本代碼（例如：果問題僅在舊版本的PHP或Android中發生，而在新版本中則沒有）

發布時要避免的錯誤

• 切勿發布代碼中包含品牌名稱或公司名稱的部分

• 裁剪屏幕截圖以僅显示相關內容

• 如果代碼包含部分內容，例如鍵或密碼（例如PHP郵件程序代碼中的电子郵件密碼），請始終用****或特殊字符替換密碼字段

• 不要發布自己創建的特殊算法或應用引擎代碼，除非您不介意其他人使用它或將其開源

壞問題和好問題

讓我們看一下146票贊成的這篇文章：

地址：https://stackoverflow.com/questions/3905734/how-to-send-100-000-emails-weekly?source=post_page-----45f87f1a2fef----------------------

如您在本示例中看到的，已發布的問題不是特定問題。如果您要這樣的教程類型答案，那麼Stack Overflow並不是一個好地方。

以該示例為例，在這種情況下，用戶要求每周使用PHP向100,000個用戶發送一封电子郵件。但問題並沒有显示用戶方面的任何努力。

到目前為止，還沒有提及用戶已經嘗試了什麼或他們面臨的任何特定錯誤。這是不能回答問題的完美範例。

另外，這裡有一些很好的示例問題供您參考。

地址：https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-processing-an-unsorted-array?source=post_page-----45f87f1a2fef----------------------

地址：https://stackoverflow.com/questions/51096796/how-to-enable-horizontal-scrolling-for-chart-js-in-ionic?source=post_page-----45f87f1a2fef----------------------

地址：https://stackoverflow.com/questions/47923524/app-is-crashing-on-some-devices-android-studio-shows-out-of-memory-exception-er?source=post_page-----45f87f1a2fef----------------------

如您所見，即使有人不回答，如果您以適當的方式提出問題，您仍然會獲得贊成票

致謝

最後，如果您得到查詢的答案並且符合您的要求，請將其標記為可接受的答案以關閉問題。

這將幫助發布答案的人獲得聲譽，並鼓勵他們幫助更多人。

畢竟，平台的存在僅是因為這些樂於助人的無私奉獻者願意為您提供幫助，因此這是您為他們所做的最少的事情。

結尾

提問是一門藝術，小編也經常遇到很多提問看不懂、看不明白的情況。無論是在團隊里還是平時和大家交流的過程中，多多少少會遇到互相不理解的情況，所以，做技術的我們實在是太難了，哈哈。

當然，如果學會了一些必要的技巧，提問對我們來說還是just so so，畢竟共同語言這麼多，雖然問題形形色色，但是茫茫人海，總會有人遇到你遇到的問題，總存在能解決問題的方法。

這是一篇很好的提問的範例，不僅僅是在Stack Overflow上，包括我們自己國內的平台、自己項目組、都可以用類似的技巧來提問，能大大節省溝通成本，獲得更高效率。

本文由博客一文多發平台 發布！

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

(馬蜂窩技術原創內容，公眾號 ID: mfwtech)

引言

消費者的狂歡節「雙 11」剛剛過去。在電商競爭環境日益激烈的今天，為了抓住流量紅利，雙 11 打響的已經不僅僅是「促銷戰」，也是「營銷戰」，這對平台的技術支撐能力提出新的要求。

從 2014 年的「318 大促」，到正在進行的 「馬蜂窩雙 11 全球旅行蜂搶節」，馬蜂窩旅遊電商業務的大促已經走過 5 年時間，僅僅是雙 11、暑期、十一黃金周、年終這些關鍵節點的 S 級促銷就張羅了 50 多場，每年上線活動達幾百個。

圖：馬蜂窩11.11全球旅行蜂搶節

 

在這個過程中，馬蜂窩營銷平台也在經歷着優化和改進，不斷探索靈活高效的營銷活動運營開發方式，更好地支撐業務營銷活動的模式創新和投放需求，努力實現平台商家與馬蜂窩旅遊消費者的高效匹配，目前已經形成了一套較為完整的技術體系。

本文將以馬蜂窩營銷活動後台的技術實踐為重點，分享馬蜂窩營銷平台的架構設計思路，希望能讓遇到類似問題的同學有所收穫。

 

一、馬蜂窩營銷平台架構

1. 營銷中心體系

談到大促，大家可能首先會想到的海量數據、高併發、高流量等關鍵詞。其實除了這些，營銷活動數量多、周期短、功能複雜多變等，都是營銷活動運營開發需要應對的挑戰。並且由於我們的很多活動會涉及到一些獎勵或權益的下發，對於安全性的要求也很高。

針對以上問題，馬蜂窩營銷系統的技術架構要具備的核心能力包括：

• 打造靈活、高效的活動開發模式

• 提供高可靠、高可用的活動運營支撐

• 保證營銷活動業務的安全運行

因此，我們本着「平台化、組件化、模塊化」的方法，將營銷體系的架構設計如下：

 

馬蜂窩整體營銷體系分為 B 端和 C 端兩部分。B 端主要面向商家，幫助商家在馬蜂窩招商平台進行大促活動的提報以及商品選取；C 端主要是面向馬蜂窩用戶，平台用戶可以在業務營銷頁面完成活動商品的購買、秒殺、大促紅包贏取等具體的營銷活動參与互動。

2. C 端營銷平台

C 端營銷平台的系統架構主要分為主要分為營銷應用層、中間層、投放平台、搭建平台四個部分。

• 活動開發平台：營銷平台最核心的部分，也是本文重點。包括前端頁面搭建層「魔方」、業務邏輯層「蜂玩樂園」、獎勵規則控制層「獎池」三部分

• 投放平台：是指營銷活動頁的投放，包括投放策略、運營策略和機制等

• 中間件：負責併發處理、分佈式緩存和容災限流等等

• 營銷應用：包括馬蜂窩大促營銷、業務營銷、新人禮包等

下面，我們重點介紹營銷搭建平台的核心部分——活動開發平台，是如何實現高效、靈活的營銷活動開發模式的。

 

二、活動開發平台的實現

2.1 靈活高效的開發模式

通過上圖可以看到，由 MySQL、ElasticSearch、Redis 組成的數據池在底層為活動開發平台提供支撐。其中 MySQL 為最主要的存儲方案，用於會場搭建配置數據、蜂玩樂園的用戶運行數據、獎池配置數據等的存放。ElasticSearch 是搜索引擎，支持活動頁面商家活動報名與篩選過程。Redis 有 2 種用途：1）活動任務併發鎖；2）獎池的獎品數據存放；3）限流和削峰。

之前我們提到，活動開發的挑戰包括數量多、周期短、功能複雜多變。為了降低開發同學的工作量，提升研發效率，我們將前端和後端組件進行了整合，並封裝成功能模塊對提供服務，形成了目前的魔方、蜂玩樂園、獎池三個子系統，使整體結構更加清晰。每個部分解決的問題和主要功能模塊示意如下：

2.1.1 系統分層

魔方

「魔方」系統希望通過組件、工具的方式完成營銷頁面的搭建，實現統一維護和復用，從而減少前端團隊在活動開發中承載的重複性開發工作。目前為止我們已經在「魔方」中開發了 80 多個組件模塊，例如秒殺模塊、貨架模塊、店鋪模塊、導航模塊、領券模塊、遊戲互動模塊等。

現在，小型活動完全可以不用開發人員支持，只需要業務同學操作即可搭建促銷會場上線活動，提升了活動運營效率，也大大解放了前端開發人員。關於「魔方」更多的細節我們會在後續文章單獨介紹，本文不過多展開。

蜂玩樂園

(1) 邏輯功能抽象

營銷活動的核心是創新和吸引力。每次活動開始前，運營同學都會在創意策劃上絞盡腦汁，盡可能創造出與眾不同的新玩法。這些新穎有趣的遊戲玩法，可以在微信，App 等渠道引起用戶的好奇心和興趣，為賣場拉新，進而創造更多的交易。

隨着「花樣」的不斷翻新，活動開發的複雜度也在增加，有時甚至讓技術同學應接不暇，也促使我們探索更加高效的開發方式。

我們開始思考在複雜多變的活動玩法下，是否潛藏着一些不變的模式和規則？通過對不同業務活動模式的分析和抽象，我們將活動的流程和用戶的行為進行了一個有趣的類比：

• 首先，開發活動就創建了一個「樂園」

• 我們會根據不同的「規則」去設計每一個「活動」，激發潛在「參与者」的興趣，或建立他們希望贏得獎勵的期待。

• 進入活動后，我們會驗證參与者「身份」，和需要滿足這次活動的「條件」，來確定他是否可以開始。

• 活動開始時，參与者參与一次活動需要發生的行為，就是在完成「任務」

• 完成「任務」后，為參与者發放相應的「權益」或「獎勵」。

這個類比模型在歷屆促銷活動中進行了推演，結果显示基本是通用的，但完成任務可能伴隨獎勵服務，也可能沒有，由具體業務需求決定。舉個例子，在一場紅包裂變的營銷活動中有一個需求是下紅包雨，用戶可以點擊掉下來的紅包領取相應的紅包獎勵。那麼「領取」這個動作就可以視為活動中的一個任務；另一個需求是每當用戶成功邀請一位好友后就可以在任務中心領取一個邀請紅包獎勵，那麼我們可以把在任務中心領取邀請紅包也看成一個任務。

這兩個任務有一個共同的特點就是觸發后都有紅包獎勵，只是在第二個場景中的任務，本質上是用戶發起了一個請求。

經過進一步的梳理、規整，我們抽象出了「參与者」、「活動」、「任務」、「獎品」等業務邏輯功能。

(2) 技術實現

蜂玩樂園將每一個業務邏輯功能收歸到一個唯一的入口和統一的體系中，形成獨立的功能組件模塊，如數據請求模塊、自定義數據配置模塊、驗證器模塊 、執行器模塊、獎勵服務模塊等。每個活動的任務開發都可以選擇模塊配置，模塊配置信息以 yaml. 的格式進行統一管理，這樣的配置具有靈活性、擴展性和可復用性。

在使用的時候解析配置數據，並向組件註冊中心註冊該任務所需要的組件模塊，再按照定義好的順序執行即可。流程如下圖所示：

為大家介紹幾個關鍵模塊的實現。

• 數據請求模塊

數據請求模塊定義了客戶端與服務端約定好的請求參數規則：

request:
       -
        field:  deviceId
        rule: required  #必填項校驗
        method: post
        message:  deviceId參數錯誤
       -
        field:  sex
        rule: in:[0,1] #範圍校驗
        method: post
        message: 性別範圍錯誤
       -
        field:  phone
        rule:   regex:/^1[3456789]\d{9}$/ #正則校驗
        method: post
        message: 手機號格式錯誤

(i) field – 傳入參數的 key 
(ii) rule – 校驗該參數的規則，目前我們已經實現了一些常用的規則：
(iii) required – 必傳參數

• in：驗證所傳參數必須在指定範圍內

• regex：正則表達式校驗 

• min，max：自定義規則最小和最大長度

• integer：必須是数字

• method：定義 GET、POST 請求方式，

(iv) message – 規則驗證失敗返回的錯誤信息。這一層會讀取配置模塊中的請求參數模塊配置內容，將內容解析出來，按照所配置的字段規則做響應的校驗，如校驗通過繼續向下執行，沒有通過則直接返回規則提示。

• 參數配置模塊

參數配置模塊定義了該任務執行中所需配置的所有靜態數據配置項。營銷活動的特點是多樣性、創新性，所以很難去窮舉各種場景建立一個有針對性的配置中心，因此這裏就為每一個任務單獨開闢了一個沒有結構化的小空間，可根據具體場景的特定需求為任務自由配置，使程序代碼里基本不用再寫各種不合理的硬編碼。

params:
    stockRedPacket:
     amount: 1
     stock: 3
     stockKey:  limit_key
     stockField: limit_key_90
     timeWindow:
       beginTime: "2019-11-06 00:00:00"
       endTime: "2019-11-10 23:59:

以一個用戶開啟紅包的配置信息為例：

(i) stockRedPacket 配置了活動設定的固定庫存與固定金額紅包的業務邏輯

• amount 金額

• stock 庫存

• stockKey、stockField 用來加鎖的字段

(ii) timeWindow 定義了該任務的活動開始和結束時間

 

• 驗證器模塊

驗證器模塊的功能主要是是對業務或者規則的校驗。它定義了該任務要執行的業務驗證規則，特點是具有單一性、普適性，能提供一種適用於大多數場景的方法。這些驗證規則可以拆解得足夠細，越細則越靈活，得以在不同任務中靈活組裝使用。

validator:
   - MCommon_Validator_TimeWindowValidator
   - MCommon_Validator_AuthValidator
   - MCommon_Validator_LockValidator

• 這裏使用了活動時間驗證 TimeWindowValidator，不在活動時間內則返回錯誤提示

• 登陸驗證 AuthValidator，參加活動必須要登錄，前端通過判斷錯誤狀態碼統一跳轉到登陸頁面

• 併發鎖 LockValidator，避免一個用戶同樣的操作多次提交

• 取出所有的驗證器，然後通過反射依次按照順序調用，如果其中一個驗證器失敗，則直接返回錯誤信息，終止向下執行。

 

• 執行器模塊

執行器模塊定義了該任務要執行的一些業務邏輯，比如要執行一段寫日誌的邏輯，要執行一個異步調用的邏輯等，都可以使用此模塊定義一個執行器去執行。

command: MSign_Command
afterCommand: MSign_Command_After

執行器又分為前置 command 和後置 afterComman：

 

• 如果需要執行獎勵模塊，則先執行前置 command，再執行獎勵邏輯，最後執行後置 afterCommand，最終返回結果

• 如果沒有獎勵，則先執行前置 command，接着執行後置 afterCommand

 

• 獎勵服務模塊

獎勵服務模塊決定該任務是否需要執行獎勵發放，如果配置了獎勵，任務在執行時會根據獎勵的配置規則下發獎勵。在我們的實際場景中，主要涉及到的獎勵類型包括獎勵機會、紅包、抽獎、優惠券等：

• 獎勵機會：有 2 種規則，分別是按固定頻次給用戶初始化機會數，和獎勵增量機會數。

• 發送紅包：設定固定紅包和隨機紅包，隨機紅包按需求設置發放的概率與用戶群。

• 抽獎：對接獎池系統，下文詳細介紹。

• 優惠券：與馬蜂窩優惠中心直接打通，只需要配置優惠券 SN 和渠道號，即可把優惠券發送到用戶卡券。

 

獎池

在營銷活動中，許多場景都涉及用戶抽獎或獎品發放。營銷技術平台因此對獎品發放的整個生命周期進行了抽象和封裝，創建了「獎池」。

(1) 主要功能

獎池的主要功能點包括：

• 創建獎品池：為每次活動創建一個或多個獎品池

• 設置獎品：在單一獎品池中均勻放置獎品

• 用戶抽獎：用戶在單一獎池中抽獎，支持按概率抽獎，支持獎品的發放和領取

• 中獎統計：包括獎品已發放數量，已領取數量，剩餘數量

如下圖所示，只需創建好獎池，配置好獎品信息，把對應的獎池 ID 填寫到任務，即可實現抽獎功能：

(2) 方案設計

獎池早期的設計非常簡單，獎品實體僅定義「余量」的概念，利用關係型數據庫中單行記錄存儲一次活動的獎品、總量、發放量、余量等數據。在用戶流量較小且均勻的情況下，發放過程平穩正常。每次進行獎品發放時，在單行記錄上進行 update 操作，扣減余量並增加發放量即可。

然而隨着公司業務的發展，一次營銷活動帶來的效果讓我們不得不立刻改進獎池方案。這次營銷活動帶來的流量遠超預期，但獎品數量的配置卻一如往常。當活動開啟后，獎品消耗很快，並在一段時間后被提前抽光。為了不影響用戶體驗，營銷運營同學不得不持續向獎池中補充獎品。

經歷這次問題開發同學發現，獎池提前抽光的原因在於設計中忽略了時間分佈的因素，使獎品抽光的速度只與訪問量相關。因此，大家開始思考如何讓獎品固定且均勻分佈在活動周期內。

通過學習與比較，最終選擇了業界比較通用的方案，使用 Redis 的有序集合（Sorted Set）創建獎池和設置獎品，從而使獎品在活動時間段內均勻分佈，防止提前抽光的情況出現。

(3) 實現算法

 

1. 時間戳：根據獎品的數量和活動時長，為每 1 份獎品設置一個出獎時間戳，這份獎品僅能在這一時間點及之後被抽出。這一步使出獎時間戳盡量均勻分佈在活動時間範圍內。

2. 創建獎品池：為每一組獎品設置一個獎池，在 Redis 創建一個 zset 數據結構，將其中的每 1 份獎品作為 1 個成員（Member），將時間戳作為分值（score）。
3. 放置獎品：使用ZADD 獎池 出獎時間戳 1 份獎品 語法，在 Redis 中布置一個獎品。

4. 抽獎：使用 Sorted Set 的排序方法，每次排序后查看排名第一的獎品，比較當前時間戳與獎品時間戳的大小。如果當前時間晚於或等於出獎時間，則使用 ZREM 指令出獎，否則不出。

示意圖如下：

2.1.2  體系統一

為了讓開發同學只專註於任務的設計開發，我們抽象出「賬戶」的概念，每個任務產生的數據資源會存儲在所在的「賬戶」體系下，使其支撐多個類似的活動。這種設計的好處在於：

（1）同一用戶在參与不同的活動時得到的獎勵都是相互獨立的，不會出現混淆的情況。

（2）之前每次活動都需要單獨創建數據表，活動下線后表不能復用。時間長了造成系統佔用許多無用的數據表。而把數據庫表以抽象的任務形態創建，不針對具體的某一業務類型，就可以使數據表實現復用。這樣我們只專註任務的設計開發，不用再關心數據表的設計。

在營銷大促的活動中，我們也接入了風控中心、併發鎖和限流服務，以保障整個活動的安全和穩定。

2.2 可用性和可靠性

秒殺模塊是大促流量的最高峰。結合業務實際，我們針對這種場景也做了限流和削峰處理。

限流採用的方案是限制時間窗內最大請求數據，用戶再搶會員權益時，第一步會讀取限流配置 key 和 value，判斷單位時間內是否超過限制的最大請求數 value，如果超過則返回信息提示結束請求；如果沒有超過閾值，則進入下一步操作。目前的限流系統只是在應用層面的實現，為了更好地支撐業務發展，後續我們也會接入網關服務，通過 Sentinel 和 Hystrix 做限流熔斷，避免流量進入應用層，提高服務的高可用性。

削峰部分結合實例說明。

以秒殺金卡會員的場景為例，我們會先用 RabbitMQ 承接瞬時的流量洪峰，再平滑地消費所有請求，並提前把庫存數量對應的 Token 寫入 Redis 緩存（這裏我們針對性的對不同的用戶引入了 Token 機制，以保證我們的秒殺商品在時效和庫存上得以保障）。用戶在秒殺時會順序地從 Redis 中 rPop 對應的 Token，避免庫存超賣的情況；用戶拿到 Token 之後再去收銀台下單開通金卡會員，就可以避免流量同一時刻去下單。

隨着業務和技術的發展，系統的不確定性以及流量的預估都更為困難。我們也在不斷學習業界的先進經驗，來更好地提升系統的可用性和可靠性。目前我們正在調研基於 Noah 的「自適應」限流技術並积極推進，以期針對不同的服務器性能以及當前的流量情況進行針對性的限流控制，相信我們會在後續的優化中會做得更好。

2.3 風險控制

目前是接入公司統一的風控中心。在營銷活動需求確定好后，我們會向風控服務中心提供需要風控的業務場景邏輯。風控中心根據業務配置不同策略，給出不同的場景 key。我們只需要在營銷活動任務中的自定義參數配置模塊配置好風控場景 key，就可在獎勵服務模塊自動調用風控接口去校驗用戶，如果識別出是風險用戶則會被攔截，終止活動參与。

可用性和可靠性、風險控制的實現流程如下圖所示：

 

三、近期規劃

1. 完善監控體系

目前對於活動運行中的數據監控，主要依賴數據組的統計與輸出。線上活動的運行情況並不能通過「蜂玩樂園」與「獎池」系統實時並綜合表現出來。

未來會補齊運行時的活動監控功能，通過活動、任務、獎品的運行時數據指標，指導運營同學第一時間調整活動參數，取得最佳運營效果。

2. 服務化改造

營銷基礎平台依舊搭建在單體架構上，部分功能的邊界與職責並不完全清晰。接下來營銷技術平台會進行技術架構的升級與改造，從單體架構轉向微服務架構，使服務能力與開發能效同步提升。

小結

隨着營銷的逐年發展，活動的趣味性和複雜度會一起上升，這需要我們不斷更新對營銷活動的認識。在這過程中也要反覆嘗試新的抽象和重構，通過不斷改進現有系統，支持更多和更好玩的營銷活動，讓馬蜂窩用戶玩兒得更省心，玩兒得更省錢。

本文作者：馬蜂窩電商研發營銷中心團隊劉遠勻、任浩、唐溶波。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益