IMLANE

古代汉语音韵学

2025-05-07T15:20:00Z

四声分类

平上去入

平：平稳、不升不降的音调。现为阴平（一声）、阳平（二声）。
上：先降后升的音调。现为三声。
去：高到低的音调。现为四声。
入：以塞音（如-p、-t、-k）结尾的音节，发音短促。普通话中不存在，粤语等方言中存在。

古代四声：平声、上声、去声、入声。
现代四声：阴平（一声）、阳平（二声）、上声（三声）、去声（四声）。

平仄的划分

平声：属于“平”，包括古代汉语的平声（现代汉语的阴平和阳平，即一声和二声）
仄声：属于“仄”，包括古代汉语的上声、去声和入声（现代汉语的上声（三声）、去声（四声），以及部分方言中保留的入声）

K3s Node NotReady State

2025-02-11T17:54:00Z

master 上查看 node 状态，可见 devops010012007114 状态为 NotReady：

[app@devops010012007068 zhanglin]<20250120 14:26:35>$ k get nodes
NAME                 STATUS     ROLES    AGE      VERSION
devops010012007068   Ready      master   3y240d   v1.19.8+k3s1
devops010012007069   Ready      <none>   288d     v1.19.8+k3s1
devops010012007070   Ready      <none>   3y240d   v1.19.8+k3s1
devops010012007071   Ready      <none>   3y240d   v1.19.8+k3s1
devops010012007073   Ready      <none>   3y240d   v1.19.8+k3s1
devops010012007109   Ready      <none>   542d     v1.19.8+k3s1
devops010012007111   Ready      <none>   542d     v1.19.8+k3s1
devops010012007113   Ready      <none>   542d     v1.19.8+k3s1
devops010012007114   NotReady   <none>   207d     v1.19.8+k3s1
devops010012007116   Ready      <none>   542d     v1.19.8+k3s1

node devops010012007114 上查看 k3s-agent 状态，有报错：

[root@localhost app]# systemctl status k3s-agent -l
● k3s-agent.service - Lightweight Kubernetes
   Loaded: loaded (/etc/systemd/system/k3s-agent.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2025-01-20 12:20:21 CST; 2h 8min ago
     Docs: https://k3s.io
  Process: 9197 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS)
  Process: 9167 ExecStartPre=/sbin/modprobe br_netfilter (code=exited, status=0/SUCCESS)
  Process: 9148 ExecStartPre=/bin/sh -xc ! /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service (code=exited, status=0/SUCCESS)
 Main PID: 9209 (k3s-agent)
    Tasks: 10
   Memory: 122.8M
   CGroup: /system.slice/k3s-agent.service
           └─9209 /usr/local/bin/k3s agent

Jan 20 14:27:55 localhost.localdomain k3s[9209]: time="2025-01-20T14:27:55.207578649+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:00 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:00.220559879+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:05 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:05.233453150+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:10 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:10.246519473+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:15 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:15.259321936+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:20 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:20.272576559+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:25 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:25.285244932+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:30 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:30.297600069+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:35 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:35.313884545+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:40 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:40.326131507+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"

使用 journalctl 也可查看 log：

[root@localhost app]# journalctl -u k3s-agent -f
-- Logs begin at Mon 2025-01-20 12:20:12 CST. --
Jan 20 14:28:10 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:10.246519473+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:15 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:15.259321936+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:20 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:20.272576559+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:25 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:25.285244932+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:30 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:30.297600069+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:35 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:35.313884545+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:40 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:40.326131507+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:45 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:45.339057664+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:50 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:50.352345609+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:28:55 localhost.localdomain k3s[9209]: time="2025-01-20T14:28:55.364271075+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"
Jan 20 14:29:00 localhost.localdomain k3s[9209]: time="2025-01-20T14:29:00.377075556+08:00" level=error msg="Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag"

其中的报错：

Failed to retrieve agent config: Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server node-passwd entry, try enabling a unique node name with the --with-node-id flag

曾把我引入歧途，我一直以为是密码错误，或者是缺乏 --with-node-id flag。
但是注意到 or contents of '/etc/rancher/node/password' may not match server node-passwd entry，且发现 [root@localhost app]# hostname 是 localhost，
联想到服务器曾重启，hostname 好像被恢复成了默认，似乎重置 hostname 可能有用。

于是尝试：

[root@localhost app]# hostname devops010012007114

重启后：

[root@devops010012007114 app]#

此时注意到 hostname 已变为 devops010012007114。

然后回到 master 上查看状态，果然恢复了：

