短鏈接服務(wù)搭建

關(guān)鍵詞：長鏈接；短鏈接；重定向；

創(chuàng)新互聯(lián)專注于淮濱網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠為您提供淮濱營銷型網(wǎng)站建設(shè)，淮濱網(wǎng)站制作、淮濱網(wǎng)頁設(shè)計(jì)、淮濱網(wǎng)站官網(wǎng)定制、小程序制作服務(wù)，打造淮濱網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供淮濱網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。

長鏈接問題：

復(fù)制容易出錯(cuò)，長鏈接URL較長，有時(shí)參數(shù)不止一個(gè)，復(fù)制容易遺漏或在粘貼時(shí)被編輯器截?cái)啵?/p>

容易被屏蔽，絕大部分長鏈接暴露了資源來源及分配策略，在投放第三方時(shí)容易被屏蔽，比如被短信屏蔽，（淘寶寶貝長鏈接）被微信屏蔽......；

反例：

因此，我們考慮短鏈接服務(wù)對長鏈接進(jìn)行壓縮，跳轉(zhuǎn)替代！

1、用戶訪問短鏈接： ；

2、短鏈接服務(wù)器0x9.me收到請求，根據(jù)路徑參數(shù)QvjlI獲取到原始鏈接：

3、服務(wù)器返回301/302狀態(tài)碼，將響應(yīng)頭中的Location設(shè)置為 原始鏈接；

4、瀏覽器重定向到原始鏈接；

5、返回響應(yīng)；

短鏈接生成：

1、庫表設(shè)計(jì)：id、code（短鏈碼）、url（原鏈接），采用Key-Value方式對應(yīng)存儲(chǔ)

2、短鏈碼

1）、存儲(chǔ)方式：62進(jìn)制，每位 可選?a-z、A-Z 和 0-9? 等62個(gè)字符，比通常的數(shù)字方式存儲(chǔ)量大。注：

4位就可以表征 62^4 = 1477,6336 約 1500萬條數(shù)據(jù)；

5位可以表征 62^5 =?9,16132832 約 9億條數(shù)據(jù)；

6位可以表征 62^6 = 568,00235584 約 560億條數(shù)據(jù)；

例子：

通過短鏈碼的長度，可以判斷得出各平臺服務(wù)板塊的歷史業(yè)務(wù)量，如上：

【菜鳥驛站】同【拼多多】，采用了8位短鏈碼，62^8 = 218,3401,05584896，業(yè)務(wù)量都累積到了多少萬億級別。

另，值得關(guān)注，點(diǎn)擊拼多多的鏈接直接打開APP（具體技術(shù)方案參考： 如何從推廣短信鏈接喚起 App ），優(yōu)于絕大部分應(yīng)用的推廣。

2）、生成方式：可以按ID自增序列（自增后10到62進(jìn)制轉(zhuǎn)換）、哈希算法方式生成，可參考： 如果教你設(shè)計(jì)一個(gè) 短 鏈接 系統(tǒng)，你會(huì)從那些方面來提高性能呢？

重定向性能考慮：

1、301、302跳轉(zhuǎn)區(qū)別：

1）、301跳轉(zhuǎn)，永久重定向，默認(rèn)被瀏覽器緩存，只要訪問過一次短鏈，后續(xù)都會(huì)直接跳轉(zhuǎn)原鏈地址，不經(jīng)過服務(wù)器；

2）、302跳轉(zhuǎn)，臨時(shí)重定向，不被瀏覽器緩存，每次都經(jīng)過短鏈接服務(wù)器；

所以，要想實(shí)現(xiàn)短鏈更靈活的資源跳轉(zhuǎn)配置，采用302跳轉(zhuǎn)就比較合適，缺點(diǎn)是：對搜索引擎不友好+性能問題（每次都要過短鏈服務(wù)）；考慮到SEO+訪問性能（瀏覽器緩存解決），建議采用301跳轉(zhuǎn)方式。

2、通過Redis做查詢表，短鏈Code 映射長鏈接Url；

