逗号的博客

最近读到一篇非常好的文章 PostgreSQL 中 timestamp 与 timestamptz 的区别，也可以访问 https://japinli.github.io/2023/03/postgresql-timestamp/，读完这篇文章后学习到了两点

1. PostgreSQL 存在两个纪元，Unix 纪元（1970-01-01 00:00:00）和 PostgreSQL 纪元（2000-01-01 00:00:00），在底层存储系统存储的是时间相对于 PostgreSQL 纪元的数值。EXTRACT(EPOCH FROM source) 是基于 Unix 纪元的结果。
2. 顺藤摸瓜可以阅读 src/backend/utils/adt/timestamp.c 文件中的 timestamp_in 和 timestamp_out 函数，从源码上理解时间字符串的输入和输出逻辑。

因此本文的逻辑是基于显示的结果而言，从显示的结果推论可能的原因，只是为了方便理解。推荐阅读它而不是本文。

问题

我们假设区间的表示为 [start, end]，对于两个区间 A 和 B 如何判断它们是否重叠？

背景知识

全球共划分为 24 个时区，以本初子午线为基准，从 7.5°W 向东至 7.5°E ，划分为一个时区，叫中时区或零时区。在中时区以东，依次划分为东一区至东十二区；在中时区以西，依次划分为西一区至西十二区。东十二区和西十二区各跨经度 7.5°，合为一个时区。每个时区跨越经度 15°，相邻区域的时间相差 1 小时（这样 24 个时区刚好是 24 小时，地球自转一周）。

问题

在我们的业务中有一个生产者程序不停地向 message 表写入记录，简化的 message 表的结构如下所示

1
2
3
4
5
6
7

CREATE TABLE message
(
    id          SERIAL,      -- ID
    content     VARCHAR,     -- 消息内容
    create_time TIMESTAMPTZ, -- 创建时间
    PRIMARY KEY (id)
);

另外有一个消费者程序不停地读取 message 表的数据，这个消费者程序依赖一个称为“水位线”的时间戳，所有创建时间小于等于水位线的消息都已经处理，我们使用 consumer 表来记录当前的水位线

1
2
3
4
5
6

CREATE TABLE consumer
(
    id        SERIAL,      -- ID
    watermark TIMESTAMPTZ, -- 水位线
    PRIMARY KEY (id)
);

我们会有一个定时任务每隔一段时间调度一次消费者程序，消费者程序的主要逻辑是

1. 检查当前水位线

   1 2 3 4 5

   test=# SELECT watermark FROM consumer; watermark ------------------------ 2024-04-30 15:16:17+08 (1 row)

2. 使用当前水位线加载待处理消息

   1 2 3 4 5 6

   test=# SELECT content, create_time FROM message WHERE create_time > '2024-04-30 15:16:17+08' AND create_time <= NOW() ORDER BY create_time; content | create_time ---------+------------------------------- aaa | 2024-04-30 16:17:18.936795+08 bbb | 2024-04-30 17:18:19.956867+08 (2 rows)

3. 逐条处理消息，并用当前消息的创建时间更新水位线，最后一条消息处理完成时

   1 2 3 4 5 6 7

   test=# UPDATE consumer SET watermark = '2024-04-30 17:18:19.956867+08'; UPDATE 1 test=# SELECT watermark FROM consumer; watermark ------------------------------- 2024-04-30 17:18:19.956867+08 (1 row)

就当前的 SQL 版本模拟的逻辑而言在定时任务第 2 轮调度时将没有待处理消息。但是当我们使用 Java 语言实现上面的逻辑时我们发现在定时任务第 2 轮调度时内容为 bbb 的消息会再一次被处理。在 Java 版本的实现里我们使用了 java.util.Date 类型来表示 create_time 和 watermark。

问题

假设有一个 PDI（Kettle）Job，运行这个 Job 需要耗时 30 秒钟。现在每 10 秒钟调度运行一次这个 Job。我们的问题是这个 Job 的运行情况是怎样的？具体地说是上一个调度的 Job 还没有执行完就到了下一个调度的 Job 的执行时间，那么下一个调度的 Job 会执行吗？也就是定时任务如果执行的时间很长的话，那么下一次还能按时执行嘛？

• Case 1：无论上一次 Job 是否执行完成，下一次 Job 按照 10 秒钟的间隔准时开始；
• Case 2：上一次 Job 未执行完成，下一次 Job 不会开始执行；一旦上一次 Job 执行完成，下一次 Job 立即开始执行，中间没有间隔；
• Case 3：上一次 Job 未执行完成，下一次 Job 不会开始执行；上一次 Job 执行完成后等待 10 秒钟的间隔再开启下一次 Job 的执行；

Kettle 的定时任务是哪一种情况呢？

在 PostgreSQL 中执行如下的 SQL 语句

1

SELECT 'AND c1 = ''' || 5 || '''';

将输出 AND c1 = '5'。我们的疑问是 5 两边的单引号 ' 是怎么得到的？

通过前面几篇文章我们已经实现了将网关作为资源服务器并在网关实现认证和授权，其他服务将是一个纯粹的微服务，那么我们将问一个问题其他微服务如何获取到已授权用户的用户信息？

问题描述

通常授权服务是作为独立的服务进行部署的或者使用的是由其他服务商提供的服务。Spring Authorization Server 比较特殊，它既可以作为独立服务进行部署，就如在上一篇文章介绍的那样；又因为它是 Spring 体系下的一员，因此将它作为内部服务部署在 Gateway 后面又是完全可行的。但是在实践的过程中遇到了一点儿问题，下面是具体的问题描述。

我们将要实现这样一个微服务系统，将 Spring Cloud Gateway 作为 OAuth2 的资源服务器，在 Gateway 实现集中的统一的鉴权功能，各个微服务之间的调用不再单独鉴权。系统的规划如下表所示

example-auth 是一个独立的服务，它不会向服务注册中心注册自己，其他的服务，包括 example-gateway，均需要向服务注册中心注册自己。

我们有一个使用 Spring Cloud 技术栈开发的简单的商城项目 acomma/shop tag:spring-boot-2，现在要将它构建成 Docker 镜像并以容器的方式运行起来。