[app@devops010012007068 zhanglin]<20250120 14:29:36>$ k get nodes
NAME                 STATUS   ROLES    AGE      VERSION
devops010012007068   Ready    master   3y240d   v1.19.8+k3s1
devops010012007069   Ready    <none>   288d     v1.19.8+k3s1
devops010012007070   Ready    <none>   3y240d   v1.19.8+k3s1
devops010012007071   Ready    <none>   3y240d   v1.19.8+k3s1
devops010012007073   Ready    <none>   3y240d   v1.19.8+k3s1
devops010012007109   Ready    <none>   542d     v1.19.8+k3s1
devops010012007111   Ready    <none>   542d     v1.19.8+k3s1
devops010012007113   Ready    <none>   542d     v1.19.8+k3s1
devops010012007114   Ready    <none>   207d     v1.19.8+k3s1
devops010012007116   Ready    <none>   542d     v1.19.8+k3s1

TDengine 笔记

2024-06-14T14:47:00Z

基本概念

表（Table）

为充分利用其数据的时序性和其他数据特点，TDengine 采取一个数据采集点一张表的策略，要求对每个数据采集点单独建表（比如有一千万个智能电表，就需创建一千万张表），用来存储这个数据采集点所采集的时序数据。

超级表（STable）

超级表是指某一特定类型的数据采集点的集合。同一类型的数据采集点，其表的结构是完全一样的，但每个表（数据采集点）的静态属性（TAG）是不一样的

子表（Subtable）

当为某个具体数据采集点创建表时，用户可以使用超级表的定义做模板，同时指定该具体采集点（表）的具体标签值（TAG）来创建该表。通过超级表创建的表称之为子表。

标签（Tag）

标签是指传感器、设备或其他类型采集点的静态属性，不是随时间变化的，比如设备型号、颜色、设备的所在地等，数据类型可以是任何类型。

TAG 是一个很特殊的数据列：

属于静态数据，创建后无需更新及插入。
同一张子表里每一行数据都应具有相同的 TAG 值。
TAG 值在做 group by 或者 partition by 的时候可以带来极高的性能。
- 因为不同 TAG 组合的表在物理上存储在不同的连续地址上，相当于提前 group by 完成了，空间换时间。
- 比如 group by 配合 last_row 的时候，如果是 group by 的是 TAG 列，则可以直接去每张表中取最后一行，效率极高。
- 否则如果 group by 的是普通数据列，则需要遍历全表，性能非常差。

一张子表里同一个 TAG 列的值是一样的，无法在一张子表某个 TAG 列里存入不同的值。所以通过超级表创建的子表的数量，应该等于超级表每个 TAG 列里值的数量的乘积。比如，假设超级表有 TAG_1，TAG_2 两个 TAG 列，TAG_1 有 2 个值，TAG_2 有 3 个值，那么创建的子表数量就应该等于 2 * 3 = 6 张子表。不同的 TAG 值组合必须对应不同的子表，但是子表的名字本身跟 TAG 没有强关联性。

-- 先切换到指定database，否则show命令会报错(感觉像TDengine的bug)
use dispatcher_data;

-- 描述子表，可见有两个TAG列(type, enterprise_id)
describe tag_two_1;
-------------+---------+------+----+
field        |type     |length|note|
-------------+---------+------+----+
ts           |TIMESTAMP|     8|    |
timestr      |VARCHAR  |    12|    |
count        |INT      |     4|    |
type         |INT      |     4|TAG |
enterprise_id|VARCHAR  |    32|TAG |
-------------+---------+------+----+

-- 查看子表的TAG详细信息
-- 可见TAG值(type, enterprise_id)已经作为meta信息存入了，实际上每张子表的TAG信息必须是一致且不可变的
-- 此时即使我设置不同的TAG值尝试插入，也只有普通数据插入成功，后来设置TAG的值实际上是未使用的
show tags from tag_two_1;
----------+---------------+------------------------+-------------+-----------+----------+
table_name|db_name        |stable_name             |tag_name     |tag_type   |tag_value |
----------+---------------+------------------------+-------------+-----------+----------+
tag_two_1 |dispatcher_data|t_realtime_count_tag_two|type         |INT        |1         |
tag_two_1 |dispatcher_data|t_realtime_count_tag_two|enterprise_id|VARCHAR(32)|1Kf5ZyXsPU|
----------+---------------+------------------------+-------------+-----------+----------+

-- 查看超级表，可见TAG值(type, enterprise_id)
select * from t_realtime_count_tag_two limit 1;
-----------------------+-------+-----+----+-------------+
ts                     |timestr|count|type|enterprise_id|
-----------------------+-------+-----+----+-------------+
2024-06-09 09:33:03.100|       |    1|   1|1Kf5ZyXsPU   |
-----------------------+-------+-----+----+-------------+

-- 查看子表信息，看不到TAG值(因为反正本表内TAG值一样，无需显示)
-- 只能看到普通数据的值
select * from tag_two_1 limit 1;
-----------------------+-------+-----+
ts                     |timestr|count|
-----------------------+-------+-----+
2024-06-09 09:33:03.100|       |    1|
-----------------------+-------+-----+

基本操作

-- 创建数据库
CREATE DATABASE IF NOT EXISTS `dispatcher_data`
    SINGLE_STABLE 0  -- 允许创建多张超级表
    PRECISION 'us'  -- 时间戳精度微秒
    DURATION 1d
    KEEP 7d
    -- 其他的使用默认值
