1.心路歷程
上年11月份來公司了，和另外一個同事一起，做了公司一個移動項目的微信公眾號，然后為了推廣微信公眾號，策划那邊需要我們做一些活動，包括抽獎，投票。最開始是沒有用過redis的，公司因為考慮到參與人數的問題，給我們配了兩台redis服務器，一台windows的（負責本地測試），一台linux的（負責線上版本），接下來說說途中遇到的坑，和最后的解決方法
2.坑之一，存List的瓶頸問題
linux版本redis服務器是16G的內存，因為第一次使用redis，並不知道去做壓力測試，不知道瓶頸在哪，然后redis又被網上的人過度神話，以為只要內存不用完，就不會有瓶頸，取數據都是秒取，存數據都是秒存。上線兩天，投票明細的key里的list集合超過10W（LIST里面存了投票時間，投票對象ID，主鍵ID，投票人ID）,讀取速度出現斷崖式的跌落，從毫秒級變成3秒左右，數據量達到15W后，5秒左右。然后客服就來電話了，說用戶說投票太慢了，點一下好久才提示成功，一直轉。（他么的，我也是第一次，鬼知道redis會這樣），我試着取了下另外一個key的數據（5W左右），發現還是毫秒級，證明key之間沒有影響，所以當時的想到的解決方案就是，老子分key，差不多就是name_1,name_2，然后另外放個key存當前key的增量，到5W數據就分key，臨時解決投票慢的問題。
總結一下，應該不是條數的問題，和List的長度有關，所以，不要把redis當關系型數據庫使用，能分key就分key，然后做好瓶頸測試（現在必做的事之一）。
3.坑之二，redis的update功能
有沒有大佬告訴我下，redis能不能Update..不是先取后改再刪最后增加的那種。。可以直接用的那種。。。可能是我找的幫助類有問題，反正一直沒找到可以直接update的方法。
因為這個問題，和redis本身不能建索引的問題，公司決定弄一台mongodb的服務器（16G）。
接下來說的是公司的另外一個需求，就是app要集成im功能，就是QQ聊天的那種，這就存在一個問題了，推送問題，這個太復雜，所以我們決定用第三方，我就不說名字了，免得有打廣告的嫌疑。但是，另外一個問題出現了，好多功能他都收費，而且還不便宜，按我們的需求來開通收費業務，最低估計要每月花3000+，老大一拍板，說，就用它的推送功能和消息的發送功能，其他不用，這2個功能是免費的。（我的心情是何等的卧槽），因為公司產品是3端在跑（內部PC端，內部移動端，客戶移動端），IM功能我負責提供接口給移動端，還有PCWEB端的聊天功能，所以考慮到用什么，Mongo弄進來用了一段時間（另外的同事弄了轉盤抽獎活動，就是用的mongo），用redis肯定是不行的，因為要存聊天記錄（媽的，你們自己說QQ是不是很不安全，啥都存着），存好友關系，存身份信息，所以不能直接用redis來搞，決定用Mongo，因為Mongo支持索引，問題來了，mongo如果用string類型做索引，效率也是不高的，不用的話，關系怎么辦（各大用戶表的主鍵都是guid）,最后想到的解決方案是，用mongo的objectid做索引，redis用hash存objectid和主鍵Guid之間的對應關系，瓶頸測試一下，發現30W用戶（只測試了這么多，瓶頸是多少我也不知道，有瓶頸了再說吧，內部員工只有7000多人，外部看下了下用戶表，才20來W，活躍的才1W不到），存取沒有任何延遲的感覺，通過！
4.總結
現在對redis的應用基本就是隊列，緩存，做索引關系，mongo針對線上活動的數據存取，新功能開發一般也都用Mongo做數據庫，后續同步到sqlserver。
大致都是這樣，現在線上redis服務器變成了2台（負載）（新功能，自動打電話的功能），mongo變成了2台，做讀寫分離。總體來說，用到的項目都很穩定的在運行，暫時沒有發現什么問題