希望长大对我而言，是可以做更多想做的事，而不是被迫做更多不想做的事...... 首页

商品详情页架构和Redis安装及持久化

丁D
学无止境
2019-05-27 18:30
2793已阅读

摘要本文介绍redis持久化的机制，和电商商品详情页的架构

1~13
1.小型电商企业和大型电商企业商品详情页的架构
小型的电商购物网站可以使用**页面静态化**
```js
//模板
<html>
	<title></title>
	<body>
		商品名称：#{productName}
		商品价格：#{productPrice}
		商品描述：#{productDesc}
	</body>
</html>
```

```js
//mysql中的数据
product表

product_name		product_price		product_desc

iphon7 plus			5599.50				这是最好的手机
```  
```js
//渲染成html  iphone7_plus.html
<html>
	<title>
		<style css>
		<javascript>
	</title>
	<body>
		商品名称：iphon7 plus（玫瑰）
		商品价格：5299.50	
		商品描述：这是最好的手机，大降价了
	</body>
</html>

```  
**将渲染后的html页面推送到nginx服务器。前端直接访问静态页面。
**
**这样做简单粗暴，性能高，没有逻辑，不用动态渲染**

可以在后台管理系统做一个按钮点击一下直接生成静态的html。。

缺点：**当数据变化的时候。对应的商品要重新生成静态的html页面**
最大的问题，当模板变化的时候所有的静态页面要重新生成，当商品数量很多的时候，要生成好久好久。很可怕。

大型的电商网站使用：**异步多级缓存+nginx数据本地动态渲染**

![alt](/upload/大型电商网站的详情页架构.png
)
假设有一个商品服务，和一个缓存生产服务

当商品服务中，商品数据变化的时候，发送一条消息到mq中。
缓存生产服务监听mq消息队列，监听到消息，经过业务逻辑计算，生成对应的模板数据缓存到缓存服务的ehcahe，redis，

将商品模板放在nginx服务器中，前端来访问的时候时时从redis中获取数据渲染中模板直接返回前端，没有逻辑计算。。redis的数据可以缓存到nginx中（10分钟），这样就不用每次都要redis中取，没有网络的开销。这样更快

**相比全量静态化的缺点就是要是时时将数据渲染到模板中。。。但是这样没有逻辑计算还是很快，性能也高
**
**redis与memcache**

redis支持k/v的存储还支持list set hash等数据结构，而memcache只支持k/v
redis支持rdb和aof持久化，memcache不支持持久化，断电就没了
redis在物理内存不足的时候，达到一定的阈值，会发生swap计算将部分的value存在磁盘中，存在磁盘的value会从内存移除，但是key是全部存在内存中的。而memcache key和value会全部存在内存中
redis扩展性好可以结合lua等

如果在不考虑扩展性和持久化的情况下。可以使用memcache

**redis事务**
https://www.cnblogs.com/DeepInThought/p/10720132.html

2.redis安装及企业的启动方式

**安装redis**
由于redis依赖 tcl所以先安装tcl

```js

//安装gcc
yum -y install gcc gcc-c++ kernel-devel

wget http://downloads.sourceforge.net/tcl/tcl8.6.1-src.tar.gz
tar -xzvf tcl8.6.1-src.tar.gz
cd  /usr/local/tcl8.6.1/unix/
./configure  
make && make install

使用redis-3.2.8.tar.gz（截止2017年4月的最新稳定版）
tar -zxvf redis-3.2.8.tar.gz
cd redis-3.2.8
make && make test && make install
 
将 redis/src目录下的redis-cli和redis-server复制到/usr/local/bin

```  
**生产环境的启动方式，**
要把redis作为一个系统的daemon进程去运行的，每次系统启动，redis进程一起启动

（1）redis utils目录下，有个redis_init_script脚本
（2）将redis_init_script脚本拷贝到linux的/etc/init.d目录中，将redis_init_script重命名为redis_6379，6379是我们希望这个redis实例监听的端口号
（3）修改redis_6379脚本的第6行的REDISPORT，设置为相同的端口号（默认就是6379）
（4）创建两个目录：/etc/redis（存放redis的配置文件），/var/redis/6379（存放redis的持久化文件）
（5）修改redis配置文件（默认在根目录下，redis.conf），拷贝到/etc/redis目、录中，修改名称为6379.conf

（6）修改redis.conf中的部分配置为生产环境

