1. 引言

大家好，我是小?，一個流浪江湖多年的 985 非科班程序員，曾混跡于國企、互聯網大廠和創業公司的后臺開發攻城獅。

1.1 尋找電影般的浪漫

“嘀嗒嘀嗒”，“嘀嗒嘀嗒”，當夜幕降臨，你還在代碼的海洋中與 BUG 進行著“持久戰”。

突然，你意識到，生活中不應只有鍵盤和屏幕，于是像個待充電的超人一樣，決定給自己來點人際交流的活力補給。右手揮舞鼠標，左手掏出手機，邊關閉 IDE 邊滑動 App。

這個時候，尋找知己的老難題又閃現在腦海：要不要先檢查一遍今日代碼、再做一次單元測試，還是直接跳入“尋緣池”？（真實情況可能是，今天跳入哪個尋緣池 ?? ）

圖片

好不容易做出了一個勇敢的決定——關閉電腦，從椅子一躍而起。你拿出手機，點開了熟悉的交友 App。

然后，個人資料頁面在屏幕上亮了起來，這可是你走出虛擬世界的敲門磚。

你快速瀏覽著，現實世界中其他的編程愛好者、攝影迷、文藝青年...，都在這個小小的舞臺中綻放著個性的光芒。

不需排隊買飲料，不再擔心交友聚會上的尷尬沉默。你滑過一個又一個感興趣的頭像，終于，停留在某個共鳴的話題上，準備展開一次思想的交鋒。

1.2 技術支撐下的交友系統

就像前文所述，人們想要跳出孤獨的循環，唯一需要的是一臺手機，一個友好的交互界面。

那這個誘人的交友系統是如何誕生的呢？它背后的算法和架構又是如何支撐起你我情感交流的橋梁呢？

今天，讓我們一同撩開這個現代愛情駭客的神秘面紗，深度解碼交友系統的設計與實現。

在這篇文章中，小?將分享常見交友軟件的系統設計，探索它是如何在短短幾年內從 idea 到蓬勃發展再到沒落的（不是，瞎說什么大實話！

2. 需求分析

2.1 Small Chat

在一個宇宙般無垠的數字海洋中，浮現了名為 Small Chat 的愛情小島。

圖片

這座島不是用巖石建成，而是由一群單身狗（咳咳，我是指單身男女）手機里的一個個 App 打造而成。說起這個 App，它簡直是孤獨心靈的救星，一個紙杯電話 2.0 版，或者說是一扇帶你邂逅愛情奇遇的神奇窗戶。

2.2 功能需求

圖片

打開這款叫做 Small Chat 的 App，就如啟動太空艇的第一步，用戶得先登錄自己的小小太空艇——上傳星球生活照，裝飾個人艙室（自我介紹）。

此時，這位宇航員您可以種下自己的位置信標，并根據個人偏好裝配指南 needle（推薦算法）。

算法這個家伙和那位算命先生有點像，據說它會依據用戶的星際坐標和你那閃閃發亮的個人信息（據說，每個程序員都認為自己是全村最靚的仔），匹配茫茫宇宙中的其他太空艇，它們都和你泊在相鄰的星域。

現在，你就可以在手機熒光屏上批量欣賞這些來自銀河系各個角落的宇航員的艙室（就是 Ta 們的照片和資料）。

要是心中一動，想要走得更近一些，用戶還可以大膽地向右滑動這張星際許可證——就像在說：“嘿，boy/girl，你在宇宙中并不孤單”！

當然，如果兩個孤獨的太空艇都向右轉了舵，哦，這不就意味著星際之船即將交匯了嗎？這個時候，系統就會像個熱心的宇航局一樣，發來一條信息：“恭喜，你們已經成功配對！”

這時，愛情的宇宙軌道就開啟了哦！

于是，兩位宇航員就可以開始在私人頻道上暢所欲言，探索彼此的宇宙，看看是否能點燃繁星。

2.3 非功能需求

現在，讓我們來分析一下 Small Chat 星球的潛在居民數量。

我們估算在這片浩渺的銀河系中，有超過 1 億顆孤單的心正在尋找彼此的引力波。因此，我們從 1 億個星際交流頻道出發，為 Small Chat 的后臺系統做設計。

想象一下，那是一個可以讓 1 億顆心交織在一起的宇宙網絡啊！

這不僅是技術的挑戰，也是對愛情信號強度的考驗。而這，就是我們今天要介紹的 Small Chat ——不只是一個交友 App，而是銀河系統中一個關于愛情的奇妙設計。

