項(xiàng)目簡(jiǎn)介：Pastebin是一個(gè)在線的文本存儲(chǔ)平臺(tái)，讓用戶可以存儲(chǔ)和分享代碼片段或者其他類型的文本。它支持多種編程和標(biāo)記語(yǔ)言的語(yǔ)法高亮，用戶可以選擇讓他們的"paste"公開(kāi)或私有。無(wú)需注冊(cè)就可以使用，但注冊(cè)用戶可以更方便地管理他們的"paste"。Pastebin常被開(kāi)發(fā)者、系統(tǒng)管理員以及其他技術(shù)專業(yè)人員用于分享和協(xié)作。

現(xiàn)在讓我們來(lái)設(shè)計(jì)一個(gè)類似Pastebin的網(wǎng)絡(luò)服務(wù)，用戶可以在這里儲(chǔ)存純文本。用戶可以輸入一段文本，并獲取一個(gè)隨機(jī)生成的URL來(lái)訪問(wèn)這段文本。

類似的產(chǎn)品有：pastebin.com，controlc.com，hastebin.com，privatebin.net

系統(tǒng)難度等級(jí)：初級(jí)

1、什么是Pastebin

Pastebin及類似服務(wù)讓用戶能夠在網(wǎng)絡(luò)（通常指的是互聯(lián)網(wǎng)）上存儲(chǔ)純文本或圖像，并生成唯一的URL來(lái)訪問(wèn)上傳的數(shù)據(jù)。這樣的服務(wù)也被用來(lái)快速地在網(wǎng)絡(luò)上共享數(shù)據(jù)，用戶只需傳遞URL，其他用戶就可以查看其內(nèi)容。

如果你以前沒(méi)有使用過(guò)pastebin.com，建議嘗試在那里創(chuàng)建一個(gè)新的“Paste”，并花些時(shí)間瀏覽他們服務(wù)提供的不同選項(xiàng)。這將在理解本章時(shí)有很大幫助。

對(duì)于類似于Pastebin這樣的代碼或文本分享平臺(tái)，中國(guó)并未有一款特別知名或廣泛使用的網(wǎng)站。很多開(kāi)發(fā)者會(huì)使用GitHub Gist來(lái)分享代碼片段，此外，國(guó)內(nèi)也有一些代碼托管平臺(tái)，比如Coding.net和Gitee，也提供代碼分享和協(xié)作的功能。

2、系統(tǒng)的需求和目標(biāo)

Pastebin服務(wù)需要滿足以下要求：

功能需求：

1. 用戶應(yīng)能夠上傳或“粘貼”他們的數(shù)據(jù)，并獲得一個(gè)獨(dú)特的URL來(lái)訪問(wèn)它。
2. 用戶只能上傳文本。
3. 數(shù)據(jù)和鏈接將在特定的時(shí)間段后自動(dòng)過(guò)期；用戶應(yīng)可以指定過(guò)期時(shí)間。
4. 用戶可以選擇為他們的粘貼內(nèi)容設(shè)置一個(gè)自定義的別名。

非功能性需求：

1. 系統(tǒng)必須具有高度的可靠性，上傳的任何數(shù)據(jù)都不應(yīng)丟失。
2. 系統(tǒng)必須始終可用。這是因?yàn)槿绻覀兊姆?wù)暫停，用戶將無(wú)法訪問(wèn)他們的粘貼內(nèi)容。
3. 用戶應(yīng)能實(shí)時(shí)訪問(wèn)他們的粘貼內(nèi)容，延遲要最小。
4. 粘貼的鏈接不能被輕易猜出（不能被預(yù)測(cè)）。

擴(kuò)展需求：

1. 分析，例如，一個(gè)粘貼內(nèi)容被訪問(wèn)了多少次？
2. 我們的服務(wù)也應(yīng)該通過(guò)REST APIs供其他服務(wù)訪問(wèn)。

