本文探讨了在面临高数据率和快速响应需求时，如何基于实际需求选择Redis作为技术解决方案。文章详细介绍了Redis的单线程模型、组件结构、不同使用方式（如单副本、主从、Sentinel和集群）的优缺点，并最终选择了Redis集群以应对66万message/s的数据处理挑战。通过逻辑优化和业务规则，降低了Redis的实际访问压力。
目录
- 需求
- Redis组件及单线程模型
- Redis使用方式
- Redis优化
- 总结
一、需求
在当前的技术方案不可用的情况下，需要新的技术方案，这个时候就需要进行技术选型，那么如何进行技术选型呢？这并不是一件简单的事情，但仍有迹可循
笔者的需求：使用Struct Streaming流式处理时需要用到一个100G的资源文件，而且资源文件每个月都要进行一次更新。显然这样的情况下，Spark广播是不合适的。这个时候就需要一个性能高，查询响应快的存储方案，使我们在进行Spark流处理时，能够在响应速度可接受的范围内关联上资源信息。
我们要消费的kafka数据率大概在66万message/s，而在流式处理过程中，每条数据都要关联资源文件以取得目标字段，怎么办？
总结一下我们的需求就是两点：快、稳定。
二、Redis组件及单线程模型
1、Redis基于内存存储，官方宣称10万/s左右的查询响应速度，这是我们选择使用redis作为中间缓存最重要的原因。
2、Reids基于I/O多路复用的单线程模型，避免了资源争用，高效。
Redis基础组件结构：
Redis网络层主要
最低0.47元/天 解锁文章
扫一扫
1653
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
