Tiny URL基本也算是必考題目了憎蛤，我是第一次刷這道題感覺并沒有什么頭緒在encoding上面外傅。我覺得是不是就隨機(jī)生成幾個(gè)數(shù)字纪吮，然后存在Database里，跟本來(lái)的url做一個(gè)matching萎胰。decode的話直接找database看/ HashMap.
也是system design可以碾盟，但是這道題不能使用database，如果用了HashMap技竟，user如果初始化另一個(gè)object 就沒法get Key了冰肴。
看完答案發(fā)現(xiàn)，看來(lái)只會(huì)生成一個(gè)TinyURL object. 所以我原本想的hashmap是可以的榔组。 這個(gè)地方需要問(wèn)面試官確認(rèn)是不是只生成一個(gè)object熙尉。
把給定的url 換成prefix+ counter. counter 變量是一個(gè)global variable。 這個(gè)方法的一個(gè)很嚴(yán)重的問(wèn)題是搓扯，當(dāng)?shù)?0000萬(wàn)個(gè)用戶使用這個(gè)方法的時(shí)候检痰，也許他生成的編號(hào)比原本的url還長(zhǎng)，這就不是Tiny URL了
Hashcode方法也很厲害锨推，但是很容易出現(xiàn)collision. 因?yàn)楫?dāng)用戶有個(gè)幾萬(wàn)人以后铅歼，很容易出現(xiàn)重復(fù)的hashcode。這個(gè)時(shí)候就操蛋了换可。
個(gè)人比較喜歡這個(gè)方法椎椰，用random的方法來(lái)encode URL。如果這個(gè)隨機(jī)生成的code已經(jīng)被用過(guò)的話锦担， 我們生成一個(gè)新的random 來(lái)用俭识。
Decode的話就去找database/hashmap問(wèn)。
