rdb

前言 日常的开发中，无不都是使用数据库来进行数据的存储，由于一般的系统任务中通常不会存在高并发的情况，所以这样看起来并没有什么问题。 一旦涉及大数据量的需求，如一些商品抢购的情景，或者主页访问量瞬间较大的时候，单一使用数据库来保存数据的系统会因为面向磁盘，磁盘读/写速度问题有严重的性能弊端，详细的磁盘读写原理请参考这一片 在这一瞬间成千上万的请求到来，需要系统在极短的时间内完成成千上万次的读/写操作，这个时候往往不是数据库能够承受的，极其容易造成数据库系统瘫痪，最终导致服务宕机的严重生产问题。 为了克服上述的问题，项目通常会引入NoSQL技术，这是一种基于内存的数据库，并且提供一定的持久化功能。 Redis 技术就是 NoSQL 技术中的一种。 Redis 缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。 但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。如果对数据的一致性要求很高，那么就不能使用缓存。 另外的一些典型问题就是，缓存穿透、缓存击穿和缓存雪崩。本篇文章从实际代码操作，来提出解决这三个缓存问题的方案，毕竟Redis的缓存问题是实际面试中高频问点，理论和实操要兼得。 缓存穿透 缓存穿透是指查询一条数据库和缓存都没有的一条数据，就会一直查询数据库，对数据库的访问压力就会增大，缓存穿透的解决方案，有以下两种：

前言 我们都知道，Redis和Memcached都是内存数据库，它们的访问速度非常之快。但我们在开发过程中，这两个内存数据库，我们到底要如何选择呢？它们的优劣都有哪些？ 为什么现在看Redis要比Memcached更火一些？ 这篇文章，我们就从各个方面来对比这两个内存数据库的差异，方便你在使用时，做出最符合业务需要的选择。 要分析它们的区别，主要从以下几个方面对比： 线程模型 数据结构 淘汰策略 管道与事务 持久化 高可用 集群化 线程模型 要说性能，必须要分析它们的服务模型。 Memcached处理请求采用多线程模型，并且基于IO多路复用技术，主线程接收到请求后，分发给子线程处理。 这样做好的好处是，当某个请求处理比较耗时，不会影响到其他请求的处理。 当然，缺点是CPU的多线程切换必然存在性能损耗，同时，多线程在访问共享资源时必然要加锁，也会在一定程度上降低性能。 Redis同样采用IO多路复用技术，但它处理请求采用是单线程模型，从接收请求到处理数据都在一个线程中完成。 这意味着使用Redis，一旦某个请求处理耗时比较长，那么整个Redis就会阻塞住，直到这个请求处理完成后返回，才能处理下一个请求，使用Redis时一定要避免复杂的耗时操作。 单线程的好处是，少了CPU的上下文切换损耗，没有了多线程访问资源的锁竞争，但缺点是无法利用CPU多核的性能。 由于Redis是内存数据库

目录 一、持久化 二、RDB持久化方式 2.1 手动触发 2.2 RDB持久化命令 2.3 恢复和异常流程演示 2.4 RDB持久化的优缺点 三、AOF持久化 3.1 AOF持久化原理 3.2 AOF持久化配置 3.3 AOF持久化恢复 四、Redis持久化加载机制顺序 一、持久化 我们前两章已经讲了，redis是内存型的数据库，他之所以快是因为数据存储在内存。那么数据存储在内存会有什么问题呢？当然就是当服务重启或者服务器宕机内存数据就被清除，我们就无法访问之前存储的数据了。那么怎么解决这个问题呢？当然就是使用持久化技术 持久化 （Persistence），即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。持久化是将程序数据在持久状态和瞬时状态间转换的机制。比如JDBC就是一种持久化机制。文件IO也是一种持久化机制。 redis也是一个支持持久化的内存数据库,也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化 ，持久化可以避免因进程退出而造成数据丢失； redis支持两种持久化方式， RDB 和 AOF 二、RDB持久化方式 RDB 持久化把当前进程数据生成快照（ .rdb ）文件保存到硬盘的过程，有 手动触发 和 自动触发 2.1 手动触发 手动触发有 save 和 bgsave 两命令 save 命令 ：阻塞当前 Redis ，直到 RDB