;

-- 查看数据库建表语句
SHOW CREATE DATABASE `dispatcher_data` \G;

-- 创建超级表
CREATE STABLE `dispatcher_data`.`t_top_info` (
    ts TIMESTAMP,
    `content` VARCHAR(2000)
) TAGS (
    `type` INT
)

-- 插入数据(`USING`语法)
INSERT INTO `dispatcher_data`.`t_top_info_1` USING `dispatcher_data`.`t_top_info`
    TAGS (1) VALUES (
    now(),
    'some content',
)

-- 插入数据(一般语法)
INSERT INTO `dispatcher_data`.`t_top_info` (
    tbname,  -- 子表名称，此项为必须
    ts,
    content,
    type  -- TAG
) VALUES (
    't_top_info_1',
    now(),
    'some content',
    1
)

git merge/rebase 用法

2024-06-13T11:47:00Z

开个坑

docker 笔记

2024-06-13T00:02:00Z

官方一键安装脚本

# 默认安装
curl -fsSL https://get.docker.com | bash -s docker

# 带镜像站安装
curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun

# `bash -s docker`这里的docker个人感觉是不需要的

添加代理或者镜像

本来添加代理或者镜像二选其一即可，但是实际发现代理非常的稳定有效，镜像目前不稳定有效，有些镜像可能获取不到或者有其他问题。

可以通过修改daemon.json(不存在可新建)文件来实现代理或者镜像。

# Linux, regular setup
sudo vim /etc/docker/daemon.json

# Linux, rootless mode
vim ~/.config/docker/daemon.json

# Windows
C:\ProgramData\docker\config\daemon.json

参考：

Docker daemon configuration overview

添加内容如下：

{
  // 代理是有效的
  "proxies": {
    "http-proxy": "http://proxy.example.com:3128",
    "https-proxy": "https://proxy.example.com:3129",
    "no-proxy": "*.test.example.com,.example.org,127.0.0.0/8"
  },
  // 登录阿里云控制台“容器镜像服务”后获取，这个不稳定有效
  "registry-mirrors": ["https://xxx.mirror.aliyuncs.com"]
}

参考：

最后重启docker服务：

# 重启
sudo systemctl daemon-reload
sudo systemctl restart docker

# 查看相应信息
sudo docker info

也可以通过http-proxy.conf文件来实现proxy

# 创建文件
sudo mkdir -p /etc/systemd/system/docker.service.d
sudo vim /etc/systemd/system/docker.service.d/http-proxy.conf

# 写入内容
[Service]
Environment="HTTP_PROXY=http://proxy.example.com:3128"
Environment="HTTPS_PROXY=https://proxy.example.com:3129"
Environment="NO_PROXY=localhost,127.0.0.1,docker-registry.example.com,.corp"

# 验证
sudo systemctl show --property=Environment docker

同样参考：

Docker daemon configuration overview

@RestController作用于接口和类的区别

2024-05-08T11:20:00Z

前言

最近发现 @RestController 作用于类上可以正常运行，作用于接口上无法正常运行，于是进行了一番探究。

探究

直接进行源码探究。查看 @RestConroller 注解，可见其本质就是 @Controller，而 @Controller 注解的本质其实又是 @Component，所以这里的本质其实就是 @Component 作用于接口为什么不能生效。

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Controller  // 注意
@ResponseBody
public @interface RestController {}

---------

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component  // 注意
public @interface Controller {}

---------

/**
 * Indicates that an annotated class is a "component".
 * Such classes are considered as candidates for auto-detection
 * when using annotation-based configuration and classpath scanning.
 *
 * <p>Other class-level annotations may be considered as identifying
 * a component as well, typically a special kind of component:
 * e.g. the {@link Repository @Repository} annotation or AspectJ's
 * {@link org.aspectj.lang.annotation.Aspect @Aspect} annotation.
 *
 * @author Mark Fisher
 * @since 2.5
 * @see Repository
 * @see Service
 * @see Controller
 * @see org.springframework.context.annotation.ClassPathBeanDefinitionScanner  // 注意
 */
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Indexed
public @interface Component {}

然后注意到 @Component 注解上方注释中提到了 ClassPathBeanDefinitionScanner 类，于是前去查看，并且其中有一个比较重要的方法 doScan：

