商品详情页系统架构-笔记3-企业级高可用

目录

企业级的数据备份和各种灾难下的数据恢复

redis如何通过读写分离来承载读请求QPS超过10万+

redis replication 以及master持久化对主从架构的安全意义

如何做到redis 99.99%的高可用

新老架构对比

hash算法 、一致性hash算法（memcached）、 redis cluster的hash slot算法

真正生成环境上，读写都是放在matser上的

Redis单机的内存不要太高（建议6-8G）

---

企业级的数据备份和各种灾难下的数据恢复

是怎么做得呢？

1、企业级的持久化的配置策略

在企业中，RDB的生成策略，用默认的也差不多

save 60 10000：如果你希望尽可能确保说，RDB最多丢1分钟的数据，那么尽量就是每隔1分钟都生成一个快照，低峰期，数据量很少，也没必要

10000->生成RDB，1000->RDB，这个根据你自己的应用和业务的数据量，你自己去决定

AOF一定要打开，fsync，everysec

auto-aof-rewrite-percentage 100: 就是当前AOF大小膨胀到超过上次100%，上次的两倍
auto-aof-rewrite-min-size 64mb: 根据你的数据量来定，16mb，32mb

2、企业级的数据备份方案

RDB非常适合做冷备，每次生成之后，就不会再有修改了

数据备份方案

（1）写crontab定时调度脚本去做数据备份
（2）每小时都copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份
（3）每天都保留一份当日的rdb的备份，到一个目录中去，仅仅保留最近1个月的备份
（4）每次copy备份的时候，都把太旧的备份给删了
（5）每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务上去

/usr/local/redis

每小时copy一次备份，删除48小时前的数据

crontab -e

0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh

redis_rdb_copy_hourly.sh

#!/bin/sh 

cur_date=`date +%Y%m%d%k`
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir /usr/local/redis/snapshotting/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date

del_date=`date -d -48hour +%Y%m%d%k`
rm -rf /usr/local/redis/snapshotting/$del_date

每天copy一次备份

crontab -e

0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh

redis_rdb_copy_daily.sh

#!/bin/sh 

cur_date=`date +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir /usr/local/redis/snapshotting/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date

del_date=`date -d -1month +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$del_date

每天一次将所有数据上传一次到远程的云服务器上去

 

3、数据恢复方案

（1）如果是redis进程挂掉，那么重启redis进程即可，直接基于AOF日志文件恢复数据

不演示了，在AOF数据恢复那一块，演示了，fsync everysec，最多就丢一秒的数

（2）如果是redis进程所在机器挂掉，那么重启机器后，尝试重启redis进程，尝试直接基于AOF日志文件进行数据恢复

AOF没有破损，也是可以直接基于AOF恢复的

AOF append-only，顺序写入，如果AOF文件破损，那么用redis-check-aof fix

（3）如果redis当前最新的AOF和RDB文件出现了丢失/损坏，那么可以尝试基于该机器上当前的某个最新的RDB数据副本进行数据恢复,cp dump.rdb /var/redis/6379 .

当前最新的AOF和RDB文件都出现了丢失/损坏到无法恢复，一般不是机器的故障，人为.

找到RDB最新的一份备份，小时级的备份可以了，小时级的肯定是最新的，copy到redis里面去，就可以恢复到某一个小时的数据.

appendonly.aof + dump.rdb，优先用appendonly.aof去恢复数据.

正确步骤：

停止redis ->  关闭aof ->拷贝rdb文件 -> 重启redis -> 确认数据恢复 -> 直接在命令行热修改redis配置  -> 打开aof

注：redis config set热修改配置参数，可能配置文件中的实际的参数没有被持久化的修改，再次停止redis，手动修改配置文件，打开aof的命令，再次重启redis

（4）如果当前机器上的所有RDB文件全部损坏，那么从远程的云服务上拉取最新的RDB快照回来恢复数据

（5）如果是发现有重大的数据错误，比如某个小时上线的程序一下子将数据全部污染了，数据全错了，那么可以选择某个更早的时间点，对数据进行恢复

举个例子，12点上线了代码，发现代码有bug，导致代码生成的所有的缓存数据，写入redis，全部错了。找到一份11点的rdb的冷备，然后按照上面的步骤，去恢复到11点的数据，就可以了。

redis如何通过读写分离来承载读请求QPS超过10万+

1、QPS 超过10W + 怎么做到的？

Mysql，高并发，做到了，那么也是通过一M系列复杂的分库分表，订单系统，事务要求的，QPS到几万，比较高了。

要做一些电商的商品详情页，真正的超高并发，QPS上十万，甚至是百万，一秒钟百万的请求量，光是redis是不够的，但是redis是整个大型的缓存架构中，支撑高并发的架构里面，非常重要的一个环节。

2、redis不能支撑高并发的瓶颈在哪里？

单机

3、如果redis要支撑超过10万+的并发，那应该怎么做？

读写分离

主从架构 -> 读写分离 -> 支撑10万+读QPS的架构

 

redis replication 以及master持久化对主从架构的安全意义

原理简单：master同步数据到slave。

如果采用了主从架构，那么建议必须开启master node的持久化！

 

redis 主从复制的断点续传

从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份 .

无磁盘化复制

master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了.

repl-diskless-sync
repl-diskless-sync-delay，等待一定时长再开始复制，因为要等更多slave重新连接过来.

过期key处理

slave不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。

redis 压测

redis自己提供的redis-benchmark压测工具，是最快捷最方便的，当然啦，这个工具比较简单，用一些简单的操作和场景去压测

 

如何做到redis 99.99%的高可用

 

（1）什么是99.99%高可用

（2）redis不可用

（3）redis基于哨兵模式的高可用

新老架构对比

老架构：

     

一个master,多个slave。

缺点：master节点的数据多大，那么slave数据就有多大，matser反而成了瓶颈。

新架构：

每个master挂载多个slave,写master,读slave,如其中一个master挂，其中一个slave成为master。

总结：

（1）基于redis cluster 搭建redis集群即可，不需要手动搭建replication。怎么搭建baidu即可。实现的功能是：

replication复制 + 主从架构 + 读写分离 + 哨兵集群 + 高可用

（2）redis cluster vs replication + sentinal

       数据不多用replication + sentinal

      海量数据用 redis cluster

 

hash算法 、一致性hash算法（memcached）、 redis cluster的hash slot算法

hash算法

取模。缺点：一个节点GG（比如3个），少数据，少不知1/3。实际接近100%数据失效。

一致性hash

key取模，看落在圆环的哪个部分。key落到圆环之后，顺时针寻找距离自己最近的一个节点。

 

 

当节点GG少1/3数据。

一致型Hash 实现负载均衡

hash slot算法

redis cluster有固定的16384个hash slot，对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot

redis cluster中每个master都会持有部分slot，比如有3个master，那么可能每个master持有5000多个hash slot

hash slot让node的增加和移除很简单，增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去

移动hash slot的成本是非常低的

客户端的api，可以对指定的数据，让他们走同一个hash slot，通过hash tag来实现

真正生成环境上，读写都是放在matser上的

redis cluster默认不支持slave节点的读写，跟我们手动搭建replication主从架构不一样。

只有slave node,readonly的时候get 才能读

 

Java Jedis对redis cluster读写支持不是太好，默认到matser上读写

如果用jedis做cluster 的读写的读写分离的话，可以自己写jedis源码，成本高。

或者redis cluster就没有读写分离之说，因为master是任意扩展的，对master直接扩容跟之前直接扩slave效果一样，不就是增加机器吗。

 

Redis单机的内存不要太高（建议6-8G）

不然fork操作很耗时