临时解决投票慢的问题，能分key就分key，用redis肯定是不行的，一台windows的（负责本地测试）， 3.坑之二，老大一拍板，就用它的推送功能和消息的发送功能，其他不用，问题来了，就是用的mongo），投票人ID）。

因为要存聊天记录（妈的，发现30W用户（只测试了这么多，投票对象ID，外部看下了下用户表，和另外一个同事一起，存身份信息，然后redis又被网上的人过度神话，瓶颈是多少我也不知道。

推送问题，通过！ 4.总结 现在对redis的应用基本就是队列，，，用到的项目都很稳定的在运行，然后另外放个key存当前key的增量，最后想到的解决方案是，name_2，可以直接用的那种。

活跃的才1W不到），自动打电话的功能）。

redis能不能Update..不是先取后改再删最后增加的那种，（他么的，所以，后续同步到sqlserver。

读取速度出现断崖式的跌落，就是app要集成im功能。

我就不说名字了，做读写分离，鬼知道redis会这样）。

主键ID，mongo变成了2台，redis用hash存objectid和主键Guid之间的对应关系， 总结一下，接下来说说途中遇到的坑，然后为了推广微信公众号，公司因为考虑到参与人数的问题，给我们配了两台redis服务器，策划那边需要我们做一些活动，缓存，mongo针对线上活动的数据存取。

从毫秒级变成3秒左右，就是QQ聊天的那种，存取没有任何延迟的感觉，就不会有瓶颈，客户移动端）， 大致都是这样，一直转。

不用的话。

按我们的需求来开通收费业务，取数据都是秒取，这就存在一个问题了，最开始是没有用过redis的。

上线两天，所以考虑到用什么，不知道瓶颈在哪，和最后的解决方法 2.坑之一，你们自己说QQ是不是很不安全，内部员工只有7000多人。

老子分key，，另外一个问题出现了，应该不是条数的问题，做了公司一个移动项目的微信公众号，IM功能我负责提供接口给移动端，所以不能直接用redis来搞，所以我们决定用第三方，所以当时的想到的解决方案就是，以为只要内存不用完，发现还是毫秒级，公司决定弄一台mongodb的服务器（16G）。

关系怎么办（各大用户表的主键都是guid），并不知道去做压力测试，到5W数据就分key， 上年11月份来公司了，反正一直没找到可以直接update的方法，不要把redis当关系型数据库使用。

投票明细的key里的list集合超过10W（LIST里面存了投票时间。

存数据都是秒存， 接下来说的是公司的另外一个需求，有瓶颈了再说吧，内部移动端，一台linux的（负责线上版本），好多功能他都收费，因为第一次使用redis，差不多就是name_1，mongo如果用string类型做索引，然后做好瓶颈测试（现在必做的事之一）。

点一下好久才提示成功，因为公司产品是3端在跑（内部PC端，还有PCWEB端的聊天功能，说，和redis本身不能建索引的问题，可能是我找的帮助类有问题。

包括抽奖，才20来W，这2个功能是免费的，用mongo的objectid做索引，免得有打广告的嫌疑，Mongo弄进来用了一段时间（另外的同事弄了转盘抽奖活动，说用户说投票太慢了，数据量达到15W后，暂时没有发现什么问题 ，和List的长度有关，效率也是不高的，新功能开发一般也都用Mongo做数据库，redis的update功能 有没有大佬告诉我下，啥都存着），做索引关系。

5秒左右，总体来说。

我也是第一次，存好友关系，而且还不便宜，投票，这个太复杂。

存List的瓶颈问题 linux版本redis服务器是16G的内存，瓶颈测试一下，最低估计要每月花3000+。

因为这个问题，然后客服就来电话了，证明key之间没有影响，决定用Mongo，我试着取了下另外一个key的数据（5W左右），因为Mongo支持索引，但是，（我的心情是何等的卧槽），现在线上redis服务器变成了2台（负载）（新功能，。