Redis部署架构选择

知识点：

持久化：高可用的一部分，在发生redis集群灾难的情况下（比如说部分master+slave全部死掉了），如何快速进行数据恢复，快速实现服务可用，才能实现整个系统的高可用

复制：主从架构，master -> slave 复制，读写分离的架构，写master，读slave，横向扩容slave支撑更高的读吞吐，读高并发，10万，20万，30万，上百万，QPS，横向扩容

哨兵：高可用，主从架构，在master故障的时候，快速将slave切换成master，实现快速的灾难恢复，实现高可用性

redis cluster：多master读写，数据分布式的存储，横向扩容，水平扩容，快速支撑高达1T的数据量；更高的读写QPS；自动进行主备切换，高可用

考虑因素：

是否要支撑海量数据：redis cluster的master水平扩容

是否要支撑很高的读写QPS：redis cluster的master水平扩容，redis replication的slave水平扩容

是否要高可用：给每个redis实例都做好AOF+RDB的备份策略+容灾策略，sentinel实现主备切换

redis的第一套企业级的架构

如果你需要缓存的数据量不大，单master就可以容纳，一般来说你的缓存的总量在10G以内就可以，那么建议按照以下架构去部署：

redis持久化 + 备份方案 + 容灾方案 + redis replication（主从+读写分离）+ sentinal（哨兵集群，3个节点，高可用性）

可以支撑的数据量在10G以内，可以支撑的写QPS在几万左右，可以支撑的读QPS可以上10万以上（随你的需求，水平扩容slave节点就可以），可用性在99.99%

redis的第二套企业级架构

如果你需要缓存的数据量很大，则建议使用redis cluster的方式：

多master分布式存储数据，水平扩容 支撑更多的数据量，1T+以上没问题，只要扩容master即可

读写QPS分别都达到几十万都没问题，只要扩容master即可，redis cluster，读写分离，支持不太好，readonly才能去slave上读

支撑99.99%可用性，也没问题，master集群自身可以做到主备切换，冗余slave去进一步提升可用性的方案