3、注意事項(xiàng)

Pastebin與URL縮短服務(wù)(系統(tǒng)設(shè)計(jì)上一個(gè)案例)有一些相同的需求，但是我們還應(yīng)該考慮一些額外的設(shè)計(jì)因素。

用戶每次粘貼的文本量應(yīng)有何限制？我們可以限制用戶不得粘貼超過(guò)10MB10MB10MB的數(shù)據(jù)，以防止服務(wù)被濫用。

我們是否應(yīng)對(duì)自定義URL的大小設(shè)置限制？由于我們的服務(wù)支持自定義URL，用戶可以選擇他們喜歡的任何URL，但是提供自定義URL并非強(qiáng)制性的。然而，對(duì)自定義URL設(shè)置大小限制是合理的（而且通常是我們期望的），這樣我們可以保持一致的URL數(shù)據(jù)庫(kù)。

4、容量估計(jì)與約束

我們的服務(wù)將是讀取密集型的；相比新建Paste，讀取請(qǐng)求會(huì)更多。我們可以假設(shè)讀取與寫(xiě)入之間的比例是5:1。

流量預(yù)估：Pastebin類似的服務(wù)并不預(yù)期有如微信或今日頭條那樣的流量，這里我們假設(shè)每天有一百萬(wàn)個(gè)新的粘貼內(nèi)容添加到我們的系統(tǒng)中。這樣算來(lái)，我們每天有五百萬(wàn)次的讀取。

每秒新粘貼內(nèi)容：

1M / (24 小時(shí) * 3600 秒) ~= 12 粘貼/秒

每秒粘貼讀取次數(shù)：

5M / (24 小時(shí) * 3600 秒) ~= 58 讀取/秒

存儲(chǔ)預(yù)估：用戶最多可以上傳10MB的數(shù)據(jù)；一般來(lái)說(shuō)，Pastebin類似的服務(wù)用于分享源代碼、配置文件或日志。這些文本并不大，所以我們假設(shè)每個(gè)粘貼內(nèi)容平均含有10KB10KB10KB。

按照這個(gè)速率，我們每天將存儲(chǔ)10GB的數(shù)據(jù)。

1M * 10KB => 10 GB/天

如果我們想將這些數(shù)據(jù)存儲(chǔ)十年，那我們總共需要36TB的存儲(chǔ)容量。

每天有1M的粘貼內(nèi)容，十年后我們將有36億的粘貼內(nèi)容。我們需要生成并存儲(chǔ)鍵來(lái)唯一地標(biāo)識(shí)這些粘貼內(nèi)容。如果我們使用Base64編碼（[A-Z, a-z, 0-9, ., -]），我們將需要六個(gè)字符的字符串：

64^6 ~= 68.7億個(gè)唯一字符串

如果存儲(chǔ)一個(gè)字符需要一個(gè)字節(jié)，存儲(chǔ)36億個(gè)鍵所需的總大小將是：

3.6B?6=>22GB

相比于36TB，22GB微不足道。為了保留一些余量，我們將假設(shè)一個(gè)70%的容量模型（意味著我們?cè)谌魏螘r(shí)候都不希望使用超過(guò)總存儲(chǔ)容量的70%），這將使我們的存儲(chǔ)需求增加到 51.4TB。

帶寬預(yù)估：對(duì)于寫(xiě)入請(qǐng)求，我們預(yù)計(jì)每秒新增12個(gè)粘貼內(nèi)容，導(dǎo)致每秒進(jìn)入120KB的數(shù)據(jù)。

12?10KB=>120KB/s

至于讀取請(qǐng)求，我們預(yù)計(jì)每秒58個(gè)請(qǐng)求。因此，總的數(shù)據(jù)出口（發(fā)送給用戶）將是0.6MB/s。

58?10KB=>0.6MB/s

盡管總的進(jìn)出口并不大，我們?cè)谠O(shè)計(jì)服務(wù)時(shí)應(yīng)記住這些數(shù)字。

