SSD 静态分离（会计、出纳设计两个角色） DSD动态分离（一个人(账号)即使被同时分配了出纳、会计两个角色，但一个会话期间只能使用一个角色）

Attr-RBAC: 基于属性的 RBAC(业务员只能查看其维护的客户信息，业务员组长能看所有组员维护的客户信息)

Rule-RBAC: 基于规则的 RBAC (系统只能在早上 9:00- 18:00才允许业务员进行业务操作)

一些重要的点

能看到就有对应的权限

能看到页面索引连接，就能读取索引下面的数据不同的人同一个页面看到的可能数据不一样能看到操作按钮，就有对应操作的权限

关注点分离

产研团队要注意在系统设计落地过程中各个角色的职责边界范围

RD、FE 关注点的差异 FE(Frontend): 关注权限 对 页面显示的影响和控制RD(Backend): 关注权限 对 数据流的影响和控制

角色说明表、角色 -权限矩阵表、权限-资源表

从 DDD的角度来说，每个角色、权限、资源点都是统一语言，可以让不同角色在不同层分别有清晰、一致的语义理解。角色 - 权限矩阵表：GUI 系统可以细分为页面、操作、数据三个维度的权限

原因嘛，就那么几个，但都挺有用：

轻松突破限制！ 有些公司或学校的网络可能会限制你访问GitHub这些网站。代理呢，就像一条“秘密通道”，能帮你绕过这些限制。速度快起来！ 有时候直接连接网络可能不怎么给力，通过代理服务器，你的连接会更快、更稳定。多一份安全！ 代理还能给你的网络多加一层保护，让你用起来更安心一些。

Git代理设置，几种方法随便你选！

你可以选择让所有Git操作都通过代理走（这叫全局设置），或者只让某个特定的仓库用代理（这叫局部设置）。1. 所有HTTP/HTTPS操作都走代理？没问题！

如果你希望所有的Git操作都通过代理进行，就像给它开了个“通用通道”：

如果是HTTP代理，就这样写！

git config --global http.proxy http://:

如果是HTTPS代理，也这么做！

git config --global https.proxy https://:

举个例子，给你看看：

git config --global http.proxy http://192.168.1.100:8080 git config--global https.proxy https://192.168.1.100:8080

如果你的代理需要用户名和密码，直接把它们写进URL里就行，很简单！ 2.不想用代理了？分分钟就能取消！

如果你不再需要代理了，随时可以把它关掉：

git config --global --unset http.proxy git config --global --unsethttps.proxy

3. 只给GitHub开“小灶”？当然可以！

如果你不想所有的网络流量都走代理，只希望连接GitHub的时候才用代理，那也没问题！你可以这样设置：

git config --global url."https://github.com/".proxyhttps://:

再给你个例子：

git config --global url."https://github.com/".proxyhttps://192.168.1.100:8080

这样一来，就只会在你访问https://github.com/的时候才走代理，是不是很方便？4. SSH连接GitHub也要代理？得另外设哦！

如果你的Git仓库是通过SSH方式连接GitHub的（就是那种git@github.com:user/repo.git格式的链接），那上面的HTTP/HTTPS代理可就不管用了！你得去改一下SSH的配置文件，通常在~/.ssh/config里：

Host github.com Hostname ssh.github.com Port 443 ProxyCommand connect-H : %h %p

比如这样（Sock 5 代理： -X 5 ）：

Host github.com Hostname ssh.github.com Port 443 ProxyCommand nc -X 5-x proxy_host : %h %p

小提醒： nc 使用 openbsd-netcat。 gnu-netcat 可能无法正常工作

代理到底设好了没？来，咱们检查一下！

想知道代理到底有没有设置成功？来，敲下这个命令，一看就知道了：

git config --global -l

要是看到里面有http.proxy或者url."https://github.com/".proxy这些信息，那就恭喜你，代理已经上线啦！

要是SSH代理，就试试这个命令：

ssh -T git@github.com

如果弹出来“Hi <你的用户名>! You've successfullyauthenticated...”这样的消息，那就恭喜你，搞定啦！ 超棒的！如果ssh有问题，命令后面加上 -v 参数，可以根据输出的 debug信息,查看工作流程，并进行简单的问题排查

遇到点小麻烦？别慌，都是些小问题！

代理信息不对？ 朋友，仔细看看你填的代理服务器地址、端口和账号密码是不是正确的，别弄错了哦！HTTP和SSH搞混了？ 记住，HTTPS代理是管HTTPS连接的，SSH代理是管SSH连接的，这两种方式可不能混着用！防火墙捣乱？ 哎呀，是不是你的电脑防火墙太“尽职”了，把代理连接给拦住了？检查一下防火墙设置！Git版本太旧？ 有时候Git的版本太老也会出问题，更新到最新版本试试，说不定就好了。工具没装好？ 如果你是用SSH代理，记得确保你需要的那些代理工具（比如connect、netcat）都已经安装好了，而且能正常运行！

只要你按照这些步骤来，相信很快就能把Git代理设置好，然后和GitHub顺畅地“交流”起来！祝你编码愉快，没有烦恼！

技术博客：确保Redis队列消息至少被消费一次——Yii2队列组件的可靠性增强

