发表于 | 分类于

大家好，我是鸭血粉丝（大家会亲切的喊我 「阿粉」），是一位喜欢吃鸭血粉丝的程序员，回想起之前线上出现 OOM 的场景，毕竟当时是第一次遇到这么 紧脏 的大事，要好好记录下来。

1 事情回顾

2 开始分析

  • 2.1 日志分析
  • 2.2 使用 MAT 分析 dump 文件
  • 2.3 根本原因

3 性能优化

  • 3.1 业务、代码逻辑梳理
  • 3.2 通过 VisualVM 进行对比

4 技术总结

  • 4.1 开发注意点
  • 4.2 应对故障注意点

5 多说两句

阅读全文 »

发表于 | 分类于

大家好，我是鸭血粉丝，今天是 2020 年的第二天，我翻来覆去，思来想去觉得是时候应该把 Java 极客技术的 2019 年总结一下了，话不多说往下看。

01、前言

2019 年已经过去了，现在陆陆续续的都要忙着写年终总结，《Java 极客技术》也陪伴了大家十个月的时间了（虽然我鸭血粉丝才出道几天），还记得第一篇文章《Java 诞生的趣事》 发布在 2019 年 02 月 25 日，这段时间也发过很多次文章给大家介绍《Java 极客技术》公号以及对应知识星球的故事，比如今天，我为他们站台！，总结丨两个月干火一个知识星球，看看我们都做了什么 。现在到了年底也该写年终总结了，这篇文章就给大家总结一下，这几个月《Java 极客技术》的故事，且听我阿鸭慢慢道来。

阅读全文 »

发表于 | 分类于

1 前言

在时间 Time 那一篇中，介绍了三种时间概念 Event、Ingestin 和 Process， 其中还简单介绍了乱序 Event Time 事件和它的解决方案 Watermark 水位线

（看过多篇文章后，决定喊它水位线，因为窗口触发条件是 Watermark > Window_end_time，有点像水流到达水位线后溢出，当然喊它水印也是可以的，全看个人爱好咯~）

前文请翻 时间 Time 和 Watermark，不过前面介绍比较浅，没能很好领会水位线的概念，所以本篇是作为补充，来加深理解~

阅读全文 »

发表于 | 分类于

01、前言

发布订阅系统在我们日常的工作中经常会使用到，这种场景大部分情况我们都是使用消息队列的，常用的消息队列有 Kafka，RocketMQ，RabbitMQ，每一种消息队列都有其特性，关于 Kafka 的使用和源码分析，公号前面有相关的文章，大家可以前往回顾一下，另外两款消息队列大家有需要可以自行研究，后续我们会出相应的介绍文章。这篇文章主要是给大家介绍 Redis 的发布订阅系统，很多时候我们可能不需要独立部署相应的消息队列，只是简单的使用，而且数据量也不会太大，这种情况下，我们就可以使用 Redis 的 Pub/Sub 模型。

阅读全文 »

发表于 | 分类于

场景引入

首先我们考虑一个场景：有一个整形数组, 我们希望通过调用一个工具类的排序方法就能对该数组进行排序. 请看下面的代码:

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
public class Strategy {
    public static void main(String[] args) {
        int[] arr = {5, 3, 1, 7, 2};
        new DataSorter().sort(arr);//调用工具类进行排序
        for(int i = 0; i < arr.length; i++){
            System.out.println(arr[i]);
        }
    }
}

class DataSorter{//用于排序的工具类
    public void sort(int[] arr){//调用sort方法进行排序, 此处使用冒泡排序
        for(int i = arr.length - 1; i > 0; i--){
            for(int j = 0; j < i; j++){
                if(arr[j] > arr[j + 1])
                    swap(arr, j, j  + 1);
            }
        }
    }

    private void swap(int[] arr, int i, int j){
        int temp = arr[i];
        arr[i] = arr[j];
        arr[j] = temp;
    }
}

Comparable接口

通过上面的代码, 我们能够轻易地对整形数组进行排序, 那么如果现在有了新需求, 需要对浮点类型数据进行排序, 排序工具类应该如何做呢?

或许你会想, 不如就新添加一个排序方法, 方法的参数类型为 float 类型, 把 int 类型数组的排序算法复制一遍不就可以了吗?

