1.心路歷程

      上年11月份來公司了，和另外一個同事一起，做了公司一個移動項目的微信公眾號，然后為了推廣微信公眾號，策劃那邊需要我們做一些活動，包括抽獎，投票。最開始是沒有用過redis的，公司因為考慮到參與人數(shù)的問題，給我們配了兩臺redis服務器，一臺windows的（負責本地測試），一臺linux的（負責線上版本），接下來說說途中遇到的坑，和最后的解決方法

2.坑之一，存List的瓶頸問題

      linux版本redis服務器是16G的內存，因為第一次使用redis，并不知道去做壓力測試，不知道瓶頸在哪，然后redis又被網(wǎng)上的人過度神話，以為只要內存不用完，就不會有瓶頸，取數(shù)據(jù)都是秒取，存數(shù)據(jù)都是秒存。上線兩天，投票明細的key里的list集合超過10W（LIST里面存了投票時間，投票對象ID，主鍵ID，投票人ID）,讀取速度出現(xiàn)斷崖式的跌落，從毫秒級變成3秒左右，數(shù)據(jù)量達到15W后，5秒左右。然后客服就來電話了，說用戶說投票太慢了，點一下好久才提示成功，一直轉。（他么的，我也是第一次，鬼知道redis會這樣），我試著取了下另外一個key的數(shù)據(jù)（5W左右），發(fā)現(xiàn)還是毫秒級，證明key之間沒有影響，所以當時的想到的解決方案就是，老子分key，差不多就是name_1,name_2，然后另外放個key存當前key的增量，到5W數(shù)據(jù)就分key，臨時解決投票慢的問題。

     總結一下，應該不是條數(shù)的問題，和List的長度有關，所以，不要把redis當關系型數(shù)據(jù)庫使用，能分key就分key，然后做好瓶頸測試（現(xiàn)在必做的事之一）。

3.坑之二，redis的update功能

      有沒有大佬告訴我下，redis能不能Update..不是先取后改再刪最后增加的那種。?？梢灾苯佑玫哪欠N。。?？赡苁俏艺业膸椭愑袉栴}，反正一直沒找到可以直接update的方法。

      因為這個問題，和redis本身不能建索引的問題，公司決定弄一臺mongodb的服務器（16G）。

      接下來說的是公司的另外一個需求，就是app要集成im功能，就是QQ聊天的那種，這就存在一個問題了，推送問題，這個太復雜，所以我們決定用第三方，我就不說名字了，免得有打廣告的嫌疑。但是，另外一個問題出現(xiàn)了，好多功能他都收費，而且還不便宜，按我們的需求來開通收費業(yè)務，最低估計要每月花3000+，老大一拍板，說，就用它的推送功能和消息的發(fā)送功能，其他不用，這2個功能是免費的。（我的心情是何等的臥槽），因為公司產品是3端在跑（內部PC端，內部移動端，客戶移動端），IM功能我負責提供接口給移動端，還有PCWEB端的聊天功能，所以考慮到用什么，Mongo弄進來用了一段時間（另外的同事弄了轉盤抽獎活動，就是用的mongo），用redis肯定是不行的，因為要存聊天記錄（媽的，你們自己說QQ是不是很不安全，啥都存著），存好友關系，存身份信息，所以不能直接用redis來搞，決定用Mongo，因為Mongo支持索引，問題來了，mongo如果用string類型做索引，效率也是不高的，不用的話，關系怎么辦（各大用戶表的主鍵都是guid）,最后想到的解決方案是，用mongo的objectid做索引，redis用hash存objectid和主鍵Guid之間的對應關系