protected Set<BeanDefinitionHolder> doScan(String... basePackages) {
    Assert.notEmpty(basePackages, "At least one base package must be specified");
    Set<BeanDefinitionHolder> beanDefinitions = new LinkedHashSet<>();
    for (String basePackage : basePackages) {
        // 注意findCandidateComponents
        Set<BeanDefinition> candidates = findCandidateComponents(basePackage);
        for (BeanDefinition candidate : candidates) {
            ScopeMetadata scopeMetadata = this.scopeMetadataResolver.resolveScopeMetadata(candidate);
            candidate.setScope(scopeMetadata.getScopeName());
            String beanName = this.beanNameGenerator.generateBeanName(candidate, this.registry);
            if (candidate instanceof AbstractBeanDefinition) {
                postProcessBeanDefinition((AbstractBeanDefinition) candidate, beanName);
            }
            if (candidate instanceof AnnotatedBeanDefinition) {
                AnnotationConfigUtils.processCommonDefinitionAnnotations((AnnotatedBeanDefinition) candidate);
            }
            if (checkCandidate(beanName, candidate)) {
                BeanDefinitionHolder definitionHolder = new BeanDefinitionHolder(candidate, beanName);
                definitionHolder =
                        AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, definitionHolder, this.registry);
                beanDefinitions.add(definitionHolder);
                registerBeanDefinition(definitionHolder, this.registry);
            }
        }
    }
    return beanDefinitions;
}

通过调试可以发现是否被加载到 Spring 中是在 findCandidateComponents 方法中进行的，继续查看：

public Set<BeanDefinition> findCandidateComponents(String basePackage) {
    if (this.componentsIndex != null && indexSupportsIncludeFilters()) {
        return addCandidateComponentsFromIndex(this.componentsIndex, basePackage);
    }
    else {
        // 注意这里
        return scanCandidateComponents(basePackage);
    }
}

此处继续进入 scanCandidateComponents：

private Set<BeanDefinition> scanCandidateComponents(String basePackage) {
    Set<BeanDefinition> candidates = new LinkedHashSet<>();
    try {
        String packageSearchPath = ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX +
                resolveBasePackage(basePackage) + '/' + this.resourcePattern;
        Resource[] resources = getResourcePatternResolver().getResources(packageSearchPath);
        boolean traceEnabled = logger.isTraceEnabled();
        boolean debugEnabled = logger.isDebugEnabled();
        for (Resource resource : resources) {
            if (traceEnabled) {
                logger.trace("Scanning " + resource);
            }
            if (resource.isReadable()) {
                try {
                    MetadataReader metadataReader = getMetadataReaderFactory().getMetadataReader(resource);
                    if (isCandidateComponent(metadataReader)) {
                        ScannedGenericBeanDefinition sbd = new ScannedGenericBeanDefinition(metadataReader);
                        sbd.setSource(resource);
                        // 注意isCandidateComponent
                        if (isCandidateComponent(sbd)) {
                            if (debugEnabled) {
                                logger.debug("Identified candidate component class: " + resource);
                            }
                            candidates.add(sbd);
                        }
                        else {
                            if (debugEnabled) {
                                logger.debug("Ignored because not a concrete top-level class: " + resource);
                            }
                        }
                    }
                    else {
                        if (traceEnabled) {
                            logger.trace("Ignored because not matching any filter: " + resource);
                        }
                    }
                }
                catch (Throwable ex) {
                    throw new BeanDefinitionStoreException(
                            "Failed to read candidate component class: " + resource, ex);
                }
            }
            else {
                if (traceEnabled) {
                    logger.trace("Ignored because not readable: " + resource);
                }
            }
        }
    }
    catch (IOException ex) {
        throw new BeanDefinitionStoreException("I/O failure during classpath scanning", ex);
    }
    return candidates;
}

继续调试发现 isCandidateComponent 里作用于接口 => false和类 => true的返回值是不同的，于是继续进入：

protected boolean isCandidateComponent(AnnotatedBeanDefinition beanDefinition) {
    AnnotationMetadata metadata = beanDefinition.getMetadata();
    // 注意metadata.isConcrete()
    return (metadata.isIndependent() && (metadata.isConcrete() ||
            (metadata.isAbstract() && metadata.hasAnnotatedMethods(Lookup.class.getName()))));
}

然后此处有一个 metadata.isConcrete() 方法，进入查看：

default boolean isConcrete() {
    return !(isInterface() || isAbstract());
}

此处显然可见，如果被注释的对象是接口或者抽象类，将返回 false，而如果是 false 的话，将不会被当做 Candidate，所以最终将不会被 Spring 载入使用。

Kafka 笔记

2024-02-02T23:20:00Z

配置

向一个 3 台机器的 Kafka 集群中创建 1 万个 topic，然后分别观察 /home/vagrant/kafka/kafka-logs 目录中的实际数据，
可见数据基本是均分的：

# 192.168.33.10
[vagrant@Kafka-1 kafka-logs]$ pwd
/home/vagrant/kafka/kafka-logs
[vagrant@Kafka-1 kafka-logs]$ ll | grep topic | wc -l
3344

# 192.168.33.11
[vagrant@Kafka-2 kafka-logs]$ pwd
/home/vagrant/kafka/kafka-logs
[vagrant@Kafka-2 kafka-logs]$ ll | grep topic | wc -l
3353

# 192.168.33.12
[vagrant@Kafka-3 kafka-logs]$ pwd
/home/vagrant/kafka/kafka-logs
[vagrant@Kafka-3 kafka-logs]$ ll | grep topic | wc -l
3303

