redis权限控制与主从只读控制

redis作为一个高速数据库，在互联网上，必须有对应的安全机制来进行保护。

1.比较安全的办法是采用绑定IP的方式来进行控制。

复制代码 代码如下:

bind 127.0.0.1

表示仅仅允许通过127.0.0.1这个ip地址进行访问。那么其实只有自己才能访问自己了，其他机器都无法访问他。

这段命令要去redis.conf里修改。

这里请注意

我们常用的启动方式src/redis-server

改为src/redis-server redis.conf

因为它需要加载配置文件。

这个方法有一点不太好，我难免有多台机器访问一个redis服务

2.设置密码，以提供远程登陆

redis.conf
找到
requirepass
写上
requirepass yourpassword
设置密码以后发现可以登陆，但是无法执行命令了。

复制代码 代码如下:

src/redis-cli -h 192.168.1.121
keys *
(error) ERR operation not permitted

授权命令

复制代码 代码如下:

auth 123456

登陆带密码方式

复制代码 代码如下:

./redis-cli -h 192.168.1.121 -a abcd

由于redis并发能力极强，仅仅搞密码，攻击者可能在短期内发送大量猜密码的请求，很容易暴力破解，所以建议密码越长越好，比如20位。（密码在 conf文件里是明文，所以不用担心自己会忘记）

Redis的主从架构，能帮助我们实现读多，写少的情况，下面配置Redis架构，很简单。

准备环境 vmware + rhel-server-7.0(101，102，103)+redis-3.2.0

1、在192.168.137.101安装好redis3.2.0，我安装的目录如下

redis的安装参考http://blog.csdn.net/yingxiake/article/details/51469364

2、通过ssh将redis文件夹copy到102和103的linux上

scp -rf redis/ root@192.168.137.102:/home/redis
scp -rf redis/ root@192.168.137.103:/home/redis

 
 
1
2
3

102，103的redis目录如下，说明copy成功

3、配置master和slave关系，有如下俩种方式

a) 在redis.conf中设置slaveof,永久性

slaveof <masterip> <masterport>
 
 
1

b)使用redis-cli客户端设置redis服务，暂时，redis重启失效

slaveof <masterip> <masterport>
 
 
1

在102和103的conf/redis.conf的配置文件配置为101的slave关系

master的密码可以直接在配置文件里面配置

4、查看设置情况，使用如下命令

info replication
 
 
1

101的主从关系，可以看slaves的连接数还有ip地址，端口

102，103的主从关系,可以看master]的ip地址，端口

若发现配置没有问题，但是master_link_status一直是down，connected_slaves一直是0，查找下，是不是三个ip之间不能拼通，如果能拼通，查看下端口是否能拼通，可以在windows上通过telnet

telnet 192.168.137.101 6379
 
 
1

如果发现不能拼通，修改下配置文件，将

bind 127.0.0.1
 
 
1

注释掉，重启服务，再试试，参考下http://blog.csdn.net/yingxiake/article/details/51472810

5、测试是否数据同步

在master设置一个key和value

在101和102上分别get数据

说明数据同步成功，接下来把102down掉，再重启，然后get数据

说明数据恢复成功，另外也说明在主从结构中，slave不能写数据

主从复制的步骤：

1、从服务器开始链接主服务器时，会向主服务器发送一个 SYNC 命令 
2、主服务接收到命令之后，执行 BGSAVE，异步的将写命令保存到一个缓冲区里面 
3、主服务器执行完BGSAVE之后，就.rdb 文件(BOF的持久化文件)发送给从服务器，从服务器从该文件恢复数据到内存中 
4、主服务器还会以 Redis 命令协议的格式， 将写命令缓冲区中积累的所有内容都发送给从服务器，从服务器通过执行命令将数据恢复到内存中

原文地址：

http://blog.csdn.net/heiyueya/article/details/69501361

http://blog.csdn.net/yingxiake/article/details/51669030