3、防機(jī)器人腳本訪問，結(jié)合白名單等機(jī)制；

注：作為對外開放的短鏈服務(wù)對設(shè)計(jì)要求更高，完全作為一個(gè)獨(dú)立系統(tǒng)進(jìn)行設(shè)計(jì)。

注：本當(dāng)章節(jié)下所有內(nèi)容的撰寫思路與方式：

1、針對指定資源手動(dòng)生成短鏈接，進(jìn)行投放；

2、針對指定資源，批量生成短鏈接，并形成記錄，以便進(jìn)行投放；

3、在一些環(huán)節(jié)（如：短信投放、微信分享時(shí)），自動(dòng)生成短鏈接（用戶無感）完成投放；

介紹如何應(yīng)用場景：

1、朋友圈消息：

2、微信/QQ群插件自動(dòng)發(fā)送鏈接

微信，空間節(jié)約效果良好：

常用的QQ群自動(dòng)回復(fù)插件：

3、短信營銷

優(yōu)點(diǎn)：

1、在鏈接投放時(shí)，方便復(fù)制粘貼；

2、短網(wǎng)址使排版變的美觀，簡潔，用戶關(guān)注的重點(diǎn)在文案上面；

3、防止屏蔽，如短信屏蔽、微信屏蔽....;

4、訪問資源有效期控制，添加密碼等：

原則上可以在跳轉(zhuǎn)之前做任何后端想做的事情，比如訪問統(tǒng)計(jì)，比如后續(xù)訪問鏈接的切換，所以對訪問資源的可控性就比較強(qiáng)，

舉例：跳轉(zhuǎn)資源不穩(wěn)定，今天是A，明天是B，就可以通過修改原鏈接實(shí)現(xiàn)跳轉(zhuǎn)資源的切換。

關(guān)聯(lián)技術(shù)的延展介紹

1、301對重定向的影響：

2、有投放就必然涉及到投放資源、渠道、及效果的管理：

資源管理，比如說文章；

渠道管理，比如：微信渠道（公號、朋友圈、運(yùn)營人員個(gè)人私聊）、QQ、微博、短信、頭條.....

投放效果統(tǒng)計(jì)，針對文章的效果統(tǒng)計(jì)（各文章的效果如何？），針對渠道的效果統(tǒng)計(jì)（各渠道的效果如何？），針對文章渠道的效果統(tǒng)計(jì)（即不同文章在不同渠道的效果如何？）

3、 一切為了營收！如何從推廣短信鏈接喚起 App ？

4、 如果教你設(shè)計(jì)一個(gè) 短 鏈接 系統(tǒng)，你會(huì)從那些方面來提高性能呢？

nosql是什么

NoSQL，泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重?cái)?shù)據(jù)種類帶來的挑戰(zhàn)，尤其是大數(shù)據(jù)應(yīng)用難題。

雖然NoSQL流行語火起來才短短一年的時(shí)間，但是不可否認(rèn)，現(xiàn)在已經(jīng)開始了第二代運(yùn)動(dòng)。盡管早期的堆棧代碼只能算是一種實(shí)驗(yàn)，然而現(xiàn)在的系統(tǒng)已經(jīng)更加的成熟、穩(wěn)定。不過現(xiàn)在也面臨著一個(gè)嚴(yán)酷的事實(shí)：技術(shù)越來越成熟——以至于原來很好的NoSQL數(shù)據(jù)存儲(chǔ)不得不進(jìn)行重寫，也有少數(shù)人認(rèn)為這就是所謂的2.0版本。這里列出一些比較知名的工具，可以為大數(shù)據(jù)建立快速、可擴(kuò)展的存儲(chǔ)庫。

NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，是一項(xiàng)全新的數(shù)據(jù)庫革命性運(yùn)動(dòng)，早期就有人提出，發(fā)展至2009年趨勢越發(fā)高漲。NoSQL的擁護(hù)者們提倡運(yùn)用非關(guān)系型的數(shù)據(jù)存儲(chǔ)，相對于鋪天蓋地的關(guān)系型數(shù)據(jù)庫運(yùn)用，這一概念無疑是一種全新的思維的注入。

