本文主要是介绍redis从单机到HA高可用集群的部署策略总结，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
最近在研究redis的部署，看了很多方案，现在总结一下
单机模式
最初接触redis，用的就是单机模式，最简单的一种模式，client直接访问1个redis服务。
优点：入门级，部署简单。
缺点：负载量小、容量小、容灾差。
客户端分片模式
客户端分片也是常见的一种模式，就是有多个redis服务，利用客户端的机制将数据存储到不同的redis服务中，然后从不同的redis服务中读取。
优点：实现了分片和负载均衡，存储数据的空间增大了。
缺点：扩容困难，增加一个redis服务，以前存储的数据将全部失效；容灾性差，1个redis服务宕机，整个分片集群将无法工作。
redis主从+读写分离+哨兵
redis主从配置，设置1台机器为主服务器，N台机器为从服务器，然后利用redis自己的机制，把主服务器的数据同步到从服务器中。
然后利用哨兵机制（哨兵也是一个服务，可以配置哨兵集群）监控主服务器，主服务器出了问题，哨兵会“提拔”一个从服务器为主服务器，从而实现高可用。
客户端可根据自己的机制，把写操作指向主服务器，读操作指向从服务器。从而实现负载均衡。
优点：实现了负载均衡和高可用。
缺点：由于每台机器都是一模一样的数据，容量小又成了问题，不支持分片。
redis主从+读写分离+哨兵 升级方案
此方案应该是 redis2.x 时代的终极方案。
就是部署多套 redis主从+哨兵 ，然后利用客户端的机制，利用某种算法向不同的主服务器分片的存储数据，从而达到扩容、负载均衡、高可用。
优点：在redis 2.x 版本的时代，实现了分片、负载均衡、高可用。
缺点：扩容还是比较困难，增加一套 redis主从+哨兵，则可能会导致数据全部失效。
关于redis分片扩容的方案
redis分片扩容，是个比较难的问题
之前看到一个方案，就是在初期在一台服务器中多建一些redis服务，当存储的数据越来越多，内存或CPU不足时，则增加机器，将redis服务移植到新机器上，从而实现平滑扩容。
终极方案，redis3.0+集群
在redis3.0以上的版本，支持了redis集群。
redis集群可以简单的实现扩容、复制均衡、分片、高可用。
redis集群至少需要3个主redis服务，为了实现高可用，最好是6个redis服务，3主3从
步骤很简单：（这里只谈理论，具体集群配置网上很多，这里不详细介绍了）
1、配置6个redis服务，打开集群选项（如果设置密码，整个集群的redis服务密码必须一致），然后启动这6个服务
2、然后安装ruby相关的包（redis集群是利用ruby实现的）
3、执行redis安装包自带的 redis-trib.rb 命令，即可启动redis服务，该命令可以设置1台主服务器有几个从服务器（ --replicas 1 参数，1代表1台主服务器有1个从服务器）
这样就会有3个主服务和3个从服务。
最后用client端去访问这个集群即可，例如：Java 可以使用 JedisCluster 类去访问。
结语
以上是我这段时间研究redis部署的个人理解，也许有不对的地方，望大家指出，会虚心改正。
这篇关于redis从单机到HA高可用集群的部署策略总结的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