daemonize	yes							让redis以daemon进程运行
pidfile		/var/run/redis_6379.pid 	设置redis的pid文件位置
logfile      /var/redis/redis6379.log
port		6379						设置redis的监听端口号
dir 		/var/redis/6379				设置持久化文件的存储位置

（7）启动redis，执行cd /etc/init.d, chmod 777 redis_6379，./redis_6379 start

（8）确认redis进程是否启动，ps -ef | grep redis

（9）让redis跟随系统启动自动启动

在redis_6379脚本中，最上面，加入两行注释

“# chkconfig:   2345 90 10”
“# description:  Redis is a persistent key-value database”

在执行chkconfig redis_6379 on命令

**redis-cli**
redis-cli命令默认连接到127.0.0.1  6379
指定连接的ip和端口
redis-cli -h 127.0.0.1 -p 6379

SHUTDOWN关闭redis进程
3.redis持久化 aof和rbd 及容灾练习

redis的持久化有两种aof和rbd
rbd是默认开启的  aof要手动开启

rdb是对redis内存数据执行周期性的持久化，是某一时刻的快照。

aof是将每条写命令当中日志，记录到日志文件中。

**如果我们想要redis仅仅作为纯内存的缓存来用，那么可以禁止RDB和AOF所有的持久化机制**

两种持久化的优缺点
rdb适合做冷备份。使用rdb来恢复数据，更加快速
在生成rdb文件的时候 redis还是可以对外提供读写服务的，，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可（fork子进程的时候不行，所以可能停顿一会儿ms级或s级）

rdb是定时生成的，比如每隔5分钟生成，，这种可能当redis宕机的时候最长丢失5分钟的数据

aof
（1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据

AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。（在fork子进程的时候不能提供读写）

对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大

AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的

怎么选择aof或者rdb

如果我们想要redis仅仅作为纯内存的缓存来用，那么可以禁止RDB和AOF所有的持久化机制

建议 同时开启aof和rdb
aof每秒写一次

**配置RDB**
save 60 1000
每隔60s，如果有超过1000个key发生了变更，那么就生成一个新的dump.rdb文件,可以配置多个

**2、RDB持久化机制的工作流程**

（1）redis根据配置自己尝试去生成rdb快照文件
（2）fork一个子进程出来
（3）子进程尝试将数据dump到临时的rdb快照文件中
（4）完成rdb快照文件的生成之后，就替换之前的旧的快照文件

dump.rdb，每次生成一个新的快照，都会覆盖之前的老快照

**aof配置**

**1、AOF持久化的配置**

AOF持久化，默认是关闭的，默认是打开RDB持久化

appendonly yes，可以打开AOF持久化机制，在生产环境里面，一般来说AOF都是要打开的，除非你说随便丢个几分钟的数据也无所谓

打开AOF持久化机制之后，redis每次接收到一条写命令，就会写入日志文件中，当然是先写入os cache的，然后每隔一定时间再fsync一下

而且即使AOF和RDB都开启了，redis重启的时候，也是优先通过AOF进行数据恢复的，因为aof数据比较完整

可以配置AOF的fsync策略，有三种策略可以选择，一种是每次写入一条数据就执行一次fsync; 一种是每隔一秒执行一次fsync; 一种是不主动执行fsync

always: 每次写入一条数据，立即将这个数据对应的写日志fsync到磁盘上去，性能非常非常差，吞吐量很低; 确保说redis里的数据一条都不丢，那就只能这样了

mysql -> 内存策略，大量磁盘，QPS到多少，一两k。QPS，每秒钟的请求数量
redis -> 内存，磁盘持久化，QPS到多少，单机，一般来说，上万QPS没问题

everysec: 每秒将os cache中的数据fsync到磁盘，这个最常用的，生产环境一般都这么配置，性能很高，QPS还是可以上万的

no: 仅仅redis负责将数据写入os cache就撒手不管了，然后后面os自己会时不时有自己的策略将数据刷入磁盘，不可控了

------------------------------------------------------------------------------
**
2、AOF持久化的数据恢复实验**

（1）先仅仅打开RDB，写入一些数据，然后kill -9杀掉redis进程，接着重启redis，发现数据没了，因为RDB快照还没生成
（2）打开AOF的开关，启用AOF持久化
（3）写入一些数据，观察AOF文件中的日志内容

其实你在appendonly.aof文件中，可以看到刚写的日志，它们其实就是先写入os cache的，然后1秒后才fsync到磁盘中，只有fsync到磁盘中了，才是安全的，要不然光是在os cache中，机器只要重启，就什么都没了