對于NoSQL并沒有一個(gè)明確的范圍和定義，但是他們都普遍存在下面一些共同特征：

不需要預(yù)定義模式：不需要事先定義數(shù)據(jù)模式，預(yù)定義表結(jié)構(gòu)。數(shù)據(jù)中的每條記錄都可能有不同的屬性和格式。當(dāng)插入數(shù)據(jù)時(shí)，并不需要預(yù)先定義它們的模式。

無共享架構(gòu)：相對于將所有數(shù)據(jù)存儲(chǔ)的存儲(chǔ)區(qū)域網(wǎng)絡(luò)中的全共享架構(gòu)。NoSQL往往將數(shù)據(jù)劃分后存儲(chǔ)在各個(gè)本地服務(wù)器上。因?yàn)閺谋镜卮疟P讀取數(shù)據(jù)的性能往往好于通過網(wǎng)絡(luò)傳輸讀取數(shù)據(jù)的性能，從而提高了系統(tǒng)的性能。

彈性可擴(kuò)展：可以在系統(tǒng)運(yùn)行的時(shí)候，動(dòng)態(tài)增加或者刪除結(jié)點(diǎn)。不需要停機(jī)維護(hù)，數(shù)據(jù)可以自動(dòng)遷移。

分區(qū)：相對于將數(shù)據(jù)存放于同一個(gè)節(jié)點(diǎn)，NoSQL數(shù)據(jù)庫需要將數(shù)據(jù)進(jìn)行分區(qū)，將記錄分散在多個(gè)節(jié)點(diǎn)上面。并且通常分區(qū)的同時(shí)還要做復(fù)制。這樣既提高了并行性能，又能保證沒有單點(diǎn)失效的問題。

異步復(fù)制：和RAID存儲(chǔ)系統(tǒng)不同的是，NoSQL中的復(fù)制，往往是基于日志的異步復(fù)制。這樣，數(shù)據(jù)就可以盡快地寫入一個(gè)節(jié)點(diǎn)，而不會(huì)被網(wǎng)絡(luò)傳輸引起遲延。缺點(diǎn)是并不總是能保證一致性，這樣的方式在出現(xiàn)故障的時(shí)候，可能會(huì)丟失少量的數(shù)據(jù)。

BASE：相對于事務(wù)嚴(yán)格的ACID特性，NoSQL數(shù)據(jù)庫保證的是BASE特性。BASE是最終一致性和軟事務(wù)。

NoSQL數(shù)據(jù)庫并沒有一個(gè)統(tǒng)一的架構(gòu)，兩種NoSQL數(shù)據(jù)庫之間的不同，甚至遠(yuǎn)遠(yuǎn)超過兩種關(guān)系型數(shù)據(jù)庫的不同。可以說，NoSQL各有所長，成功的NoSQL必然特別適用于某些場合或者某些應(yīng)用，在這些場合中會(huì)遠(yuǎn)遠(yuǎn)勝過關(guān)系型數(shù)據(jù)庫和其他的NoSQL。

系統(tǒng)方案 - 設(shè)計(jì)一個(gè) URL 短鏈服務(wù)

短鏈接，通俗來說，就是將長的URL網(wǎng)址，通過程序計(jì)算等方式，轉(zhuǎn)換為簡短的網(wǎng)址字符串。

微博和Twitter都有140字?jǐn)?shù)的限制，如果分享一個(gè)長網(wǎng)址，很容易就超出限制。

營銷短信，字?jǐn)?shù)的限制,當(dāng)字?jǐn)?shù)過長: 1.不美觀 2.超出字符額外收費(fèi)。

生成二維碼的原始鏈接,當(dāng)原始鏈接過長時(shí),生成的二維碼過于復(fù)雜,導(dǎo)致一些像素較低的手機(jī)無法掃描.

