設計Pastebin

讓我們設計一個類似于web服務的Pastebin,用戶可以在其中存儲純文本。該服務的用戶將輸入一段文本,并獲得一個隨機生成的URL來訪問它。類似服務:pastebin.com,chopapp.com。難度等級:簡單

1. Pastebin是什么?

????類似于Pastebin的服務允許用戶通過網絡(通常是Internet)存儲純文本或圖像,并生成訪問上傳數據的唯一url。這類服務還用于通過網絡快速共享數據,因為用戶只需要傳遞URL就可以讓其他用戶看到它。
????如果你以前沒有使用過pastebin.com,請嘗試創建一個新的“Paste”在那里,花一些時間通過不同的選項他們的服務提供。這將對你理解本章有很大幫助。

2. 系統的需求和目標

我們的Pastebin服務應滿足以下要求:

功能需求:

1. 用戶應該能夠上傳或“Past”他們的數據,并獲得一個唯一的URL來訪問它。
2. 用戶只能上傳文本。
3. 數據和鏈接將在指定的時間范圍后自動過期;用戶也應該能夠指定過期時間。
4. 用戶應該有選擇地為他們的粘Past擇一個自定義別名。

非功能性需求:

1. 系統應高度可靠,上傳的任何數據都不應丟失。
2. 系統應該具有高可用性。這是必需的,因為如果我們的服務關閉,用戶將無法訪問他們的Past。
3. 用戶應該能夠以最小的延遲實時訪問他們的Past。
4. Past鏈接不應該是可猜測的(不可預測的)。

擴展要求:

1. 分析,例如,一個粘貼被訪問了多少次?
2. 其他服務也應該可以通過REST api訪問我們的服務。

3.一些設計方面的考慮

????Pastebin與URL Shortening服務共享一些需求,但還有一些額外的設計考慮我們應該記住。
????用戶一次可以粘貼的文本量的上限是多少? 我們可以限制用戶的paste大小不超過10MB,以防止濫用該服務。
????我們應該對自定義url設置大小限制嗎? 由于我們的服務支持自定義URL,用戶可以選擇他們喜歡的任何URL,但提供自定義URL不是必須的。但是,對自定義URL施加大小限制是合理的(通常也是可取的),這樣我們就有一個一致的URL數據庫。

4. 容量估計和約束條件

????我們的服務需要大量閱讀;與創建新的paste相比,會有更多的讀請求。我們可以假設讀寫的比例為5:1。
流量估算:Pastebin服務預計不會有類似于Twitter或Facebook的流量,讓我們在這里假設我們每天有100萬個新粘貼添加到我們的系統。這樣我們每天就有500萬的閱讀量。
每秒新Paste次數:

100萬 / (24hour * 3600秒) = ~ 12 pastes/s

Paste每秒讀的次數:

500萬 /(24hour * 3600秒) = ~58 paste/s

存儲容量估算:用戶最多可以上傳10MB的數據;通常類似于Pastebin的服務
用于共享源代碼、配置或日志。這樣的文本并不大,所以讓我們假設每個粘貼平均包含10KB。
按照這個速度,我們每天將存儲10GB的數據。

100萬 * 10 KB = 10GB/day如果我們想要存儲這些數據十年,我們將需要36TB的總存儲容量。????每天有100萬個`Paste`,10年后我們將有36億個`Paste`。我們需要生成和存儲鍵來惟一地標識這些粘貼。如果我們使用base64編碼([A-Z, A-Z, 0-9, ., -]),我們將需要六個字母字符串:?64 ^6 = 687億????如果存儲一個字符需要一個字節,則存儲36億鍵所需的總大小為:36億 * 6B = 22G????與36TB相比,22GB可以忽略不計。為了保留一些剩余空間,我們將假設一個70%的容量模型(這意味著我們在任何時候都不希望使用超過總存儲容量的70%),這將使我們的存儲需求提高到51.4TB。

帶寬估計:對于寫請求,我們期望每秒12個新Paste,導致每秒120KB的輸入。

12*10K == ~ 120KB/s
對于讀請求,我們期望每秒58個請求。因此,發送給用戶的總數據出口為0.6 MB/s。58 *10KB = 0.6 MB/s雖然總入口和出口并不大,但我們在設計服務時應該牢記這些數字。**內存估計**:我們可以緩存一些經常被訪問的熱`Paste`。遵循80-20規則,即20%的熱`Paste`產生80%的流量,我們希望緩存這20%的`Paste`由于我們每天有5M個讀請求,要緩存其中的20%,我們需要: 500萬*10KB * 0.2= 10G## 5. 系統api我們可以使用SOAP或REST api來公開服務的功能。下面是創建/檢索/刪除`Paste`的api定義:`addPaste(api_dev_key, paste_data, custom_url=None user_name=None, paste_name=None, expire_date=None)`**參數**:> api_dev_key (string): 注冊帳戶的API開發者密鑰。這將被用來,在其他事情的基礎上,限制用戶分配的配額。> paste_data (string): `Paste`的文本數據。> custom_url (string): 可選的自定義URL。> user_name (string): 可選用戶名,用于生成URL。> paste_name (string): `Paste`的可選名稱> expire_date (string): 可選的`Paste`過期日期。

