Redis读写分离搭建的完整步骤

• • 2.2 修改从服务器a和从服务b的redis配置
  • 2.3 删除从服务器a和从服务器b的数据文件
  • 2.4 重启从服务器a和从服务器b
• 3、redis读写分离优势
  

1、概述

随着企业业务的不断扩大，请求的并发量不断增长，redis可能终会出现无法负载的情况，此时我们就需要想办法去提升redis的负载能力。

读写分离（主从复制）是一个比较简单的扩展方案，使用多台机器同时运行redis服务，一台负责写服务，多台负责读服务，通过多台服务器对请求进行负载，大大提高了redis服务的负载压力。

最常见的读写分离是一主二从的模式，一台主服务器负责redis写入服务，两台从服务器负责redis的读取服务，从服务器定时从主服务器复制redis数据。

今天我们就来聊聊redis的读写分离如何搭建的。

2、读写分离的搭建

2.1 场景说明

主服务器ip：192.168.1.144

从服务器a ip：192.168.1.22

从服务器b ip：192.168.1.8

这三台服务器上都已经安装好了redis环境，安装方法参见我的另一篇文章《redis的安装、基本使用以及与springboot的整合》。

2.2 修改从服务器a和从服务b的redis配置

replicaof　　　设置redis主服务的ip和端口

masterauth　 设置redis主服务的密码

2.3 删除从服务器a和从服务器b的数据文件

# cd/usr/local/redis/db

#rm -rf *.rdb *.aof

2.4 重启从服务器a和从服务器b

#cd /etc/init.d/

#./redis_init_script stop

# ./redis_init_script start

2.5 查看主从状态

# redis-cli

> auth zhuifengren

>info replication

主服务器状态：

从服务器a状态：

从服务器b状态：

2.6 测试主从复制

此时，在主服务器，写入redis值，在从服务器就可以读取。

3、redis读写分离优势

透明兼容

读写分离和普通集群规格一样，都使用了redis-proxy做请求转发，多分片令使用存在一定的限制，但从主从升级单分片读写分离，或者从集群升级到多分片的读写分离集群可以做到完全兼容。

用户和redis-proxy建立连接，redis-proxy会识别出客户端连接发送过来的请求是读还是写，然后按照权重作负载均衡，将请求转发到后端不同的db节点中，写请求转发给master，读操作转发给read-only replica（master默认也提供读，可以通过权重控制）。

用户只需要购买读写分离规格的实例，直接使用任何客户端即可直接使用，业务不用做任何修改就可以开始享受读写分离服务带来的巨大性能提升，接入成本几乎为0。

高可用

高可用模块（ha）监控所有db节点的健康状态，为整个实例的可用性保驾护航。master宕机时自动切换到新主。如果某个read-only replica宕机，ha也能及时感知，然后重搭一个新的read-only replica，下线宕机节点。

除ha之外，redis-proxy也能实时感知每个read-only replica的状态。在某个read-only replica异常期间，redis-proxy会自动降低这个节点的权重，如果发现某个read-only replica连续失败超过一定次数以后，会暂时屏蔽异常节点，直到异常消失以后才会恢复其正常权重。

redis-proxy和ha一起做到尽量减少业务对后端异常的感知，提高服务可用性。

高性能

对于读多写少的业务场景，直接使用集群版本往往不是最合适的方案，现在读写分离提供了更多的选择，业务可以根据场景选择最适合的规格，充分利用每一个read-only replica的资源。

目前单shard对外售卖1 master + 1/3/5 read-only replica多种规格（如果有更大的需求可以提工单反馈），提供60万qps和192 mb/s的服务能力，在完全兼容所有命令的情况下突破单机的资源限制。后续将去掉规格限制，让用户根据业务流量随时*的增加或减少read-only replica数量。

4、综述

今天介绍了redis读写分离的搭建，相对来说是比较容易的，但读写分离有个缺点，当主服务宕机后，从服务是不能升级成主服务的。

为了解决这个单点问题，后面我们会介绍redis的哨兵模式和集群模式。

到此这篇关于redis读写分离搭建的文章就介绍到这了,更多相关redis读写分离搭建内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！