以后会每天更新 更新内容大多是分布式博客。
感觉不错的加我java群 群号是:369784068
1.redis持久化机制
1.1 rdb持久化
在指定的时间间隔内将内存中的数据集快照写入磁盘
redis.conf文件中如下配置是rdb持久化
save 900 1
save 300 10
save 60 10000 rdb 保存的dump.rdb文件
rdb优势:只包含一个文件
灾难恢复是好的选择(单独的文件拷贝到别的存储)
只fork出子进程,子进程完成持久化避免服务进程执行IO,能够达到性能最大化
与aof相比,数据集大,启动效率高。
rdb劣势:
数据可能丢失
数据集较大,fork子进程可能会导致服务器停止几百毫秒,甚至1秒
1.2 aof持久化
以日志的形式来记录每个写操作,redis启动之初会读取该文件重新构建数据
保证数据的完整性
redis.conf文件中
appendonly yes (默认是no改成yes就打开了aof持久化)
appendonly.aof文件
aof优势:
3种同步策略 每秒同步、每修改同步、不同步
appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差
# appendfsync everysec 异步操作,每秒记录 如果一秒内宕机,有数据丢失
# appendfsync no 从不同步
带来更高的数据安全
对日志文件的操作是append模式的,写入过程中即使宕机,也不会破坏日志文件
已经存在的内容,如果写一半出现宕机,redis在下次启动之前,做一个redis-check-aof工作即可,使得数据一致
rewrite机制。
aof日志文件清晰、易懂
aof劣势:相同数据集的数据而言aof文件要远大于rdb文件
aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同
1.3 无持久化
1.4 同时使用rdb和aof方式
如果只打开rdb,启动时通过rdb重建数据
如果只打开aof,启动时通过aof重建数据
如果既打开了rdb又打开了aof,通过aof重建数据
redis-cli -a pwd bgsave
redis-cli -a pwd bgrewriteaof
通过命令显示启动rdb记录 aof记录
2.redis 复制流程
2.1 slaveof指令可以配置方式也可以是命令方式,slave端有定时器触发事件连接master,
发送sync命令,阻塞等待master发送其内存快照(新版不用阻塞)
2.2master端收到sync命令,判断是否有子进程做内存快照,有等待其完成,没有立即
开始内存快照,快照完成后,将该文件发送给slave端
2.3slave接收到内存快照,保存到本地.接收完,清空内存,重新读取发来的
内存快照,重新建立整个内存数据
2.4此时master如果有修改更新,暂时先发送到缓存队列,等slave快照完成后,依次
再发给slave.
3.复制缺陷
无增量复制概念,每次重新连接都要取master全部内存快照,并清空数据,重新内存数据
redis集群需要主从复制,最好事先配置好所有的从库,避免中途再去增加从库
redis持久化机制还不是特别成熟 Cache/Store
4.在实际应用中redis复制机制、影响效率
解决方案:自己完成增量同步的工作
首先写redis 的aof文件,并对这个文件按文件的大小进行自动分割回滚。
同时关闭redis的rewrite命令,然后会在业务低峰时间进行内存快照存储,
并把当前的AOF文件位置一起写入到快照文件中,这样我们可以是快照文件
和aof文件的位置保持一致性。这样我们就得到了系统某一时刻的内存快照,
并且同时你也知道了这一时刻对应的AOF文件的位置,当从库发送同步命令
的时候,首先会把快照文件发送给从库,然后从库会去取出快照文件存储
的AOF文件位置,并将该位置发给主库,主库随后发送该位置之后的所有命令,
以后的复制就都是这个位置之后的增量信息了。
也有一些中间件,专门来解决这个问题。Twitter专门开发了一个用于复制
和分区的中间件gizzard(主动复制避开redis复制缺陷)