3. 概要設計

在數字化的銀河系中， Small Chat 是一個獨特的星球，擁有著精妙絕倫的生態系統。

3.1 整體架構

不妨把它想象為一座由微服務構成的未來城市，這里的每一個角落都通過智能網關保護著，就像是銀河巡警，確保通道暢通無阻。

這座未來城市的每個街區都是一個專門的小微服務工廠：用戶工廠、鄰近算法工廠、配對工廠、聊天工廠、還有那個精確匹配你可能邂逅愛情坐標的推薦工廠。

圖片

在 Small Chat 的系統架構中，我們采取了被廣泛認可的微服務架構設計。

首先，用戶通過一個集中的網關服務來接入不同的微服務，你可以將其視為一個高效的調度中心，既能保安全，又能提高效率。

然后，用戶的所有請求首先被發送到這個網絡門衛——也就是網關服務器。這個網關服務器的任務范圍相當廣泛，它既要做好流量的管制工作，保護系統免受過多請求的壓垮，也要時刻警惕潛在的網絡攻擊，同時對用戶的身份和權限進行校驗。

此外，網關服務器還起到了一個'中介'的角色，把用戶的請求引導到相應的微服務，并將返回的數據整合后再展現給用戶。

根據預估的用戶級，這個網關服務器需要能夠應對每天高達千萬甚至億萬次的訪問量。

3.2 業務系統

然后是微服務的各個具體組件，用戶系統是負責管理和存儲用戶個人信息的模塊，包括用戶的登錄認證，所有的用戶都必須通過這個服務來驗證身份才能使用系統的其他功能。

為了處理龐大的數據量，這里用到了分片技術的 MySQL 數據庫系統，并將它們放在一個集群里面，方便彈性伸縮。

分布式對象存儲集群主要存儲了用戶上傳的圖片、音視頻信息，以及聊天時用到的表情包圖片或者其它文件信息，文件的元數據放置在 DB 存儲。

圖片

此外，為了更高效地提供圖片，我們通過 CDN 服務緩存了用戶訪問頻率較高的熱門圖片，以加速圖片加載速度。

至于配對系統，它則是負責用戶互相"右劃"表示喜歡后進行配對的模塊，如果兩個人互相"右劃"了對方，這個服務就會將這對用戶加入到對方的通訊錄中。

最后，推薦系統的責任是將可能相互感興趣的用戶推薦給對方，這需要結合用戶的行為、興趣愛好和前述的"配對"情況來進行智能推薦。

同時，考慮到地理位置的親近性因素，這個服務時常會與算法團隊密切合作，確保推薦的對象在地理上也方便用戶進行真實的社交互動。

通過這些微服務的配合， Small Chat 的平臺可以以模塊化的方式靈活地擴展功能，同時保證了用戶數據處理的效率和安全。

4. 詳細設計

4.1 高并發挑戰

對于交友系統來說，高并發處理是確保用戶體驗和系統穩定性的首要技術挑戰。對于一個可能有著幾千萬用戶同時在線的系統來說，維護系統穩定性需要注意以下幾點。

1. 水平擴展與負載均衡

圖片

• 首先，采用無狀態的設計模式，讓系統后端服務能夠在多個處理單元之間進行水平擴展。這意味著任何一個單元都可以獨立處理請求，而不依賴于特定的上下文信息。
• 部署負載均衡器，將流量分發到多個后端服務器。負載均衡器可以是硬件負載均衡器，也可以是如 Nginx 這樣的軟件解決方案，其利用算法（如 輪詢、最小連接數、一致性哈希 等）智能地將用戶請求分配到處理能力最佳的服務器節點。
• 實現自動擴縮容機制，監控系統的負載情況，當流量急劇上升，超過預置閾值時，自動擴展服務器實例；當流量下降時，適當減少實例以節約成本。

2. 數據庫優化和緩存策略

圖片

• 數據庫分區和分片，將數據分布到多個數據庫中，每個數據庫只負責處理一部分數據，數據庫之間可通過分布式事務進行數據一致性控制。

不了解 DB 分庫分表的同學可以看我之前的這篇文章：MySQL高可用，分庫分表你學廢了嗎

• 使用讀寫分離模型，通過主從復制的方式攤開讀操作的壓力。寫操作只在主數據庫上進行，而讀操作則可以在多個從數據庫上進行，這樣可以大幅提高數據庫的讀取性能。
• 引入緩存系統，如 Redis 或 Memcached，將頻繁讀取的數據，如用戶的基礎信息、用戶的交互動態緩存起來。對于交友系統來說，用戶的動態信息、瞬時狀態等可以緩存，減少數據庫的請求次數。