功能要求：

非功能性要求：

擴(kuò)展要求：

可以使用 REST API 來公開我們服務(wù)的功能。以下可能是用于創(chuàng)建和刪除 URL 的 API 的定義：

createURL (api_dev_key, original_url, custom_alias=None, user_name=None, expire_date=None)

參數(shù)：

api_dev_key(string)：注冊賬號的API開發(fā)者密鑰。除其他外，這將用于根據(jù)分配的配額限制用戶。

original_url（字符串）：要縮短的原始 URL。

custom_alias（字符串）：URL 的可選自定義鍵。

user_name（字符串）：在編碼中使用的可選用戶名。

expire_date (string): 縮短 URL 的可選過期日期。

返回 ：（字符串）

成功插入會(huì)返回縮短的 URL；否則，它會(huì)返回錯(cuò)誤代碼。

deleteURL (api_dev_key, url_key)

其中“url_key”是一個(gè)字符串，表示要檢索的縮短的 URL；成功刪除會(huì)返回“已刪除 URL”。

如何發(fā)現(xiàn)和防止濫用？惡意用戶可以通過使用當(dāng)前設(shè)計(jì)中的所有 URL 密鑰使我們破產(chǎn)。為了防止濫用，我們可以通過他們的 api_dev_key 限制用戶。每個(gè) api_dev_key 可以限制為每個(gè)時(shí)間段內(nèi)特定數(shù)量的 URL 創(chuàng)建和重定向（每個(gè)開發(fā)者密鑰可以設(shè)置為不同的持續(xù)時(shí)間）。

結(jié)合儲(chǔ)存數(shù)據(jù)設(shè)計(jì)：

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

我們需要兩張表：一張用于存儲(chǔ)有關(guān) URL 映射的信息，另一張用于創(chuàng)建短鏈接的用戶數(shù)據(jù)。

應(yīng)該使用什么樣的數(shù)據(jù)庫？由于我們預(yù)計(jì)存儲(chǔ)數(shù)十億行，并且我們不需要使用對象之間的關(guān)系——NoSQL 選擇更容易擴(kuò)展

在第 1 節(jié)的示例中，縮短的 URL 是“”。這個(gè) URL 的最后八個(gè)字符構(gòu)成了我們要生成的短鏈。討論以下兩種解決方案： 摘要算法、自增序列算法

方案一：摘要算法

這種算法,雖然會(huì)生成4個(gè),但是仍然存在重復(fù)幾率

方案二： 自增序列算法

設(shè)置 id 自增，一個(gè) 10進(jìn)制 id 對應(yīng)一個(gè) 62進(jìn)制的數(shù)值，1對1，也就不會(huì)出現(xiàn)重復(fù)的情況。這個(gè)利用的就是低進(jìn)制轉(zhuǎn)化為高進(jìn)制時(shí)，字符數(shù)會(huì)減少的特性。

第一種算法的好處就是簡單好理解，永不重復(fù)。但是短碼的長度不固定，隨著 id 變大從一位長度開始遞增。如果非要讓短碼長度固定也可以就是讓 id 從指定的數(shù)字開始遞增就可以了。百度短網(wǎng)址用的這種算法。

為了擴(kuò)展我們的數(shù)據(jù)庫，我們需要對其進(jìn)行分區(qū)，以便它可以存儲(chǔ)有關(guān)數(shù)十億個(gè) URL 的信息。因此，我們需要開發(fā)一種分區(qū)方案，將我們的數(shù)據(jù)劃分并存儲(chǔ)到不同的數(shù)據(jù)庫服務(wù)器中。

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

這種方法的主要問題是它可能導(dǎo)致數(shù)據(jù)庫服務(wù)器不平衡。例如，我們決定將所有以字母“E”開頭的 URL 放入 DB 分區(qū)，但后來我們意識到我們有太多以字母“E”開頭的 URL。