去年，我在Yii2的队列组件库yiisoft/yii2-queue中发起了一个PR（#516），旨在增强Redis驱动在进程崩溃时的消息可靠性，确保每条消息至少被消费一次。在这篇博客中，我将详细介绍这个问题的背景、解决方案以及实现过程中的关键讨论。背景介绍

在使用Redis作为队列驱动时，我们可能会遇到进程崩溃的情况。如果进程在处理消息的过程中意外终止，而消息尚未从队列中移除，那么这条消息可能会永久丢失，导致数据不一致或服务中断。为了解决这个问题，我们需要一种机制来确保即使进程崩溃，消息也能在恢复后被重新消费。解决方案

我的解决方案是通过模拟进程崩溃的场景，验证Redis队列在崩溃后能否正确恢复并重新消费消息。具体步骤如下：

模拟延迟任务：首先，我向队列中推送一个延迟任务，并等待其过期。触发Redis崩溃：在任务过期后，模拟Redis在尝试将任务从延迟队列移动到等待队列时崩溃（通过拦截rpush命令）。验证消息恢复：在Redis恢复后，运行队列处理器，验证任务能否被成功消费。

为了实现这个解决方案，我编写了一个单元测试，通过MockRedis客户端来模拟崩溃场景，并验证消息的恢复机制。 技术实现

在单元测试testConsumeDelayedMessageAtLeastOnce中，我完成了以下关键步骤：

创建延迟任务：使用createSimpleJob方法创建一个简单的延迟任务，并将其推送到队列中。模拟Redis崩溃：通过配置Redis客户端，使其在收到rpush命令时崩溃。这模拟了进程在尝试将任务从延迟队列移动到等待队列时崩溃的场景。运行队列处理器：在Redis恢复后，运行队列处理器，并验证任务能否被成功消费。断言消息计数：通过断言消息计数来验证任务是否仅被消费一次，确保没有重复消费或消息丢失的情况。

关键讨论

在PR的审查过程中，维护者samdark提出了一些宝贵的改进建议：

测试方法命名：建议将测试方法名从testConsumeMsgAtLeastOnce改为testConsumeDelayedMessageAtLeastOnce，以更明确地表达测试的是延迟消息场景。变量命名和注释：指出变量名和注释中的一些拼写错误和不清晰的地方，建议进行修正以提升代码可读性。异常处理：建议在catch块中添加注释，说明忽略异常的原因，以便其他开发者更容易理解测试逻辑。时间一致性：指出sleep(2)与注释中提到的“1秒”不一致，需要确认是否为预期行为。

这些建议帮助我进一步完善了测试代码，提升了其健壮性和可读性。未来展望

目前，这个PR已经根据社区反馈进行了多次迭代，测试代码更加健壮和清晰。这个增强将使得Yii2的Redis队列驱动在进程崩溃时更加可靠，为开发者提供更加稳定的服务。

通过这个PR，我不仅解决了 Redis队列在进程崩溃时可能丢失消息的问题，还学会了如何编写更加健壮和可读的单元测试。同时，我也深刻体会到了社区合作的重要性，以及通过不断迭代和完善来提升代码质量的过程。

如果你对这个PR感兴趣，欢迎在https://github.com/yiisoft/yii2-queue/pull/516上查看完整的讨论和代码实现。期待与大家一起交流和学习！

锁所需要具有的属性

1. 独享 - 在任意一个时刻，只有一个客户端持有锁
2. 无死锁 - 持锁客户端失联（崩溃、网络分区），锁仍然可以被自动释放
3. 容错 - 只要大部分Redis节点都活着，客户端就可以获取和释放锁

面临的问题

1. 系统层 - 网络分区、崩溃、重启等问题
2. Redis层 - Redis节点的崩溃、重启等问题
3. 客户端层 - 客户端的崩溃、重启等问题
4. 重入 - 同一个客户端多次获取锁
5. 锁续期 - 锁的有效期到了，但是业务还没有执行完，需要续期
6. 释放 - 释放锁的时候，锁已经被其他客户端获取
7. 时钟漂移 - 不同的Redis节点的时间不一致
8. 时钟回拨 - 时钟回拨导致锁的有效期不准确
9. 误删 - 误删其他客户端的锁

解决方法

1. 互斥性 - 通过SETNX命令实现
2. 无死锁 - 通过设置锁的过期时间实现
3. 容错性 - 通过大多数原则实现
4. 重入 - 通过客户端ID实现
5. 锁续期 - 通过锁的过期时间实现
6. 释放 - 通过客户端ID实现
7. 时钟漂移 - 通过设置锁的过期时间实现
8. 时钟回拨 - 通过设置锁的过期时间实现
9. 误删 - 通过客户端ID实现

算法

单机算法

1. 获取锁

   SET resource_name my_random_value NX PX 30000

2. 释放锁

1
2
3
4
5

if redis.call("get",KEYS[1]) == ARGV[1] then 
  return redis.call("del",KEYS[1]) 
else
  return 0 
end

分布式算法

1. 获取锁
   1. 生成一个随机的客户端ID
   2. 依次向N个Redis节点获取锁
   3. 如果大多数Redis节点都获取到了锁，那么认为获取锁成功
   4. 如果获取锁失败，那么向所有Redis节点释放锁

Yii2 Redis lock 代码实现

