标签：投票 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台，做读写分离。总体来说，用到的项目都很稳定的在运行，暂时没有发现什么问题
标签：投票 sql guid 公司 方法 style 接下来 lis 推送
原文地址：http://www.cnblogs.com/wuxl360/p/6018937.html
