1.心路歷程
上年11月份來公司了，和另外一個(gè)同事一起，做了公司一個(gè)移動(dòng)項(xiàng)目的微信公眾號(hào)，然后為了推廣微信公眾號(hào)，策劃那邊需要我們做一些活動(dòng)，包括抽獎(jiǎng)，投票。最開始是沒有用過redis的，公司因?yàn)榭紤]到參與人數(shù)的問題，給我們配了兩臺(tái)redis服務(wù)器，一臺(tái)windows的（負(fù)責(zé)本地測(cè)試），一臺(tái)linux的（負(fù)責(zé)線上版本），接下來說說途中遇到的坑，和最后的解決方法
2.坑之一，存List的瓶頸問題
linux版本redis服務(wù)器是16G的內(nèi)存，因?yàn)榈谝淮问褂胷edis，并不知道去做壓力測(cè)試，不知道瓶頸在哪，然后redis又被網(wǎng)上的人過度神話，以為只要內(nèi)存不用完，就不會(huì)有瓶頸，取數(shù)據(jù)都是秒取，存數(shù)據(jù)都是秒存。上線兩天，投票明細(xì)的key里的list集合超過10W（LIST里面存了投票時(shí)間，投票對(duì)象ID，主鍵ID，投票人ID）,讀取速度出現(xiàn)斷崖式的跌落，從毫秒級(jí)變成3秒左右，數(shù)據(jù)量達(dá)到15W后，5秒左右。然后客服就來電話了，說用戶說投票太慢了，點(diǎn)一下好久才提示成功，一直轉(zhuǎn)。（他么的，我也是第一次，鬼知道redis會(huì)這樣），我試著取了下另外一個(gè)key的數(shù)據(jù)（5W左右），發(fā)現(xiàn)還是毫秒級(jí)，證明key之間沒有影響，所以當(dāng)時(shí)的想到的解決方案就是，老子分key，差不多就是name_1,name_2，然后另外放個(gè)key存當(dāng)前key的增量，到5W數(shù)據(jù)就分key，臨時(shí)解決投票慢的問題。
總結(jié)一下，應(yīng)該不是條數(shù)的問題，和List的長(zhǎng)度有關(guān)，所以，不要把redis當(dāng)關(guān)系型數(shù)據(jù)庫使用，能分key就分key，然后做好瓶頸測(cè)試（現(xiàn)在必做的事之一）。
3.坑之二，redis的update功能
有沒有大佬告訴我下，redis能不能Update..不是先取后改再刪最后增加的那種。。可以直接用的那種。。。可能是我找的幫助類有問題，反正一直沒找到可以直接update的方法。
