商品賣不動？閒魚Tellus任務系統來幫你

業務背景

閒魚作為一款C2X的app，與淘寶、天貓等B2C的業務模式存在天然不同。個人賣家也是普通的消費者，很多個人賣家相比專業賣家，並不清楚如何賣出自己的商品，問題主要表現在以下兩個方面：

• 商品資訊不足。閒魚採用輕釋出模式，使用者只需要上傳幾張照片，簡單描述一下商品資訊，即可在一分鐘之內完成釋出流程。輕釋出模式迎合了使用者快速釋出的體驗，但也導致了商品資訊不足的問題。

• 商品定價不合理。有些賣家使用者誤判了自己商品的市場行情，導致定價和買家預期存在偏差，降低了買家的購買意願。

所以問題來了，如何在既保證輕釋出的同時，提升商品的有效資訊量，增加商品寶貝的吸引力，促進成交呢？

解決思路

在上述問題背景下，我們想到了做任務的方式引導使用者。具體做法是：在輕釋出的前提下，透過做任務的方式引導賣家補全商品資訊或引導商品降價，從而促進成交。一方面，商品關鍵屬性的資訊補全了，價格變得合理了，就有更多的買家願意瀏覽商品併成交。另一方面，也幫助我們技術小二更好的理解商品的特徵，從而更精準地推薦給需要的買家。

技術實現與系統沉澱

在這個解決思路下，我們創造了Tellus-基於使用者&商品的任務系統。有些同學可能問了：“公司內部難道沒有類似的系統嗎？任務系統應該比較常見吧？”經過調研，發現已有的內部系統大部分是基於使用者的任務系統，而閒魚的任務系統是基於使用者&商品維度的，這樣的特點導致我們無法複用現有的任務系統，只能透過自研。

整體系統結構圖

任務的生命週期分為建立任務、展示任務和完成任務。 

任務建立模組

建立任務的難點在於之前提到的資料來源複雜的問題，因為任務建立的來源較多，為了降低接入成本，Tellus的任務建立模組使用訊息佇列來做事件解耦。Tellus使用MetaQ作為訊息佇列。MetaQ是一款阿里自研分散式、佇列模型的訊息中介軟體（RocketMQ）。基於釋出訂閱模式，有Push和Pull兩種消費方式，支援嚴格的訊息順序，億級別的堆積能力，支援訊息回溯和多個維度的訊息查詢。透過訊息定製，所有的資料來源統一傳送建立任務的訊息，Tellus系統監聽此類訊息並且根據業務邏輯建立對應的任務，很好地解決了複雜訊息源的問題。 

任務展示模組

當任務建立後，如何展示任務呢？展示流程如下：

我們透過AB實驗進行了全方位的探索，Tellus系統支援了豐富的任務型別， 我們嘗試了單個任務和組合任務。

單個任務展示

組合任務展示

還支援基於使用者維度(例如連續擦亮任務)的和基於商品維度(例如選商品成色)的任務。Tellus系統同時也實現了任務頻次的定製，任務可以一次性完成，也可以重複做，可以按照特定順序完成組合任務，也可以亂序完成，給業務提供了靈活的可配置型。 

任務完成模組    

任務的完成模組分為主動完成邏輯和被動完成邏輯，主動完成可分為任務成功和任務失敗，被動完成屬於使用者的某些app行為觸發了完成任務的邏輯，從而在不知情的情況下完成了任務，比如在重新編輯商品的時候新增了商品成色，那麼新增成色的任務就自動完成了。不同任務還可以實現個性化的激勵步驟，Tellus透過策略模式的設計，將介面開放給業務方開發，每個任務的完成，使用者都可以獲取到一定的激勵，這些激勵根據業務的不同而不同，透過介面開放，業務方開發只需要遵守介面的協議，便可以實現定製化開發，完成不同的任務激勵機制。

技術選型