Redis AOF 文件探究

2024-01-31T20:20:00Z

配置

编辑 redis.conf 文件：

# 启用 AOF 持久化模式
appendonly yes

# 各种 redis 操作的工作目录
dir /home/vagrant/redis-home

# AOF 文件存放的文件夹名
appenddirname "appendonlydir"

# AOF 基准名称
# 结合上面的配置，文件将存放在于：
# /home/vagrant/redis-home/appendonlydir
#  - /home/vagrant/redis-home/appendonlydir/appendonly.aof.1.base.rdb
#  - /home/vagrant/redis-home/appendonlydir/appendonly.aof.1.incr.aof
#  - /home/vagrant/redis-home/appendonlydir/appendonly.aof.manifest
appendfilename "appendonly.aof"

# 写入频率，通常推荐 everysec
appendfsync everysec

文件分析

# appendonly.aof.manifest 是清单文件
# 会记载哪个是 rdb 类型的文件，哪个是 aof 类型的文件
# type b 即 .base.rdb
# type i 即 .incr.aof
[vagrant@Redis-1 appendonlydir]$ cat appendonly.aof.manifest
file appendonly.aof.1.base.rdb seq 1 type b
file appendonly.aof.1.incr.aof seq 1 type i

# appendonly.aof.1.base.rdb 是快照文件
# 在 aof 文件过大的时候，redis 会自动把过旧的数据合并构建成一个 rdb 类型的快照文件
# 让后再在 aof 文件中记载增量变化，这样可以缩小 aof 文件大小
[vagrant@Redis-1 appendonlydir]$ cat appendonly.aof.1.base.rdb | hexdump -C
00000000  52 45 44 49 53 30 30 31  31 fa 09 72 65 64 69 73  |REDIS0011..redis|
00000010  2d 76 65 72 05 37 2e 32  2e 34 fa 0a 72 65 64 69  |-ver.7.2.4..redi|
00000020  73 2d 62 69 74 73 c0 40  fa 05 63 74 69 6d 65 c2  |s-bits.@..ctime.|
00000030  d5 3b ba 65 fa 08 75 73  65 64 2d 6d 65 6d c2 70  |.;.e..used-mem.p|
00000040  37 0d 00 fa 08 61 6f 66  2d 62 61 73 65 c0 01 ff  |7....aof-base...|
00000050  00 d3 de 03 2c 42 96 75                           |....,B.u|
00000058

# appendonly.aof.1.incr.aof 是增量文件
# 记载每次写入操作的增量命令
# *2 代表有 2 个操作数 (SELECT 0)
# $6 代表命令长度为 6 (SELECT)
# $1 代表数据长度为 1 (0)
# 后半部分的 `set key value`` 以此类推
[vagrant@Redis-1 appendonlydir]$ cat appendonly.aof.1.incr.aof
*2
$6
SELECT
$1
0

...

*3
$3
set
$3
key
$5
value

SpringBoot 笔记

2024-01-15T22:38:00Z

Initializer

# 官方
https://start.spring.io

# 阿里云
https://start.aliyun.com

JAR / WAR

如果希望使用 jar 启动的话，即类似 java -jar ohMySpringBoot.jar 的方式启动（微服务推荐方式），则 pom 中如下配置：

<packaging>jar</packaging>

<dependency>
    <!-- jar模式下此包可以不要 -->
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-tomcat</artifactId>
    <scope>compile</scope>
</dependency>

如果希望使用 war 的方式启动，则如下配置：

<packaging>war</packaging>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-tomcat</artifactId>
    <!-- 为了IDEA里可以调试，此处可以设为默认的compile -->
    <!-- 不过部署的时候似乎可能与外部的tomcat冲突 -->
    <!-- 如果冲突可以改为provided -->
    <scope>compile</scope>
</dependency>

数据库

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-jdbc</artifactId>
</dependency>
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
</dependency>

@SpringBootTest
class OhMySpringBootApplicationTests {
    @Autowired
    DataSource dataSource;

    @Test
    void contextLoads() throws SQLException {
        Connection conn = dataSource.getConnection();
        System.out.println(conn);
        conn.close();
    }

}


@RestController
public class IndexController {
    @Autowired
    JdbcTemplate jdbcTemplate;

    @RequestMapping("/")
    public Object index() {
        String sql = "select * from Student";
        Object object = jdbcTemplate.queryForList(sql);
        return object;
    }
}

打 jar 包

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-jar-plugin</artifactId>
      <version>3.1.2</version>
      <configuration>
        <archive>
          <manifest>
            <mainClass>co.zhanglintc.App</mainClass>
          </manifest>
        </archive>
      </configuration>
    </plugin>
  </plugins>
</build>

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <version>${spring-boot.version}</version>
    <configuration>
        <mainClass>co.zhanglintc.ohMySpringBoot.OhMySpringBootApplication</mainClass>
        <skip>false</skip>
    </configuration>
    <executions>
        <execution>
            <id>repackage</id>
            <goals>
                <goal>repackage</goal>
            </goals>
        </execution>
    </executions>
