1、redis服务配置文件详解
bind 0.0.0.0 #监听地址，可以用空格隔开后多个监听IP
protected-mode yes #redis3.2之后加入的新特性，在没有设置bind IP和密码的时候,redis只允许访问127.0.0.1:6379，可以远程连接，但当访问将提示警告信息并拒绝远程访问
port 6379 #监听端口,默认6379/tcp
tcp-backlog 511 #三次握手的时候server端收到client ack确认号之后的队列值，即全连接队列长度
timeout 0 #客户端和Redis服务端的连接超时时间，默认是0，表示永不超时
tcp-keepalive 300 #tcp 会话保持时间300s
daemonize no #默认no,即直接运行redis-server程序时,不作为守护进程运行，而是以前台方式运行， 如果想在后台运行需改成yes,当redis作为守护进程运行的时候，它会写一个 pid 到
/var/run/redis.pid 文件
supervised no #和OS相关参数，可设置通过upstart和systemd管理Redis守护进程，centos7后都使用systemd
pidfile /var/run/redis_6379.pid #pid文件路径,可以修改为/apps/redis/run/redis_6379.pid
loglevel notice #日志级别
logfile "/path/redis.log" #日志路径,示例:logfile "/apps/redis/log/redis_6379.log"
rdbcompression yes #持久化到RDB文件时，是否压缩，"yes"为压缩，"no"则反之
rdbchecksum yes #是否对备份文件开启RC64校验，默认是开启
dbfilename dump.rdb #快照文件名
dir ./ #快照文件保存路径，示例：dir "/apps/redis/data"
主从复制相关
replicaof <masterip> <masterport> #指定复制的master主机地址和端口，5.0版之前的指令为slaveof
# masterauth <master-password> #指定复制的master主机的密码
replica-serve-stale-data yes #当从库同主库失去连接或者复制正在进行，从机库有两种运行方式： 1、设置为yes(默认设置)，从库会继续响应客户端的读请求，此为建议值
2、设置为no，除去特定命令外的任何请求都会返回一个错误"SYNC with master in progress"。
replica-read-only yes #是否设置从库只读，建议值为yes,否则主库同步从库时可能会覆盖数据，造成数据丢失
repl-diskless-sync no #是否使用socket方式复制数据(无盘同步)，新slave第一次连接master时需要做数据的全量同步，redis server就要从内存dump出新的RDB文件，然后从master传到slave，有两种方式把RDB文件传输给客户端：
1、基于硬盘（disk-backed）：为no时，master创建一个新进程dump生成RDB磁盘文件，RDB完成之后由 父进程（即主进程）将RDB文件发送给slaves，此为默认值
2、基于socket（diskless）：master创建一个新进程直接dump RDB至slave的网络socket，不经过主进程和硬盘
#推荐使用基于硬盘（为no），是因为RDB文件创建后，可以同时传输给更多的slave，但是基于socket(为yes)， 新slave连接到master之后得逐个同步数据。只有当磁盘I/O较慢且网络较快时，可用diskless(yes),否则一般建议使用磁盘(no)
repl-diskless-sync-delay 5 #diskless时复制的服务器等待的延迟时间，设置0为关闭，在延迟时间内到达的客户端，会一起通过diskless方式同步数据，但是一旦复制开始，master节点不会再接收新slave 的复制请求，直到下一次同步开始才再接收新请求。即无法为延迟时间后到达的新副本提供服务，新副本将排 队等待下一次RDB传输，因此服务器会等待一段时间才能让更多副本到达。推荐值：30-60
repl-ping-replica-period 10 #slave根据master指定的时间进行周期性的PING master,用于监测master状态,默认10s
repl-timeout 60 #复制连接的超时时间，需要大于repl-ping-slave-period，否则会经常报超时repl-disable-tcp-nodelay no #是否在slave套接字发送SYNC之后禁用 TCP_NODELAY，如果选
择"yes"，Redis将合并多个报文为一个大的报文，从而使用更少数量的包向slaves发送数据，但是将使数 据传输到slave上有延迟，Linux内核的默认配置会达到40毫秒，如果 "no" ，数据传输到slave的延迟将会减少，但要使用更多的带宽
repl-backlog-size 512mb #复制缓冲区内存大小，当slave断开连接一段时间后，该缓冲区会累积复制副本数据，因此当slave 重新连接时，通常不需要完全重新同步，只需传递在副本中的断开连接后没有同步的部分数据即可。只有在至少有一个slave连接之后才分配此内存空间,建议建立主从时此值要调大一些或在 低峰期配置,否则会导致同步到slave失败
repl-backlog-ttl 3600 #多长时间内master没有slave连接，就清空backlog缓冲区
replica-priority 100 #当master不可用，哨兵Sentinel会根据slave的优先级选举一个master，此值最低的slave会优先当选master，而配置成0，永远不会被选举，一般多个slave都设为一样的值，让其自 动选择
min-replicas-to-write 3 #至少有3个可连接的slave，mater才接受写操作
#min-replicas-max-lag 10 #和上面至少3个slave的ping延迟不能超过10秒，否则master也将停止写操作
requirepass foobared #设置redis连接密码，之后需要AUTH pass,如果有特殊符号，用" "引起来。
2、RDB、AOF详解及优缺点总结
RDB的优缺点：
优点：
RDB快照保存了某个时间点的数据，可以通过脚本执行redis指令bgsave(非阻塞，后台执行)或者
save(会阻塞写操作,不推荐)命令自定义时间点备份，可以保留多个备份，当出现问题可以恢复到不 同时间点的版本,很适合备份,并且此文件格式也支持有不少第三方工具可以进行后续的数据分析
比如: 可以在最近的24小时内，每小时备份一次RDB文件，并且在每个月的每一天，也备份一个
ROB文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。
RDB可以最大化Redis的性能，父进程在保存 RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘工/0操作。
RDB在大量数据,比如几个G的数据，恢复的速度比AOF的快
缺点：
不能实时保存数据，可能会丢失自上一次执行RDB备份到当前的内存数据
如果你需要尽量避免在服务器故障时丢失数据，那么RDB不适合你。虽然Redis允许你设置不同的 保存点（save point）来控制保存RDB文件的频率，但是，因为ROB文件需要保存整个数据集的状态，所以它并不是一个轻松的操作。因此你可能会至少5分钟才保存一次RDB文件。在这种情况下，一旦发生故障停机，你就可能会丢失好几分钟的数据。
当数据量非常大的时候，从父进程fork子进程进行保存至RDB文件时需要一点时间，可能是毫秒或 者秒，取决于磁盘IO性能
在数据集比较庞大时，fork()可能会非常耗时，造成服务器在一定时间内停止处理客户端﹔如果数 据集非常巨大，并且CPU时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒或更久。 虽然 AOF重写也需要进行fork()，但无论AOF重写的执行间隔有多长，数据的持久性都不会有任何损失。
AOF的优缺点
AOF的优点：
1，数据安全性相对较高，根据所使用的fsync策略(fsync是同步内存中redis所有已经修改的文件到存 储设备)，默认是appendfsync everysec，即每秒执行一次 fsync,在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据( fsync会在后台线程执行，所以主线程可以继续努力地处理命令请求)
由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中不需要seek, 即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果本次操作只是写入了一半数据就出 现了系统崩溃问题，不用担心，在Redis下一次启动之前，可以通过 redis-check-aof 工具来解决数据一致性的问题
2，Redis可以在 AOF文件体积变得过大时，自动地在后台对AOF进行重写,重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为Redis在创建新 AOF文件的过程中，append模式不断的将修改数据追加到现有的 AOF文件里面，即使重写过程中发生停机，现有的 AOF文件也不会丢失。而一旦新AOF文件创建完毕，Redis就会从旧AOF文件切换到新AOF文件，并开始对新AOF文件进行追加操作。
3，AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，也可以通过该文 件完成数据的重建AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因 此 AOF文件的内容非常容易被人读懂，对文件进行分析(parse)也很轻松。导出（export)AOF文件也非常简单:举个例子，如果你不小心执行了FLUSHALL.命令，但只要AOF文件未被重写，那么只 要停止服务器，移除 AOF文件末尾的FLUSHAL命令，并重启Redis ,就可以将数据集恢复到FLUSHALL执行之前的状态。
AOF的缺点：
缺点：
即使有些操作是重复的也会全部记录，AOF 的文件大小要大于 RDB 格式的文件
AOF 在恢复大数据集时的速度比 RDB 的恢复速度要慢
根据fsync策略不同,AOF速度可能会慢于RDB
bug 出现的可能性更多
3，Redis Cluster扩、缩容
动态扩容：
扩容一定要先做数据备份 做这个有很大的风险数据丢失
redis 集群运行之后，难免由于硬件故障、网络规划、业务增长等原因对已有集群进行相应的调整， 比如: 增加Redis node节点、减少节点、节点迁移、更换服务器等。增加节点和删除节点会涉及到已有的槽位重新分配及数据迁移。
注意: 生产环境一般建议master节点为奇数个,比如:3,5,7,以防止脑裂现象
增加Redis node节点，需要与之前的Redis node版本相同、配置一致，然后分别再启动两台Redis node，应为一主一从
Redis 5 添加方式
redis-cli -a 123456 --cluster add-node 10.0.0.68:6379 <当前任意集群节点>:6379
redis-cli -a 123 --cluster add-node 10.0.0.27:6379 10.0.0.22:6379
命令用法是前一个是新家的节点的ip 后面要跟上在集群中的任何一个ip都可以。
加了之后默认的是主节点 ，并且没有槽位
意思就是要从每个槽位点在取一部分分给新家的主节点
16384/4 =4096 5461-4096=1365 要从每个节点中取1365节点分给新家的主节点。
添加槽位的命令：
redis-trib.rb check 10.0.0.67:6379 #当前状态
redis-trib.rb reshard <任意节点>:6379 #重新分片 --老版本
redis-trib.rb fix 10.0.0.67:6379 #如果迁移失败使用此命令修复集群
redis-cli -a 123456 --cluster reshard <当前任意集群节点>:6379 ---redis5使用这个命令
这里要写要分配的全部槽位 ，然后可以设置 all系统自动从每个节点拿
也可以写一个节点就从一个节点拿 但是要写节点的id 就是nodes那个号
扩容一定要先做数据备份 做这个有很大的风险数据丢失
检查：
redis-cli -a 123456 --cluster check 10.0.0.8:6379
然后添加新的主节点的从节点：
为新的master添加新的slave节点
需要再向当前的Redis集群中添加一个Redis单机服务器10.0.0.78，用于解决当前10.0.0.68单机的潜在 宕机问题，即实现响应的高可用功能，有两种方式：
redis-cli -a 123456 --cluster add-node 10.0.0.78:6379 <任意集群节点>:6379 -- cluster-slave --cluster-master-id d6e2eca6b338b717923f64866bd31d42e52edc98
举例：
redis-cli -a 123456 --cluster check 10.0.0.22:6379
redis-cli -a 123 --cluster add-node 10.0.0.29:6379 10.0.0.22:6379 --cluster-slave --cluster-master-id d6e2eca6b338b717923f64866bd31d42e52edc98
就是在要加进来的id后面加上一个 任意集群内的ip和端口号 再跟上 这个从节点的主ID号
或者分两步做：先加进来在设置成从节点
redis-cli -a 123 --cluster add-node 10.0.0.29:6379 10.0.0.22:6379
然后进入新加入的redis：
redis-cli -h 10.0.0.29 -p 6379 -a 123
CLUSTER NODES #查看当前集群节点，找到目标master 的ID
CLUSTER REPLICATE 886338acd50c3015be68a760502b239f4509881c #将其
设置slave，命令格式为cluster replicate MASTERID
就成功了，在讲将数据导进去
动态缩容
电商因为临时要求增加服务器，如果大的并发一斤过去 可以缩减配置
添加节点的时候是先添加node节点到集群，然后分配槽位，删除节点的操作与添加节点的操作正好相 反，是先将被删除的Redis node上的槽位迁移到集群中的其他Redis node节点上，然后再将其删除， 如果一个Redis node节点上的槽位没有被完全迁移，删除该node的时候会提示有数据且无法删除。
先删除槽位：
查看状态：
redis-cli -a 123 --cluster check 10.0.0.22:6379 ---任意一个集群内的ip都行
redis-cli -a 123 --cluster reshard 10.0.0.22:6379 ---重新分配槽位--任意节点
要拿多少：3000
谁来接收
从哪拿
挪完可以删除了
确认10.0.0.24的所有slot都移走了，上面的slave也自动删除，成为其它master的slave
删除命令：
redis-cli -a 123 --cluster del-node 10.0.0.24:6379 869392a4ce0e4461fcd0db0f0f6a65d4264a458b
然后需要删除conf配置文件 要不启动又成了集群
删除从节点：25
redis-cli -a 123 --cluster del-node 10.0.0.25:6379 c771afac48f1c115a00adca92f294fe41e445b78
4，LVS调试算法总结
VS：
1、抗负载能力强。抗负载能力强、性能高，能达到F5硬件的60%；对内存和cpu资源消耗比较低
2、工作在网络4层，通过vrrp协议转发（仅作分发之用），具体的流量由linux内核处理，因此没有流量的产生。
2、稳定性、可靠性好，自身有完美的热备方案；（如：LVS+Keepalived）
3、应用范围比较广，可以对所有应用做负载均衡；
4、不支持正则处理，不能做动静分离。
5、支持负载均衡算法：rr（轮循）、wrr（带权轮循）、lc（最小连接）、wlc（权重最小连接）
6、配置 复杂，对网络依赖比较大，稳定性很高。
DR 模型的缺陷是不能更改端口 全部走的是4层 然后将这两个编程安全模式的方式是 将lvs的arp设置改成 不响应arp包
将两个真实的server的arp变成不发布。
lvs tun 模式：远程调度模式 适合大公司的远程调用 也有dr模式的不经过lvs返回的功能 给报文添加了一层头部 有一个tip 这个要给lvs的服务器上单独设置。
sh：对源ip进行hash算法 生成一个hash值 128位的二进制数字 而lvs会对这个hash值进行验证 同一个cip的hash值都会发往同一个rs，实现会话绑定。
dh：对目标的地址进行hash 首先 cip会对目的网站进行hash 然后相同的网站的缓存会在proxy上有一个存储区 这里会有很多网站的缓存 这里就能非常快速的访问 一个网站了 如果想要更快速的访问 可以在proxy中间和rs中间搭建很多的缓存服务器 这样即使在proxy中没有一个网站的信息 proxy也可以去后端的缓存服务器中查找 。因为目的网站的hash的值是唯一的 所以信息也是唯一的 可以设置缓存服务器的过期时间 。
动态有6种算法 ：
lc：是最小连接 算法 ，到哪个服务器的距离最短选哪个 overhead=活动链接*256+已经激活的连接 ：算法
wlc：加权重的lc算法 算出哪个值小 就选哪个 根据这个算法100*256/2是最小的 就选2 wight这个 。
这个算法的bug是在第一次连接的时候 2权重的会被选 这里的权重就没有意义了
SED:初始最短权重高的被选为初始 所以这个就是wlc的优化算法。bug是会导致权重高的 全部接受请求
NQ：第一次按照 rr算法来实现 第二次 按照SED来算
LBLC:正向的DH(静态算法) 会根据后端的缓存服务器的负载情况来 调度到其他服务器上
LBLCR:根据请求的类型来调度 会话 将一些需要大缓存和带宽的服务调度到负载轻的一些服务器上去
lblcr+lblc +dh+sh=一般运营商会用。
LVS的NAT、DR模型实现
DR模式;
在Real Server1 和Real Server2上做以下配置,
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
以上命令需填加到/etc/rc.local文件中让其开机自动生效
vim /etc/sysconfig/network-scripts/ifcfg-lo:0 内容如下
DEVICE=lo:0
IPADDR=10.0.0.1
NETMASK=255.255.255.255
BROADCAST=10.0.0.1
ONBOOT=yes
NAME=loopback
ifdown lo:0
ifup lo:0
route add -host 10.0.0.1 dev lo:0
echo "route add -host 10.0.0.1 dev lo:0" >> /etc/rc.local
2,在Director Server上做以下配置
vim /etc/sysconfig/network-scripts/ifcfg-eth0:0 内容如下
DEVICE=eth0:0
IPADDR=10.0.0.1
NETMASK=255.255.255.255
BROADCAST=10.0.0.1
ONBOOT=yes
ifdown eth0:0
ifup eth0:0
route add -host 10.0.0.1 dev eth0:0
echo "route add -host 10.0.0.1 dev eth0:0" >> /etc/rc/local
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "echo "1" > /proc/sys/net/ipv4/ip_forward" >> /etc/rc.local
ipvsadm -A -t 10.0.0.1:80 -s rr
ipvsadm -a -t 10.0.0.1:80 -r 20.0.0.2 -g
ipvsadm -a -t 10.0.0.1:80 -r 20.0.0.3 -g
NAT模型实现：
yum install -y httpd
Director 上安装 ipvsadm
yum install -y ipvsadm
echo 1 > /proc/sys/net/ipv4/ip_forward:打开核心转发
ipvsadm -A -t 192.168.1.29:80 -s wrr
ipvsadm -a -t 192.168.1.29:80 -r 192.168.100.2:80 -m