內(nèi)存預(yù)估：我們可以緩存一些被頻繁訪問(wèn)的熱門(mén)粘貼內(nèi)容。根據(jù)80-20原則，意味著20%的熱門(mén)粘貼內(nèi)容產(chǎn)生了80%的流量，我們希望將這20%的粘貼內(nèi)容進(jìn)行緩存。

既然我們每天有500萬(wàn)次的讀取請(qǐng)求，要緩存這些請(qǐng)求中的20%，我們需要：

0.2?5M?10KB =10GB

因此，我們大約需要10GB的內(nèi)存來(lái)緩存那些熱門(mén)的粘貼內(nèi)容。

5、系統(tǒng)API

我們可以有SOAP或REST API來(lái)公開(kāi)我們服務(wù)的功能。以下是創(chuàng)建/檢索/刪除粘貼內(nèi)容的API定義：

addPaste(api_dev_key, paste_data, custom_url=None user_name=None, paste_name=None, expire_date=None)

參數(shù)：

api_dev_key (字符串): 已注冊(cè)帳戶的API開(kāi)發(fā)者密鑰。這將用于基于分配的配額對(duì)用戶進(jìn)行限流等操作。

paste_data (字符串): 粘貼的文本數(shù)據(jù)。

custom_url (字符串): 可選的自定義URL。

user_name (字符串): 可選的用于生成URL的用戶名。

paste_name (字符串): 粘貼內(nèi)容的可選名稱。

expire_date (字符串): 粘貼內(nèi)容的可選過(guò)期日期。

返回： (字符串)

成功插入返回可以訪問(wèn)粘貼內(nèi)容的URL，否則，它將返回一個(gè)錯(cuò)誤碼。

類似地，我們可以有檢索和刪除粘貼內(nèi)容的API：

getPaste(api_dev_key, api_paste_key)

其中api_paste_key是一個(gè)表示要檢索的粘貼內(nèi)容的粘貼鍵的字符串。這個(gè)API將返回粘貼內(nèi)容的文本數(shù)據(jù)。

deletePaste(api_dev_key, api_paste_key)

成功刪除返回true，否則返回false。

6、數(shù)據(jù)庫(kù)設(shè)計(jì)

關(guān)于我們存儲(chǔ)的數(shù)據(jù)性質(zhì)，我們有一些觀察：

1. 我們需要存儲(chǔ)數(shù)十億條記錄。
2. 我們存儲(chǔ)的每個(gè)元數(shù)據(jù)對(duì)象都很小（小于1KB）。
3. 我們存儲(chǔ)的每個(gè)粘貼對(duì)象大小適中（可以達(dá)到幾MB）。
4. 記錄之間沒(méi)有關(guān)系，除非我們要存儲(chǔ)哪個(gè)用戶創(chuàng)建了哪個(gè)粘貼內(nèi)容。
5. 我們的服務(wù)主要是讀取操作。

數(shù)據(jù)庫(kù)架構(gòu)：

我們需要兩個(gè)表，一個(gè)用于存儲(chǔ)粘貼內(nèi)容的信息，另一個(gè)用于存儲(chǔ)用戶的數(shù)據(jù)。

這里，URlHash是TinyURL的URL等效項(xiàng)，ContentKey是指向一個(gè)外部對(duì)象的引用，該對(duì)象存儲(chǔ)粘貼內(nèi)容的內(nèi)容；我們將在本章后面討論粘貼內(nèi)容的外部存儲(chǔ)。

7、頂層設(shè)計(jì)