1. 随机数获取实现Yii::$app->security->generateRandomString 底层依赖https://www.php.net/manual/en/function.random-bytes.php

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

 /**
     * Acquires a lock by name.
     * @param string $name of the lock to be acquired. Must be unique.
     * @param int $timeout time (in seconds) to wait for lock to be released. Defaults to `0` meaning that method will return
     * false immediately in case lock was already acquired.
     * @return bool lock acquiring result.
     */
    protected function acquireLock($name, $timeout = 0)
    {
        $key = $this->calculateKey($name);
        $value = Yii::$app->security->generateRandomString(20);

        $result = $this->retryAcquire($timeout, function () use ($key, $value) {
            return $this->redis->executeCommand('SET', [$key, $value, 'NX', 'PX', (int) ($this->expire * 1000)]);
        });

        if ($result) {
            $this->_lockValues[$name] = $value;
        }
        return $result;
    }

    /**
     * Releases acquired lock. This method will return `false` in case the lock was not found or Redis command failed.
     * @param string $name of the lock to be released. This lock must already exist.
     * @return bool lock release result: `false` in case named lock was not found or Redis command failed.
     */
    protected function releaseLock($name)
    {
        static $releaseLuaScript = <<<LUA
if redis.call("GET",KEYS[1])==ARGV[1] then
    return redis.call("DEL",KEYS[1])
else
    return 0
end
LUA;
        if (
            !isset($this->_lockValues[$name])
            || !$this->redis->executeCommand('EVAL', [
                $releaseLuaScript,
                1,
                $this->calculateKey($name),
                $this->_lockValues[$name],
            ])
        ) {
            return false;
        }

        unset($this->_lockValues[$name]);
        return true;
    }

    /**
     * Generates a unique key used for storing the mutex in Redis.
     * @param string $name mutex name.
     * @return string a safe cache key associated with the mutex name.
     */
    protected function calculateKey($name)
    {
        return $this->keyPrefix . md5(json_encode([__CLASS__, $name]));
    }

N个协程交替打印数字，到达一个数值后终止

网友解法

网上搜索的解法大概如下，网友错别字地方已经修复

启动N个协程，共用一个外部变量计数器，计数器范围是1到100

开启N个无缓冲chan，chans[i]塞入数据代表协程i可以进行打印了，打印的数字就是计数器的数

协程i一直阻塞，直到chan[i]通道有数据可以拉，才打印

分析

大思路没有问题，但具体实现的小细节处理上存在两个问题。

• N 为 1 的时候存在死锁问题
• 程序运行完后，协程没有回收，这个比较严重。
  • 首先，破坏了谁申请、谁释放资源管理的基本设计原则
  • 其次，常驻内存运行时如果经常被其他协程调用，应用有 OOM 的风险。

只能作为一次性脚本调用，运行结束后整个进程被操作系统回收。针对两个问题做如下修正:

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
75
76
77

package main

import (
    "fmt"
    "sync"
)



var counter = 0

const CounterMaxValue = 100

func DoJob(GoRoutineNum int) {

    //用于控制业务逻辑
    sigChannel := make([]chan struct{}, GoRoutineNum)
    //用于控制协成是否终结
    quitSigChannel := make([]chan struct{}, GoRoutineNum)

    for i := 0; i < (GoRoutineNum); i++ {
        sigChannel[i] = make(chan struct{})
        quitSigChannel[i] = make(chan struct{})
    }

    mainRoutine := make(chan struct{})

    wg := sync.WaitGroup{}

    for i := 0; i < GoRoutineNum; i++ {
        wg.Add(1)
        go func(idx int) {
            defer wg.Done()
            //FOR:
            for {
                select {
                case <-quitSigChannel[idx]:
                    //break FOR
                    goto END
                case <-sigChannel[idx]:
                    fmt.Printf("goroutine-num:%d %d\n", idx, counter)
                    counter += 1
                    mainRoutine <- struct{}{}
                }

            }
        END:
            fmt.Printf("goroutine-num:%d end\n", idx)
        }(i)
    }

    wg.Add(1)

    go func() {
        wg.Done()

        for i := 0; i < CounterMaxValue; i++ {
            //<-mainRoutine
            sigChannel[i%GoRoutineNum] <- struct{}{}
            <-mainRoutine
        }

        ////使最后一个任务处理协成，进入信号等待状态
        //<-mainRoutine

        for i := 0; i < GoRoutineNum; i++ {
            quitSigChannel[i] <- struct{}{}
        }
    }()

    //mainRoutine <- struct{}{}
    wg.Wait()
}

func main() {
    DoJob(10)
}

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

#include<signal.h>
#include<unistd.h>

static int sleepFlag = 1;

static void alrm_handler(int signo){
    sleepFlag = 0;
}

int mySleep(int sec)
{
    signal(SIGALRM,alrm_handler);
    alarm(sec);
    
    while(sleepFlag);
    
    return 0;
}

开启优化选项后，程序变成了死循环。从下面的汇编代码，不难发现编译器优化了sleepFlag 的读取，导致了死循环。

volatile 使用场景总结^[1]

1
2
3
4
5
6
7
8
9