在整個任務的生命週期過程中，還有一個始終都繞不開的難題，就是資料該如何儲存，任務資料主要分為兩類：一類為任務的詳細資料；另一類為任務的後設資料。針對任務的詳細資料，首先要考慮的是關係型資料庫還是非關係型資料庫，關係型資料庫支援事務，可以進行復雜的聯表查詢，這些對於任務系統並非必須和必要的，任務系統對資料的關聯性要求不高（任務資料之間幾乎是相互獨立的），但是對於資料的儲存量級要求較高（百億級別）。支援海量資料儲存的Table store進入了我們的視野。表格儲存（Table Store）是阿里雲自研的NoSQL多模型資料庫，提供海量結構化資料儲存以及快速的查詢和分析服務。表格儲存的分散式儲存和強大的索引引擎能夠支援PB級儲存、千萬TPS以及毫秒級延遲的服務能力。除此之外，Table Store還兼具以下優點：

• Table Store還是一種全託管的資料庫。使用表格儲存只需專注於業務研發，無需擔心軟硬體預置、配置、故障、叢集擴充套件、安全等問題，在保證高服務可用性的同時，極大地減少了管理及運維成本，這樣可以使我們把精力全部放在業務的開發上。

• 查詢能力強。除了支援主鍵查詢，表格儲存還支援多元索引、全域性二級索引。

• 高可用。表格儲存將資料的多個備份儲存在不同機架的不同機器上，並會在備份失效時進行快速恢復，提供99.99999999%（10個9）的可靠性。

• 資料強一致。表格儲存保證資料寫入強一致，並保證資料 3 副本均寫入磁碟，且所有資料保持一致。寫操作一旦返回成功，應用程式就能立即讀到最新的資料。

基於上述優點，Table Store比較好的滿足了我們資料儲存的需求。針對任務的後設資料，考慮到使用頻率，我們也建立了快取進行讀寫，對於任務系統的後設資料，我們選取了guava cache作為快取。原因是guava cache請求快速且簡單易用。任務後設資料資料量較小，即使每個節點都儲存一份快取，開銷也不大，這種情形使用分散式快取比較重，意義不大。 

業務效果

Tellus由於其功能支援的多樣性，可擴充性，以及可配置性的多種特點，在短時間內可以支援大量不同業務場景的上線，這裡我們以超級曝光和存量診斷也為為例，具體說明一下。超級曝光針對新發商品在商品釋出時彈出一個彈窗，引導使用者進入組合任務頁面完成任務，完成後使用者可獲得超級曝光特權。存量診斷針對存量商品，在寶貝下方透出第一個任務資訊，引導使用者進入組合任務頁面，完成組合任務。上線後，任務完成率翻倍。

開發效率提升

對於Tellus來說，比較大的一個挑戰是新增任務數量較多，較短時間內需要支援數百個任務，這幾乎是不可完成的工作。為了支援業務的快速試錯，並且降低開發成本，Tellus主要做了兩個方面的最佳化，一個是任務模版化，另一個是支援任務的可配置化。先說說任務的模版化：我們發現任務從表現形式上可以抽象為單選類、多選類、確認類、跳轉類等等。將每類任務定製為一個模版，視覺同學針對模板進行視覺抽象，固定展示樣式，服務端根據展示樣式抽象模板型別，前端完全基於服務端資料驅動，前後端的協議格式舉例如下：

新增任務時，只需要套模版即可，減少了很多重複開發的工作量。再說下任務的可配置化：在任務模版化的基礎上，我們發現對於某些任務，任務的邏輯基本一致，只是對應的任務文案不同。Tellus針對這些簡單任務，支援了任務可配置化的開發，目前1.0已經開發完成，原本需要改程式碼才可以新增一個任務，如今只需要改配置文案即可。後續2.0版本將做運營頁面的開發，運營同學只需要在頁面上配置即可，不再需要開發人員介入，從而大幅提高開發運營效率。

後續計劃

Tellus後續計劃與Omega和Hermes平臺對接。Omega是閒魚一個實時事件採集系統，透過日誌採集使用者行為事件，透過規則計算，對符合條件的使用者呼叫Hermes精準觸達。Hermes是閒魚的觸達系統，之前的公眾號文章也有介紹。舉個例子：使用者釋出商品，可以透過omega實時採集這一事件，然後實時生成該商品對應的某些任務，這樣相較於訊息的方式設計更合理，後期可擴充性更高；和Hermes的聯動，更多地體現在透過push等方式去促使使用者完成任務，增加任務的曝光。

Tellus還計劃增加一系列激勵措施，鼓勵使用者做任務，最近我們在和閒魚幣的同學進行對接，對於完成某類任務的使用者，透過給與一定量的閒魚幣，從而激勵使用者更多地完成任務。