上一篇文章我讲了关于负载均衡的三种算法，轮询法，随机法，最小连接法，这三种负载均衡的算法，但是关于负载均衡还有其他的算法，我们也需要你去看，而且在面试的过程中，很有可能是会问到的呦。

01、前言

相信很多小伙伴在使用 Redis 的时候都知道 Redis 有相关慢日志的查询功能，并且多多少少都看过。那 Redis 底层到底是如果创建慢日志以及慢日志的结构是什么样子的呢？这篇文章就带大家认识一下。我们先看一张慢日志的截图

使用slowlog get 2命令查看最近的两条慢日志信息，如上图，我们可以看到每条日志中包含的信息有六个部分组成，从上到下编号为 0-5，依次代表的意思是

• 0：日志的唯一编号 ID
• 1：命令执行的当前时间戳
• 2：命令执行的耗时时长，单位微妙
• 3：具体的执行命令和参数
• 4：客户端的 ip 和端口（4.0 版本以上才支持）
• 5：客户端名称（4.0 版本以上支持）

如上图所示，第一条慢日志的 ID 是 41，命令执行的时间戳是 1575729996，并且执行了 16129 微妙，具体执行的命令就是slowlog get，ip 和端口是27.38.56.88:8223，客户端的名称没有设置。

02、慢日志命令设置

查看命令

上面我们已经大概的知道的一条慢日志的格式，自然的我们可以想到的问题是一个命令执行多长时间，我们就可以认为是慢查询，以及慢日志最多能保存多少条。

我们可以通过config get slowlog-log-slower-than 命令来查看 Redis 的时长设置，以及通过config get slowlog-max-len 来查看最大慢日志条数。如下图。

设置命令

上面我们使用config get 命令查看了时长设置和条数设置，相反的我们可以用config set来设置相关参数，如下图，我们先查看一下配置，然后再通过config set slowlog-log-slower-than 1000 命令和 config set slowlog-max-len 64 命令来设置具体的值：

通过上面的操作我们可以看到相关的配置已经更改生效了。

1. slowlog-log-slower-than：这个参数的意思是任何命令执行超过这个时间就会被记录为慢日志，单位是微秒。
2. slowlog-max-len：这个参数表示记录的慢日志的最大条数，设置了这个值过后，新的日志加进来，ID 最小的日志就会被删除。

为了验证上面的第二点，我这边将slowlog-log-slower-than设置为 10 微秒，slowlog-max-len 设置为 5 条来进行试验，首先第一次使用slowlog get命令查询的时候 5 条慢日志的编号是从 83-87，

再次使用slowlog get命令查询的编号结果是84-88，说明 ID 为 83 的那一条已经被删除了。

03、慢日志的存储原理

存储结构

1
2
3
4
5
6

struct redisServer {
	long long slowlog_entry_id;//下一条慢查询日志的 ID
	list *slowlog;//保存了所有慢查询日志的链表
	long long slowlog_log_slower_than;//服务器配置 slowlog-log-slower-than 选项的值
	unsigned long slowlog_max_len;//服务器配置的 slowlog-max-len 的值
}

• 在 Redis 的服务器状态中保存了慢日志的相关属性slowlog_entry_id 属性的初始值是 0 每创建一条慢日志的时候就会增加 1。
• slowlog 链表里面存储了所有的慢日志，链表是由slowlogEntry结构组成的，每个slowlogEntry代表一条慢日志。
• slowlog_log_slower_than 和 slowlog_max_len 是前面服务器配置的相关参数。

slowlog 链表

1
2
3
4
5
6
7

typedef struct slowlogEntry {
	long long id;//唯一标识符
	time_t time; //命令执行的时间，格式为 unix 时间戳
	long long duration;//命令消耗的时间，以微妙为单位
	robj **argv;//命令与命令参数
	int argc; //命令与命令参数个数
} slowlogEntry;

slowlogEntry 实体的相关字段含义如下：

