摘要：異步事件處理本項目涉及到多種異步事件的處理。即是的粉絲，是的關注對象。模式定義優(yōu)缺點推事件觸發(fā)后廣播給所有粉絲。具體來說，推模式就是事件觸發(fā)后產(chǎn)生，觸發(fā)事件的用戶下所有粉絲的實現(xiàn)中都存入該的。

項目源代碼已托管在 Github，歡迎 Star、Fork。

QA 是一個基于 B/S 架構而設計開發(fā)的社區(qū)網(wǎng)站。

主要為用戶提供以下服務：

問題發(fā)布

評論

用戶私信

關注

站內(nèi)全文搜索

Spring Boot + MyBatis + MySQL + Redis + FreeMarker

為了保證用戶信息安全，系統(tǒng)對用戶密碼采用「salt + md5」方式進行加密。用戶注冊/登錄成功后，系統(tǒng)會生成一個 ticket ，將 ticket 與用戶 id 相關聯(lián)，并將此信息插入到數(shù)據(jù)庫表 login_ticket 中，同時將 ticket 響應給客戶端。

用戶每次請求頁面的時候，都需要先經(jīng)過 PassportInterceptor 攔截器，攔截器判斷此 ticket 是否真實有效，若是，根據(jù) ticket 對應的用戶 id ，查出相應用戶信息，并添加至頁面上下文中。

問題發(fā)布

評論發(fā)布

私信發(fā)布

在以上 UGC (User Generated Content, 用戶產(chǎn)生的內(nèi)容)中，系統(tǒng)都會進行 HTML 標簽及敏感詞過濾，這在一定程度上防止網(wǎng)站被注入腳本或者充斥著不良信息。

若沒有對 HTML 標簽進行處理，當用戶發(fā)布的內(nèi)容含有如時，網(wǎng)站頁面每次加載此內(nèi)容時都會彈出消息框。

對于敏感詞過濾，按照常規(guī)的思維，也是最簡單的方式，就是：對于每個敏感詞，都在文本中查找該敏感詞是否出現(xiàn)，出現(xiàn)則進行替換。這種方式，每個敏感詞都要在一段文本中進行遍歷查找，復雜度非常高。

本項目采用「前綴樹」方式實現(xiàn)敏感詞過濾，空間換時間，效率較高。前綴樹結點結構如下：

class TrieNode {
    // 標記是否為敏感詞結尾
    boolean end;
    
    // 該結點的所有直接子結點
    Map subNodes = new HashMap<>();
    
    // 添加一個子結點
    void addSubNode(Character key, TrieNode node) {
        subNodes.put(key, node);
    }
    
    // 根據(jù)key獲取子結點
    TrieNode getSubNode(Character key) {
        return subNodes.get(key);
    }
}

后臺從敏感詞文件 SensitiveWords.txt 順序讀取每一行建立前綴樹。進行過濾時，遍歷需要過濾的文本，用星號替換發(fā)現(xiàn)的敏感詞。假設文本長度為 len，前綴樹的最大高度為 h，那么此算法的最壞時間復雜度為 O(len*h)。

算法比較
假如敏感詞平均長度為10，數(shù)量為100000，文本長度為 len。
常規(guī)方式，復雜度O(100000  (len + 10))；前綴樹算法復雜度O(10  len)。

對于評論功能，系統(tǒng)建立的是一個統(tǒng)一的評論服務中心，通過 EntityType 與 EntityId 識別所評論的實體。用戶對于問題/評論的回復，都可以應用此服務。查詢某實體下的評論時，同樣根據(jù) EntityType 和 EntityId 查詢即可。

贊踩功能采用「Redis」作為數(shù)據(jù)存儲。Why Redis？

比較一下 Redis 和 MySQL:

Redis: key-value數(shù)據(jù)庫，數(shù)據(jù)放在內(nèi)存

MySQL: 關系型數(shù)據(jù)庫，數(shù)據(jù)放在磁盤

Redis 適合放一些頻繁使用、比較熱的數(shù)據(jù)。因為數(shù)據(jù)放在了內(nèi)存中，讀寫性能卓越。

除了用戶內(nèi)容贊踩，在本項目中，Redis 還應用于以下場景：

異步事件處理

關注服務

Timeline

本小節(jié)討論用戶內(nèi)容贊踩服務。

