思有所皈，绪有所依

Hexo宣称支持GitHub Flavored Markdown Spec，这里记录一些常用语法。

创建索引

对大表进行分表

查询时使用with进行预处理（select in with）

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

WITH regional_sales AS (
    SELECT region, SUM(amount) AS total_sales
    FROM orders
    GROUP BY region
), top_regions AS (
    SELECT region
    FROM regional_sales
    WHERE total_sales > (SELECT SUM(total_sales)/10 FROM regional_sales)
)
SELECT region,
       product,
       SUM(quantity) AS product_units,
       SUM(amount) AS product_sales
FROM orders
WHERE region IN (SELECT region FROM top_regions)
GROUP BY region, product;

既然Spring Boot官方宣称3.0是未来10年的基石，那我们也有必要做一些储备和尝试。笔者用当前生产部署的一个项目，建立git分支进行升级测试，这里做一个记录，后续逐渐完善。

安装

官网下载IntelliJ IDEA 社区版

从Ultimate切换到Community

项目的运行可能会被标记为Unknown，没什么关系，在配置里删除掉，然后在要运行的Class文件上鼠标右键，重新运行即会自动创建

插件

grep console，定义控制台输出的日志样式。

Key Promoter X，在该使用快捷键的地方提醒你使用快捷键。

Alibaba Java Coding Guidelines，阿里巴巴代码规范约束插件，对代码规范等很有帮助，可以养成良好的代码规范，编程风格。

SonarLint，编写代码时修复错误和漏洞。

Json Helper，Json格式化插件。

AiXcoder Code Completer，代码智能提示（本来是搜索Codota，出来这个，还没测试效果）

Git Commit Template，提供了很好的 Git 格式化模版，规范Git提交。

Maven Helper，依赖分析工具。

SequenceDiagram，可以方便地可视化代码中的方法调用关系，以及方法之间的时序关系。

Statistic，统计代码量。

用Hexo写个人博客已经有一段时间了，但是一直没找到一个好的方式来发布到互联网上（既要省钱又要省事）：

1. 是否购买独立的域名？
2. 是否购买有公网IP的主机来部署？

今天终于发布出来了，采用“阿里云域名 + Cloudflare Pages”的组合，首年只花9元的域名钱，后续也只是域名续费。

现在感觉Spring Cloud的整个体系太重了，尝试看看Spring Boot + Dubbo 3.0

官方示例： Spring Boot 开发服务
内置对容器化部署的支持： Docker部署Dubbo跨主机IP访问解决方案

Dubbo超时设置的优先顺序，调用方的接口方法 > 调用方全局设置 > 提供方全局设置 > 提供方接口方法

dubbo-admin: 待探索

官方文档JobRunr Doc

安装

在Spring Boot上的安装非常简单，有Spring Boot Starter

Spring boot 2的Maven依赖包：

1
2
3
4
5

<dependency>
    <groupId>org.jobrunr</groupId>
    <artifactId>jobrunr-spring-boot-starter</artifactId>
    <version>5.1.3</version>
</dependency>

JobRunr从6.0开始支持Spring Boot 3：

1
2
3
4
5

<dependency>
    <groupId>org.jobrunr</groupId>
    <artifactId>jobrunr-spring-boot-3-starter</artifactId>
    <version>6.1.3</version>
</dependency>

配置application.yml，主要是开启/关闭 JobRunr 的Server和Dashboard，Server用来执行job，Dashboard则是在一个独立的端口提供网页看板：

1
2
3
4
5
6
7
8
9
10

org:
  jobrunr:
    background-job-server:
      enabled: true
    dashboard:
      enabled: true
      port: 8000
    database:
      #JobRunr创建表的默认前缀是jobrunr_
      skip-create: false

使用JobScheduler创建Job

1
2
3
4
5
6
7
8
9
10

@Autowired
private JobScheduler jobScheduler;
...

//这里使用了自定义的实体来保存任务信息，然后创建时指定了id，注意id如果已经存在则不会创建
//JobRunr的jobrunr_jobs表也记录了任务信息，其id跟这里给的id一一对应，所以借用这个机制可以扩展自定义的任务记录
SomeTask task = ...
jobScheduler.enqueue(UUID.fromString(task.getId()), () -> {
    someService.someMethod(task);
});

使用注解创建重复执行的任务(Job)

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

@Recurring(id = "per-day-trigger-job", cron = "0 0 7 * * *")
@Job(name = "每天的7时触发")
public void bizMsgPerDayTrigger() {
    ...
}

@Recurring(id = "per-minute-trigger-job", interval = "PT1M")
@Job(name = "每分钟触发")
public void bizMsgPerMinuteTrigger() {
    ...
}