（4）kill -9杀掉redis进程，重新启动redis进程，发现数据被恢复回来了，就是从AOF文件中恢复回来的

redis进程启动的时候，直接就会从appendonly.aof中加载所有的日志，把内存中的数据恢复回来

------------------------------------------------------------------------------

**3、AOF rewrite**

redis中的数据其实有限的，很多数据可能会自动过期，可能会被用户删除，可能会被redis用缓存清除的算法清理掉

redis中的数据会不断淘汰掉旧的，就一部分常用的数据会被自动保留在redis内存中

所以可能很多之前的已经被清理掉的数据，对应的写日志还停留在AOF中，AOF日志文件就一个，会不断的膨胀，到很大很大

所以AOF会自动在后台每隔一定时间做rewrite操作，比如日志里已经存放了针对100w数据的写日志了; redis内存只剩下10万; 基于内存中当前的10万数据构建一套最新的日志，到AOF中; 覆盖之前的老日志; 确保AOF日志文件不会过大，保持跟redis内存数据量一致

redis 2.4之前，还需要手动，开发一些脚本，crontab，通过BGREWRITEAOF命令去执行AOF rewrite，但是redis 2.4之后，会自动进行rewrite操作

在redis.conf中，可以配置rewrite策略

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

比如说上一次AOF rewrite之后，是128mb

然后就会接着128mb继续写AOF的日志，如果发现增长的比例，超过了之前的100%，256mb，就可能会去触发一次rewrite

但是此时还要去跟min-size，64mb去比较，256mb > 64mb，才会去触发rewrite

（1）redis fork一个子进程
（2）子进程基于当前内存中的数据，构建日志，开始往一个新的临时的AOF文件中写入日志
（3）redis主进程，接收到client新的写操作之后，在内存中写入日志，同时新的日志也继续写入旧的AOF文件
（4）子进程写完新的日志文件之后，redis主进程将内存中的新日志再次追加到新的AOF文件中
（5）用新的日志文件替换掉旧的日志文件

###redis的LRU淘汰策略

redis的内存是有限的，然而我们一直往redis中写数据，所以就需要有一定的策略，来淘汰缓存。**redis默认是使用LRU算法**

LRU：是最近最少使用

在redis.conf配置，主要下面3个参数
**maxmemory**：设置redis用来存放数据的最大的内存大小，一旦超出这个内存大小之后，就会立即使用LRU算法清理掉部分数据
**maxmemory-policy**
（1）noeviction: 如果内存使用达到了maxmemory，client还要继续写入数据，那么就直接报错给客户端
（2）allkeys-lru: 就是我们常说的LRU算法，移除掉最近最少使用的那些keys对应的数据
（3）volatile-lru: 也是采取LRU算法，但是仅仅针对那些设置了指定存活时间（TTL）的key才会清理掉
（4）allkeys-random: 随机选择一些key来删除掉
（5）volatile-random: 随机选择一些设置了TTL的key来删除掉
（6）volatile-ttl: 移除掉部分keys，选择那些TTL时间比较短的keys

**最常用的是allkeys-lru**，其他的都是乱78遭的，知道就好

**maxmemory-samples**
redis LRU算法，是采样之后再做LRU清理的，跟真正的、传统、全量的LRU算法是不太一样的
maxmemory-samples，比如5，可以设置采样的大小，如果设置为10，那么效果会更好，不过也会耗费更多的CPU资源

###一些坑

1。当只配置rdb 没有启用aof，是不会使用aof来恢复数据的
2。当启动rdb和aof，优先使用aof来恢复。即使没有aof日志文件，也会自己生成一个aof文件
这样就会导致rdb和aof的数据全部丢失

**例如 同时开启了 rdb和aof，。。。然后想要使用rdb文件来恢复数据，没有aof日志文件**

这时候 就会出来redis自己生成一个aof（空的），来恢复，这样就导致redis启动后，还是没有数据，连同rdb的数据都被覆盖了。。

**怎么处理。。**
1.我们应该在启动redis前，关闭aof这样就会使用rdb来恢复。。。然后使用热修改来启用aof，这样就有aof文件了。。。但是这时候启用的aof是临时了，不是永久了的

2.这时候我们可以停止redis，然后修改配置文件开启aof（永久了），然后使用上个步骤生成aof日志来恢复

上一篇：Redis读写分离和分布式缓存算法原理

下一篇：redis cluster