愛彼迎如何實現聯合房東的共同託管？

Airbnb愛彼迎開發了一個協作託管基礎設施，支援所有型別的房東。這使得構建產品變得更加容易，因為工程師只需要瞭解一個涵蓋所有託管用例的中央框架。合作託管對於 Airbnb 上的許多房東的成功至關重要。為所有房東打造的無縫開發者體驗使我們能夠讓房東為房客提供出色的住宿體驗。

Airbnb 的使命是讓房東能夠提供獨一無二的住宿體驗，讓房客能夠以更真實、更互聯的方式體驗世界。有時託管是由一個人處理的，但在許多情況下託管是一個團隊的努力。房東通常會與另一個值得信賴的人分擔他們的責任，例如家庭成員或鄰居。這些值得信賴的合作伙伴是愛彼迎平臺上的聯合房東，他們有權訪問房東的房源、預訂資訊以及與房客進行資訊交流。

共同託管只是主持協作的一種形式。隨著託管成為主流，託管規模也隨之增長；事實上，現在很多人都將 Airbnb 房東作為他們的主要職業。從經營自己業務的房東企業家到隸屬於知名酒店公司的房東，這些型別的房東通過 Airbnb 上的團隊進行合作。在團隊內，接待團隊成員被授予與其實際接待職責相對應的角色（例如，客人經理）並擁有一組相應的許可權（例如，允許向客人傳送訊息）。

隨著協作主機數量的增加和新協作形式的引入，支援它們的工程工作變得越來越複雜。考慮到這一挑戰，Airbnb 開發了一個單一的通用基礎設施，可以支援所有當前和未來的 Airbnb 協作產品。此解決方案現在可供所有內部團隊使用。

在這篇博文中，我們將介紹 Airbnb 協作託管的統一架構，以及我們如何使用這種共享基礎架構來簡化為房東構建產品的過程。在下一節中，我們將說明為什麼在沒有共享基礎架構的情況下支援協作託管很快變得笨拙。然後，我們將介紹 Airbnb 的協作託管架構。最後，我們將討論此基礎架構如何支援產品工程師的需求。

。。。

協同託管核心架構

我們使用使用者組作為資料模型來表示任何一組人。使用者組由 id、組型別（例如COHOSTING、TEAM）和使用者組成員列表定義。

使用者組中的每個成員都由他們的 Airbnb 使用者 ID 和使用者組角色定義，這使我們能夠區分使用者組中不同型別的成員。例如，如果主持人（列表所有者）有一個共同主持人，那麼相應的使用者組將是一個COHOSTING具有兩個成員型別的使用者組：主持人，擁有LISTING_OWNER角色，共同主持人，擁有LISTING_COHOST角色。

此模型也可擴充套件到託管團隊。我們根據託管團隊通常如何分解團隊成員之間的職責（例如LISTING_MANAGER角色、FINANCE_MANAGER角色和角色）來支援特定於 Teams 的多個角色GUEST_MANAGER。

在共同主持人或團隊的建立和刪除流程中，相應的使用者組會相應更新。

資源 <> 使用者組關聯

現在我們有了一個用於任何協作託管組的模型，我們希望將每個組與該組的相應資源相關聯。這樣，當我們試圖回答關於一個人是否與給定資源有關係的問題時，無論具體的協作關係如何，都有一個單一的來源可以給我們答案。我們通過儲存 Airbnb 資源 ID、使用者組 ID 和建立關聯時的時間戳來跟蹤這些資源 <> 使用者組關聯。

需要更新資源<>使用者組關聯的場景有兩種：

1. 當協作託管關係更新時。例如，建立託管團隊時，團隊建立者的所有資源都與團隊相應的使用者組相關聯
2. 當協作託管資源更新時。例如，當客人在聯合託管房源上預訂時，我們需要將聯合託管使用者組與新預訂相關聯，以便房源的聯合託管人可以幫助房源所有者進行託管。

如果針對這些事件的更新沒有及時發生，產品體驗可能會過時。例如，如果房東將共同房東新增到列表中，但未更新基礎關聯，則共同房東將無法訪問列表及其預訂。

在 Airbnb 這樣規模的企業中，保持資源 <> 使用者組關聯的最新狀態可能具有挑戰性。事態不斷變化，有時是快速連續的；主持人可能會建立一個託管團隊，然後改變主意並立即將其刪除。結果，競爭條件確實發生了。

在本節的其餘部分，我們將介紹 Airbnb 的可擴充套件系統，以在競爭條件下保持資源 <> 使用者組關聯的最新狀態。在接下來的部分中，我們將詳細介紹 Airbnb 在產品開發過程中如何利用這些資源 <> 使用者組關聯。

點選標題見原文