另外基于散列的分區(qū)： 在這個(gè)方案中，我們獲取我們正在存儲(chǔ)的對象的散列。然后我們根據(jù)哈希計(jì)算要使用的分區(qū)。在我們的例子中，我們可以使用“鍵”或短鏈接的哈希值來確定我們存儲(chǔ)數(shù)據(jù)對象的分區(qū)。

我們的散列函數(shù)會(huì)將 URL 隨機(jī)分布到不同的分區(qū)中（例如，我們的散列函數(shù)總是可以將任何“鍵”映射到 [1…256] 之間的數(shù)字）。這個(gè)數(shù)字將代表我們存儲(chǔ)對象的分區(qū)。

這種方法仍然會(huì)導(dǎo)致分區(qū)過載，這可以使用一致哈希解決。

可以緩存經(jīng)常訪問的 URL，結(jié)合緩存中間件例如 Memcached、redis，它可以存儲(chǔ)完整的 URL 及其各自的哈希值。因此，應(yīng)用服務(wù)器在訪問后端存儲(chǔ)之前，可以快速檢查緩存是否具有所需的 URL。

我們應(yīng)該有多少緩存內(nèi)存？ 我們可以從每天 20% 的流量開始，根據(jù)客戶的使用模式，我們可以調(diào)整我們需要多少緩存服務(wù)器。如上所述，我們需要 170GB 的內(nèi)存來緩存 20% 的日常流量。由于現(xiàn)代服務(wù)器可以擁有 256GB 內(nèi)存，我們可以輕松地將所有緩存放入一臺機(jī)器中。或者，我們可以使用幾個(gè)較小的服務(wù)器來存儲(chǔ)所有這些熱門 URL。

哪種緩存驅(qū)逐策略最適合我們的需求？ 當(dāng)緩存已滿，并且我們想用更新/更熱的 URL 替換鏈接時(shí)，我們將如何選擇？最近最少使用 (LRU) 可能是我們系統(tǒng)的合理策略。根據(jù)此政策，會(huì)首先丟棄最近最少使用的 URL，可以使用 Linked Hash Map 或類似的數(shù)據(jù)結(jié)構(gòu)來存儲(chǔ)我們的 URL 和哈希，這也將跟蹤最近訪問過的 URL。

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

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

條目應(yīng)該永遠(yuǎn)存在，還是應(yīng)該被清除？如果達(dá)到用戶指定的過期時(shí)間，鏈接會(huì)發(fā)生什么？

如果我們選擇不斷搜索過期鏈接來刪除它們，這會(huì)給我們的數(shù)據(jù)庫帶來很大的壓力。相反，我們可以慢慢刪除過期鏈接并進(jìn)行惰性清理。我們的服務(wù)會(huì)確保只刪除過期的鏈接。

用戶能否創(chuàng)建私有 URL 或允許一組特定用戶訪問 URL？

可以將權(quán)限級別（公共/私有）與數(shù)據(jù)庫中的每個(gè) URL 一起存儲(chǔ)，還可以創(chuàng)建一個(gè)單獨(dú)的表來存儲(chǔ)有權(quán)查看特定 URL 的 UserID。如果用戶沒有權(quán)限并嘗試訪問 URL，可以發(fā)回錯(cuò)誤 (HTTP 401)。鑒于我們將數(shù)據(jù)存儲(chǔ)在像 Cassandra 這樣的 NoSQL 寬列數(shù)據(jù)庫中，表存儲(chǔ)權(quán)限的鍵將是“哈希”（或 KGS 生成的“鍵”）。這些列將存儲(chǔ)那些有權(quán)查看 URL 的用戶的用戶 ID。

當(dāng)前文章：短鏈接服務(wù)nosql,短鏈接服務(wù)是如何實(shí)現(xiàn)的
轉(zhuǎn)載來源：http://chinadenli.net/article28/dseppjp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供移動(dòng)網(wǎng)站建設(shè)、軟件開發(fā)、網(wǎng)站營銷、云服務(wù)器、手機(jī)網(wǎng)站建設(shè)、動(dòng)態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)