Nicksxs's Blog

derper是 tailscale 已经开源的 tailscale 中转服务，可以进行自己搭建，不然就是使用 tailscale 提供的 derper 节点，我的体验是在晚上高峰期会比较卡，所以有能力可以自建的话也是比较推荐的，不过相对比前面的设置会麻烦点

第一个就是默认这个是需要 https 的，所以需要给 derper 服务申请个域名，或者有了域名就加个解析，比如 dp.hello.com，申请完域名就需要申请证书了，这个刚好就学习下使用 acme.sh这个工具，还是非常不错的，我用的是腾讯云的域名解析服务，其实是收购的 dnspod 的服务，acme.sh 安装就很简单，一条命令

`

1

curl  https://get.acme.sh | sh

然后成功了之后就要把.zshrc 生效下，默认会把脚本路径加入到当前的 shell 的 rc 文件里，然后就是申请证书，但是有两种方式，一种就是在域名指定的 ip 机器对应的访问路径下放置验证的文件

1

acme.sh  --issue  -d domain.tld -d www.domain.tld  --webroot  /home/wwwroot/domain.tld/

比如这样指定 webroot，另一个中更方便的方式就是通过 dns 认证的方式，我这边以 dnspod 举例，这边要特别注意的是 dnspod 虽然被腾讯云收购，但是这个方式还是需要用 dnspod 原来自己的 api token 验证的

然后拿到生成的 id 跟 token 设置到环境变量里，需要保存好这个 token，后面是看不到了的

1
2

export DP_Id=123456
export DP_Key=xxxxxx

然后就可以用命令进行验证了

1

acme.sh --issue --dns dns_dp -d xxx.hello.com

这个是 dnspod 家的，其他的也可以在这里找到验证方式

申请完成后会把证书放在用户目录下的.acme.sh 目录中，记得把cer文件改成 crt，并且文件名只能是域名 xxx.hello.com.crt，我没试过其他的行不行，从别的文章里看到需要一致，然后就是启动 derper 了

我们通过 docker 的方式，

1
2
3
4
5
6
7
8
9

sudo docker run --restart always \
  --name derper -p 12345:12345 -p 3478:3478/udp \
  -v /$dir/.acme.sh/xxxxx.hello.com_ecc/:/app/certs \
  -v /run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock \
  -e DERP_CERT_MODE=manual \
  -e DERP_ADDR=:12345 \
  -e DERP_DOMAIN=xxxxx.hello.com \
  -e DERP_VERIFY_CLIENTS=true \
  -d ghcr.io/yangchuansheng/derper:latest

 前一个端口 12345可以自己随意定，后面$dir改成自己的.acme.sh目录所在的路径，然后

-v /run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock \ 这一行 和-e DERP_VERIFY_CLIENTS=true \ 是为了能够让 derper 能够安全一些，就是在本机开一个 tailscale 客户端，连接接到 headscale 服务，可以参考前面的添加节点，然后把这个启动客户端的进程映射进docker里面，因为本身 derper 就没有特别的认证逻辑，所以就让同一个headscale服务的客户端进程来验证是属于同一个headscale服务的节点才允许加入中转，实际这样就跑起来了一个 derper 服务这样可以用 docker 命令查看日志

sudo docker logs -f derper 查看是不是有问题，然后如果没有问题的话还不一定代表 derper 起来了，比较直接的方法就是直接打开域名加上端口的地址，比如 xxxx.hello.com:12345 这个,

显示这个就代表服务已经正常启动运行了，然后就是需要修改 headscale 的配置文件了，首先要设置 derper 的配置文件，类似这样

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

regions:
  100:
    regionid: 100
    regioncode: ahk 
    regionname: Aliyun Hongkong 
    nodes:
      - name: 100a
        regionid: 100
        hostname: xxxxx.hello.com
        ipv4:
        stunport: 3478
        stunonly: false
        derpport: 12345

regionid表示区域 id，一个区域下可以后多个 node，node的 name 是节点的唯一识别码，ipv4 可以不填，有 hostname 就可以，然后stunonly 是 false 表示不只使用 stun还可以使用 derp

然后就是修改 headscale 自身的配置文件，把共用的 derper 配置改成

上面的 urls 注释掉，后面的 paths 添加刚才的配置文件路径，这样就可以了，至于连接是不是走的这个

可以用 tailscale netcheck 查看最近的 derper 节点已经延迟，看到使用了自己的 derper 就对了

headscale 在前面两篇初体验和添加节点 主要是介绍了如何搭建和使用，但是这里有个很大的缺点，比如我在想要两地的网络能够连通，但是两地的网络内都不止一个机器，那想让他们连通就需要把它们都加入这个 headscale 所组成的虚拟局域网，并且每个都是这个虚拟局域网的ip，跟原来的 ip 地址不一样会比较难记忆，所以有没有办法不用这么麻烦呢，当然是有的，那就是 headscale 的路由功能。
原先比如我们有两个设备，在两地，通过headscale我把这两个异地节点都添加进去了，节点 A 的 ip比如是 10.0.0.1，另一个节点 B 是 10.0.0.2，在之前的状态下，我的节点 A 只能通过 10.0.0.2 来连接节点 B，如果节点 A 想要连接节点 B 所在地的局域网内部其他节点，我们就可以通过节点 B 的客户端登录的时候开启路由转发，这样节点 B 就会充当一个路由转发的功能，并且不需要通过10.0.0这个网段来访问，直接可以通过节点 B所在的局域网地址来访问，比如192.168.2.10，具体操作就是把客户端启动方式改成命令行的，主要就是 --advertise-routes, 指明需要转发的网段

1

tailscale up --advertise-routes=192.168.xx.0/24 --accept-dns=false --login-server=http://serverIp:serverPort --unattended  

前面的 192.168.xx.0 就是节点 B 所在局域网的网段，然后 login-server 是 headscale 的服务 ip 跟端口，这个本身客户端就会使用，另外这个还有一个前提的，需要开启服务器的端口转发，对于 Windows 其实默认就可以，Linux 的话就需要设置下

1
2
3

$ echo 'net.ipv4.ip_forward = 1' | tee /etc/sysctl.d/ipforwarding.conf
$ echo 'net.ipv6.conf.all.forwarding = 1' | tee -a /etc/sysctl.d/ipforwarding.conf
$ sysctl -p /etc/sysctl.d/ipforwarding.conf

到这里我们只完成了第一步，第二步需要在 headscale 服务端启用这条路由配置
首先可以用 sudo headscale routes 查看当前有的路由
sudo headscale routes enable -h 这里看下怎么启用，因为网上有些是用-i 指定哪一条路由的，但是我使用的这个版本是用-r 的
sudo headscale routes enable -r 1 然后用这个命令启用就行了


这样我们就能够很方便地在单个节点互连之后访问到对方局域网内的其他节点

之前买来玩客云作为轻nas使用，但是由于只能外接硬盘，并且是usb2.0的接口，使用体验不是特别好，并且前期作为老母鸡还能兑换视频会员这种，后面取消了就不怎么使用了，前阵子玩客云停止提供服务了，所以就想可以折腾下，比如Armbian这样的，可以作为轻量服务器使用，功耗也比较低，跑一些简单的docker还是可以的，

配置是这样的，存储小了点，其他就是一个普通小服务器的配置了，usb2.0有点弱，但是现在有一些是正常退役，还有很多是PCDN被禁了宽带以后咸鱼出售的，带上电源跟网线才30左右，还是比较有性价比的
首先机器有几个版本，主要是1.0跟1.3，要注意1.3版本的主板上有个混淆点，会有一个1.2的版本，指的是具体存储或者网卡等组件的版本，玩客云版本是较大的 V1.3，而1.0则是比较小的字体，而且据网上的资料，1.0版本是有个MAC地址的贴条

可以看上图的标示，箭头指向的是短接点，这是1.0版本的，1.3版本是找不到这个短接点，而是在反面（有S805芯片和存储的一面）
新版手边没有，借用一张恩山的图

这个在最开始我刷第一个的时候比较困扰我，因为不确定版本，网上又有很多都是只截一小块区域的图，也不知道相对位置
首先如果是从闲鱼买来的已经刷成PCDN，某心云的需要通过短接刷底包之后再刷入系统，可以先用吹风机热风吹一会后盖，然后用一字螺丝刀从SD卡槽把外层的一片壳撬开，然后通过十字螺丝刀拧开之后就可以把主板拿出来
然后需要镊子或者其他铁丝，能够短接的就行，外加一个双公头USB线
刷机工具包可以用我这个分享的

1
2

https://www.alipan.com/s/sd4Wi6TDzeP
提取码: 84or

第一步打开USB Burning Tool, 要短接刷入update.img

通过文件导入网盘里的 update.img，然后先用双公头USB线连接电脑的USB口和玩客云靠近HDMI口的USB口，如果方便最好接到电脑后置的USB口，防止不稳定刷机终端，接下来就需要短接了，这里的姿势要先短接好，保持稳定，然后插上电源线，这里如果连接成功就会在软件左上会显示一栏连接成功，如果电脑连接音响也会有叮咚这样的声音，接下去就可以点开始进行刷入底包了，这里最大的困难点就是保持短接稳定后插电源，并且继续保持稳定刷入底包，底包刷入会比较快，等到刷机进度条走完刷成功后就点停止，然后关闭软件，拔掉玩客云电源，拔掉USB
第二步是刷入Armbian系统，根据一些教程有些说需要先刷入5.8，我这边是直接刷入了5.9的系统，也就多一步，准备一个U盘，16G或者8G都行，先用Etcher把5.8系统刷入U盘，刷入完成后再关闭软件，推出U盘，将U盘插入玩客云上靠近网口的USB口，然后再通电，指示灯会蓝色-> 绿色 -> 蓝紫闪烁 -> 蓝色，这样就是刷机成功了，会需要一点时间，刷机完成后再把5.9的的刷入U盘，再继续刚才的步骤，此时需要把网线插入玩客云，等待正常亮灯显示后，在路由器上可以找到一个aml-s812的设备，在通过ssh连接，账号是root，密码是1234，进入系统后通过以下命令就可以刷入emmc了

1

cd /boot/install  sudo ./install.sh

完成后会自动断开，拔掉U盘后再用同样方法连接就可以了，后续怎么使用就是Linux相关的了，后面也可以讲下docker的操作，但要注意架构，这个是arm架构32位的

原先在 23 年初的时候调研过一些国产的大模型，包括复旦开源的 MOSS 和清华的 ChatGLM，那时候还是早期版本，需要在 Linux 上，并且有比较好的显卡，而且一般来讲都得是 N 卡，过程中需要安装 pytorch和比较多依赖，并且当时的效果也还比较差，所以后面就没有长期使用。
最近看到谷歌在 2 月份开源了大模型 Gemma ，gemma 的博客在这里，想要在本地运行这个模型在现在这个阶段也变得简单很多，因为我们有了 ollama 工具

可以通过这个工具来运行大模型，并且已经支持了谷歌开源的 Gemma

我这边本地是 MacBook Pro 14 寸的，m3 pro 的处理器，18g 内存，刚好可以用 7b 量化的模型

这里有推荐的模型和内存推荐匹配规则，16g 可以运行 13B 及以下模型
下载安装完后我们可以用以下命令

1

ollama run gemma:7b

这里需要拉取模型，约5.2g 大小，考虑网络原因可能会比较慢

我们可以简单来试试问个问题


看出来回答的还是比较丰富的，谷歌出品还是比较有水平的，不至于像 ChatGLM 最初版本的在不做调优的情况下甚至有点前言不搭后语
对于想使用 chatgpt 但是没条件，这也算是个低配平替了, 并且已经是个比较可用的了，同时也方便进行学习调优等
如果想要类似于 chatgpt 那样的网页版，可以安装 open-webui
可以通过 webui 访问 ollama 运行的大模型，
用 docker 启动的命令也贴一下

1

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

不过有个小问题就是 docker 镜像拉取会有点慢，可以添加下国内镜像加速

1
2
3
4
5
6
7

{
    "registry-mirrors": [
        "https://dockerproxy.com",
        "https://docker.mirrors.ustc.edu.cn",
        "https://docker.nju.edu.cn"
    ]
}

这里有一个小区别，Gemma 在多轮会话的时候会在前面的答案基础上再完善。

补充一个在 windows 环境下，cpu 跑模型的也是可行的

现在是大模型可以深入千家万户了，大家都可以尝试下，如果对日常的工作学习有一些效率上的提升也是好的

线程池在实际使用过程中，有时候在理解比较偏理论的时候会出现一些判断错误，这里我们就来看一个实际的案例

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

private static final ThreadPoolExecutor threadPoolExecutor =
            new ThreadPoolExecutor(1, 1,
                    0, TimeUnit.MINUTES,
                    new MyArrayBlockingQueue<>(2));
    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < 100; i++) {
            Thread.sleep(100);
            for (int j = 0; j < 3; j++) {
                threadPoolExecutor.execute(() -> {
                    int a = 0;
                });
            }
            System.out.println("===============>  详情任务 - 任务处理完成");
        }
        System.out.println("都执行完成了");
    }

MyArrayBlockingQueue 是我复制的 ArrayBlockingQueue 加了点日志，可以认为就是一样的，这种情况下
执行过程是怎么样的呢， 队列长度是 2，核心线程数和最大线程数都是 1，提交任务是采用了两层循环，内层是循环三次，往线程池里提交任务，然后内层循环完了以后会重新睡眠 100 毫秒
在进入下一次外层循环，如果能一眼看出来问题的说明对线程池了解得很深入了，如果没有的话我们就一起来看下
先说下结论，这个代码会出现拒绝异常

考虑下是什么原因呢，是不是我线程数太少了，放大一些，感觉符合直觉一点
修改成

1
2
3
4

private static final ThreadPoolExecutor threadPoolExecutor =
            new ThreadPoolExecutor(100, 100,
                    0, TimeUnit.MINUTES,
                    new MyArrayBlockingQueue<>(2));

然而还是一样

只不过晚了点出现，那么问题出在哪呢
为什么我要去重写这个 MyArrayBlockingQueue，就是为了找到原因，其实很多讲解线程池的都是讲了线程池的参数，什么队列是链表的，数组的
但是没有讲到我是怎么往队列塞任务，怎么从队列取任务的呢

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

public boolean offer(E e) {
           checkNotNull(e);
           final ReentrantLock lock = this.lock;
           lock.lock();
           try {
               if (count == items.length) {
                   return false;
               }
               else {
                   enqueue(e);
                   return true;
               }
           } finally {
               lock.unlock();
           }
       }

这里是往队列里塞任务，注意这里需要获得锁，
而对于获取任务呢

1
2
3
4
5
6
7
8
9
10
11

public E take() throws InterruptedException {
    final ReentrantLock lock = this.lock;
    lock.lockInterruptibly();
    try {
        while (count == 0)
            notEmpty.await();
        return dequeue();
    } finally {
        lock.unlock();
    }
}

注意这里也需要获得锁，当我一个线程池的线程数进入稳定状态，也就是保持一定数量的线程不变的情况下
上面是一种比较可能的情况，即核心线程数等于最大线程数，那么我在提交任务的时候是非常快的

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

if (command == null)
           throw new NullPointerException();
       /*
        * Proceed in 3 steps:
        *
        * 1. If fewer than corePoolSize threads are running, try to
        * start a new thread with the given command as its first
        * task.  The call to addWorker atomically checks runState and
        * workerCount, and so prevents false alarms that would add
        * threads when it shouldn't, by returning false.
        *
        * 2. If a task can be successfully queued, then we still need
        * to double-check whether we should have added a thread
        * (because existing ones died since last checking) or that
        * the pool shut down since entry into this method. So we
        * recheck state and if necessary roll back the enqueuing if
        * stopped, or start a new thread if there are none.
        *
        * 3. If we cannot queue task, then we try to add a new
        * thread.  If it fails, we know we are shut down or saturated
        * and so reject the task.
        */
       int c = ctl.get();
       if (workerCountOf(c) < corePoolSize) {
           if (addWorker(command, true))
               return;
           c = ctl.get();
       }
       if (isRunning(c) && workQueue.offer(command)) {
           int recheck = ctl.get();
           if (! isRunning(recheck) && remove(command))
               reject(command);
           else if (workerCountOf(recheck) == 0)
               addWorker(null, false);
       }
       else if (!addWorker(command, false))
           reject(command);
   }

再来看下这段代码，第一步只需要判断是否为空，第二步就是判断核心线程数量，明显我说的情况，前面两步就直接过去了
然后就是判断线程池运行状态和往队列里塞任务了，但是线程运行完一个任务主动从队列里获取则需要更多的逻辑
这样就造成了我往队列里塞任务会比获取任务快很多，队列一满，就会抛出拒绝异常
即使我把线程数量放大到 100 还是一样，只不过会出现的慢一点，那么口说无凭，我们来验证下，提交任务过快，那么我在提交
方法里做个延迟

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public boolean offer(E e) {
    checkNotNull(e);
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        if (count == items.length) {
            return false;
        }
        else {
            enqueue(e);
            return true;
        }
    } finally {
        lock.unlock();
        try {
            Thread.sleep(1000);
        } catch (InterruptedException ex) {
            throw new RuntimeException(ex);
        }
    }
}

这样就没啥问题了

除了最后这个加延时，其他的直接用 ArrayBlockingQueue 就可以实验，实操一下会对这个逻辑有更深的理解