Dashboard

Dashboard是一个网页看板，在这里可以查看任务的执行情况，也可以手动触发任务、删除任务。

个人觉得选用JobRunr，一方面是与Spring Boot集成比较方便，这样在开发和运维上比较节省人力和服务器资源，当然这可能是个双刃剑，对那些不差钱也不差人的场景来说，这是“缺点”；另一方面是Dashboard的可视化，会增加我们的掌控感。

有问题的Job会进入Scheduled状态

JobRunr建议在写Job的执行代码时，把异常抛出来，这样JobRunr就会把这个Job的状态设置为Failed，然后在Dashboard上可以看到这个Job的执行情况，如下图所示：

如果某个Job每次执行都抛异常，就会进入Scheduled状态，以更低的频率执行。

重复执行任务的手工触发和删除

有些任务，比如每天甚至每周才执行一次，如果想手工触发，可以在Dashboard上的RecurringJobs下，勾选Job，然后点击“Trigger”按钮触发，如下图所示：

任务的删除，主要是这种场景：代码做了修改之后，使用@Recurring和@Job注解申明的任务，名称变了或者不需要了，也就是代码里其实已经没有这个名称的Job了。这时候可以在Dashboard上的RecurringJobs下，勾选Job，然后点击“Delete”按钮删除。

PaaS - Platform as a Service，平台即服务
Baas - Backend as a Service，后端即服务
Serverless - 无服务

都是试图简化后端的复杂性和运维压力

Firebase是谷歌的一项服务，主要针对App开发，提供了通用的一些服务端功能，基本上一个App前端可以不依赖后端就可以开发一款应用。
Supabase是对标Firebase的开源实现。

Supabase目前来看，只适合负载比较小的应用，也就是一个Docker部署可以支撑的情况。这可能只是笔者的误解，看官方的文档时可以部署在Kubernates上，k8s是可以缩放的。但是k8s本身很复杂很重，基本上对个人开发者或者中小企业来说，只能是用云提供商的服务，这就没什么成本优势了。再说Supabase是基于PostgreSQL来提供一些核心能力，就笔者自己的经验来说，数据库用云服务商提供的最省事也最便宜，不然你需要购买CPU、内存和存储，也需要专业的人员来运维，后患很大。

参考：
Supabase

2022年Firebase十大替代平台

APISIX和KONG都是基于OpenResty开发的API网关，从目前看到的资料来看，APISIX的性能要好一些。

OpenResty在nginx上增加动态脚本能力(Lua)，主要是解决了nginx修改配置后必须reload的问题。这个耗时以秒计，而OpenResty是动态脚本，耗时就是一次admin api 请求，几毫秒。看官方的文档，一直在强调“同步非阻塞”，既可以充分利用nginx的非阻塞I/O模型，又能享受同步编程的简便性，也就是代码看上去就是同步执行代码，很好理解和开发，但其实执行是非阻塞的效率很高。同步非阻塞的开发体验应该是优于node.js的，只是javascript更流行。事实上nginx也被OpenResty启发，尝试在nginx上增加javascript来实现OpenResty类似的能力，但也没火起来。
参考：OpenResty的现状、趋势、使用及学习方法
参考：从openresty谈到rust

我按APISIX官方的文档用docker-compose的方式进行了简单尝试，发现APISIX还是非常重的，如果在API管理上没有很强的需求，没有必要使用APISIX。个人的体会，需要借助OpenResty的动态配置能力来实现业务的场景，才需要使用OpenResty或者更强（更复杂）的APISIX和KONG。

TODO: OpenResty值得研究一下

官方文档

随机查询

用随机函数的值来排序，以达到随机查询的目的；最好限制一个取数范围，不然对行数比较多的表来说，随机取数查询可能耗时会比较长。

select * fro some_table order by random() limit 100;

解决JPA不支持PostgreSQL双冒号的问题

冒号在JPA中是特殊符号，所以需要加转义字符

select * from some_table where details::varchar like 'ABC%';

Java中添加转义字符：

String strSql = "select * from some_table where details\\:\\:varchar like 'ABC%'";

长事务的查询与中断

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

# 查询
SELECT 
  pid, 
  datname AS db, 
  query_start AS start,
  now() - query_start AS lap, 
  query 
FROM pg_stat_activity 
WHERE state <> 'idle' and query not like '%pg_stat_activity%'
  and (now() - query_start) > interval '10 seconds';

# 取消（pid为前面查询的具体值）
select pg_cancel_backend($pid);

# 中断
select pg_terminate_backend($pid);