int  *output = (unsigned  int *)0xff800000;//定义一个IO端口；
int   init(void)
{
    int i;
    //会被优化为 *output = 9
    for(i=0;i< 10;i++){
        *output = i;
    }
}

背景

我是22年入职的公司。

在熟悉环境的过程中发现：公司对 Go的支持人力投入有限，构建过程缺少规范、没有指导文档。比我入职早的一位同事，靠自己东找找西找找，缝合了一个Gitlab 的 yml 文件。

我当时觉得这是一个很奇葩的事情，就拉上中间件团队、研效、基础设施团队的同事组了一个公司的Go 技术交流群。沟通过程中发现，构建 Go 基础镜像的Dockerfile 文件也丢失了，这下可好一件事变成了两件事。

针对 Gitlab 的编排流程和Go基础镜像的构建，结合自己的项目实际情况进行了造轮子。去年9月，研效团队把Go 基础镜像的构建的也接过手去了，对这件事算是画上了一个相对完满的句号。下面对造轮子的过程进行一个简要的回顾总结。

研发流程

先简单的说下 CI 流程

1. 开发人员提交代码到 Gitlab
2. Gitlab CI/CD 自动构建
3. 构建成功后，镜像推送到 Harbor
4. 研发人员去发版系统选择构建好的镜像进行发布到测试、正式环境

改造

改造 Golang 基础镜像

反解旧镜像Dockerfile

1

docker run -v /var/run/docker.sock:/var/run/docker.sock --rm alpine/dfimage ${PRIVATE_DOCKER_REPO}/base/xhs-golang:1.15 

从输出结果来看主要需要做了如下几件事情 1. 基础镜像使用debian:buster-20200803 2. copy go 1.15 的包到镜像内 3. 更改apt 镜像源 4. 修改时区、语言设置、环境变量 5.安装一些依赖使用的软件包

重新封装 Golang 基础镜像Dockerfile

基于反解后的信息，和同事先前做的 CI 脚本重新封装了一个 Golang的基础镜像。

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

FROM golang:1.18-bullseye