在頂層設(shè)計(jì)上，我們需要一個(gè)應(yīng)用層來(lái)處理所有的讀取和寫(xiě)入請(qǐng)求。應(yīng)用層將與存儲(chǔ)層進(jìn)行通信，以存儲(chǔ)和檢索數(shù)據(jù)。我們可以將存儲(chǔ)層劃分為兩部分，一部分?jǐn)?shù)據(jù)庫(kù)存儲(chǔ)與每個(gè)粘貼內(nèi)容、用戶等相關(guān)的元數(shù)據(jù)，另一部分將粘貼內(nèi)容存儲(chǔ)在某些對(duì)象存儲(chǔ)中（如阿里云OSS）。這種數(shù)據(jù)的劃分也允許我們單獨(dú)進(jìn)行擴(kuò)展。

8、組件設(shè)計(jì)

A. 應(yīng)用層

我們的應(yīng)用層將處理所有的進(jìn)出請(qǐng)求。應(yīng)用服務(wù)器將與后端數(shù)據(jù)存儲(chǔ)組件進(jìn)行通信以服務(wù)這些請(qǐng)求。

如何處理寫(xiě)入請(qǐng)求？在收到寫(xiě)入請(qǐng)求后，我們的應(yīng)用服務(wù)器將生成一個(gè)六位隨機(jī)字符串，這將作為粘貼的鍵（如果用戶沒(méi)有提供自定義鍵）。然后，應(yīng)用服務(wù)器將粘貼的內(nèi)容和生成的鍵存儲(chǔ)在數(shù)據(jù)庫(kù)中。成功插入后，服務(wù)器可以將鍵返回給用戶。這里可能存在的一個(gè)問(wèn)題是由于鍵重復(fù)而導(dǎo)致插入失敗。由于我們是生成一個(gè)隨機(jī)鍵，所以新生成的鍵可能與現(xiàn)有的鍵相匹配。在這種情況下，我們應(yīng)該重新生成一個(gè)新的鍵并再試一次。我們應(yīng)該一直重試，直到我們不再因?yàn)橹貜?fù)鍵看到失敗。如果用戶提供的自定義鍵已經(jīng)在我們的數(shù)據(jù)庫(kù)中存在，我們應(yīng)該向用戶返回一個(gè)錯(cuò)誤。

上述問(wèn)題的另一種解決方案可能是運(yùn)行一個(gè)獨(dú)立的鍵生成服務(wù)（KGS），它提前生成隨機(jī)的六位字符串，并將它們存儲(chǔ)在數(shù)據(jù)庫(kù)中（我們稱之為key-DB）。每當(dāng)我們想要存儲(chǔ)一個(gè)新的粘貼，我們只需要取一個(gè)已經(jīng)生成的鍵并使用它。這種方法將使事情變得非常簡(jiǎn)單和快速，因?yàn)槲覀儾粫?huì)擔(dān)心重復(fù)或碰撞。KGS將確保所有插入key-DB的鍵都是唯一的。

KGS可以使用兩個(gè)表來(lái)存儲(chǔ)鍵，一個(gè)用于尚未使用的鍵，一個(gè)用于所有已使用的鍵。一旦KGS向應(yīng)用服務(wù)器提供了一些鍵，它可以將這些移動(dòng)到已使用的鍵表中。KGS可以始終在內(nèi)存中保持一些鍵，以便每當(dāng)服務(wù)器需要它們時(shí)，它可以快速提供。一旦KGS在內(nèi)存中加載了一些鍵，它就可以將它們移動(dòng)到已使用的鍵表中；這樣我們就可以確保每個(gè)服務(wù)器獲取到的鍵都是唯一的。如果KGS在使用所有加載到內(nèi)存中的鍵之前死掉，我們將浪費(fèi)這些鍵。我們可以忽略這些鍵，因?yàn)槲覀冇写罅康逆I。

KGS會(huì)出現(xiàn)單點(diǎn)故障嗎？會(huì)的。為了解決這個(gè)問(wèn)題，我們可以有一個(gè)備用的KGS副本，每當(dāng)主服務(wù)器死掉時(shí)，它可以接管來(lái)生成和提供鍵。

