Redis 部署选型方案
2018-07-25 本文已影响61人
Impassable_time
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一般只负责读。只要主从服务器之间的网络连接正常,主从服务器两者会具有相同的数据,主服务器就会一直将发生在自己身上的数据更新同步给从服务器,从而一直保证主从服务器的数据相同。
特点:
- 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.jpgTwemproxy
- 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、数据通过异步复制,不保证数据的强一致性。