介绍

1.单机、单实例的持久化方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

rdb（relation-ship database）持久化：
默认redis会以一个rdb快照的形式，将一段时间内的数据持久化到硬盘，保存成一个dumpr.rdb二进制文件。
工作原理：当redis需要持久化时，redis会fork一个子进程，子进程将数据写到磁盘上临时一个RDB文件中。当子进程完成写临时文件后，将原来的RDB替换掉，这样的好处就是可以copy-on-write。

配置redis.conf:
save 900 1
save 300 10
save 60 10000

在900秒内，如果有一个key被修改，则会发起快照保存。300秒之内，如果超过10个key被修改，则会发起快照保存。在60秒内，如果1w个key被修改，则会发起快照保存。

aof（append-only file）持久化：
默认会以一个appendonly.aof追加进硬盘。

redis.conf默认配置:
appendfsync yes
appendfdync always
#每次有数据修改都会写入AOF
appendfsync everysec
#每秒同步一次，策略为AOF的缺省策略

1.string

• select db 选择数据库（0-20）
• set k v 设置一个数据
• set k1 v nx nx仅仅可以新建的时候进行插入数据
• set k2 v xx xx仅仅可以更新的时候进行更新数据
• mset k1 v1 k2 v2 可以进行设置多个值
• get k 返回一个v，没有返回nil
• mget k1 k2 k3 获取多个v
• getrange k start end 获取一个索引从start到end，双闭合的区间

1.问题

redis是单线程，单实例，为什么并发那么多，依旧很快呢？

回答：因为调用了系统内核的epoll

2.Linux的早期版本

Linux有Linux kernal，我们的客户端，进行连接，首先到达的是Linux kernal，在Linux的早期版本，只有read和write进行文件读写。我们使用一个线程/进程 进行调用read和write函数，那么将会返回一个文件描述符fd(file description)。我们开启线程/进程去调用read进行读取。因为socket在这个时期是blocking（阻塞的），遇到高并发，就会阻塞，也就是bio时期。

1.下载

1

wget http://download.redis.io/releases/redis-5.0.5.tar.gz

2.解压

1

tar -xf redis-5.0.5.tar.gz

1.磁盘时代

很久之前，我们的数据存储方式是磁盘存储，每个磁盘都有一个磁道。每个磁道有很多扇区，一个扇区接近512Byte。

磁盘的寻址速度是毫秒级的，带宽是GB/M的。内存是ns级的，带宽也比磁盘大上好几个数量级。总体来说，磁盘比内存在寻址上慢了接近10W倍。

在这段历史中，我们的面临的问题是，I/O问题。在读写文件时，我们常常面临很大的I/O成本问题。但是最初有个最初的解决方案是加一个buffer。

自定义消息通道

上篇文章我们提到了Sink和Source两个接口，这两个接口中分别定义了输入通道和输出通道，而Processor通过继承Source和Sink，同时具有输入通道和输出通道。这里我们就模仿Sink和Source，来定义一个自己的消息通道。

首先我们定义一个接口叫做MySink，如下：

1
2
3
4
5
6

public interface MySink {
    String INPUT = "mychannel";

    @Input(INPUT)
    SubscribableChannel input();
}

创建工程

首先我们创建一个普通的Spring Boot工程，名为stream-hello，然后添加如下依赖：

1
2
3
4
5
6
7
8

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-stream-rabbit</artifactId>
</dependency>

结合RabbitMQ，可以实现配置文件动态刷新。我们先来看下面一张架构图：

整张图的工作流程我们之前也详细的说过，当我的微服务A/微服务B启动的时候，会从Config-Server中加载配置文件，而Config-Server则会通过git clone命令将配置中心的配置文件先clone下来在本地保存一份，然后再返回给微服务A/微服务B。
这是我们之前的工作流程，现在我们结合Spring Cloud Bus来实现配置文件的动态更新。使用Spring Cloud Bus来实现配置文件的动态更新原理很简单，如上图，当我的配置文件更新后，我向Config-Server中发送一个/bus/refresh请求，Config-Server收到这个请求之后，会将这个请求广播出去，这样所有的微服务就都收到这个请求了，微服务收到这个请求之后就会自动去更新自己的配置文件。在这个系统中，从RabbitMQ的角度来看，所有的微服务都是一样的，所以这个/bus/refresh请求我们也可以在微服务节点上发出，一样能够实现配置文件动态更新的效果，但是这样做就破坏了我们微服务的结构，使得微服务节点之间有了区别，所以刷新配置的请求我们还是放在Config-Server上来做比较合适，好了，下面我们就来看看如何实现这一需求。

Arrays

Arrays 是针对数组进行操作的工具类。

常用成员方法

1
2
3

public static String toString(int[] a) //把数组转成字符串
public static void sort(int[] a) //对数组进行排序
public static int binarySearch(int[] a,int key) //二分查找

Kafka下载

Kafka现在是Apache上的开源项目，直接到官网下载即可(http://kafka.apache.org/)，这个不用我多说。

启动

下载成功之后，是一个压缩文件，解压该文件，我们可以看到一个bin目录，进入到bin目录中，bin目录下的.sh文件都是Linux/Unix下的shell脚本，在Linux/Unix环境下直接运行这些脚本即可，bin目录中还有一个windows目录，该目录下存储的都是windows中的批处理文件。我们在运行时根据自己的操作系统选择合适的命令去执行，本文以windows为例。解压后为了后面的命令操作方便，我将windows文件配置到环境变量中，我的是D:\Program\kafka_2.11-0.11.0.1\bin\windows,然后在cmd中进入到解压目录下，执行zookeeper-server-start.bat .\config\zookeeper.properties命令，表示启动zookeeper（由于Kafka依赖的zookeeper，所以我们要先启动zookeeper再启动Kafka），如下：