每個(gè)應(yīng)用服務(wù)器可以從key-DB中緩存一些鍵嗎？是的，這肯定可以加快速度。雖然在這種情況下，如果應(yīng)用服務(wù)器在消費(fèi)所有鍵之前死掉，我們將最終丟失那些鍵。這可能是可以接受的，因?yàn)槲覀冇?8B個(gè)唯一的六位字母鍵，這比我們需要的要多得多。

如何處理粘貼讀取請(qǐng)求？在收到讀取粘貼請(qǐng)求后，應(yīng)用服務(wù)層聯(lián)系數(shù)據(jù)存儲(chǔ)。數(shù)據(jù)存儲(chǔ)搜索鍵，如果找到了，就返回粘貼的內(nèi)容。否則，返回一個(gè)錯(cuò)誤碼。

B. 數(shù)據(jù)存儲(chǔ)層

我們可以將我們的數(shù)據(jù)存儲(chǔ)層分為兩部分：

1. 元數(shù)據(jù)數(shù)據(jù)庫(kù)：我們可以使用像MySQL這樣的關(guān)系數(shù)據(jù)庫(kù)，或者像Dynamo或Cassandra這樣的分布式Key-Value存儲(chǔ)。
2. 對(duì)象存儲(chǔ)：我們可以將我們的內(nèi)容存儲(chǔ)在像阿里云OSS這樣的對(duì)象存儲(chǔ)中。每當(dāng)我們感覺(jué)到我們的內(nèi)容存儲(chǔ)容量已經(jīng)滿了，我們可以通過(guò)平臺(tái)直接擴(kuò)容。

9、數(shù)據(jù)分區(qū)和復(fù)制

為了擴(kuò)展我們的數(shù)據(jù)庫(kù)，我們需要對(duì)其進(jìn)行分區(qū)，以便它能存儲(chǔ)數(shù)十億個(gè)URL的信息。因此，我們需要設(shè)計(jì)一個(gè)分區(qū)方案，將我們的數(shù)據(jù)劃分并存儲(chǔ)到不同的數(shù)據(jù)庫(kù)中。

A. 基于范圍的分區(qū)：我們可以根據(jù)哈希鍵的第一個(gè)字母在不同的分區(qū)中存儲(chǔ)URL。因此，我們將所有以字母“A”（和“a”）開(kāi)頭的URL哈希鍵存儲(chǔ)在一個(gè)分區(qū)中，將以字母“B”開(kāi)頭的URL存儲(chǔ)在另一個(gè)分區(qū)中，以此類推。這種方法被稱為基于范圍的分區(qū)。我們甚至可以將某些出現(xiàn)頻率較低的字母組合到一個(gè)數(shù)據(jù)庫(kù)分區(qū)中。因此，我們應(yīng)開(kāi)發(fā)一個(gè)靜態(tài)分區(qū)方案，始終以可預(yù)測(cè)的方式存儲(chǔ)/查找URL。

這種方法的主要問(wèn)題是可能導(dǎo)致數(shù)據(jù)庫(kù)服務(wù)器不平衡。例如，我們決定將所有以字母“E”開(kāi)頭的URL放入一個(gè)數(shù)據(jù)庫(kù)分區(qū)，但后來(lái)我們發(fā)現(xiàn)以字母“E”開(kāi)頭的URL過(guò)多。

B. 基于哈希的分區(qū)：在這種方案中，我們對(duì)存儲(chǔ)的對(duì)象進(jìn)行哈希。然后，我們根據(jù)哈希值計(jì)算使用哪個(gè)分區(qū)。在我們的情況下，我們可以獲取key或短鏈接的哈希值，以確定我們存儲(chǔ)數(shù)據(jù)對(duì)象的分區(qū)。

我們的哈希函數(shù)將隨機(jī)地將URL分配到不同的分區(qū)（例如，我們的哈希函數(shù)可以始終將任何key映射到[1...256]之間的一個(gè)數(shù)字）。這個(gè)數(shù)字將表示我們存儲(chǔ)對(duì)象的分區(qū)。

