在正文主题之前，给奋战在一线的程序员兄弟、各位大佬、各位各种o发个福利，最近我们根据多年积累的开发企业级软件经验，研发了基于web，类excel编辑器的免费java报表平台。无论是对开发报表项目还是暂时没有这方面需求的各位都希望你能了解下，加入我们的群，更希望您能多提宝贵意见，并且如果有时间也能参与到产品优化中来。谢谢大家。产品地址：http://product.mftcc.cn/rdp
互联网应用场景下，每分钟数十万并发量，redis是不可或缺的，推荐系统业务作为一个应用或者说服务在电商各个频道、榜单、排行中有着不可或缺作用，因为确实是比人工选品有着巨大优势。
回过头来我们看在超多分片下一些典型问题，分片一多，出问题几率就大，主从是必须的。为了异地容灾双机房是必须的，双机房主从是高可用场景下典型配置，可见确定是存在一定资源消耗。
单条数据不要过大，不要形成写热点，不要形成读热点，这些问题其实集群规模小的时候也需要注意的，有很多同事也有遇到相应问题。
数据写的时候，618时不要把数据写满，单个分片内存到80%风险就比较大，这时还不能扩容，因为扩容本身会影响集群性能，但是不扩容分片满后会爆掉，这时怎么办呢？停止写入或者说减少一些新的写入，就能会好的控制问题，解决问题。
不要把连接数打满，因为以前多个集群是混用的更多是分散数据压力，那是逻辑简单，架构在当时是合理的，但随着业务发展逻辑复杂，特征工程演进，过多微服务以及storm程序，这时集群连接数就太多了。
减少连接数，是问题关键，怎么减少？备战时刻去在去通过分拆服务方式减少连接数是不太可能了，离618已经很近，并且促销活动已经开始。
想其他办法，通过分析发现storm本身进程很多，每个进程对应一个客户端，每个客户端一个连接池，这也是本身造成连接数一个原因。
storm本身是不需要上线的，对storm改造优化减少连接数，通过和redis团队沟通，构建新的分组并且通过控制分组连接数，单个分组可以单独配置连接数，通过这种方式一定程度减少连接。
还有没有别的办法来控制连接数？答案是有的，就是通过新版客户端，新客户端采用类似dubbo架构，单连接，相比于原有架构连接数一下子就下来了，没有通过上面调整分组数解决问题。
单连接这种架构这么好有没有缺点呢，肯定是有的连接中如果有一个数据稍大会影响客户端本身吞吐的，原来也是存在这种问题的，但单连接架构理论上问题会更严重。这是需要注意的，但是现在主要先解决主要问题，应对618。
618一晃已过去好多天做一下，redis使用上总结，希望对其他遇到同学有一点帮助，遇到类似问题时候。
搞懂一个存储对于其他存储hbase、数据库等，会能有更多认知。