長鏈接問題:
復制容易出錯，長鏈接URL較長，有時參數不止壹個，粘貼時復制容易被編輯省略或截斷；
很容易被屏蔽。大部分長鏈接暴露了資源來源和分配策略，放入第三方容易被屏蔽，比如被短信屏蔽，被微信屏蔽。
反例:
所以我們考慮短鏈接服務壓縮長鏈接，改為跳轉！
1.用戶訪問短鏈接:/Dao Gou/20200914/64294 . html
3.服務器返回狀態碼301/302，並將響應頭中的位置設置為原始鏈接；
4.瀏覽器重定向到原始鏈接；
5.返回響應；
短鏈接生成:
1.庫表設計:id、代碼(短鏈代碼)和url(原鏈接)以鍵值模式存儲。
2、短鏈碼
1)，存儲方式:62，每位可選？A-Z，a-z和0-9？62個字符等。，比通常的數字存儲要大。註意:
四位可以代表62 ^ 4 = 1477，6336約15萬條數據；
5位可以代表62 ^ 5 =？916132832約9億條數據；
六位可以代表62 ^ 6 = 568，00235584約560億條數據；
示例:
通過短鏈碼的長度，可以判斷各個平臺服務板塊的歷史業務量，如上圖:
菜鳥驛站和拼多多壹樣，采用8位短鏈碼，62 ^ 8 = 218，3401，05584896，業務量積累到幾萬億級別。
另外值得註意的是，點擊拼多多的鏈接直接打開APP(具體技術方案參考:如何從短信鏈接的推廣中喚起App)，比大多數應用的推廣要好。
2)生成方法:可以通過ID自增序列(自增後從10到62二進制轉換)和哈希算法生成。供參考，如果教妳設計壹個短鏈接系統，妳會從哪些方面提升性能？
重定向性能註意事項:
1，301，302跳差:
1)、301跳轉，永久重定向，默認由瀏覽器緩存，只要訪問壹次短鏈，就直接跳轉到原鏈地址，不經過服務器；
2)、302跳轉，臨時重定向，不被瀏覽器緩存，每次都經過短鏈接服務器；
因此，為了在短鏈中實現更靈活的資源跳轉配置，使用302跳轉更為合適。缺點是:對搜索引擎不友好+性能問題(每次都需要短鏈服務)；考慮到SEO+訪問性能(瀏覽器緩存解決方案)，建議采用301跳轉模式。
2.通過Redis做壹個查詢表，將短鏈代碼映射到長鏈接Url；
3、阻止機器人腳本訪問，結合白名單等機制；
註:作為對外開放的短鏈服務，對設計要求較高，設計為獨立系統。
註:本章所有內容的寫作思路和方法:
1.手動生成指定資源的短鏈接並啟動它；
2.對於指定的資源，批量生成短鏈接，形成記錄進行交付；
3.在某些環節(如短信投放、微信分享)自動生成短鏈接(用戶無感)完成投放；
描述如何應用場景:
1，朋友圈消息:
2.微信/QQ群插件自動發鏈接。
微信，節省空間效果不錯:
常用QQ群自動回復插件:
3.短信營銷
優勢:
1，鏈接放置時，方便復制粘貼；
2.短網址使排版美觀簡潔，用戶關註文案；
3.防止屏蔽，比如短信屏蔽，微信屏蔽.....；
4、訪問資源有效性控制，添加密碼等。：
原則上妳可以在跳轉之前做任何後端想做的事情，比如訪問統計，比如後續訪問鏈接的切換，所以訪問資源的可控性比較強。
比如跳轉資源不穩定，如果今天是A，明天是B，可以通過修改原鏈接來切換跳轉資源。
相關技術的擴展介紹
1和301對重定向的影響:/p/457.html
2.如果推出，必然涉及資源、渠道、效果的管理:
資源管理，比如文章；
渠道管理，如:微信渠道(公眾號、朋友圈、運營商私聊)、QQ、微博、短信、頭條。.....
投放效果統計，文章效果統計(每篇文章的效果是什麽？)，對於渠道統計的效果(每個渠道的效果如何？)，針對文章&；渠道效果統計(即不同文章在不同渠道的效果如何？)
3，壹切都是為了營收！如何喚起App推廣短信鏈接？
4.如果教妳設計壹個短鏈接系統，妳會從哪些方面提升性能？