• id: 标识慢日志的唯一 ID
• time: 命令执行的时间戳
• duration: 命令执行是耗时，单位为微妙
• agrv: 命令和参数数组
• argc: 命令和参数的个数

如上图就表示了在执行命令set number 520 发生了慢日志，命令执行耗时 10 微妙。

04、操作慢日志

知道了慢日志的存储结构，我们就需要考虑在执行命令的时候，如何根据条件去创建慢日志。

首先我们需要在命令的执行前后记录时间戳，然后相减计算出命令的执行耗时，然后根据 Redis 服务器配置slowlog-log-slower-than 进行对比，决定是否记录慢日志，另外在记录慢日志的时候需要根据slowlog_max_len 值判断是否要删除最久的日志信息。伪代码如下：

1
2
3
4
5
6
7
8

//1. 记录命令执行前的时间戳
long before = now();
//2. 执行命令
execute(argv, argc);
//3. 记录命令执行后的时间戳
long after = now();
//4. 调用创建慢日志函数
slowlogPushEntryIfNeed(argv, argc, after - before);

slowlogPushEntryIfNeed 函数主要用来判断是否插入数据，以及是否删除旧数据。

1
2
3
4
5
6
7
8
9
10
11

void slowlogPushEntryIfNeed(robj **argv, int argc, long long duration) {
	//1. 判断是否开启慢日志
	if (server.slowlog_log_slower_than < 0) return;
	//2. 如果超时，则插入慢日志
  if (duraton > server.slowlog_log_slower_than){
    //插入
  }
  while (listLength(server.slowlog) > server.slowlog_max_len) {
    //删除
  }
}

我们先判断服务器是否配置了超时参数，如果超时参数小于 0 则直接返回，否则再比较命令执行时间是否超时，如果超时则插入慢日志；最后在比较慢日志的条数是否达到上限，如果达到则进行删除。

05、总结

Redis 在日常工作中经常会使用，其中还有很多细节需要我们慢慢研究和学习，公号已经发过好多关于 Redis 相关的文章了，后续还会有其他内容的相关文章，欢迎关注。最后欢迎大家到我们《Java 极客技术》知识星球中来跟我们一起学习，一起进步。

副本机制

复制功能是 Kafka 架构的核心功能，在 Kafka 文档里面 Kafka 把自己描述为 一个分布式的、可分区的、可复制的提交日志服务。复制之所以这么关键，是因为消息的持久存储非常重要，这能够保证在主节点宕机后依旧能够保证 Kafka 高可用。副本机制也可以称为备份机制(Replication)，通常指分布式系统在多台网络交互的机器上保存有相同的数据备份/拷贝。

Docker 在当下很火，那么，当我们谈 Docker ，谈容器的时候，我们在谈什么？ 或者说，你对 Docker ，对容器了解吗？容器，到底是怎么一回事儿？

1 前言

前面理论性的知识是不是有点太“干货”，所以来点实战性的内容吧，这次记录了如何搭建高可用的 Flink 集群。

在正式配置前，来讲下为何要配置高可用（High Availability）

目前越来越多公司的线上应用，都采用的是分布式架构（一主多从），从而避免单点故障引起的服务不可用。

而在 Flink 中，同样也有集群保障服务的高可用，任何时候都有一个主 JobManager 和多个备 JobManager，当前主节点宕机后，立刻会有备 JobManager 当选成为主 JobManager ，接管集群，让每个作业继续正常进行。

出于这样的考虑，在 Flink 应用上线前，需要有这样一个集群来进行保障，下面就来看下该如何进行配置吧。

在逛 programcreek 的时候，我发现了一些专注基础但不容忽视的主题。比如说：Java 的可变参数究竟是怎么一回事？像这类灵魂拷问的主题，非常值得深入地研究一下。

限时 1 秒钟给出答案，来来来，听我口令：“Java 如何获取数组和字符串的长度？length 还是 length()？”