今天主要聊聊Redis持久化的问题 废话不多说直接开始 概述 Redis的高性能是由于其将所有数据都存储在了内存中，为了使Redis在重启之后仍能保证数据不丢失，需要将数据从内存中同步到硬盘中，这一过程就是持久化。 Redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。可以单独使用其中一种或将二者结合使用。 下面针对这两种方式来介绍一下。由浅入深。 持久化流程 既然redis的数据可以保存在磁盘上，那么这个流程是什么样的呢？ 要有下面五个过程： （1）客户端向服务端发送写操作(数据在客户端的内存中)。 （2）数据库服务端接收到写请求的数据(数据在服务端的内存中)。 （3）服务端调用write这个系统调用，将数据往磁盘上写(数据在系统内存的缓冲区中)。 （4）操作系统将缓冲区中的数据转移到磁盘控制器上(数据在磁盘缓存中)。 （5）磁盘控制器将数据写到磁盘的物理介质中(数据真正落到磁盘上)。 这5个过程是在理想条件下一个正常的保存流程，但是在大多数情况下，我们的机器等等都会有各种各样的故障，这里划分了两种情况： （1）Redis数据库发生故障，只要在上面的第三步执行完毕，那么就可以持久化保存，剩下的两步由操作系统替我们完成。 （2）操作系统发生故障，必须上面5步都完成才可以。 在这里只考虑了保存的过程可能发生的故障，其实保存的数据也有可能发生损坏，需要一定的恢复机制

Redis Nosql ​ 现在是大数据时代，一般的关系型数据库无法快速处理那么大的访问量。 为什么使用Nosql 单机Mysql时代 ​ 那时候更多使用静态网页Html，访问量不会很大，单个数据库已经足够。 这样的模式存在什么问题？ 数据量如果太大，一台服务器放不下 数据的索引(B+Tree)，一台服务器也放不下 读写混合，一台服务器无法承受 Memcached(缓存) + MySQL + 垂直拆分 ​ 实际场景80%都是进行查询的操作，每次都去查数据库效率很低。所以我们希望使用缓存减轻数据库压力。 ​ 发展历程：优化数据结构和索引——》文件缓存(IO)——》Memcached 分库分表 + 水平拆分 + MySQL集群 ​ 以前使用MylSAM ： 表锁 查一行数据锁住了整张表 高并发下有严重的问题 Innodb使用行锁解决 ​ MySQL在那个时代推出了表分区，但是使用的不多。 ​ 集群在这时已经能满足大部分需求。 大数据时代 ​ 2010-2020发生了翻天覆地的变化，各种实时变化的数据。 ​ MySQL等关系型数据库的弊端就暴露了，无法应付这种场景。 为什么要用NoSQL ​ 用户的每天生成的个人信息，社交网络，地理位置等等以PB计，呈爆发式增长。 ​ NoSQL非常适合应对这种场景。 什么是NoSQL ​ NoSQL = Not Only SQL 不仅仅是SQL

原文出处： Java 技术驿站 『 chenssy 』 Redis 提供了一个非常有用的查看状态信息的命令：info。它以一种易于理解和阅读的格式，返回关于 Redis 服务器的各种信息和统计数值。使用方法有如下三种： info：部分Redis系统状态统计信息。 info all：全部Redis系统状态统计信息。 info section：某一块的系统状态统计信息，其中section可以忽略大小写。 详细内容如下表格： 参数名 说明 server 获取 server 信息 clients 获取 clients 信息，如客户端连接数等 memory 获取 server 的内存信息，包括当前内存消耗、内存使用峰值 persistence 获取 server 的持久化配置信息 stats 获取 server 的一些基本统计信息，如处理过的连接数量等 replication 获取 server 的主从配置信息 cpu 获取 server 的 CPU 使用信息 keyspace 获取 server 中各个 DB 的 key 的数量 cluster 获取集群节点信息，仅在开启集群后可见 commandstas 获取每种命令的统计信息 其中 memory，stats，clients，keyspace 是 Redis 运行时经常要关注的信息。 server 获取 server 信息，包括

