Redis作为分布式缓存，适用于高并发读写场景，但不宜作主数据库。架构选型包括单点、主从、哨兵和Cluster，根据业务需求选择。持久化策略可选AOF和RDB，或结合使用以平衡安全性和性能。避免大key以减少读写延迟，使用pipeline提升批量操作效率。Redis版本选择应考虑新特性和稳定性，如 Sentinel在2.8，Cluster在3.0。
1.Redis适合做什么，不适合做什么？
Redis是分布式缓存，不要把它当数据库使用。它的增删改查不如MySQL好用，也不能保证绝对安全的持久化。
2. 架构选型
| 读写分离 | 主节点宕机从节点自动顶上 | 数据分片 | 可横向扩展 | |
|---|---|---|---|---|
| 单点 | N | N | N | N |
| 主从 | Y | N | N | N |
| 哨兵 | Y | Y | N | N |
| cluster | Y | Y | Y | Y |
- 除了以上各种模式，也可以选择阿里云提供的Redis服务，模式可选单点、主从、cluster等多种，底层内置proxy，使用起来使用单点，很方便。
- 如果是做游戏全球化部署，还可以考虑阿里云的Redis全球化缓存，全球各地部署，能最小化Redis延迟，各节点之间自动同步，底层使用的是cluster。
3. 是否需要代理
根据实际需求，加代理的好处是：
- 方便客户端代码编写，无论后端是cluster还是其他模式，写法统一。
- 后端扩容、迁移，客户端无感知。
常见的Redis代理实现有：Twemproxy，predixy，redis-cluster-proxy，CodisProxy等。如果用阿里云的Redis服务，其内置了代理。
4. 持久化方式选择
| AOF | RDB | |
|---|---|---|
| 定义 | 追加方式 | 全量快照方式 |
| 占用空间 | 大 | 小 |
| 重启恢复速度 | 慢 | 快 |
| 持久化时机 | 每次修改或每秒 | 一定时间内达到修改次数 |
| 数据安全性 | 高 | 低 |
| 其他 | 数据量大时fork()很耗CPU |
两种方式都会影响Redis性能，具体使用哪种根据实际需求决定。
- 如果需要数据库级别的安全性，那么两种方式同时使用
- 如果可以容忍一段时间数据丢失，那么可以只使用RDB
- 不推荐只使用AOF，因为RDB恢复的速度更快
5. 避免大key出现
大key是指单个key对应的数据结构中数据量太大，它会导致读写严重超时。解决办法是：将原key对应的内容分散到不同key中存储，例如游戏中设置新key为原key+playerId。
6. 批量操作请用pipeline
使用pipeline可以将一系列命令打包传输到服务端，显著减小RTT。
7. Redis版本选择
| 版本 | 主要特性 |
|---|---|
| 2.8 | Sentinel生产可用 |
| 3.0 | Cluster功能 |
| 4.0 | 模块系统 |
| 5.0 | 新的流数据类型 |
| 6.0 | 多线程IO |
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
