tcp_max_syn_backlog控制处于半连接SYN_RECV状态的连接数量。
somaxconn控制处于全连接ESTABLISHED状态的连接数量
有关这两个参数可以参考这篇 文章 ，写的比较详细。
我们在使用的时候要知道，tcp-backlog和somaxconn这两者的最小值会起作用。我们把somaxconn调整为1024，然后看看实际效果。
tcp-backlog起作用了。
是否配置upstart或者systemd来管理Redis服务器
如果我们需要使用systemd来管理和使用Redis服务器，我们就将设置该参数为supervised systemd
然后，我们添加redisservice 到/etc/systemd/system下。编辑内容如下几可以了。
就可以实现systemd对 redis的管理。
这个backlog感觉更像是一个cache，复制节点断网后，在连接重新建立后，将这个backlog中的数据复制过去。也称为部分同步。
条件允许，可以定义大一些。没有坏处。
既然类似于cache，就有生存期
在使用NAT时候是，master和复制节点连接信息中的ip和port可能是经过NAT后的信息，我们这里使用该参数将真正的IP和PORT信息汇报给主节点
可以将一些重要系统命令，重新命名为不容易猜测的名字。
命令重命名后再同步到别的节点，可能会引起一些问题。
Redis默认删除时是处于一种阻塞状态，自从有了异步删除方式。我们现在可以配置不同情况下的删除方式
lazyfree-lazy-eviction:达到最大内存时
lazyfree-lazy-expire：过期时
lazyfree-lazy-server-del ：内部删除时
replica-lazy-flush no：复制节点执行全部同步时
同步刷新可能会带来阻塞的现象，没有其他任何办法。
通过启用本选项，在BGSAVE和BGREWRITEAOF过程中能禁止fsync的调用。
-配置AOFRewrite策略
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
这个配置表明aof增长了百分百，而且增长的大小超过了64mb，就启动bgrewriteaof。
-是否支持rdb和aof的混合持久化
启用rdb和aof的混合持久化后，aof文件跟在rdb后面，既能利用上rdb快速读取的优点，有能利用aof的安全持久能力。
如果在同一个系统中，这个配置文件不要重名RDB：Redis DataBase ， 记录快照
RDB是redis 默认的持久化方案 RDB 是当满足一定条件时, 就会将redis内存中的数据写入磁盘,并生成一个快照文件dumprdb 文件Redis 重启会通过加载dumprdb文件恢复数据
一定条件分为以下几种情况: 1自动触发 2 手动触发 下面分开说明下:
a)redisconf 中 SNAPSHOTTING 其中定义了触发把数据保存到磁盘的触发频率
如果不需要rdb 方案, 注释save 或者配置成空字符串" "
save 900 1 #900秒内至少有一个key被修改(包括添加)
save 300 10 #400秒内至少10个key被修改
save 10000 #60秒内至少有10000个key 被修改
这三条配置不冲突, 只要满足一条就触发
rdb 文件位置和目录 (默认在安装根目录下)
#文件路径
dir /
#文件名称
dbfilename dumprdb
#是否以LZY压缩rdb 文件
rdbcompression yes
#开启数据校验
rdbchecksum yes
b) shutdown触发 ,保证服务器正常关闭
c) flushall , rdb文件是空的, 会生成一个空的文件,所以这种情况也没有什么意义但需要知道,这种情况下
会触发生成rdb文件
Redis 提供了两条命令: save 和 bgsave
a) save 命令
save 在生成快照的时候会阻塞当前Redis 服务器,Redis不能处理其他命令如果内存数据较多,会造成
b)bgsave 命令
执行bgsave命令时, Redis会在后台进行异步快照 *** 作,快照同时还可以响应客户端请求
具体 *** 作
具体 *** 作:Redis进程会执行fork *** 作创建子进程(copy-on-write),RDB 持久化过程由子进程负载,完成后自动结束它不会记录fork之后产生的记录阻塞只发送在fork阶段,一般时间较短
一优势
1RDB是一个非常紧凑的文件,它保存了Redis在某个时间点上的数据集这种文件非常适合进行备份和
灾难恢复
2生成RDB文件的时候,redis主进程会fork()一个子进程来处理所有保存的工作,主进程不需要进行任何
IO *** 作
3RDB在恢复大数据集时的速度比AOF的恢复速度要快
二劣势
1)RDB 没办法做到实时持久化/妙级持久化因为bgsave每次运行都要执行fork创建子进程,频繁执行成本过高
2)在一定间隔时间做一次备份,所以如果Redis 以为down掉的话,就会丢失最后一次快照之后所有修改
(数据有丢失)
AOF：<Append Only File> ， 记录日志
Redis 默认不开启AOF采用日志的形式来记录每个写 *** 作,并追加到文件中开启后,执行更改Redis 命令时,就会把命令写入到AOF文件中
Redis 重启时会根据日志文件的内容把写指令从前往后执行一次以完成数据的恢复工作
#开关
appendonly no
#文件名
appendfilename "appendonlyaof"
由于 *** 作系统缓存机制,AOF数据并没有真正地写入硬盘,而是进入了系统的硬盘缓存什么时候
把缓冲区的内容写入到AOF文件中 由下面参数决定
appendfsync : 值: no \ always \everysec
no: 表示不执行fync, 由 *** 作系统保证数据同步到磁盘,速度最快,但是不安全
always:表示每次写入都执行fync,以保证数据同步到磁盘,效率很低
everysec:表示每秒执行以fync ,可能会导致丢失1s数据通常选择everysec,兼顾效率和安全性
因为AOF文件只有一个, 随着redis 不断进行,AOF 的文件会越来越大,文件越大, 文件占用服务器内存
以及AOF恢复要求时间越长
为了解决这个问题,可以使用bgwriteaof来重写那什么时候重写 又是怎样重写
一 什么时候重写
#重写触发机制
auto-aof-rewrite-percentage 100 默认值是100 当前aof 文件大小超过 上一次重写的aof文件大小百分之多少进行重写,即当aof文件增长到一定大小时,Redis能够调用bgwriteaof对日志文件进行重写当前aof文件大小是上次日志重写得到aof文件大小的二倍时, 自动启动新的日志重写过程
auto-aof-rewrite-min-size 默认是64M设置允许重写的最小aof文件大小,避免达到了约定百分比 但尺寸
仍然很小的情况还要重写
二 怎样重写
并不是对原文件进行重新整理,而是直接读取服务器上现有的键值对,然后用一条命令去代替之间记录这
个键值对的多条命令,生成一个新的文件后去替换原来的 AOF文件
看下面这两个参数:
no-appendfsync-on-rewrite
aof-load-truncated
AOF 数据恢复
重启Redis之后就会进行AOF文件恢复
AOF 的优势和劣势
优点:
1AOF 持久化的方法提供了多种的同步频率,即使使用默认的同步频率每秒同步一次,Redis最多也就丢失
1秒的数据
缺点:
1对于具有相同数据的Redis, AOF文件通常比RDF文件体积更大(RDB存的是数据快照)
2虽然AOF提供了多种同步的频率,默认的情况下,没秒同步一次的频率也具有较高的性能在高并发的情况下,RDB比AOF具有更好的性能
如果可以忍一小段时间数据的丢失,毫无疑问使用RDB 是最好的,定时生成RDB快照非常便于进行数据备份,而且RDB恢复数据集的速度也要比AOF恢复速度要快
否则就要使用AOF重写但是一般情况下建议不要单独使用某一种持久化机制,而是两种一起用
本文内容来自咕泡学院-青山老师,感谢青山老师!!
Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集
合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务器。
Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；也可以把每一次数据变化都写入到一个append
only
file(aof)里面(这称为“全持久化模式”)。
第一种方法filesnapshotting：默认redis是会以快照的形式将数据持久化到磁盘的（一个二进制文件，dumprdb，这个文件名字可以指定），在配置文件中的格式是：save
N
M表示在N秒之内，redis至少发生M次修改则redis抓快照到磁盘。当然我们也可以手动执行save或者bgsave（异步）做快照。
工作原理简单介绍一下：当redis需要做持久化时，redis会fork一个子进程；子进程将数据写到磁盘上一个临时RDB文件中；当子进程完成写临时文件后，将原来的RDB替换掉，这样的好处就是可以copy-on-write
还有一种持久化方法是Append-only：filesnapshotting方法在redis异常死掉时，最近的数据会丢失（丢失数据的多少视你save策略的配置），所以这是它最大的缺点，当业务量很大时，丢失的数据是很多的。Append-only方法可以做到全部数据不丢失，但redis的性能就要差些。AOF就可以做到全程持久化，只需要在配置文件中开启（默认是no），appendonly
yes开启AOF之后，redis每执行一个修改数据的命令，都会把它添加到aof文件中，当redis重启时，将会读取AOF文件进行“重放”以恢复到redis关闭前的最后时刻。
LOG
Rewriting随着
通常Redis将数据存储在内存中或虚拟内存中，但它提供了数据持久化功能可以把内存中的数据持久化到磁盘。持久化有什么好处呢？比如可以保证断电后数据不会丢失，升级服务器也会变得更加方便。
1RDB 持久化机制 ：是对 redis 数据执行周期性的持久化。
这种方式就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为 dumprdb。客户端也可以使用save或者bgsave命令通知redis做一次快照持久化。save *** 作是在主线程中保存快照的，由于redis是用一个主线程来处理所有客户端的请求，这种方式会阻塞所有客户端请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步增量数据。如果数据量大的话，写 *** 作会比较多，必然会引起大量的磁盘IO *** 作，可能会严重影响性能。
2AOF持久化机制 ：AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，在 redis 重启的时候，可以通过回放 AOF 日志中的写入指令来重新构建整个数据集。当然由于 *** 作系统会在内核中缓存write做的修改，所以可能不是立即写到磁盘上。这样的持久化还是有可能会丢失部分修改。不过我们可以通过配置文件告诉 redis我们想要通过fsync函数强制 *** 作系统写入到磁盘的时机。
appendonly yes //启用日志追加持久化方式
（1）appendfsync always //收到写命令就立即强制写入磁盘。最慢的，但是保证完全持久化，不推荐使用。
（2）appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐使用。
（3）appendfsync no //完全依赖 *** 作系统，性能最好,持久化没保证。
通过 RDB 或 AOF，都可以将 redis 内存中的数据持久化到磁盘上面来，然后可以将这些数据备份到别的地方去。
1RDB方式
优点：
缺点：
2AOF方式
优点:
缺点：
不要仅仅使用 RDB，因为那样会导致你丢失很多数据；也不要仅仅使用 AOF，因为那样有两个问题：第一，你通过 AOF 做冷备，没有 RDB 做冷备来的恢复速度更快；第二，RDB 每次简单粗暴生成数据快照，更加健壮，可以避免 AOF 这种复杂的备份和恢复机制的 bug；redis 支持同时开启开启两种持久化方式，我们可以综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。
出处： >一、目录
1、工具
2、安装tcl
3、安装单机版redis
4、把redis设置为daemon进程，每次系统启动，redis进程一起启动
5、安装redis cluster
二、工具
21、tcl861-srctargz
22、ruby-231targz
23、redis-411gem
24、redis-328targz
25、openssl-102rtargz
三、安装tcl（安装redis必须先要安装tcl）
31、把tcl861-srctargz通过WinSCP上传到虚拟机中的/usr/local目录下
四、安装单机版redis
41、把redis-328targz通过WinSCP上传到虚拟机中的/usr/local目录下
42、依次运行如下命令：
tar -zxvf redis-328targz 解压文件
cd redis-328
make && make test && make install
五、把redis设置为daemon进程，每次系统启动，redis进程一起启动
51、将redis的utils目录下的redis_init_script脚本拷贝到linux的/etc/initd目录中，将redis_init_script重命名为redis_6379，6379是我们希望这个redis实例监听的端口号
52、修改redis_6379脚本的第6行的REDISPORT，设置为相同的端口号（默认就是6379）
protected-mode no 取消保护模式，保护模式只能127001访问
daemonize yes 让redis以daemon进程运行
pidfile /var/run/redis_6379pid 设置redis的pid文件位置
bind 1921683110
port 6379 设置redis的监听端口号
dir /var/redis/6379 设置持久化文件的存储位置
logfile /var/log/redis/6379log 设置日志文件位置
56、启动redis，依次执行：
cd /etc/initd,
chmod 777 redis_6379，赋读写执行的权限（chmod -R 777 是递归把该目录下的所有文件和其子文件全部赋权限）
/redis_6379 start 启动
57、确认redis进程是否启动，ps -ef | grep redis
58、让redis跟随系统启动自动启动
59、重启系统，不手动启动redis，直接连接redis，可以连接上，表示配置成功
此时一个单机版的redis的生产环境已经搭建好了，每次服务器重启，redis都会自动的启动
六、安装redis cluster
（redis cluster集群，要求至少3个master，去组成一个高可用，健壮的分布式的集群，每个master都建议至少给一个slave，3个master，3个slave）
61、前提，我在其它机器上启动了六个redis（安装步骤都如下）
22、创建三个目录：
mkdir -p /etc/redis-cluster 存放集群配置信息，自动生成配置
mkdir -p /var/log/redis redis日志
mkdir -p /var/redis/7001 存放redis的rdb文件和aof文件
63、将redis的utils目录下的redis_init_script脚本拷贝到linux的/etc/initd目录中，将redis_init_script重命名为redis_7001，7001是我们希望这个redis实例监听的端口号,并修改redis_7001配置文件中的REDISPORT=7001
64、修改/etc/redis/7001conf中的部分配置为生产环境
65、完成了一个redis环境的配置，依次再配置其余五个，分别为7002、7003、7004、7005、7006，每个启动脚本内，都修改对应的端口号
66、启动6个redis实例
67、创建集群（需要安装ruby、rubygems）
上述命令在部分机器上是可以直接运行完成，成功安装的，但在部分机器上运行第三条命令时会提示ruby版本太低、openssl找不到的问题，下面依次解决这两个问题：
68、再次运行gem install redis命令，报出两个错误
69、再次运行gem install redis命令，报出一个错误
610、再次运行gem install redis命令，报出一个错误
611、再次运行gem install redis命令
[root@ceshi01 local]# gem install redis
Successfully installed redis-411
Parsing documentation for redis-411
Done installing documentation for redis after 1 seconds
WARNING: Unable to pull data from ' >先连上redis 后输入 config get appendonly 验证是否开启 aof 持久化
开启的结果为 yes，没有开启结果为 no
127001:6379> config get appendonly
1) "appendonly"
2) "yes"
两种方式解决：
1： 如果你发现在配置文件中直接修改不起作用，可以通过命令解决
127001:6379> config set appendonly yes // 对服务器的当前配置进行修改
OK
127001:6379> config rewrite // 将修改后的配置写入配置文件（不写断开连接后就会失效）
OK
2：你是不是发现有2个以 conf 结尾的文件，要改两个都改
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）