</plugin>

排错

webxml attribute is required (or pre-existing WEB-INF/web.xml if executing in update mode)

<properties>
    <failOnMissingWebXml>false</failOnMissingWebXml>
</properties>

<!-- Or -->

<plugin>
    <artifactId>maven-war-plugin</artifactId>
    <version>3.0.0</version>
</plugin>

打包完成的 jar 包过小，导致无法直接启动

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <version>${spring-boot.version}</version>
    <configuration>
        <mainClass>co.zhanglintc.ohMySpringBoot.OhMySpringBootApplication</mainClass>
        <!-- 检查此处，不能为true，否则此插件被跳过了 -->
        <skip>false</skip>
    </configuration>
    <executions>
        <execution>
            <id>repackage</id>
            <goals>
                <goal>repackage</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Spring 基础

声明 bean

// 通用注解，下记不适用时使用
@Component

// 用于 Dao 层
@Repository

// 用于 Service 层
@Service

// 用于 Controller 层
@Controller

简单类型赋值
```
@Value
```

引用类型赋值

// 由 Spring 提供， 默认赋值方式为 byType
@Autowired
// Autowired 需要赋值方式为 byName 时配合使用
@Qualifier

// 由 jdk 提供，默认赋值方式为 byName
// 如果 byName 失败会自动尝试 byType
// 高于 jdk 1.8 需要添加依赖 javax-annotaion-api
// （那么看起来还是用 Autowired 比较科学）
@Resource

@Component / @Bean

// 直接作用于类
@Component
public class Student {
    private String name = "lkm";
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
}

// 作用于方法，用于把方法返回的对象注入。没有源码时非常实用。
//
// @Configuration 相当于 <beans></beans>
// @Bean 相当于 <bean></bean>
@Configuration
public class WebSocketConfig {
    @Bean
    public Student student(){
        return new Student();
    }
}

激活 profiles 的方式

# 命令行方式是一种外部配置的方式，在执行java -jar命令时可以通过 --spring.profiles.active=test的方式进行激活指定的profiles
java -jar order.0.0.1-SNAPSHOT.jar --spring.profiles.active=dev > logs.info 2>&1 &

# Java系统属性方式也是一种外部配置的方式，在执行java -jar命令时可以通过-Dspring.profiles.active=test 的方式进行激活指定的profiles
# 注意：-D方式设置Java系统属性要在-jar前定义
java -Dspring.profiles.active=dev -jar order.0.0.1-SNAPSHOT.jar > logs.info 2>&1 &

# 编辑环境变量配置文件/etc/profile，添加名为 SPRING_PROFILES_ACTIVE 的环境变量
export SPRING_PROFILES_ACTIVE=dev

# 配置文件方式是最常用的方式，不过灵活性不强，局限性比较大，不建议使用这种方式来激活配置文件，我们只需要在application.yml配置文件添加配置即可
spring:
  profiles:
    active: dev
    
# 命令行方式 > Java系统属性方式 > 系统变量方式 > 配置文件方式

Mybatis

输出log：

mybatis:
 configuration:
   log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

# Or

logging:
  level:
    co.zhanglintc.ohMySpringBoot.mapper: debug

Misc

// 输出：
// file:/D:/_Git_for_me/IDEA/ohMyApp/target/classes/
//
// 相当于 `ohMyApp/src/main/resources/` 目录
// 也对应 `ohMyApp/target/classes/` 目录
System.out.println(App.class.getClassLoader().getResource(""));

// 输出：
// file:/D:/_Git_for_me/IDEA/ohMyApp/target/classes/co/zhanglintc/
System.out.println(App.class.getResource(""));

autossh 总是自动重连的探究

2023-10-11T21:38:00Z

背景

用树莓派做了个采集器，采集到的数据需要放到阿里云服务器的 MySQL 上。因为 MySQL 只监听了 127.0.0.1，所以需要做一个端口转发到到阿里云服务器。
又因为我希望如果端口转发挂掉后能自动重连，所以我选择了使用 autossh 来帮我完成这个工作。

使用的命令如下：

sudo autossh -f -M 666 -N -o "PubkeyAuthentication=yes" -o "StrictHostKeyChecking=false" -o "PasswordAuthentication=no" -o "ServerAliveInterval 10" -o "ServerAliveCountMax 3" -L localhost:1516:localhost:1516 -i /XXXXX/id_rsa user@server.com

开始使用后，我观察到采集器的 log 经常报错，基本都类似如下内容：

2023-10-11 18:59:42,897 [ERROR] MySQLDBManager.py <update_category:161> - e.errno: 2055, error: 2055: Lost connection to MySQL server at '127.0.0.1:3306', system error: 32 Broken pipe
2023-10-11 18:59:43,944 [ERROR] MySQLDBManager.py <get_category_line:134> - error: 2055: Lost connection to MySQL server at '127.0.0.1:3306', system error: 32 Broken pipe, sql:

全都是连接断掉的相关信息。

起初我还很高兴，这说明 autossh正在工作，我选择使用 autossh 进行自动重连是正确的。
我认为这只是网络不稳定，所以 ssh 断掉了，所以 autossh 帮我重连了 ssh，此时我丝毫没有怀疑 autossh。

但是后来我有一次 cat trace.log | grep error 的时候发现错误时间似乎特别有规律：

2023-10-11 14:00:29,714 [ERROR] MySQLDBManager.py <insert_multi:280> - e.errno: 2013, error: 2013: Lost connection to MySQL server during query
2023-10-11 14:10:00,456 [ERROR] MySQLDBManager.py <update_category:161> - e.errno: 2013, error: 2013: Lost connection to MySQL server during query
2023-10-11 14:10:31,360 [ERROR] MySQLDBManager.py <insert_multi:280> - e.errno: 2013, error: 2013: Lost connection to MySQL server during query
2023-10-11 14:20:14,978 [ERROR] MySQLDBManager.py <get_category_line:134> - error: 2013: Lost connection to MySQL server during query, sql: 
2023-10-11 14:20:15,025 [ERROR] MySQLDBManager.py <get_category_line:134> - error: 2055: Lost connection to MySQL server at '127.0.0.1:3306', system error: 32 Broken pipe, sql: 
2023-10-11 14:20:15,059 [ERROR] MySQLDBManager.py <get_category_line:134> - error: 2055: Lost connection to MySQL server at '127.0.0.1:3306', system error: 32 Broken pipe, sql: 
2023-10-11 14:20:16,554 [ERROR] MySQLDBManager.py <update_category:161> - e.errno: 2055, error: 2055: Lost connection to MySQL server at '127.0.0.1:3306', system error: 32 Broken pipe
2023-10-11 14:20:44,648 [ERROR] MySQLDBManager.py <insert_multi:280> - e.errno: 2013, error: 2013: Lost connection to MySQL server during query
2023-10-11 14:30:31,055 [ERROR] MySQLDBManager.py <update_category:161> - e.errno: 2013, error: 2013: Lost connection to MySQL server during query
2023-10-11 14:30:43,774 [ERROR] MySQLDBManager.py <insert_multi:280> - e.errno: 2013, error: 2013: Lost connection to MySQL server during query

可见错误有明显的的时间间隔 10 分钟。这就不太正常了，如此有规律的断线显然应该不是随机事件，而是有原因的。

由此我开始了我的调查，此时我依然没有怀疑 autossh。

调查

一开始我也没什么思路，先查了下 man autossh，倒是看到一个环境变量 AUTOSSH_POLL 它的默认值正好就是 600 秒，符合我观察到的 10 分钟间隔。
于是我修改了我的 autossh 命令：

export AUTOSSH_POLL=60; sudo autossh -f -M 666 -N -o "PubkeyAuthentication=yes" -o "StrictHostKeyChecking=false" -o "PasswordAuthentication=no" -o "ServerAliveInterval 10" -o "ServerAliveCountMax 3" -L localhost:1516:localhost:1516 -i /XXXXX/id_rsa user@server.com

在前面添加了 export AUTOSSH_POLL=60，然而并没有什么卵效果。

于是我又去 v2ex 发了个帖子：SSH 端口转发 10 分钟左右自动断开一般是什么原因？。

回复里提到了一个 StackOverflow 的提问：https://stackoverflow.com/questions/61732346/autossh-tunnel-getting-killed-after-10-minutes。
跟我的现象类似却又不同，它也是 10 分钟掉线，我也是。但是它是有多个 autossh 竞争端口，我并没有。
但是我看到它也提到了 AUTOSSH_POLL 这个参数，那么这个参数的嫌疑就很大了。

而且这个帖子里设置环境变量的写法与我不同，于是尝试修改为与那个回答一致：

sudo AUTOSSH_POLL=60 autossh -f -M 666 -N -o "PubkeyAuthentication=yes" -o "StrictHostKeyChecking=false" -o "PasswordAuthentication=no" -o "ServerAliveInterval 10" -o "ServerAliveCountMax 3" -L localhost:1516:localhost:1516 -i /XXXXX/id_rsa user@server.com

这次有了一点效果，log 中每次报错的时间从 10 分钟变为了 1 分钟，那么现在就比较明显的是 autossh 的问题了，而不是我起初怀疑的 ssh 的问题。
但是此时依然没有什么思路说到底是 autossh 的哪里不对。

尝试查看了系统日志 tail -n100 /var/log/messages:

