此为龙果学院课程笔记，记录以供以后翻看

概述

本文系统讲解Redis缓存架构的核心技术，包括持久化配置、高可用方案和最佳实践。

上亿流量的商品详情页系统的多级缓存架构

很多人以为做个缓存其实就是用一下redis访问一下就可以了，这只是简单的缓存使用方式。做复杂的缓存，支撑电商等复杂的场景下的高并发的缓存，遇到的问题非常非常之多，绝对不是说简单的访问一下redis就可以了。

此为龙果学院课程笔记，记录以供以后翻看

Redis高可用集群实战

概述

本文系统讲解Redis缓存架构的核心技术，包括持久化配置、高可用方案和最佳实践。

如何做到99.99%高可用性

1. 什么叫99.99%的高可用性？

   在365天 * 99.99%的时间内，你的系统都是可以对外提供服务的，那就是高可用性，99.99%。

2. redis不可用是什么？单实例不可用？主从架构不可用？不可用的后果是什么？

   如果是master进程被杀了，或者系统宕机了，那就无法提供服务了。但是如果是集群中某一个slave挂掉了，没问题，还有其他的slave可以提供服务。

3. Redis怎么才能做到高可用？

   如果master挂了怎么办？Redis有个故障转移功能，如果master node故障时，自动检测，并且将某个slave node自动切换为master node，也可以叫做主备切换，这实现了redis主从架构下的高可用性，这其中会用到Redis的哨兵架构（它会去检测）。
   一旦master故障，在很短的时间内，就会切换到另外一个master上去，可能就几分钟，或者几秒钟是不可用的。

此为龙果学院课程笔记，记录以供以后翻看

Redis企业应用实战

上一篇说了redis的持久化的原理和操作，但是在企业中，持久化到底是怎么去用的呢？企业级的数据备份和各种灾难下的数据恢复，是怎么做的呢？

概述

本文系统讲解Redis缓存架构的核心技术，包括持久化配置、高可用方案和最佳实践。

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

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

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

1分内10000个key发生变更->生成RDB，1分内1000->RDB，这个根据应用和业务的数据量，自己去决定。

AOF一定要打开，fsync配置everysec

auto-aof-rewrite-percentage 100: 就是当前AOF大小膨胀到超过上次100%，上次的两倍就重写。
auto-aof-rewrite-min-size 64mb: 至少64m才重写，根据你的数据量来定，可改成16mb，32mb等等。

本文为龙果学院课程笔记，记录Redis持久化机制的详细说明。

概述

Redis作为内存数据库，持久化机制是保障数据安全的关键。本文将深入分析RDB和AOF两种持久化方式的工作原理、优缺点对比以及企业级应用的最佳实践。

Redis

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

Redis与其他key-value缓存产品有以下三个特点：

1. Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
2. Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
3. Redis支持数据的备份，即master-slave模式的数据备份。

分片

在Mongodb里面存在另一种集群，就是分片技术,可以满足MongoDB数据量大量增长的需求。

当MongoDB存储海量的数据时，一台机器可能不足以存储数据，也可能不足以提供可接受的读写吞吐量。这时，我们就可以通过在多台机器上分割数据，使得数据库系统能存储和处理更多的数据。

为什么使用分片

• 复制所有的写入操作到主节点
• 延迟的敏感数据会在主节点查询
• 单个副本集限制在12个节点
• 当请求量巨大时会出现内存不足。
• 本地磁盘不足
• 垂直扩展价格昂贵

副本集

MongoDB复制是将数据同步在多个服务器的过程。

复制提供了数据的冗余备份，并在多个服务器上存储数据副本，提高了数据的可用性， 并可以保证数据的安全性。

复制还允许您从硬件故障和服务中断中恢复数据。

什么是复制?

• 保障数据的安全性
• 数据高可用性 (24*7)
• 灾难恢复
• 无需停机维护（如备份，重建索引，压缩）
• 分布式读取数据

GridFS

https://docs.mongodb.com/manual/core/gridfs/index.html#use-gridfs

GridFS 用于存储和恢复那些超过16M（BSON文件限制）的文件(如：图片、音频、视频等)。

GridFS 也是文件存储的一种方式，但是它是存储在MonoDB的集合中。

GridFS 可以更好的存储大于16M的文件。

GridFS 会将大文件对象分割成多个小的chunk(文件片段),一般为256k/个,每个chunk将作为MongoDB的一个文档(document)被存储在chunks集合中。

GridFS 用两个集合来存储一个文件：fs.files与fs.chunks。

每个文件的实际内容被存在chunks(二进制数据)中,和文件有关的meta数据(filename,content_type,还有用户自定义的属性)将会被存在files集合中。

聚合

聚合通常在mysql中是group by，例如统计sum等操作，MongoDB也为我们提供了聚合操作，但是实现却不一样。

group()

这次需要的数据会比较多，这次直接用js来准数据。

1
2
3
4

for(var i = 1; i < 30; ++i ) {
    var count = i % 5;
    db.mygroup.insert({name: 'name' + i, count : count});
}

查询

MongoDB为我们提供了很强大的查询功能，之前演示的都比较简单，接下来将展示一些进阶用法。

数据准备

1
2
3
4

db.personalinfo.remove({});
db.personalinfo.save({name:'zhangsan',age:10});
db.personalinfo.save({name:'lisi',age:11});
db.personalinfo.save({name:'wangsu',age:12});

Netty处理器

编解码器本质上也是ChannelHandler的特殊实现，Netty本身为我们提供了很多处理器。

Netty处理器重要概念：

1. Netty的处理器可以分为两类：入站处理器与出站处理器。
2. 入站处理器的顶层是ChannelInboundHandler，出站处理器的顶层是ChannelOutboundHandler。
3. 数据处理时常用的各种编解码器本质上都是处理器。
4. 编解码器：无论我们向网络中写入的数据是什么类型（int、char、String、二进制等），数据在网络中传递时，其都是以字节流的形式呈现的；将数据由原本的形式转换为字节流的操作称为编码（encode），将数据由字节转换为它原本的格式或是其他格式的操作称为解码（decode），编解码统一称为codec。
5. 编码：本质上是一种出站处理器，因此，编码是一种ChannelOutboundHandler。
6. 解码：本质上是一种入站处理器，因此，解码是一种ChannelInboundHandler。
7. 在Netty中，编码器通常以XXXEncoder命名；解码器通常以XXXDecoder命名。