3. 消息隊列和異步處理

• 引入消息隊列，比如 Kafka 或 RabbitMQ，用來解耦應用服務和后端處理。這允許系統在面對突發流量時把請求排隊，而不是直接在數據庫或服務層上造成壓力，從而提高整體系統的彈性和響應能力。比如，用戶聊天時可以把消息通知放到隊列中排隊處理。
• 異步執行耗時操作，比如用戶的 匹配運算、數據分析 等可以放在后臺服務中異步執行，用戶不需要同步等待這些操作完成。特別是用戶匹配機制，可以放到并發量小的時段統一進行。

需要要注意的是，以上策略需要遵循微服務架構的原則，將系統拆分為多個松耦合、易于擴展的小型服務，每個服務可以單獨部署，獨立擴展。

通過這些架構層面的優化，即便 Small Chat 面臨幾千萬到上億級別的用戶并發請求，也能保持服務的高可用性和穩定性。

4.2 空間鄰近算法

如何根據用戶的地理位置尋找距其一定范圍內的其他用戶，也是交友系統中必不可少的一個考慮點。

空間鄰近算法是為了解決 給定一個點，找出距離其最近的點 這一問題的算法。在不同的應用背景下，會有不同的考量因素，如精度、效率、存儲需求和實施的難易程度等，以下是一些常見的空間鄰近算法。

1. 常見的空間鄰近算法：

1）網格（Grid）算法

這種算法是將地理空間簡單劃分成網格，可以認為網格內的點是鄰近的。

為提高鄰近好友查詢效率，我們的系統可以按照一定規則把每位用戶歸類到一個特定的網格，并在他們的用戶信息里標記對應的網格ID（gridID），將位置信息存入 MySQL 中。

這樣，當需要查找用戶附近的人時，我們可以將 3*3 的網格視為相近用戶，這樣僅需搜索目標用戶所在的那個網格以及其相鄰的八個網格內的用戶即可。

但是，即便如此，每當面對 DB 的高頻訪問時，這類查詢仍然可能會帶來負擔：一方面是太慢，另一方面是不精確，邊界處理也比較復雜。

為了進一步優化，我們決定把所有網格及其中的用戶信息都存儲在內存中，這樣就可以避免頻繁的 DB 操作。對于鄰近用戶的查詢，通過內存中的數據進行計算即可。

首先，我們可以把所有用戶的經緯度信息加載到內存中，實現這一解決方案的關鍵在于選擇合適的網格尺寸，并能快速確定用戶所在的網格及其周邊網格信息。

實踐中，通常會用到 四叉樹網格 和  GeoHash 算法 來優化這一過程。

2）四叉樹（Quadtree）網格算法

四叉樹網格算法類似網格方法，但是網格的大小是動態分配的。

圖片

它底層使用了四叉樹結構自適應地調整網格大小，以處理用戶密度不同的區域，這種算法對不均勻分布的數據集表現更好。

具體來說，在人口密集區，它通過細分網格來減少每個網格的用戶量（比如深圳南山、北京海淀）；而在人疏少地，網格則相應擴大（比如一些用戶數較少的平原地區）。

這種方法保證了每個網格的用戶數不超過設定閾值（例如 500 人），當查詢附近用戶時，算法從四叉樹的根節點開始逐級向下，直至抵達包含目標用戶的葉子節點。為了進一步查找鄰近網格用戶，可通過將所有葉子節點連成一個雙向鏈表來實現（類型 B+ 樹的網狀結構）。

盡管該算法適應了很多場景，但編程實施較復雜且若網格大小設置不當，會影響搜索性能，接下來我們再看 Geohash 算法。

3）Geohash 算法

Geohash 算法是一種將二維空間坐標編碼為一維字符串的方法，它可以有效地表示地理位置信息。

圖片

在交友系統中，Geohash 可以用來索引用戶的位置，以便快速查詢附近的用戶。結合 Redis 這樣的內存數據存儲，使用 GeoHash 應對大規模地理位置處理成為可能。

1. 用戶位置編碼

當用戶提供自己的位置信息，通常是經度和緯度，系統會使用 GeoHash 算法將這些坐標轉換為一個字符串。GeoHash 將地圖劃分為網格，每次劃分會將網格細分為更小的區域，經緯度坐標每一次細分都相應地在 GeoHash 字符串上增加一個字符。

2. 存儲用戶位置

