Hello 大家好，我是阿粉，前面有篇文章给大家介绍了动态规划，并通过两个案例给大家演示，后台很多小伙伴也提供了很多建议，没看过的小伙伴可以去看下什么是动态规划——从青蛙跳台阶开始了解。今天再给大家介绍两个案例，帮助大家更好的掌握也顺便回顾一下。

案例 1

问：给定一个包含非负整数的 m x n 网格，请找出一条从左上角到右下角的路径，使得路径上的数字总和为最小，其中 arr[m][n] 表示具体的值。每次只能向下或者向右移动一步。这个问题是上篇文章中的案例的进阶篇。

思考

根据上篇文章提供的思路，我们依次进行相关的步骤：

1. 定义变量：我们定义从左上角走到(i, j) 这个位置时，最小的路径和是 dp[i - ][j - 1]。那么，dp[m-1] [n-1] 就是我们要的答案；
2. 寻找关系：dp[i][j] = min(dp[i-1][j]，dp[i][j-1]) + arr[i][j]; arr[i][j] 表示网格中的数值，到达当前格子的最小路径等于左边或者上边中较小的路径加上格子本身的数值；
3. 定义初始值：dp[i][0] = dp[i-1][0] + arr[i][0];，dp[0][i] = dp[0][i-1] + arr[0][i];；第一行或者第一列的时候就是整行和整列的数值累加。

编码

上面的分析可以想到，那么接下来我们就需要用代码来实现了，对于需要使用到之前的记录，我们可以考虑用二维数组来记录，所以就有了下面的这段代码。

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

public int dp(int[][] arr) {
    int m = arr.length;
  	int n = arr[0].length;
    if (m <=0 || n <= 0) {
        return 0;
    }
    int[][] dp = new int[m][n];
    // 初始化
  	dp[0][0] = arr[0][0];
  	// 初始化最左边的列
  	for(int i = 1; i < m; i++){
      dp[i][0] = dp[i-1][0] + arr[i][0];
    }
  	// 初始化最上边的行
  	for(int i = 1; i < n; i++){
      dp[0][i] = dp[0][i-1] + arr[0][i];
    }
    
    for (int i = 1; i < m; i++) {
        for (int j = 1; j < n; j++) {
            dp[i][j] = Math.min(dp[i-1][j]，dp[i][j-1]) + arr[i][j];
        }
    }
    return dp[m - 1][n - 1];
}

解释下上面的代码，首先我们创建了一个二维数组 dp[m][n]，用于记录到达位置的最短路径，由于当前的路径是由左边或者上边的最小路径加上当前格子的数值得到。这里我们需要找到对应关系，也就是dp[i][j] = min(dp[i-1][j]，dp[i][j-1]) + arr[i][j]，这里我们需要取相邻的最小值再加上当前格子的数值。

案例 2

问：给定不同面额的硬币 coins 和一个总金额 amount。编写一个函数来计算可以凑成总金额所需的最少的硬币个数。如果没有任何一种硬币组合能组成总金额，返回 -1。你可以认为每种硬币的数量是无限的。 Leetcode 322. 零钱兑换。

思考

