面臨問題
在閒魚生態裏，用戶之間會有很多種關係。其中大部分關係是由買家觸發，聯繫到賣家，比如買家通過搜索、收藏、聊天等動作與賣家產生聯繫；另外一部分是平臺與用戶之間的關係。對這些關係分析之後我們發現這些關係中存在兩個問題：
-
用戶產生關係的層次不夠豐富； 現有系統只維護了一部分用戶關係，包括收藏、點贊等，用戶關係的層次還不夠豐富。
-
用戶之間關係是單向且不夠實時； 在現有的玩法中，買家可以通過多種行爲與賣家產生聯繫，但賣家不能主動與買家發生關係和互動；而且平臺計算的關係都是離線的，對用戶的吸引力不足。
上面提到的場景經過抽象歸納之後都是同一個範式：當某個條件被滿足之後，就會觸發相對應的動作。這個範式是IFTTT的基本理念，而閒魚IFTTT就是對這些問題的解決方案。
IFTTT概念
IFTTT是一個被稱爲 “網絡自動化神器” 的創新型互聯網服務理念，它很實用而且概念很簡單。IFTTT全稱是 *If this then that *，意思是如果滿足“this”條件，則觸發執行“that”動作。IFTTT由三部分構成，分別爲Trigger、Action和Recipe。
可以看出IFTTT本身概念並不複雜，它的真正魔力在於“由簡單組成的複雜”，也就是由衆多簡單的IFTTT流程相互銜接成跨越整個互聯網、跨越多平臺、跨越多設備的狀態機。
閒魚IFTTT是基於閒魚的業務場景與IFTTT理念結合後產生的，提供IFTTT標準協議封裝，對業務無侵入可擴展的服務編排系統。
閒魚IFTTT的兩個特性對應上述兩個問題，分別是：
-
多維用戶關係感知
多維指的是覆蓋面，閒魚IFTTT通過更多維度的挖掘，抽象並維護了更豐富的用戶關係。基於用戶關係數據，我們可以產出用戶畫像，並通過更有效的方式觸達用戶。
-
實時用戶雙向互動
閒魚IFTTT底層具有對用戶關係大數據的高效存儲和處理能力，以支持上層業務中用戶關係實時處理；閒魚IFTTT不僅支持買家到賣家關係，而且通過設計天生支持賣家到買家關係。
閒魚IFTTT把之前平臺與用戶的互動、買家到賣家的聯繫，切換稱閒魚用戶之間天然的關係互動，對用戶騷擾更少且激活拉回的效果更好，我們基於這個場景設計閒魚IFTTT的技術方案。
技術方案
-
Channel Channel層在閒魚IFTTT的作用是保存和管理用戶關係數據，Channel層定義了用戶關係的元數據結構，包括關係類型、源賬戶和目標賬戶。Channel層是閒魚IFTTT的基石，Trigger和Action均基於用戶關係數據進一步抽象業務邏輯。
-
Trigger Trigger是業務上自定義的觸發事件，與業務息息相關，可能是關注的人上新、瀏覽寶貝降價或者是參加的百幣奪寶活動開獎等。當Trigger觸發後，閒魚IFTTT會根據Trigger類型和配置的關係類型計算用戶名單，並調用Action層進行處理。
-
Action Action層處理對象是Trigger觸發後計算的用戶名單，可以給名單裏的用戶發Push，發權益或者其他定製邏輯。Action本身是標準化、可插拔的組件，業務上可以利用Action組件對用戶名單做AB測試，快速實驗不同Action策略。
接下來我們說一下閒魚IFTTT詳細技術方案，方案如下：
場景快速接入
設計場景快速接入的目的是讓業務對接入閒魚IFTTT無感知，因爲在最開始的設計中，場景接入是準備通過在業務邏輯裏增加AOP切面，將業務數據和場景上報。但因爲這種方式對業務本身有一定侵入，增加業務執行的RT而且不夠靈活，最終被否決。
而現在的場景快速接入方案解決了這些問題，通過SLS接入所有應用的海量網絡請求日誌，記錄請求的URL、參數和響應；將SLS作爲Blink流計算任務的數據源；根據diamond動態下發的規則實時篩選網絡請求URL和參數，把數據按照指定格式組裝後上報給Channel層。
場景快速接入方案將業務邏輯與場景接入解耦，支持快速接入，靈活變更且延遲低，是針對大數據場景接入的高性能解決方案。
計算用戶名單
計算用戶名單模塊採用責任鏈模式設計，因爲在不同Trigger場景中，業務對用戶名單的計算和篩選邏輯都是不同的。通過責任鏈模式，將主流程與業務篩選邏輯解耦，並支持各業務靈活定製篩選邏輯，互不干擾。
PushAction
Action層是閒魚IFTTT中最重要的一環，會直接觸達到用戶，Action的邏輯會直接影響用戶對平臺的直觀感受和活躍率。消息Push是Action中最常見的邏輯，更要防止用戶被騷擾，PushAction邏輯如下：
-
敏感人羣過濾；
-
疲勞度校驗；
-
對發送人羣進行AB實驗；
-
組裝消息；
-
將Action各節點日誌同步到SLS，方便檢索和排查問題；
-
統計消息發送數據及點擊數據，爲業務後續決策提供依據；
其中，疲勞度是防止用戶被騷擾的關鍵，我們針對疲勞度進行了分層設計，分爲三層，第一層爲用戶級別疲勞度，控制一個用戶在一個週期內收到消息數量；第二層是業務維度，控制用戶在一個週期內收到某個業務的消息數量；第三層是目標級別，控制用戶在一個週期內收到同一個發送者消息數量。
在業務維度層面，支持靈活控制多個業務聯合疲勞度，保證用戶不會被消息過度騷擾。
用戶關係存儲
用戶關係數據是閒魚IFTTT的基石，它的特點是存儲量級大，達到TB級別；而且對存儲和查詢的性能要求高，TPS和QPS的峯值都在一萬以上。經過調研，我們發現集團內部開發的Lindorm可以滿足需求。
Lindorm是阿里內部基於Hbase自研的高性能KV存儲數據庫，對Hbase的性能和穩定性均有一定優化。閒魚IFTTT採用Lindorm作爲用戶關係數據存儲，經性能測試驗證數據讀取QPS達到7萬，數據存儲TPS在10萬以上。Lindorm本身性能優異，爲閒魚IFTTT高性能奠定基礎。
效果
閒魚IFTTT自上線以來，已支持關注上新、瀏覽寶貝降價和租房小區上新等多個業務場景，提供買賣雙方實時雙向互動能力，平均每天處理關係數據數億條，處理Trigger量達到上千萬，處理Action量達到億級別，消息點擊率較離線push提高1倍以上。
閒魚IFTTT目前支持的是用戶互動場景，後續我們將結合閒魚自身業務特點，對IFTTT進行更高維度抽象，封裝標準Recipe接口，將閒魚IFTTT打造成提供流程編排、管理能力的服務平臺。
在我看來，IFTTT從2010年推出以來，在國外有很大的熱度，在互聯網和物聯網領域都有專門的公司和團隊在研發，IFTTT的概念雖然簡單，卻通過標準化協議滿足用戶的強需求-讓各種互聯網產品爲用戶服務。這其實也給我們互聯網從業者一些思考：在新機遇面前，究竟是快速投入比較重要還是抽象標準協議解決一類問題更加有效？
名次註解
-
SLS：https://cn.aliyun.com/product/sls
-
Diamond：阿里內部研發的持久配置管理中間件；
-
Blink：https://data.aliyun.com/product/sc?spm=5176.10695662.1131226.1.bf495006EWuVAB
-
MetaQ：阿里內部研發的分佈式、隊列模型的消息中間件；
-
Lindorm：阿里內部基於HBase研發的新一代分佈式NoSQL數據庫，阿里雲類似產品：https://www.aliyun.com/product/ots?spm=a2c4g.11174283.cwnn_jpze.59.2f5a15c3NH30me；
-
Tair：阿里內部研發的高性能、分佈式、可擴展、高可靠的Key-Value結構存儲系統；