1.心路歷程
上年11月份來公司了，和另外一個同事一起，做了公司一個移動項目的微信公眾號，然后為了推廣微信公眾號，策劃那邊需要我們做一些活動，包括抽獎，投票。最開始是沒有用過redis的，公司因為考慮到參與人數(shù)的問題，給我們配了兩臺redis服務(wù)器，一臺windows的（負(fù)責(zé)本地測試），一臺linux的（負(fù)責(zé)線上版本），接下來說說途中遇到的坑，和最后的解決方法
2.坑之一，存List的瓶頸問題
linux版本redis服務(wù)器是16G的內(nèi)存，因為第一次使用redis，并不知道去做壓力測試，不知道瓶頸在哪，然后redis又被網(wǎng)上的人過度神話，以為只要內(nèi)存不用完，就不會有瓶頸，取數(shù)據(jù)都是秒取，存數(shù)據(jù)都是秒存。上線兩天，投票明細(xì)的key里的list集合超過10W（LIST里面存了投票時間，投票對象ID，主鍵ID，投票人ID）,讀取速度出現(xiàn)斷崖式的跌落，從毫秒級變成3秒左右，數(shù)據(jù)量達(dá)到15W后，5秒左右。然后客服就來電話了，說用戶說投票太慢了，點(diǎn)一下好久才提示成功，一直轉(zhuǎn)。（他么的，我也是第一次，鬼知道redis會這樣），我試著取了下另外一個key的數(shù)據(jù)（5W左右），發(fā)現(xiàn)還是毫秒級，證明key之間沒有影響，所以當(dāng)時的想到的解決方案就是，老子分key，差不多就是name_1,name_2，然后另外放個key存當(dāng)前key的增量，到5W數(shù)據(jù)就分key，臨時解決投票慢的問題。
總結(jié)一下，應(yīng)該不是條數(shù)的問題，和List的長度有關(guān)，所以，不要把redis當(dāng)關(guān)系型數(shù)據(jù)庫使用，能分key就分key，然后做好瓶頸測試（現(xiàn)在必做的事之一）。
3.坑之二，redis的update功能
有沒有大佬告訴我下，redis能不能Update..不是先取后改再刪最后增加的那種。?？梢灾苯佑玫哪欠N。。。可能是我找的幫助類有問題，反正一直沒找到可以直接update的方法。
延伸閱讀
- ssh框架 2016-09-30
- 阿里移動安全 [無線安全]玩轉(zhuǎn)無線電——不安全的藍(lán)牙鎖 2017-07-26
- 消息隊列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 論文筆記【圖片目標(biāo)分割】 2017-07-26
- 詞向量-LRWE模型-更好地識別反義詞同義詞 2017-07-26
- 從棧不平衡問題 理解 calling convention 2017-07-26
- php imagemagick 處理 圖片剪切、壓縮、合并、插入文本、背景色透明 2017-07-26
- Swift實(shí)現(xiàn)JSON轉(zhuǎn)Model - HandyJSON使用講解 2017-07-26
- 阿里移動安全 Android端惡意鎖屏勒索應(yīng)用分析 2017-07-26
- 集合結(jié)合數(shù)據(jù)結(jié)構(gòu)來看看(二) 2017-07-26
學(xué)習(xí)是年輕人改變自己的最好方式