用戶對某一實體點贊，會將"LIKE:ENTITY_TYPE:ENTITY_ID"作為 key ，用戶 id 作為 value ，存入 like 集合中。同時移除 unlike 集合中該 key 對應的用戶 id。點踩服務反之。
最后將點贊數(shù)響應給頁面。

本項目涉及到多種異步事件的處理。如：

用戶評論了某個問題

用戶點贊了某條評論

用戶關注了另一個實體

這些動作并不是單一的，它們會觸發(fā)一些后續(xù)的操作：

用戶評論了某個問題，系統(tǒng)除了處理“評論”這個動作外，還需要給該問題對應的用戶發(fā)送一條消息，通知說“xx評論你的問題”，或者還需要給用戶增加積分/經(jīng)驗...

事件觸發(fā)者并不關心這些后續(xù)的任務，系統(tǒng)處理完某個動作后就可以將結果返回給觸發(fā)者，而后續(xù)的任務交給系統(tǒng)進行異步處理即可。

因此，設計一個異步事件處理框架尤為重要。
本項目的異步框架如下圖所示：

業(yè)務觸發(fā)一個異步事件，EventProducer 將該事件(EventModel)序列化并存入隊列(Redis List)中，EventConsumer 開啟線程循環(huán)從隊列中取出事件，識別該事件的類型，找出該類型對應的一系列 EventHandler，交由這些 Handler 去處理。

EventModel 的設計如下：

class EventModel {
    // 事件類型
    EventType type;
    
    // 事件觸發(fā)者
    int actorId;
    
    // 事件對應的實體
    int entityType;
    int entityId;
    
    // 事件對應的實體的Owner
    int entityOwnerId;
    
    // 一些擴展字段
    Map exts;
}

與評論功能類似，對于關注功能，系統(tǒng)同樣建立了一個統(tǒng)一的關注服務中心，用戶可以關注不同的實體(問題/用戶)，只需要通過 EntityType 和 EntityId 識別即可。
在數(shù)據(jù)存儲方面，采用 Redis 的 zset 完成，原因有以下幾個：

zset 有序，系統(tǒng)可以根據(jù)用戶關注實體的時間倒序排列，獲取最新的關注列表；

zset 去重，用戶不能重復關注同一個實體；

zset 可以獲取兩用戶之間的共同關注。

一個用戶，系統(tǒng)存儲兩個集合：

①保存用戶關注的實體；②保存關注用戶的人。

即 A 是 B 的粉絲，B 是 A 的關注對象。 [參考資料 ]

用戶關注了一個問題，需要發(fā)生兩個動作：

將問題存入①中

在②中存入用戶 id

這兩個動作必須同時發(fā)生，因此，這里用到了 Redis 事務保證原子性和數(shù)據(jù)的一致性。

另外，對于關注功能，如前面所說，會觸發(fā)異步事件，將消息通知被關注的實體 / 實體 Owner。

本系統(tǒng)未采用排名算法。若要了解相關算法，可以參考如下資料：

基于用戶投票的排名算法（一）：Delicious和Hacker News

基于用戶投票的排名算法（二）：Reddit

基于用戶投票的排名算法（三）：Stack Overflow

基于用戶投票的排名算法（四）：牛頓冷卻定律

基于用戶投票的排名算法（五）：威爾遜區(qū)間

基于用戶投票的排名算法（六）：貝葉斯平均

當用戶更新動態(tài)時，該用戶所有粉絲都可以在一定時間內(nèi)收到新的動態(tài)（也稱為新鮮事、feed），可以由 “推拉模式” 實現(xiàn)。

具體來說，推模式就是：事件觸發(fā)后產(chǎn)生 feed，觸發(fā)事件的用戶下所有粉絲的 Timeline(redis list 實現(xiàn))中都存入該 feed 的 id。而拉模式，就是當前用戶去拉取自己關注的人的 feed。

更多推拉模式相關，可以參考 微博 feed 系統(tǒng)推拉模式。

由于系統(tǒng)初始數(shù)據(jù)較少，為了豐富網(wǎng)站內(nèi)容，本項目采用 pyspider 實現(xiàn)對 V2EX 網(wǎng)站的數(shù)據(jù)爬取，存儲到后臺數(shù)據(jù)庫，并展示在前端頁面上。

安裝 pyspider：

pip install pyspider

啟動 pyspider：

pyspider

本項目在全文搜索服務上采用 Solr 框架，中文分詞采用 Solr 自帶的中文分詞插件 solr_cnAnalyzer 。