之前我讲了关于 HTTP 的安全性问题，本篇文章将会从一个朋友的面试题入手，来说一下关于 HTTP 的重定向和负载均衡。

如果你只追一个妹子并且对这个妹子特别用心的话，知道的人一定会说你是个好男人；如果你只是浅尝辄止并且追了大部分妹子的话，知道的人一定会骂你渣男。

之前的文章说了一下关于 Cookie 的内容，但是也就引出来了一些问题，比如 HTTP 是怎么进行安全处理的？来了，本文给大家讲述 HTTP 的安全问题。

前言

Tomcat/Jetty 是目前比较流行的 Web 容器，两者接受请求之后都会转交给线程池处理，这样可以有效提高处理的能力与并发度。JDK 提高完整线程池实现，但是 Tomcat/Jetty 都没有直接使用。Jetty 采用自研方案，内部实现 QueuedThreadPool 线程池组件，而 Tomcat 采用扩展方案，踩在 JDK 线程池的肩膀上，扩展 JDK 原生线程池。

JDK 原生线程池可以说功能比较完善，使用也比较简单，那为何 Tomcat/Jetty 却不选择这个方案，反而自己去动手实现那？

1 前言

前面讲了时间 Time 的概念和实际解决问题后，本篇来看下经常搭配使用的另一个关键工具：窗口 Window。

窗口也有三种类型可供选择使用：

• Tumbling Windows：滚动窗口
• Sliding Windows：滑动窗口
• Session Windows：会话窗口

友情提示，本篇主要翻译自官网以及参考了 wuchong 大神的博客，内容比较干货，介绍这三种窗口的概念以及使用场景，希望看完能对 Flink 的窗口概念加深理解。

Kafka 系列的阶段性总结（万字长文，做好准备）

PriorityQueue 一个特殊的优先级队列，今天咱们一起来揭开它的面纱！

ArrayDeque 一个循环数组，诞生于 JDK 1.6，今天小编想和大家一起来揭开它的面纱！

前面的例子中有出现过 时间窗口 TimeWindow 这个词语，其实是两个概念，时间 Time 和窗口 Window。

本篇文章比较干货，主要翻译自官网（参考资料一）， 来讲下关于 Time 的学习、理解以及配套的概念 Watermark。

Watermark 有两种译法：水位线、水印。由于个人暂时分不清，所以后面一律以英文 Watermark 出现

01、前言

作为有追求的程序员，我们日常在写代码的时候往往都会运用很多奇技淫巧，不单单是为了炫耀我们的技术，更是为了追求更高的效率。了解局部性原理，可以有效的帮助我们理解和写出更好的代码，对于局部性原理可能有的小伙伴知道，有的小伙伴不知道，知道的小伙伴就当做复习知识点，不知道的小伙伴也没关系，接着往下看就知道了。

本篇文章是 《带你涨姿势的认识一下Kafka》系列第三篇文章，历史文章请戳

带你涨姿势的认识一下kafka

带你涨姿势是认识一下Kafka Producer

1 前言

先来回顾一下 Flink 基础的三兄弟：

• 数据来源 DataSource
• 数据转换 Transaformation
• 数据存储 DataSink

前面两篇笔记已经写了数据来源和转换如何使用，那么这篇当然就到了数据存储，接下来将会从以下角度介绍一下（喜闻乐见的 What / Why / How）~：

• 1 为什么要用 Sink
• 2 DataSink 是什么
• 3 如何使用（进阶使用，滑动时间窗口例子）

前言

不知不觉 JDK13 发布已有两个月，不知道各位有没有下载学习体验一番？每次下载安装之后，需要重新配置一下 Java 环境变量。等到运行平时的项目又需要切回之前 JDK 版本，这又需要重新环境变量。这么重复配置显然非常低效，又不能灵活切换版本。

所幸通过万能 Google 找到解决方案，使用 jenv 管理 JDK 版本。