Redis NoSql入门和概述 入门概述 互联网时代背景下大机遇，为什么用nosql 1.单机MySQL的美好年代 在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付,在那个时候，更多的都是静态网页，动态交互类型的网站不多 上述架构下，我们来看看数据存储的瓶颈是什么？ 数据量的总大小 一个机器放不下时 数据的索引（B+ Tree）一个机器的内存放不下时 访问量(读写混合)一个实例不能承受 2.Memcached(缓存)＋MySQL＋垂直拆分 后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品 Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端 3

我是Redis，一个叫Antirez的男人把我带到了这个世界上。 “快醒醒！快醒醒！”，隐隐约约，我听到有人在叫我。 慢慢睁开眼睛，原来旁边是MySQL大哥。 “我怎么睡着了？” “嗨，你刚才是不是出现了错误，整个进程都崩溃了！害得一大堆查询请求都给我怼过来了！”，MySQL说到。 刚刚醒来，脑子还有点懵，MySQL大哥扶我起来继续工作。 “糟了！我之前缓存的数据全都不见了！” “WTF？你没有做持久化吗？”，MySQL大哥一听脸色都变了。 我尴尬的摇了摇头，“我都是保存在内存中的，所以才那么快啊” “那也可以在硬盘上保存一下啊，遇到这种情况全部从头再来建立缓存，这不浪费时间嘛！” 我点了点头，“让我琢磨一下，看看怎么做这个持久化”。 RDB持久化 没几天，我就拿出了一套方案：RDB 既然我的数据都在内存中存放着，最简单的就是遍历一遍把它们全都写入文件中。 为了节约空间，我定义了一个二进制的格式，把数据一条一条码在一起，生成了一个RDB文件 不过我的数据量有点大，要是全部备份一次得花不少时间，所以不能太频繁的去做这事，要不然我不用干正事了，光花时间去备份了。 还有啊，要是一直没有写入操作，都是读取操作，那我也不用重复备份，浪费时间。 思来想去，我决定提供一个配置参数，既可以支持周期性备份，也可以避免做无用功。 就像这样： save 900 1 # 900秒（15分钟）内有1个写入

SQLite数据库 '增、删、改、查' 1. 数据库简介 数据库指的是以一定方式存储在一起，能为多个用户共享，具有尽可能小的冗余度的特点，是与应用程序彼此独立的数据集合。 // 一定方式：可以理解为策略、算法 // 网盘相同的文件是以 MD5 码的形式标记相同的文件，以网络共享。 2. 和数据相关的术语 DBMS '数据库管理系统' DBA '数据库管理员' DB '数据库' RDB '关系型数据库' RDBMS '关系型数据库管理系统' 3. 数据分类 层次型数据库 - 有序二叉树，现在用的少 网络型数据库 - 网状结构，用的也少 关系型数据库 - '二维表格形式'，现在普遍使用的。 4. 常见数据库 商业数据库： - 甲骨文 Oracle , 市场占有率 50% - IBM DB2 , 市场占有率 20% - 微软 Sqlserver , 市场占有率 15% 非商业数据库： - Sun Mysql ---> 被Oracle收购，甲骨文旗下产品 - 开源SQLite，轻量级嵌入式领域关系型数据库 5. 数据库的操作语言 'SQL' 结构化查询语言 是一种特殊目的的编程语言，实现数据库的查询和程序设计，常用于关系型数据库系统，实现数据增、删、改、查等操作。 三、SQLite 数据库的操作 1. 安装 在线安装 $: sudo apt-get install sqlite3 离线安装

Redis构建简单的主从复制 原理： 当设置好slave服务器后，slave会建立和master的连接，然后发送sync命令。无论是第一次同步建立的连接还是连接断开后的重新连 接，master都会启动一个后台进程，将数据库快照保存到文件中，同时master主进程会开始收集新的写命令并缓存起来。后台进程完成写文件 后，master就发送文件给slave，slave将文件保存到磁盘上，然后加载到内存恢复数据库快照到slave上。 配置前提，关闭防火墙或允许redis端口通行 Centos7 IP:10.0.0.128（master） IP:10.0.0.129（slave） 主服务器配置： 下载安装包，解压并编译； [root@master ~]# cd /usr/local/src/ [root@master src]# wget [root@master src]# tar -zxvf redis-stable.tar.gz [root@master src]# mv redis-stable /usr/local/redis [root@master src]# cd /usr/local/redis/ [root@master redis]# make && make install copy配置文件redis.conf到/etc/目录下 [root@master redis]