這種方法仍然可能導(dǎo)致分區(qū)負(fù)載過(guò)大，這可以通過(guò)使用'一致性哈希'來(lái)解決。

10、緩存

我們可以緩存頻繁訪問(wèn)的URL。我們可以使用任何現(xiàn)成的解決方案，比如Memcached，它可以存儲(chǔ)完整的URL及其對(duì)應(yīng)的哈希值。因此，應(yīng)用服務(wù)器在訪問(wèn)后端存儲(chǔ)之前，可以快速檢查緩存是否有所需的URL。

我們應(yīng)該有多少緩存內(nèi)存？我們可以從日流量的20%開(kāi)始，根據(jù)客戶的使用模式，我們可以調(diào)整需要多少緩存服務(wù)器。如上所估計(jì)，我們需要170GB的內(nèi)存來(lái)緩存日流量的20%。目前的一些服務(wù)器可以擁有256GB的內(nèi)存，我們可以輕松將所有緩存放入一臺(tái)機(jī)器。或者，我們可以使用幾臺(tái)小一點(diǎn)的服務(wù)器來(lái)存儲(chǔ)所有這些熱門(mén)URL。

哪種緩存驅(qū)逐策略最適合我們的需求？當(dāng)緩存滿了，我們想用一個(gè)新的/更熱門(mén)的URL替換一個(gè)鏈接，我們應(yīng)該如何選擇？最近最少使用（LRU）可能是我們系統(tǒng)的一個(gè)合理策略。根據(jù)這個(gè)策略，我們首先丟棄最近最少使用的URL。我們可以使用Linked Hash Map或類似的數(shù)據(jù)結(jié)構(gòu)來(lái)存儲(chǔ)我們的URL和哈希值，這也會(huì)記錄最近訪問(wèn)過(guò)的URL。

為了進(jìn)一步提高效率，我們可以復(fù)制我們的緩存服務(wù)器來(lái)分配它們之間的負(fù)載。

每個(gè)緩存副本如何更新？每當(dāng)有一個(gè)緩存未命中，我們的服務(wù)器會(huì)訪問(wèn)后端數(shù)據(jù)庫(kù)。當(dāng)這種情況發(fā)生，我們可以更新緩存，并將新的條目傳遞給所有的緩存副本。每個(gè)副本都可以通過(guò)添加新的條目來(lái)更新其緩存。如果副本已經(jīng)有了該條目，它可以簡(jiǎn)單地忽略它。

11、負(fù)載均衡（LB）

我們可以在系統(tǒng)中的三個(gè)位置添加負(fù)載均衡層：

• 客戶端與應(yīng)用服務(wù)器之間
• 應(yīng)用服務(wù)器與數(shù)據(jù)庫(kù)服務(wù)器之間
• 應(yīng)用服務(wù)器與緩存服務(wù)器之間

最初，我們可以使用一個(gè)簡(jiǎn)單的輪詢方法，將進(jìn)入的請(qǐng)求均等地分配到后端服務(wù)器。這種負(fù)載均衡方法簡(jiǎn)單易行，不會(huì)引入任何額外的開(kāi)銷。這種方法的另一個(gè)優(yōu)點(diǎn)是，如果一個(gè)服務(wù)器死機(jī)，負(fù)載均衡器會(huì)將其從輪詢中移除，停止向其發(fā)送任何流量。

輪詢負(fù)載均衡的一個(gè)問(wèn)題是，我們沒(méi)有考慮到服務(wù)器的負(fù)載。如果一個(gè)服務(wù)器過(guò)載或運(yùn)行緩慢，負(fù)載均衡器不會(huì)停止向該服務(wù)器發(fā)送新的請(qǐng)求。為了處理這個(gè)問(wèn)題，我們可以放置一個(gè)更優(yōu)的負(fù)載均衡解決方案，它定期查詢后端服務(wù)器的負(fù)載，并根據(jù)負(fù)載情況調(diào)整流量。