返回:(字符串)
成功的插入將返回可以訪問Paste的URL,否則將返回錯誤代碼。

類似地,我們可以使用檢索和刪除Paste api:
getPaste(api_dev_key, api_paste_key)
????其中“api_paste_key”是一個字符串,表示要檢索的粘貼的粘貼密鑰。這個API將返回粘貼的文本數據。
deletePaste(api_dev_key, api_paste_key)
刪除成功返回' true ',否則返回' false '。
6. 數據庫設計
以下是對我們所存儲數據性質的幾點觀察:

1. 我們需要存儲數十億條記錄。
2. 我們存儲的每個元數據對象都很小(小于100字節)。
3. 我們存儲的每個Paste對象可以是中等大小(可以是幾MB)。
4. 記錄之間沒有關系,除非我們想存儲哪個用戶創建了什么 Paste。
5. 我們的服務閱讀量很大。

數據庫模式:

我們需要兩個表,一個用于存儲關于paste的信息,另一個用于存儲用戶數據。

• paste信息表

URLHash: varchar(16)
ContentKey: varchar(512)
Name: varchar(20)
ExpirationDate: datatime
Email: varchar(32)
CreationDate: datetime

• 用戶數據表

UserID: int
Name: varchar(20)
Email: varchar(32)
CreationDate: datetime
LastLogin: datatime

高級設計

????在較高的層次上,我們需要一個應用程序層來處理所有的讀寫請求。應用層與存儲層通信以存儲和檢索數據。我們可以將存儲層隔離為一個數據庫存儲與每個粘貼、用戶等相關的元數據,而另一個數據庫將粘貼內容存儲在某個對象存儲(如Amazon S3)中。這種數據劃分還允許我們單獨地擴展它們。

8. 組件設計

????我們的應用程序層將處理所有傳入和傳出請求。應用服務器將與后端數據存儲組件進行通信以處理請求。

a.應用程序層

????如何處理寫請求? 在接收到寫請求時,我們的應用服務器將生成一個6個字母的隨機字符串,它將作為粘貼的密鑰(如果用戶沒有提供自定義密鑰)。然后,應用服務器將在數據庫中存儲粘貼的內容和生成的密鑰。成功插入之后,服務器可以將密鑰返回給用戶。這里可能出現的一個問題是由于重復的鍵導致插入失敗。因為我們正在生成一個隨機密鑰,所以新生成的密鑰有可能與現有的密鑰相匹配。在這種情況下,我們應該重新生成一個新密鑰并重試。我們應該繼續嘗試,直到我們沒有看到由于重復的密鑰而失敗。如果用戶提供的自定義密鑰已經存在于我們的數據庫中,則應該向用戶返回一個錯誤。
????上述問題的另一個解決方案可能是運行一個獨立的密鑰生成服務(KGS),它事先生成隨機的6個字母字符串,并將它們存儲在數據庫中(我們稱之為Key - db)。每當我們想要存儲一個新的粘貼時,我們只需要取一個已經生成的鍵并使用它。這種方法將使事情變得非常簡單和快速,因為我們不需要擔心重復或碰撞。KGS將確保key-DB中插入的所有鍵都是惟一的。KGS可以使用兩個表存儲鍵,一個用于尚未使用的鍵,另一個用于所有已使用的鍵。一旦KGS將一些密鑰提供給應用服務器,它就可以將這些密鑰移動到使用的密鑰表。KGS可以始終在內存中保留一些鍵,以便在服務器需要時快速提供它們。一旦KGS在內存中加載了一些鍵,它就可以將它們移動到已使用的鍵表中,這樣我們就可以確保每個服務器獲得唯一的鍵。如果KGS在使用內存中加載的所有鍵之前死亡,我們將浪費這些鍵。我們可以忽略這些鍵因為它們的數量非常多。
KGS難道不是單點故障嗎? 是的,它是。為了解決這個問題,我們可以有一個KGS的備用副本,當主服務器死亡時,它可以接管生成并提供密鑰。
每個應用服務器可以從key-DB緩存一些鍵嗎? 是的,這肯定能加快速度。盡管在本例中,如果應用服務器在使用所有密鑰之前死亡,我們將最終丟失這些密鑰。這是可以接受的,因為我們有68B個唯一的6個字母的鍵,這比我們需要的多得多。
它如何處理粘貼讀取請求? 在接收到讀粘貼請求后,應用程序服務層與數據存儲聯系。數據存儲將搜索鍵,如果找到鍵,則返回粘貼的內容。否則返回錯誤碼。

b.數據存儲層

????我們可以將數據存儲層分為兩層:

1. 元數據數據庫:我們可以使用像MySQL這樣的關系數據庫,或者像Dynamo或Cassandra這樣的分布式鍵值存儲。
2. 對象存儲:我們可以將內容存儲在類似Amazon S3的對象存儲中。當我們想要達到內容存儲的最大容量時,我們可以通過添加更多的服務器來輕松地增加容量。