得到 GeoHash 字符串后，可以使用 Redis 自帶的地理空間索引 GeoSpatial index（Redis3.2 之后支持），直接使用 GEOADD 命令添加用戶的地理位置信息。

3. 查詢附近的用戶

當需要查找一個用戶的附近用戶時，系統可以做如下操作：

• 首先，獲取查詢用戶的 GeoHash 字符串；
• 使用 Redis 的 GEOSEARCH 或類似的命令，通過指定中心點（即查詢用戶的位置）和搜索半徑，查詢附近的用戶；
• Redis 會返回在該區域內的所有用戶 ID 和它們的位置信息。

4. 結果排序和范圍限制

Redis 的 GEOSEARCH 命令返回的結果已經根據距離中心點的遠近排序，查找到的用戶可以進一步按實際距離排序。

如果系統需要對結果進行限制，如只顯示前10個最近的用戶，可以在查詢時指定或者在查詢后處理。

2. 如何選擇

在交友系統中，由于地理位置是不斷變化的，咱們需要一個可以處理動態數據集的算法。并且，為了在大規模用戶中工作，需要考慮算法的效率和擴展性。

GeoHash 由于其簡單性和易于與其他存儲解決方案結合使用（如 Redis），在許多現代的定位系統（如 T3 出行、滴滴打車）中非常受歡迎。

所以在 Small Chat 中，我們也使用 GeoHash 算法來處理位置信息以及附近用戶的匹配機制。

4.3 推薦算法

推薦算法在交友平臺中至關重要，它直接影響用戶的體驗和平臺的留存率。

在 Small Chat 中，我們綜合考慮用戶的互動、地理位置等因素來給用戶打分，并最終生成一個排名（rank）值，用以推薦其他匹配的用戶。

1. 用戶特征與行為因素

用戶的每一項行為都可能成為加分項，比如：

• 活躍度加分：用戶登錄頻率、交互次數等，表示用戶對平臺的參與度。
• 完善度加分：用戶資料的完整性，包括真實身份認證、興趣愛好、自我介紹等。
• 正面互動加分：其他用戶對該用戶的正面評價，如點贊、喜歡、私信等響應。
• 新鮮度加分：新注冊用戶或長時間未登錄后重新快樂用戶可能會有一定加分，這點，在很多 moba 手游的匹配機制里得以充分體現，比如 王者榮耀、和平精英 等。

2. 地理位置因素

• 地理鄰近加分：距離用戶較近的其他用戶會獲得額外加分。這可以通過 GeoHash 位置算法計算得出。

3. 算法打分機制

設置一個打分系統，每個因素根據其重要性分配權重，比如：

• 活躍度權重：25%
• 資料完善度權重：20%
• 正面互動權重：30%
• 距離權重：25%

用戶得分計算公式可表示為：

UserScore = {活躍度分} * 25% + {最大資料完善度分} * 20% + {最大正面互動分} * 30% + {最大距離分} * 25%

4. 推薦列表的生成

得到每個用戶的得分后，為目標用戶生成推薦列表的過程如下：

1. 用戶相似性計算：首先，通過用戶的行為和資料完善度找到傾向上相似的用戶。
2. 位置篩選：其次，利用位置信息篩選出距離合適的候選人。
3. 綜合得分排序：根據上述的得分機制對所有篩選后的用戶計算得分，得到每個用戶的排名值。
4. 推薦列表生成：最后，根據得分從高到低排列用戶，生成推薦列表。

為了優化響應，我們可以將一定范圍的 Rank 列表保存到 Redis 的 Sorted Set 里。其中 key 為用戶 Id， score 字段為推薦度分數，field 列為被推薦的用戶 Id。

5. Rank值的更新

Rank 值不是靜態的，它應隨著用戶行為的變化動態更新。比如，用戶的活躍度可以是逐日遞減的，而一次新的正面互動則能帶來即時的得分提升。

在實踐中，可以通過設定定時任務，如每日或每周更新一次用戶得分。對于即時性較強的操作（如互動行為），可以觸發即時的得分更新流程。

5. 小結

以上，我們對現代交友系統的一些常見技術難點做了一個大致的剖析，從用戶對浪漫邂逅的渴望出發，到細致的技術構建。

Small Chat 系統不僅讓屏幕前的很多單身貴族與各種可能的緣分相遇，更在龐大訪問壓力下，展示了其穩定的架構。通過微服務、負載均衡、數據庫優化、緩存、異步處理和空間鄰近算法的使用，讓一個可擴展、高效且個性化的交友應用得以呈現。