現在貌似tinyurl很火爆，也逐漸成為一種流行趨勢。
對應於php版本的tinyurl也有一些演算法，其實本質上來說是一種hash。
除此之外，還有另外一種tinyurl方案 ，類似於http://img.ly 。
其實這種設計 是最簡單的，沒有使用hash，而是遞增，這種的好 處就是資料庫 可以無限擴充套件，並且不會重複。
我們可以想想一下，我們只用大小寫字母來表示，如果三位的話，就可以儲存52*52*52=140608的url，如果是4位的話就成了 52*52*52*52=7311616，這個數量是幾何級增長，並且搜尋速度非常快。
ps：如果你覺得這不夠用的話，你還可以把數字加進去：）
我剛才測試了下，我新建了乙個表：
view source
print?
1.createtableifnotexists `url` (
2.`id`int(11)notnullauto_increment,
3.`tiny`char(10)charactersetutf8collateutf8_binnotnulldefault'',
4.`url` textnotnull,
5.primarykey(`id`),
6.uniquekey`tiny` (`tiny`)
7.) engine=myisamdefaultcharset=utf8 auto_increment=1;
注： 使用utf8_bin是為了區分大小寫。
然後我往表中新增了100w條資料 ，下面是我的演算法，非常簡單，還可以再優化：
view source
print?
01.functiongettinyurl($num)elseelse
13.}
14.returnstrrev($tiny);
15.}
16.}
從 1開始，每個數字就可以生成乙個唯一的識別符號，然後插入到資料庫中。
這時候我執行了一條sql 語句：
view source
print?
1.select*from`url`wheretiny ='dzpm'
許可權設計方案
簡要介紹一下該許可權管理系統的特點，該系統功能上做到了靈活授權，操控細緻，許可權可以細到按鈕及超鏈級別,而且部署簡單，下面談談我自己的設計經驗。該系統主要功能如下 1 自定義操作動作 如增加 刪除 修改 審核等，不再是以前見過的那種粗粒度的 按模組分配許可權，或者稍微先進點的規定死某幾個操作了 2 ...
快取設計方案
redis提供的快取的api，但是在開發階段，如果每個人都自己呼叫原生api實現快取時，由於每個人的水平問題，會導致實現方案千差萬別，同事又很難統一管理維護 通過提供spring的annotation，實現快取方案的統一 target retention retentionpolicy.runtim...
MCU設計方案
文章裡有兩個要點 1 邊緣計算 具體功能有 流合成 錄影 水印 送審等功能 這些多數設計到需要對 資料做處理 2 作者再部署的部署方案是自己搭建idc 這樣會面臨多線的問題 多線機房比單線機房要貴很多 所以核心就是吧計算節點放在單線機房 多線主機盡量只承擔sfu的功能 3 有個核心的問題 就是 資料...