12、清除或數(shù)據(jù)庫(kù)清理

key條目是否應(yīng)永久存在，還是應(yīng)該被清除？如果達(dá)到用戶設(shè)定的過(guò)期時(shí)間，鏈接應(yīng)該怎么處理？

如果我們選擇持續(xù)尋找過(guò)期鏈接并將其刪除，這將對(duì)我們的數(shù)據(jù)庫(kù)產(chǎn)生很大壓力。相反，我們可以慢慢地刪除過(guò)期的鏈接，進(jìn)行懶人清理。我們的服務(wù)將確保只刪除過(guò)期的鏈接，盡管有些過(guò)期鏈接可能會(huì)存在更長(zhǎng)時(shí)間，但永遠(yuǎn)不會(huì)被返回給用戶。

• 每當(dāng)用戶試圖訪問(wèn)一個(gè)已過(guò)期的鏈接，我們可以刪除該鏈接并向用戶返回錯(cuò)誤。
• 我們可以設(shè)置一個(gè)單獨(dú)的清理服務(wù)，定期從我們的存儲(chǔ)和緩存中刪除過(guò)期的鏈接。這個(gè)服務(wù)需要非常輕量，只在預(yù)計(jì)用戶流量較低的時(shí)候運(yùn)行。
• 我們可以為每個(gè)鏈接設(shè)定一個(gè)默認(rèn)的過(guò)期時(shí)間（例如兩年）。
• 刪除過(guò)期鏈接后，我們可以將該Key重新放回Key-DB，以供重復(fù)使用。
• 我們是否應(yīng)刪除一段時(shí)間（比如說(shuō)六個(gè)月）內(nèi)沒(méi)有被訪問(wèn)過(guò)的鏈接？這可能有點(diǎn)不合適。由于存儲(chǔ)成本越來(lái)越低，我們可以決定永久保存鏈接。

13、數(shù)據(jù)跟蹤

我們?nèi)绾谓y(tǒng)計(jì)短鏈接被使用的次數(shù)、用戶的位置等信息？我們?nèi)绾蝺?chǔ)存這些統(tǒng)計(jì)信息？如果它是數(shù)據(jù)庫(kù)中的一部分，每次查看都需要更新，那么當(dāng)一個(gè)流行的短鏈接被大量并發(fā)請(qǐng)求瞬間涌入時(shí)，會(huì)發(fā)生什么？

一些值得追蹤的統(tǒng)計(jì)數(shù)據(jù)：訪客的國(guó)家、訪問(wèn)的日期和時(shí)間、引導(dǎo)點(diǎn)擊的網(wǎng)頁(yè)、訪問(wèn)頁(yè)面的瀏覽器或平臺(tái)。

14、安全和權(quán)限

用戶能否創(chuàng)建私有URL或者允許特定的用戶組訪問(wèn)某個(gè)URL？

我們可以在數(shù)據(jù)庫(kù)中每個(gè)URL的條目里存儲(chǔ)訪問(wèn)權(quán)限級(jí)別（公開(kāi)/私有）。我們也可以創(chuàng)建一個(gè)單獨(dú)的表來(lái)存儲(chǔ)有權(quán)訪問(wèn)特定URL的用戶的UserID。如果一個(gè)用戶沒(méi)有權(quán)限但試圖訪問(wèn)一個(gè)URL，我們可以返回一個(gè)錯(cuò)誤（HTTP 401）。考慮到我們的數(shù)據(jù)儲(chǔ)存在一個(gè)類似Cassandra的NoSQL寬列數(shù)據(jù)庫(kù)中，儲(chǔ)存權(quán)限的表的key將是‘哈希值’（或KGS生成的key）。列將儲(chǔ)存有權(quán)查看URL的用戶的UserID。