RUN  cat /etc/apt/sources.list && \
     sed -i "s/deb.debian.org/mirrors.tuna.tsinghua.edu.cn/g" /etc/apt/sources.list && \
     sed -i "s/security.debian.org/mirrors.tuna.tsinghua.edu.cn/g" /etc/apt/sources.list && \
     cat /etc/apt/sources.list && \
     apt update &&  \
     apt install upx -y && \
     rm -rf /var/lib/apt/lists/*

RUN cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime  \
         && echo 'Asia/Shanghai' > /etc/timezone  \
         && echo "alias ll='ls -l --color'" >> /root/.bashrc

ENV  GO111MODULE=on GOPROXY=https://goproxy.cn GOPRIVATE=code.devops.xiaohongshu.com

RUN git config --global url."git@code.devops.xiaohongshu.com:".insteadof "https://code.devops.xiaohongshu.com/" && \
    git config --global --add url."git@code.devops.xiaohongshu.com:".insteadof "http://code.devops.xiaohongshu.com/"

COPY id_rsa /root/.ssh/
COPY id_rsa.pub /root/.ssh/

RUN  ssh-keyscan code.devops.xiaohongshu.com > /root/.ssh/known_hosts && \
      chmod 600 ~/.ssh/id_rsa

1. 基于 Go 官方提供的最新镜像golang:1.18-bullseye进行构建
2. 修改镜像源、安装需要的用到的软件包、清理 apt 包缓存、更改时区
3. 配置 Go 私有仓库、共有仓库代理。
4. 配置密钥，防止 gitlab有些仓库因为权限问题无法拉取。密钥可以不配置，放在主机的某个文件路径下面，使用卷挂载的方式使进行共享。

改造 Golang应用程序运行时镜像

反解旧镜像Dockerfile

1

docker run -v /var/run/docker.sock:/var/run/docker.sock alpine/dfimage  ${PRIVATE_DOCKER_REPO}/base/xhs-debian:10

基础镜像的构建过程主要做了几件事： 1. 选定基础镜像： debian:buster-20200803（xhs-debian构建时的Debian latest 版本） 2. 本地化设置：更改时区、设置语言字符集、更改镜像源3. 安装了一些非所有场景都需要的软件

重新封装 Golang应用程序运行时镜像 Dockerfile

原理弄清楚，问题就很容易解决。下面对应用程序的基础镜像每一步做如下的优化升级：

1
2
3
4
5
6
7
8
9
10
11

FROM debian:stable-slim

RUN  cat /etc/apt/sources.list && \
     sed -i "s/deb.debian.org/mirrors.tuna.tsinghua.edu.cn/g" /etc/apt/sources.list && \
     sed -i "s/security.debian.org/mirrors.tuna.tsinghua.edu.cn/g" /etc/apt/sources.list && \
     cat /etc/apt/sources.list

RUN cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime  \
         && echo 'Asia/Shanghai' > /etc/timezone  \
         && echo "alias ll='ls -l --color'" >> /root/.bashrc
ENV LANG=C.UTF-8

1. 换一个比较精巧的OS ，最后选了 Debian Slim (↘️alpine vsslim)
   1. 镜像相对来说也比较小：删除了很多运行时用不到的东西
   2. glibc vs musl
      1. ↘️Functionaldifferences from glibc
      2. musl 跑纯 Go 的项目一般问题不大，但是碰到需要使用依赖 glibc的项目就很麻烦
   3. 包管理器，线上出现问题时，还能使用包管理器安装 Deb 包 排查问题
   4. 运行时用不到的软件就不装了，除了浪费空间、增加攻击面暂时也没发现其他用处~
2. 镜像源、语言、时区，照抄原来镜像的设置

效果

1. 镜像大小从 440M → 110M （alpine 能降到 36M ）
2. 285个中、高、致命漏洞 降低为 23 个低级风险问题

改造 .gitlab-ci.yml

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

set -x
# 基于 Dockerfile 构建镜像，并将构建后的镜像推送到私有镜像仓库
function docker_build() {
    local app_id=$1
    local docker_tags=$2
    docker build .  -t ${PRIVATE_DOCKER_REPO}/qa/"$app_id":"$docker_tags"
    docker login -u username -p passwordk ${PRIVATE_DOCKER_REPO}
    docker push ${PRIVATE_DOCKER_REPO}/qa/"$app_id":"$docker_tags"
}



# 更改时区，不然 date 函数时间会计算错误
sed -i 's/dl-cdn.alpinelinux.org/mirrors.tuna.tsinghua.edu.cn/g' /etc/apk/repositories
apk add -U tzdata
cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
CURRENT_DATETIME="$(date +%Y%m%d_%H%M)"


tags=$1
bin=$2
cp "${bin}" ./app
docker_build ${APP_ID} "${tags}_${CURRENT_DATETIME}"

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

# 此镜像用于执行 docker 运行时镜像的构建
image: ${PRIVATE_DOCKER_REPO}/library/docker:v1.0

# gitlab 关键字，分几个阶段
stages:
  - compile
  - publish

# 代码编译阶段
compile:
  stage: compile
  image: ${PRIVATE_DOCKER_REPO}/qa/itworkspace:go_1.21_latest

  before_script:
    - go version
    - ls -alh
  script:
    - go mod tidy
    - go build -o ./app_dir/http ./cmd/http.go
    - upx ./app_dir/http
  
  # 编译成功后，将产物共享给下一个阶段
  artifacts:
    paths:
      - "./app_dir"
      - "./conf"
    untracked: false
    # 编译成功后，才进行产物缓存
    when: on_success

# 镜像构建阶段
publish_http:
  stage: publish
  script:
    - cp ./conf/app.sit.yaml ./conf/app.yaml
    - /bin/sh ./build.gitlab.sh sit_http ./app_dir/http

参考资料

1. 见字如晤

   书名: 第一本Docker书

   作者: [澳]詹姆斯•特恩布尔（JamesTurnbull）

   出版年份: 2014-12

   评分: 7.3

1
2

gh auth login
gh auth refresh -h github.com -s delete_repo

批量删除仓库

待删除的仓库批量放入 github.repo.txt文本文件中，每行一个仓库名。

1

cat github.repo.txt | xargs -I {}  -n 1  gh repo delete {} --yes

请求 - 响应

双边通信本质来说是请求-响应模型，主动方发出一个服务请求，被动方给一个服务结果应答。事很简单，但实现起来确很费劲。

传输层协议提供信道传输模型-如TCP，应用层协议提供信息标准格式封装模型-如HTTP,RPC。

Thrift的设计方式对应用层协议设计有很好的参考意义

thrift

1
2
3

service HelloWorldService {
  string say(1: string username)
}

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

public class SimpleServer {
    public static void main(String[] args) throws Exception {
        ServerSocket serverSocket = new ServerSocket(ServerConfig.SERVER_PORT);
        TServerSocket serverTransport = new TServerSocket(serverSocket);
        HelloWorldService.Processor processor =
                new HelloWorldService.Processor<HelloWorldService.Iface>(new HelloWorldServiceImpl());

        TBinaryProtocol.Factory protocolFactory = new TBinaryProtocol.Factory();
        TSimpleServer.Args tArgs = new TSimpleServer.Args(serverTransport);
        tArgs.processor(processor);
        tArgs.protocolFactory(protocolFactory);

        // 简单的单线程服务模型 一般用于测试
        TServer tServer = new TSimpleServer(tArgs);
        System.out.println("Running Simple Server");
        tServer.serve();
    }
}

结合代码，从架构上看拆分了四层^[1]

• 服务层 HelloWorldServiceImpl
• 处理层 HelloWorldService.Processor
• 协议层 TBinaryProtocol.Factory
• 传输层 TServerSocket

分析

为什么是 4 层

正常来说一个系统会考虑这么几个最近本的问题：具体功能、吞吐量、作业时间,显然thrift考虑到了下面几个问题

1. 传输信道是什么？系统吞吐量如何？

2. 协议封装格式是什么？ 协议封装格式是否合法？

3. 一个系统不可能只有一个服务，不同服务请求的服务如何进行 路由分发？

4. 具体服务响应是什么，以何种封装格式返回？

设计者-使用者

一个系统永远可以从设计者与使用者两个视角去看。thrift也不例外，暂时叫做协议框架设计者与协议使用者，处理层是两者的边界，利用钩子（注入）进行关注点分离。

• 协议框架设计者

  关注的整体的效率吞吐量、idl compiler工具，

• 协议使用者

  关注的是工具易用性、接入成本。

标准 - 工具

相比HTTP,thrift在模型上来说改进上进步不大，都在应用层。但通过对idl增加约束，引入工具，在工程上前进了一步，形成接口描述统一语言，减少沟通歧义。

设计工具留意的其他点

• 学习成本

  带来额外的通信模型与工具学习成本

• 桥接

  以开头代码为例，idl生成的代码从一个项目角度来说是在接口层，接口层有一套自己的设计模型理念，服务层使用的工具有一套工具理念。这层代码的桥接，本质是两种理念的差异弥合

• 兼容性

  刨除标准版本升级导致的前向不兼容外，工具本身一定依赖其他工具，工具集合融入到另外的工具集合时就会遇到版本冲突问题。

参考资料

Hexo是最早使用的工具，样式精美，主题切换也是很方，便部署工具友好。年轻总爱折腾，16年切换到了Jekyll。Jekeyll主题很多，但切换麻烦。本地构建预览，每隔一段时间总是莫名的出一些问题，小问题不死人但很恶心人。

Jekyll 2 Org

有段时间用 Emacs 很上头， 感觉 Markdown 好难用，折腾了一段时间Org。DIY 友好，运维部署稍微有点麻烦。

Hexo

对于工具简单前段时间就想着牵回来了，这么多年了，牵回来也每个头绪，心烦意乱，往后拖延~

最近看 Manjaro 电报群 的劝退文https://blog.zhullyb.top/2021/01/01/Why-I-dont-recommend-Manjaro/发现这个Hexo主题不错，Fluid^[3]文档也不错，瞬间感觉有点世外桃源人了，趁着有点心气，赶紧折腾下，切换回来。

老二最好的策略就是模仿，恩，开干，Hexo + Fluid + Waline

Hexo 升级^[2][4]

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

// 配置镜像源
> npm config set registry https://registry.npmmirror.com

//以下指令均在Hexo目录下操作，先定位到Hexo目录
//查看当前版本，判断是否需要升级
> hexo version

//全局升级hexo-cli
> npm i hexo-cli -g

//再次查看版本，看hexo-cli是否升级成功
> hexo version

//安装npm-check，若已安装可以跳过
> npm install -g npm-check

//检查系统插件是否需要升级
> npm-check

//安装npm-upgrade，若已安装可以跳过
> npm install -g npm-upgrade

//更新package.json
> npm-upgrade

//更新全局插件
> npm update -g

//更新系统插件
> npm update --save

//再次查看版本，判断是否升级成功
> hexo version

// 安装 hexo 依赖
> npm i -d

// 更新 hexo 依赖
> npm update -d

Hexo + Fluid + Waline + Emacs + Markdown就是以后的写字基本工具了。

pkg 构建目录

`~/.cache/yay/pkg/`

安装过程有时会出现问题，手工介入，解决速度会快不少。先前装drawio的时候经常下载一般旧挂了，浏览器下载完后copy到目录 重新yay 可以继续往后执行。

安装过程修改 PKGBUILD

需要联公司VPN，本来琢磨 openconnect应该能解决问题，没想到某服自己单独玩了一套。安装EeasyConnect时，官方提供的最新的包版本号没有变，但是md5 发生了变化，不知道他们在搞什么鬼。

着急用，需要修改PKGBUILD 尝试了两个没有效果的解决方案yay --editmenu --saveyay -G <pkgname>，直接进入构建目录后，手动修改构建脚本快，改完后编译、安装一分钟不到解决问题

1
2
3

cd .cache/yay/easyconnect
md5sum 
makepkg -si

清缓存

1
2
3
4
5

yay -Sc

pacman -Qqtd| sudo pacman -Rs -

paru -Sc

跑了有一年多了前段时间看硬盘不足二十个G了，清清缓存节约了 80G

1
2

[2020-11-04T19:24:07+0800] [ALPM] running 'update-mime-database.hook'...
[2020-11-04T19:28:49+0800] [PACMAN] Running 'pacman -Syyu'

backup

系统引导修复

1
2
3
4
5
6

lsblk -f
vim /etc/fstab
mkinitcpio -P

grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable --recheck --force
update-grub

VirtualBox

VirtualBox– Cannot register the hard disk 解决办法^[1]

File -> Virtual Media Manager -> Removed existing images (note, I removed them only from the registry).

压缩 vdi 磁盘大小

vmdk 格式不支持，vdi 压缩前，需要先进入虚拟机中把没有使用的磁盘位置填充 0

windows工具：^[2]

https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete

1

sdelete64.exe -z c:  # 对 C 盘剩余空间写零，适合虚拟磁盘优化

Linux 工具：

1

dd if=/dev/zero of=./1.img bs=102400 status=progress 

Manjaro 宿主机中执行如下压缩指令

1

VBoxManage modifymedium  docs.vdi --compact

vmware

Wayland

wayland^[3][4][5][6]

fcitx5

1
2
3
4

#/etc/profile
export GTK_IM_MODULE=fcitx5
export QT_IM_MODULE=fcitx5
export XMODIFIERS="@im=fcitx5"

Firefox thunderbird

1

MOZ_ENABLE_WAYLAND=1

chromium

--ozone-platform-hint=autovivaldi-stable --ozone-platform-hint=autochrome://flags 裏面就可以開啓wayland

QT

 QT_QPA_PLATFORM="wayland;xcb"

Emacs

./configure --enable-largefile --with-all --with-json --with-imagemagick --with-threads --with-pgtk --with-native-compilation --with-native-image-api

Ref

GOPATH

go env|grep GOPATH

go mod

go mod 代理设置

1
2
3
4
5

go env -w GO111MODULE=on
go env -w GOPROXY=https://goproxy.cn,direct
go env -w GOPRIVATE=code.devops.xiaohongshu.com 
git config --global url."git@code.devops.xiaohongshu.com:".insteadof "http://code.devops.xiaohongshu.com/"
git config --global url."git@code.devops.xiaohongshu.com:".insteadof "https://code.devops.xiaohongshu.com/"

Goland

对 go get引入的包不能自动提示

有说需要清理缓存重新启动，有说需要 go mod vendor， 但都不起效，加上-u 选项就起效了 go get -u -x -v pkg_url

语言

channel

读写操作

一个流行的 Yii2 队列扩展，支持驱动支持DB,Redis,RabbitMQ,Bestalk,German等十多种技术架构

源码地址: https://github.com/yiisoft/yii2-queue

下面对以 Redis 为驱动的实现源码进行简要分析

特性

1. 延迟消息
2. 重试机制
3. 消息主题
4. 消费者组
5. 消费确认

数据结构

流程

PR

yii2-queue#516

维护的一个线上工单同步项目，业务方反馈工单不能同步。线上排查过程简单总结一下。

查看定时任务，没什么问题，每分钟会检测进程是否存活，挂掉的会拉起来，并且每天凌晨也会重启一下进程。

查看进程状态也是在S态，运行时间也无异常

日志中有一条如下记录：

1
2

invalid memory address or nil pointer dereference
exit....

很奇怪，日志记录 exit，但是进程却没有退出。

排查源码，结构逻辑类似下面代码样例

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
75
76
77
78
79

package main

import (
"fmt"
"github.com/Shopify/sarama"
"github.com/astaxie/beego/logs"
cluster "github.com/bsm/sarama-cluster"
"os"
"os/signal"
"runtime/debug"
"syscall"
)

var (
cfg struct {
Kafka struct {
Addrs  []string
Group  string
Topics []string
}
}
)

func bussiness_logic(message *sarama.ConsumerMessage) {
println("pass")
}

func main() {

go func() {

defer func() {
if err := recover(); err != nil {
fmt.Println(err)
fmt.Println("exit....")
}
}()

var (
kafkaConfig   = cluster.NewConfig()
KafkaConsumer *cluster.Consumer
err           error
)

kafkaConfig.Consumer.Return.Errors = true
kafkaConfig.Group.Return.Notifications = true

if KafkaConsumer, err = cluster.NewConsumer(cfg.Kafka.Addrs, cfg.Kafka.Group, cfg.Kafka.Topics, kafkaConfig); err != nil {
panic(err)
}

defer KafkaConsumer.Close()

var (
message      *sarama.ConsumerMessage
notification *cluster.Notification
)

for {
select {
case message = <-KafkaConsumer.Messages():
bussiness_logic(message)
case notification = <-KafkaConsumer.Notifications():
logs.Info("kafka notification:%v", notification)
case err = <-KafkaConsumer.Errors():
logs.Info("kafka error:%v", err)
}
}
}()

c := make(chan os.Signal, 1)
signal.Notify(c)
signal.Ignore(syscall.SIGPIPE, syscall.SIGWINCH, syscall.SIGHUP, syscall.SIGURG)

s := <-c
fmt.Println(s)
debug.PrintStack()
}

bussiness_logic 出现指针访问异常后，go 协程会被回收，执行defer语句。问题出在了这里，记录完日志后，没调用os.Exit(1)

1
2
3
4
5
6

      defer func() {
if err := recover(); err != nil {
fmt.Println(err)
fmt.Println("exit....")
}
}()

消息为什么会丢失？

• 协程 hbloop： 间隔一段时间向broker发送心跳的
• 协程 parseResponse,responseFeeder：会将获取到的 kafka批量消息存到内存 []*ConsumerMmessage{} 中,并通过管道chan *ConsumerMmessage发送出去，应用程序从而能一条一条的消费

原因

应用程序在消费其中一条数据时，业务处理逻辑处理出现内存异常，协程退出，系统回收。内存中剩余未消费的消息旧在哪里一直不会被消费，等到进程通过信号终止时，这些消息被丢弃

同类问题 demo

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

package main

import (
"fmt"
"sync"
"time"
)

func main() {

var f func()

c := make(chan int)
d := make(chan int)
wg := sync.WaitGroup{}
wg.Add(1)
    
f = func() {
defer func() {
if err := recover(); err != nil {
fmt.Println(err)
fmt.Println("exit....")
}
}()

for data := range d {
fmt.Printf("cosume %d\n ", data)

var i *int
*i = 1
fmt.Println(i, &i, *i)
}

}

go f()

go func() {
for {
print("-\n")
select {
case x, _ := <-c:
d <- x
}
}
}()

go func() {
for i := 0; i < 100; i++ {
fmt.Printf("producing %d:\n", i)
c <- i
}
}()
    
    go func() {
t := time.Tick(1 * time.Second)

for {
select {
case <-t:
print("--\n")

}
}
}()

time.Sleep(1 * time.Second)

wg.Wait()

}

35岁后还能干的动吗？总不能一辈子干大头兵吧？总得往上走一走吧，转管理、带项目、干产品、考公务员...？

感觉都很焦虑，随着岁数增长体力不支，家庭负担过大精力不够，和年轻全员工比会被公司抛弃，搞得好像行业呆的太久，就会被“体制化”无法融入社会再就业。

干的事情杂七杂八，没有目标方向感，挣扎在生死的边界线上。

但是仔细想想这就是现实吗，转行干哪一行不都面临这些问题？

//--------------------------------------------------------------程序员行业从大的方向来说是信息产业，行业前景很宽阔。

为什么不反过来想想我们做这些事情的目的是什么呢？社会价值是什么呢？互联网难到真是人类历史的一条弯路吗？

都说市场是一个无形的手，优化资产配置效率，但是不受管束的资本会把人推向深渊。

匹夫无罪，怀璧其罪，

继续干程序员 ？

转行

转 管理

转 PM

《读书》新刊 |王路：我的逻辑启蒙老师

怎样把书读得“四通八达”？（文/王路）

** 工程学方法 抓大方小，逐步求精 分而治之 编程随想单一信息源不可靠

这俩人同名

Liquidsyntax error (line 52): Unexpected character $ in

https://github.com/jekyll/jekyll/issues/5663

1

{{ ppp }}

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

➜  jekyll s
<internal:/usr/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require': libffi.so.7: cannot open shared object file: No such file or directory - 
...
...
...

➜  sudo ln /usr/lib/libffi.so -s /usr/lib/libffi.so.7

➜  jekyll s
<internal:/usr/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require': /usr/lib/libffi.so.7: version `LIBFFI_CLOSURE_7.0' not found (required by /home/
...
...
...


➜   gem install ffi

1
2

➜ pacman -Si libffi
➜ man ffi

初始实现是单线程，和import_records去掉多线程后的部分差不多。

读取Excel数据 --->发送到行政服务接口

安全起见线上操作放在了晚上进行。运行时发现每条数据导入消耗1s多，晚上十点开始跑这几千条数据想想都让人崩溃。

等着也是干等，下楼转两圈透透气，屋里龌龊的空气让人昏昏沉沉，寒冷让人清醒不少，突然想到为什么不用多线程呢？

第一版多线程和处理业务的程序糅合在了一起，跟屎一样难读。后面两天又抽了点时间重构了几个版本，分离出来一个线程池、迭代器和import_records。

清晰不少，但是迭代器被暴露了出来，需要import_records调用一下判断当前任务是否给当前线程处理，类似协程的思路。

暴露有好有坏，但已基本满足日常使用，可以往一边先放放了。读读书、看看电影，不亦乐乎：）。

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

import threading

def task_pool(thread_num, task_fn):

  if thread_num <= 0 :
      raise ValueError

  threads = []

  def gen_thread_checker(thread_id, step):

      base = 1
      i = 0

      def thread_checker():
          nonlocal i

          i += 1
          # print((thread_id,i,step, i < base or (i - base) % step != thread_id))

          if i < base or (i - base) % step != thread_id:
              return False

          return True

      return thread_checker


  for x in range(0, thread_num):
    threads.append(threading.Thread(target=task_fn, args=(x,thread_num, gen_thread_checker(x, thread_num))))

  # 启动所有线程
  for t in threads:
    t.start()
  # 主线程中等待所有子线程退出
  for t in threads:
    t.join()

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

import argparse
import re

import requests
from openpyxl import load_workbook
from requests import RequestException

import myThread

parser = argparse.ArgumentParser(description='美餐到店交易数据导入')
parser.add_argument('--filename', '-f', help='美餐到店交易数据 .xlsx 文件路径', required=True)
parser.add_argument('--thread_num', '-t', help='线程数量', default= 100, required=False)
parser.add_argument('--debug', '-d', help='调试模式', default= 0, required=False)
args = parser.parse_args()

filename = args.filename
thread_num = int(args.thread_num)
debug = args.debug

if debug:
    print((filename,thread_num,debug))


def add_meican_meal_record(data):
   pass

def import_records(thread_id, thread_number, thread_checker):
    wb = load_workbook(filename=filename)
    ws = wb.active

    for row in ws:
        #------------------------------------------
        if row[0].value is None:
            break

        if not thread_checker():
            continue
        #------------------------------------------

        if row[0].value == '日期' or row[0].value == '总计' or not re.findall('^\d{4}-\d{1,2}-\d{1,2}$', row[0].value):
            continue
        else:

            date = str.replace(row[0].value,'-', '')

            order_id = row[3].value
            restaurant_name = row[5].value
            meal_plan_name = row[6].value
            meal_staffid = row[10].value
            identify = row[11].value
    
            add_meican_meal_record({
                'orderId':order_id,
                'date': date,
                'meal_plan_name':meal_plan_name,
                'meal_staffid':meal_staffid,
                'identify':identify,
                'restaurant_name':restaurant_name
            })

myThread.task_pool(thread_num,import_records)