1. 定义变量：定义 dp[i] 表示凑成金额 i ，所需要的最少硬币个数，即 dp[amount] 则是我们需要求解的；
2. 寻找关系：假设我们有三种硬币a，b，c，兑换的金币数为 m，我们可以推出 dp[m] = min(dp[m - a], dp[m - b], dp[m - c]) + 1，因为如果我们是需要求 m 金额的最少硬币个数，如果我们求出了 m - a 金额需要的硬币个数，在加上一个 a 就可以得到 m，硬币个数只要加 1。其实 b，c 同理。并且我们需要取所有硬币种类的最小数。
3. 定义初始值：dp[0] = 0，没有金额当时也不需要硬币个数，dp[i - coins[j] 需要有解；

编码

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

public int dp(int[] coins, int amount) {

        int[] dp = new int[amount + 1];
        int size = coins.length;
        int i = 0;
        int j = 0;
  			# 定义初始值
        dp[0] = 0;
        for (i = 1; i <= amount; i++) {
            #赋值，当不能组合和输出 -1 判断使用
            dp[i] = Integer.MAX_VALUE;
          	# 遍历 coins 中的硬币种类
            for (j = 0; j < size; j++) {
                if (i >= coins[j] && (dp[i - coins[j]]) != Integer.MAX_VALUE) {
                    dp[i] = Math.min(dp[i - coins[j]] + 1, dp[i]);
                }
            }
        }
        if (dp[amount] == Integer.MAX_VALUE) {
            dp[amount] = -1 ;
        }
        return dp[amount];
    }

总结

动规划的题目在 LeetCode 上面有很多，大家可以根据上面提供的思路去多刷几道题，慢慢就会有感觉了，刷完动态规划的题目，相信对大家工作或者找工作肯定有很大的帮助。https://leetcode-cn.com/problemset/all/?topicSlugs=dynamic-programming

Hello 大家好，我是阿粉，动态规划（Dynamic Programming），简称 DP 相信大家在日常的工作或者学习的过程中都遇到过这个词，而且动态规划也是面试过程中最喜欢被问到的题目，阿粉在经历的不多的几场面试中都被问到了，实在是苦不堪言，不过好在阿粉还是有学过的，一些简单的套路阿粉还是懂的。下面就从一个很多人应该都不陌生的题目讲起。

案例 1

问：一只青蛙一次可以跳上 1 级台阶，也可以跳上 2 级，求该青蛙跳上一个 n 级的台阶总共有多少种跳法？

思考

刚开始看到这个题目的时候可能没什么思路，不过我们可以一点点的想下去，我们假设青蛙跳上一个 n 级的台阶总共有多少种跳法 f(n) 种跳法，那当 n = 0 时，f(0) = 0，没有台阶当然没有跳法。n = 1，f(1) = 1；只有一个台阶的时候，只能跳 1 个；n = 2，f(2) = 2，当有两个台阶的时候，可以有 2 种跳法，一个一个跳和一下跳 2 个，那如果我们有三个台阶的话，是不是将一个台阶和两个台阶的总和加起来就可以了呢？所以我们就可以想到 f(3) = f(2) + f(1)，所以我们能推导出 f(n) = f(n - 1) + f(n - 2);

编码

上面的分析可以想到，那么接下来我们就需要用代码来实现了，对于需要使用到之前的记录，我们可以考虑用一维数组来记录，所以就有了下面的这段代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public int dp(int n) {
    if (n <= 0) {
        return 0;
    }
    int[] dp = new int[n + 1];
    dp[0] = 0;
    dp[1] = 1;
    dp[2] = 2;
   // 之所以要从 3 开始，是因为 2 不符合下面的规则
    for (int i = 3; i <= n; i++) {
        dp[i] = dp[i - 1] + dp[i - 2];
    }
    return dp[n];
}

解释下上面的代码，首先我们创建了一个一维数组 dp，用于记录每个台阶有的跳法，然后从索引三开始遍历，运用公式f(n) = f(n - 1) + f(n - 2); 进行赋值，结果直接输出 dp[n] 对应的数值即可。

分析

通过上面的案例，我们思考一下对于动态规划的题目我们需要怎么做，我们一开始定义了 n 级台阶有 f(n) 种跳法，然后通过模拟的方式计算出 f(0),f(1),f(2)，接着我们找到了 f(n) = f(n - 1) + f(n - 2); 的关系。按照这种思路我们可以总结出三个步骤，分别是

1. 定义变量：把已知的和需要求解的，定义出变量，如上面的 n 和 f(n)；
2. 寻找表达式：找到 f(n) 和 f(n - 1) 以及 f(n - 2)，等情况的表达式，如上面的 f(n) = f(n - 1) + f(n - 2)，这一步往往是最难的；
3. 寻找初始值：确保找到所有的临界条件，如上面的 f(0) = 0, f(1) = 1, f(2) = 2；

上面的步骤是通用步骤，往往在第一步的时候我们设置的 f(n) 是一个数组，根据具体的场景可能是一维数组也有可能是二维数组，上面的例子我们定义的就是一维数组，而且往往我们需要求解什么就定义什么数组。

下面我们通过这种方式再看一道 LeetCode 的原题

案例 2

问：一个机器人位于一个 m x n 网格的左上角 （起始点在下图中标记为“Start” ）。机器人每次只能向下或者向右移动一步。机器人试图达到网格的右下角（在下图中标记为“Finish”）。问总共有多少条不同的路径？

根据上面的三个步骤，我们依次来解决，既然是 m x n 的网格，很显然我们需要用二维数组来解决问题，所以我们

1. 定义 d[m][n] 表示在 m x n 网格上移到右下角需要的总步数；
2. 因为机器人只能向右和向下移动，所以到达下一个格子只能是从左边或者上面，所以达到 m x n 的步数等于(m - 1) x n + m x (n - 1)，也就是 d[m][n] = d[m - 1][n] + d[m][n - 1]；
3. 定义初始值d[0][n] = 1，d[n][0] = 1，也就是只有一行或者一列的时候只有一种方法，全部向下或者向右移动；

编码

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

public int dp(int m, int n) {
    if (m <=0 || n <= 0) {
        return 0;
    }
    int[][] dp = new int[m][n];
    //只有一列的时候
    for (int i = 0; i < m; i++) {
        d[i][0] = 1;
    }
    //只有一行的时候
     for (int i = 0; i < n; i++) {
        d[0][i] = 1;
    }
   
    for (int i = 1; i < m; i++) {
        for (int j = 1; j < n; j++) {
            d[i][j] = d[i][j - 1] + d[i - 1][j];
        }
    }
    //数组的下标从 0 开始
    return d[m - 1][n - 1];
}

通过上面的三个步骤，我们可以完美的解决问题，动态规划的问题难点就在于找寻规律和初始值，有点时候如果我们找不到规律就没办法了，而且如果初始值找的不完全也会有问题，这个只能多多练习了。

总结

动规划的题目在 LeetCode 上面有很多，大家可以根据上面提供的思路去多刷几道题，慢慢就会有感觉了，刷完动态规划的题目，相信对大家工作或者找工作肯定有很大的帮助。

看完本文，你一定会有所收获

Hello 大家好，我是阿粉，前面的文章给大家介绍了一下如何在本地搭建微服务环境下的服务注册中心和配置管理中心 Nacos，今天通过

我们通过使用 SpringBoot 项目集成 Nacos 来给大家演示一下是如何使用 Nacos 来实现服务发现和配置管理的。

启动 Nacos 服务

启动完本地搭建的 Nacos 服务后，我们可以看到，目前的服务管理下面的服务列表里面在三个命名空间下都没有服务，这是正常的，因为目前我们还没有服务接入 Nacos。

Nacos 服务启动成功后，我们再创建两个 SpringBoot 项目，一个用于接入 Nacos 服务注册与发现和配置中心作为服务提供者 Producer，另一个只接入 Nacos的服务注册与发现，调用 Producer 获取配置中心的参数，我们叫做 Consumer。

服务提供者 Producer

1. 我们首先创建一个 SpringBoot 的项目，bootstrap.properties 文件内容如下：

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

   spring.application.name=producer #######################配置中心配置################################# # 指定的命名空间，只会在对应的命名空间下查找对应的配置文件 spring.cloud.nacos.config.namespace=caeser-adsys-naming spring.cloud.nacos.config.file-extension=properties # 配置的分组名称 spring.cloud.nacos.config.group=TEST1 # 配置文件，数组形式，可以多个，依次递增 spring.cloud.nacos.config.ext-config[0].data-id=com.example.properties spring.cloud.nacos.config.ext-config[0].group=TEST1 # 配置中心的地址 spring.cloud.nacos.config.server-addr=127.0.0.1:8848 #启用自动刷新对应的配置文件 spring.cloud.nacos.config.ext-config[0].refresh=true ######################服务注册发现配置################################## # 服务集群名称 spring.cloud.nacos.discovery.cluster-name=TEST1_GROUP # 服务注册中心的地址 spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848 # 服务的命名空间 spring.cloud.nacos.discovery.namespace=caeser-adsys-naming

2. application.properties 的文件内容如下，主要就是一个端口，其他配置根据情况自行添加或删除就好：

   1 2 3 4 5 6 7 8 9 10 11 12 13

   # 服务启动的端口 server.port=8080 spring.main.allow-bean-definition-overriding=true # tomcat 配置 server.tomcat.max-threads=500 spring.mvc.servlet.load-on-startup=1 spring.servlet.multipart.max-file-size=40MB spring.servlet.multipart.max-request-size=100MB # 日志配置 logging.level.root=info logging.level.com.alibaba=error logging.pattern.console=%clr{[%level]}{green} [%d{yyyy-MM-dd HH:mm:ss}] %clr{[${PID:-}]}{faint} %clr{[%thread]}{magenta} %clr{[%-40.40logger{80}:%line]}{cyan} %msg%n

3. 在启动类上面增加如下注解

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

   package com.ziyou.nacos.demo.producer; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cache.annotation.EnableCaching; import org.springframework.cloud.client.discovery.EnableDiscoveryClient; @SpringBootApplication(scanBasePackages = "com.ziyou.nacos") @EnableDiscoveryClient @EnableCaching public class ProducerApplication { public static void main(String[] args) { SpringApplication.run(ProducerApplication.class, args); } }

4. pom.xml 文件内容如下：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88

   <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.example</groupId> <artifactId>nacos-demo</artifactId> <version>1.0-SNAPSHOT</version> </parent> <artifactId>producer</artifactId> <version>1.0-SNAPSHOT</version> <name>producer Maven Webapp</name> <!-- FIXME change it to the project's website --> <url>http://www.example.com</url> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>1.7</maven.compiler.source> <maven.compiler.target>1.7</maven.compiler.target> <spring.maven.plugin.version>2.2.2.RELEASE</spring.maven.plugin.version> </properties> <dependencies> <!-- Spring Boot --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-logging</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-log4j2</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- nacos 配置中心 --> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> </dependency> <!-- nacos 注册发现 --> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> </dependency> </dependencies> <build> <!--指定下面的目录为资源文件--> <resources> <!--设置自动替换--> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> <includes> <include>**/**</include> </includes> </resource> </resources> <finalName>producer</finalName> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <version>${spring.maven.plugin.version}</version> <executions> <execution> <goals> <goal>repackage</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </project>

5. 在 Producer 侧提供一个获取配置里面内容的接口，代码如下：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

   package com.ziyou.nacos.demo.producer.controller; import com.ziyou.nacos.demo.producer.config.UserConfig; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; /** * <br> * <b>Function：</b><br> * <b>Author：</b>@author ziyou<br> * <b>Date：</b>2021-04-11 19:59<br> * <b>Desc：</b>无<br> */ @RestController @RequestMapping(value = "producer") public class ProducerController { private UserConfig userConfig; @GetMapping("/getUsername") private String getUsername() { String result = userConfig.getUsername() + "-" + userConfig.getPassword(); System.out.println(result); return result; } @Autowired public void setUserConfig(UserConfig userConfig) { this.userConfig = userConfig; } }

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

   package com.ziyou.nacos.demo.producer.config; import org.springframework.beans.factory.annotation.Value; import org.springframework.cloud.context.config.annotation.RefreshScope; import org.springframework.stereotype.Component; /** * <br> * <b>Function：</b><br> * <b>Author：</b>@author ziyou<br> * <b>Date：</b>2021-04-11 20:39<br> * <b>Desc：</b>无<br> */ @RefreshScope @Component public class UserConfig { @Value("${username}") private String username; @Value("${password}") private String password; public String getUsername() { return username; } public void setUsername(String username) { this.username = username; } public String getPassword() { return password; } public void setPassword(String password) { this.password = password; } }

6. 启动 Producer，并且手动调用接口，启动 Producer 过后，我们在 Nacos 的服务注册列表可以看如下所示的内容，在 test1 的命名空间下，已经有了我们创建的 Producer 服务。

   

7. 通过手动调用 Producer 的接口 http://127.0.0.1:8080/producer/getUsername 显示如下内容并且我们看下此时 Nacos 的配置中心里面配置文件com.example.properties 里面的内容正是这个，这个时候我们手动把配置里面password 参数的值改成JavaGeek666，再次访问接口，我们会发现接口的输出也自动改变了。

   

   修改配置内容如下：

   

   再次访问结果如下：

   

服务调用者 Consumer

前面我们已经完成了 Producer 的服务注册与配置动态生效的功能，这个时候基本已经可以使用了，不过我们还需要更进一步通过 Nacos 来实现服务发现，接下来我们创建 Consumer 的 SpringBoot 的项目，配置文件和pom.xml 文件基本一致，只要修改端口以及对应地方，下面贴一下不一样的地方

1. boostrap.properties 内容如下，因为这里我们只调用Producer 的接口，不需要接入 Nacos 的配置中心，所以这里只配置发服务注册与发现

   1 2 3 4 5 6

   spring.application.name=consumer ######################服务注册发现配置################################## spring.cloud.nacos.discovery.cluster-name=TEST1_GROUP spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848 spring.cloud.nacos.discovery.namespace=caeser-adsys-naming

2. 启动类，配置上 feignClient 需要扫描的包路径

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

   package com.ziyou.nacos.demo.consumer; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cache.annotation.EnableCaching; import org.springframework.cloud.openfeign.EnableFeignClients; /** * <br> * <b>Function：</b><br> * <b>Author：</b>@author ziyou<br> * <b>Date：</b>2021-04-11 17:07<br> * <b>Desc：</b>无<br> */ @SpringBootApplication(scanBasePackages = "com.ziyou.nacos") @EnableFeignClients(basePackages = {"com.ziyou.nacos.demo.consumer.rpc"}) @EnableCaching public class ConsumerApplication { public static void main(String[] args) { SpringApplication.run(ConsumerApplication.class, args); } }

3. 编写调用 Producer 的接口，FeignClient 里面的 value 就是 Producer 的应用名称

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

   package com.ziyou.nacos.demo.consumer.rpc; import org.springframework.cloud.openfeign.FeignClient; import org.springframework.stereotype.Component; import org.springframework.web.bind.annotation.GetMapping; /** * <br> * <b>Function：</b><br> * <b>Author：</b>@author ziyou<br> * <b>Date：</b>2021-04-11 20:01<br> * <b>Desc：</b>无<br> */ @FeignClient(value = "producer") @Component public interface IProducerFeign { /** * 获取生产者名称接口 * * @return */ @GetMapping("/producer/getUsername") String getUsername(); }

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

   package com.ziyou.nacos.demo.consumer.controller; import com.ziyou.nacos.demo.consumer.rpc.IProducerFeign; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; /** * <br> * <b>Function：</b><br> * <b>Author：</b>@author ziyou<br> * <b>Date：</b>2021-04-11 19:59<br> * <b>Desc：</b>无<br> */ @RestController @RequestMapping(value = "consumer") public class TestNacosController { private IProducerFeign iProducerFeign; @GetMapping("/testNacos") private String testNacos() { return iProducerFeign.getUsername(); } @Autowired public void setiProducerFeign(IProducerFeign iProducerFeign) { this.iProducerFeign = iProducerFeign; } }

4. 启动 Consumer，我们可以看到在 Nacos 如下图所示

5. 调用 Consumer 的接口consumer/testNacos，结果如下图所示，同样的如果此时更改了 Nacos 配置文件中的内容，Consumer 这边也是可以实时更新的，感兴趣的小伙伴可以自己试试。

   

今天主要给大家介绍了一下如何通过 SpringBoot 项目来接入 Naocs 实现服务注册与发现，以及配置管理和动态刷新，相关的代码已经上传到 GitHub 了，公众号回复【源码】获取地址。

看完本文，你一定会有所收获

看完本文，你一定会有所收获

Hello 大家好，我是阿粉，现如今微服务早就成为每个互联网公司必备的架构，在微服务中服务的注册发现和统一配置中心是不可或缺的重要角色。现有的服务注册中心主要有 ZooKeeper、Eureka、Consul ，Etcd、Nacos，而统一配置中心主要有 Apollo，Spring Cloud Config，Disconf，Nacos 可以看到服务注册中心和统一配置管理有很多，而且每一种都是网上比较流行的，使用人数也偏多，但是我们可以发现只有 Nacos 是集两者于一身的。这篇文章主要给大家介绍一下 Naocs 的基本信息以及安装步骤，后面的文章再带大家更深入的了解一下Nacos。

Nacos 是什么

打开网站 Nacos 的首页，我们可以看到下面的内容，写到 Nacos 是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

Nacos 致力于帮助我们发现、配置和管理微服务，提供了一组简单易用的特性集，帮助我们快速实现动态服务发现、服务配置、服务元数据及流量管理。

Nacos 本地搭建

Nacos 的安装可以通过安装包或者源码来时候，这里我们为了以后方便调试，所以选择采用源码来安装。

1. 第一步在 GitHub 上面下载源码，这里可以使用 HTTP 协议也可以使用 SSH，阿粉这里为了简单就直接采用 HTTP 协议来下载了：git clone https://github.com/alibaba/nacos.git；
2. 下载完成过后，我们使用 IDEA 的 File》Open 打开项目，如下图
3. 刚打开后我们会看到有很多个模块，从模块的命名我们大概可以猜到有些模块是干嘛的，比如有 auth 权限模块，config 配置模块等这篇文章我们主要看安装和使用，后面慢慢深入了解具体的细节。
4. 拉取下来过后，我们需要创建数据库，我们找到console 模块下的数据库脚本和配置文件，如下图，在 MySQL 数据库中创建一个名为nacos 的数据库，然后执行schema.sql 脚本，创建相应的表结构，同时在 application.properties 文件中找到对应配置数据源的地方，配置好账号密码。这里对于 MySQL 的数据库的搭建和创建不在这篇文章的讨论范围里面就不提了。
5. 配置好数据库过后，在控制台执行 mvn 命令 mvn -Prelease-nacos -Dmaven.test.skip=true -Drat.skip=true clean install -U，编译一下，然后执行 console 模块下面的 Nacos.java 中的 main 方法，启动后我们会看到下图，显示的是集群模式启动，因为我们是本地单机启动，所以可以增加一个 JVM 参数-Dnacos.standalone=true 来设置单机模式。按照下图设置好过后，重新启动即可。
6. 启动成功过后，我们可以访问地址http://127.0.0.1:8848/nacos ，我们可以看到如下页面，包含配置管理、服务管理、以及权限，命名空间和集群的管理。阿粉这里搭建的是最新的版本，旧版本是没有权限管理的。我们可以看到整个页面非常的简洁，其中配置管理服务管理基本上覆盖了我们常用的所有功能。

核心角色

上面我们已经搭建好了 Nacos 平台，现在给大家介绍一下，Nacos 的几个核心角色。

1. 命名空间Namespace ：用于进行租户粒度的配置隔离，不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离，例如开发测试环境和生产环境的资源（如配置、服务）隔离等。
2. 分组group：每个命名空间下还可以进行分组，相同集群的服务可以设置在同一个分组里面，如果没有手动指定默认分组为DEFAULT_GROUP
3. 配置集 Data ID：用于唯一区分不同配置文件，可以根据配置的信息不同，分别设置，比如可以单独配置 Redis 的配置文件，以及 MySQL 的配置文件，可以尽量细分复用，这样在有调整的时候只需要改一处即可。
4. 更详细的名词解释可以参考官网https://nacos.io/zh-cn/docs/concepts.html

使用

上面介绍了 Nacos 的本地搭建，搭建好了过后我们就可以使用了，因为 Nacos 不仅支持服务发现也支持统一配置管理，这篇文章我们先创建两个命名空间 test1 和 test2，然后分别添加两个配置文件com.example.properties 和com.example2.properties，创建的步骤比较简单。首先点击命名空间菜单，然后在右上角新增命名空间，接着输入相关信息就好了，这里新版本的 Nacos 支持手动填入命名空间的 ID，旧版本是不支持的，会随机生成一个字符串，这里建议手动填入具有含义的ID。

创建完命名空间过后，就可以在此命名空间下创建相应的配置文件了，这篇文章主要给大家介绍一下 Nacos 的本地部署过程以及简单的系统使用，后面的文章结合代码来实现一下服务的注册发现和配置的动态更新，敬请期待。

Hello 大家好，我是阿粉，关于 TCP 的三次握手和四次挥手相比大家早就烂熟于心了，毕竟这也是一个高频的面试题，但是很多小伙伴只是照本宣科，并没有真正的理解其中的原理，这篇文章，阿粉用通俗易懂的大白话带你们重新熟悉一下，已经掌握的小伙伴可以在回味一下，没有掌握的小伙伴刚好可以查漏补缺。

三次握手

再解释三次握手之前我们先从生活中想一个场景，假如你现在需要给领导打个电话汇报一下工作，为了保证双方能正常交流，那么在电话接通的那一刻想象一下会不会是这样的场景。

我们：领导好，我是 xx，可以听到我说话吗？有个工作需要向您汇报下。

领导：嗯，可以的，能听到我说话吧。

我们：可以。

我们：…..(汇报工作)。

通过上面的场景我们可以看出，其实跟 TCP 的三次握手是一个意思，只不过在我们日常生活中并不是每次都这么严谨，但是 TCP 不一样，TCP 是通过程序实现的，可靠的，面向连接的协议。而且程序是严谨的，每一次的建立连接都会进行这样的步骤。放一张经典的 TCP 三次握手图。

我们先用大白话解释一下为什么需要三次握手，首先我们要知道建立连接的目的是什么，我们是为了可靠的传输数据。那既然是可靠的传输数据，我们必须保证客户端和服务端都能正常的发送和接收数据，如果某一方不能正常的发送或者接收数据，那整个数据的传输就不能成功也就不可靠了。知道这个我们看下，为什么会需要三次握手，而不是两次握手。

1. 刚开始客户端和服务端都是处于关闭的状态，而且服务器 B 端一直处于监听的状态，时刻监听是否有建立连接的请求；
2. 当有客户端需要建立连接的时候就会发送一个确定连接的报文，此报文是同步报文SYN = 1，并且会生成一个随机的序号 seq = x，这是第一次握手；
3. 当服务端接收到请求连接报文的时候，会发送一个同步报文确认报文，此报文 SYN = 1，并且 ACK = 1，同时服务端也会随机生成一个 seq = y，并将 ack 设置成 x + 1，回传给客户端，这是第二次握手；
4. 当客户端接收到服务端的 ACK 报文后，会回复一个 ACK 确认报文，用于确认确认报文已经收到，此报文 ACK = 1，seq = x + 1, ack = y + 1，这是第三次握手；

这里有个点说明一下：大写的 ACK 表示报文的类型是确认报文，小写的 ack 是报文里面的确认号，这个确认号是上一次握手对方的 seq 值加 1 得到。

上面是整个三次握手的过程，现在我们分析一下为什么三次握手可以可靠的确定客户端和服务端都能支持的发送和接收数据。

第一次握手：第一次握手是客户端发送同步报文到服务端，这个时候客户端是知道自己具备发送数据的能力的，但是不知道服务端是否有接收和发送数据的能力；

第二次握手：当服务端接收到同步报文后，回复确认同步报文，此时服务端是知道客户端具有发送报文的能力，并且知道自己具有接收和发送数据的能力，但是并不知道客户端是否有接收数据的能力；

第三次握手：当客户端收到服务端的确认报文后，知道服务端具备接收和发送数据的能力，但是此时服务端并不知道自己具有接收的能力，所以还需要发送一个确认报文，告知服务端自己是具有接收能力的。

当整个三次握手结束过后，客户端和服务端都知道自己和对方具备发送和接收数据的能力，随后整个连接建立就完成了，可以进行后续数据的传输了。

看到这里，如果大家理解了就会知道很明显，两次握手是不行的，因为服务端并不知道客户端是具备接收数据的能力，所以就不能成为面向连接的可靠的传输协议。就像我们上面提到的打电话的例子，也是为了双方能够正常的进行交流，只不过我们现实生活中不会那么严谨，并不是每次都这样，但是程序是不一样的。

四次挥手

三次握手是为了建立可靠的数据传输通道，四次挥手则是为了保证等数据完成的被接收完再关闭连接。既然提到需要保证数据完整的传输完，那就需要保证双方都达到关闭连接的条件才能断开。

从上图中我们可以看到，

1. 客户端发起 FIN 断开连接的报文，携带随机生成的 seq 值 u，发送给服务端，并且自己处于 FIN-WSIT 状态，这是第一次挥手；
2. 服务端接收到 FIN 报文后，回复一个确认报文，其中 ACK = 1，随机生成一个 seq，以及 ack = u + 1，这是第二次挥手；
3. 当服务端数据发送完了过后，再发送一个 FIN 报文给客户端，通知客户端，服务端准备关闭连接了，此报文 FIN = 1，ACK = 1，ack = u + 1，seq = w，这是第三次挥手；
4. 当客户端收到 FIN 确认报文时再发送一个FIN 的确认报文，其中 ACK = 1，seq = u + 1，ack = w + 1，并进入 TIME-WAIT 状态，当等待 2MSL 后关闭连接，这是第四次挥手。

第一次挥手客户端发起关闭连接的请求给服务端；

第二次挥手：服务端收到关闭请求的时候可能这个时候数据还没发送完，所以服务端会先回复一个确认报文，表示自己知道客户端想要关闭连接了，但是因为数据还没传输完，所以还需要等待；

第三次挥手：当数据传输完了，服务端会主动发送一个 FIN 报文，告诉客户端，表示数据已经发送完了，服务端这边准备关闭连接了。

第四次挥手：当客户端收到服务端的 FIN 报文过后，会回复一个 ACK 报文，告诉服务端自己知道了，再等待一会就关闭连接。

疑问

1. 为什么握手要三次，挥手却要四次呢？

   那是因为握手的时候并没有数据传输，所以服务端的 SYN 和 ACK 报文可以一起发送，但是挥手的时候有数据在传输，所以 ACK 和 FIN 报文不能同时发送，需要分两步，所以会比握手多一步。

2. 为什么客户端在第四次挥手后还会等待 2MSL？

   等待 2MSL 是因为保证服务端接收到了 ACK 报文，因为网络是复杂了，很有可能 ACK 报文丢失了，如果服务端没接收到 ACK 报文的话，会重新发送 FIN 报文，只有当客户端等待了 2MSL 都没有收到重发的 FIN 报文时就表示服务端是正常收到了 ACK 报文，那么这个时候客户端就可以关闭了。

总结

TCP 协议是面向连接的可靠的传输层协议，它的拥塞控制，失败重传等机制在互联网数据传输中是不可或缺的。当下互联网行业中，基于 TCP 实现的程序数不胜数。对于我们程序员来说，很多时候如果不是参与底层项目的话，很少有机会会主动编写 TCP 相关的代码，但是理解 TCP 的实现原理，对我们来说是很有帮助的。

Hello 大家好，传说中的金三银四就在当下，阿粉知道很多小伙伴都在蠢蠢欲动，明修栈道暗度陈仓，表面上还在公司踏踏实实的干着，心里早就有了自己的小算盘。作为一个 Java 工程师，涉及到的领域会很多，每次面试都会被问到头破血流，阿粉今天就给大家带来一份面试题目，具体是哪家公司的阿粉就不说了，因为不管哪家其实都差不多，重点是自己要完全掌握，才能更好的应对。

技术细节

第一个部分我们先来看技术细节，往往很多公司的第一面都是考察技术细节的，小伙伴们如果在面试的过程中经常一面没有过的话，那往往是基础不扎实，这个时候我们就需要静下心来，好好的补一下基础知识，看看面经刷刷题，或者看看我们 Java 极客技术的文章都是可以的。

1. 三分钟自我介绍

   自我介绍这块是面试的一个开场白，这块没什么好说的，不过建议大家可以将自己想表述的内容以文字的形式写下来，然后熟练的背诵下来，这样不管是在电话面试，视频面试还是现场面试都能够流畅的有条理的表述出来。

2. 最熟悉的领域是什么？

   这个问题给大家一个忠告！千万别说自己不会的领域，不然整个面试还没开始就已经结束了，千万别为了表现，说自己什么领域都擅长，这样在被面试官问了几个问题都答不上来的话，那基本上就判了死刑了，而且整个印象都不会好，以后再想面试都很难了。所以这里我们实事求是就好，熟悉什么就说什么，不熟悉的就不说。

3. Redis 的常用数据类型有哪些？

   Redis 常用的五大数据类型，String，Hash，List，Set，Sorted Set。然后不要说完这几个类型就不说了，可以再扩展下，顺便可以说下每种数据类型在自己的项目里面是否有用到，具体使用在什么地方，为什么选用这种类型。面试的过程中虽然说是一问一答，但是也要适当的扩展一下，把自己知道的东西稍等多说一点，让面试官知道你是真正的了解。问你数据类型有哪些你就回答有这五个，这样的面试就比较枯燥，很难继续进展下去，给面试官的印象就不好。

4. Redis 的持久化了解吗？有几种方式，区别是什么？

   关于 Redis 的持久化，我们公众号之前有篇文章专门写了，大家可以看下面试官：请说下 Redis 是如何保证在宕机后数据不丢失的

5. Redis 的三种集群模式了解吗？

   关于 Redis 的集群模式不管自己有没有搭建过，都可以把自己知道的说出来，主从模式，哨兵模式，集群模式，以及三种模式的区别。

6. Redis 的主从数据是如何同步的？

   Redis 的主从数据同步跟上面的集群模式这两点都可以单独成一篇文章了，后期阿粉单独分享。

7. Redis 使用的场景？

   Redis 作为目前主流的缓存数据库，使用的场景有很多，用户 token 的存储，热点数据的存储，当成队列使用，分布式锁，计数器，布隆过滤器等等，结合自己项目中使用的场景可以跟面试官多聊一下。

8. Redis 为何性能如此高？

   Redis 官文号称最高 QPS 可以达到十万，那么问什么 Redis 可以有这么高的并发呢？主要是 Redis 采用多路复用 IO 模型，在处理命令的时候是采用单线程去处理的，同时 Redis 的底层采用 C 语言编写，数据结构也相对简单，所以才能如此快速。

9. MySQL 的存储引擎有哪些，InnoDB 和 MyISAM有什么区别？

   MySQL 常用的存储引擎主要有 InnoDB 和 MyISAM 以及 Memory，其中关于 InnoDB 和 MyISAM 的区别公众号前面有文章详细说过，感兴趣的小伙伴可以看一下面试必问的 MySQL 知识点，你还有哪些没准备好，赶紧收藏脑图！

10. 什么是事务？事务的隔离级别有哪些？为什么需要事务的隔离级别？

事务的内容在上面的文章里面也有详细说到，可以进去看下。

1. SQL 优化方面的内容？分库分表是怎么做的？

   关于 SQL 优化也是一个老生常谈的话题，在面试中也经常会被问到，关于 SQL 优化，有一篇文章很不错，推荐给大家，里面讲到了很多优化的点，认真记下来对我们很有帮助52条SQL语句性能优化策略，建议收藏

2. MySQL 的索引采用的是什么存储结构？为什么采用这个？

   MySQL 的索引也是一个面试中逃避不了的一个问题，详细的内容可以参考公号前面的文章为什么Mysql的常用引擎都默认使用B+树作为索引？

3. Java 中的线程池有哪些默认实现，几个核心参数是如何配合工作的？拒绝策略有哪些？

   Java 中的线程池有默认的实现，但是日常工作的时候我们一般都会手动创建线程池，具体的内容可以看文章面试官因为线程池，让我出门左拐！，聊聊面试中的 Java 线程池

4. Java 中 volatile, synchronized 的作用是什么？

   这两个关键词在 Java 中的重要性已经不言而喻了，不用阿粉在多说什么了，那对于这两个关键词小伙伴都理解了吗？同样的，我们前面也有写过，诡异的并发之可见性

5. 什么是类加载机制？

   啥也不说了，直接看文章 JVM 是如何加载 Java 类的？，相信看完你就懂了。

看完上面 15 个面试题，很容易发现一个问题，那就是真正面试的时候很多东西我们公众号之前都有写过，只要好好的把这些东西消化了，再加上面试的时候好好发挥，不说一定能拿到 offer，至少前几面都能很完美的过。看到这样是不是觉得这篇文章值得收藏呢？收藏起来，以后在面试前或者面试别人的时候都可以拿出来用一用。

项目部分

上面提到的是一些技术细节，其实还有很多很多东西，毕竟 Java 的领域涉及到很多地方，像这种面试题简直可以无休止的问下去。聊完了技术细节，后面一般都是针对项目开始询问，每个人的项目不一样，涉及的领域也不一样，不具有参考性，但是一些通用的问题还是要准备下的，比如

1. 项目运用到了哪些技术，整个的框架是什么样子的？
2. 你在这个项目中主要负责哪些内容，你是怎么设计的？
3. 在做这个项目的时候有没有遇到什么技术难点，你是怎么解决的？
4. 项目上线后的 QPS 是多少，用户量有多少，有没有出现过 Fullgc 或者线上 OOM 的情况，你是如何处理的？
5. 模块与模块之前是怎样调用的？HTTP 还是 RPC？RPC 框架用的是什么？了解其实现原理吗？
6. 做这个项目的目的是什么？你对项目所涉及的行业有了解吗？

上面这几个都是日常做项目的时候需要知道和思考的，技术上面涉及到的东西肯定要知道，在最后一个问题上面往往很多小伙伴会忽略，认为不就是一个项目吗？关行业什么事情？其实不是这样的，了解了一个项目的背景和价值可以更好的帮忙我们理解业务需求，从而做到更好的实现，而且对于一些想在某个方向长期发展的朋友，那就更有必要了。

架构部署方面

1. 你们项目是分布式的吗？怎么部署的？
2. 如何在不增加机器的情况下提升 QPS？
3. 如何降低各个服务或者机房之间网络通信耗时？
4. 如果机房突然出现故障如何保证数据不丢失？
5. 当下游服务出现问题时如何做熔断限流保证自己的服务不受影响？

上面几个问题是阿粉遇到的几个架构部署相关的问题，关于这一方面阿粉也不是特殊熟悉，所以就不做回答了，相信关注阿粉的小伙伴都是厉害的，可以在我们的留言下面回答下，大家一起学习谈论，帮助他人同时也是提升自己。

作为一个 Java 开发，在面试的过程中垃圾回收器是经常会被问到的一个问题，随着 Java 的发展，垃圾回收器也经历了很多的发展。大家熟知的垃圾回收器主要有下面几种。

1. Serial 单线程新生代复制算法的垃圾回收器；
2. SerialOld 垃圾回收器，是一种单线程老年代标记整理算法；
3. ParNew 垃圾回收器，是 Serial 的多线程实现，采用复制算法实现；
4. Parallel Scavenge 垃圾回收器，是一种高效的多线程复制算法；
5. ParallelOld 垃圾回收器，是 Parallel Scavenge 的一种老年代的多线程标记整理算法；
6. CMS 垃圾回收器，是一种多线程标记清除算法，后面会详细介绍；
7. G1 垃圾回收器，是一种高吞吐量的垃圾回收器。

回收算法

在介绍垃圾回收器之前，我们先了解一下垃圾回收器背后的算法，每个垃圾回收器都是具体算法的实现，不同的垃圾回收器只是背后的算法不同而已，下面就先简单介绍下具体的算法。

标记清除

标记清除算法是一种先标记，后清除的算法，在第一次扫描的时候先标记出所有需要清理的内存，将所有需要回收的内存都标记过后，一次性清理掉。这种算法简单但是效率低，而且内存碎片化严重。内存一旦碎片化严重的话，就会浪费内存，无法分配较大的对象。

复制算法

复制算法的实现方式比较简洁明了，就是霸道的把内存分成两部分，在平时使用的时候只用其中的固定一份，在当需要进行 GC 的时候，把存活的对象复制到另一部分中，然后将已经使用的内存全部清理掉。这种算法可以解决碎片化的问题，但是缺点也很明显，就是浪费内存，有一半的内存都不能使用。

标记整理算法

既然标记清除和复制算法各有优缺点，那自然的我们就想到是否可以把这两种算法结合起来，于是就出现了标记整理算法。标记阶段是标记清除算法一样，先标记出需要回收的部分，不过清除阶段不是直接清除，而是把存活的对象往内存的一端进行移动，然后清除剩下的部分。

标记整理的算法虽然可以解决上面两个算法的一些问题，但是还是需要先进行标记，然后进行移动，整个效率还是偏低的。

分代回收算法

分代回收算法是目前使用较多的一种算法，这个不是一个新的算法，只是将内存进行的划分，不同区域的内存使用不同的算法。根据对象的存活时间将内存的划分为新生代和老年代，其中新生代包含 Eden 区和 S0，S1。在新生代中使用是复制算法，在进行对象内存分配的时候只会使用 Eden 和 S0 区，当发生 GC 的时候，会将存活的对象复制到 S1 区，然后循环往复进行复制。当某个对象在进行了 15 次GC 后依旧存活，那这个对象就会进入老年代。老年代因为每次回收的对象都会比较少，因此使用的是标记整理算法。

垃圾回收器

上面虽然提到了好几个垃圾回收器，但是目前主流的垃圾回收器只有 CMS 和 G1。下面就跟大家聊下这两个垃圾回收器。

CMS 垃圾回收器

CMS 全称 Concurrent Mark Sweep 并发标记清除垃圾回收器。CMS 是一种以获取最短停顿时间为目的的垃圾回收器。提到停顿时间，我们都知道任何垃圾回收器在进行工作的时候都会出现 STW，Stop the World 停止用户进程，这对业务来说只很难接受的，但是现在市面上所有的垃圾回收器都无法避免这个问题，只能最大化的去优化，从而降低停顿的时间。

CMS 虽然被称为是并发的垃圾回收器，但是也并不是完全并发的，从名字上我们可以看到是采用标记-清除算法来实现的，整个实现过程分为五个步骤：

1. 初始标记：暂停所有线程，从来可达性分析来标记对象，这也是 CMS 垃圾回收器第一个 STW 的时候；
2. 并发标记：并发标记的时候 GC 线程和用户线程是同时存在的，这个过程中会记录所有可达的对象，但是这个过程结束过后由于用户线程一直在运行所以还会产生新的引用更新，也就是需要下一步了；
3. 并发预清理：这个阶段用户线程和 GC 线程同时运行，GC 线程会进行一下预清理的动作；
4. 重新标记：重新标记这个阶段会暂停用户线程，将上一步并发标记过程中用户线程引起的更新进行修正，这个时间会比初始标记时间长，但是会比并发标记时间短一点；
5. 并发清除：在所有需要清理的对象都被标记完过后就会执行最后一步清理的动作。清理的时候用户线程是可以继续运行的，GC 线程只清理标记的区域。

G1 垃圾回收器

G1 全称 Garbage-First 是一种面向服务器的垃圾回收器，通过将堆内存划分为多个 Region 来实现可预测的停顿时间模型。在 G1 当中，新生代和老年代已经不再是物理隔离，而都是被划分一个个 Region 区域。正是由于这种可预测的时间停顿模型让 G1 成为了一个高吞吐量的垃圾回收器。G1 能充分利用 CPU，多核环境下可以缩短 STW 的时间。

G1 垃圾回收器的整个实现过程分为四个步骤：

1. 初始标记：通过可达性分析标记 GC Roots 的直接关联对象，这个阶段与 CMS 一样需要 STW；
2. 并发标记：并发标记是通过 GC Roots 找到存活的对象，这个阶段 GC 线程是与用户线程同时运行的，并且这个阶段的时间比初始标记长；
3. 最终标记：最终标记跟 CMS 的重新标记一样，也是为了修正并发标记过程中因用户线程继续运行而导致产生新的引用更新；同样的这里也需要 STW；
4. 筛选回收：筛选回收这里会对每个 Region 的回收成本进行排序，根据用户期望的停顿时间来制定收回计划，这也就是可预测的停顿时间模型的体现之处，这个阶段 GC 线程是与用户线程同时运行的。

总结

虽然说 Java 开发不用程序员去手动创建和回收内存，但是了解和掌握垃圾回收器是每个 Java 程序员必须要掌握的，不仅仅是面试的过程中会被问到，对自己的职业发展也是很有帮助的。本文是阿粉自己学习和整理的，部分资料参考网络上，分享给大家，帮助大家一起成长。

大家好，我是阿粉~

搜索引擎应该各位程序员开发中离不开软件吧，日常开发不懂的地方，直接上搜索引擎，大半问题都可以得到解答。

我们时常会把将这种方式戏称为「面向搜索引擎编程」，讲真的如果哪一天搜索引擎真不能打开了，阿粉相信大半程序可能开展不了工作了[狗头]。

目前国内搜索引擎，百度一家独大，如果我们没有特殊的科学上网能力，那只能通过百度了。

但是现在百度搜索体验怎么样，各位读者平常使用过程应该都有点体会吧？

打开「www.baidu.com」，搜索框下方很大的版面是当天的时事新闻，然后右侧就是当天热搜。

这样的页面展示，对于普通大众来说，可以说非常方便。

但是对于开发者来说，干扰信息有点太多了。阿粉记得之前有几次搜索东西，然后就被傍边信息吸引，吃了半天的瓜。

等阿粉回过头的时候才发现，哎，我刚才要干什么来着？

如果此时你没有被这些信息干扰，输入关键信息，然后你就会看到第一条结果是广告，然后往下滑，第四条第五条还是广告。

翻了好几页，可能才找到的想要的结果。

这真不是我们开发者想要的搜索的引擎！！！

开发者搜索

百度搜索实在太难用了，所以阿粉真的好久没有使用了。最近上网的时候无意间发现一款搜索引擎，名叫「开发者搜索」，地址为：

https://kaifa.baidu.com/

从名字上就可以看出，这款产品专门针对「开发者」而开发，另外从网址我们可以看到这款产品竟然是百度开发的？？？

这个真的有点意外!

果然只有使用魔法才能打败魔法。

打开这个网页，可以看到这个页面真的非常简洁，只有一个简单的搜索框，其他任何信息都没有!

这个页面让阿粉想到很早之前百度的搜索页面~

输入想要搜索信息之后，可以看到搜索结果非常聚焦，没有任何广告。

页面布局与原来百度页面类似：

• 左侧顶部是各类标签，下方则是搜索页面
• 右侧为百度百科，以及 gitee 上开源项目

仔细看开发者搜索的搜索结果，可以发现目前搜索结果仅仅来源于知乎、CSDN以及博客园三个站点。从这一点来说，其实比较可惜了，虽然这三个网站已经包含大量的文章了，但是其实还是源源不够。

其实很多个人独立网站，比如阮一峰老师，左耳朵耗子的博客网站，里面的内容其实质量也比较高。

不过也可以理解，毕竟现在「开发者搜索」仅仅是 Beta 版本，不完善也是正常。

那这里还是希望百度可以完善这款产品，真正帮到国内的开发者。

其他搜索引擎

那说实话，现在对开发者最友好的引擎，阿粉觉得还是 「Google 」搜索了。

无论是搜索结果的准确度，又或是显示站点的质量，都比百度号上一截。

不过由于神秘的东方的力量，这网站已经不能在国内正常打开。

不过这一点，我觉得应该难不倒爱折腾的程序员们，所以如果你能打开「Google 」，那就赶紧抛弃百度吧~

最后对于一些没办法打开「Google 」的小伙伴，再推荐一个搜索引擎，那就是微软的「必应搜索」。

打开必应搜索的首页，可以看到页面非常简洁，并且背景图还是一些高清壁纸，视觉感非常舒服。

另外可以看到搜索框上可以分为国内版跟国际版，那这两者主要区别在于：

• 国内版适合中文搜索
• 国际版适合使用英文搜索

最后

如果大家可以打开「Google」搜索，那阿粉真心建议你们直接使用 Google。阿粉这几年用下来，使用体验真的非常好，搜索结果也比较准确，真的非常适合开发者使用。

哎，百度「开发者搜索」加把劲吧，什么时候真的把功能完善好，让国内开发者搜索更加简单高效一点~

加油吧，百度~

你做过代码 Review 吗？

Hello 大家好我是阿粉，代码 Review 相信大家一定不会陌生，但是真正在日常工作中能使用并且坚持执行下去的公司或者团队，阿粉觉得并不多，但是代码 Review 的好处大家都是有目共睹的，很多招聘岗位上面都有这样的要求，坚持执行代码 Review 对团队，对公司是很有好处的，特别是对写代码的同事！每个一起阅读代码的同事都会提出一些自己的建议 ，这些建议都是很宝贵的资源，往往都会有很大的收获。

那么如何做好一场代码 Review 呢？想要做好一场合格的代码 Review，首先我们需要知道代码 Review 的过程中都有哪些角色以及需要怎样的流程。

角色

1. 代码的作者 Author；
2. 阅读代码的同事 Reviewer；
3. 主持人 Host；
4. 记录员 Recorder。

流程

1. 提前一天发送 Review 代码邮件给相关人员，确定 Host 和 Recorder；
2. 由 Host 主持 Review 会议；
3. 由 Reviewer 和 Author 进行代码走读；
4. 由 Recorder 进行改进记录。

在做代码 Review 之前 Author 需要提前一天需要发正式邮件给相关人员，并且将需要被 Review 的代码通过邮件附件的方式，发送给相关的 Reviewer 让他们提前阅读，这样有助于 Review 的时候可以更高效的进行。并且提前沟通好代码 Review 的会议 Host 和 Recorder。Host 在会议过程中负责组织大家发言和维护秩序，让代码 Review 更高效；Recorder 则负责将整个 Review 过程中提到的需要优化和改进的点进行文档形式的记录，记录的信息需要言简意赅，将哪个文件哪一行代码，问题是什么，建议怎么优化都需要记下来，并且在会议结束过后以邮件的形式发送给 Author 和抄送大家。

Review

在进行代码 Review 的时候 Author 需要从文件的第一行开始进行一行行的代码走读，对每一行的代码进行描述，这里需要注意的是不要认为某个功能很简单，就可以一句带过，往往很多线上 Bug 都是因为这种忽略导致的。走读代码的时候 Author 需要解释清楚每一行代码的含义，说明这行代码是干嘛的，为什么要这样写。Reviewer 则需要根据 Author 的描述再结合自己之前阅读代码的理解进行提问或者改进方案。

代码走读的过程持续进行的同时 Recorder 需要及时记录需要改进的内容，并把提出的优化方案记录下来。代码走读的过程是整个 Review 的核心，在这个环节中我们需要注意很多东西。知乎上面有个提问大家的公司的 Code Review 都是怎么做的？遇到过哪些问题？，上面有个回答提出的几个点很不错，我觉得有必要分享给大家，对我们的整个 Review 会很有帮助，特别是当自己是 Reviewer 的时候，需要格外注意。

1. 对事不对人。要记住大家都是同事，今天自己是 Reviewer 来对别人的代码进行 Review，哪天别人就会对自己的代码进行 Review，所以在整个代码 Review 的环节中，我们可以提出自己的建议，但是需要注意自己的用词和语气，虽然程序员有鄙视链，并且都认为别人的代码垃圾，但是这种时候不能瞎说，容易打架的，还是要谦虚点。
2. 用正面的词汇进行评价。跟上面说的一样，我们需要用正面的词汇进行评价代码，考虑 Author 的情绪，即使代码写的不好。这个很好理解，毕竟代码 Review 是在很多人面前的，对 Author 来说，让别人看自己写的代码就像在别人面前裸奔一样，所以我们不仅要提出意见在好的地方我们也要进行正向的表扬。
3. 如果有更好的方案一定要提出来。代码 Review 的目的就是优化代码，找出代码中的隐藏 BUG 以及逻辑问题。所以如果发现了代码有任何不优雅的地方或者会出现问题的地方一定要及时的提出来，不要担心自己说的不对，或者考虑 Author 的面子问题，不指出来，提供更好的解决方案，让大家一起进步。
4. Review 会议是 Review 代码，而不是讨论需求。这一点也是很容易被带偏的一个点，经常我们会发现在 Review 的过程中，慢慢的就变成了讨论需求了，这种情况一定要避免发生，不然整个代码 Review 环节就是失败的，无法进行下去了。所以 Author 在发起代码 Review 邀请时一定要确保自己理解的需求是正确的，避免浪费大家的时间。
5. 高效的进行。进行代码 Review 的时候我们需要注意一定要高效，如何做到高效就需要每个人都做好相应的准备，Author 需要对自己的代码进行熟练的讲解，Reviewer 需要在参加会议之前将需要 Review 的代码看一下，提前找到可能隐藏的 Bug，对于不懂地方需要做好记录，方便开会的时候及时指出。
6. 避免形式主义。这一点也是被很多小伙伴忽略的一点，随着代码 Review 的次数越来越多，很多小伙伴可能就把这个当成一个任务，慢慢的就变成了形式主义，而不是注重实际，每次代码 Review 的时候就很随意，长期这样下去对公司，团队以及自己都不好，而且还浪费时间。

总结

阿粉今天给大家介绍了一个如何做一个合格的代码 Review，当然这只是阿粉自己的一些见解，大家有任何意见可以在评论区给我们留言，也可以加入我们的微信群，大家一起交流学习。

Redis 作为后端工程师必备的技能，阿粉每次面试的时候都会被问到，阿粉特意把公号前面发过的 Redis 系列文章整理出来，自己学习同时也帮助大家一起学习。

Redis 的数据类型有哪些？

Redis 五种数据类型，每种数据类型都有相关的命令，几种类型分别如下：

1. String（字符串）

2. List（列表）

3. Hash（字典）

4. Set（集合）

5. Sorted Set（有序集合）

Redis 有五种常见的数据类型，每种数据类型都有各自的使用场景，通用的字符串类型使用最为广泛，普通的 Key/Value 都是这种类型；列表类型使用的场景经常有粉丝列表，关注列表的场景；字典类型即哈希表结构，这个类型的使用场景也很广泛，在各种系统里面都会用到，可以用来存放用户或者设备的信息，类似于 HashMap 的结构；Redis set 提供的功能与列表类型类似也是一个列表的功能，区别是 Set 是去重的；有序集合功能与 Set 一样，只不过是有顺序的。

Redis 的内存回收与Key 的过期策略

Redis 内存过期策略

过期策略的配置

Redis 随着使用的时间越来越长，占用的内存会越来越大，那么当 Redis 内存不够的时候，我们要知道 Redis 是根据什么策略来淘汰数据的，在配置文件中我们使用 maxmemory-policy 来配置策略，如下图

我们可以看到策略的值由如下几种：

1. volatile-lru: 在所有带有过期时间的 key 中使用 LRU 算法淘汰数据；
2. alkeys-lru: 在所有的 key 中使用最近最少被使用 LRU 算法淘汰数据，保证新加入的数据正常；
3. volatile-random: 在所有带有过期时间的 key 中随机淘汰数据；
4. allkeys-random: 在所有的 key 中随机淘汰数据；
5. volatile-ttl: 在所有带有过期时间的 key 中，淘汰最早会过期的数据；
6. noeviction: 不回收，当达到最大内存的时候，在增加新数据的时候会返回 error，不会清除旧数据，这是 Redis 的默认策略；

volatile-lru, volatile-random, volatile-ttl 这几种情况在 Redis 中没有带有过期 Key 的时候跟 noeviction 策略是一样的。淘汰策略是可以动态调整的，调整的时候是不需要重启的，原文是这样说的，我们可以根据自己 Redis 的模式来动态调整策略。 ”To pick the right eviction policy is important depending on the access pattern of your application, however you can reconfigure the policy at runtime while the application is running, and monitor the number of cache misses and hits using the Redis INFO output in order to tune your setup.“

策略的执行过程

1. 客户端运行命令，添加数据申请内存；
2. Redis 会检查内存的使用情况，如果已经超过的最大限制，就是根据配置的内存淘汰策略去淘汰相应的 key，从而保证新数据正常添加；
3. 继续执行命令。

近似的 LRU 算法

Redis 中的 LRU 算法不是精确的 LRU 算法，而是一种经过采样的LRU，我们可以通过在配置文件中设置 maxmemory-samples 5 来设置采样的大小，默认值为 5，我们可以自行调整。官方提供的采用对比如下，我们可以看到当采用数设置为 10 的时候已经很接近真实的 LRU 算法了。

在 Redis 3.x 以上的版本的中做过优化，目前的近似 LRU 算法以及提升了很大的效率，Redis 之所以不采样实际的 LRU 算法，是因为会耗费很多的内存，原文是这样说的

The reason why Redis does not use a true LRU implementation is because it costs more memory.

Key 的过期策略

设置带有过期时间的 key

前面介绍了 Redis 的内存回收策略，下面我们看看 Key 的过期策略，提到 Key 的过期策略，我们说的当然是带有 expire 时间的 key，如下

通过 redis> set name ziyouu ex 100 命令我们在 Redis 中设置一个 key 为 name，值为 ziyouu 的数据，从上面的截图中我们可以看到右下角有个 TTL，并且每次刷新都是在减少的，说明我们设置带有过期时间的 key 成功了。

Redis 如何清除带有过期时间的 key

对于如何清除过期的 key 通常我们很自然的可以想到就是我们可以给每个 key 加一个定时器，这样当时间到达过期时间的时候就自动删除 key，这种策略我们叫定时策略。这种方式对内存是友好的，因为可以及时清理过期的可以，但是由于每个带有过期时间的 key 都需要一个定时器，所以这种方式对 CPU 是不友好的，会占用很多的 CPU，另外这种方式是一种主动的行为。

有主动也有被动，我们可以不用定时器，而是在每次访问一个 key 的时候再去判断这个 key 是否到达过期时间了，过期了就删除掉。这种方式我们叫做惰性策略，这种方式对 CPU 是友好的，但是对应的也有一个问题，就是如果这些过期的 key 我们再也不会访问，那么永远就不会删除了。

Redis 服务器在真正实现的时候上面的两种方式都会用到，这样就可以得到一种折中的方式。另外在定时策略中，从官网我们可以看到如下说明

Specifically this is what Redis does 10 times per second:

1. Test 20 random keys from the set of keys with an associated expire.
2. Delete all the keys found expired.
3. If more than 25% of keys were expired, start again from step 1.

意思是说 Redis 会在有过期时间的 Key 集合中随机 20 个出来，删掉已经过期的 Key，如果比例超过 25%，再重新执行操作。每秒中会执行 10 个这样的操作。

Redis 的发布订阅功能你知道吗？

发布订阅系统在我们日常的工作中经常会使用到，这种场景大部分情况我们都是使用消息队列的，常用的消息队列有 Kafka，RocketMQ，RabbitMQ，每一种消息队列都有其特性。其实在很多时候我们可能不需要独立部署相应的消息队列，只是简单的使用，而且数据量也不会太大，这种情况下，我们就可以考虑使用 Redis 的 Pub/Sub 模型。

使用方式

发布与订阅

Redis 的发布订阅功能主要由 PUBLISH，SUBSCRIBE，PSUBSCRIBE 命令组成，一个或者多个客户端订阅某个或者多个频道，当其他客户端向该频道发送消息的时候，订阅了该频道的客户端都会收到对应的消息。

上图中有四个客户端，Client 02，Client 03，Client 04 订阅了同一个Sport 频道（Channel），这时当 Client 01 向 Sport Channel 发送消息 “basketball” 的时候，02-04 这三个客户端都同时收到了这条消息。

整个过程的执行命令如下：

首先开四个 Redis 的客户端，然后在 Client 02，Client 03，Client 04 中输入subscribe sport 命令，表示订阅 sport 这个频道

然后在 Client 01 的客户端中输入publish sport basketball 表示向 sport 频道发送消息 “basketball”

这个时候我们在去看下Client 02-04 的客户端，可以看到已经收到了消息了，每个订阅了这个频道的客户端都是一样的。

这里 Client 02-Client 04 三个客户端订阅了 Sport 频道，我们叫做订阅者（subscriber），Client 01 发布消息，我们叫做发布者（publisher），发送的消息就是 message。

模式订阅

前面我们看到的是一个客户端订阅了一个 Channel，事实上单个客户端也可以同时订阅多个 Channel，采用模式匹配的方式，一个客户端可以同时订阅多个 Channel。

如上图 Client 05 通过命令subscribe run 订阅了 run 频道，Client 06 通过命令psubscribe run* 订阅了 run* 匹配的频道。当 Client 07 向 run 频道发送消息 666 的时候，05 和 06 两个客户端都收到消息了；接下来 Client 07 向 run1 和 run_sport 两个频道发送消息的时候，Client 06 依旧可以收到消息，而 Client 05 就收不到了消息了。

Client 05 订阅run 频道和接收到消息：

Client 06 订阅run* 频道和接收到消息：

Client 07 向多个频道发送消息：

通过上面的案例，我们学会了一个客户端可以订阅单个或者多个频道，分别通过subscribe，psubscribe 命令，客户端可以通过 publish 发送相应的消息。

在命令行中我们可以用 Ctrl + C 来取消相关订阅，对应的命令时 unsubscribe channelName。

Pub/Sub 底层存储结构

订阅 Channel

在 Redis 的底层结构中，客户端和频道的订阅关系是通过一个字典加链表的结构保存的，形式如下：

在 Redis 的底层结构中，Redis 服务器结构体中定义了一个 pubsub_channels 字典

1
2
3
4

struct redisServer {
	//用于保存所有频道的订阅关系
	dict *pubsub_channels;
}

在这个字典中，key 代表的是频道名称，value 是一个链表，这个链表里面存放的是所有订阅这个频道的客户端。

所以当有客户端执行订阅频道的动作的时候，服务器就会将客户端与被订阅的频道在 pubsub_channels 字典中进行关联。

这个时候有两种情况：

• 该渠道是首次被订阅：首次被订阅说明在字典中并不存在该渠道的信息，那么程序首先要创建一个对应的 key，并且要赋值一个空链表，然后将对应的客户端加入到链表中。此时链表只有一个元素。
• 该渠道已经被其他客户端订阅过：这个时候就直接将对应的客户端信息添加到链表的末尾就好了。

比如，如果有一个新的客户端 Client 08 要订阅 run 渠道，那么上图就会变成

如果 Client 08 要订阅一个新的渠道 new_sport ，那么就会变成

整个订阅的过程可以采用下面伪代码来实现

1
2
3
4
5
6
7
8
9
10

Map<String, List<Object>> pubsub_channels = new HashMap<>();
    public void subscribe(String[] subscribeList, Object client) {
        //遍历所有订阅的 channel，检查是否在 pubsub_channels 中，不在则创建新的 key 和空链表
        for (int i = 0; i < subscribeList.length; i++) {
            if (!pubsub_channels.containsKey(subscribeList[i])) {
                pubsub_channels.put(subscribeList[i], new ArrayList<>());
            }
            pubsub_channels.get(subscribeList[i]).add(client);
        }
    }

取消订阅

上面介绍的是单个 Channel 的订阅，相反的如果一个客户端要取消订阅相关 Channel，则无非是找到对应的 Channel 的链表，从中删除对应的客户端，如果该客户端已经是最后一个了，则将对应 Channel 也删除。

1
2
3
4
5
6
7
8
9
10

public void unSubscribe(String[] subscribeList, Object client) {
        //遍历所有订阅的 channel，依次删除
        for (int i = 0; i < subscribeList.length; i++) {
            pubsub_channels.get(subscribeList[i]).remove(client);
            //如果长度为 0 则清楚 channel
            if (pubsub_channels.get(subscribeList[i]).size() == 0) {
                remove(subscribeList[i]);
            }
        }
    }

模式订阅结构

模式渠道的订阅与单个渠道的订阅类似，不过服务器是将所有模式的订阅关系都保存在服务器状态的pubsub_patterns 属性里面。

1
2
3
4

struct redisServer{
	//保存所有模式订阅关系
	list *pubsub_patterns;
}

与订阅单个 Channel 不同的是，pubsub_patterns 属性是一个链表，不是字典。节点的结构如下：

1
2
3
4
5
6

struct pubsubPattern{
	//订阅模式的客户端
	redisClient *client;
	//被订阅的模式
	robj *pattern;
} pubsubPattern;

其实 client 属性是用来存放对应客户端信息，pattern 是用来存放客户端对应的匹配模式。

所以对应上面的 Client-06 模式匹配的结构存储如下

在pubsub_patterns链表中有一个节点，对应的客户端是 Client-06，对应的匹配模式是run*。

订阅模式

当某个客户端通过命令psubscribe 订阅对应模式的 Channel 时候，服务器会创建一个节点，并将 Client 属性设置为对应的客户端，pattern 属性设置成对应的模式规则，然后添加到链表尾部。

对应的伪代码如下：

1
2
3
4
5
6
7
8
9
10

List<PubSubPattern> pubsub_patterns = new ArrayList<>();
    public void psubscribe(String[] subscribeList, Object client) {
        //遍历所有订阅的 channel，创建节点
        for (int i = 0; i < subscribeList.length; i++) {
            PubSubPattern pubSubPattern = new PubSubPattern();
            pubSubPattern.client = client;
            pubSubPattern.pattern = subscribeList[i];
            pubsub_patterns.add(pubSubPattern);
        }
    }

1. 创建新节点；
2. 给节点的属性赋值；
3. 将节点添加到链表的尾部；

退订模式

退订模式的命令是punsubscribe，客户端使用这个命令来退订一个或者多个模式 Channel。服务器接收到该命令后，会遍历pubsub_patterns链表，将匹配到的 client 和 pattern 属性的节点给删掉。这里需要判断 client 属性和 pattern 属性都合法的时候再进行删除。

伪代码如下：

1
2
3
4
5
6
7
8
9
10
11

public void punsubscribe(String[] subscribeList, Object client) {
        //遍历所有订阅的 channel 相同 client 和 pattern 属性的节点会删除
        for (int i = 0; i < subscribeList.length; i++) {
            for (int j = 0; j < pubsub_patterns.size(); j++) {
                if (pubsub_patterns.get(j).client == client
                && pubsub_patterns.get(j).pattern == subscribeList[i]) {
                    remove(pubsub_patterns);
                }
            }
        }
    }

遍历所有的节点，当匹配到相同 client 属性和 pattern 属性的时候就进行节点删除。

发布消息

发布消息比较好容易理解，当一个客户端执行了publish channelName message 命令的时候，服务器会从pubsub_channels和pubsub_patterns 两个结构中找到符合channelName 的所有 Channel，进行消息的发送。在 pubsub_channels 中只要找到对应的 Channel 的 key 然后向对应的 value 链表中的客户端发送消息就好。

Redis 的持久化你了解吗

持久化是将程序数据在持久状态和瞬时状态间转换的机制。通俗的讲，就是瞬时数据（比如内存中的数据，是不能永久保存的）持久化为持久数据（比如持久化至数据库中，能够长久保存）。另外我们使用的 Redis 之所以快就是因为数据都存储在内存当中，为了保证在服务器出现异常过后还能恢复数据，所以就有了 Redis 的持久化，Redis 的持久化有两种方式，一种是快照形式 RDB，另一种是增量文件 AOF。

RDB

RDB 持久化方式是会在一个特定的时间间隔里面保存某个时间点的数据快照，我们拿到这个数据快照过后就可以根据这个快照完整的复制出数据。这种方式我们可以用来备份数据，把快照文件备份起来，传送到其他服务器就可以直接恢复数据。但是这只是某个时间点的全部数据，如果我们想要最新的数据，就只能定期的去生成快照文件。

RDB 的实现主要是通过创建一个子进程来实现 RDB 文件的快照生成，通过子进程来实现备份功能，不会影响主进程的性能。同时上面也提到 RDB 的快照文件是保存一定时间间隔的数据的，这就会导致如果时间间隔过长，服务器出现异常还没来得及生成快照的时候就会丢失这个间隔时间的所有数据；那有同学就会说，我们可以把时间间隔设置的短一点，适当的缩短是可以的，但是如果间隔时间段设置短一点频繁的生成快照对系统还是会有影响的，特别是在数据量大的情况下，高性能的环境下是不允许这种情况出现的。

我们可以在 redis.conf 进行 RDB 的相关配置，配置生成快照的策略，以及日志文件的路径和名称。还有定时备份规则，如下图所示，里面的注释写的很清楚，简单说就是在多少时间以内多少个 key 变化了就会触发快照。如save 300 10 表示在 5 分钟内如果有 10 个 key 发生了变化就会触发生产快照，其他的同理。

除了我们在配置文件中配置自动生成快照文件之外，Redis 本身提供了相关的命令可以让我们手动生成快照文件，分别是 SAVE 和 BGSAVE ，这两个命令功能相同但是方式和效果不一样，SAVE 命令执行完后阻塞服务器进程，阻塞过后服务器就不能处理任何请求，所以在生产上不能用，和SAVE 命令直接阻塞服务器进程的做法不同，BGSAVE 命令是生成一个子进程，通过子进程来创建 RDB 文件，主进程依旧可以处理接受到的命令，从而不会阻塞服务器，在生产上可以使用。

阿粉在这里测试一下自动生成快照，我们修改一下快照的生成策略为save 10 2，然后在本地启动Redis 服务，并用 redis-cli 链接进入，依次步骤如下

1. 修改配置，如下

   

2. 启动 Redis 服务，我们可以从启动日志中看到，默认是会先读取 RDB 文件进行恢复的

   

3. 链接 Redis 服务，并在 10s 内设置 3 个 key

   

4. 这个时候我们会看到 Redis 的日志里面会输出下面内容，因为触发了规则，所以开启子进程进行数据备份，同时在对应的文件路径下面，我们也看到了 rdb 文件。

   

从上面可以看出，我们配置的规则生效了，也成功的生成了 RDB 文件， 后续在服务器出现异常的情况，只要重新启动就会读取对应的 RDB 文件进行数据备份。

AOF

AOF 是一种追加执行命令的形式，它跟 RDB 的区别是，AOF 并不是把数据保存下来，而是保存执行的动作。在开启 AOF 功能的时候，客户端连接后执行的每一条命令都会被记录下来。这其实让阿粉想起来的 MySQL 的 binlog 日志，也是记录操作的命令，后续可以根据文件去恢复数据。

AOF 是追加命令格式的文件，同样的我们可以定义多长时间把数据同步一次，Redis 本身提供了三种策略来实现命令的同步，分别是不进行同步，每秒同步一次，以及当有查询的时候同步一次。默认的策略也是使用最多的策略就是每秒同步一次，这样我们可以知道，丢失的数据最多也就只有一秒钟的数据。有了这种机制，AOF 会比 RDB 可靠很多，但是因为文件里面存在的是执行的命令，所以AOF 的文件一般也会比 RDB 的文件大点。

Redis 的 AOF 功能，默认是没有开启的，我们可以通过在配置文件中配置appendonly yes 是功能开启，同时配置同步策略appendfsync everysec 开启每秒钟同步一次，我们拿到 AOF 文件过后，可以根据这个文件恢复数据。

同样的我们在redis.conf 中可以看到默认是没有开启 AOF 功能的，并且我们也可以指定对应的文件名称和路径。

接下来，我们测试一下开启 AOF 功能，先修改配置然后重启 Redis 的服务器，我们会发现已经没有读取 RDB 文件的日志了，并且在日志文件路径下面已经生成了一个 aof 文件。需要注意的是，因为我们重启的服务，并且开启了 AOF，所以现在 Redis 服务器里面并没有我们之前添加的数据（说明什么问题呢？）。

接下来我们使用客户端连接进入，设置如下值，接下来我们可以看看 aof 文件里面的内容

我们可以看到aof 文件里面的内容就是执行的命令，只不过是以一种固定的格式存储的，我们在备份的时候如果不需要哪些数据，可以手动删掉对应的命令就可以重新备份数据。

Redis 的有几种集群模式

虽然说单机 Redis 理论上可以达到 10 万并发而且也可以进行持久化，但是在生产环境中真正使用的时候，我相信没有哪个公司敢这样使用，当数据量达到一定的规模的时候肯定是要上 Redis 集群的。

Redis 的模式有主从复制模式，哨兵模式以及集群模式，这三种模式的涉及到篇幅内容会比较多，阿粉后面会单独写一篇文章来介绍，感兴趣的小伙伴可以先自己学习下。

相信关注我们 Java 极客技术的朋友大部分都是程序员，那么你还记得自己是怎么踏上这条致(不)富(归)路的吗？

今天大年初五，距离上班没有几天的时间了，今天跟大家分享一下阿粉是如何走上程序员的道路的，阿粉的经历只是一个缩影，相信有很多人跟阿粉一样，更有很多比阿粉优秀的人也在坚持着。

阿粉记得高考结束填志愿的时候，当时志愿填的都是计算机相关的专业，那会什么也不懂，只知道计算机听上去很高大上但是具体干什么的，完全不知道。就这样懵懵懂懂的进了计算机学院并且选修了网络工程专业，刚开始我以为同学都跟我一样是因为对计算机的热爱才进了这个专业，但是慢慢的才发现本班很多人是调剂过来的，都是因为选的其他专业人数满了，最后被调剂到计算机学院的，而且当时我们学校的计算机学院是第一年招生。

但是不管怎样对外还是可以说是计算机科班出身，但是阿粉我接触电脑还是比较晚的，接触编程也是上大学才开始的，出身农村，小时候根本没用过电脑，不像有些朋友从小就接触电脑接触编程。

接触的第一门编程语言毫无疑问《谭浩强的 C 语言》，相信很多人都跟阿粉一样从这本书开始了自己的编程生涯。对于这本书的褒贬我不做评价，有人说不好，有人说好，但是既然能出书并能被纳入大学教材自然有它的道理。

刚接触编程语言的时候，第一感觉就是，这也太神奇好玩了吧！只要在屏幕上输入一些特定的字符，就能实现动画，做出网页，并且可以解决一些问题，感觉太有意思了。都说男人的成长是因为压力，大学头两年是在懵懵懂懂中度过的，有课的时候上课，没课的时候就打游戏睡觉，到处玩，一点生活压力都没有。大三的时候觉得快要实习找工作了，不能再浪费时间，然后就天天在实验室里面看各种技术视频，跟着视频一行一行敲代码，跟着视频里面的老师做了一个小小的静态网站傻傻的开心了好几天，所以说有时候成长就是一瞬间的事情还是很有道理的。

后面实验室老师接项目，让我们帮他做，给我们每个人每个月三千多块钱，那个时候当其他专业的朋友还在跟家里要生活费，各种花钱买实验设备的时候，我们这个专业的同学都已经自食其力挣钱了，既能学东西又能挣点零花钱，不用跟家里要生活费，感觉还是很棒的，特别有成就感。

后来大三暑假的时候找了一家公司进行了两个月的实习，实习的过程中就发现书本上学到的东西跟实际工作中遇到的问题真是南辕北撤，而且主要是在学校里面老师教的很多东西，在工作中已经不用了，那个时候就发现学校跟社会有一点脱轨，虽然说原理都是一样的，但是难免工作的时候动手能力还稍微差了点。

所以以过来人经验告诉那些还没有毕业，快要毕业的朋友，一定要多在网上看看资料，多看看一些招聘网站上的要求，提前多学习一下。

经过两个月的实习过后，公司觉得各方面不错阿粉也觉得机会难得，双方就签了意向书，毕业后可以直接入职。实习后既然工作已经定了，阿粉就没有再找过其他公司，而是一门心思的在提升技能（这个现在想想挺后悔的，还是要去大公司试试~~）。毕业后直接入职，留下来工作了。

就这样阿粉一步一步的走上了程序员的这条路，自从走上这条路，虽然头发日渐稀少，逐渐油腻起来，但是阿粉还是很开心和快乐的，因为热爱，因为梦想，毕竟每个程序员都有一颗让世界变的更美好的心！

互联网行业学无止境，未来的路还有很长，有的人是因为喜爱走上了这条路，有的人是因为谋生走上了这条路，有的人是因为梦想走上了这条路，那么你呢？是因为什么走上了这条路呢？

《孙子兵法》中有一句：“胜者先胜而后求战，败者先战而后求胜”。胜者之所以能常胜是因为在开战之前就已经洞悉了一切，做好了充分的准备，有着百分百必胜的把握，而后才会开战，自然必胜。而败者在开战前没有任何准备，直到战争开始才想着怎样取胜，这样失败的概率必然很大。

总结给我们的知识就是在做任何事情的时候都要做好准备，只有自己准备的充分，才能取得最大的胜利，也就是我们常说的知己知彼，百战不殆。不仅是对待某件事情，对待我们的人生都应该这样，前期做好准备，集聚能量，蓄势待发，在关键时刻必然一飞冲天。

与君共勉！

序言

最近一款被马克斯带火的社交软件 ClubHouse 在科技圈被广泛讨论，所以最近在各大技术群和论坛里面往往看到的都是求一个邀请码，如下图所示，不得不说真是一码难求。那这个 ClubHouse 到底是个什么样的 APP，为什么这么火爆呢？

软件介绍

ClubHouse 首先是一个语音社交软件，这个软件的模式是采用手机号邀请制注册，只要注册的手机号被别人邀请到，就同样会有两个邀请名额。通过通讯录找到都注册了的朋友，然后就可以开个聊天室在里面聊天。每一个聊天室里面都会有一个主持人以及会邀请一些嘉宾，他们每个人都可以针对特定的主题进行分享，旁听的听众可以只旁听，也可以举手申请发言，只要被主持人同意就可以跟嘉宾一起交流。

看上去其实很普通的一个软件，为什么突然一下子火起来呢？阿粉主要觉得有这么几点，第一个是赶上了疫情，国外很多人在家没事做，打字聊天太慢，视频聊天太正式，而语音则刚刚好，不管自己是坐着还是躺着都可以。第二个是邀请制，就跟早期的知乎一样，如果一个软件的模式是邀请制，那么这个人群的质量就可以有保证，因为毕竟都是一个圈子的人才会互相邀请。第三个是名人效应做的好，刚开始内测的用户都是知名人士，特别是经过马克思在一次采访上面提到自己会开一个聊天室分享，这对于很多人来说能有一个跟大佬一起在一个虚拟房间聊天的机会是很可贵的。说不定举手发言被同意，还能直接跟大佬提问，这对于自己的成长绝对是“听君一席话胜读十年书”。

下载安装

阿粉经过一个下午的努力，成功的下载和注册体验了一下，总的来说整个体验还是不错的（就是好多外国人的聊天室进去听不懂），整个交互很简单，大大的创建聊天室的按钮，然后主页面就是一个个聊天室，随便点击就可以进去旁听，有的聊天室人多，有的聊天室人少。可以找到自己感兴趣的聊天室直接点击进去旁听，也可以申请发言直接交流。

最上面最左右是搜索功能，可以搜索好友或者聊天室，右边第一个邮件菜单就是邀请好友功能，每个成功被邀请注册的都有两个名额可以邀请别人（有朋友反馈在填写注册信息的时候要多选择几个自己喜欢的领域和关注一些人，不然没有邀请名额）。

上面简单说了一下软件的使用，但是在这之前我们需要先下载安装，目前 ClubHouse 这款软件只能在 iOS 上面运行，也就是只有苹果手机才能玩，另外这个软件在中国大陆的 App Store 是下载不了的，我们需要注册一个国外的 Apple Id 才能下载。所以我们要想体验这个软件，需要做如下几个事情。

1. 注册国外的 Apple Id；
2. 下载 ClubHouse 并注册；
3. 找有邀请资格的朋友邀请（确保邀请的手机号和之前注册的手机号一致）；

首先我们在苹果网站注册一个 Apple Id ，主要一个邮箱和手机号，然后地址记得不要选中国大陆，对于要填写的地址，邮编或电话直接在网上搜搜就可以了。

等到注册验证结束后，在手机设置里面媒体与购买项目菜单进行账号切换，切换到国外的账号，然后再到 App Store 里面去搜 ClubHouse 就可以搜索到了，然后认准下面的图标进行下载。

下载完过后通过手机号就可以进行注册，但是这个时候只能提供手机号和验证码，并不能进入软件里面，只能显示如下内容。进行到这里过后剩下的自己能做的就能到处找人邀请了。

总结

最后简单说下，阿粉在第一天使用的时候旁听了几个，感觉还是很有意思的。其中有一个聊天室标题叫做“我是美团骑手，我想跟美团 PM 聊聊” 在这个聊天室里面大家就如何帮忙残障人士点餐或者送外卖进行了讨论，虽然不一定有美团的产品经理能听到，但是感觉大家都想做点什么，还是挺有意思的。