那如果我继续追问, 如果现在要对一只猫进行排序, 那应该怎么做呢? 猫的类如下：

1
2
3
4
5
6
class Cat{
    private int age;//猫的年龄
    private int weight;//猫的体重

    //get / set 方法...
}

你也许会顺着原来的思路回答, 照样 copy 一份排序的算法, 修改方法参数, 然后在比较的地方指定比较猫的年龄或体重不就可以了吗?

1
2
3
4
5
6
7
8
public void sort(Cat[] arr){//以猫数组作为参数
    for(int i = arr.length - 1; i > 0; i--){
        for(int j = 0; j < i; j++){
            if(arr[j].getAge() > arr[j + 1].getAge())//根据猫的年龄作比较
                swap(arr, j, j  + 1);
        }
    }
}

但仔细想想, 如果还要继续比较小狗, 小鸡, 小鸭等各种对象, 那么这个排序工具类的代码量岂不是变得很大? 为了能让排序算法的可重用性高一点, 我们希望排序工具中的 sort() 方法可以对任何调用它的对象进行排序.

你可能会想: 到对任何对象都能排序, 把 sort() 方法的参数改为 Object 类型不久可以了嘛. 这个方向是对的, 但是问题是, 当拿到两个 Object 类型对象, 应该根据什么规则进行比较呢?

这个时候我们自然而然地就希望调用工具类进行排序的对象本身就具备自己的比较法则, 这样在排序的时候就能直接调用对象的排序法则进行排序了.

我们把比较法则抽象为 Comparable 接口, 凡是要进行比较的类都要实现 Comparable 接口, 并且定义自己的比较法则, 也就是 CompareTo() 方法.

这样当我们在封装工具时, 就可以直接对实现了 Comparable 接口的对象进行比较, 不用担心比较的细节了.

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
public class Strategy {
public class Strategy {
    public static void main(String[] args) {
//      Integer[] arr = {5, 3, 1, 7, 2};//注意这里把int改为Integer, Integer是Object的子类
        Cat[] arr = {new Cat(3, 3), new Cat(1, 1), new Cat(5, 5)};
        DataSorter ds = new DataSorter();
        ds.sort(arr);
        for(int i = 0; i < arr.length; i++){
            System.out.println(arr[i]);
        }
    }
}
}

class DataSorter{//用于排序的工具类
    public void sort(Object[] arr){//参数类型为Object
        for(int i = arr.length - 1; i > 0; i--){
            for(int j = 0; j < i; j++){
                Comparable c1 = (Comparable) arr[j];//先转为Comparable类型
                Comparable c2 = (Comparable) arr[j + 1];
                if(c1.CompareTo(c2) == 1)//调用CompareTo()进行比较, 不关心具体的实现
                    swap(arr, j, j  + 1);
            }
        }
    }

    private void swap(Object[] arr, int i, int j){
        Object temp = arr[i];
        arr[i] = arr[j];
        arr[j] = temp;
    }
}

class Cat implements Comparable{
    private int age;
    private int weight;

    @Override
    public int CompareTo(Object o) {
        if(o instanceof Cat){//先判断传入的是否是Cat类对象, 不是则抛异常
            Cat c = (Cat) o;
            if(this.age > c.age) return 1;
            else if (this.age < c.age) return -1;
            else return 0;
        }
        throw null == o ? new NullPointerException() : new ClassCastException();
    }

    // get / set ...
    //toString() ...
}

interface Comparable{
    public int CompareTo(Object o);
}

Comparator接口

相信看了上面的 Comparable 接口来由, 大家会感觉整个设计又美好了一些, 但是其中还有漏洞. 我们在 Cat 类的 CompareTo() 方法中, 对猫的比较策略是写死的, 现在我们按猫的年龄比较大小, 如果哪天我们想按照猫的体重比较大小, 又要去修改源码了. 有没有扩展性更好的设计?

我们可以让用户自己定义一个比较器类, 对象可以根据用户指定的比较器比较大小.

整个逻辑是: 如果这个对象需要进行比较, 那么它必须实现 Comparable 接口, 但是它具体是怎么比较的, 则通过具体的 Comparator 比较器进行比较.

