推荐引擎数百分片 Redis 使用时需要注意的事
source link: https://mp.weixin.qq.com/s/RK1ThFCZ2uDym8jTky4vpQ?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
互联网应用场景下，每分钟数十万并发量，redis是不可或缺的，推荐系统业务作为一个应用或者说服务在电商各个频道、榜单、排行中有着不可或缺作用，因为确实是比人工选品有着巨大优势。
回过头来我们看在超多分片下一些典型问题，分片一多，出问题几率就大，主从是必须的。为了异地容灾双机房是必须的，双机房主从是高可用场景下典型配置，可见确定是存在一定资源消耗。
单条数据不要过大，不要形成写热点，不要形成读热点，这些问题其实集群规模小的时候也需要注意的，有很多同事也有遇到相应问题。
数据写的时候，618时不要把数据写满，单个分片内存到80%风险就比较大，这时还不能扩容，因为扩容本身会影响集群性能，但是不扩容分片满后会爆掉，这时怎么办呢？停止写入或者说减少一些新的写入，就能会好的控制问题，解决问题。
不要把连接数打满，因为以前多个集群是混用的更多是分散数据压力，那是逻辑简单，架构在当时是合理的，但随着业务发展逻辑复杂，特征工程演进，过多微服务以及storm程序，这时集群连接数就太多了。
减少连接数，是问题关键，怎么减少？备战时刻去在去通过分拆服务方式减少连接数是不太可能了，离618已经很近，并且促销活动已经开始。
想其他办法，通过分析发现storm本身进程很多，每个进程对应一个客户端，每个客户端一个连接池，这也是本身造成连接数一个原因。
storm本身是不需要上线的，对storm改造优化减少连接数，通过和redis团队沟通，构建新的分组并且通过控制分组连接数，单个分组可以单独配置连接数，通过这种方式一定程度减少连接。
还有没有别的办法来控制连接数？答案是有的，就是通过新版客户端，新客户端采用类似dubbo架构，单连接，相比于原有架构连接数一下子就下来了，没有通过上面调整分组数解决问题。
单连接这种架构这么好有没有缺点呢，肯定是有的连接中如果有一个数据稍大会影响客户端本身吞吐的，原来也是存在这种问题的，但单连接架构理论上问题会更严重。这是需要注意的，但是现在主要先解决主要问题，应对618。
618一晃已过去好多天做一下，redis使用上总结，希望对其他遇到同学有一点帮助，遇到类似问题时候。
搞懂一个存储对于其他存储hbase、数据库等，会能有更多认知。
以前写的redis相关文章，有架构设计，有遇到问题，以及使用总结：
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK