推荐引擎数百分片 Redis 使用时需要注意的事

互联网应用场景下，每分钟数十万并发量，redis是不可或缺的，推荐系统业务作为一个应用或者说服务在电商各个频道、榜单、排行中有着不可或缺作用，因为确实是比人工选品有着巨大优势。

回过头来我们看在超多分片下一些典型问题，分片一多，出问题几率就大，主从是必须的。为了异地容灾双机房是必须的，双机房主从是高可用场景下典型配置，可见确定是存在一定资源消耗。

单条数据不要过大，不要形成写热点，不要形成读热点，这些问题其实集群规模小的时候也需要注意的，有很多同事也有遇到相应问题。

数据写的时候，618时不要把数据写满，单个分片内存到80%风险就比较大，这时还不能扩容，因为扩容本身会影响集群性能，但是不扩容分片满后会爆掉，这时怎么办呢？停止写入或者说减少一些新的写入，就能会好的控制问题，解决问题。

不要把连接数打满，因为以前多个集群是混用的更多是分散数据压力，那是逻辑简单，架构在当时是合理的，但随着业务发展逻辑复杂，特征工程演进，过多微服务以及storm程序，这时集群连接数就太多了。

减少连接数，是问题关键，怎么减少？备战时刻去在去通过分拆服务方式减少连接数是不太可能了，离618已经很近，并且促销活动已经开始。

想其他办法，通过分析发现storm本身进程很多，每个进程对应一个客户端，每个客户端一个连接池，这也是本身造成连接数一个原因。

storm本身是不需要上线的，对storm改造优化减少连接数，通过和redis团队沟通，构建新的分组并且通过控制分组连接数，单个分组可以单独配置连接数，通过这种方式一定程度减少连接。

还有没有别的办法来控制连接数？答案是有的，就是通过新版客户端，新客户端采用类似dubbo架构，单连接，相比于原有架构连接数一下子就下来了，没有通过上面调整分组数解决问题。

单连接这种架构这么好有没有缺点呢，肯定是有的连接中如果有一个数据稍大会影响客户端本身吞吐的，原来也是存在这种问题的，但单连接架构理论上问题会更严重。这是需要注意的，但是现在主要先解决主要问题，应对618。

618一晃已过去好多天做一下，redis使用上总结，希望对其他遇到同学有一点帮助，遇到类似问题时候。

搞懂一个存储对于其他存储hbase、数据库等，会能有更多认知。

以前写的redis相关文章，有架构设计，有遇到问题，以及使用总结：

分布式redis架构设计简介

大型电商互联网架构中redis运用

redis导致线上服务每隔5分钟可用率下降

在谈电商618大促备战分布式redis、压测、限流、降级、review