redis数据怎么落地 redis写数据流程

Redis数据库

Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

首先我们来看一下数据库在进行写操作时到底做了哪些事，主要有下面五个过程： 
		客户端向服务端发送写操作（数据在客户端的内存中）。
		数据库服务端接收到写请求的数据（数据在服务端的内存中）。
		服务端调用write这个系统调用，将数据往磁盘上写（数据在系统内存的缓冲区中）。
		操作系统将缓冲区中的数据转移到磁盘控制器上（数据在磁盘缓存中）。
		磁盘控制器将数据写到磁盘的物理介质中（数据真正落到磁盘上）。

Redis	特点、优势
		k、v键值存储以及数据结构存储（如列表、字典）
		所有数据(包括数据的存储)操作均在内存中完成
		单线程服务(这意味着会有较多的阻塞情况)，采用epoll模型进行请求响应，对比nginx（高性能的HTTP和反向代理服务）
		支持主从复制模式，更提供高可用主从复制模式（哨兵）
		去中心化分布式集群
		丰富的编程接口支持，如Python、Golang、Java、php、Ruby、Lua、Node.js 
		功能丰富，除了支持多种数据结构之外，还支持事务、发布/订阅、消息队列等功能
		支持数据持久化(AOF、RDB)
			RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。
			AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。
				AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

memcache特点：
	memcache是一个分布式的内存对象缓存系统，并不提供持久存储功能，而redis拥有持久化功能
	memcache数据存储基于LRU(简单说：最近、最少使用key会被剔除)，而redis则可以永久保存(服务一直运行情况下)
		LRU：内存管理的一种页面置换算法,对于在内存中但又不用的数据块(内存块)叫做LRU
	memcache是多线程的（这是memcache优势之一），也就意味着阻塞情况少，而redis是单线程的，阻塞情况相对较多
	Redis和memcache两者性能上相差不大
	memcache只支持简单的k、v数据存储，而redis支持多种数据格式存储。
	memcache是多线程、非阻塞IO复用网络模型，而redis是单线程IO复用模型

CAP原则(CAP定理)、BASE理论
　　CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
　　CAP原则是NOSQL数据库的基石。Consistency（一致性）。 Availability（可用性）。Partition tolerance（分区容错性）。
			分布式系统的CAP理论：理论首先把分布式系统中的三个特性进行了如下归纳：
			一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
			可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
			分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
			
		NoSQL系统通常注重性能和扩展性，而非事务机制（事务就是强一致性的体现）。redis就是注重在性能上

RDB优势
	一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这样非常方便进行备份。比如你可能打算没1天归档一些数据。
	方便备份，我们可以很容易的将一个一个RDB文件移动到其他的存储介质上
	RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
	RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。
	
劣势
	如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。
	每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

AOF优势
	使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。							
	AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等）， redis-check-aof 工具也可以轻易地修复这种问题。
	Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。							
	AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。			
				
劣势
	对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。	
	根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。
	
	AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。） 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。

linux和windows安装

1. linux中安装

yum install gcc -y  #安装C依赖
wget http://download.redis.io/redis-stable.tar.gz  #下载稳定版本
tar zxvf redis-stable.tar.gz  #解压
cd redis-stable
make install     #或者指定路径    make PREFIX=/opt/app/redis install   #指定目录编译，也可以不用指定

------------手动进行其他配置
mkdir /etc/redis   #建立配置目录
cp redis.conf /etc/redis/6379.conf # 拷贝配置文件
cp utils/redis_init_script /etc/init.d/redis  #拷贝init启动脚本针对6.X系统
chmod a+x  /etc/init.d/redis  #添加执行权限
vi /etc/redis/6379.conf #修改配置文件： 
bind 0.0.0.0      #监听地址
maxmemory 4294967296   #限制最大内存（4G）：
daemonize yes   #后台运行

####启动与停止
/etc/init.d/redis start
/etc/init.d/redis stop

redis的使用
	1. 启动redis服务器
		编译安装
			找到项目目录的src文件夹
				./redis-server
		包管理器
			在任意的地方输入
				redis-server
		redis默认端口
			6379
	2. 链接redis
		1. 工具
			redis-cli
		2. 命令
			redis-cli
				redis-cli -h 127.0.0.1 -p6379  -a xxxx
				-h ip地址
				-p port 端口
					默认端口 6379
				-a 密码

2.windows中安装

windows版本的在github上手动下载，解压

https://github.com/MicrosoftArchive/redis/releases

下载解压后

redis-server.exe和redis-cli.exe两个文件启动即可

redis命令大全

官网：http://redisdoc.com/

redis缓存设置

官方文档：http://chibisov.github.io/drf-extensions/docs/#cacheresponsemixin

1.配置setting

#链接redis
#"LOCATION": "redis://127.0.0.1:6379/1",后面的1为使用redis使用的库，默认有十六个库（0-15）
CACHES = {
    "default": {
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379/1",			
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
        }
    }
}

#设置缓存失效时间，到点了就重新请求，保证数据实时更新性。
REST_FRAMEWORK_EXTENSIONS = {
    'DEFAULT_CACHE_RESPONSE_TIMEOUT': 60
}

2.模块应用

#views中

from rest_framework_extensions.cache.mixins import CacheResponseMixin   #导入CacheResponseMixin库，安装库pip3 install drf-extensions

class MovieInfoViewSet(CacheResponseMixin,ReadOnlyModelViewSet):      #CacheResponseMixin必须为第一个
    """
    #ReadOnlyModelViewSet里面包含了list，destroy,create
    list:
        这个接口是获取多条用户信息的
    destroy:
        这个接口是删除用户的,请慎重使用
    create:
        这个接口是创建用户的
    """
    queryset = User.objects.all()
    #serializer的作用是把object转换成json,object直接转json换转不了,
    #因为object 里面有function
    serializer_class = UserSerializer