Redis 部署选型方案
==前言==
- 项目即将使用Redis，本文对Redis的部署方案，进行选型分析。
==一、部署方案介绍==
==1）、单机版==
1-单机版.jpg
单机版三个问题
- 1、内存容量有限
- 2、处理能力有限
- 3、无法高可用
==2）、多机版==
2-多机版.jpg
特性
- 1、复制（Replication）
- 2、哨兵（Sentinel）
- 3、集群（Cluster）
Redis多机版部署特性功能
- 复制：扩展系统对于读的能力
- 哨兵：为服务器提供高可用特性，减少故障停机出现
- 集群：扩展内存容量，增加机器，提高性能读写能力和存储以及提高可用特性
==3）、复制==
Redis的复制（replication）功能允许用户根据一个Redis 服务器来创建任意多个该服务器的复制品，其中被复制的服务器为主服务器（master），而通过复制创建出来的服务器复制品，则为从服务器（slave），master负责读写，slave一般只负责读。只要主从服务器之间的网络连接正常，主从服务器两者会具有相同的数据，主服务器就会一直将发生在自己身上的数据更新同步给从服务器，从而一直保证主从服务器的数据相同。
3-复制.jpg
特点：
- 1、master/slave 角色
- 2、master/slave 数据相同
- 3、降低master读的压力，在转交从库
问题：
- 1、无法保证高可用
- 2、没有解决master写的压力
4）、哨兵
Redis sentinel 是一个分布式系统中监控redis主从服务器，并在主服务器下线时自动进行故障转移，其中三个特性：
- 监控（Monitoring）：Sentinel 会不断的检查你的主服务器和从服务器是否运作正常。
- 提醒（Notification）：当被监控的某个Redis服务器出现问题时，Sentinel可以通过API向管理员或者其他应用程序发送通知。
- 自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时，Sentinel会开始一次自动故障前一操作。
4-哨兵.jpg
特点： - 1、保证高可用
- 2、监控各个节点
- 3、自动故障迁移
缺点：
- 1、主从模式，切换需要时间丢数据
- 2、没有解决master写的压力
5）、集群proxy
5-集群proxy.jpg
Twemproxy
- Twemproxy 是一个Twitter开源的一个redis和memcache 快速/轻量级代理服务器。
- Twemproxy是一个快速的单线程代理程序，支持Memcached ASCII协议和redis协议。
特点：
- 1、多种hash算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkis
- 2、支持失败节点自动删除
- 3、后端Sharding分片逻辑对业务透明，业务方的读写方式和操作单个Redis一致。
缺点：
- 1、增加了新的proxy，需要维护其高可用。
- 2、failover逻辑需要自己实现，其本身不能支持故障的自动转移。
- 3、可扩展性差，进行扩缩容都需要手动干预。
6）、直连版（三主三从）(cluster)
6-直连版.jpg
特点：
- 1、无中心架构（不存在哪个节点影响性能瓶颈），少了proxy层。
- 2、数据按照slot存储分布在多个节点，节点时间数据共享，可动态调用整数分布。
- 3、可扩展性，可线性扩展到1000个节点，节点可动态添加或删除。
- 4、高可用性，部分节点不可用时，集群仍可用，通过增加Slave做备份数据副本。
- 5、实现故障自动failover，节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色提升。
缺点：
- 1、资源隔离性较差，容易出现相互影响的情况。
- 2、数据通过异步复制，不保证数据的强一致性。
