談一談NOSQL的應用，Redis/Mongo

標籤：投票   sql   guid   公司   方法   style   接下來   lis   推送   

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台，做讀寫分離。總體來說，用到的項目都很穩定的在運行，暫時沒有發現什麼問題

談一談NOSQL的應用，Redis/Mongo