Oct 11 18:40:11 raspberrypi autossh[18954]: starting ssh (count 1)
Oct 11 18:40:11 raspberrypi autossh[18954]: ssh child pid is 18955
Oct 11 18:41:26 raspberrypi autossh[18954]: timeout polling to accept read connection
Oct 11 18:41:26 raspberrypi autossh[18954]: port down, restarting ssh
Oct 11 18:41:26 raspberrypi autossh[18954]: starting ssh (count 2)
Oct 11 18:41:26 raspberrypi autossh[18954]: ssh child pid is 19068
Oct 11 18:42:41 raspberrypi autossh[18954]: timeout polling to accept read connection
Oct 11 18:42:41 raspberrypi autossh[18954]: port down, restarting ssh
Oct 11 18:42:41 raspberrypi autossh[18954]: starting ssh (count 3)
Oct 11 18:42:41 raspberrypi autossh[18954]: ssh child pid is 19182
Oct 11 18:43:56 raspberrypi autossh[18954]: timeout polling to accept read connection
Oct 11 18:43:56 raspberrypi autossh[18954]: port down, restarting ssh
Oct 11 18:43:56 raspberrypi autossh[18954]: starting ssh (count 4)
Oct 11 18:43:56 raspberrypi autossh[18954]: ssh child pid is 19295
Oct 11 18:45:11 raspberrypi autossh[18954]: timeout polling to accept read connection
Oct 11 18:45:11 raspberrypi autossh[18954]: port down, restarting ssh
Oct 11 18:45:11 raspberrypi autossh[18954]: starting ssh (count 5)
Oct 11 18:45:11 raspberrypi autossh[18954]: ssh child pid is 19446

只是能看到每分钟再自动重启，除此以外并没有什么有用的信息。

突然灵光一闪现想起来 StackOverflow 里提到了端口竞争，我似乎之前 ps -ef | grep ssh 的时候似乎发现过什么一个奇怪的端口：

root     20959     1  0 19:00 ?        00:00:00 /usr/lib/autossh/autossh    -M 666 -N -o PubkeyAuthentication=yes -o StrictHostKeyChecking=false -o PasswordAuthentication=no -o ServerAliveInterval 10 -o ServerAliveCountMax 3 -L localhost:1516:localhost:1516 -i /XXXXX/id_rsa user@server.com
root     20960 20959  0 19:00 ?        00:00:43 /usr/bin/ssh -L 666:127.0.0.1:666 -R 666:127.0.0.1:667 -N -o PubkeyAuthentication=yes -o StrictHostKeyChecking=false -o PasswordAuthentication=no -o ServerAliveInterval 10 -o ServerAliveCountMax 3 -L localhost:1516:localhost:1516 -i /XXXXX/id_rsa user@server.com

此处可以看到 -R 666:127.0.0.1:667，这说明 ssh 理应在远端服务器上创建一个 666 端口的监听。
但是我查过远端服务器，并没有观察到过这个端口。
同时需要注意到这个端口是一个小于 1024 的低位端口，这就比较危险了，似乎有可能是因为端口被服务器禁止启动了。

于是尝试将低位端口 666 改成高位端口 6666 后再次启用 autossh：

root     20959     1  0 19:00 ?        00:00:00 /usr/lib/autossh/autossh    -M 6666 -N -o PubkeyAuthentication=yes -o StrictHostKeyChecking=false -o PasswordAuthentication=no -o ServerAliveInterval 10 -o ServerAliveCountMax 3 -L localhost:1516:localhost:1516 -i /XXXXX/id_rsa user@server.com
root     20960 20959  0 19:00 ?        00:00:43 /usr/bin/ssh -L 6666:127.0.0.1:6666 -R 6666:127.0.0.1:6667 -N -o PubkeyAuthentication=yes -o StrictHostKeyChecking=false -o PasswordAuthentication=no -o ServerAliveInterval 10 -o ServerAliveCountMax 3 -L localhost:1516:localhost:1516 -i /XXXXX/id_rsa user@server.com

然后去远端服务器观察，终于发现远端服务器上也出现了 6666 的端口监听。
接着又进行了一个小时的运行观察，再也没有出现过端口转发断线的问题了。

由此问题解决。

总结

autossh 的原理是先启动自己，然后启动一个 ssh 子进程。然后因为使用了 -M 6666 参数， autossh 还会在本地启动两个监听端口： 6666 和 6667，并且在远端启动一个监听端口。

使用 netstat -ntlp 命令分别观察，可见正常的时候端口监听情况如下：

# Local
tcp        0      0 127.0.0.1:6666          0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:6667          0.0.0.0:*               LISTEN      -

# Remote
tcp        0      0 0.0.0.0:6666            0.0.0.0:*               LISTEN      11524/sshd: lane

然后 autossh 会往这些监听端口定时里发消息，以判断 ssh 端口转发是否还能正常工作，时间间隔正好是 AUTOSSH_POLL。
由此可以解释为什么之前会每 10 分钟和每 1 分钟断线重连一次。

我这次的情况就是远端监听端口没有启动成功，AUTOSSH_POLL 的时间到后，发送到远端的消息无法在传回来，于是 autossh 认为网络超时自动帮我重启了 ssh 子进程。

所以以后使用 autossh 的时候还要注意监听端口不要选择低位端口，否则可能会在远端启动失败，导致 ssh 总是被重启。