当然这里少不了多态, 我们首先要定义一个比较器接口 Comparator, 用户的比较器需要实现 Comparator 接口, 下面上代码:

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
public class Strategy {
    public static void main(String[] args) {
        Cat[] arr = {new Cat(3, 3), new Cat(1, 1), new Cat(5, 5)};
        DataSorter ds = new DataSorter();
        ds.sort(arr);
        for(int i = 0; i < arr.length; i++){
            System.out.println(arr[i]);
        }
    }
}

class DataSorter{//用于排序的工具类
    public void sort(Object[] arr){//参数类型为Object
        for(int i = arr.length - 1; i > 0; i--){
            for(int j = 0; j < i; j++){
                Comparable c1 = (Comparable) arr[j];//先转为Comparable类型
                Comparable c2 = (Comparable) arr[j + 1];
                if(c1.CompareTo(c2) == 1)//背后已经转换为使用Comparator的定义的规则进行比较
                    swap(arr, j, j  + 1);
            }
        }
    }

    private void swap(Object[] arr, int i, int j){
        Object temp = arr[i];
        arr[i] = arr[j];
        arr[j] = temp;
    }
}

class Cat implements Comparable{
    private int age;
    private int weight;
    private Comparator comparator = new CatAgeComparator();//默认持有年龄比较器

    @Override
    public int CompareTo(Object o) {
        return comparator.Compare(this, o);//调用比较器比较而不是直接在此写比较法则
    }

    // get / set / toString ...
}

interface Comparable{
    public int CompareTo(Object o);
}

interface Comparator{
    public int Compare(Object o1, Object o2);
}

//用户自己定义的, 按照猫的年龄比较大小的比较器
class CatAgeComparator implements Comparator{
    @Override
    public int Compare(Object o1, Object o2) {
        Cat c1 = (Cat) o1;
        Cat c2 = (Cat) o2;
        if(c1.getAge() > c2.getAge()) return 1;
        else if(c1.getAge() < c2.getAge()) return -1;
        else return 0;
    }
}

//按照猫的体重比较大小的比较器
class CatWeightComparator implements Comparator{
    @Override
    public int Compare(Object o1, Object o2) {
        Cat c1 = (Cat) o1;
        Cat c2 = (Cat) o2;
        if(c1.getWeight() > c2.getWeight()) return 1;
        else if(c1.getWeight() < c2.getWeight()) return -1;
        else return 0;
    }
}

关于策略模式的思考

在上面的例子中, 我们自己定义了 Comparable 接口和 Comparator 接口, 其实这两个接口都是 Java 自带的, 通过上面的代码示例, 想必大家也应该知道了为什么会有这两个接口。

其实 Comparable 定义的就是一种比较的策略, 这里的策略你可以理解为一个功能, 然而策略有了, 我们还需要有具体的策略实现, 于是便有了 Comparator 接口。

在比较对象的 Comparable 和 Comparator 中运用策略模式我认为有以下的好处：

  • 不同的类在比较时的行为不同，策略模式可以让它们在运行时动态选择具体的比较逻辑。
  • 方便对一个对象在不同的时候使用不同的比较策略，方便未来添加不同的比较策略。

但也有一个主要的缺点：

  • 因为每个具体的比较策略类都会产生一个新类，随着时间增长，系统需要维护的类数量可能会增加。
阅读全文 »

发表于 | 分类于

前言

GC 中文直译垃圾回收，是一种回收内存空间避免内存泄漏的机制。当 JVM 内存紧张，通过执行 GC 有效回收内存，转而分配给新对象从而实现内存的再利用。 JVM GC 机制虽然无需开发主动参与，减轻不少工作量，但是某些情况下，自动 GC 将会导致系统性能下降，响应变慢，所以这就需要我们提前了解掌握 GC 机制。当面对这种情况时，才能从容不迫的解决问题。另外 GC 机制也是 Java 面试高频考题，了解掌握 GC 是一项必备技能。

阅读全文 »

发表于 | 分类于

01、前言

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

1使用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 来查看最大慢日志条数。如下图。

2

设置命令

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

3

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

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

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

4

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

5

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;

image-20191211220858341

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)，通常指分布式系统在多台网络交互的机器上保存有相同的数据备份/拷贝。

阅读全文 »

发表于 | 分类于

1 前言

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

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

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

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

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

阅读全文 »