GzzhM

[LeetCode][hot100] 图论

Tue, 11 Aug 2026 00:00:00 +0000

200. 岛屿数量

思路 :

使用标记数组标记每一个走过的路地，并且计数。
如果没有走过路地，那么从当前路地节点走一遍bfs 跑完所有路地节点。

#define x first
#define y second
typedef pair<int,int> PII ;

const int N = 310 ;
bool st[N][N];
int cnt ;
PII q[N*2];
int n,m;
void init() {
    memset(st,0,sizeof(st)); 
    cnt = 0 ;
    n = 0 ;
    m = 0 ;
}

int wx[] = {1,-1,0,0} ;
int wy[] = {0,0,1,-1};

void bfs(int sx,int sy,vector<vector<char>>& g) {
    int hh  = 0 , tt = 0 ;
    q[0] = {sx,sy};
    st[sx][sy] = 1 ;
    
    while(hh <= tt) {
        PII t = q[hh ++ ];
            for(int i = 0 ; i < 4 ; i ++ ) {
                int dx = t.x + wx[i];
                int dy = t.y + wy[i];

                if(dx < 0 || dx >= n || dy < 0 || dy >= m ) continue;
                if(g[dx][dy] == '0' || st[dx][dy]) continue ;

                q[++tt] = {dx,dy};
                st[dx][dy] = 1;
            }
        }
}

class Solution {
public:
    int numIslands(vector<vector<char>>& grid) {
        init() ;
         n = grid.size() ;
         m = grid[0].size() ;

        for(int i = 0 ; i < n ; i ++ ) {
            for(int j = 0 ; j < m ; j ++ ) {
                if(grid[i][j] == '1' && !st[i][j]) {
                    bfs(i,j,grid);
                    cnt ++ ;
                }
            }
        }
        return cnt ;
    }
};

994.腐烂的橘子

腐烂的橘子

思路 :

和岛屿数量差不多。无非是让烂橘子进行bfs
计算每个烂橘子到新鲜橘子的最短距离。然后求一个最大值即可

因为 n,m = 10 . 所以直接这样子暴力了

#define x first
#define y second
typedef pair<int,int> PII ;

const int N = 20 ;
const int INF = 0x3f3f3f3f ;

int dist[N][N];
PII q[N*N];
int n,m;

bool st[20][20];
void init() {
    memset(dist,INF,sizeof(dist)); 
    n = 0 ;
    m = 0 ;
}

int wx[] = {1,-1,0,0} ;
int wy[] = {0,0,1,-1};

void bfs(int sx,int sy,vector<vector<int>>& g) {
    memset(st,0,sizeof(st)); 
    int hh  = 0 , tt = 0 ;
    q[0] = {sx,sy};
    dist[sx][sy] = 0 ;
    st[sx][sy] = 1;
    
    while(hh <= tt) {
        PII t = q[hh ++ ];
        for(int i = 0 ; i < 4 ; i ++ ) {
            int dx = t.x + wx[i];
            int dy = t.y + wy[i];
            if(dx < 0 || dx >= n || dy < 0 || dy >= m ) continue;
            if(g[dx][dy] == 0 || g[dx][dy] == 2) continue ;
            if(st[dx][dy]) continue;
            st[dx][dy] = 1; 
            dist[dx][dy] = min(dist[dx][dy], dist[t.x][t.y] + 1);
            q[++tt] = {dx,dy};
        }
    }
}


class Solution {
public:
    int orangesRotting(vector<vector<int>>& grid) {
        init(); 
        n = grid.size();
        m = grid[0].size();
    
        for(int i = 0 ; i < n ; i ++ )
            for(int j = 0 ; j < m ; j ++ ) {
                if(grid[i][j] == 2) {
                     bfs(i,j,grid);
                }
        }

        int ans = 0;
        for(int i = 0 ; i < n ; i ++ )
            for(int j = 0 ; j < m ; j ++ ) {
                if(grid[i][j] == 1 ) {
                    if (dist[i][j] == INF)return -1;
                    else ans = max(ans , dist[i][j]);
                }
            }
        return ans ;
    }
};

当然也可以使用多源 bfs 进行优化

class Solution {
public:
    int orangesRotting(vector<vector<int>>& grid) {
        int n = grid.size(), m = grid[0].size();
        int wx[4] = {1, -1, 0, 0};
        int wy[4] = {0, 0, 1, -1};

        queue<pair<int, int>> q;
        int fresh = 0;

        // 所有烂橘子同时入队，作为多个源点
        for (int i = 0; i < n; i++) {
            for (int j = 0; j < m; j++) {
                if (grid[i][j] == 2) {
                    q.push({i, j});
                } else if (grid[i][j] == 1) {
                    fresh++;
                }
            }
        }

        if (fresh == 0) return 0;

        int minutes = 0;
        while (!q.empty()) {
            int sz = q.size();
            bool infected = false;

            // 同一分钟内，当前层全部扩散完
            for (int i = 0; i < sz; i++) {
                auto [x, y] = q.front();
                q.pop();

                for (int k = 0; k < 4; k++) {
                    int dx = x + wx[k];
                    int dy = y + wy[k];
                    if (dx < 0 || dx >= n || dy < 0 || dy >= m) continue;
                    if (grid[dx][dy] != 1) continue;

                    grid[dx][dy] = 2;   // 标记已腐烂，避免重复入队
                    q.push({dx, dy});
                    fresh--;
                    infected = true;
                }
            }

            if (infected) minutes++;
        }

        return fresh == 0 ? minutes : -1;
    }
};

207. 课程表

课程表

思路 :

主要考察的是拓扑排序

拓扑排序我们的方法是

查找所有入度为0的点进去队列，然后减少其关联的点
然后再重新入所有入度为0的点

const int N = 4e3 + 10 ;

int h[N] , e[N], ne[N], idx;

int d[N] ;

int num ;
 
 
void init(){
    memset(h,-1,sizeof(h));
    memset(e,0,sizeof(e));
    memset(ne,0,sizeof(ne));
    memset(d,0,sizeof(d));
    idx = 0 ;
    num = 0 ;
}

// a -> b 
void add(int a,int b) {
    e[idx] = b;
    ne[idx] = h[a];
    h[a] = idx ++ ;
}

bool topsort() {
    int cnt = 0 ;
    queue<int> q;
    for(int i = 0;  i < num ; i ++ ) {
        if(!d[i]) q.push(i);
    }

    while(!q.empty()) {
        int t = q.front() ;
        q.pop () ;
        cnt ++ ;
        for(int i = h[t] ; i!= -1 ; i = ne[i]) {
            int j = e[i] ;
            d[j] -- ;
            if(!d[j]) q.push(j);
        }
    }
    return cnt == num; 
}


class Solution {
public:
    bool canFinish(int numCourses, vector<vector<int>>& prerequisites) {
        init(); 
        num = numCourses ; 

        for(auto x : prerequisites) {
            int a = x[0];
            int b = x[1];
            add(a,b);
            d[b] ++ ;
        }

        return topsort();
    }
};

208. 实现 Trie (前缀树)

实现 Trie (前缀树)

Tire 的实现思路

定义 son[p][u] ; 表示第 p 层节点是否有值 u
然后再进行顺序即可

class Trie {
static const int N = 4e4 + 10 ;
int son[N][26];
int idx ;
bool isEnd[N];

public:
    Trie() {
        memset(son,0,sizeof(son));
        memset(isEnd,0,sizeof(isEnd));
        idx = 0 ;
    }   
    
    void insert(string word) {
        int p = 0 ;
        for(auto x : word) {
            int u = x-'a';
            if(!son[p][u]) son[p][u] = ++idx; 
            p = son[p][u];
        }
        isEnd[p] = 1; 
    }
    
    bool search(string word) {
        int p = 0 ;
        for(auto x : word) {
            int u = x-'a';
            if(son[p][u]) p = son[p][u];
            else return false;
        }
        return isEnd[p];
    }
    
    bool startsWith(string prefix) {
        int p = 0 ;
        for(auto x : prefix) {
            int u = x-'a';
            if(son[p][u]) p = son[p][u];
            else return false;
        }
        return p ; 
    }
};

/**
 * Your Trie object will be instantiated and called as such:
 * Trie* obj = new Trie();
 * obj->insert(word);
 * bool param_2 = obj->search(word);
 * bool param_3 = obj->startsWith(prefix);
 */

AiCoding

Tue, 11 Aug 2026 00:00:00 +0000

前言

由于不少面试最近都增加了 Ai Coding 的题目特别先来熟悉一下

看了一眼 LeetCode 和牛客发现只有牛客有所以单独开辟一个专栏看一下

HelloWorld

做这道题可以看到右边有一个 AI Agent。可以沟通第一题很简单直接给出了做法。

具体做法预计就是

把自己的思路写到一个文档里面。
然后@Agent 进行执行

感觉和日常开发一样。另外我们最终文件是可以编辑的。

不过这里竟然没有满分，只有97分

我们发现过程分占了很多 70 分去了。结果分只有30分。看来 AI coding 更注重的不是算出结果

这个过程分没有给出合理的解释不过看现有的维度有

对话的轮次
用时
接受 AI 建议
拒绝 AI 建议
运行的次数
Token 输入
Token 输出

因此可以总结出第一个高分思路

目的 :

xxxx

思路 :

根据 xxxx
通过 xxxx
实现 xxxx

要求 :

优化文字回答内容,要求清晰简单

下面我们继续看下一题吧

卡牌翻翻乐

这道题一开始编写了一个 soultion.md . 之前开发的习惯, 喜欢使用 md 存放思路然后@给Agent。因为之前输入的prompts不能太长。使用文件传入 Cursor会优化

简单给了要求和示例以及题目给的描述就直接给AI了

这里增加了一轮回答因为我 md 内容中是 logic.js , AI访问不到 ,让我重复提交了一次 commit 应该是 js/logic.js

第一次抽奖没抽出来，功能性只有70分。看了一下发现我实现的效果和预期效果差点意思。所以又使用 upgrade 根据产品的角度额外调整了一下

soultion.md :

目的 : 完善 @js/logic.js 的逻辑。 使得 @index.html 能够实现 翻牌数字匹配的游戏

思路 :
function flipCard(board, index)
board 是牌桌数组。
每个位置为 null，或一个 [value, faceUp] 二元数组。
value 是整数，faceUp 是布尔值。
null 表示该位置当前没有牌。
index 使用从 0 开始的数组下标。
调用时，index 一定指向一个 [value, false]；牌桌中至多有一个 [value, true]。
返回处理后的完整牌桌，数组长度和元素格式不变。可以修改传入数组，也可以返回新数组。


要求 :
1. 保留文件末尾的导出方式：
if (typeof module !== "undefined") module.exports = { flipCard };
if (typeof window !== "undefined") window.flipCard = flipCard;

2. 优化文字回答的内容,要求简单清晰


示例：
flipCard(
  [[1, false], [2, false], [1, false], [2, false]],
  0
);
// 返回：
// [[1, true], [2, false], [1, false], [2, false]]
保留文件末尾的导出方式：
if (typeof module !== "undefined") module.exports = { flipCard };
if (typeof window !== "undefined") window.flipCard = flipCard;

upgrade.md :

优化现有的 @js/logic.js 逻辑, 保证 @index.html 中的逻辑符合如下内容 :

目的 :

1. 我们如果点开两个不一样的牌, 需要清空两个牌的展示。不需要保留最后一次牌的内容 

相关资料可以参考 :

@solution.md

第一次提交后的分数很低。这个评价也很扯，认为我直接引用文件没有思考

然后第二次我尝试把文件的内容塞到 prompts里面进行求解。并且一次命中。得分也只有77分

虽为单轮委托且缺乏显式校验与迭代过程

我不确定这个显示校验是什么，写一个ut ？迭代过程可能就是缺少了多轮对话毕竟我们是一次命中的。

总结

做题不和开发一样。尽量使用 prompts的形式进行避免使用 markdown @file 的形式
对于不再同一个层级的包或者是其他文件可能会有权限问题，需要额外 @
需要增加一些产品类型的描述。细化每个功能的细节

数珠游龙

目的 : 实现 @js/logic.js 中的内容。在 @index.html 实现一个数珠游龙的游戏。

function insertNumber(chain, index, value) chain 是一个由整数组成的一维数组，也可能为空。 index 是插入位置，范围为 0 到 chain.length；0 表示最前方，chain.length 表示最后方。 value 是本次插入的整数。返回本次操作结束后的完整一维整数数组。可以修改传入数组，也可以返回新数组。

功能需求 :

用户操作会发送一个小球进入到本次队列
对于相同数字例如 <2,2>,<3,3> 需要进行消除。
如果是不同的数字直接插入到当前位置例如 <2,3,4> 在<3,4>中间插入了一个数5那么队列变成 <2,3,5,4>

思路 :

根据 xxxx
通过 xxxx
实现 xxxx

要求 :

优化文字回答内容,要求清晰简单
保留文件末尾的导出方式： if (typeof module !== “undefined”) module.exports = { insertNumber }; if (typeof window !== “undefined”) window.insertNumber = insertNumber;

示例： insertNumber([2, 4, 1], 2, 3); // 返回 [2, 4, 3, 1]

优化 @js/logic.js 保证 @index.html 满足:

消除逻辑不对，对于初始队列 <4,2,2,4,1,3,3,2> 我在末尾插入一个 2 前面的数字就都消失了
可以参考 @demo.ncdemo 的实现

优化 @js/logic.js 保证 @index.html 满足:

消除逻辑不正确 , 我们需要保证对于 <2,2> 相同的形式是被消除的。对于<2,2,2>也应该全部消除，而不是只保留<2>

AutoApprove

Mon, 10 Aug 2026 00:00:00 +0000

最终实现

能够自动创建对应的请假审批

整体流程如下

注册 ApproveHandle 这里由上层 Agent 判断调度
ApproveHandle 支持 ApproveAdd 和 ApproveFind 分别对应创建审批和查找审批

细节

ApproveAdd

这里的逻辑很简单

根据 Agent 传递的 input 解析出对应的参数
根据参数build对应的 Service实现
然后透传用户原始信息去 Create


// Call 解析审批类型与原文，并创建审批
func (a *ApprovalAdd) Call(ctx context.Context, input string) (string, error) {
	// ... 
	out, err := a.outputparser.Parse(input)
	if err != nil {
		return "", err
	}
	data := out.(map[string]any)

	var approvalType float64
	if t, ok := data["type"]; ok {
		switch v := t.(type) {
		case float64:
			approvalType = v
		case int:
			approvalType = float64(v)
		}
	}
	userInput := input
	if v, ok := data["input"].(string); ok && v != "" {
		userInput = v
	}

	// 保留用户原文，同时补充工时上下文供二级抽取使用
	enriched := fmt.Sprintf("%s\n%s", userInput, workHoursHint)

	ap, err := approval.NewApproval(a.svc, model.ApprovalType(approvalType))
	if err != nil {
		return "", err
	}

	id, err := ap.Create(ctx, enriched)
	if err != nil {
		return "", err
	}

	return Success + "\n created approval id : " + id, nil
}

我们可以看到一个 Create实现，这里由额外进行了一次LLM操作，根据透传的 input 进行额外的解析

func (m *GoOut) Create(ctx context.Context, input string) (string, error) {
	out, err := chains.Predict(ctx, m.c, map[string]any{
		langchain.Input: input,
	}, chains.WithCallback(m.svc.Callbacks))
	if err != nil {
		return "", xerr.WithMessage(err, "chains.Predict : "+input)
	}

	v, err := m.outPutParser.Parse(out)
	if err != nil {
		return "", xerr.WithMessage(err, "m.outPutParser.Parse")
	}

	var data domain.GoOut
	if err := decodeJSON(v, &data); err != nil {
		return "", xerr.WithMessage(err, "decode goOut")
	}

	return createApproval(ctx, m.svc, domain.Approval{
		Type:  int(model.GoOutApproval),
		GoOut: &data,
	})
}

ApproveFind

Approve Find 同样内容更加简单

func (a *ApprovalFind) Call(ctx context.Context, input string) (string, error) {
	if a.Callback != nil {
		a.Callback.HandleText(ctx, "approval find start input : "+input)
	}

	out, err := a.outputparser.Parse(input)
	if err != nil {
		return "", err
	}

	data := out.(map[string]any)
	if data == nil {
		data = make(map[string]any)
	}

	// List API 使用当前登录用户；type 为「我提交/我审核」
	listType := float64(model.ApprovalSubmit)
	if t, ok := data["type"].(float64); ok && t > 0 {
		listType = t
	}
	data["type"] = int(listType)
	if data["count"] == nil {
		data["count"] = 10
	}
	if data["page"] == nil {
		data["page"] = 1
	}

	res, err := curl.GetRequest(token.GetTokenStr(ctx), a.svc.Config.Host+"/v1/approval/list", data)
	if err != nil {
		return "", err
	}

	if a.Callback != nil {
		a.Callback.HandleText(ctx, "approval find end data : "+string(res))
	}

	return ResParser(res, domain.ApprovalFind, nil)
}

SummaryChat

Mon, 10 Aug 2026 00:00:00 +0000

最终实现

用户可以通过 @机器人, 实现总结自己所发的内容

整体流程如下

前端发起调用传入 Time Range
后端获取对应的群聊消息。整理聚合给 LLM
LLM 处理之后进行输出

细节

创建的时候制定一下 templatePrompt ，然后自己开辟一条chain

func NewChatLogHandle(svc *svc.ServiceContext) *ChatLogHandle {
	return &ChatLogHandle{
		svc: svc,
		chains: chains.NewLLMChain(svc.LLMs, prompts.NewPromptTemplate(
			_defaultChatLogPrompts, []string{"input"},
		)),
	}
}

func (c *ChatLogHandle) Chains() chains.Chain {
	return chains.NewTransform(c.transform, nil, nil)
}

去数据库获取对应的MSG 然后整合给LLM 进行输出

func (c *ChatLogHandle) transform(ctx context.Context, inputs map[string]any,
	opts ...chains.ChainCallOption) (map[string]any, error) {

//...

	msgs, err := c.chatLog(ctx, cid, startTime, endTime)
	if err != nil {
		return nil, err
	}
//...
	res, err := chains.Call(ctx, c.chains, map[string]any{
		"input": msgs,
	}, opts...)
	if err != nil {
		return nil, err
	}

	text, ok := res[langchain.OutPut].(string)
	if !ok {
		return nil, chains.ErrInvalidOutputValues
	}
//...
	if err != nil {
		return nil, err
	}
	return map[string]any{
		langchain.OutPut: string(b),
	}, nil
}

Rag-Knowledge

Sun, 09 Aug 2026 00:00:00 +0000

最终实现

我们能够通过前端上传 pdf 进行知识库的更新
我们可以通过自然语言询问文章里面的内容。并且更新对应的内容
同样我们可以重新上传文章进行更新

细节

大体框架

我们提供了一个 KnowLedgeHandle 其中 . 介绍我们这个 Handle 是做什么内容的

Name : knowledge
Desc : This is the company's knowledge base.
Use for: summarizing uploaded documents, retrieving knowledge content, answering questions about employee manuals, attendance, leave, approval process, and other office policies.
Also use for updating/ingesting the knowledge base from uploaded files, and for revising/correcting knowledge facts (e.g. 更改工作时间).
Prefer this destination whenever the user mentions 知识库 / 文档 / 手册 / 总结 / 更改手册内容

这个Handle 对应3个 Tool

KnowledgeQA 用于进行 RAG 回答问题
KnowledgePatch 部分更新 vector 中的内容
KnowledgeUpdate 更新全量的文章

knowledgeQa

我们看一下 knowledgeQa 这里做的内容

获取 Store 也就是获取我们的 Redis CLi
后去其中的 Content 内容。并且存入到 qa 里面。这里使用了 RAG 相似度匹配
然后去询问 AI

整个流程大致这样，相似度匹配也是框架帮我们做的事

func (k *KnowledgeRetrievalQA) Call(ctx context.Context, input string) (string, error) {
	var err error
	if k.qa == nil {
		k.store, err = getKnowledgeStore(ctx, k.svc)
		if err != nil {
			return "", fmt.Errorf("连接知识库向量存储失败(请确认 Redis Stack 已启动): %v", err)
		}

		// topK 取多块，目录/全文结构类问题才有足够上下文
		k.qa = chains.NewRetrievalQAFromLLM(k.svc.LLMs, vectorstores.ToRetriever(k.store, 5))
	}

	res, err := chains.Predict(ctx, k.qa, map[string]any{
		"query": input,
	})
	if err != nil {
		return "", err
	}

	return `请基于检索资料回答用户。写作要求：
1. 直接输出当前有效规定，语气像员工手册正文，条理清晰。
2. 若资料里同一主题有多条说法，只保留最新有效内容合并进答案；不要对比新旧，不要出现「修订」「原规定」「冲突」「优先于」「最新版本」等词。
3. 用户问某类政策时，尽量给出完整条目，而不是只讲变更点。
检索资料：
` + res, nil
}

KnowledgeUPdate

KnowledgeUPdate 就好像是一个 Python 脚本，可以看作想是一个skills

不过这里还是有几点需要注意的

Param . 我们可以看到 Update 在操作之前解析了参数 path,name,time . 这几个参数从哪里来？
我们上传完文件之后会传入到放入到 memory 中

func (l *chat) File(ctx context.Context, files []*domain.FileResp) (err error) {
	// ... 
	err = l.memory.SaveContext(ctx, map[string]any{ // 将文件信息保存到记忆机制中
		langchain.OutPut: string(b), // langchain.OutPut: `[{"Path":"upload/xxx.pdf","Name":"...","Time":"..."}]`
	}, map[string]any{
		langchain.OutPut: "uploaded files", // AI 的回复内容
	})
	// ...
}

然后框架会自动把 memory 挂载到 history 中。从而模型就能够看到这部分memory

1
2

newValues := memory.LoadMemoryVariables(...)  // → {"history": "Human: [{Path,Name,Time}]\nAI: uploaded files\n..."}
合并进 fullValues

通过 PDFprocess 解析pdf文件然后通过 redis 重新更新 Vector

func NewKnowledgeUpdate(svc *svc.ServiceContext) *KnowledgeUpdate {
	return &KnowledgeUpdate{
		//. .. 
		outPutParser: outputparserx.NewStructured([]outputparserx.ResponseSchema{
			{
				Name:        "path",
				Description: "the path to file",
			}, {
				Name:        "name",
				Description: "the name to file",
			}, {
				Name:        "time",
				Description: "file update time",
			},
		}),
	}
}

func (k *KnowledgeUpdate) Call(ctx context.Context, input string) (string, error) {
	 // ... 
	var data any
	data, err := k.outPutParser.Parse(input)
	// ... 

	file := data.(map[string]any)
	filePath := resolveKnowledgeFilePath(fmt.Sprintf("%v", file["path"]))

	if _, err := os.Stat(filePath); err != nil {
		return "", fmt.Errorf("文件不存在: %s", filePath)
	}

	pdfProcessor := NewPDFProcessor()
	chunkedDocuments, err := pdfProcessor.LoadAndSplitPDF(ctx, filePath, 800, 100)
	if err != nil {
		return "", fmt.Errorf("PDF处理失败: %v", err)
	}
	if len(chunkedDocuments) == 0 {
		return "", fmt.Errorf("PDF处理失败: 未生成任何文档块")
	}

	// ... 
	if _, err = k.store.AddDocuments(ctx, chunkedDocuments); err != nil {
		return "", fmt.Errorf("写入知识库失败: %v", err)
	}

	return fmt.Sprintf("%s：文件 %s 已入库，共 %d 个文档块（已覆盖同内容旧数据）。若用户还要求总结或问答文档内容，请继续调用 knowledge_retrieval_qa；若仅要求更新知识库，再给出 Final Answer。",
		knowledgeUpdateSuccessPrefix, filepath.Base(filePath), len(chunkedDocuments)), nil
}

遗留问题

memory 的实现
多个Handle共用memory
- 方案： chatid = uid + busienss_type 根据业务进行区分

RouterChain

Sun, 09 Aug 2026 00:00:00 +0000

最终实现

在聊天窗口让 AI 创建一个待办。给出具体信息之后会创建对应的待办信息

整体流程如下

前端调用 /call 接口传入自然语言信息
后端拼接已经注册的路由Handle + input 去查找然后返回对应的 key

给你一份路由清单，请根据用户输入选出一个最合适的，
如果都不合适就返回Default:

intput : req -front - xxxx

并且根据 xxx 格式返回

查找到对应的 Handle 然后去访问对应 Handle 支持的 Tool
使用 langchain.OneShotAgent 再次询问AI 应该访问哪一个 Tool
调用Tool 发起请求。返回响应

细节

第一次 LLM 拼接 prompts

我们在 NewRouter 的时候就把所有已经实现的 Handler 写进去 . 这里会根据 handle 进行整合 opt

func NewRouter(llm llms.Model, handler []Handler, opts ...Option) *Router {
	opt := executorDefaultOptions(handler)
	for _, o := range opts {
		o(&opt)
	}
	// ...
}

Option 会返回一个 prompt . 类型 PromptTemplate

我们可以看到这里会遍历没用过 hander 然后拼接他们的 Name() 和 Descritipn()

type Option func(options *Options)

// executorDefaultOptions 创建默认的路由器配置选项
func executorDefaultOptions(handler []Handler) Options {
	return Options{
		prompt: createPrompt(handler),
		memory: memory.NewSimple(),
	}
}


func createPrompt(handler []Handler) prompts.PromptTemplate {
	return prompts.PromptTemplate{
		Template:       MULTI_PROMPT_ROUTER_TEMPLATE,
		InputVariables: []string{_input},
		TemplateFormat: prompts.TemplateFormatGoTemplate,
		PartialVariables: map[string]any{
			_destinations: handlerDestinations(handler),
			_formatting:   _outputparser.GetFormatInstructions(),
		},
	}
}

这里可以看到 handle 的定义如下 , 和 Tool 一样自带说明书

func NewTodoHandle(svc *svc.ServiceContext) *TodoHandle {
	//...
}

// Name 返回处理器名称，用于路由识别
func (t *TodoHandle) Name() string {
	return "todo"
}

// Description 返回处理器描述，帮助 AI 理解何时使用此处理器
func (t *TodoHandle) Description() string {
	return "suitable for todo processing, such as todo creation, query, modification, deletion, etc"
}

// Chains 返回处理链，使用转换链包装代理输出
func (t *TodoHandle) Chains() chains.Chain {
	return chains.NewTransform(t.transform, nil, nil)
}

寻找Handle进行处理

因为我们在提示词中增加了,格式化返回 . 我们可以从会使用 outputparser 解析对应的 output

我们通过 chains.Call(ctx, r.handlers[next].Chains(), inputs) 调用对应的 Tool

1
2
3

<< FORMATTING >>
Return a markdown code snippet with a JSON object formatted to look like:
{{.formatting}}

func (r *Router) Call(ctx context.Context, inputs map[string]any, options ...chains.ChainCallOption) (map[string]any, error) {
// ... 
	out, err := r.outputparser.Parse(text.(string))
	if err != nil {
		return nil, err
	}

	if r.callbacks != nil {
		r.callbacks.HandleChainEnd(ctx, map[string]any{
			"out": out,
		})
	}

	data := out.(map[string]string)
	next, ok := data[_destinations]
	if !ok || next == Empty || r.handlers[next] == nil {
		if r.emptyHandle != nil {
			return chains.Call(ctx, r.emptyHandle.Chains(), inputs)
		}
		return nil, ErrNotHandles
	}

	return chains.Call(ctx, r.handlers[next].Chains(), inputs)
}

Agents Find tool

我们可以看到 TodoHandle 支持了 todoAdd和 TodoFind 这两个Tool

对于每一个 Tool 都会有格式化输出配置同样也有 Name +Desc 。Tool 的基本定义一个说明书

func NewTodoHandle(svc *svc.ServiceContext) *TodoHandle {
	return &TodoHandle{
		svc: svc,
		// 创建包含待办工具的 AI 代理
		agentChain: agents.NewExecutor(agents.NewOneShotAgent(svc.LLMs, []tools.Tool{
			toolx.NewTodoAdd(svc),  // 待办创建工具
			toolx.NewTodoFind(svc), // 待办查询工具
		})),
	}
}


func NewTodoAdd(svc *svc.ServiceContext) *TodoAdd {
	return &TodoAdd{
		svc:      svc,
		callback: svc.Callbacks,
		// 配置结构化输出解析器，定义待办事项的字段格式
		outputparser: outputparserx.NewStructured([]outputparserx.ResponseSchema{
			{
				Name:        "title",
				Description: "todo title",
			}, {
				Name:        "deadlineAt",
				Description: "calculate the final deadline based on the time information entered by the user and combined with today's time. a Unix time",
				Type:        "int64",
			}, {
				Name:        "desc",
				Description: "todo description",
			}, {
				Name:        "executeIds",
				Description: "list of participating users in the backlog. the data type is a set of string ids. none is empty",
				Type:        "[]string",
			},
		}),
	}
}

// Name 返回工具名称，用于 AI 代理识别
func (t *TodoAdd) Name() string {
	return "todo_add"
}

// Description 返回工具描述和使用说明，包含输出格式指令
func (t *TodoAdd) Description() string {
	template := `
	a todo add interface.
	use when you need to create a todo.
	keep Chinese output.
` + t.outputparser.GetFormatInstructions()

	return template
}

我们看 NewOneShotAgent ，这里也是单独创建了一个 LLM Chain 。并且使用自己的 getMrklPrompt 传入了 tools 用于寻找 tool .方式和我们实现 Router 一样

func NewOneShotAgent(llm llms.Model, tools []tools.Tool, opts ...Option) *OneShotZeroAgent {
	options := mrklDefaultOptions()
	for _, opt := range opts {
		opt(&options)
	}

	return &OneShotZeroAgent{
		Chain: chains.NewLLMChain(
			llm,
			options.getMrklPrompt(tools),
			chains.WithCallback(options.callbacksHandler),
		),
		Tools:            tools,
		OutputKey:        options.outputKey,
		CallbacksHandler: options.callbacksHandler,
	}
}

AI helper 常规开发

Sat, 08 Aug 2026 00:00:00 +0000

鉴权 & 白名单

使用 group 加上 Jwt Parse 实现 Check

func (h *User) InitRegister(engine *gin.Engine) {
	g0 := engine.Group("v1/user")
	g0.POST("/login", h.Login)

	g1 := engine.Group("v1/user", h.svcCtx.Jwt.Handler)
	g1.GET("/:id", h.Info)
	g1.POST("", h.Create)
	g1.PUT("", h.Edit)
	g1.DELETE("/:id", h.Delete)
	g1.GET("/list", h.List)
	g1.POST("/password", h.UpdatePassword)
}

func (m *Jwt) Handler(ctx *gin.Context) {
	r, err := m.tokenParser.ParseWithContext(ctx.Request)
	if err != nil {
		httpx.FailWithErr(ctx, err)
		ctx.Abort()
		return
	}

	ctx.Request = r
	ctx.Next()
}

同样的我们在 Websocket 那边也是使用 JWT 进行鉴权

func (s *Ws) auth(r *http.Request) (uid string, tokenStr string, err error) {
   // 优先从请求头中获取WebSocket认证Token（保持原有功能）
   tok := r.Header.Get("websocket")
//...

   // 解析JWT Token，获取用户身份信息
   claims, tokenStr, err := s.tokenParser.ParseToken(tok)
   if err != nil {
   	return "", "", err
   }
   //...
}

用户模块

支持 Login、Info、Create、Edit、Delete、List、UpdatePassword

这一部分基本上都是 CRUD 并且没有做并发控制。

// User 用户业务逻辑接口
type User interface {
   // Login 用户登录验证
   Login(ctx context.Context, req *domain.LoginReq) (resp *domain.LoginResp, err error)
   // Info 根据ID获取用户信息
   Info(ctx context.Context, req *domain.IdPathReq) (resp *domain.User, err error)
   // Create 创建新用户
   Create(ctx context.Context, req *domain.User) (err error)
   // Edit 更新用户信息
   Edit(ctx context.Context, req *domain.User) (err error)
   // Delete 删除指定用户
   Delete(ctx context.Context, req *domain.IdPathReq) (err error)
   // List 分页查询用户列表
   List(ctx context.Context, req *domain.UserListReq) (resp *domain.UserListResp, err error)
   // UpdatePassword 更新用户密码
   UpdatePassword(ctx context.Context, req *domain.UpdatePasswordReq) (err error)
}

表结构设计

type User struct {
	ID primitive.ObjectID `bson:"_id,omitempty" json:"id,omitempty"`
	// TODO: Fill your own fields

	Name     string `bson:"name" json:"name"`
	Password string `bson:"Password" json:"Password"`
	Status   int    `bson:"status" json:"status"`
	IsAdmin  bool   `bson:"isAdmin" json:"isAdmin"` // 是否为管理员
	UpdateAt int64  `bson:"updateAt" json:"updateAt"`
	CreateAt int64  `bson:"createAt" json:"createAt"`
}

Department

Soa 方法会根据所有的部门构建一个部门树进行展示
- 全量查出所有部门
- 按 ParentPath 分组
- 否则按照父路径放进 groupDep

1
2
3

公司(A) ParentPath=""
  └─ 技术部(B) ParentPath=":A"
       └─ 后端组(C) ParentPath=":A:B"

其他的设计基本上都是 CRUD

type Department interface {
   Soa(ctx context.Context) (resp *domain.DepartmentSoaResp, err error)
   Info(ctx context.Context, req *domain.IdPathReq) (resp *domain.Department, err error)
   Create(ctx context.Context, req *domain.Department) (err error)
   Edit(ctx context.Context, req *domain.Department) (err error)
   Delete(ctx context.Context, req *domain.IdPathReq) (err error)
   SetDepartmentUsers(ctx context.Context, req *domain.SetDepartmentUser) (err error)
   AddDepartmentUser(ctx context.Context, req *domain.AddDepartmentUser) (err error)
   RemoveDepartmentUser(ctx context.Context, req *domain.RemoveDepartmentUser) (err error)
   DepartmentUserInfo(ctx context.Context, req *domain.IdPathReq) (resp *domain.Department, err error)
}

表结构设计

设计一个部门数据表一个部门用户表

type Department struct {
	ID         primitive.ObjectID `bson:"_id,omitempty" json:"id,omitempty"`                // 部门ID
	Name       string             `bson:"name" json:"name"`                                 // 部门名称
	ParentId   string             `bson:"parentId,omitempty" json:"parentId,omitempty"`     // 父部门ID
	ParentPath string             `bson:"parentPath,omitempty" json:"parentPath,omitempty"` // 父部门路径
	Level      int                `bson:"level" json:"level"`                               // 部门层级
	LeaderId   string             `bson:"leaderId,omitempty" json:"leaderId,omitempty"`     // 部门负责人ID
	Leader     string             `bson:"leader,omitempty" json:"leader,omitempty"`         // 部门负责人姓名
	Count      int64              `bson:"count" json:"count"`                               // 部门人数
	UpdateAt   int64              `bson:"updateAt,omitempty" json:"updateAt,omitempty"`     // 更新时间
	CreateAt   int64              `bson:"createAt,omitempty" json:"createAt,omitempty"`     // 创建时间
}

type DepartmentUser struct {
	ID primitive.ObjectID `bson:"_id,omitempty" json:"id,omitempty"` // 关联ID

	DepId  string `bson:"depId,omitempty"`  // 部门ID
	UserId string `bson:"userId,omitempty"` // 用户ID

	UpdateAt int64 `bson:"updateAt,omitempty" json:"updateAt,omitempty"` // 更新时间
	CreateAt int64 `bson:"createAt,omitempty" json:"createAt,omitempty"` // 创建时间
}

Todo

基本上也都是CRUD接口

type Todo interface {
	Info(ctx context.Context, req *domain.IdPathReq) (resp *domain.TodoInfoResp, err error)   // 获取待办事项详情
	Create(ctx context.Context, req *domain.Todo) (resp *domain.IdResp, err error)            // 创建待办事项
	Edit(ctx context.Context, req *domain.Todo) (err error)                                   // 编辑待办事项
	Delete(ctx context.Context, req *domain.IdPathReq) (err error)                            // 删除待办事项
	Finish(ctx context.Context, req *domain.FinishedTodoReq) (err error)                      // 完成待办事项
	CreateRecord(ctx context.Context, req *domain.TodoRecord) (err error)                     // 创建待办操作记录
	List(ctx context.Context, req *domain.TodoListReq) (resp *domain.TodoListResp, err error) // 获取待办事项列表
}

表结构设计

type TodoRecord struct {
	TodoId   string `json:"todoId,omitempty"`
	UserId   string `json:"userId,omitempty"`
	UserName string `json:"userName,omitempty"`
	Content  string `json:"content,omitempty"`
	Image    string `json:"image,omitempty"`
	CreateAt int64  `json:"createAt,omitempty"`
}

type Todo struct {
	ID          string        `json:"id,omitempty"`
	CreatorId   string        `json:"creatorId,omitempty"`
	CreatorName string        `json:"creatorName,omitempty"`
	Title       string        `json:"title,omitempty"`
	DeadlineAt  int64         `json:"deadlineAt,omitempty"`
	Desc        string        `json:"desc,omitempty"`
	Status      int           `json:"status,omitempty"`
	Records     []*TodoRecord `json:"records,omitempty"`
	ExecuteIds  []string      `json:"executeIds,omitempty"` // 待办执行人
	TodoStatus  int           `json:"todoStatus,omitempty"`
}

type UserTodo struct {
	ID         string `json:"id,omitempty"`
	UserId     string `json:"userId,omitempty"`
	UserName   string `json:"userName,omitempty"`
	TodoId     string `json:"todoId,omitempty"`
	TodoStatus int    `json:"todoStatus,omitempty"` // 待办事项的状态
}

type TodoInfoResp struct {
	ID          string        `json:"id,omitempty"`
	CreatorId   string        `json:"creatorId,omitempty"`
	CreatorName string        `json:"creatorName,omitempty"`
	Title       string        `json:"title,omitempty"`
	DeadlineAt  int64         `json:"deadlineAt,omitempty"`
	Desc        string        `json:"desc,omitempty"`
	Records     []*TodoRecord `json:"records,omitempty"`
	ExecuteIds  []*UserTodo   `json:"executeIds,omitempty"`
	Status      int           `json:"status,omitempty"`
	TodoStatus  int           `json:"todoStatus,omitempty"`
}

审批

基本上也是CRUD

func (h *Approval) InitRegister(engine *gin.Engine) {
	// 创建审批路由组，添加JWT中间件进行身份验证
	g := engine.Group("v1/approval", h.svcCtx.Jwt.Handler)
	g.GET("/:id", h.Info)        // 获取审批详情
	g.POST("", h.Create)         // 创建审批申请
	g.PUT("/dispose", h.Dispose) // 处理审批（通过/拒绝/撤销）
	g.GET("/list", h.List)       // 获取审批列表
}

表结构设计

一张超级无敌巨宽的表

	Approval struct {
		ID primitive.ObjectID `bson:"_id,omitempty" json:"id,omitempty"` // 数据库ID

		UserId   string         `bson:"userId,omitempty" json:"userId,omitempty"`     // 申请人用户ID
		No       string         `bson:"no,omitempty" json:"no,omitempty"`             // 审批编号
		Type     ApprovalType   `bson:"type,omitempty" json:"type,omitempty"`         // 审批类型
		Status   ApprovalStatus `bson:"status,omitempty" json:"status,omitempty"`     // 审批状态
		Title    string         `bson:"title,omitempty" json:"title,omitempty"`       // 审批标题
		Abstract string         `bson:"abstract,omitempty" json:"abstract,omitempty"` // 审批摘要
		Reason   string         `bson:"reason,omitempty" json:"reason,omitempty"`     // 申请理由

		ApprovalId    string      `bson:"approvalId,omitempty"`    // 当前审批人ID
		ApprovalIdx   int         `bson:"approvalIdx,omitempty"`   // 当前审批人索引
		Approvers     []*Approver `bson:"approvers,omitempty"`     // 审批人列表
		CopyPersons   []*Approver `bson:"copyPersons,omitempty"`   // 抄送人列表
		Participation []string    `bson:"participation,omitempty"` // 参与人员ID列表

		FinishAt    int64 `bson:"finishAt,omitempty" json:"finishAt,omitempty"`       // 完成时间戳
		FinishDay   int64 `bson:"finishDay,omitempty" json:"finishDay,omitempty"`     // 完成日期
		FinishMonth int64 `bson:"finishMonth,omitempty" json:"finishMonth,omitempty"` // 完成月份
		FinishYeas  int64 `bson:"finishYeas,omitempty" json:"finishYeas,omitempty"`   // 完成年份

		MakeCard *MakeCard `bson:"makeCard,omitempty" json:"makeCard,omitempty"` // 补卡申请详情
		Leave    *Leave    `bson:"leave,omitempty" json:"leave,omitempty"`       // 请假申请详情
		GoOut    *GoOut    `bson:"goOut,omitempty" json:"goOut,omitempty"`       // 外出申请详情

		UpdateAt int64 `bson:"updateAt,omitempty" json:"updateAt,omitempty"` // 更新时间戳
		CreateAt int64 `bson:"createAt,omitempty" json:"createAt,omitempty"` // 创建时间戳
	}

	// Approver 审批人数据模型
	Approver struct {
		UserId   string         `bson:"userId,omitempty"`   // 用户ID
		UserName string         `bson:"userName,omitempty"` // 用户姓名
		Status   ApprovalStatus `bson:"status,omitempty"`   // 审批状态
		Reason   string         `bson:"reason,omitempty"`   // 审批理由
	}

	// MakeCard 补卡
	MakeCard struct {
		Date      int64         `bson:"date,omitempty"`          //补卡时间
		Reason    string        `bson:"reason,omitempty"`        //补卡理由
		Day       int64         `bson:"day,omitempty"`           //补卡日期(20221011)
		CheckType WorkCheckType `bson:"workCheckType,omitempty"` //补卡类型
	}

	// Leave 请假
	Leave struct {
		Type      LeaveType      `bson:"type,omitempty"`      //请假类型
		StartTime int64          `bson:"startTime,omitempty"` //开始时间
		EndTime   int64          `bson:"endTime,omitempty"`   //结束时间
		Reason    string         `bson:"reason,omitempty"`    //请假原由
		TimeType  TimeFormatType `bson:"timeType,omitempty"`  //请假类型  1=小时 2=天
	}

	// GoOut 外出
	GoOut struct {
		StartTime int64   `bson:"startTime,omitempty"` //开始时间
		EndTime   int64   `bson:"endTime,omitempty"`   //结束时间
		Duration  float32 `bson:"duration,omitempty"`  //时长(小时)
		Reason    string  `bson:"reason,omitempty"`    //外出原由
	}

Chat

AiHelper WebSocket 聊天技术总结

结论：聊天能力集中在后端独立 WS 服务（gorilla/websocket），与 Gin REST 共用 JWT；front/ 为空，无正式客户端。仓库内无架构图，设计意图主要体现在代码注释与 Chat_API_测试指南.md。

1. 整体架构

进程内双服务并行启动（共享同一 svc.ServiceContext）：

服务	框架	默认地址	职责
REST API	Gin	`0.0.0.0:8888`	登录、用户管理等
WebSocket	`net/http` + gorilla	`0.0.0.0:9000`，路径 `/ws`	实时私聊/群聊

客户端
  │
  ├─ POST /v1/user/login ──► Gin API ──► JWT(AccessToken)
  │
  └─ WS /ws (Header: websocket: <JWT>)
         │
         ▼
   handler/ws.Ws ──► logic.Chat ──► MongoDB chat_log
         │
         └─ 内存 uidToConn / ConnToUid 推送

入口：/Users/gzm/gopath/src/AiHelper/backend/main.go

api.NewHandle(svcContext).Run()
ws.NewWs(svcContext).Run()

依赖：github.com/gorilla/websocket v1.5.3（无 nhooyr、无 gin-websocket）

2. 连接生命周期

核心文件：/Users/gzm/gopath/src/AiHelper/backend/internal/handler/ws/ws.go

阶段	函数	行为
启动	`Ws.Run`	`http.HandleFunc("/ws", ServerWs)` + `ListenAndServe`
握手前鉴权	`Ws.auth`	读 Header `websocket`，JWT 解析取 uid
升级	`ServerWs` → `Upgrader.Upgrade`	响应头回写 `websocket: <token>`
登记连接	`addConn`	写入双向 map；同 uid 旧连接先 `Close`（单点在线）
读循环	`handleConn`（goroutine）	`ReadMessage` → JSON → 按 `chatType` 分发
发送	`send` / `sendByUids`	TextMessage + JSON
断开	`closeConn`	读失败或处理失败时清理 map 并关闭

要点：

CheckOrigin 恒为 true（注释写明生产应收紧）
鉴权失败只打日志并 return，不写 HTTP 错误体
JSON 解析失败或业务错误会 return 结束循环，但不一定走 closeConn（潜在连接泄漏）
无 ping/pong、心跳、重连协议

3. 消息协议

领域模型：domain.Message（/Users/gzm/gopath/src/AiHelper/backend/internal/domain/ws.go）

{
  "conversationId": "string",
  "recvId": "string",
  "sendId": "string",
  "chatType": 1,
  "content": "string",
  "contentType": 1
}

字段	说明
`conversationId`	群聊强制 `"all"`；私聊空则服务端生成
`recvId`	私聊必填；群聊可空
`sendId`	服务端强制覆盖为 JWT uid，防伪造
`chatType`	见下表（以代码为准）
`content` / `contentType`	内容；`contentType` 注释为 1 文字 / 2 图片 / 3 表情等，未入库

model.ChatType（chatlogtypes.go）：

值	常量	含义
1	`GroupChatType`	群聊
2	`SingleChatType`	私聊

分发（handleConn）：

SingleChatType → privateChat → logic.Chat.PrivateChat → sendByUids(recvId)
GroupChatType → groupChat → logic.Chat.GroupChat → sendByUids()（全员广播）

注意：backend/doc/Chat_API_测试指南.md 把私聊写成 chatType:1、群聊写成 2，与代码相反；以 domain/model 注释为准。

无独立事件类型字段（无 event/type/ack）；协议即「一条 JSON = 一条聊天消息」。

4. Auth / Session 与 REST 关系

登录（REST）

POST /v1/user/login → User.Login → logic.user.Login
token.GetJwtToken(secret, iat, expire, user.ID.Hex())
Claims：exp/iat + 自定义键 aihelper（常量 token.Identify）= uid
响应：LoginResp.AccessToken（JSON 字段名 token）

REST 鉴权

Header：Authorization: Bearer <JWT>
中间件：middleware.Jwt.Handler → token.Parse.ParseWithContext

WS 鉴权

Header：websocket: <JWT>（非 Bearer）
Ws.auth → 同一 token.Parse + 同一 Jwt.Secret
连接期把 uid/token 放入 context（Ws.context），供业务/日志使用

会话模型：

无独立 chat room / WS session 表
在线态 = 进程内 uidToConn / ConnToUid
会话 ID：
- 群聊："all"（全局大厅）
- 私聊：GenerateUniqueID(sendId, recvId) = 排序后拼接 → SHA256 → Base64Raw 取前 22 位（顺序无关、稳定）

持久化：ChatLogModel.Insert → MongoDB chat_log；无按会话拉历史的 REST/WS API（模型仅有 Insert/FindOne/Update/Delete）。

5. 关键组件与数据流

关键文件

路径	角色
`backend/main.go`	API + WS 双 goroutine 启动
`backend/internal/handler/ws/ws.go`	连接管理、鉴权、读写循环
`backend/internal/handler/ws/conversation.go`	`privateChat` / `groupChat` 推送
`backend/internal/domain/ws.go`	`Message` 协议结构
`backend/internal/logic/chat.go`	落库、`GenerateUniqueID`
`backend/internal/model/chatlogtypes.go`	`ChatLog`、`ChatType`
`backend/internal/model/chatlogmodel.go`	MongoDAO
`backend/pkg/token/{token,ctxtoken}.go`	JWT 签发/解析
`backend/internal/middleware/jwt.go`	REST JWT
`backend/internal/logic/user.go`	登录发 Token
`backend/internal/config/config.go` + `etc/*/api.yaml`	`Ws.Addr`、`Jwt.*`
`backend/doc/Chat_API_测试指南.md`	手工联调文档（部分与代码不一致）
`backend/internal/logic/chat_test.go`	仅测 `GenerateUniqueID`

客户端

front/ 目录为空
文档用 wscat -c ws://localhost:9000/ws -H "websocket:{token}"

数据流（私聊）

A 发 JSON（recvId=B, chatType=2）
handleConn 设 SendId=A
PrivateChat → 必要时生成 conversationId → Insert
sendByUids(ctx, msg, B) → 仅 B 在线则推送
发送者 A 收不到自己消息的 echo（代码注释已说明）

数据流（群聊）

chatType=1 → ConversationId="all" → 落库
sendByUids 无 uid → 广播所有在线用户（含发送者）
文档写「除发送者外」与代码不符；也不是真实群组房间，而是全站在线广播

6. 重要设计决策

API/WS 端口分离：Gin 与裸 net/http 各占端口，共享 Mongo/JWT 配置
共享 ServiceContext：避免双实例初始化竞态（main.go 注释）
Header 传 Token：自定义 websocket 头，规避部分 WS 客户端难带 Authorization 的问题
服务端信任边界：sendId 只认 JWT，客户端不可伪造
单连接/用户：新连踢旧连
轻量会话：无私聊房间实体；群聊固定 "all"
先存后推：落库成功再推送；接收方离线则只落库、不推
内存连接表：单机、无 Redis；水平扩展需改造
协议极简：无 ACK、回执、已读、错误帧、心跳
安全简化：全放行 Origin；鉴权失败无标准 HTTP 状态

7. 配置与联调

本地配置示例（backend/etc/local/api.yaml）：

API：0.0.0.0:8888
WS：0.0.0.0:9000
JWT：Secret + Expire

推荐联调顺序（与文档一致、chatType 按代码）：

POST /v1/user/login 取 token 与 id
wscat 带 websocket 头连 /ws
私聊：chatType: 2 + recvId
群聊：chatType: 1

8. 缺口与风险（实现现状）

无前端 WS 客户端
无聊天历史查询 API
contentType 未持久化
文档 chatType、群聊是否回显发送者与代码不一致
处理错误路径可能未清理连接
群聊非真实群组，而是全局广播
无多实例在线路由能力

Rag 实战

Sat, 08 Aug 2026 00:00:00 +0000

RAG

本篇的目的是为了将文件向量化后存到数据库中这里面的步骤有

读取文件
切分文件
索引（embedding 和存醋）

流程编排

解释一下下面的这个流程

Start 程序启动
File loader 读取文件转换成 schema.Document (文档对象列表)
Markdown Transfomer 转换成 Markdown 格式
Milvus Index 向量索引
- 使用 oepnai 进行 Embedding 把文本变成向量
- 然后把 [原文 + 向量 + 元数据] 写入 Milvus Collections
结束

生成完后，会在目录看到这些组件

最终实现

我们的一个文本最后会被分片插入到向量数据库中

代码解析

首先调用 knowledge_index_pipeline.BuildKnowledgeIndexing 创建了一个 runner

并且使用 r.Invoke 传入了文件的地址

func main() {
	ctx := context.Background()
	r, err := knowledge_index_pipeline.BuildKnowledgeIndexing(ctx)
	if err != nil {
		panic(err)
	}
	err = filepath.WalkDir("./docs", func(path string, d fs.DirEntry, err error) error {
		if err != nil {
			return fmt.Errorf("walk dir failed: %w", err)
		}
		if d.IsDir() {
			return nil
		}

		if !strings.HasSuffix(path, ".md") {
			fmt.Printf("[skip] not a markdown file: %s\n", path)
			return nil
		}

		fmt.Printf("[start] indexing file: %s\n", path)
		ids, err := r.Invoke(ctx, document.Source{URI: path})
		if err != nil {
			return fmt.Errorf("invoke index graph failed: %w", err)
		}
		fmt.Printf("[done] indexing file: %s, len of parts: %d，%s\n", path, len(ids), ids)
		return nil
	})
	if err != nil {
		panic(err)
	}
}

Runnable

详细拆解一下 BuildKnowledgeIndexing

我们可以看到这个方法返回了一个 compose.Runnable[document.Source, []string] 接口使用 doucument 返回 []string
Invoke 在注释里面说明。是输出的意思

func BuildKnowledgeIndexing(ctx context.Context) (r compose.Runnable[document.Source, []string], err error) {
	// ... 
}

// Runnable is the interface for an executable object. Graph, Chain can be compiled into Runnable.
// runnable is the core conception of eino, we do downgrade compatibility for four data flow patterns,
// and can automatically connect components that only implement one or more methods.
// eg, if a component only implements Stream() method, you can still call Invoke() to convert stream output to invoke output.
type Runnable[I, O any] interface {
	Invoke(ctx context.Context, input I, opts ...Option) (output O, err error)
	Stream(ctx context.Context, input I, opts ...Option) (output *schema.StreamReader[O], err error)
	Collect(ctx context.Context, input *schema.StreamReader[I], opts ...Option) (output O, err error)
	Transform(ctx context.Context, input *schema.StreamReader[I], opts ...Option) (output *schema.StreamReader[O], err error)
}

BuildKnowledgeIndexing

详细看一下其他流程

这里有很多 AddEdge 。我们看里面的参数 start, fileLoader, markdown... 可以看出来就是我们在 Eino 里面绘制的点
也就是这里组装了一下整个流程然后返回一个执行器

func BuildKnowledgeIndexing(ctx context.Context) (r compose.Runnable[document.Source, []string], err error) {
	const (
		FileLoader       = "FileLoader"
		MarkdownSplitter = "MarkdownSplitter"
		Indexer          = "Indexer"
	)
	g := compose.NewGraph[document.Source, []string]()
	fileLoaderKeyOfLoader, err := newLoader(ctx)
	if err != nil {
		return nil, err
	}
	_ = g.AddLoaderNode(FileLoader, fileLoaderKeyOfLoader)
	markdownSplitterKeyOfDocumentTransformer, err := newDocumentTransformer(ctx)
	if err != nil {
		return nil, err
	}
	_ = g.AddDocumentTransformerNode(MarkdownSplitter, markdownSplitterKeyOfDocumentTransformer)
	indexerKeyOfIndexer, err := newIndexer(ctx)
	if err != nil {
		return nil, err
	}
	_ = g.AddIndexerNode(Indexer, indexerKeyOfIndexer)
	_ = g.AddEdge(compose.START, FileLoader)
	_ = g.AddEdge(Indexer, compose.END)
	_ = g.AddEdge(FileLoader, MarkdownSplitter)
	_ = g.AddEdge(MarkdownSplitter, Indexer)
	r, err = g.Compile(ctx, compose.WithGraphName("KnowledgeIndexing"), compose.WithNodeTriggerMode(compose.AnyPredecessor))
	if err != nil {
		return nil, err
	}
	return r, err
}

Loader

我们看下面的这个代码可以看返回值是一个 document.Loader 的接口

这个接口需要实现 load 方法

func newLoader(ctx context.Context) (ldr document.Loader, err error) {
	// UseNameAsID 必开：Redis Indexer 的默认映射要求 doc.ID 非空。
	config := &file.FileLoaderConfig{
		UseNameAsID: true,
	}
	ldr, err = file.NewFileLoader(ctx, config)
	if err != nil {
		return nil, err
	}
	return ldr, nil
}

type Loader interface {
	Load(ctx context.Context, src Source, opts ...LoaderOption) ([]*schema.Document, error)
}

File Load

详细看一下官方的 file loader 是怎么实现的

OpenFile 打开文件
读取文件
构建元数据 ExtraMeta
构造返回值然后返回

func (f *FileLoader) Load(ctx context.Context, src document.Source, opts ...document.LoaderOption) (docs []*schema.Document, err error) {
// ... 
	file, err := openFile(src.URI)
//...
	name := filepath.Base(src.URI)
	ext := filepath.Ext(src.URI)

	meta := map[string]any{
		MetaKeyExtension: ext,
		MetaKeyFileName:  name,
		MetaKeySource:    src.URI,
	}

//...
	o := document.GetLoaderCommonOptions(&document.LoaderOptions{}, opts...)

	docs, err = f.Parser.Parse(ctx, file, append([]parser.Option{parser.WithURI(src.URI), parser.WithExtraMeta(meta)}, o.ParserOptions...)...)
	if err != nil {
		return nil, fmt.Errorf("file parse err of [%s]: %w", src.URI, err)
	}

// ... 
	return docs, nil
}

func (dp TextParser) Parse(ctx context.Context, reader io.Reader, opts ...Option) ([]*schema.Document, error) {
	data, err := io.ReadAll(reader)
	if err != nil {
		return nil, err
	}

	opt := GetCommonOptions(&Options{}, opts...)

	meta := make(map[string]any)
	meta[MetaKeySource] = opt.URI

	for k, v := range opt.ExtraMeta {
		meta[k] = v
	}

	doc := &schema.Document{
		Content:  string(data),
		MetaData: meta,
	}

	return []*schema.Document{doc}, nil
}

Transformer

newDocumentTransformer 返回一个 Transformer 的接口

func newDocumentTransformer(ctx context.Context) (tfr document.Transformer, err error) {
	// 按 Markdown 标题级别切分；Headers 为必填，key 只能是 '#' 组成。
	config := &markdown.HeaderConfig{
		Headers: map[string]string{
			"#":   "h1",
			"##":  "h2",
			"###": "h3",
		},
		TrimHeaders: false,
		// 每个 chunk 需要唯一 ID，否则 Redis 会用同一个 key 互相覆盖。
		IDGenerator: func(_ context.Context, originalID string, splitIndex int) string {
			return fmt.Sprintf("%s_%d", originalID, splitIndex)
		},
	}
	tfr, err = markdown.NewHeaderSplitter(ctx, config)
	if err != nil {
		return nil, err
	}
	return tfr, nil
}

type Transformer interface {
	Transform(ctx context.Context, src []*schema.Document, opts ...TransformerOption) ([]*schema.Document, error)
}

HeaderSplitter

可以看这里先进行了 Split
然后每个切片复制一个 uuid
并且给每个分片增加元数据信息
返回

func (h *headerSplitter) Transform(ctx context.Context, docs []*schema.Document, opts ...document.TransformerOption) ([]*schema.Document, error) {
	var ret []*schema.Document
	for _, doc := range docs {
		result := h.splitText(ctx, doc.Content)
		for i := range result {
			nDoc := &schema.Document{
				ID:       h.idGenerator(ctx, doc.ID, i),
				Content:  result[i].chunk,
				MetaData: deepCopyAnyMap(doc.MetaData),
			}
			if nDoc.MetaData == nil {
				nDoc.MetaData = make(map[string]any, len(result[i].meta))
			}
			for k, v := range result[i].meta {
				nDoc.MetaData[k] = v
			}
			ret = append(ret, nDoc)
		}
	}
	return ret, nil
}

Index

构建 Indexer 返回一个 Indexer 接口

func newIndexer(ctx context.Context) (idr indexer.Indexer, err error) {
	embeddingIns, err := newEmbedding(ctx)
	if err != nil {
		return nil, err
	}
	// 写入 Attu 中看到的 default/biz；向量维度需与 embedding 模型一致（vision=2048）。
	config := &milvus2.IndexerConfig{
		ClientConfig: &milvusclient.ClientConfig{
			Address: "localhost:19530",
		},
		Collection: "biz",
		Vector: &milvus2.VectorConfig{
			Dimension:  2048,
			MetricType: milvus2.COSINE,
			VectorField: "vector",
		},
		Embedding: embeddingIns,
	}
	idr, err = milvus2.NewIndexer(ctx, config)
	if err != nil {
		return nil, err
	}
	return idr, nil
}

type Indexer interface {
	// Store stores the documents.
	Store(ctx context.Context, docs []*schema.Document, opts ...Option) (ids []string, err error) // invoke
}

Milvus Indexer

首先是对分片进行向量获取向量数组
构造符合 milvus 表记录的结构体。 id、content、vector、metadata
构造完成记录后 , 插入到数据库。最后返回所有 id

func (i *Indexer) Store(ctx context.Context, docs []*schema.Document, opts ...indexer.Option) (ids []string, err error) {
// ... 
	vectors, err := i.embedDocuments(ctx, co.Embedding, docs)
	if err != nil {
		return nil, err
	}

	upsertResult, err := i.upsertDocuments(ctx, docs, vectors, io.Partition)
	if err != nil {
		return nil, err
	}

// .. 

	return upsertResult, nil
}

func (i *Indexer) embedDocuments(ctx context.Context, emb embedding.Embedder, docs []*schema.Document) ([][]float64, error) {
	if emb == nil {
		return nil, nil // Return nil vectors if no embedder
	}

	texts := make([]string, 0, len(docs))
	for _, doc := range docs {
		texts = append(texts, doc.Content)
	}

	vectors, err := emb.EmbedStrings(i.makeEmbeddingCtx(ctx, emb), texts)
	if err != nil {
		return nil, fmt.Errorf("[Indexer.Store] failed to embed documents: %w", err)
	}
	if len(vectors) != len(docs) {
		return nil, fmt.Errorf("[Indexer.Store] embedding result length mismatch: need %d, got %d", len(docs), len(vectors))
	}
	return vectors, nil
}


func (i *Indexer) upsertDocuments(ctx context.Context, docs []*schema.Document, vectors [][]float64, partition string) ([]string, error) {
	columns, err := i.config.DocumentConverter(ctx, docs, vectors)
	if err != nil {
		return nil, fmt.Errorf("[Indexer.Store] failed to convert documents: %w", err)
	}

	insertOpt := milvusclient.NewColumnBasedInsertOption(i.config.Collection)
	if partition != "" {
		insertOpt = insertOpt.WithPartition(partition)
	}
	for _, col := range columns {
		insertOpt = insertOpt.WithColumns(col)
	}

	result, err := i.client.Upsert(ctx, insertOpt)
	if err != nil {
		return nil, fmt.Errorf("[Indexer.Store] failed to upsert documents: %w", err)
	}

	ids := make([]string, 0, result.IDs.Len())
	for idx := 0; idx < result.IDs.Len(); idx++ {
		idStr, err := idValueAsString(result.IDs, idx)
		if err != nil {
			return nil, fmt.Errorf("[Indexer.Store] failed to get id: %w", err)
		}
		ids = append(ids, idStr)
	}

	return ids, nil
}

总结

总到来看，主要就是我们上面编排的流程

文件加载
文件分块
文件索引 (分片 - 向量化)

Rag 召回

Sat, 08 Aug 2026 00:00:00 +0000

RAG

本篇的目的是为了使用 LLM 进行 RAG 的召回也就是我们的下面的流程

在我们做完文件索引和向量化存储之后
我们需要进行提问召回向量数据库中国呢的信息
将 input和召回的 docs 一起发给大模型

结果

func main() {
	ctx := context.Background()
	r, err := retriever.NewMilvusRetriever(ctx)
	if err != nil {
		panic(err)
	}
	query := "服务下线是什么原因"
	docs, err := r.Retrieve(ctx, query)
	if err != nil {
		panic(err)
	}
	fmt.Println("Q：", query)
	for _, doc := range docs {
		fmt.Println("A：", doc.Content)
	}
	fmt.Println("Done", len(docs))
}

拆解实现

NewMilvusRetriever

我们创建 milvus 的 Retriver
要求指定向量字段 Vector。并且需要返回的字段有 id、content、metadata

func NewMilvusRetriever(ctx context.Context) (rtr retriever.Retriever, err error) {
	eb, err := embedder.DoubaoEmbedding(ctx)
	if err != nil {
		return nil, err
	}
	r, err := milvus2.NewRetriever(ctx, &milvus2.RetrieverConfig{
		ClientConfig: &milvusclient.ClientConfig{
			Address: milvusAddress,
		},
		Collection:  milvusCollectionName,
		VectorField: "vector",
		OutputFields: []string{
			"id",
			"content",
			"metadata",
		},
		TopK:       1,
		SearchMode: search_mode.NewApproximate(milvus2.COSINE),
		Embedding:  eb,
	})
	if err != nil {
		return nil, err
	}
	return r, nil
}

Retrive

这里的 Retrieve 支持多种方法，不过大体思路都是

对于输入的问题进行向量化 EmbedQuery
然后调用相似度查询接口 client.Search
构造返回结构体并且返回

type Retriever interface {
	Retrieve(ctx context.Context, query string, opts ...Option) ([]*schema.Document, error)
}

func (r *Retriever) Retrieve(ctx context.Context, query string, opts ...retriever.Option) (docs []*schema.Document, err error) {
// ... 
	docs, err = r.config.SearchMode.Retrieve(ctx, r.client, r.config, query, opts...)
 // ... 
	return docs, nil
}

func (a *Approximate) Retrieve(ctx context.Context, client *milvusclient.Client, conf *milvus2.RetrieverConfig, query string, opts ...retriever.Option) ([]*schema.Document, error) {
	if conf.Embedding == nil {
		return nil, fmt.Errorf("embedding is required for approximate search")
	}

	queryVector, err := EmbedQuery(ctx, conf.Embedding, query)
	if err != nil {
		return nil, err
	}

	searchOpt, err := a.BuildSearchOption(ctx, conf, queryVector, opts...)
	if err != nil {
		return nil, fmt.Errorf("failed to build search option: %w", err)
	}

	result, err := client.Search(ctx, searchOpt)
	if err != nil {
		return nil, fmt.Errorf("failed to search: %w", err)
	}

	if len(result) == 0 {
		return []*schema.Document{}, nil
	}

	return conf.DocumentConverter(ctx, result[0])
}

这几个 Mode :

这里其实叠了两层概念，容易混在一起。

Mode	作用
Approximate	ANN 近似最近邻（你们现在用的）
Range	按半径/阈值过滤
Hybrid	稠密 + 稀疏/BM25 混合
Sparse	稀疏向量检索
Iterator	分批迭代拉取
Scalar	标量查询

关注 detail

Sat, 08 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 实现了一个完整的用户关系功能

需求分析 :

大部分平台为了提供社交互动、个性化体验，内容传播

这一部分功能被称为用户关系

积极用法：关注

消极用法 : 屏蔽或者拉黑，从系统设计的角度来说没有本质的区别

设计难点

高并发 : 每打开一篇文章，都要判定你是否关注了这个创作者

大数据 : 假设每个用户平均会关注100个人，那么关注数据的行数就是用户数的100倍

功能 & 表结构设计

关注功能设计 :

关注, 取消关注
获取某个人的关注列表, 获取某个人关注另外一个人的详细信息
获取某人的粉丝列表, 获取默认的关注人数

service FollowService {
  // 增删
  rpc Follow (FollowRequest) returns (FollowResponse);
  rpc CancelFollow(CancelFollowRequest) returns (CancelFollowResponse);

  // 改，例如说你准备支持备注、标签类的，那么就会有对应的修改功能

  // 获得某个人的关注列表
  rpc GetFollowee (GetFolloweeRequest) returns (GetFolloweeResponse);
  // 获得某个人关注另外一个人的详细信息
  rpc FollowInfo (FollowInfoRequest) returns (FollowInfoResponse);
  // 获取某人的粉丝列表
  rpc GetFollower (GetFollowerRequest)returns(GetFollowerResponse );
  // 获取默认的关注人数
  rpc GetFollowStatic(GetFollowStaticRequest)returns(GetFollowStaticResponse);
}

表结构设计 :

索引设计

创建联合唯一索引 follwer_followee 这个索引用于查看所有关注的人
并且反向创建一个普通索引 followee_follwer 这个索用于查看谁关注了我

type FollowRelation struct {
	ID int64 `gorm:"primaryKey,autoIncrement,column:id"`

	Follower int64 `gorm:"type:int(11);not null;uniqueIndex:follower_followee,priority:1;index:followee_follower,priority:2"`
	Followee int64 `gorm:"type:int(11);not null;uniqueIndex:follower_followee,priority:2;index:followee_follower,priority:1"`

	Status uint8

	// 这里你可以根据自己的业务来增加字段，比如说
	// 关系类型，可以搞些什么普通关注，特殊关注
	// Type int64 `gorm:"column:type;type:int(11);comment:关注类型 0-普通关注"`
	// 备注
	// Note string `gorm:"column:remark;type:varchar(255);"`
	// 创建时间
	Ctime int64
	Utime int64
}

功能实现

关注某人

DB 创建的时候维护 Upsert 语意进行创建关注关系

func (g *GORMFollowRelationDAO) CreateFollowRelation(ctx context.Context, f FollowRelation) error {
	now := time.Now().UnixMilli()
	f.Utime = now
	f.Ctime = now
	f.Status = FollowRelationStatusActive
	return g.db.WithContext(ctx).Clauses(clause.OnConflict{
		DoUpdates: clause.Assignments(map[string]any{
			"utime":  now,
			"status": FollowRelationStatusActive,
		}),
	}).Create(&f).Error
}

使用 TxPipeline 实现双写两个 Map 。关注者和粉丝单独维护两个 HMap

func (r *RedisFollowCache) updateStaticsInfo(ctx context.Context, follower, followee int64, delta int64) error {
	tx := r.client.TxPipeline()
	// 增加 follower 的关注多少人的数量
	tx.HIncrBy(ctx, r.staticsKey(follower), fieldFolloweeCnt, delta)
	// 增加 followee 被多少人关注的数量
	tx.HIncrBy(ctx, r.staticsKey(followee), fieldFollowerCnt, delta)
	_, err := tx.Exec(ctx)
	return err
}

取消关注

DB 层面只需要更新一下 status 即可

func (g *GORMFollowRelationDAO) UpdateStatus(ctx context.Context, followee int64, follower int64, status uint8) error {
	now := time.Now().UnixMilli()
	return g.db.WithContext(ctx).
		Where("follower = ? AND followee = ?", follower, followee).
		Updates(map[string]any{
			"status": status,
			"utime":  now,
		}).Error
}

Cache 层面同样使用, HIncryBy 进行-1

1
2
3

func (r *RedisFollowCache) CancelFollow(ctx context.Context, follower, followee int64) error {
	return r.updateStaticsInfo(ctx, follower, followee, -1)
}

查询 & 缓存

获取关注列表

这个功能不需要缓存

没有人会频繁去看这个功能缓存效率低
分页接口不好缓存

func (g *GORMFollowRelationDAO) FollowerRelationList(ctx context.Context,
	followee, offset, limit int64) ([]FollowRelation, error) {
	var res []FollowRelation
	err := g.db.WithContext(ctx).
		Where("followee = ? AND status = ?", followee, FollowRelationStatusActive).
		Offset(int(offset)).Limit(int(limit)).
		Find(&res).Error
	return res, err
}

关注数量和粉丝数量

借助 Redis + 兜底 Count 功能来计算关注数量和粉丝数量

通过 HGetAll 直接获取 Uid 的粉丝数量和关注数量然后返回

func (r *RedisFollowCache) StaticsInfo(ctx context.Context, uid int64) (domain.FollowStatics, error) {
	data, err := r.client.HGetAll(ctx, r.staticsKey(uid)).Result()
	if err != nil {
		return domain.FollowStatics{}, err
	}
	// 也认为没有数据
	if len(data) == 0 {
		return domain.FollowStatics{}, ErrKeyNotExist
	}
	// 理论上来说，这里不可能有 error
	followerCnt, _ := strconv.ParseInt(data[fieldFollowerCnt], 10, 64)
	followeeCnt, _ := strconv.ParseInt(data[fieldFolloweeCnt], 10, 64)
	return domain.FollowStatics{
		Followees: followeeCnt,
		Followers: followerCnt,
	}, nil
}

慢查询就是需要去确认DB, DB查询结束之后再回写缓存

func (g *GORMFollowRelationDAO) CntFollower(ctx context.Context, uid int64) (int64, error) {
	var res int64
	err := g.db.WithContext(ctx).
		Select("count(follower)").
		Where("followee = ? AND status = ?",
			uid, FollowRelationStatusActive).Count(&res).Error
	return res, err
}

func (d *CachedRelationRepository) GetFollowStatics(ctx context.Context, uid int64) (domain.FollowStatics, error) {
	// 快路径
	res, err := d.cache.StaticsInfo(ctx, uid)
	if err == nil {
		return res, err
	}
	// 慢路径
	res.Followers, err = d.dao.CntFollower(ctx, uid)
	if err != nil {
		return res, err
	}
	res.Followees, err = d.dao.CntFollowee(ctx, uid)
	if err != nil {
		return res, err
	}
	err = d.cache.SetStaticsInfo(ctx, uid, res)
	if err != nil {
		// 这里记录日志
		d.l.Error("缓存关注统计信息失败",
			logger.Error(err.Error()),
			logger.Int64("uid", uid))
	}
	return res, nil
}

难点尝试解决

我们之前提到的用户关系的量级和用户本身还要高一个数量级。单表肯定是不可以的因此需要考虑

分库分表
换用别的存储中间件

我们这里可以采用 TableStore 进行存储。

部分代码如下，无非是把分库分表的操作丢给了第三方应用

func (t *TableStoreFollowRelationDao) UpdateStatus(ctx context.Context, followee int64, follower int64, status uint8) error {
	cond := tablestore.NewCompositeColumnCondition(tablestore.LO_AND)
	cond.AddFilter(tablestore.NewSingleColumnCondition("follower", tablestore.CT_EQUAL, follower))
	cond.AddFilter(tablestore.NewSingleColumnCondition("followee", tablestore.CT_EQUAL, followee))
	req := new(tablestore.UpdateRowChange)
	req.TableName = FollowRelationTableName
	req.SetCondition(tablestore.RowExistenceExpectation_EXPECT_EXIST)
	req.SetColumnCondition(cond)
	req.PutColumn("status", int64(status))
	_, err := t.client.UpdateRow(&tablestore.UpdateRowRequest{
		UpdateRowChange: req,
	})
	return err
}

面试

总结类似于维护计数的方案
如何优化 COUNT 查询？
- Redis 直接维护结果避免 COUNT
- 利用索引
Redis 的 Pipeline 是什么？ Transaction 又是什么？用来解决什么问题？

关注 one

Sat, 08 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 实现了一个完整的用户关系功能支持关注、取消关注、获取关注列表

流程设计

需求分析 :

要求支持用户的关注，取消关注，获取关注列表，获取关注数量的功能

模块分析 :

完全独立的一个业务，单独拆分成一个模块

关注模块

支持的功能

关注某人
取消关注
查看用户粉丝列表
查看用户关注列表
查看用户关注数量

表结构设计

表结构维护 Follower 和 Followee 以及 status 进行维护关系之间的展示

并且创建唯一索引 <follower_followee> 和普通索引 <followee_follower> 来优化查询用户的关注列表和粉丝列表

type FollowRelation struct {
	ID int64 `gorm:"primaryKey,autoIncrement,column:id"`

	Follower int64 `gorm:"type:int(11);not null;uniqueIndex:follower_followee,priority:1;index:followee_follower,priority:2"`
	Followee int64 `gorm:"type:int(11);not null;uniqueIndex:follower_followee,priority:2;index:followee_follower,priority:1"`

	Status uint8

	// 这里你可以根据自己的业务来增加字段，比如说
	// 关系类型，可以搞些什么普通关注，特殊关注
	// Type int64 `gorm:"column:type;type:int(11);comment:关注类型 0-普通关注"`
	// 备注
	// Note string `gorm:"column:remark;type:varchar(255);"`
	// 创建时间
	Ctime int64
	Utime int64
}

缓存设计

使用 Hash 结构维护一个 follow 和 followee 的关注和被关注数量

使用 TxPiepline 进行一致性控制

在关注和取消关注的时候进行同步的 +1 和 -1 操作

其他细节

拉黑，屏蔽 的功能不额外创建表进行存放。考虑这个操作是一个低频操作，因此使用 status 直接存放到关系表里面
对于关系表，一个用户关注100个人，那么行数就会增加100倍。使用阿里的 tablestore 进行类似分库分表的优化
获取用户关注数量和粉丝数量的时候。优先去获取 Redis 的数量然后再通过 Mysql Count 进行统计
获取关注列表不进行缓存。
- 考虑是一个低频操作缓存命中率低
- 并且是一个分页查询不好缓存

难点 & 亮点

问题 :

维护关注数量 , 我们可以采用单独创一张表进行实现。但是为关注服务直接创一张表太重了

方案 :

因此使用 Redis 进行直接统计计数在关注和取消关注的时候分别操作
在获取关注数量的时候使用 Cache-Aside快慢路径，优先获取 Redis 的数据然后再根据 Count 进行计数。因为我们关注表的索引设计，保证了能够命中索引

问题 :

创建了唯一索引后 <followee_follower> 。这个只能解决查询粉丝数量，但是对于关注数量并不能很好的命中索引

方案 :

反向创建一个普通索引，不需要额外创建唯一索引因为原有的索引就能控制。

亮点 :

使用 tablestore 进行维护大数据量级的关系信息。避免自身系统的复杂性
使用 TxPiePline 进行控制同时写入粉丝和关注的计数。
获取关注和粉丝列表是一个分页接口考虑用户使用频率低缓存命中率差。不进行额外缓存
取消关注通过表设计的 status 进行处理更新 status 就可以完成取消关注，软删除。并且在关注功能的时候，使用 Upsert 保证语意

缺点

对于关系维护的大数据量级处理只是引入了三方的 tablestore 进行处理比较简单
如果 Redis 崩溃，那么会有大部分 Count操作进入到我们的Mysql 中并没有很好的容错机制

总分：68 / 100

对「2 年经验、讲关注关系模块」的面试准备来说：骨架够用，能过一轮筛选，但扛不住有经验的面试官追问。 更像「能把做过的事串起来」，还没到「能把设计讲透、把坑讲清楚」。

优点

需求边界清晰：关注 / 取消关注 / 列表 / 数量，模块独立，简历表述和正文能对上。
表设计基本正确：Follower + Followee + 唯一索引防重复关注，反向普通索引服务粉丝查询，这是面试里常见的加分点。
有取舍意识：列表不缓存（低频 + 分页）、拉黑用 status 软状态、取消关注用 status + Upsert，说明不是只会「全量加 Redis」。
有自我批评：缺点里提到 Redis 挂了打爆 MySQL、tablestore 引入偏简单，态度加分。

缺点（面试里容易被打穿）

一致性讲错/讲浅了
TxPipeline 只保证 Redis 内部多命令原子，不保证 MySQL ↔ Redis 一致。面试官一问「DB 成功、Redis 失败怎么办？」现在的稿子接不住。
索引表述前后矛盾
前文唯一索引是 follower_followee，难点里写成「唯一索引 <followee_follower>」——细节错了会显得没真正想清楚。
计数方案深度不够
Hash + 同步 ±1 + Cache-Aside，缺：key 设计、并发丢更新、缓存击穿/雪崩、冷启动回源、与 DB 对账。
亮点偏「名词」
tablestore、Pipeline 写得很空，2 年经验候选人若只背名词，追问「为什么不用分表 / 为什么不用计数表」会立刻露馅。
业务边界漏洞
未关注却要拉黑、自己关注自己、重复关注并发、软删后重新关注的语义、分页游标 vs offset，基本没准备。
几乎没有 Golang 工程视角
接口分层、Repo、事务边界、幂等、错误码、超时降级——对「Golang 岗」这是硬伤。
文档完成度差
xxxx、TxPiepline 拼写、序号重复（两个「2.」），会给面试官「准备潦草」的印象。

建议（按优先级）

优先级	做什么
P0	把一致性故事补全：写路径（先 DB 再 Redis / Outbox / 对账）、读路径降级、Redis 不可用时的限流与熔断
P0	画一张「关注 / 取消关注」时序图，标清事务、Upsert、status、计数更新顺序
P1	准备 3 个追问标准答：并发重复关注、未关注拉黑、百万粉丝列表分页
P1	把 tablestore 改成「可选扩展」：先讲单机/单库上限与分片思路，再提引入外部存储的原因与代价
P2	补一层 Go 实现：`FollowService` 接口、幂等、GORM 事务片段，能对着代码讲 2 分钟
P2	修正文案与术语：Pipeline 拼写、索引名统一、标题 description 写完整

分项参考（面试官视角）

维度	分数	说明
需求与模块拆分	78	清楚，但偏浅
存储与索引	72	方向对，表述有错
缓存与一致性	55	最大短板
难点/亮点说服力	60	有点，深度不够
自我认知与表达	70	有缺点意识，文档粗糙
对 2 年岗的匹配度	68	能讲项目，难打深水区

一句话：当成「项目介绍提纲」大约 70+；当成「能过中高级追问的面试稿」现在大概 60 出头。把 DB–缓存一致性 和 3～5 个边界追问 补扎实，整体可以冲到 80+。

[LeetCode][hot100] 滑动窗口

Fri, 07 Aug 2026 00:00:00 +0000

3. 无重复字符的最长子串

无重复字符的最长子串

#include <bits/stdc++.h>

const int N = 1e5 + 10 ;
int mp[N];

class Solution {
public:
    int lengthOfLongestSubstring(string s) {
        memset(mp,0,sizeof(mp));
        int ans =  0 ;
        int n = s.size();

        int j = 0 ;
        for(int i = 0 ; i < n ; i ++ ) {
            mp[s[i]] ++ ;
            while(mp[s[i]] > 1 && j < i)  {
                mp[s[j ++ ]]  -- ; 
            }
            ans =max(ans , i - j   + 1);
        }
        return ans ; 
    }
};

心路历程

说实话挑着滑动窗口做的，但是这道题是一个双指针的题。没什么难度直接就做了。另外 leetcode 这种需要人眼 debug 的模式确实很刺激。

一开始写的是 mp[j] > 1 该成了 mp[s[j]] 后面自测还是不对又改成了 mp[s[i]] 人眼 debug 加缺少深度思考确实很容易写偏

438. 找到字符串中所有字母异位词

找到字符串中所有字母异位词

const int N = 3e4 + 10 ;
int tt , hh ; 
int cnt[27],cnts[27];
int q[N];

void init() {
    tt = - 1;
    hh = 0 ;
    memset(cnt,0,sizeof(cnt));
    memset(cnts,0,sizeof(cnts));
}

bool check() {
    for(int i = 0 ; i < 26 ; i ++ ) {
        if(cnt[i] != cnts[i]) {
            return false; 
        }
    }
    return true ;
}


class Solution {
public:
    vector<int> findAnagrams(string s, string p) {
        init();
        int n = s.size();
        int k = p.size();
        vector<int> ans ;
        for(int i  = 0 ; i < k ; i ++ ) {
            cnt[p[i]- 'a'] ++ ;
        }

        for(int i = 0 ; i < n ; i ++ ) {
            q[++tt] = s[i];
            cnts[s[i] - 'a']++;
            // 2. 超过 k 则左端出
            if (tt - hh + 1 > k) {
                cnts[q[hh++] - 'a']--;
            }
            // 3. 长度刚好 k 再判断
            if (tt - hh + 1 == k && check()) {
                ans.push_back(i - k + 1);
            }
        }
        return ans ; 
    }
};

// 固定窗口 len(p)
// 寻找 cnt[p...] = cnt[ans , ans + len(p)]  这里看着是 O(n) 的 
// 找的是异位词 如果是同位词 感觉就像是 KMP里面的next 数组了

// 需要有一个算法能够快速 check cnt , 外面的循环肯定是 On 的
// 我们只 check 26个字母。 那么就是 On * 26 只需要通过滑动窗口固定一下窗口即可，当成为队列的时候 check 一下

心路历程

这道题上来就压力拉满了还以为要我写 kmp next 数组的求法但是想了一下我们可以暴力的使用 cnt 进行遍历

不过一开始写滑动窗口的代码很傻逼

我一开始是这样子处理的,如果队列把当前字符插入到队列里面。如果队列满了那么就判断。

我这里的判读逻辑导致我遗漏了当前满节点的这个值。

后来优化了一下代码成上面的样子之后就完成了

        for(int i = 0 ; i < n ; i ++ ) {
            if(tt < hh || (tt - hh  + 1 < k ))  {
                q[++tt] = s[i]; // 空的话入队列 或者 窗口比较小
                cnts[s[i] - 'a'] ++ ;
            }else { // 队列已经满了
                if(check()) {
                    ans.push_back( i -  k  + 1); 
                }
                cnts[q[hh ++ ] - 'a'] -- ; // 队头弹出队列
            }   
        }

实际可以改成

        for(int i = 0 ; i < n ; i ++ ) {
            if(tt < hh || (tt - hh  + 1 < k ))  {
                q[++tt] = s[i]; // 空的话入队列 或者 窗口比较小
                cnts[s[i] - 'a'] ++ ;
            }else { // 队列已经满了
                if(check()) {
                    ans.push_back( i -  k); 
                }
                cnts[s[i] - 'a'] ++ ;
                q[++tt] = s[i];
                cnts[q[hh ++ ] - 'a'] -- ; // 队头弹出队列
            }   
        }

        if(check()) {
            ans.push_back( n -  k); 
        }

feed detail

Fri, 07 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 实现点赞文章Feed

前置

什么是 Feed 流 : 用于将实时生成的数据传递给应用程序

特点：

实时性: 数据实时推送,确保用户获取最新消息
个性化: 根据用户兴趣和行为跳转展示内容
多样性: 支持各种类型的内容, 如文本、图片、视频等

解决了什么问题

如果我要查询, 我关注的人最近发了什么文章. 我们很容易想到一个实现是直接查询数据库

-- 我关注的人最近发的文章
SELECT * FROM articles
WHERE author_id IN (我关注的人)
ORDER BY ctime DESC
LIMIT 20

但是现有的问题是 :

用户不只是要看文章的更新。还想要看 点赞、关注、评论 。
- 每次打开首页都需要查关注列表 → 查文章 → 查点赞 → 查关注事件 → 自己合并排序。
并且关注的人又很多。例如一个人关注了 1000个人。那么每次打开首页都需要扫 1000 人的数据
大 V 发送一条内容。一个大V 如果有100w的粉丝，那么100w的粉丝每次去查询的时候都会发起 100w个select , 。

因此 Feed 流做的事是 :

在事件发生(发文、点赞) 先记录下来, 整理成每人一条时间线。用户打开首页，仅读这条时间线,不再现场拼凑

	没有 Feed	有 Feed
打开首页时	实时去查：我关注了谁 → 每人最近文章 → 再拼点赞、关注等 → 自己排序合并	直接读「我的收件箱/时间线」
复杂度	读路径很重，关注 1000 人就很惨	读路径轻，复杂逻辑提前做完
返回内容	临时拼出来的结果	预先沉淀好的事件流

同理 :

Feed、热榜定时算、缓存预热，都属于同一类思路：

把读路径上又重又复杂的活，提前算好（或换个地方算），业务方直接读结果。

差别主要在「提前到什么时候、给谁算」：

	热榜定时算	缓存预热	Feed（推模型）
何时算	定时批处理	访问前/启动时	事件发生时（有人发文）
给谁	通常一份全局榜	热点 key	每个用户一份时间线
读的时候	直接取榜	直接取缓存	直接取「我的 inbox」

需求分析

从已有功能来说, Feed 流的数据来源可以包含 :

用户关注的人发表了新的作品
用户发表的作品被人点赞、收藏、评论了
用户发表的评论被人回复了
有人关注了该用户
系统通知

目前的平台在组织 Feed 流的时候大体上有两种方式

第一种方式是把前面列举的内容都合并在一起
只把关注者发表新作品做成 Feed 流其余做成系统通知

第一种例如 :

张三 发布了《Go 并发》
李四 赞了你的文章
王五 关注了你
赵六 发布了《Redis 笔记》
钱七 评论了你：写得真好

第二种例如 :

Feed 流

1
2

张三 发布了《Go 并发》
赵六 发布了《Redis 笔记》

系统通知

1
2
3

李四 赞了你的文章
王五 关注了你
钱七 评论了你

第一种方式实现起来更复杂，并且可以删减代码来转化为第二种。因此我们考虑使用第一种方式

Feed 流式设计模式

拉模型

这应该是我们最先能想到的一个办法就是我们直接去手动的获取相关数据。然后聚合成 Feed 流

这种方式的缺陷 :

用户每发起一个查询请求，最终都会扩散为 N个数据库查询，数据库压力很大
分页问题难以处理 : 我们正常使用 Feed 流查询的时候都是分页返回。例如每次返回 20条, 而这 20条是按照时间戳来排序的。我们没办法知道这20条会在哪些数据库上

推模型

推模型是以 Feed 模块为核心, 不同业务方将数据推送过来。

读扩散

我们从拉模型中将查询 DB 的操作改为查询 发件箱 的操作

对于每个业务维护自己的发件箱。用于通知操作
Feed 服务每次需要
- 查询 A 关注了哪些人
- 再查询 A 关注的人里面, 发件箱里面有什么数据
- 聚合排序、取出所需的数据

写扩散

从推模型中引入 收件箱 的概念, 每个业务都有自己的收件箱

对于一个用户爱说，如果用户 A 关注了用户B.

那么 B 再发表一篇新文章的时候就会把数据写入到 A
对于 A 需要查询自己数据的时候只需要查询自己的收件箱即可

写扩散的缺陷 :

极大的放大的流量 , 如果 B 有 100w 粉丝。他发一篇文章的时候就需要同步给 100w 个粉丝

一瞬间就产生了 100w 条记录

读扩散和写扩散的综合应用

我们知道

读扩散的缺点 :

每次读取都需要读取每个业务相关的数据
分页不好处理

写扩散的缺点 :

对于一个大V来说， 100w的粉丝，一次推送就需要推送 100w条数据

因此我们可以考虑一个基本思路

如果一个人的粉丝并不多, 那么就直接使用写扩散模型
如果一个人的粉丝很多, 那么就直接使用读扩散模型

并且这里还可以扩展

判断粉丝是不是活跃用户，在写入数据的时候针对活跃用户进行写扩散

综合使用的优缺点 :

综合使用只能说是一个还不错的方案，是我们在读扩散和写扩散之间做了权衡之后不得不考虑的方案。

• 从写流程来说，它依旧有写扩散的问题，但是我们能够限制住写扩散的数据并不多。

• 从读流程来说，它依旧有聚合排序的问题。如果发件箱已经分库分表的话，那么也会存在跨库跨表查询的问题。

只是说，这两个缺陷都比单独使用读扩散或者单独使用写扩散要轻微，而不是完全没有。

这个综合方案来说，可以优先保障活跃用户的使用体验，而对于非活跃用户来说，它的查询性能就要稍微差一些。

流程设计

写入流程

因为 Feed 里面不同类型的数据，字段会不一样。怎么存业务方同步过来的数据

并且我们进一步考虑

我们是否需要存储一些冗余数据。例如用户的昵称，文章的标题
冗余数据的好处就是从 Feed 里面拿到最完整的数据，而不需要进一步回查业务方

存储扩展数据

对于存储不同事件 Feed 独有的消息有两种方案

一个大的 Json 字段存储这些所有的扩展数据

type FeedEvent struct {
	ID    int64
	Uid   int64
	Type  string          // 决定 JSON 怎么解读
	Ctime time.Time
	Ext   ExtendFields    // map[string]string，个性化字段
}

type ExtendFields map[string]string

使用扩展表

type FeedEvent struct{
	Id int64
	Type string
}

type ArticleEvent struct{
	Id int64
	Fid int64
	Article int64
}

表结构设计

FeedPushEvent 推模型，写扩散。也就是收件箱
FeedPullEvent 拉模型，读扩散。也就是发件箱

最关键的是我们这个 Content 字段。我们设计存储不同事件的个性化字段，是一个 JSON 字段

type FeedPushEvent struct {
	Id int64 `gorm:"primaryKey,autoIncrement"`
	// 收件人
	UID int64 `gorm:"index"`
	// Type 用来标记是什么类型的事件
	// 这边决定了 Content 怎么解读
	Type string
	// 大的 json 串
	Content string
	Ctime   int64 `gorm:"index"`
	// 这个表理论上来说，是没有 Update 操作的
	Utime int64
}

type FeedPullEvent struct {
	Id int64 `gorm:"primaryKey,autoIncrement"`
	// 发件人
	UID int64 `gorm:"index"`
	// Type 用来标记是什么类型的事件
	// 这边决定了 Content 怎么解读
	Type string
	// 大的 json 串
	Content string
	Ctime   int64 `gorm:"index"`
	// 这个表理论上来说，是没有 Update 操作的
	Utime int64
}

扩展字段处理流程

在 Feed 的时候我们并不关心个性化数据是什么。业务方可以随意传递

然后我们再把对应的数据返回回去。由 BFF 自己去解决对应的数据查找

服务定义

定义一个共用的 feedService 和一个业务自己实现的 feedHandler

对于 FeedService 单纯只处理推模型

而 feedHandler 可以根据业务自定义是否要采用拉模型

type FeedService interface {
	CreateFeedEvent(ctx context.Context, feed domain.FeedEvent) error
	GetFeedEventList(ctx context.Context, uid, timestamp, limit int64) ([]domain.FeedEvent, error)
}

// Handler 具体业务处理逻辑
// 按照 type 来分。因为 type 是天然标记了哪个业务
type Handler interface {
	CreateFeedEvent(ctx context.Context, ext domain.ExtendFields) error
	FindFeedEvents(ctx context.Context, uid, timestamp, limit int64) ([]domain.FeedEvent, error)
}

发表文章

对于发表文章来说，我们需要考虑我们最上面的问题

对于一个大V 来说, 如果我们发表一篇文章。应该是让用户自己来读大V的发件箱，也就是拉模型。而不是大V 发送100条消息
所以这里需要额外处理一下

func (a *ArticleEventHandler) CreateFeedEvent(ctx context.Context, ext domain.ExtendFields) error {
	followee, err := ext.Get("uid").AsInt64()
	if err != nil {
		return err
	}
	// 要灵活判定是拉模型（读扩散）还是推模型（写扩散）
	static, err := a.followClient.GetFollowStatic(ctx, &followv1.GetFollowStaticRequest{
		Followee: followee,
	})
	if err != nil {
		return err
	}
	// 粉丝数超过阈值了，然后读扩散，不然写扩散
	if static.FollowStatic.Followers > threshold {
		return a.repo.CreatePullEvent(ctx, domain.FeedEvent{
			Type: ArticleEventName,
			Uid:  followee,
			Ext:  ext,
		})
	} else {
		// 写扩散
		followers, err := a.followClient.GetFollower(ctx, &followv1.GetFollowerRequest{Followee: followee})
		if err != nil {
			return err
		}
		// 在这里，判定写扩散还是读扩散
		// 要综合考虑什么活跃用户，是不是铁粉，
		// 在这里判定
		events := slice.Map(followers.FollowRelations,
			func(idx int, src *followv1.FollowRelation) domain.FeedEvent {
				return domain.FeedEvent{
					Uid:  src.Follower,
					Type: ArticleEventName,
					Ext:  ext,
				}
			})
		return a.repo.CreatePushEvents(ctx, events)
	}
}

部分问题

Q : 为什么同步数据的时候是异步接口？

在设计 Feed 流的时候，我们一般会说 Feed 对实时性的要求很高。那么就会有一个问题，如果要是实时性要求很高的话，为什么在这里我还是用了异步接口？

A :

虽然明面上我们对 Feed 的实时性要求高，但是这种要求其实是秒级，甚至十秒级。也就是说，如果 A 发了一篇文章之后，B 能够在十秒内知道，那么我们认为这个实时性是可以接受的。

查询流程

我们在整个 Feed 系统设计里面只有两个东西

发件箱
收件箱

当用户查询 Feed 的时候, 要求我们聚合这两部分数据。我们有两种方法

在 Service 层统一查询
查询的时候转交 handler 来处理， Handler 内部可以处理一些和具体业务有关的事情

面试

什么是 Feed 流？系统设计方面有什么难点？
- 大数据高并发
在 Feed 里面，什么是拉模型 / 读扩散？有什么优缺点
在 Feed 里面什么是推模型/写扩散？有什么优缺点
在 Feed 里面应该用推模型还是拉模型？
为什么大部分平台都是使用推和拉模型

feed one

Fri, 07 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 实现关注,点赞, 收藏, 发布文章 Feed 流的实现

流程设计

需求分析 :

对于用户关注的博主, 希望能够在博主发布文章的第一时间进行通知
对于点赞 , 关注,收藏操作希望能够第一时间进行通知

模块分析 :

提供一个 Feed 服务供给业务方读取和写入

Feed 模块

支持的功能

通用的写入收件箱
业务定制化的写入收件箱并且根据业务定制考虑优先写入到发件箱
通用的查询用户 Feed 流
业务定制化的查询用户 Feed 流

表结构设计

对于收件箱和发件箱维护一个大JSON列进行处理

创建 uid和 ctime 的索引

type FeedPushEvent struct {
	Id int64 `gorm:"primaryKey,autoIncrement"`
	// 收件人
	UID int64 `gorm:"index"`
	// Type 用来标记是什么类型的事件
	// 这边决定了 Content 怎么解读
	Type string
	// 大的 json 串
	Content string
	Ctime   int64 `gorm:"index"`
	// 这个表理论上来说，是没有 Update 操作的
	Utime int64
}

缓存设计

无。因为需要保证实时性并不考虑设计缓存

但是引入 kafka 进行削峰。因为在业务上能够容忍 1s -10s 的响应误差

其他细节

在文章服务写入收件箱的时候考虑定制化服务

对于大V 关注的人很多, 写扩散来说会产生很多内容。因此根据用户粉丝数量来判断写入发件箱还是收件箱

同样的查询用户 Feed 流的时候同样在文章服务做定制化服务

因为大V 可能发送了文章之后又设置了隐藏，因此会额外根据 status 进行一层过滤

难点 & 亮点

难点 :

问题：

对于文章服务, 如果是一个大V 采用写扩散会一时间产生很多数据，但是普通用户无所谓。但是对于一个普通用户使用读扩散会导致请求多次数据库

方案 :

设计文章服务混合使用推拉模型，而点赞/关注服务只进行写扩散

难点 :

问题 :

读路径可能存在业务方定制和非业务方定制 , 并且还需要考虑数据聚合

方案 :

考虑优先读取业务定制的内容,通过每个handle 自己的实现进行读取。然后再通过通用逻辑进行读取。另外对于第三方业务方如果降级的情况会考虑不进行读取。全局limit查询之后再聚合内容进行排序

亮点 :

使用 Kafka 进行异步的处理 Feed 流
设计了一个通用的和业务定制化的 Feed 流。关联之前开发的点赞、收藏、文章服务

缺点

Feed 流的存储比较简单，非常粗暴的使用大JSON 进行存储并且数据表并没有做定期归档
写入服务还可以再优化，根据判断用户是否是活跃用户，判断是否要使用写扩散保证活跃用户的使用体验

作为面试官，按「2 年经验、能讲清一个完整 Feed 项目」来打分。

总分：62 / 100

维度	得分	满分	说明
需求与业务理解	12	15	关注/点赞/收藏/发文通知说清楚了
架构与方案设计	14	25	有推拉混合，但细节和取舍不够
数据与存储	8	15	表结构过简，缺容量与演进
工程实现（Kafka/异步）	10	15	有削峰思路，缺可靠性细节
难点与亮点表达	10	15	方向对，面试官追问容易露怯
自我反思与边界	8	15	有缺点意识，但深度不够

优点

业务闭环清晰：从「谁要被通知」到「Feed 读写服务」再到「文章大 V 定制」，简历点能对上故事。
推拉混合有意识：大 V 写发件箱、普通人写收件箱，这是 Feed 面试的核心考点，方向正确。
知道自己的短板：大 JSON、无归档、可按活跃用户优化写扩散——自我认知加分。
工程上有基本取舍：用 Kafka 换 1–10s 延迟，比「全都要实时」更真实。

缺点（面试里容易被打穿）

「无缓存」说得太绝对
实时性 ≠ 不能缓存。常见做法是：收件箱最近 N 条 Redis ZSet、发件箱热 Key、读路径短 TTL。直接说「无」会被追问「QPS 上去怎么办」。
表结构过于简陋
- 单表 Content 大 JSON：如何按 Type 过滤、分页、清理？
- uid + ctime 索引是否联合？大 V 粉丝千万级写入怎么分库分表？
- 发件箱表结构没写出来，推拉混合缺一半。
推拉切换规则模糊
「按粉丝数判断」——阈值多少？阈值变化怎么办？粉丝从 999 涨到 1001 历史数据怎么处理？面试官一追问就虚。
读路径描述含糊
「业务定制优先 → 通用逻辑 → 降级跳过 → limit 再聚合」——
多 Handler 如何保证全局时间序？每个源 limit 多少？聚合复杂度？降级后一致性？这些才是 2 年候选人该补的。
Kafka 只停在「削峰」
缺：幂等、顺序（按 uid 分区？）、失败重试/死信、重复投递、消费者并发与乱序。
亮点偏「做过什么」而非「解决了什么」
「用了 Kafka」「接了点赞收藏」——面试官更想听量化效果或具体坑（延迟、重复、空洞 Feed）。
文档结构略乱
功能列表编号重复、发件箱模型缺失、流程图依赖图片但文字没补关键路径。

建议（按优先级）

立刻补齐，面试可讲 3 分钟版

画清两条写路径 + 两条读路径
- 写：普通用户 → 写扩散进粉丝收件箱；大 V → 只写发件箱。
- 读：收件箱时间线 ∪ 关注列表里大 V 发件箱 → merge 按时间排序 → 分页。
把「粉丝阈值」说死
例：粉丝 ≥ 1万走拉模式；并说明阈值变更时只影响新内容、或异步回填策略。
缓存改成「有边界的有」
例：用户 Feed 首屏 200 条 ZSet；未命中再查 DB；写路径异步更新。强调与「可容忍秒级延迟」一致。
Kafka 准备 4 个追问答案
幂等（业务唯一键）、分区键（authorId/uid）、至少一次语义下的去重、消费失败策略。
亮点改成「问题 → 方案 → 结果」
例：「大 V 发文写扩散导致写放大 → 粉丝阈值切拉模式 → 峰值写 QPS 从 X 降到 Y」（没有真实数字就说「预期/压测方向」）。

建议你能背下来的追问清单

分页用 offset 还是 cursor？空洞/重复怎么处理？
取消关注、删文、隐藏后 Feed 如何失效？
点赞/收藏也写 Feed，和文章 Feed 如何统一 Type？
单用户收件箱无限增长怎么办（归档/TTL）？
降级某个业务 Handler 后，用户看到的 Feed 如何保证「还能刷」？

面试官结论

能过初级/中级偏初的筛选，但撑不起「独立设计过 Feed」的强叙事。
架构骨架有了（推拉混合 + 异步削峰 + 业务定制 Handler），但存储、缓存、一致性、容量、读聚合这几块偏薄，和 2 年「做过但未深挖」的画像吻合。

把推拉边界、读合并算法、Kafka 可靠性、缓存策略补成可口述的闭环后，有机会提到 75–80；再补上容量估算和一次真实故障/压测故事，才更像能打的中级候选人。

评论 one

Fri, 07 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 设计并实现了用户的评论功能, 支持多层级的评论回复

流程设计

需求分析 :

需要支持用户某篇文章进行评论
需要支持用户给评论进行评论
需要支持获取评论，以及获取子评论，创建评论，删除评论

模块分析 :

用户可以给文章进行评论也可以给用户的评论进行评论，可以抽象为用户给某个资源进行评论因此将评论单独抽象成一个服务

评论服务模块

支持的功能

获取第一页的评论
删除评论
创建评论
获取单条评论
获取子评论

表结构设计

设计 <PID, id> 外键, 因为我们不允许子评论出现在一个不存在的父评论上。并且我们希望在删除父评论的时候同步删除子评论。
引入 RootID, 因为是通过邻接表创建的评论结构。额外创建一个 RootId 列能够优化查询顶级评论下全部评论的时间
PID 和 RootID 的类型是 Sql.NullInt64 因为顶级节点的父节点是空。这里考虑优化成 -1

type Comment struct {
	ID int64

	Uid int64
	Biz   string `gorm:"index:biz_type_id"`
	BizID int64  `gorm:"index:biz_type_id"`


	PID sql.NullInt64 `gorm:"index"`
	// 外键指向的也是同一张表
	ParentComment *Comment `gorm:"ForeignKey:PID;AssociationForeignKey:ID;constraint:OnDelete:CASCADE"`

	RootID sql.NullInt64 `gorm:"index:root_ID_ctime"`
	Ctime  int64         `gorm:"index:root_ID_ctime"`

	// 评论的内容
	Content string

	Utime int64
}

获取评论列表功能设计

我们需要获取对应业务的第一页所有评论，并且返回前3条子评论

直接根据 biz 和 bizID 进行查询
考虑到并发问题使用 minID 进行偏移控制。如果使用 offset 可能会频繁变化
在降级到时候考虑不去读取子评论。遍历所有顶级节点然后并发的去查询子评论

其他细节

创建和删除的时候通过外键进行约束
查询顶级评论的时候根据 RootId 进行优化

难点 & 亮点

问题 :

对于多级评论的表结构设计

方案 :

使用邻接表的方案进行设计评论表。设计外键 <pid, id> 控制插入子评论的时候不应该插入到不存在的父评论。以及删除父评论的时候应该同步删除子评论

亮点 :

在查找第一页评论的时候需要返回对应的前3条子评论。考虑在服务降级的时候，不走这部分慢查询。
考虑用户可以评论别人的评论和文章将评论服务单独拆成一个服务并且使用 biz + biz_id 进行通用化处理
使用 minId 进行第一次分页查询，避免 offset 在高并发插入下会漏
表结构设计冗余 RootID 列，在查询顶级评论的时候能够直接查询全部回复，而不需要递归一整颗树

缺点

没有较好的缓存方案，例如加载第一页的时候可以考虑维护一个热榜评论，并且缓存第一页定时刷新

总分：68 / 100

对标 2 年 Golang、简历点「多层级评论」：能讲清主干，但深度、完整性和面试表达还不够稳，容易被追问卡住。

分项（满分）

维度	分	说明
需求分析 / 边界	14/20	功能列全了，缺非功能（QPS、延迟、一致性、审核）
表结构 / 建模	16/20	邻接表 + RootID + FK 方向对，细节经不起深挖
查询 / 分页	12/20	知道 minID、降级，论证不严谨，实现路径模糊
亮点可讲性	14/20	有点，但缺「为什么 / 怎么权衡 / 踩过什么坑」
表达与材料质量	12/20	结构尚可，笔误多、描述空、像草稿

优点

服务抽象合理：biz + biz_id 把「评文章 / 评评论」统一成资源评论，符合可扩展拆分，面试官一般认可。
树存储选型正确：邻接表 + 冗余 RootID 是常见方案；外键约束父子存在性、级联删也说得通。
有工程意识：第一页带前 3 条子评、降级不查子评、minID 代替 offset，说明想过热路径和并发插入。
有自省：主动写「缺缓存」比硬吹完整方案更加分。

缺点（面试里会被追的）

「多层级」与实现深度不匹配
简历写多层级，正文几乎是「顶级 + 若干子评」。要明确：产品是无限嵌套还是只展示两级；邻接表如何保证插入时 PID/RootID 一致。
分页说法不严谨
高并发下 offset 的问题主要是重复/跳过、深分页成本，不是简单「漏数据」。minID（游标）要讲清排序键（id 还是 ctime）、同时间戳、方向（上滑/下滑）。
级联硬删很脆
真实产品多为软删、子评保留并标「父评已删」。只说 OnDelete:CASCADE 会被问：误删恢复、审核下架、计数怎么维护。
「前 3 条子评」实现空洞
按时间还是热度？一次 SQL 还是 N+1？并发查子评的限流、错误、超时？降级开关与指标？这些不补，亮点站不住。
空值方案半吊子
sql.NullInt64 vs -1 只提「考虑」，没有索引、查询条件、GORM 写入的结论。
缺面试常问块
创建时事务与 RootID 赋值、内容长度/敏感词、计数（回复数）、鉴权（谁可删）、幂等、缓存一致性——几乎空白。
材料完成度低
description: xxxx、错别字、口语化、无接口草图/时序，显得准备不充分。

建议（按优先级）

准备 3 分钟口述稿：需求 → 为何独立评论服务 → 表（PID/RootID）→ 第一页查询（含前 3 条子评）→ 降级 → 已知不足（缓存）。控制在 2～3 分钟。
画清两种删除语义：硬删级联 vs 软删；选一种并说清对列表、计数、子评展示的影响。
把分页讲死：排序字段、WHERE id < ? ORDER BY id DESC LIMIT、为何不用 offset、边界 case。
补「前 3 条」实现：例如按 root_id 批量取 + 应用层截断，或窗口函数；说明为何不用「每条顶级再查一次」做默认路径。
补一条缓存方案（哪怕未做）：第一页热评 ZSet / 本地+Redis、失效（写删、TTL）、穿透与击穿——对应你自己写的缺点。
对齐简历用词：若只做两级展示，简历改成「支持回复与两级展示」；若真支持 N 级，补插入校验与查询深度限制。
准备 5 个追问答案：并发插评、父评不存在、删父留子、深分页、评论热点文章打爆 DB。

一句话结论

68 分：方向和关键词对，够「做过评论」的入门讲述；要过认真的 Golang 一面/二面，需要把分页、删除语义、子评批量查询和缓存权衡讲扎实，并把材料从草稿修到能直接口述的版本。

热榜 one

Fri, 07 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 实现多实例部署下的热榜异步计算和查询

流程设计

需求分析 :

需要能够获取到最近7天前100点赞的数据

模块分析 :

设计一个 RankService 支持获取 TopN 的操作

模块设计

提供一个基于本地缓存 + Zset 实现的热榜设计并且通过分key 热点信息
提供一个离线计算的热榜服务, 使用小根堆进行维护数据。使用分布式锁启动时固定实例进行计算热榜

难点 & 亮点

问题 :

热榜服务要求高可用高性能以及处理较大的数据怎么做到 ?

方案 :

使用本地缓存 + Redis 的方式进行处理高可用。如果本地缓存和redis 缓存都实效加载本地已过期的进行兜底
较大的数据可以采用分key 的方式进行处理。或者通过业务折中的方式，例如只考虑最近7天的 top 数据，最近 7 天可能最多也就100w条

问题 :

Zset 不可能进行较大数据量大计算, 这会给机器带来很大的压力

方案 :

采用定时任务离线计算。
使用优先队列维护一个小根堆，固定 TopN 的数量。每次分批进行获取数据加载计算

亮点 :

考虑在多实例部署的情况下, 可能会存在多个实例同时计算一个热榜，并且每个热榜都会有细微的偏差。使用分布式锁+自动续约的机制控制同一时间只有一个节点在进行计算
使用 Hacknews 模型 Score = (p - 1) / (T + 2)^G 公式进行计算热点信息。防止点赞数量被老贴市场霸占
在 Redis 存 TopN 的时候晴空 Content 避免占用较大的内存

缺点

缓存方式比较简单
强一致性不足

总分：62 / 100

按「2 年 Golang 后端」面试标准看：方向对、有架构意识，但深度不够、表述不严谨、经不起追问。能过初筛讲清故事，很难稳住深挖。

维度	分数	简评
问题定义与业务抽象	70	TopN + 近 7 天边界清楚
架构设计完整性	65	多级缓存 + 离线计算主链路合理
技术细节与落地	50	缺关键实现、参数、边界条件
难点亮点说服力	68	锁、堆、HN 公式有亮点，但讲不透
表达与专业度	55	错别字、占位符多，像草稿
面试可追问准备	48	几乎没有「被问住」时的备用料

优点

主路径合理：查询走本地缓存 → Redis → 兜底；计算走离线 TopN + 小根堆，符合热榜常见做法，不是乱堆关键词。
有业务折中意识：用「近 7 天 / 约 100 万」控数据量，比硬扛全量排序更像有生产经验。
亮点选得对：多实例分布式锁、Hacker News 时间衰减、ZSet 不存 Content——这些正是面试官能追问的点。
主动暴露缺点：缓存简单、强一致不足，至少说明你知道系统边界，比只会吹「高可用高性能」好。
有架构图：比纯文字更容易在面试里讲清读写两条链路。

缺点（面试会被卡住的地方）

简历描述太空：「多实例部署下的热榜异步计算和查询」没有规模、指标、职责边界，面试官第一问就会要数字。
方案停在名词层：分 key、小根堆、分布式锁、自动续约都点到了，但缺：
- 分 key 规则（按天？按互动类型？怎么合并 TopN？）
- 堆的维护时机与批大小
- 锁用 Redis/etcd？续约失败怎么办？持锁实例挂了呢？
- 本地缓存过期后仍兜底，跨实例一致性怎么说？
公式只写了不解释：Score = (p - 1) / (T + 2)^G 里 p/T/G 含义、G 怎么选、和「点赞数排序」差在哪，不讲等于没亮点。
图文对不齐：图里有并发 Queue、分区、forceGetLocal，正文几乎没展开，面试官对着图一问，你会空。
「高可用」论证弱：本地 + Redis 失效后用过期数据，是降级不是高可用；没有说明降级 SLA、空榜、穿透、击穿。
表达不专业：xxxx、实效→失效、晴空→清空、Hacknews，会直接拉低可信度。
缺点写完就停了：「强一致性不足」没有影响面和为何可接受，像没想完。

建议（按面试准备优先级）

补一组可说的数字：数据量、TopN、计算周期、单次计算耗时、QPS、缓存命中率、锁超时/续约周期。没有真实数也要给合理量级。
准备 3 层回答：一句话结论 → 架构步骤 → 细节/权衡。例如「为何小根堆」：只要 Top100，堆复杂度 O(n log k)，比全量排序或大 ZSet 更合适。
把追问清单写进稿子，至少覆盖：
- 多实例本地缓存不一致怎么办？
- 计算中途失败，半成品会不会写进 Redis？
- 分 key 后如何得到全局 Top100？
- 锁续约失败 / 时钟漂移 / 脑裂
- 缓存击穿（热榜 key 过期瞬间）
讲清 HN 公式：老帖高赞为何会被新帖追上；G 调大/调小的业务含义。
把图里的并发 Queue 讲成 Go 实现：channel + worker pool、batch size、背压，对应 2 年经验该有的落地感。
润色表述：去掉占位符和错别字；简历改成「近 7 天 Top100 热榜：离线小根堆计算 + Redis ZSet + 本地缓存，分布式锁保证单实例计算」。
缺点改成「已知取舍」：例如强一致不必要，因为热榜允许分钟级延迟；用计算周期 + TTL 把最终一致说清楚。

面试官视角一句话

作为 2 年经验候选人，这份材料证明你做过热榜、懂分层和折中，但目前更像设计草稿，不像能扛 20–30 分钟深挖的面试稿。把「分 key / 锁续约 / 公式参数 / 并发队列 / 降级语义」补实，并清掉错别字，分数大概能到 75–80；再补上指标和失败场景，才比较稳。

用户关系 detail

Fri, 07 Aug 2026 00:00:00 +0000

简历 preview

[all_in_ai] AI 名词扫盲 FunctionCall

Thu, 06 Aug 2026 00:00:00 +0000

什么是 FunctionCall

我们已经知道一个 Tool 是 函数本体+名称+描述+参数 定义的

有一个关键问题 : 大模型在作出要调用这个工具的决策之后, 它怎么告诉 Agent 去执行

大模型只会说话 , 输出的永远只是文字

Agent 要调用工具,必须知道调哪个工具，传什么参数，格式是什么。这中间的信息交换，靠什么来保证正确

没有 Funcition Call 之前

开发者将全部自然语言写进 system prompt 系统提示词里面

你是一个智能助手，你可以使用以下工具：

工具名：check_weather
功能：查询菜个城市的天气

参数：
- city：城市名，中文，比如"上海"
- date：日期，格式必须是 YYYY-MM-DD，比如"2026-03-19"
- date 是可选的，不填默认查今天


当用户需要查天气时，你要调用这个工具，告诉我工具名和参数。

你让他查 [上海明天的天气] ，可能会返回

散文式回复 :, “好的，我来帮你查询上海明天的天气”
参数顺序颠倒 :

TBD

canal

Thu, 06 Aug 2026 00:00:00 +0000

canal

TBD

ELK

Thu, 06 Aug 2026 00:00:00 +0000

ELK

TBD

搜索 detail

Thu, 06 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 设计并实现了搜索

需求分析

平台里面都会有一个搜索栏大体上的目的是 :

方便用户快速找到所需的内容
增加广告收入

支持搜索主要是支持 :

搜索具体的用户
搜索某篇文章

因为需要考虑使用使用 ES 进行实现, 所以需要把这两个服务原有的数据额外的写入到 ES 中。

Q : 为什么不是用户直接写入到 ES

A : 从 DDD 的角度来说 , es 并不考虑 user 的索引怎么确定也不处理一些业务相关的内容。所以只能通过 search 服务

搜索流程设计

推送接口

支持业务定制化的结构和统一处理的结构
提供统一处理接口和定制化接口

service SyncService {
  rpc InputUser (InputUserRequest) returns (InputUserResponse);
  rpc InputArticle (InputArticleRequest) returns (InputArticleResponse);
  rpc InputAny(InputAnyRequest) returns(InputAnyResponse);
  // 同步标签
  // rpc InputTags()
}

推送接口实现

唯一需要注意的一点就是,我们需要传入 user.Id 保证是 updateSert 语意

func (h *UserElasticDAO) InputUser(ctx context.Context, user User) error {
	_, err := h.client.Index().
		Index(UserIndexName).
		Id(strconv.FormatInt(user.Id, 10)).
		BodyJson(user).Do(ctx)
	return err
}

es 表结构设计

文章表结构

mapping :

title : type : text

content : type : text

id : type long ; (贯穿业务的id)

status : type : interger

用户表结构

mapping :

nickname : type : text

email : type : text (不使用keyword，正常人很难记住邮箱)

phone : type : keyword

id : tyoe long

(这里要不要处理,理论上来说前端是不支持的。用户层面应该是看不到的，但是客服预计能看到)

搜索接口设计

service SearchService {
  // 这个是最为模糊的搜索接口
  rpc Search(SearchRequest) returns (SearchResponse);
}

搜索接口的实现

func (s *SearchServiceServer) Search(ctx context.Context,request *searchv1.SearchRequest,)(*searchv1.SearchResponse, error) {
	resp, err := s.svc.Search(ctx, request.Uid, request.Expression)
	if err != nil {
		return nil, err
	}
	return &searchv1.SearchResponse{
		User: &searchv1.UserResult{
			Users: slice.Map(resp.Users, func(idx int, src domain.User) *searchv1.User {
				return &searchv1.User{
					Id:       src.Id,
					Nickname: src.Nickname,
					Email:    src.Email,
					Phone:    src.Phone,
				}
			}),
		},
		Article: &searchv1.ArticleResult{
			Articles: slice.Map(resp.Articles, func(idx int, src domain.Article) *searchv1.Article {
				return &searchv1.Article{
					Id:      src.Id,
					Title:   src.Title,
					Status:  src.Status,
					Content: src.Content,
				}
			}),
		},
	}, nil
}

func (h *UserElasticDAO) Search(ctx context.Context, keywords []string) ([]User, error) {
	queryString := strings.Join(keywords, " ")
	query := elastic.NewBoolQuery().Must(
		elastic.NewMatchQuery("nickname", queryString),
	)
	resp, err := h.client.Search(UserIndexName).Query(query).Do(ctx)
	if err != nil {
		return nil, err
	}
	res := make([]User, 0, len(resp.Hits.Hits))
	for _, hit := range resp.Hits.Hits {
		var ele User
		err = json.Unmarshal(hit.Source, &ele)
		if err != nil {
			return nil, err
		}
		res = append(res, ele)
	}
	return res, nil
}

推送消息

我们在推送消息那个模块引入 3个 kafka 进行异步的推送消息

为不同的业务定义不同的 event , 而后业务方朝特定的 Topic 发送消息
定义一个统一的 Event 的格式

标签流程设计

标签功能

提升用户体验
提高搜索引擎优化
社交分享
个性化推荐

全局标签、个人标签、通用标签

用户创建标签
用户对某个资源打上标签

表结构设计

创建两张表

Tag 表 , 索引 uid . 主要是为了解决加载个人的全部标签的内容
TagBiz 表, 记录某个人对某个资源打的标签。
理论上我们可以通过 TagBiz 查询一次 Tag 进行获获取 Uid。但是会多一次自查询。尤其是我们在覆盖标签的写法的时候删除的时候很麻烦

1
2

// delete from tag_biz where tid IN
// (select distinct id from tag where uid = ?) AND biz = ? AND biz_id = ?

我们为什么要外键。 Tid 必须对应完整的 Id 字段。避免脏关系。并且设置级联删除，删除标签的时候关联的 tag_bizs 一起清理掉

type Tag struct {
	Id int64 `gorm:"primaryKey,autoIncrement"`
	// 我要不要在这里创建一个唯一索引<uid, name>
	Name string `gorm:"type=varchar(4096)"`
	// 要在 uid 上创建一个索引
	// 因为你有一个典型的根据 uid 来查询的场景
	Uid   int64 `gorm:"index"`
	Ctime int64
	Utime int64
}

// TagBiz 某个人对某个资源打了标签。
type TagBiz struct {
	Id    int64  `gorm:"primaryKey,autoIncrement"`
	BizId int64  `gorm:"index:biz_type_id"`
	Biz   string `gorm:"index:biz_type_id"`
	// 冗余字段，加快查询和删除
	// 这个字段可以删除的
	Uid int64 `gorm:"index"`
	//TagName string
	Tid   int64
	Tag   *Tag  `gorm:"ForeignKey:Tid;AssociationForeignKey:Id;constraint:OnDelete:CASCADE"`
	Ctime int64 `bson:"ctime,omitempty"`
	Utime int64 `bson:"utime,omitempty"`
}

缓存方案

对于获取用户的全部 tags 我们使用 redis-list 进行缓存预加载

提供一个 PreloadUserTags 在程序启动的时候获取全量的tags 分为多个不同的 uid list 进行插入


func (repo *CachedTagRepository) PreloadUserTags(ctx context.Context) error {
	offset := 0
	const batch = 100
	for {
		dbCtx, cancel := context.WithTimeout(ctx, time.Second)
		// 在这里还有一点点的优化手段，就是 GetTags 的时候，order by uid
		tags, err := repo.dao.GetTags(dbCtx, offset, batch)
		cancel()
		if err != nil {
			return err
		}
		for _, tag := range tags {
			rctx, ccancel := context.WithTimeout(ctx, time.Second)
			err = repo.cache.Append(rctx, tag.Uid, repo.toDomain(tag))
			ccancel()
			if err != nil {
				continue
			}
		}
		if len(tags) < batch {
			return nil
		}
		offset += batch
	}
}

func (r *RedisTagCache) Append(ctx context.Context, uid int64, tags ...domain.Tag) error {
	data := make([]any, 0, len(tags))
	for _, tag := range tags {
		val, err := json.Marshal(tag)
		if err != nil {
			return err
		}
		data = append(data, val)
	}
	key := r.userTagsKey(uid)
	// 利用 pipeline 来执行，性能好一点
	pip := r.client.Pipeline()
	pip.RPush(ctx, key, data...)
	if r.expiration > 0 {
		pip.Expire(ctx, key, r.expiration)
	}
	_, err := pip.Exec(ctx)
	return err
}

标签 + 搜索

使用 kafka 发送一个通用的信息到 any里面。注意这里需要保证有序性因此需要设置key

func (svc *tagService) AttachTags(...)error {
	err := svc.repo.BindTagToBiz(ctx, uid, biz, bizId, tags)
	if err != nil {
		return err
	}
	// 异步发送
	go func() {
		ts, err := svc.repo.GetTagsById(ctx, tags)
		if err != nil {
			svc.logger.Error("查询标签失败", logger.Error(err.Error()))
			return
		}
		// 这里要根据 tag_index 的结构来定义
		// 同样要注意顺序，即同一个用户对同一个资源打标签的顺序，
		// 是不能乱的
		pctx, cancel := context.WithTimeout(context.Background(), time.Second)
		defer cancel()
		err = svc.producer.ProduceSyncEvent(pctx, events.BizTags{
			Uid:   uid,
			Biz:   biz,
			BizId: bizId,
			Tags: slice.Map(ts, func(idx int, src domain.Tag) string {
				return src.Name
			}),
		})
		if err != nil {
			svc.logger.Error("发送标签搜索事件失败", logger.Error(err.Error()))
		}
	}()
	return nil
}

&sarama.ProducerMessage{
    Topic: "search_sync_data",
    Key:   sarama.StringEncoder(fmt.Sprintf("%d_%s_%d", tags.Uid, tags.Biz, tags.BizId)),
    Value: sarama.ByteEncoder(data),
}

标签索引定义 :

{
  "mappings": {
    "properties": {
      "tags": {
        "type": "keyword"
      },
      "uid": {
        "type": "long"
      },
      "biz": {
        "type": "keyword"
      },
      "biz_id": {
        "type": "long"
      }
    }
  }
}

关联两个查询

一个问题：

我们标签和文章是两个索引, 我们需要解决一个类似 mysql 一样的 JOIN 查询

ES 提供了两种方式

内嵌文档
父子关系

这两种性能很差，我们采用多次查询的方式

先查询标签，找到对应的 biz id
查询 article ,子 title 和 conent 的查询基础上进一步叠加是否在第一次查询到的 biz id

先去 tags 查询出符合条件的 artclie - id
然后再去 article 查询对应的文章。并且设置文章命中的权重更高

	ids, err := a.tags.Search(ctx, uid, "article", keywords)
	if err != nil {
		return nil, err
	}
	// 加一个 bizids 的输入，这个 bizid 是标签含有关键字的 biz_id
	arts, err := a.dao.Search(ctx, ids, keywords)
	if err != nil {
		return nil, err
	}
	// ..

func (h *ArticleElasticDAO) Search(ctx context.Context,tagArtIds []int64,keywords []string,) ([]Article, error) {
	queryString := strings.Join(keywords, " ")
	// 标签命中
	tagArtIdAnys := slice.Map(tagArtIds, func(idx int, src int64) any {
		return src
	})
	title := elastic.NewMatchQuery("title", queryString)
	content := elastic.NewMatchQuery("content", queryString)
	or := elastic.NewBoolQuery().Should(title, content)
	if len(tagArtIds) > 0 {
		tag := elastic.NewTermsQuery("id", tagArtIdAnys...).Boost(2.0)
		or = or.Should(tag)
	}
	query := elastic.NewBoolQuery().Must(
		or,
		elastic.NewTermQuery("status", 2),
	)
	// ..
}

面试

你有没有用过 ES ？用它来解决什么问题？
ES 中的倒排索引是什么？为什么叫做倒排索引？
ES 是如何组织倒排索引的？核心是利用了 FST 结构
ES 的节点类型有哪些？他们的作用是什么？
ES 的写入过程是怎么样的？为什么说他是近实时的

什么是缓存预加载？
怎么判定一个场景要不要缓存？缓存时间多久？
- 同一个资源，短时间内不会被重复访问就不需要缓存
- 理论上缓存时间应该根据用户的习惯来定
如何控制 ES 返回的结果
怎么在 ES 中解决类似 Mysql Join 的查询场景？

搜索 one

Thu, 06 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 设计并实现了搜索

流程设计

需求分析 :

支持用户创建标签, 查看已有标签, 删除标签
支持用户给指定文章打标签
支持用户查询对应关键字的文章并且把打过标签的文章优先返回

模块分析 :

考虑标签应该是一个通用的功能所以将标签单独拆分一个模块

并且不希望业务直接写入ES，单独设计一层搜索和插入服务。将读和写拆成两个服务

标签服务模块

支持功能

覆盖标签
创建标签
获取用户的全部标签
获取用户给某篇文章打的全部标签

表结构设计

设计 Tag 表, 和 TagBiz 表用于统计用户创建的 tag 和用户给文章标记的 Tag

索引设计 :

在 Tag 表上设计了 uid 为索引，保证获取用户的全部标签的时候能够命中

在TagBiz表设计了 biz_id,biz 和 uid 设计了索引, 同时tagBiz 设置 target_id 外键连接 tag 表

考虑 uid 的不可变性, 设计 tagBiz 表的时候冗余了 uid 的设计，从而在查寻用户给某篇文章打的标签的时候不需要去Join Tag表加速查询

缓存设计

在获取用户的全部标签的时候, 考虑使用缓存预加载进行优化

在程序启动的时候，提前全量扫描一次数据库
将数据分key 加载到 redis-list 中
在获取全部标签的时候预先读取缓存再去操作数据库

插入搜索模块

支持

通用的插入逻辑 content_id,content
业务定制化的 user 和 article 的插入逻辑

Es 索引设计

文章表结构设计 :

title , content , id ,status . 这里引入 status 主要是为了后续用户可以查看到仅自己可以见的文章处理

用户表设计 :

nickename, email(text), phone, id . email设计称为 text 而不是keyword是因为正常人很难记住邮箱

数据插入处理

使用 Kafka 开启 3个 Consumer 分别监听文章, User, Any 的插入

因为我们在索引中引入了 id 字段, 保证了在并发场景下是 upsert 语意

查询搜索模块

支持查询有关用户的信息
支持查询有关文章的信息
- 并且将用户打过标签文章的内容优先返回

联合 Tag 查询

Es 支持通过父子关系和内嵌文章进行联合查询但是性能过差。我们这里采用二次查询的方式实现联合查询

先查询 Tag 里面的内容，查询当前用户已经打过标签的文章 id
再去查询有关keywords的文章信息，并且使用 TermQuery Boost 增加在第一次查询出来的权重

难点 & 亮点

问题 :

用户在给某个文章打标签的时候都会加载一次自己已有的全部标签, 预计这里会是一个高频的全量扫表过程

方案 :

使用 Redis-list 预加载一次全部用户的全部标签内容
每次查询优先查询缓存再查询数据库,对于未命中的内容再次更新缓存

问题 :

在获取用户给某篇文章的所有标签内容处理时都需要去 Join 一次 Tag 表 . Join操作会变慢

方案 :

因为 Uid 的不可变性。我们设计的 tag 是基于 Uid 的。不存在用户A给文章 A打了标签。突然这个标签变成用户 B 的情况。所以在 TagBiz 冗余了 Uid 字段加速查询

问题 :

用户对一篇文章重复打标签可能会有并发问题。因为我们使用 kafka 进行发送Es信息

方案 :

在对应 producer 的时候, 使用 key 绑定对应的uid 保证同一个uid 的内容只会发送到同一个分区

亮点 :

实现了两个 Tag 内容之前的查询 , 使用二次查询的方法实现用户查询有关文章的时候, 优先返回已打标签的文章

亮点 :

搜索服务拆分成 sync 和 search ,读写分离。业务方面不直连 Es . 并且支持 InputAny 方便业务快速上线

亮点 :

预加载的时候使用 pipeline 进行打包发送 redis 指令

缺点

仅实现了文章和标签的相关服务。实现内容过少，并没有聚合点赞收藏等业务
Kafka 部分少了兜底机制

总分：61 / 100

定位：2 年经验、项目深挖准备材料。能讲清主流程和模块边界，但多处方案经不起追问，Golang 工程深度偏弱。面试中「能讲」可以，扛不住连环追问。

维度	分数	说明
需求与模块拆分	72	标签独立、读写拆分思路清楚
表结构 / 索引	65	有索引与冗余意识，外键与命名易被挑
缓存设计	42	启动全量预加载是明显硬伤
ES / 搜索	60	二次查询 + Boost 合理，缺量化与一致性
Kafka / 并发	48	问题与解法错位
难点亮点表达	68	有结构，但方案可信度不足
自我认知	70	知道功能少、缺兜底
Golang 工程深度	35	几乎看不到语言/并发/落地细节

优点

需求 → 模块 → 表 → 缓存 → MQ → ES 叙事完整，面试官能跟着走。
标签独立模块 + sync/search 读写分离 + 业务不直连 ES，符合中级对边界的基本要求。
TagBiz 冗余 uid 避免 Join、ES 二次查询 + Term Boost（相对 nested/父子文档）是可讲的取舍。
有难点/亮点/缺点框架，并提到 Kafka 缺兜底、功能未聚合，比只会吹亮点强。
提到 pipeline 批量写 Redis、id upsert，说明接触过落地细节。

缺点（面试里最容易被打穿的点）

缓存方案危险
启动全量扫库、把「全部用户全部标签」塞进 Redis List：冷启动、内存、扩缩容、局部失效都没讲。2 年经验里这是减分点，不是加分点。List 也不适合标签的增删改；一致性（写标签后如何更新缓存）几乎空白。
并发问题与解法错位
「重复打标签」应落到：DB 唯一约束 / 事务 / 幂等。Kafka 按 uid 分区只保证同 uid 有序，解决不了重复打标、更解决不了跨服务幂等。面试官一追问就会露馅。
ES 细节经不起问
- email 用 text：理由偏弱，应讲分词、模糊、精确匹配、keyword 多字段。
- status 字段只点到，未见权限/过滤怎么做。
- upsert、同步延迟、最终一致性、失败重试几乎没准备。
表设计表述不严谨
TagBiz target_id 外键、索引 (biz_id, biz) + uid 缺查询路径说明；「覆盖标签」语义不清。
缺量化与 Golang 深度
无 QPS、延迟、数据量、缓存命中率。无接口抽象、超时取消、consumer 并发、错误处理、压测——对 Golang 岗这是硬伤。
材料完成度
「其他细节」空、序号重复、resume「搜索」与正文「标签+搜索」焦点略散。

建议（按优先级）

1. 重写缓存故事（必改）
改成：按 uid 懒加载 / 热点预热；Hash 或 String+JSON；打标/删标时删缓存或局部更新；讲穿透、击穿、雪崩之一即可。删掉「启动全量预加载所有用户」。

2. 对齐「重复打标」叙事
主答：唯一索引 (uid, biz, biz_id, tag_id) + 幂等；Kafka 分区 key 只作为「同步有序/同用户串行」的补充，不要当并发正解。

3. 补 3 个可量化数字
例：标签人均条数、搜索 P99、sync 延迟、日增量。没有真实数据就给设计目标量级，比没有强。

4. 准备 5 个追问答案

标签写后搜索多久可见？
sync 失败怎么办？（重试、DLQ、对账）
缓存与 DB 不一致怎么办？
Boost 权重怎么定、如何验证效果？
为何不用 nested / join / 宽表？

5. 补 Golang 落地半页
Consumer 并发模型、context 超时、接口分层、ES client 错误处理、本地单测怎么 mock——面试官常从这里区分 1 年和 2 年。

6. 收束简历表述
简历写「标签 + 搜索（读写分离）」或主讲一条线，避免「实现了搜索」却大段讲标签预热。

面试官一句话结论

能过初筛讲项目，过不了深挖。 模块拆分和二次查询+Boost 可以撑住 10–15 分钟；缓存全量预加载和「Kafka 解决重复打标」会把印象从「还行」拉到「基础不扎实」。把这两处改掉，材料有机会到 75+；再补量化与 Golang 细节，更接近 2 年合格线。

Es

Wed, 05 Aug 2026 00:00:00 +0000

Es

提供一种简单、高效的方式来存储、搜索和分析大量数据

ES 支持近实时的搜索

ES 支持极大数据量

ES 提供 Resful API

主要核心就是 : 搜索

搜索引擎的搜索并不依赖 ES，因为搜索引擎优先出现。但是他们底层都是倒排索引

搜索、广告、金融

数据的组织方式 :

索引: 类比 Mysql 的表
文档 : 类比 Myssql 的表的数据

数据的部署方式 :

分片: 类比关系数据库的分库分表
副本 : 类比主从同步中的从库

索引与倒排索引

索引 : 数据本身

倒排索引 : 从属性出发，找到这些属性的数据

ES 写入流程 :

文档首先写入到 buffer 里面
定时刷新到 page cache 中，这个过程叫做 refresh
刷新到磁盘中

ES HTTP API

创建索引

Es 暴露了 HTTP API 。可以通过 HTTP 请求来操作整个 CRUD

我们在下面的操作进行了 :

创建了一个索引
制定了 3个分片和 2个副本
设置了3个字段，并且设置了每个字段的类型

写入数据 & 查询数据

通过指定 index 和 _doc 表示我们在 user_index 写入了数据

我们通过 index 和 search 指定我们查询的数据

虽然我们并没有指定完整的 email 但是还是返回了预期的结果

ES 支持的查询

Match Query（匹配查询）：根据字段中的内容进行全文匹配查询。

• Term Query（精确查询）：根据字段中的精确值进行查询，适用于 keyword 类型或者已经执行过分词器的字段。

• Range Query（范围查询）：根据字段中的范围值进行查询，可以用来查询数字或日期范围。

• Bool Query（布尔查询）：通过逻辑运算符（must、must_not、should）组合多个查询条件，实现更复杂的查询逻辑。

• Match Phrase Query（短语匹配查询）：根据字段中连续的短语进行查询，适用于需要保持短语顺序的查询。

• Prefix Query（前缀查询）：根据字段中的前缀进行查询，适用于需要按照前缀匹配查询的场景。

• Wildcard Query（通配符查询）：根据通配符模式进行查询，支持通配符符号（*和?）进行模糊匹配。

• Fuzzy Query（模糊查询）：根据字段中的模糊匹配进行查询，可以通过设置 fuzziness 参数来控制模糊程度。

• Nested Query（嵌套查询）：根据嵌套对象进行查询，以便查询嵌套在文档中的相关信息。

• Aggregation Query（聚合查询）：用于计算、统计和分析数据，包括求和、平均值、最小值、最大值、分组等操作

查询例子

下面分别进行了

一次精确匹配
查询范围大于等于的日期

ES & Go

创建索引

这里可以看到，实际上我们还是需要构造一个如 http 一样的 jsonBody

func (s *ElasticSearchTestSuite) TestCreateIndex() {
	ctx, cancel := context.WithTimeout(context.Background(), time.Second*3)
	defer cancel()
	// 这是一个链式调用，你可以通过链式调用来构造复杂请求。
	// 重复创建会报错，所以你可以换一个名字
	resp, err := s.es.Indices.Create("user_idx_test",
		s.es.Indices.Create.WithContext(ctx),
		s.es.Indices.Create.WithBody(strings.NewReader(`
{  
  "settings": {  
    "number_of_shards": 3,  
    "number_of_replicas": 2  
  },  
  "mappings": {  
    "properties": {
      "email": {  
        "type": "text"  
      },  
      "phone": {  
        "type": "keyword"  
      },  
      "birthday": {  
        "type": "date"  
      }
    }  
  }  
}
`)))
	require.NoError(s.T(), err)
	assert.NotNil(s.T(), resp)
	assert.Equal(s.T(), 200, resp.StatusCode)
}

写入文档

通过 client.index 指定对应的 index 然后放入文档

func (s *ElasticSearchTestSuite) TestPutDoc() {
	ctx, cancel := context.WithTimeout(context.Background(), time.Second*3)
	defer cancel()
	resp, err := s.es.Index("user_idx_test", strings.NewReader(`
{  
  "email": "john@example.com",  
  "phone": "1234567890",  
  "birthday": "2000-01-01"  
}
`), s.es.Index.WithContext(ctx))
	require.NoError(s.T(), err)
	require.NotNil(s.T(), resp)
	assert.Equal(s.T(), 201, resp.StatusCode)
}

搜索文档

func (s *ElasticSearchTestSuite) TestGetDoc() {
	ctx, cancel := context.WithTimeout(context.Background(), time.Second*3)
	defer cancel()
	resp, err := s.es.Search(s.es.Search.WithContext(ctx),
		s.es.Search.WithBody(strings.NewReader(`
{  
  "query": {  
    "range": {  
      "birthday": {
        "gte": "1990-01-01"
      }
    }  
  }  
}
`)))
	require.NoError(s.T(), err)
	assert.Equal(s.T(), 200, resp.StatusCode)
}

打赏 one

Wed, 05 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 支持用户使用微信支付进行文章的打赏功能以及用户对账流程

流程设计

需求分析 :

用户能够选择一篇文章通过微信支付进行打赏
支付成功后用户能够在自己的余额里面看到扣款以及被打赏的金额，同时可以看到对应的流水

模块设计 :

考虑支付是一个通用的模块, 并且支付可以额外对接审计，账号，反洗钱等模块所以把支付模块单独拆分出来

设计 支付、用户资产、打赏 三个模块

功能分析 :

用户模块支持 :

查看业务流水
更新用户资产

打赏模块支持 :

查看文章打赏记录
发起支付请求

支付模块支持 :

向第三方发起支付请求
接受微信支付的calback
查询发起的支付信息

难点 & 亮点

问题 :

微信支付回调后如果成功那么不会在此推送消息, 我们使用 MQ进行通知下游,如果MQ发送失败那么将丢失该信息

方案 :

引入本地消息表
使用本地事务开启支付表和本地消息表的写入。并且设置消息表 init
只有当MQ发送成功之后才会设置本地表 success 。
定时任务定时轮询 init 的任务进行补偿

问题 :

由于本地消息表的引入, 可能带来重复消费的问题

方案 :

在下游账户处理模块，设置了 biz_id + biz + account + account_type 的联合唯一索引
并且引入 redis 进行查询优化, 预先判断 redis 的状态

问题 :

可能存在微信回调消息发送失败, 微信回调只会默认会在 30分钟之后不再回调不管成功或是失败

方案 :

定时任务定期扫描超过约30分钟的未完结订单主动查询微信状态并写回

问题 :

获取打赏信息的时候 ,我们会先去查询打赏表的数据,如果打赏表数据还未完成。会通过慢路径查询支付表的信息进行更新用于加快状态的轮询。

方案 :

考虑限流时候降级, 对于限流的时候不走慢路径
在账户资产更新 MQ 的时候会一并更新对应的状态

亮点 :

模块拆分与边界 + gRPC

支付只关心第三方与支付单状态
打赏只关心业务单和分账意图
账户只关心余额与流水

缺点

缺少定时自动对账的机制。涉及 打赏-支付-记帐 三个流程
在 MQ 更新账户资产和打赏表的时候。并不是强一致的, 我们优先更新打赏表, 如果之后调用 rpc 处理账户资产失败了。那么会发送告警由人工手动修复

其他细节

支付消息必然发送成功

支付的一个核心步骤是由微信来回调的 . 我们原先的处理是

微信回调
更新支付表状态
发送消息给 MQ 通知账户变更

如果这里 MQ 发送失败,那么将会丢失这笔消息。但是支付消息可以认为是一个非常关键的功能。

所以考虑优化引入了本地消息表

表结构设计

主要字段 content 和 status
我们通过 content 记录原有的 MQ 信息使用 status 维护 MQ 的状态分为 init,success,failed

{
id: "id"
content: ""
stauts: ""
Ctime: ""
Utime: ""
}

流程优化设计 :

使用事务控制更新支付表状态和写入本地事务表并且初始化 init
只有当我们成功发送 MQ 之后才把本地事务表设置 success
- 这里可能会造成重复发送
开启一个定时任务，批次获取 init 的状态, 然后发送 MQ 消息。如果半小时内都发送失败设置 failed . 发送成功之后设置 success

接口幂等性分析

由于改造了本地事务之后，可能会产生重复消费数据 . 我们在下游账户更新的时候

通过 redis+ 本地索引来处理。

我们设置账户流水表的唯一索引 biz,biz_id,account,account_type 进行过滤

biz_id 就是微信回调里面带的 tradeNoId

使用 redis 进行初步过滤使用唯一索引进行兜底

打赏详情降级处理

我们打赏的时候会先查询我们打赏表如果打赏已经是支付状态会直接返回
否则会去查询一遍支付表

对于限速的状态,我们会抛弃这个慢路径。这条慢路径，由 MQ 进行处理, MQ 会较慢一点时间更新到支付表的状态。

func (s *WechatNativeRewardService) GetReward(ctx context.Context, rid, uid int64) (domain.Reward, error) {
	// 快路径
	r, err := s.repo.GetReward(ctx, rid)
	if err != nil {
		return domain.Reward{}, err
	}
	if r.Uid != uid {
		// 说明是非法查询
		return domain.Reward{}, errors.New("查询的打赏记录和打赏人对不上")
	}

	// 有可能，我的打赏记录，还是 Init 状态
	// 已经是完结状态
	if r.Completed() || ctx.Value("limited") == "true" {
		// 我已经知道你的支付结果了
		return r, nil
	}

	// 这个时候，考虑到支付到查询结果，我们搞一个慢路径
	// 你有可能支付了，但是我 reward 本身没有收到通知
	// 我直接查询 payment，
	// 只能解决，支付收到了，但是 reward 没收到
	// 降级状态，限流状态，熔断状态，不要走慢路径
	resp, err := s.client.GetPayment(ctx, &pmtv1.GetPaymentRequest{
		BizTradeNo: s.bizTradeNO(r.Id),
	})
	if err != nil {
		// 这边我们直接返回从数据库查询的数据
		s.l.Error("慢路径查询支付结果失败",
			logger.Int64("rid", r.Id), logger.Error(err.Error()))
		return r, nil
	}
	// 更新状态
	switch resp.Status {
	case pmtv1.PaymentStatus_PaymentStatusFailed:
		r.Status = domain.RewardStatusFailed
	case pmtv1.PaymentStatus_PaymentStatusInit:
		r.Status = domain.RewardStatusInit
	case pmtv1.PaymentStatus_PaymentStatusSuccess:
		r.Status = domain.RewardStatusPayed
	case pmtv1.PaymentStatus_PaymentStatusRefund:
		// 理论上来说不可能出现这个，直接设置为失败
		r.Status = domain.RewardStatusFailed
	}
	err = s.repo.UpdateStatus(ctx, rid, r.Status)
	if err != nil {
		s.l.Error("更新本地打赏状态失败",
			logger.Int64("rid", r.Id), logger.Error(err.Error()))
		return r, nil
	}
	return r, nil
}

总分：72 / 100

对应 2 年经验中级偏上：系统设计与可靠性意识不错，能讲清主链路和几个关键问题；但深度、闭环和对面试追问的准备还不够稳。

评分拆解

维度	分数	说明
需求与业务理解	14/20	主流程清楚，但对账、分账、退款几乎空缺
模块拆分与边界	16/20	支付 / 打赏 / 账户划分合理，亮点明确
可靠性设计（消息必达、补偿）	18/20	本地消息表 + 定时补偿是加分项
幂等与一致性	12/20	有唯一索引思路，但一致性模型讲得偏浅
降级与工程细节	8/10	慢路径 + 限流降级有工程味道
表达与面试可讲性	4/10	结构散、术语错误多，容易被追问打穿

优点

边界意识好
「支付只关心第三方与支付单」「打赏关心业务单」「账户关心余额流水」——这是面试里很吃香的表述，说明做过拆分，不是堆接口。
抓住了支付域真难点
微信回调只推一次成功、MQ 可能丢、回调有时效——都点到了，再配本地消息表 + 定时扫 init 补偿，对 2 年经验来说已经超过很多只会 CRUD 的候选人。
幂等有兜底思路
biz + biz_id + account + account_type 唯一索引 + Redis 前置过滤，主路径对、兜底也对。
会主动说缺点
缺自动对账、账户与打赏非强一致靠告警人工修——面试官通常加分，显得务实。
有可落地的代码片段
GetReward 快慢路径 + limited 降级，能证明不是纯理论。

缺点（面试里容易被打穿的点）

「对账」名不副实
简历写「对账流程」，正文却写「缺少定时自动对账」。2 年经验可以不做完整对账，但简历与口述必须对齐，否则会被认定夸大。
一致性模型说不清
「优先更新打赏表，RPC 失败靠人工」——面试官会问：为何不先账后业务 / 同事务 / Outbox 统一出口？最终一致还是人工一致？超时重试与幂等如何配合？这里准备不足。
本地消息表细节偏薄
- failed 后怎么办？（死信、告警、人工重放）
- 发送成功但改 status 失败 → 重复投递，下游如何保证？
- 定时任务并发扫同一批 init 如何防重？
- content 序列化格式、版本兼容？
  这些是「本地消息表」题的标配追问。
Redis 幂等设计不严谨
「预先判断 Redis 状态」太模糊：key 是什么？TTL？先 Redis 还是先 DB？Redis 挂了怎么办？正确叙事应是：DB 唯一约束是真相，Redis 只是加速，不能单独当幂等源。
Golang / 工程深度弱
全文几乎没有：gRPC 超时与重试、context 传递、回调验签、并发安全、事务边界、错误码。2 年 Golang 岗会被追问这些。
表达与硬伤
calback、stauts、ctx.Value("limited")（类型不安全、难测）、JSON 伪结构不规范——细节会拉印象分。
退款 / 部分失败 / 重复打赏 几乎未覆盖
支付面试常问：重复回调、金额篡改校验、订单超时关单、退款与冲正。

建议（按优先级）

1. 先改简历表述（立刻做）

改为：「实现微信支付打赏；用本地消息表保证支付结果可靠投递；账户侧幂等入账」
不要写「完整对账」，除非补一版：按日对 支付成功单 vs 账户流水 vs 打赏状态 的差异报表 + 告警。

2. 准备一张 2 分钟口述主链路
发起打赏 → 建业务单/支付单 → 微信下单 → 回调验签 → 本地事务写支付状态+Outbox → 发 MQ → 账户幂等入账 → 更新打赏状态；失败靠定时补偿 + 主动查单。

3. 把三个「追问答案」写死

为何本地消息表而不是直接依赖微信重试？
重复消息如何保证只加一次钱？
打赏已成功、账户失败如何发现与修复？（最好从「人工」升级到「对账任务 + 可重放」）

4. 补齐技术细节清单（半页纸即可）

回调验签、金额与 out_trade_no 校验
Outbox 状态机：init → sending → success / failed
定时任务：分页、FOR UPDATE SKIP LOCKED 或租约，避免多实例抢同一批
幂等：先插流水（唯一索引）再改余额；冲突当成功返回
主动查单：状态机只允许 Init→Success/Failed，禁止回退

5. 代码展示再打磨

限流标记不要用 ctx.Value("limited")，改成明确参数或中间件注入的 Limiter/Degrade 标志
慢路径更新打赏状态时说明：是否只更新、是否再触发入账（避免查询接口变成写副作用）

6. 面试话术升级一句
不要只说「模块拆了」；说：「支付可复用到会员/订单，打赏是支付的一种业务形态，账户是账本，三者用 MQ 最终一致，用唯一键兜底。」

面试官结论

这份材料说明候选人做过真实支付链路，懂拆分和消息可靠性，对 2 年经验够用；但若现场只能复述文档、答不上一致性与对账追问，分数会掉到 60 左右。把「对账诚实化 + Outbox/幂等细节 + 2 分钟口述」补上，冲击 80+ 更稳。

评论 detail

Wed, 05 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 实现了一套完整的评论系统

需求分析 :

评论本身是评价一类资源，例如评价文章、视频
评论本身是可以被回复的
评论本身是可以被点赞的

更加进一步考虑,我们会发现查询评论本身也是一个高并发场景,打开任何资源都需要考虑加载评论

评论设计

回复评论的层级

因为评论也是可以被评论的，所以考虑维护一个树形结构

邻接表存储 :

我们可以使用邻接表存放树形结构，通过设计一个 partent_id 来表示自己的父节点

根节点的 partent_id 可以表示为 null 或者是 -1

缺点 :

很难找出全部的评论 , 需要找出 paretn_id 然后找出评论再找出评论
而且删除操作不太好处理
查找的时候是 join 操作

分段式 path设计 :

一个列维护了从根节点到当前节点的路径

例如 path a/b/c

如果路径包含当前节点那么当前节点就是 c 他的父节点就是 b 根节点就是 a
如果当前路径不包含当前节点,那么c就是当前节点的父节点
查找的时候是 like 操作

确定结构

我们考虑以下几个场景

加载资源的第一页评论
加载资源的第一页评论的直接评论，分批加载其他评论
查找评论的更多评论

第一个场景可以认为是根据 biz+biz_type 查询

第二第三个场景可以认为是查询某个节点的子节点

我们发现邻接表和 path 的设计都可以很好的查询出来。但是使用 path 的情况下是使用 like 查询因此最终采用邻接表

表结构设计

字段结构设计 :

引入 rootId 来优化批量查询的问题

索引设计 :

biz、biz_id 肯定要建立索引第一个场景
pid 找父节点一定要增加索引
- 这个列的 null值会非常多
rootId 加载整个评论也需要索引

所有的索引设计都是根据 where,order by, select 如果有 join 那么需要考虑 on

在没有遇到更新、查询性能瓶颈之前，不需要过于担忧维护索引的开销

struct {
id int
uid int64
biz string
bizId int64

Pid sql.NullInt64

// 所有顶级评论的 id
RootId sql.NullInt64 

Content string
Ctime int64
Utime int64
}

异步写评论

使用kafka 怎么保证容错和可用性

分kafka和分topic

删除评论的设计

删除评论: 是否需要删除其子节点

目前主流的做法就是 : 会把子评论一并删了

PG :

DELETE from comments where pid = 4 return id

mysql Select * from comments where pid = 4 Delete * from comments where pid = 4

能否使用非关系型数据库？

查询接口

热度评论业务折中 :

90%都不会超过10个评论的话，那么就没必要计算热度

offset 有并发问题，如果有新id出现，那么可能会导致重复取

缓存处理

可以考虑 , 缓存第一页

面试

怎么在数据库里面设计一个支持树形结构的表，你知道哪些方法？用过哪些？各有什么优缺点
什么是外键？你用过没有。？为什么大厂不推荐使用外键
- 会对数据库性能有很大的影响
- 外键约束是一个很强的约束
如何提高评论系统的性能？
- 各种缓存要不要缓存，长尾不缓存，
如何提高评论系统的可用性？
- 写引入kafka
- 读各种降级
- 读实例和写实例分离

打赏 detail

Tue, 04 Aug 2026 00:00:00 +0000

简历 preview

简历上 :

实现了一套完整的打赏支付流程和简单对账

需求分析 :

为了激励创作者，在文章模块支持打赏功能

主要用例如下 :

读者 : 发起支付
webook : 记录打赏，调用第三方服务进行支付
创作者 : 提现 (这里不实现，因为微信提现涉及审计相关的内容)
第三方支付 : 实际完成支付的地方

设计过程

支付过程

实际支付流程如下 :

读者点击打赏
webook 创建一个支付订单
Webook 跳转第三方支付
读者扫码支付
第三方支付回调给 webook
webook 得到支付结果，记录结果并更新系统状态

说一下这里和微信登陆的不同

	支付回调	登录重定向回调
是什么	服务端 → 服务端的结果通知	浏览器 OAuth 回跳
谁在请求你	微信支付服务器	用户浏览器
你在干什么	更新支付状态、通知业务	换身份、建用户、发登录态
有没有用户页面	通常没有	有，整条链路围着浏览器转
失败了怎么办	微信重试；你们还有主动查单兜底	用户重新扫码登录

微信登陆我们校验之后会自动重定向

而支付回调是一个异步的，仅仅发送通知

模块划分

打赏功能我们不假思索的会认为是一个模块。但是实际上可以进行额外的拆分

支付本身。和第三方支付打交道
利用支付模块实现的打赏模块

因此实现一个打赏模块，实际上要处理两个微服务 支付 和 打赏

接口分析

可以看到必传的参数有

mchid, appid, sub_mchid, sp_appid, mcc 这里都是微信那边给的对应 id

descripition, notify_url, out_trade_no, trade_type 分别是商品描述,通知地址,商户系统内部id,交易类型

微信下单接口

返回结果如下 :

我们可以使用在线的二维码生成，展示这个二维码

接口设计思路

根据接口请求和返回, 我们采用最小化原则可以定义出下列接口

type PaymentService interface {
	// Prepay 预支付，对应于微信创建订单的步骤
	Prepay(ctx context.Context, pmt domain.Payment) (string, error)
}

type Payment struct {
	Amt Amount
	// 代表业务，业务方决定怎么生成，
	// 我们这边不管。
	BizTradeNO string
	// 订单本身的描述
	Description string

	Status      PaymentStatus
	// 第三方那边返回的 ID
	TxnID string
}

问题1 BizTradeNO

BizTradeNO 理论上是业务方传递过来的，但是存在一个问题

对于在打赏的情况下，如果用户第一次点击打赏的时候，没有支付。后续要再次打赏。

业务方应该要考虑：缓存前一次的二维码，或者直接生成一个新的 BizTradeNO

如果不缓存，每一次打赏并且取消支付再次打赏，会call多次 wechat 以及插入 init 数据到数据库中

表结构设计

仅考虑保留 currency ,amt , tradeNo ,status,txnId 后续如果有其他字段可以考虑使用 extra_blob 进行维护

type Payment struct {
	Id  int64 `gorm:"primaryKey,autoIncrement" bson:"id,omitempty"`
	Amt int64

	Currency string
	// 可以抽象认为，这是一个简短的描述
	// 也就是说即便是别的支付方式，这边也可以提供一个简单的描述
	// 你可以认为这算是冗余的数据，因为从原则上来说，我们可以完全不保存的。
	// 而是要求调用者直接 BizID 和 Biz 去找业务方要
	// 管得越少，系统越稳
	Description string `gorm:"description"`

	// 后续可以考虑增加字段，来标记是用的是微信支付亦或是支付宝支付
	// Type uint8 // 微信支付或者支付宝支付
	// 也可以考虑提供一个巨大的 BLOB 字段，
	// 来存储和支付有关的其它字段
	// ExtraData

	// 业务方传过来的
	BizTradeNO string `gorm:"column:biz_trade_no;type:varchar(256);unique"`

	// 第三方支付平台的事务 ID，唯一的
	TxnID sql.NullString `gorm:"column:txn_id;type:varchar(128);unique"`

	Status uint8
	// Utime 上面要创建一个索引
	Utime int64 `gorm:"index"`
	Ctime int64
}

接收支付通知

对于微信那边会通知一个回调到 notifyURL 上。但是有一个问题

这个地址通常是线上地址。我们开发环境和测试环境怎么接受这个 http 请求

解决办法 :

考虑转发请求

考虑配置多个回调域名，特定域名就打到特定的环境上
考虑在回调路径上做一些特殊的标记，比如 /test 就打到测试环境

处理支付通知

更新数据库状态和 TxnId
同时传递消费数据到 kafka 中

func (n *NativePaymentService) updateByTxn(ctx context.Context, txn *payments.Transaction) error {
	status, ok := n.nativeCBTypeToStatus[*txn.TradeState]
	if !ok {
		// 这个地方，要告警
		return fmt.Errorf("%w, %s", errUnknownTransactionState, *txn.TradeState)
	}
	// 核心就是更新数据库状态
	err := n.repo.UpdatePayment(ctx, domain.Payment{
		BizTradeNO: *txn.OutTradeNo,
		Status:     status,
		TxnID:      *txn.TransactionId,
	})
	if err != nil {
		return err
	}

	// 发送消息，有结果了总要通知业务方
	// 这里有很多问题，核心就是部分失败问题，其次还有重复发送问题
	err1 := n.producer.ProducePaymentEvent(ctx, events.PaymentEvent{
		BizTradeNO: *txn.OutTradeNo,
		Status:     status.AsUint8(),
	})
	if err1 != nil {
		// 加监控加告警，立刻手动修复，或者自动补发
		n.l.Error("发送支付事件失败",
			logger.String("biz_trade_no", *txn.OutTradeNo),
			logger.Error(err1.Error()))
	}
	return nil
}

对账处理

和微信交互的场景主要有两个

调用 prepay 接口, 创建预支付订单。比较容易出现的情况就是 超时，如果超时没办法确认成功还是失败
处理回调的时候失败了，你同样不知道用户是支付了还是没支付

我们能够想到的办法就是让客户端重试

处理回调失败的问题

微信在回调通知我们的时候也可能会失败。当失败多次之后，微信就会放弃该条消息

所以我们需要一个兜底机制，来使用 tradeNo 定时的去请求微信，更新订单状态

定时的去获取还在 init 定任务，并且已经过期的任务。然后查询微信获取状态进行更新。

这里的定时任务交由我们是之前实现的分布式任务实现。

func (s *SyncWechatOrderJob) Run() error {
	offset := 0
	// 也可以做成参数
	const limit = 100
	// 三十分钟之前的订单我们就认为已经过期了。
	now := time.Now().Add(-time.Minute * 30)
	for {
		ctx, cancel := context.WithTimeout(context.Background(), time.Second*3)
		pmts, err := s.svc.FindExpiredPayment(ctx, offset, limit, now)
		cancel()
		if err != nil {
			// 直接中断，你也可以仔细区别不同错误
			return err
		}
		// 因为微信没有批量接口，所以我们这里也只能单个查询
		for _, pmt := range pmts {
			// 单个重新设置超时
			ctx, cancel = context.WithTimeout(context.Background(), time.Second)
			err = s.svc.SyncWechatInfo(ctx, pmt.BizTradeNO)
			if err != nil {
				// 这里你也可以中断，不过我个人倾向于处理完毕
				s.l.Error("同步微信支付信息失败",
					logger.String("trade_no", pmt.BizTradeNO),
					logger.Error(err.Error()))
			}
			cancel()
		}
		if len(pmts) < limit {
			// 没数据了
			return nil
		}
		offset = offset + len(pmts)
	}
}

打赏设计过程

需求分析 & 功能设计

用户希望能够在某篇文章的最后，有一个打赏按钮按钮

用户点击这个按钮，就会弹出微信的支付二维码，即 prepay 的过程
可以查看支付的结果和状态 getStatus

表结构设计

文章模块和文章 id

type Reward struct {
	Id      int64  `gorm:"primaryKey,autoIncrement" bson:"id,omitempty"`
	Biz     string `gorm:"index:biz_biz_id"`
	BizId   int64  `gorm:"index:biz_biz_id"`
	BizName string
	// 被打赏的人
	TargetUid int64 `gorm:"index"`

	// 直接采用 RewardStatus 的取值
	Status uint8
	// 打赏的人
	Uid    int64
	Amount int64
	Ctime  int64
	Utime  int64
}

状态更新

状态更新有两个流程

异步的消费 kafka 进行更新
获取detail的时候进行更新
- 这里在限流的时候，就不进行慢路径的查询。等待 kafaka 进行补充

func (s *WechatNativeRewardService) GetReward(ctx context.Context, rid, uid int64) (domain.Reward, error) {
	// 快路径
	r, err := s.repo.GetReward(ctx, rid)
	if err != nil {
		return domain.Reward{}, err
	}
	if r.Uid != uid {
		// 说明是非法查询
		return domain.Reward{}, errors.New("查询的打赏记录和打赏人对不上")
	}

	// 有可能，我的打赏记录，还是 Init 状态
	// 已经是完结状态
	if r.Completed() || ctx.Value("limited") == "true" {
		// 我已经知道你的支付结果了
		return r, nil
	}

	// 这个时候，考虑到支付到查询结果，我们搞一个慢路径
	// 你有可能支付了，但是我 reward 本身没有收到通知
	// 我直接查询 payment，
	// 只能解决，支付收到了，但是 reward 没收到
	// 降级状态，限流状态，熔断状态，不要走慢路径
	resp, err := s.client.GetPayment(ctx, &pmtv1.GetPaymentRequest{
		BizTradeNo: s.bizTradeNO(r.Id),
	})
	if err != nil {
		// 这边我们直接返回从数据库查询的数据
		s.l.Error("慢路径查询支付结果失败",
			logger.Int64("rid", r.Id), logger.Error(err.Error()))
		return r, nil
	}
	// 更新状态
	switch resp.Status {
	case pmtv1.PaymentStatus_PaymentStatusFailed:
		r.Status = domain.RewardStatusFailed
	case pmtv1.PaymentStatus_PaymentStatusInit:
		r.Status = domain.RewardStatusInit
	case pmtv1.PaymentStatus_PaymentStatusSuccess:
		r.Status = domain.RewardStatusPayed
	case pmtv1.PaymentStatus_PaymentStatusRefund:
		// 理论上来说不可能出现这个，直接设置为失败
		r.Status = domain.RewardStatusFailed
	}
	err = s.repo.UpdateStatus(ctx, rid, r.Status)
	if err != nil {
		s.l.Error("更新本地打赏状态失败",
			logger.Int64("rid", r.Id), logger.Error(err.Error()))
		return r, nil
	}
	return r, nil
}

对账模块设计

对于每一条付款记录，我们都维护到用户余额里面并且记录一笔流水

func (s *WechatNativeRewardService) UpdateReward(ctx context.Context,
	bizTradeNO string, status domain.RewardStatus) error {
	rid := s.toRid(bizTradeNO)
	err := s.repo.UpdateStatus(ctx, rid, status)
	if err != nil {
		return err
	}
	// 完成了支付，准备入账
	if status == domain.RewardStatusPayed {
		r, err := s.repo.GetReward(ctx, rid)
		if err != nil {
			return err
		}
		// webook 抽成
		weAmt := int64(float64(r.Amt) * 0.1)
		_, err = s.acli.Credit(ctx, &accountv1.CreditRequest{
			Biz:   "reward",
			BizId: rid,
			Items: []*accountv1.CreditItem{
				{
					AccountType: accountv1.AccountType_AccountTypeReward,
					// 虽然可能为 0，但是也要记录出来
					Amt:      weAmt,
					Currency: "CNY",
				},
				{
					Account:     r.Uid,
					Uid:         r.Uid,
					AccountType: accountv1.AccountType_AccountTypeReward,
					Amt:         r.Amt - weAmt,
					Currency:    "CNY",
				},
			},
		})
		if err != nil {
			s.l.Error("入账失败了，快来修数据啊！！！",
				logger.String("biz_trade_no", bizTradeNO),
				logger.Error(err.Error()))
			// 做好监控和告警，这里
			return err
		}
	}
	return nil
}

表结构设计


// Account 账号本体
type Account struct {
	Id int64 `gorm:"primaryKey,autoIncrement" bson:"id,omitempty"`
	// 对应的用户的 ID，如果是系统账号
	Uid int64 `gorm:"uniqueIndex:account_uid"`
	// 账号 ID，这个才是对外使用的
	Account int64 `gorm:"uniqueIndex:account_uid"`
	// 一个人可能有很多账号，你在这里可以用于区分
	Type uint8 `gorm:"uniqueIndex:account_uid"`

	// 账号本身可以有很多额外的字段
	// 例如跟会计有关的，跟税务有关的，跟洗钱有关的
	// 跟审计有关的，跟安全有关的

	// 可用余额
	// 一般来说，一种货币就一个账号，比较好处理（个人认为）
	// 有些一个账号，但是支持多种货币，那么就需要关联另外一张表。
	// 记录每一个币种的余额
	Balance  int64
	Currency string

	Ctime int64
	Utime int64
}

面试

微信的支付流程， prepay 和处理回调
怎么处理支付的回调？关键是，怎么分发/区别不同环境收到的支付回调
金额应该怎么存？
怎么防止重复支付？
如果微信支付的回调处理失败怎么办？

如何保证消息一定发出去？怎么确保一定发送了数据？如何确保消息不丢失？
怎么保证消息丢有序性？？
- 如果 topic 增加分区，怎么保证有序性？
- 如果保证消息有序性，消息积压了，怎么半？
  - 开goroutine 批量提交
如果在自己业务里面，有明显的部分失败的场景，怎么补偿
怎么保证幂等？你有什么方案？能不能撑住高并发
- 唯一索引处理
- 二话不说先插入一个数据，保证坐在一个本地事务里面，如果有冲突那么就说明做过了
- 不拢过滤器去重

不停机数据迁移 one

Mon, 03 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 支持一套通用的同构数据不停机迁移方案, 支持全量和增量校验使用 kafka 进行减轻数据库压力并且动态的根据数据库状态进行切换挂载和运行

方案描述 :

由于我在拆分了点赞、阅读、收藏相关的微服务, 考虑微服务中一个服务一个数据库进行数据隔离。从而实现了一套数据迁移方案。因为不修改原有数据存储架构，所以采用同构的方案 , 并且考虑这个服务属于关键服务，因此选用不停机迁移方案

考虑在 100w条数据的情况下,如果进行校验后立即进行修复会给数据库带来很大的负担因此使用 kafka 进行削峰的处理

另外通过额外重写 gorm 中 connPool 的exec、prepare、query Func 实现双写

并且通过重写 Commit 和 Rollback 实现双写的事务控制

困难点和改进 :

引入 kafka 进行异步的优化全量校验与修复的过程。
优化单条校验的逻辑采用批量校验的逻辑。并且考虑硬删除的业务场景，在校验原表和目标表的条件下，同步进行目标表和原表的差异校验防止硬删除产生的不一致问题
支持使用者动态切换数据迁移 原表only,读原表写目标表，读目标表写原表，目标表only 的配置
支持根据数据库状态，判断是否高负载从而判断是否要挂载校验任务。并且通过 context cancel() 实现，尽可能只有同一个全量/增量校验程序在运行

缺点 :

因为 ConnPool 返回值 sql.Result 并不暴露 Error 的设置，所以对于双写的错误并不能很好的暴露出来，只能进行打log和监控
事务控制的实现并不能保证一致性，只能做到主表最大可控，但是对于目标表如果失败了只能等待全量校验与修复

不停机迁移数据

相比较于停机迁移数据，主要的困难点在于一边迁移一边有新数据产生

并且因为我们切换原表和目标表的时候，如果运气不好会导致出现一些数据不一致。不停机数据迁移很难做到最终数据一致性

数据校验

为了防止重复写一些 dirty code, 放弃在 dao层维护两个数据库的思路

重建了一套通用的双写逻辑。由业务方提供 equal 的方法，对于某些校验不严格的业务方可以考虑

不需要 time 就可以认为 equal 以及自定义精度误差等等

流量控制和性能优化

在数据库高负载的情况下会自动挂起全量校验只有当数据库低负载的时候才会进行
尽可能多的进行异步处理和并发处理。对于全量数据与校验采用异步处理，对于目标表和原表的校验以及目标表和原表的差异校验采用异步处理的方式进行

面试题

Q: 不停机迁移的基本步骤是什么

数据初始化，完成首轮数据的同步和数据库表的建立。对于 mysql 可以使用 mysqldump 进行同步，如果是异构数据的话，可以考虑内部批量轮询的方式进行首次同步
这时候可以考虑启用全量校验进行一次数据的校验与修复
读取并写入原表同时写入目标表。同时进行全量校验与修复
写入并读取目标表同时写入原表。同时进行全量校验与修复如果业务稳定可以考虑只运行增量校验
完全使用目标表

Q : 你的数据校验方案是什么

支持全量的数据校验和增量的数据方案。通过用户是否传递 utime + sleepTime 考虑走的是全量校验还是增强校验
同步的进行原表和目标表的校验以及目标表和原表的差异检查。批量获取原表的数据并且批量的获取目标表的数据，使用业务方提供的 equal method 进行比对，如果存在不想等的在轮询完成之后批量通过 kafka 发送给下游修复。批量获取目标表的数据，并且检查是否在原表存在，如果不存在同时发送对应的 event 给下游

Q : 你的数据修复方案是什么？如何保证数据正确性？怎么解决并发问题？

使用 kafka 进行异步的通知修复。 kafka 仅仅只是做触发器，并不存放detail信息用于实际修复。
对于数据修复情况只会有3种场景，target 不存在那么需要insert，not equal 需要进行 update, base_missing 则需要删除。考虑 insert & update 的并发问题，使用 upsert 进行控制
并不能够在单词修复保证数据的正确性，数据的正确性最终交由多次校验与修复来控制

Q : 在数据迁移的每个阶段，你是怎么考虑保护着数据库的

尽可能的进行批量操作。批量的查询数据库，本地机器进行比对
使用 kafka 进行异步的校验与修复
考虑调度时机进行校验任务的运行，对于数据库高负载的情况挂载正在运行的任务

Q : 如果 kafka 瓶颈了怎么办，消息积压了怎么办？

优化消费者。尽可能改成批量消费
并行处理数据库修复流程

Q : 为什么你要使用 Kafka 直接校验之后修复数据不行吗

直接进行修复数据 , 会给数据库带来很大的负担。 Mysql 单库的读写有瓶颈，尽可能保证大量的读和写操作不同时进行

Q: 增量校验和修复、业务写数据、全量校验和修复同时进行，有什么并发问题？怎么解决？

同时进行会带来更多的数据库操作，带来负担。并且我们在事务以及双写操作上必然会有并发问题，在我们切换目标表和原表的时候最终总会有不一致的情况。
采用超时控制, 优化任务调度时间。所有的不一致问题，最终都是由反复校验反复修复解决的

Q : 怎么保证在数据迁移的时候不影响业务

调度时间的控制。在低负载的情况下进行
可以考虑在内部数据跑完几次全量校验之后只开启增量校验，每次仅校验一周之内的数据

总分：62 / 100

按「2 年经验、能讲清一个核心项目」来评：能过初筛，但扛不住深挖。

评分拆解

维度	分数	说明
项目背景与动机	12/15	微服务拆库、同构不停机，动机清楚
方案完整性	14/25	四阶段迁移有框架，关键细节和边界含糊
技术深度	10/20	提到 ConnPool 双写、Kafka 削峰，但原理讲不透
问题意识与权衡	12/15	能主动说缺点，这点加分
面试表达与结构化	8/15	有 Q&A，但表述乱、有笔误、答不到位
与 2 年经验匹配度	6/10	选题够大，但「最终靠反复校验」像在回避设计

优点

选题合适：不停机迁移 + 双写 + 校验修复，是面试官愿意追问的「有难度」项目。
有诚实的缺点：ConnPool 错误难暴露、事务只能保主表——比空谈「强一致」强很多。
有业务抽象意识：业务方提供 Equal，比硬编码字段对比更像工程实践。
有保护库的意识：批量、Kafka 削峰、高负载挂起任务，方向对。
准备了面试题清单：说明有意识在「被问什么」。

缺点（面试里会被打穿的点）

核心一致性说不清
「切换时总会不一致」「最终靠反复校验」可以当结论，但不能当唯一答案。面试官会问：双写失败怎么回滚？阶段切换的窗口期如何缩小？源表为准 / 目标表为准时，修复方向怎么定？
Kafka 用法站不住脚
「只做触发器、不带 detail」——那消费者靠什么修？再查一次库？查到的是哪一侧？积压时只说「批量消费 / 并行」，没有分区键、幂等、重试、死信、顺序。
并发问题答得空
业务写、全量校验、增量修复同时跑，只提「超时 + 调度」不够。应有：同一主键的冲突策略、upsert 的版本/utime 条件、校验批次与写路径的可见性。
双写实现太薄
重写 ConnPool / Commit / Rollback 是亮点，但文档几乎没展开：嵌套事务？只读语句？Prepare 缓存？目标库延迟？失败是「打日志继续」还是「业务失败」？
表达与严谨性差
「挂载」应为「挂起」；「增强校验」应为「增量」；步骤编号重复；句子碎、逻辑跳。面试口述时会显得准备乱。
缺可量化结果
100 万量级提了，但没有：迁移耗时、校验一轮多久、峰值 QPS、不一致率下降、切换窗口多长。2 年经验项目，数据是加分项。

建议（按优先级）

1. 把故事讲成一条线（30 秒版）
背景（拆库）→ 约束（不停机、同构）→ 四阶段 → 双写怎么做 → 校验/修复怎么兜底 → 已知局限。每阶段说清「读谁、写谁、以谁为准」。

2. 补齐 5 个必追问答案（写到能口述）

双写失败：主成功副失败怎么办？是否影响接口返回？
事务：主提交、目标失败时数据状态与补偿路径
Kafka：消息体设计、幂等键、消费失败重试、为何不直接同步修
硬删除：双向 diff 的具体算法（按主键批量 in-query）
切换：如何判断可以进下一阶段（不一致率、连续 N 轮全量通过）

3. 准备一组数字
例如：数据量、双写延迟、全量一轮时间、Kafka 吞吐、挂起阈值、最终不一致量级。

4. 把「反复校验」升级成「有界收敛」
说明：在「源为准」阶段修复方向固定；切换前要求不一致 < 阈值；切换后短窗口只开增量；为何认为会收敛而不是越修越乱。

5. 润色简历与口述

简历：一句话写清「四阶段双写 + 全量/增量校验 + Kafka 异步修复 + 负载感知调度」
去掉口语和错别字；每个 Q 控制在「结论 → 做法 → 权衡」三层

6. 区分「你做了什么」和「方案通用知识」
mysqldump 初始化、四阶段迁移是通识；面试官更想听你改 ConnPool、Equal 抽象、双向校验、挂起任务这些「你亲手做的」。

面试官结论

材料证明你做过这件事，也知道难点在一致性和库压力，作为 2 年经验的项目素材够用。但当前深度停在「知道概念 + 知道会有问题」，还不足以在中高级追问里稳住。

把一致性边界、Kafka 契约、双写失败语义、切换判定补全后，这份准备可以冲到 75–80；再加可量化结果和一次完整口述演练，才更接近「能让面试官点头」的水平。

服务注册与发现 detail

Sat, 01 Aug 2026 00:00:00 +0000

简历 preview

简历上 :

使用 xxx 进行了服务的注册与框架

服务注册与发现

在微服务架构里面，我怎么知道哪些机器上部署了我需要的服务

IP + 端口

最原始的形态就是 : IP+端口 . 不过这个不能称为服务注册与发现，因为既没有注册也没有发现

缺点 :

IP 是会变的不好维护

域名 + DNS

另外一个思路 : 使用域名 + DNS . 因为 IP 经常变动所以考虑使用域名代替

考虑解析域名的开销，所以一般在客户端这边缓存解析域名的结果

优点 :

简单好用，不需要额外的组建

缺点 :

如果客户端不缓存 DNS 结果，每次调用都会多一次调用
如果客户端缓存 DNS 结果，那么就可能无法及时更新本地可用节点列表

域名解析的问题是不能及时得到通知，那么能不能让域名服务器主动通知一下节点变化

一个域名可以有多个 IP 地址。域名可以认为是一个连锁品牌而每一个 IP 可以认为是一家分店

看来眼代码，我们 Gin 写的 HTTP 内容其实并没有牵扯到域名注册的逻辑。

而且我工作的代码，域名注册也是由运维负责的

注册中心

注册中心的原理就是：

服务端在启动的时候主动在注册中心注册一下
客户端在第一次发起调用之前，先查询注册中心，而后缓存住可用节点
注册中心在服务端节点发生变动的时候 ,主动通知 客户端

缺点 :

注册中心在大规模集群下，会成为瓶颈

注册中心自省 :

dubbo 提出来的概念，随着集群规模增长加上微服务框架复杂度上升，

导致注册中心的 数据越来越多, 更新越来越频繁

于是有了服务自省

保留注册中心, 但是注册中心里面只有最小化的数据
剩余跟服务有关的元数据，通过一个元数据服务来暴露

服务注册

问题 :

什么时候进行服务注册？

暴露端口的时候注册？
健康检查通过就注册？
所有前置计算完成之后再注册

注册什么数据？

定位信息 : IP + 端口
其他信息. 一般和微服务框架等具体功能有关系

服务端和注册中心保持心跳

服务端主动保持心跳，服务端每隔一段时间就朝着注册中心发送一个心跳
注册中心主动。注册中心主动朝着所有服务端节点发送心跳

主要讨论：

心跳间隔多长
如何判定节点连不上？一次心跳连不上还是多次心跳连不上？

服务下线

如果服务端关闭了，就需要通知注册中心，而后注册中心通知客户端

客户端就会把该节点从可用列表里面挪走

服务端优雅下线 :

问题 : 服务端 A 不能告诉注册中心自己下线了之后就立刻退出

需要先通知注册中心，下线
而后服务端不在接受新请求。（在网络中读取一般的请求，也会直接拒绝）
- 中间件类似的机制
服务端需要等待正在处理的请求结束
等服务端已经接受的请求处理完毕，服务端结束运行
还需要额外考虑定时任务，分布式事务，数据库事务

接入服务注册与发现

gprc 时候注册中心

gpc 在客户端提供 Resolver 进行对服务的解析

但是他并没有在服务端提供 register 的功能， grpc 根本不知道你使用的是不是注册中心

grpc 使用注册中心 etcd

服务注册与发现的高可用

高可用

高可用围绕三个点三条边来思考 :

服务端崩溃怎么办？
注册中心崩溃怎么办？
客户端崩溃？。不需要处理

三条边 :

注册中心和服务端之间无法通信怎么办？
注册中心和客户端之间无法通信怎么办？
客户端和服务端之间无法通信怎么办？
- failover

服务端崩溃 :

服务端崩溃 -> 注册中心发现 -> 通知客户端, 中间有时间间隔

简单来说如果服务端崩溃，那么我们就要切换一个节点来重试也就是 failover

注册中心崩溃了怎么办 :

先描述很难崩溃

启用注册中心高可用方案, 例如部署一个集群，多活方案
双注册中心方案, 注册的时候同时注册两个注册中心，在一个注册中心崩溃之后可用使用离国内外i啊一个注册中心
按照业务拆分多个注册中心

然后在解决真的崩溃的问题

如果真的崩溃了，客户端怎么办

使用本地缓存的可用节点信息

如果真的崩溃了，服务端怎么办

如果是新节点，注册失败直接退出服务，如果是老节点继续提供服务

注册中心与服务端无法通信:

继续保持服务，并且告警，并且考虑是否要退出

面试

服务注册与发现，有哪些组件
- 客户端、服务端、注册中心
- 监控平台
什么是注册中心？为什么要使用注册中心？直接使用 IP 或域名行不行？
- 一种中间件用于注册支持的服务的内容
注册的时候，注册了什么数据
- 定位信息和其他信息（分组信息，权重信息）
在使用注册中心的整个流程是什么
注册中心怎么知道服务端已经崩溃
注册中心和服务端怎么保持心跳
心跳的间隔怎么设置？有什么影响
服怎么避免偶发性心跳失败
服务端在下线的时候需要注意什么？具体的步骤是什么
客户端和注册中心需要保持心跳吗

不停机数据迁移 detail

Fri, 31 Jul 2026 00:00:00 +0000

简历 preview

简历上 : 点赞、阅读、收藏模块拆分成微服务之后进行了数据库迁移实现微服务的单独存储

为什么要做数据迁移 :

经过微服务化之后，我们的代码已经拆除去了，但是实际上还是共享一个数据库。我们认为 某个微服务的数据也是单独存储的 因此还需要做数据分离

迁移

分类 :

异构数据迁移
- 原表和目标表的结构不一样
- 如果数据库都不一样，也算异构数据迁移
问题 :
- 数据转换 : 不同数据类型可能转出不同的兼容问题，如果是数字会有精度问题
- 完整性校验 : 数据之间的业务关系很难校验
同构数据迁移

方式 :

停机迁移
- 数据迁移比较困难的就是，我们在迁移过程中会有新的数据插入，老的数据更新/删除，导致一致性问题
- 停机迁移可以很好的规避这部分内容，但是缺点就是应用停了下来
不停机迁移
- 需要考虑新老数据的更新
- 需要考虑不能对数据库造成太大的压力

不停机迁移

难点 : 数据始终是变动的

不停机迁移的方案 :

整个不停机迁移可以分成四个阶段：

• 第一阶段：业务读写源表。在这个阶段，你要完成目标表的数据初始化过程。

• 第二阶段：双写阶段，以源表为准。在这个阶段，数据会被双写到源表和目标表中，并且读是读源表，如果数据不一致，也是以源表的数据为准。

• 第三阶段：双写阶段，以目标表为准。在这个阶段，数据也是保持双写，但是读以目标表为准，并且修复数据的时候，是以目标表为准。

• 第四阶段：业务读写目标表。

数据初始化

对于同构迁移

我们可以使用 mysqldunmp 进行导出数据库数据，然后使用 source命令执行 sql 进行数据的插入

对于异构数据的话

我们只能够

批量读取原数据库的数据
转换为 SQL
在代码中利用 ORM 进行插入

校验与修复

不停机数据迁移没办法做到完全保证一致性，所以需要引入数据的校验从而尽可能大概率的保证一致性

因为在切换目标表或者是原表的过程，总会有一些时间空隙

数据校验

全量校验从方案来说, 就是 一条一条去比对

但是如果 数据量特别大，怎么尽快完成校验与修复

场景题 :

在一些大厂的核心业务，一个表可能会有数十亿条数据，如何要求在一天内完成数据同步

答案就是并发

整个全量校验和修复可以看作两个步骤 : 校验 , 如果发现不一致则修复

能够想到的做法有下面几个

立刻修复
使用 channel 通知 goroutine 去修复
使用消息队列进行异步修复

考虑需要保护住目标表,因此这里引入 kafka

校验基本思路

校验的基本思路就是

从原表获取数据
根据主键去目标着找出对应数据
比较字段是否相等
- 这里根据业务折中进行处理是否相等的过滤

校验逻辑

我们通过 offset 获取 base 中的第一条数据
然后去 target 找对应 id 的数据，如果没有找到那么通知修复，如果找到了那么比较，否则通知修复

需要额外考虑的点 :

超时控制，手动取消
数据库连接错误

剩余问题 :

我们可以批量获取一部分数据进行处理

func (v *Validator[T]) validateBaseToTarget(ctx context.Context) {
	offset := 0
	for {
		if v.highLoad.Load() {
			// 挂起
		}

		// 找到了 base 中的数据
		// 例如 .Order("id DESC")，每次插入数据，就会导致你的 offset 不准了
		// 如果我的表没有 id 这个列怎么办？
		// 找一个类似的列，比如说 ctime (创建时间）
		// todo 改成批量，性能要好很多
		src, err := v.fromBase(ctx, offset)
		switch err {
		case context.Canceled, context.DeadlineExceeded:
			// 超时或者被人取消了
			return
		case nil:
			// 你真的查到了数据
			// 要去 target 里面找对应的数据
			var dst T
			err = v.target.Where("id = ?", src.ID()).First(&dst).Error
			switch err {
			case context.Canceled, context.DeadlineExceeded:
				// 超时或者被人取消了
				return
			case nil:
				if !src.CompareTo(dst) {
					// 不相等
					// 这时候，我要干嘛？上报给 Kafka，就是告知数据不一致
					v.notify(ctx, src.ID(),
						events.InconsistentEventTypeNEQ)
				}

			case gorm.ErrRecordNotFound:
				// 这意味着，target 里面少了数据
				v.notify(ctx, src.ID(),
					events.InconsistentEventTypeTargetMissing)
			default:
				// 这里，要不要汇报，数据不一致？
				// 你有两种做法：
				// 1. 我认为，大概率数据是一致的，我记录一下日志，下一条
				v.l.Error("查询 target 数据失败", logger.Error(err.Error()))
				// 2. 我认为，出于保险起见，我应该报数据不一致，试着去修一下
				// 如果真的不一致了，没事，修它
				// 如果假的不一致（也就是数据一致），也没事，就是多余修了一次
				// 不好用哪个 InconsistentType
			}

		case gorm.ErrRecordNotFound:
			// 比完了。没数据了，全量校验结束了
			// 同时支持全量校验和增量校验，你这里就不能直接返回
			// 在这里，你要考虑：有些情况下，用户希望退出，有些情况下。用户希望继续
			// 当用户希望继续的时候，你要 sleep 一下
			if v.sleepInterval <= 0 {
				return
			}
			time.Sleep(v.sleepInterval)
			continue
		default:
			// 数据库错误
			v.l.Error("校验数据，查询 base 出错",
				logger.Error(err.Error()))
			// 课堂演示方便，你可以删掉
			time.Sleep(time.Second)
			// offset 最好是挪一下
			// 这里要不要挪
		}
		offset++
	}
}

同时我们还需要反向考虑一个点，如果 target 表存在，但是base表没有怎么办

因为可能存在硬删除操作

func (v *Validator[T]) validateTargetToBase(ctx context.Context) {
	// 先找 target，再找 base，找出 base 中已经被删除的
	// 理论上来说，就是 target 里面一条条找
	offset := 0
	for {
		dbCtx, cancel := context.WithTimeout(ctx, time.Second)

		var dstTs []T
		err := v.target.WithContext(dbCtx).
			Where("utime > ?", v.utime).
			Select("id").
			Offset(offset).Limit(v.batchSize).
			Order("utime").Find(&dstTs).Error
		cancel()
		if len(dstTs) == 0 {
			// 没数据了。直接返回
			if v.sleepInterval <= 0 {
				return
			}
			time.Sleep(v.sleepInterval)
			continue
		}
		switch err {
		case context.Canceled, context.DeadlineExceeded:
			// 超时或者被人取消了
			return
		// 正常来说，gorm 在 Find 方法接收的是切片的时候，不会返回 gorm.ErrRecordNotFound
		case gorm.ErrRecordNotFound:
			// 没数据了。直接返回
			if v.sleepInterval <= 0 {
				return
			}
			time.Sleep(v.sleepInterval)
			continue
		case nil:
			ids := slice.Map(dstTs, func(idx int, t T) int64 {
				return t.ID()
			})
			// 可以直接用 NOT IN
			var srcTs []T
			err = v.base.Where("id IN ?", ids).Find(&srcTs).Error
			switch err {
			case context.Canceled, context.DeadlineExceeded:
				// 超时或者被人取消了
				return
			case gorm.ErrRecordNotFound:
				v.notifyBaseMissing(ctx, ids)
			case nil:
				srcIds := slice.Map(srcTs, func(idx int, t T) int64 {
					return t.ID()
				})
				// 计算差集
				// 也就是，src 里面的咩有的
				diff := slice.DiffSet(ids, srcIds)
				v.notifyBaseMissing(ctx, diff)
			default:
				// 记录日志
			}
		default:
			// 记录日志，continue 掉
			v.l.Error("查询target 失败", logger.Error(err.Error()))
		}
		offset += len(dstTs)
		if len(dstTs) < v.batchSize {
			if v.sleepInterval <= 0 {
				return
			}
			time.Sleep(v.sleepInterval)
		}
	}
}

异构数据的校验:

对于异构数据，我们没办法使用 id 进行查找，所以只能考虑其他唯一键去寻找相同数据

数据修复

数据修复的基本逻辑

target_missiong : 那么就是 insert。获取原表数据进行插入

neq : 那么就是更新，使用原表数据来覆盖

base_missiong : 代表目标表多了数据应该删除目标表数据

并发问题 :

Q : base找到了数据，但是更新的时候 base 删除了数据。 target 的更改会失败

A : 重新开启一轮修复

func (o *OverrideFixer[T]) Fix(ctx context.Context, id int64) error {
	var src T
	// 找出数据
	err := o.base.WithContext(ctx).Where("id = ?", id).
		First(&src).Error
	switch err {
	// 找到了数据
	case nil:
		return o.target.Clauses(&clause.OnConflict{
			// 我们需要 Entity 告诉我们，修复哪些数据
			DoUpdates: clause.AssignmentColumns(o.columns),
		}).Create(&src).Error
	case gorm.ErrRecordNotFound:
		return o.target.WithContext(ctx).
			Where("id = ?", id).Delete(new(T)).Error
	default:
		return err
	}
}

双写

我们经历了全量的校验与修复之后就可以考虑进行双写了

由于是两个数据库开启不了数据库本地事务

分布式事务 : 性能很差

需要考虑双写 + 流量切换。即考虑读写哪个数据源

方案 1

引入原子类进行并发控制, 监听配置变更进行切换数据源

dao层面，双写两张表，如果源表失败则退出，如果目标表失败等待校验与修复

问题是

增删改都需要写一份代码

方案 2 ConnPool

Prepare : 预编译语句

Select 都用于 Query

增删改用于 Exec

Query返回的结构体，error并没有暴露出来，所以处理 error 的话，只能 panic

额外在增加一个双写的 DAO

然后根据 pattern 进行控制

type DoubleWriteDAO struct {
	src     InteractiveDAO
	dst     InteractiveDAO
	pattern *atomicx.Value[string]
}

func NewDoubleWriteDAOV1(src *gorm.DB, dst *gorm.DB) *DoubleWriteDAO {
	return &DoubleWriteDAO{src: NewGORMInteractiveDAO(src),
		pattern: atomicx.NewValueOf(patternSrcOnly),
		dst:     NewGORMInteractiveDAO(dst)}
}

通过实现以下几个接口进行实现双写的操作


// ConnPool db conns pool interface
type ConnPool interface {
	PrepareContext(ctx context.Context, query string) (*sql.Stmt, error)
	ExecContext(ctx context.Context, query string, args ...interface{}) (sql.Result, error)
	QueryContext(ctx context.Context, query string, args ...interface{}) (*sql.Rows, error)
	QueryRowContext(ctx context.Context, query string, args ...interface{}) *sql.Row
}

type TxBeginner interface {
	BeginTx(ctx context.Context, opts *sql.TxOptions) (*sql.Tx, error)
}

// ConnPoolBeginner conn pool beginner
type ConnPoolBeginner interface {
	BeginTx(ctx context.Context, opts *sql.TxOptions) (ConnPool, error)
}

// TxCommitter tx committer
type TxCommitter interface {
	Commit() error
	Rollback() error
}

面试要点

不停机迁移的基本步骤
你的数据校验方案是什么
你的数据修复方案是什么？如何保证数据正确性？怎么解决并发问题？
- 不使用 MQ 来进行数据的更新只当作触发器
在数据迁移的每个阶段，你是怎么考虑保护着数据库的
- 调度时机考虑
- 查询改成批量，修复改成批量。
  - 修复的批量该成 kafka 批量消费
如果 kafka 瓶颈了怎么办，消息积压了怎么办？

为什么你要使用 Kafka 直接校验之后修复数据不行吗
增量校验和修复、业务写数据、全量校验和修复同时进行，有什么并发问题？怎么解决？
在主从同步下，校验和修复有什么注意事项
怎么保证在数据迁移的时候不影响业务
你使用了哪些优化手段来加速迁移数据的过程

微服务 detail

Fri, 31 Jul 2026 00:00:00 +0000

简历 preview

简历上 : 将单体业务中的点赞服务拆出一个微服务并且使用 grpc 进行通行管理

微服务

微服务架构 : 将功能分解到各个离散的服务中实现对解决方案的解耦。

每个服务可独立进行 开发，管理和迭代

为什么要使用微服务

为了 分而治之 :

降低复杂度
易于开发、测试、部署和扩容

模块化对比微服务

整合全部模块于一个单体应用，这个过程比较复杂
从运维角度看，实例才是基本单位，微服务化的管理力度更细。
微服务独立性更强

这里说一下我的理解 :

我前司大概有 6-8个业务组。按照 模块化单体+进程角色部署 进行开发

不过单独拆出了两个业务，一个 qass 跨环境的行情中心和配置中心 , 一个 apitest 用于进行维护项目的api稳定

为什么我们不全部拆成微服务

一次下单会串着账户、仓位、ledger、风控。这一套流程强事务、强一致
如果拆成微服务需要考虑事务和最终一致

那么拆微服务能给企业带来什么收益 :

发版时间

我们知道单体的发版需要依赖整体发版，例如如果我账户模块改动，想要提前发版，这不可能。只能发在上一个版本然后发一次全局的重构

但是如果拆成微服务，我们可以每个服务自己控制发版时间

官方话就是，需要考虑团队边界、发布节奏、技术异构

成本

我们现在单体是 文字+用户+登陆+点赞 , 但是如果我们点赞的性能跟不上, 在单体阶段我们只能考虑增加全部机器的性能

如果我们部署一台 文字+用户+登陆+点赞 的服务需要 1w ，那么如果我们想要单独增加点赞的性能需要重新部署一台完整的服务也需要 1w

但是如果我们把点赞拆出来，单独部署一个点赞服务只需要 2k, 那么 1w 可以部署 5 台

RPC

PRC : 远程过程调用，允许程序在本地计算机上调用远程计算机上的字程序，而无需程序员额外变成

RPC 协议可以简历在很多协议基础之上

基于 TCP 的 RPC 协议，典型的国内大厂自研的协议，比如说 Dubbo 协议。
基于 HTTP 的 RPC 协议，比如说 gRPC 协议。而 HTTP 本身又是可以基于 TCP 协议或者 UDP 协议的。

为什么要引入 rpc

我们可以看一些接口的文档，他们暴露了一些接口可以让我们使用，我们带上对应的 apikey + apisecret 即可

但是为什么我们还需要使用 rpc

	口语里的 HTTP（REST）	口语里的 RPC（如 gRPC）
你怎么写代码	拼 URL、method、body	`client.Like(ctx, req)`
契约	OpenAPI / 约定 JSON 字段	`.proto` / 接口定义，强类型生成
载荷	多为 JSON 文本	多为 Protobuf 二进制
传输	HTTP/1.1 或 HTTP/2	常见 HTTP/2（多路复用）
风格	资源导向（`/users/1`）	方法导向（`UserService.GetUser`）
调试	浏览器、curl 极友好	要 grpcurl 等工具，稍麻烦
流式	有限（SSE/WebSocket 另说）	双向流较自然

对开发者的体感：RPC 更像「远程函数调用」；HTTP/REST 更像「发一次 Web 请求」。

GRPC

特点 :

高性能 : 基于 QUIC 协议，利用 HTTP2 的双向流特性
跨语言 :
开源 :

Grpc 使用 protobuf 来作为自己的 IDL 语言

IDL : 接口描述语言

protobuf 基本原理 :

使用二进制格式进行序列话和反序列化
定义一种标准的消息格式。用于表示结构化数据
每个字段都有唯一的标签和类型

GRPC 服务端与客户端

服务端 :

通过 Server Listen 启动服务
通过 Register 注册对应的服务

func TestServer(t *testing.T) {
	s := grpc.NewServer()
	// 这个是生成的代码
	RegisterUserServiceServer(s, &Server{})
	l, err := net.Listen("tcp", ":8090")
	assert.NoError(t, err)
	// 启动
	if err = s.Serve(l); err != nil {
		// 启动失败，或者退出了服务器
		t.Log("退出 gRPC 服务", err)
	}
}

客户端 :

通过 Dial 来进行通信连接
使用 NewClient 创建客户端
过程调用直接调用 GetById

func TestClient(t *testing.T) {
	conn, err := grpc.Dial(":8090",grpc.WithTransportCredentials(insecure.NewCredentials()))

	assert.NoError(t, err)
	client := NewUserServiceClient(conn)
	ctx, cancel := context.WithTimeout(context.Background(), time.Second)
	defer cancel()
	resp, err := client.GetById(ctx, &GetByIdReq{
		Id: 123,
	})
	assert.NoError(t, err)
	t.Log(resp.User)
}

DDD 基本理论

• 限界上下文（Bounded Context）

描述我们所要解决的问题上下文
描述微服务的边界

• 实体（Entity）

标记业务的唯一 ID

• 值对象（Value Object）

一堆属性的集合

• 聚合体（Aggregate）

一个实体 + N个值对象的集合

• 工厂（Factory)

普通工厂方法在 DDD 中的应用

• 仓库（Repository）

数据存储的抽象

• 事件（Domain Event)

就是我们说的 MQ event

• 服务（Domain Service）

微服务拆分

按照 DDD 的理论拆分微服务，一个领域就是一个微服务

微服务拆分路线 :

单体应用 :

完善单元测试。
先抽取公共部分，如utils、helper 等。
引入聚合层解除模块间循环依赖。
按照业务对象划分模块，分到不同的包里。

模块化 :

创建不同的代码仓库，将公共部分、业务模块逐个挪到别的代码仓库。
开始准备微服务环境和服务框架选型。
搭建好 CI 和集成测试环境。

模块依赖化 :

业务模块逐个服务化，解决微服务开发、测试、部署中所遇到的问题。
搭建自动部署和回滚平台。
调研服务治理和网关。
引入消息队列。
引入分布式事务解决方案。
引入分布式任务调度。
搭建可观测性平台：logging、tracing、metrics，以及对应的告警系统

微服务化：

引入服务治理
引入网关
引入回归测试
按照业务分库

拆分

拆分方案 :

选定模块
- 原则 : 先易后难
检测覆盖率
代码拆分
确定技术选型
改造微服务
在原先的应用中同时使用本地调用和微服务调用。使用开关控制流量 并且允许回滚
逐步调整流量
抹除原先的本地调用

流量控制

我们将原先的本地服务使用装饰器重新抽象成一个接口

这个接口支持使用 threshold 控制流量，通过随机数控制。

func (g *GreyScaleInteractiveServiceClient) GetByIds(
	ctx context.Context, in *intrv1.GetByIdsRequest, opts ...grpc.CallOption,
) (*intrv1.GetByIdsResponse, error) {
	return g.client().GetByIds(ctx, in, opts...)
}

func (g *GreyScaleInteractiveServiceClient) UpdateThreshold(newThreshold int32) {
	g.threshold.Store(newThreshold)
}

func (g *GreyScaleInteractiveServiceClient) client() intrv1.InteractiveServiceClient {
	threshold := g.threshold.Load()
	// [0-100) 的随机数
	num := rand.Int31n(100)
	// 举例来说，如果要是 threshold 是 100，
	// 可以预见的是，所有的 num 都会进去，返回 remote
	if num < threshold {
		return g.remote
	}
	// 假如说我的 threshold 是 0，那么就会永远用本地的
	return g.local
}

面试

什么是微服务架构？为什么要使用微服务架构。？
模块化后为什么要微服务化？
Restful 和微服务架构是什么关系？
可以用 HTTP 协议来说实现微服务架构吗？
什么是 RPC ？ RPC 和 HTTP 是什么关系
什么是 DDD ？

微服务拆分，怎么拆，拆分的具体步骤
微服务拆分有哪些难点
怎么保证微服务拆分没有引入 bug
怎么在线上做灰度发布？
- 阈值+随机数

[深信服] 面经每日一看

Thu, 30 Jul 2026 00:00:00 +0000

本篇面经来自 : https://www.nowcoder.com/feed/main/detail/e28ee3b477754207a97a79516d7e7101?sourceSSR=search

牛客上面最新的 golang 社招没有了，不确定是不是没有岗位面试还是工作了之后大家都不爱写面经导致的

随便找一个实习或者是校招的看看

开场基础

自我介绍 ( 我是xxx, 毕业 xxx, 曾经工作于 xxx 负责 xxx, 拥有 xxx 经验 )
当初为什么会选择做这两个核心项目？ (我这边预计一个是公司项目，一个手写的项目，一个AI项目)
- 对于 AI 项目，AI发展是趋势，而且在公司的时候参加过黑客松，之前开过一个头，后面有空了之后就打算把他完善一下
- 由于在之前的公司少了一部分微服务,高并发相关的业务需求,所以单独写一个项目用于完善该部分的经验

项目1

项目中用到了分片上传、断点续传，具体如何保证最终上传的文件是完整正确的？
如何保证所有分片拼接后绝对正确，不只是简单判断无缺片？

这两个不会，预计后续补充该部分知识点。不过可以根据题目思路发散一些

保证文件完整正确, 先保证分片存在
如果分片存在 , 可以考虑根据后端存放的 metaData即后端存放每次分片发送过来的数据。然后每个分片单独比较该分片的数据。

AI 编程能力认知

日常 Go 开发中，是依赖 AI 编程更多，还是自己手写代码更多？

基本上使用 AI, AI 占比率 99% 。工作的时候主要使用 codex 和 cursor 这种具有高安全性并且性能够用的 Agent. 有时候会考虑使用 GLM 进行跑涉及多模块的需求。

平时使用 AI 编程，用过哪些实用的 Skill/能力？

写了一个 skills用于排查对账问题,我们服务客户60%的时间都是要解决客户的对账问题，排查是否缺少数据，是否有数据没有参与对账。通过写了一个 skill 把之前人为排查的顺序告诉 AI 让他来进行排查。最终效率提升了 50%
将内部接口暴露出来供外部使用，组内封装过过个MCP接口, 通过使用各个环境的 Apikey 进行访问每个环境的数据。

你用过的这些 AI 编程 Skill，存在哪些不好用、有局限的地方

局限的地方 : 对于较为明显的问题，实际上人一眼就能看出来,但是跑AI的话预计要等5-10分钟。不好用: 因为部分接口还没有封装暴露成为MCP,导致现有 skills需要的数据需要人手动传入

项目1

项目使用 Kafka 做任务调度，重试机制、失败恢复的具体实现方案是什么

这两个也没有接触过,不过可以根据感觉来回答

在点赞服务，使用 kafka 进行异步统计。如果在任务调度中失败了,我们会尝试 3次重试，如果重试也失败之后,会把该数据放到死信队列中, 死信队列的数据单独启动一个定时任务来进行处理这部分数据。如果多次失败，会有对应的告警和日志，并且可以在监控中观测到，这时候就需要人为到定位，是不是第三方服务不稳定或者是传入了错误的请求导致的。
当然我们也可以考虑业务折中的方案，我们对于点赞服务，只需要确保用户能够正常的维护是否点赞这个功能，而对于点赞数在业务上允许他可以不稳定更新

重试、退避策略、失败恢复，是否依赖 MySQL 状态表 + 定时扫表实现调度？具体流程是什么。如上

项目 2

详细介绍项目中的长会话上下文管理方案。
你项目中做过受限子任务编排，具体展开讲讲实现思路与作用。

这两个完全是知识盲区了

六、场景题

设计异步任务创建接口，如何保证接口幂等，避免重复创建任务？

根据业务字段进行重复性校验。例如一个异步任务需要时间范围,操作对象 . 那么就查看是否已经有 <操作对象,时间范围> 的组合存在,如果存在则不创建
使用进程级的限流, 防止前端一秒内多次点击从而频繁发送相同的请求

生产环境接口原本响应几十毫秒，突然耗时飙升至数秒：如何快速排查问题？如何紧急止损？

一般这种异常都会有对应的告警同时会有完整的tracing. 如果没有的话可以考虑通过监控图观察异常情况的发生时间,然后去对应时间点查询日志。并且根据对应接口最近改动进行比较
如果接口特别影响使用, 那么可以考虑使用本地缓存 cover一下实际请求实现降频 . 或者是回退最近改动的代码。如果在可以接受范围内的话，可以考虑定位出来之后再解决

若问题在版本更新后出现，优先从哪些方向排查根因？

最近代码的改动，大概率是
如果涉及第三方服务，可以排查第三方服务是否稳定

哪些具体代码改动，会直接导致接口耗时从几十毫秒飙升至数秒？

数据库层面, 开发环境和线上环境数据不一致，可能新增了某些大量查询或者是更新的操作，但是后端没有做限制和处理
缓存层面, 可能引入了某些大型配置文件,但是这些配置文件的 json.unmarshal没有使用缓存进行控制或者说未命中缓存导致频繁 unmarshal
网络层面, 代理或者是某些三方接口网络不稳定。导致等待http请求，并且http timeout设置的很大，导致等待了很长
硬件层面, 其他进程的占用飙升导致我们服务只能拥有少部分资源导致速度变慢

项目主要使用 MySQL 吗？有没有实际做过慢查询优化、SQL 调优相关工作？

用的 pgSQL .有过慢查询优化的经历

最主要常见的就是，业务需要支持账户+时间的查询。但是历史表结构并没有 <account + timestamp>的索引。主要优化就是在其上面创建索引
其他优化方向也大同小异。主要是根据业务方向进行调整，使用 ESR 原则进行优化

综合评分：58 / 100

按 2 年 Golang 社招标准看：方向对、有真实业务痕迹，但项目深度、技术闭环和面试表达都偏弱，目前更接近「能聊几句」而不是「能扛住追问」。

分项打分

维度	分数	简评
项目深度与闭环	45	分片上传、Kafka、AI 长会话多处空白，硬伤
场景题 / 排查能力	68	有思路，但缺具体手段和分层排查
AI 工程实践	75	Skill/MCP 有真实落地，是亮点
数据库 / SQL	70	有索引优化经历，但深度不够
表达与面试策略	55	「不会」「根据感觉答」会直接扣印象分
岗位匹配（深信服向）	60	偏业务+AI，缺系统/网络/高并发细节

优点

AI 工程有真实产出：对账 Skill、MCP 暴露内部接口、效率提升 50%，比空谈「会用 Cursor」强很多，2 年经验里这是差异化点。
知道业务折中：点赞数允许最终一致，说明有业务取舍意识，不只堆组件。
慢查优化有落点：account + timestamp 索引、提到 ESR，说明碰过真实 PG/MySQL 问题。
耗时飙升题有分层意识：库 / 缓存 / 网络 / 机器都想到了，方向基本正确。

缺点

项目答不上核心题
分片完整性、长会话、子任务编排直接写「不会 / 盲区」。面试官会默认：项目是挂上去的，不是你做的。
技术答案停在「感觉层」
- 分片：只说到 metaData 比对，没提分片 hash、整文件 MD5、ETag、合并校验。
- Kafka：重试/死信方向对，但缺幂等、offset、重试是否可重入、和「定时扫表」方案的对比。
- 幂等：业务唯一键有思路，但「进程级限流」解决不了分布式重复创建，应用层锁 / Redis SETNX / DB 唯一索引没讲。
AI 占比 99% 很危险
面试官会追：没有 AI 时你怎么 debug？怎么读 pprof？怎么自己写并发？建议改成「生成 + 审查 + 自测」比例，强调你负责设计和验收。
排查题缺「可操作清单」
耗时飙升应落到：QPS、P99、DB 慢查、连接池、GC、锁等待、下游 RT、最近发布；止损应有限流、降级、回滚、熔断，而不是只说「本地缓存 cover」。
准备姿态偏被动
多处「这两个不会，后续补充」「根据感觉来回答」——面试现场不能这样说，要说「这块我负责的是 X，完整方案是 Y，边界是 Z」。

建议（按优先级）

1. 先补项目闭环（最高优先级）

每个项目至少能讲清：背景 → 你的职责 → 关键路径 → 数据一致性 → 失败怎么处理 → 指标。

分片上传建议补齐并能口述：

上传前：文件 hash / uploadId
分片：chunkIndex + chunkHash，落盘后校验
续传：查已上传分片列表
合并：校验分片齐全 + 按序合并 + 整文件 hash
可选：秒传（文件 hash 已存在则跳过）

Kafka / 异步任务建议补齐：

至少一种可靠方案：本地消息表 / Outbox，或 Kafka + 幂等消费
重试：有限次 + 指数退避 + 死信 + 告警
明确：为什么不用「只扫 MySQL 状态表」，或两者如何配合

AI 项目（长会话 / 子任务）若写在简历上：

上下文：滑动窗口 / 摘要 / 向量检索，各自取舍
子任务：状态机或 DAG，超时、取消、部分失败怎么处理

写了却讲不清，比不写更伤。

2. 场景题改成「标准答题模板」

幂等：客户端 requestId + Redis/DB 去重表 + 业务唯一键；限流只防刷，不是幂等。
耗时飙升：监控定位时段 → 看发布/依赖 → 拆 RT（本机/DB/下游）→ 止损（回滚/限流/降级）→ 再查根因。
版本后出问题：优先 diff 发布内容、配置、SQL、缓存 key、依赖版本。

3. 调整 AI 叙事

建议口径：

AI 提效写样板和排查脚本；核心协议、一致性、并发、线上问题由我设计并验证；Skill 是把可重复排查流程固化，不是替代判断。

准备 1～2 个「没有 AI 也搞定」的案例（慢 SQL、死锁、goroutine 泄漏等）。

4. 把「不会」改成「边界诚实」

可以说：「合并校验是同事做的，我负责分片落盘和续传列表；完整方案我了解是 hash 校验这条链路。」
不要说「根据感觉答」。

5. 针对深信服多补一块

这类公司常挖：网络、并发、资源占用、稳定性。建议再准备：

goroutine / channel / context 取消
连接池、超时、熔断
pprof 怎么用
一次真实线上/准线上问题的复盘（现象→排查→根因→防再发）

结论

评价	说明
当前水平	业务感 + AI 落地尚可，系统与项目深度不够
面试风险	项目关键题答空时，很容易被判定「包装项目」
提分空间	把 3 个项目各自补成 10 分钟可讲、5 分钟可追问的闭环，分数有望到 75+

如果你愿意，我可以按这份面经，直接帮你改一版「可上场口述」的标准答案（分片上传 + Kafka 重试 + 幂等 + 耗时排查）。

大文件上传

Thu, 30 Jul 2026 00:00:00 +0000

需求分析

对于一个大文件 >= 50mb 的上传, 走单个文件上传的接口很容易超时

单个请求时长过长，容易出发网关/前端axios 超时
中间失败就要整个文件重传
也可能遇见中间件请求大小限制

业务流程

前端拆分文件
通过 /post-init . 初始化本次文件的基本信息

{
file_name  // 文件名
file_size // 文件大小
totalChunks // 总分片数
// .. 
}

/post-init 为每个分片创建临时目录, 然后将本次的 uploadItem 存放到进程级 map中并且返回upload-id
前端分片带上 upload-id 和 chunk_index 以及本次的数据到 post-chunk 接口
所有数据上传完之后前端调用 post-merge接口进行数据到合并，通过 upload-id 遍历每一个分区

一些问题

数据上传信息记录由进程级 map 进行记录，重启之后会丢失 , 并且不支持跨实例续传
- 业务上是允许的，因为客户环境只有每次升级才会进行重启，升级前后的上传操作从业务上看确实需要客户重新操作一次
- 项目是分环境分数据库部署的，没有多实例要求

优化点

业务没有断点续传。如果失败的话需要整体重传
- 如果上传失败了，我们需要重新传整改文件
- 旧的文件也不会主动清理掉，磁盘上会一直留着，直到运维来清理他
并不能保证拼接后绝对正确。

单机热榜

Thu, 30 Jul 2026 00:00:00 +0000

高频面试题：如果要你找出按照点赞数量前 N 个数据，怎么做？

设计一个高性能方案, 要求 :

综合考虑可以怎么利用缓存，包括 Redis 和本地缓存。要想清楚，你这个缓存方案拿出去面试究竟有没有竞争力，有没有让面试官眼前一亮的点

允许业务折中，但是你要说清楚你准备怎么折中

ZSet 存储

我们在用户请求点赞 URL 之后, 使用 ZSET 进行维护一个点赞集合。使用 lua 脚本控制 check-dothing 的并发问题

如果请求的 key 不存在, 则查找数据库将已有的 value 写入到 zset 中

local zsetName = KEYS[1]  -- 有序集合的名称
local memberToIncrement = ARGV[1]   -- 要增加分数的元素
-- 获取指定元素的当前分数
local currentScore = redis.call("ZSCORE", zsetName, memberToIncrement)

if currentScore then
    -- 将分数加1
    local newScore = currentScore + 1
    -- 更新有序集合中指定元素的分数
    redis.call("ZADD", zsetName, newScore, memberToIncrement)
    return newScore
else
    -- 指定元素不存在
    return 0
end

如果不存在那么需要把 value 写入到 zset 中

先判断 set-key 是否存在
如果存在判断 key 是否有统计，如果有则 +1 否则设置 value

local zsetName = KEYS[1]                     -- 有序集合的名称
local memberToIncrement = ARGV[1]            -- 要增加分数的元素
local specifiedScore = tonumber(ARGV[2])     -- 指定的分数，如果未指定则默认为1

-- 检查有序集合是否存在，如果不存在则创建并设置指定元素的分数
local exists = redis.call("EXISTS", zsetName)
if exists == 0 then
    redis.call("ZADD", zsetName, specifiedScore, memberToIncrement)
    return specifiedScore
end

-- 获取指定元素的当前分数
local currentScore = redis.call("ZSCORE", zsetName, memberToIncrement)

if currentScore then
    -- 如果元素存在，将分数加1
    local newScore = currentScore + 1
    redis.call("ZADD", zsetName, newScore, memberToIncrement)
    return newScore
else
    -- 如果元素不存在，将分数设置为指定的分数
    redis.call("ZADD", zsetName, specifiedScore, memberToIncrement)
    return specifiedScore
end

读取

通过使用 ZRevRangeWithScores 来获取前 100 的数据进行获取 topN 的数据

func (r *RedisInteractiveCache) LikeTop(ctx context.Context, biz string,) ([]domain.Interactive, error) {
	var start int64 = 0
	var end int64 = 99
	key := r.rankingKey(biz)
	res, err := r.client.ZRevRangeWithScores(ctx, key, start, end).Result()
	if err != nil {
		return nil, err
	}
	interactives := make([]domain.Interactive, 0, 100)
	for i := 0; i < len(res); i++ {
		id, _ := strconv.ParseInt(res[i].Member.(string), 10, 64)
		interactives = append(interactives, domain.Interactive{
			Biz:     biz,
			BizId:   id,
			LikeCnt: int64(res[i].Score),
		})
	}
	return interactives, nil
}

优化 :

我们业务上只需要 top100 可以考虑只维护前1000的数据。使用 ZREMRANGEBYRANK 删除 > 1000的内容
最坏情况下，无非就是冷门文章爆火，需要查一次数据库。但是爆火的冷门文章并发并不是很高

问题

前 100 名是一个高频数据
如果有一亿个数据怎么维护？

我们假设 100b 一条数据， 100w 条就是 100mb , 1000w 条就是 1gb . 1亿条就是 10gb 这很夸张了

前 100 名的维护

可以结合一个本地缓存，使用定时任务更新本地缓存。例如每 5s 调用一次 topN 函数，放进本地缓存中

本地缓存的实现

type cacheImpl[T any] struct {
	result         sync.Map // [string]cacheResult[T]
	successTimeout time.Duration
	failTimeout    time.Duration
	lock           sync.Mutex
	lockMap        map[string]*sync.Mutex
}

一亿个数据

分 key 写入 . 我们在写入数据的时候按照每 100个元素一个。set 进行分 key 处理
业务折中。并不是真的维护一亿，而是维护近期的点赞数据例如 3天内的。
- 这里可以考虑算法过期例如 likecnt / (age + 2) ^ gravity
- 或者是考虑整个 key 过期

func (r *RedisInteractiveCache) IncrRankingIfPresentV1(ctx context.Context, biz string, bizId int64, error {
	h := fnv.New32a()
	_, _ = h.Write([]byte(bizId))
	key := fmt.Sprintf("top_100_%d_%s", h.Sum32()%100, biz)
	res, err := r.client.Eval(ctx, luaRankingIncr, []string{key}, bizId).Result()
	if err != nil {
		return err
	}
	if res.(int64) == 0 {
		return RankingUpdateErr
	}
	return nil
}

分key 版本的读取

每次从同一个业务中的 100 个分key 中获取前100的数据，然后再合并出前100的数据

func (r *RedisInteractiveCache) LikeTopV1(ctx context.Context, biz string,) ([]domain.Interactive, error) {
	// 我从 100 个 key 里面，各取前 100
	// 然后，合并再取前 100
	interactives := make([]domain.Interactive, 0, 100*100)
	for i := 0; i < 100; i++ {
		var start int64 = 0
		var end int64 = 99
		key := fmt.Sprintf("top_100_%d_%s", i, biz)
		res, err := r.client.ZRevRangeWithScores(ctx, key, start, end).Result()
		if err != nil {
			return nil, err
		}
		for j := 0; j < len(res); j++ {
			id, _ := strconv.ParseInt(res[j].Member.(string), 10, 64)
			interactives = append(interactives, domain.Interactive{
				Biz:     biz,
				BizId:   id,
				LikeCnt: int64(res[j].Score),
			})
		}
	}
	// 进一步排序，然后取前 100
	return interactives, nil
}

其他

借助定时计算，每次计算1000名，使用 Zset 来维护 1000 名的分数

总结

Q : 你是如何设计一个高性能的排行榜服务

我们使用 Zset 进行维护, 每次用户点赞的时候会去操作一次 Zset 如果 Zset 不存在会获取数据库中的数据进行补充。

对外提供一个 TopN 的函数用于获取 topN 的数据。

使用本地缓存 + 使用定时任务每5s 维护 Zset TopN 的任务。
对于大数据结构，我们采用了分 key 的方案 , 并且考虑业务折中的方案我们只维护最近3天的数据。对于超过 3 天的数据，我们会进行整 key 过期。如果有业务需求，可以考虑使用算法过期
对于数据的读取，每次获取同一个业务中 100 个key内的前100的数据，合并后再去前 100 的数据
由于我们业务只需要前 100 的数据。所以我们对于每一个 topN 维护一个 1000 数量的 Zset 。通过使用。ZREMRANGEBYRANK 进行裁剪优化

总分：62 / 100（按「2 年 Go 后端」面试深度）

能讲清 ZSet + 本地缓存 + 业务折中，达到中级入门；但并发正确性、分片收益、读路径细节经不起追问，离「眼前一亮」还有距离。

分项（供对照）

维度	分	说明
问题建模	14/20	点到高频读、亿级内存，缺一致性与降级
方案设计	16/25	ZSet / 本地缓存 / 分片方向对，收益与边界说不清
正确性与并发	10/20	Lua / 冷启动 / 裁剪与回写有明显漏洞
缓存竞争力	12/20	有本地缓存+定时刷新，缺亮点与可落地细节
表达与代码	10/15	结构尚可，代码未完成、笔误多

优点

选型合理：点赞排行用 Redis ZSet + ZRevRangeWithScores，是面试官期望的标准答案。
有业务折中意识：只维护 Top1000、近 3 天、时间衰减公式，比死磕「全量精确」更像有线上经验。
意识到读热点：Top100 用本地缓存 + 定时刷新，方向正确。
有规模感：用「100B × 条数 ≈ 内存」估算，说明想过容量，而不是只背 API。
分片合并思路：每分片取 TopK 再归并，全局 Top100 在理论上是成立的（全局 Top100 一定落在各分片 Top100 里）。

缺点（面试深挖会挂的点）

1. 写路径 / Lua 正确性不足

第一段脚本：member 不存在就 return 0，和「key 不存在回源 DB」混在一起，边界说不清。
EXISTS + 回源 + ZADD 有典型竞态：多请求同时发现 key 不存在，会重复回源、互相覆盖。
直接 ZINCRBY 通常更简单；自己做 ZSCORE + ZADD 却没讲清为何不用原子自增。
冷门突爆「并发不高」不能当结论，面试官会问：缓存击穿 / 单飞 / 互斥回源怎么做？

2. 分 Key 没有真正解决「10GB」问题

分 100 个 key 只是摊内存到多实例/多槽，总量仍约 10GB，除非配合「每分片只留 Top1000 + 时间窗」。
文档里「分 key」和「裁剪 1000 / 只保 3 天」缠在一起，容易被问成：分片到底解决什么？裁剪丢了的 member 再点赞怎么回写？

3. 读路径代码与叙述不一致

1
2

// ... 注释写合并再取前 100
return interactives, nil  // 实际未排序、未截断

100 次串行 ZRevRange，没提 Pipeline / 并发，高 QPS 下这是减分项。
h.Write([]byte(bizId))：bizId 是 int64，这样写编译都过不了，暴露准备粗糙。

4. 「眼前一亮」的缓存方案偏薄

本地缓存只给了结构体字段，没有：过期策略、失败降级、单飞、多实例一致性、Redis 挂了怎么办。
5s 定时刷新可以，但要主动说清楚：最多 5s 脏读、是否可接受、写后是否主动失效。

5. 总结段有自相矛盾

一边「只维护近 3 天」，一边「每个 topN 维护 1000 的 ZSet 裁剪」——没串成一条清晰主路径（写什么、裁什么、读什么、何时过期）。

建议（按面试表述优先级改）

先定一条主链路（30 秒版本）

点赞写：ZINCRBY（或 Lua 原子自增）→ 可选裁剪到 TopK → 读：本地缓存 Top100（定时/主动刷新）→ Redis 兜底 → 业务只保证近 N 天、允许秒级延迟。

补齐会被追问的 5 个点

冷启动：key 不存在时 singleflight / 分布式锁回源，防止击穿。
与点赞主链路一致性：双写失败怎么补偿（异步对账 / 消息队列重放）。
分片收益：说清是「内存分散 + 裁剪」还是「近似排行」；读用 Pipeline。
本地缓存：成功/失败 TTL、刷新抖动、降级返回旧数据。
降级：排行挂了不影响点赞主流程（熔断、开关、返回空或历史快照）。

代码准备

把 LikeTopV1 补完：归并堆 / sort + 截断 Top100。
分片 key 用 strconv.FormatInt；Lua 收敛成一种语义讲透。
修标题笔误 signle → single，避免细节减分。

想加分的「亮点」（选 1～2 个讲深）

读写分离：写只碰分片 ZSet，读只碰「聚合后的 Top100 专用 key」（定时任务算好写入），线上读路径 O(1)。
或：消息异步更新排行，点赞接口不直连大 ZSet，用最终一致性换写吞吐。

面试官一句话结论

作为 2 年经验的准备稿：骨架有了（约及格偏上），深度和正确性不够。把「并发回源、分片真实收益、读合并实现、一致性与降级」补成能闭环口述的一条故事，分数可以到 75～80；再补上「聚合 Top key / 异步更新」一类可落地亮点，才接近「眼前一亮」。

MQ kafka

Wed, 29 Jul 2026 00:00:00 +0000

消息队列

消息队列的作用是 : 实现生产者和消费者解耦

例如 :

点赞服务聚合推送，批量插入数据库

kafka 基本概念

生产者 : producer

消费者 : consumer

broker : 消息服务器。逻辑上的概念 , 实践中一个 broker 就是一个消息队列进程

topic 与分区 (parition)

消费者组与消费者

Topic 与分区

topic : 可以认为是消息队列上代表不同业务的东西。简单的认为一个业务就是一个 topic

一个 topic 可以有多个分区

Kafka 为了保证 高可用 和 数据不丢失 分区有主分区和从分区

当发送消息到 kafka 上的时候， kafka 会把消息写入主分区之后再同步到从分区

分区与 broker 的关系

主分区之间, 不会在同一个 broker 上

同一个分区的主从分区也不会在同一个 broker 上

分区与生产者的关系

正常情况下，一个 topic 都会有多个分区。所以发送者在发送消息的时候需要选择一个目标分区。

比较常见的有三种 :

轮询 : 一个分区发送一次
随机 : 随机挑选一个
hash : 根据消息中的 key 来筛选一个目标分区

分区和消息有序性

Kafka 中的消息有序性保证是以分区为单位的。也就是说 一个分区内的消息是有序的

因此如果要做到 全局有序, 那么只能有一个分区

如果要做到 业务有序, 需要保证业务的消息都丢在同一个分区里面

分区与消费者组、消费者的关系

一个消费者组可以认为是关心这个 topic 的一个也无妨

同一个消费者组里面，一个分区最多只能有一个消费者。

一个分区最多有一个消费者 :

如果一个 topic 有 N 个分区，那么同一个消费者组最多有 N 个消费者
如果消费者性能很差，那么并不能通过无限增加消费者来提高速率

消息队列相关问题

Q : 一个分区只有一个消费者，那么怎么做到两个业务消费同一条信息。例如账户更新发送了一个 MQ, 需要计算服务和聚合服务共同消费这次改动

如果两个不同的服务需要消费同一条消息，需要属于不同的消费者组，从而能够从同一个 topic 获取相同的信息进行消费

Q : 死信、消息堆积

死信 : 消费多次失败，无法被正常处理的消息，会单独丢进一个死信队列 DLQ 。目的是为了把坏消息隔离出来，避免反复重试拖垮消费者。

消息堆积 : 生产速度大于消费速度导致 topic 的消息越堆越多。

面试题

有没有用过 kafka ？用来解决什么问题

用过。对于点赞、阅读业务的时候，需要将用户点击和数据库操作进行解耦.

在用户获取文章接口的时候，会进行一次数据库自增操作，这会使得接口变慢。如果考虑使用 go 异步出来。那么每次点击都会产生一个 goroutine 不安全。并且希望能够做到自动聚合一部分相同业务的内容增量，所以考虑使用 kafka

什么是 broker , broker 和分区的关系是什么

broker 是一个逻辑上的概念，可以认为是一个 MQ 的进程。一个 broker 拥有一个主分区和多个从分区。

什么是 topic , topic 和分区的关系是什么

一个 Broker 可托管多个 Topic 的多个分区（Leader / Follower 都有）。应说：分区副本尽量打散到不同 Broker；同一分区的 Leader 与 Follower 不在同一 Broker。

Kafka 中一个分区可以有多个消费者吗

同一消费者组内，一个分区同一时刻只被一个消费者消费；不同组可并行消费同一分区。Q4 按现有答案答，追问就会挂。

消息积压了怎么办？
1. 增加 topic
2. 异步消费
3. 批量消费
怎么保证消息的顺序？怎么保证全局有序？怎么保证业务有序。？

kafka 支持分区上的有序性，一个分区是消息是有序的。

全局有序性需要保证所有消息都发送到同一个分区

业务有序性需要保证同一个业务都发送到同一个分区

可以使用 hash + biz-key 来选择一个目标分区进行发送

Sarma Kafka

Wed, 29 Jul 2026 00:00:00 +0000

Saram 入门

发送消息

func TestProducer(t *testing.T) {
	cfg := sarama.NewConfig()
	cfg.Producer.Return.Successes = true

	producer, err := sarama.NewSyncProducer(addrs, cfg)
	assert.NoError(t, err)
	p, offset, err := producer.SendMessage(&sarama.ProducerMessage{
		Topic: "test_topic",
		Value: sarama.StringEncoder("hello,这是一条消息"),
		Headers: []sarama.RecordHeader{
			{Key: []byte("header1"), Value: []byte("header1_value")},
		},
		Metadata: map[string]any{"metadata1": "metadata_value1"},
	})
	assert.NoError(t, err)
	t.Log(p, offset)
}

saram 指定分区

我们观察上面的内容，发现消息发送在来 partition : 0 上面

我们可以看到 partitioner 支持

random : 随机挑一个

RoundRobin : 轮询

Hashkey : 根据 key 的哈希值塞选一个

Manual : 根据 Message 中的 partition 来选择

异步发送

saram 支持 aysnc 和 sync 两种发送其中支持异步发送 async

初始化 producer 后，从 producer 获取 input 的 channel 并且发送一个消息。通过 select 监听 success 和 error

func TestAsyncProducer(t *testing.T) {
	cfg := sarama.NewConfig()
	cfg.Producer.Return.Successes = true
	cfg.Producer.Return.Errors = true
	producer, err := sarama.NewAsyncProducer(addrs, cfg)
	assert.NoError(t, err)
	msgCh := producer.Input()

	msgCh <- &sarama.ProducerMessage{
		Topic: "test_topic",
		Value: sarama.StringEncoder("hello,这是一条异步消息"),
		// 会在 producer 和 consumer 之间传递
		Headers: []sarama.RecordHeader{
			{Key: []byte("header1"), Value: []byte("header1_value")},
		},
		Metadata: map[string]any{"metadata1": "metadata_value1"},
	}
	// 在实践中，一般是开另外一个 goroutine 来处理结果的
	select {
	case err := <-producer.Errors():
		// 这边是出错了
		val, _ := err.Msg.Value.Encode()
		t.Log(err.Err, string(val))
	case msg := <-producer.Successes():
		// 这边是成功了
		val, _ := msg.Value.Encode()
		t.Log("成功了", string(val))
	}
}

指定 acks

生产者在发送数据的时候需要设置一个关键参数 ack

0 ; 客户端发送一次，不需要服务端的确认
1 ; 客户端发送，并且服务端写入主分区
-1 ; 客户端发送，并且需要服务端同步到所有的 ISR 上。(ISR 即所有跟上主分区的从分区)

type RequiredAcks int16
const (
	// NoResponse doesn't send any response, the TCP ACK is all you get.
	NoResponse RequiredAcks = 0
	// WaitForLocal waits for only the local commit to succeed before responding.
	WaitForLocal RequiredAcks = 1
	// WaitForAll waits for all in-sync replicas to commit before responding.
	// The minimum number of in-sync replicas is configured on the broker via
	// the `min.insync.replicas` configuration key.
	WaitForAll RequiredAcks = -1
)

ConsumerGroupHandler

业务方通过指定 consumer_group 和 topic 进行消费处理。消费 interface 需要实现 setup, cleanup,consumeclaim

func TestConsumer(t *testing.T) {
	cfg := sarama.NewConfig()
	cg, err := sarama.NewConsumerGroup(addrs,"test_group", cfg)
	assert.NoError(t, err)
//...
	ctx, cancel := context.WithTimeout(context.Background(), time.Second*30)
	defer cancel()
//...
	err = cg.Consume(ctx,[]string{"test_topic"}, &ConsumerHandler{})
	assert.NoError(t, err)
}
// ... 
type ConsumerGroupHandler interface {
	// Setup is run at the beginning of a new session, before ConsumeClaim.
	Setup(ConsumerGroupSession) error

	// Cleanup is run at the end of a session, once all ConsumeClaim goroutines have exited
	// but before the offsets are committed for the very last time.
	Cleanup(ConsumerGroupSession) error

	// ConsumeClaim must start a consumer loop of ConsumerGroupClaim's Messages().
	// Once the Messages() channel is closed, the Handler must finish its processing
	// loop and exit. Handlers should also return when ConsumerGroupSession.Context()
	// is done; Messages() alone can block while the partition consumer is retrying
	// (e.g. after a broker disconnect). See examples/consumergroup.
	ConsumeClaim(ConsumerGroupSession, ConsumerGroupClaim) error
}

异步消费批量提交

kafka 要求消费后的数据必须提交。如果不提交，在下一次重启之后会出现重复提交的情况

下面是一个异步消费的写法

func (c *ConsumerHandler) ConsumeClaim(session sarama.ConsumerGroupSession,
	claim sarama.ConsumerGroupClaim) error {
	ch := claim.Messages()
	batchSize := 10
	for {
		var eg errgroup.Group
		msgs := make([]*sarama.ConsumerMessage, 0, batchSize)
		ctx, cancel := context.WithTimeout(context.Background(), time.Second)
		done := false
		for i := 0; i < batchSize && !done; i++ {
			select {
			case <-ctx.Done():
				// 这一批次已经超时了，
				// 或者，整个 consumer 被关闭了
				// 不再尝试凑够一批了
				done = true
			case msg, ok := <-ch:
				if !ok {
					cancel()
					// channel 被关闭了
					return nil
				}
				msgs = append(msgs, msg)
				eg.Go(func() error {
					log.Println("offset", msg.Offset)
					// 标记为消费成功
					time.Sleep(time.Second * 3)
					return nil
				})
			}
		}
		err := eg.Wait()
		if err == nil {
			// 这边就要都提交了
			for _, msg := range msgs {
				session.MarkMessage(msg, "")
			}
		} else {
			// 这里可以考虑重试，也可以在具体的业务逻辑里面重试
			// 也就是 eg.Go 里面重试
		}
		cancel()
	}
}

面试题

kafka 中 producer 中的 ack 有哪些取值？分别是什么含义？你用了哪些

0, -1, 1

0 表示客户端发送之后不需要服务端验证

1 表示客户端发送之后并且同步到服务端主分区

-1 表示客户端发送之后并且同步到所有 ISR 上

Kafka 中 ISR 是什么意思？

所有跟得上主分区节奏的从分区

总分：58 / 100

按「2 年经验、Golang + Kafka」面试标准看：能证明你用过 Sarama，覆盖了发送/分区/acks/消费组的入门面，但深度、完整度和可追问的生产经验都偏弱，深挖很容易露怯。

优点

有可运行的 Sarama 代码：Sync / Async Producer、ConsumerGroupHandler，比纯背概念强，能证明动手过。
Producer 关键点抓得对：Partitioner（Random / RoundRobin / Hash / Manual）和 acks（0 / 1 / -1）是常考项。
消费侧有「批量 + 提交」意识：知道要 MarkMessage，也提到失败可重试，方向对。
结构适合当笔记骨架：从发消息 → 分区 → 异步 → acks → 消费，学习路径清晰。

缺点

面试题太薄：只有 2 道，且第二题「ISR」写成「解咒」，表述不严谨，面试官一追问就挂。
缺少语义与可靠性主线：至少一次 / 至多一次 / 精确一次、幂等 Producer、事务、重平衡、Consumer Lag、死信、重试，几乎没写。
示例代码有明显硬伤（面试官很爱抠）：
- eg.Go 里闭包捕获循环变量 msg，Go 经典坑；
- 没用 session.Context()，rebalance / 关闭时可能卡死；
- 只 MarkMessage、未说明 auto-commit / 手动 Commit 策略；
- 批次超时 1s、业务 Sleep 3s，逻辑自相矛盾。
「你用了哪些」没答完：acks 题只背取值，没结合业务说选了什么、为什么、出过什么问题。
表达与细节粗糙：Saram/Sarma、aysnc、塞选等；acks=-1 与 min.insync.replicas 的关系没讲清。

建议（按优先级）

优先级	建议
P0	把面试题扩到 15～20 道：acks+ISR、分区与顺序、消费组重平衡、offset 提交、至少一次如何做幂等、Sync vs Async 选型、Lag 排查
P0	修掉消费示例：闭包、`session.Context()`、失败不提交/重试/死信策略写清楚
P1	每道题加「项目经历」：业务场景、选型原因、踩过的坑（重复消费、消息丢失、rebalance 卡住）
P1	补齐：幂等 Producer、`enable.idempotence`、批量参数（`linger`/`batch.size`）、压缩、监控指标
P2	对照官方注释精修术语；和 `kafka_0x01` 基础篇打通，形成「原理 → Sarama → 生产落地」一条线

分项参考

维度	得分	说明
Producer 基础	70	acks / partitioner / sync·async 有，深度不够
Consumer 基础	55	知道接口，提交与生命周期不扎实
可靠性语义	35	面试高频区几乎空白
代码可追问性	45	能演示，但经不起抠细节
面试题准备	30	题量与质量都不足
表达与准确度	50	笔误和概念表述拖后腿

面试官结论：当前水平大约是「跟过教程、能写 Demo」；以 2 年经验去面中级岗，过 HR/浅技术面有希望，过深挖 Kafka 生产问题的技术面风险较大。把可靠性语义 + 修代码坑 + 项目故事补上，目标可冲到 75～80。

热榜 detail

Wed, 29 Jul 2026 00:00:00 +0000

简历 preview

简历上 :

设计了一个热榜

需求分析 :

一些问题：

什么样的才算是热点？
如何计算热点？
热点必然带来高并发，怎么保证性能
如果热点功能崩溃了，怎么降低对整个系统的影响

算法模型

Hacknews 模型 Score = (p - 1) / (T + 2)^G

模型认为 : 得票数最重要，而后热度随着时间衰减

Reddit 模型

数据计算

考虑一点 : 是否需要 实时计算

实时计算的难点

要扫描全表，找出所有帖子的点赞数和发表时间
计算每个帖子的 score 并且全局排序

难点在于 : 全表扫描 + 全局排序

异步计算

由于全表计算的困难，我们考虑使用异步定时计算

解决方案包括 :

每隔一段时间就计算一次热榜
在异步的情况下，计算的时间可以比较长，但是依旧不能太长

在这个基础上考虑

怎么设计缓存，保证有极好的查询性能
怎么保证可用性，保证在任何情况下都能拿到热榜数据

计算热榜的算法实现

从数据库中拉取一批文章（batchSize），再找到对应的点赞数，计算 score。
使用一个数据结构来维持住 score 前 100 的数据。如果该批次中有 score 比已有的前 100 的还要大，那么就从数据结构中淘汰热度最低的。
加入更高 score 的。
全部数据计算完毕之后，数据结构中维护的就是热度前 100 的
将这些数据装入 Redis 缓存

这里使用的数据结构可以使用已经封装好的优先队列也就是小根堆

放入缓存有两个关键点 :

热榜数据不需要保存在数据库中。一些公司会把这些内容保存到数据库里面用于大数据分析
在 Redis 的过期时间，要比计算间隔长，最好留有足够的重试时间。

查询接口的处理

使用 atomicx.Value 进行本地缓存

在操作的时候优先操作本地缓存，如果本地缓存找不到数据，再去查找 redis 缓存。然后回写本地缓存

可用性问题

一个降级策略，对于数据库和Redis 都崩崩溃的情况下。如果本地缓存也失败了

那么可以增加一个 ForceGet 的流程，即不管本地缓存是否已经过期我们都获取数据。

极致的缓存方案

在大多数时候，追求极致性能的缓存方案，差不多就是本地缓存 + Redis 缓存 + 数据库。

那么：

查找的时候，就要先查找本地缓存，再查找 Redis，最后查找数据库
更新的时候，就要先更新数据库，再更新本地缓存，最后更新（或者删除）Redis。核心在于一点，本地缓存的操作几乎不可能失败

高级的亮点在于：

本地缓存可以预加载。也就是在启动的时候预加载，或者在快过期的时候，提前加载
本地缓存可以用于容错。也就是如果 Redis 崩溃，这时候依旧可以使用本地缓存。例如，正常过期时间是三分钟，但是本地缓存会设置五分钟。如果数据已经超过了三分钟，那么会尝试刷新缓存，如果刷新失败，那么就继续使用这个已经“过期”的本地缓存。在部分场景下，可以考虑让本地缓存永不过期，同时异步任务刷新本地缓存。好处是可以在 Redis 或者 MySQL 崩溃的时候，依旧提供缓存服务。

当下的问题

如果我们部署了多个实例，那么多个实例会同时执行这个计算热榜的任务。

理论上来说同一时刻计算的结果应该是一样的，但是大多数都不是同一时刻，这会导致在实例1看上的和实例2看上的结果会有细微的差距

因此我们需要考虑控制任务只在一个节点上进行运行

分布式锁方案

使用分布式锁来控制 goroutine 的计算方式

因为我们知道任务的运行 timeout 时间。所以不需要开启续约
另外解锁失败的话，最多 r.Timeout 就会自动释放也不需要担心

但是上述方案会出现一个问题，这个只能控制同一时刻只有一个 goroutine 计算，但是控制不住计算了一次之后别的机器就不要计算热榜了

所以我们可以考虑

在启动的时候拿到锁，而后不管几次都不会释放锁

分布式锁的具体实现如下

定时任务每次运行，尝试拿分布式锁
如果拿到异步开启自动续约
下一次正常运行，不需要额外拿锁

func (r *RankingJob) Run() error {
  r.localLock.Lock()
  defer r.localLock.Unlock()
  if r.lock == nil {
  	// 说明你没拿到锁，你得试着拿锁
  	ctx, cancel := context.WithTimeout(context.Background(), time.Second)
  	defer cancel()
  	// 我可以设置一个比较短的过期时间
  	lock, err := r.client.Lock(ctx, r.key, r.timeout, &rlock.FixIntervalRetry{
  		Interval: time.Millisecond * 100,
  		Max:      0,
  	}, time.Second)
  	if err != nil {
  		// 这边没拿到锁，极大概率是别人持有了锁
  		return nil
  	}
  	r.lock = lock
  	// 我怎么保证我这里，一直拿着这个锁？？？
  	go func() {
  		r.localLock.Lock()
  		defer r.localLock.Unlock()
  		// 自动续约机制
  		err1 := lock.AutoRefresh(r.timeout/2, time.Second)
  		// 这里说明退出了续约机制
  		// 续约失败了怎么办？
  		if err1 != nil {
  			// 不怎么办
  			// 争取下一次，继续抢锁
  			r.l.Error("续约失败", logger.Error(err1.Error()))
  		}
  		r.lock = nil
  		// lock.Unlock(ctx)
  	}()
  }

  ctx, cancel := context.WithTimeout(context.Background(), r.timeout)
  defer cancel()
  return r.svc.TopN(ctx)
}

基于 mysql 的分布式任务调度

基本思路就是

在数据库中创建一张表，里面是等待运行的定时任务
所有的实例都试着从这个表里面抢占等待运行的任务 , 抢占到了就执行

抢占但是崩溃

如果一个实例抢占了，但是还没执行完毕，直接崩溃了怎么办？

引入 续约机制 , 实例0 要不断更新数据库的更新时间证明自己还活着

tbd

阅读、点赞、收藏 one

Wed, 29 Jul 2026 00:00:00 +0000

简历 preview

简历上 :

实现了一个通用的阅读、点赞、收藏服务。使用 Kafka 进行解耦

数据库表设计 :

通用表设计 :

id,biz,bizid,readCnt,CollectCnt,LikeCnt

为 bizid 和 biz 创建一个联合唯一索引

点赞表设计 :

id,biz,bizid,uid,status

为 bizid 和 biz和uid 创建一个联合唯一索引, 用 status进行软删除

数据库处理

对于阅读、点赞、收藏操作都会涉及到一个 check-dothing 的并发问题

即 : 当用户点赞的时候文章是否已经点赞过了，如果点赞过需要+1，否则创建，这里统一采用 do on conflict update 处理

不过需要注意的是 : update 的时候我们需要保证自增所以需要使用 gorm.Expr 来获取数据库运行的值，而不是直接 select-update

缓存处理

对于写入方，优先写入数据库，后写入redis

对于查询方，优选查redis 然后再查数据库

对于写入的过程，因为我们使用的 redis key 是一次缓存了 3个 like,read,collect 三个字段

所以我们自增的时候使用的是 HINCRBY 指令，对于 key 不存在的情况下会有歧义。所以使用 lua 控制了一下仅只有 key 存在的时候才会自增

消息队列

新增统计事件引入 kafka 给阅读、点赞服务解耦

在阅读文章服务，使用 kafka 异步发送，设置 10次每批，1s超时进行聚合发送消息

消费端同样设置 10条每批，1s超时来进行组合消费

每次消费使用一个 map 进行聚合同个biz+biz_id的内容，优化之前一次点赞就需要一次 insert 的操作

并且通过开启事务进行消费，防止 MVCC 中的刷盘操作，将原先要进行10次的刷盘降低到1次。

问题

一致性问题的处理

不处理

从业务上来说，没有必要要求阅读数、点赞数或者收藏数量一定是严格准确的，因为即便不准确，也不会对用户产生什么不好的影响。

更进一步说，只有高并发的文章才会有并发问题。而高并发的文章，阅读数、点赞数或者收藏数本身就很多，你少一点点无所谓。

亮点

大量使用了事务，来保证在同时操作两个表的时候，保持住 ACID 语义。

大量使用了 Upsert 语义 , 因为很多情况下我们都不知道数据库中是否已经存在数据

大量使用 lua 脚本来保证缓存中的数据是正确的, 但是没有彻底解决缓存一致性的问题

在查询接口中，只缓存总数数据，, 并不会缓存个人是否收藏或者点赞的数据。

总分：62 / 100

按「2 年 Go 后端」面试标准看：方向对、有工程意识，但表达粗糙、关键点浅、经不起追问。面试里能撑 15–20 分钟开场，深入一追容易露怯。

分项打分

维度	分数	说明
业务建模与表设计	14/20	通用计数表 + 点赞明细表思路正确，索引方向对
并发与数据正确性	12/20	知道 Upsert / Expr，但 check-then-act、事务边界讲不清
缓存设计	12/20	Cache-Aside + Lua 防空 key 自增有亮点，一致性论证弱
消息队列与解耦	13/20	Kafka 批量、聚合、减刷盘有工程味道
表达与面试叙事	6/10	口语化、错别字多，「大量使用」空洞，像笔记不像口述稿
亮点与深度	5/10	亮点空泛，缺少权衡、失败场景、可观测性

优点

表设计合理：biz + biz_id 抽象通用互动能力，点赞用 (biz, biz_id, uid) 唯一 + status 软删除，符合常见业务。
踩过真实坑：ON CONFLICT + gorm.Expr 自增、Redis HINCRBY 空 key 用 Lua 护栏，说明写过代码而不只是背概念。
有吞吐意识：Kafka 批量生产/消费、按 biz+biz_id 聚合、事务合并刷盘，对 2 年经验来说是加分项。
一致性取舍有业务理由：承认最终一致、高热内容允许误差，比死磕「强一致」更成熟——前提是能讲清边界。

缺点（面试官会盯的）

「不处理一致性」太绝对：面试官会问：DB 成功 Redis 失败？Kafka 重复消费？取消点赞与计数对不上？需要有策略（补偿、对账、幂等），不能只说「少一点点无所谓」。
亮点写法很伤：连续「大量使用事务/Upsert/Lua」像模板，没有场景、没有代价。事务多 ≠ 好，还可能拖慢吞吐。
技术细节易被打穿：
- 写库再写缓存：失败怎么回滚/补偿？
- Lua「仅 key 存在才 incr」：key 不存在时计数会丢吗？靠查询回源还是异步重建？
- Kafka 聚合：幂等键、乱序、部分失败重试怎么做？
- 「防止 MVCC 刷盘」表述不严谨，容易被纠正。
缺个人态查询设计：只说不缓存「是否点赞」，但列表页如何批量查个人态？N+1？位图/本地缓存？没写。
表达与文档质量差：优选/check-dothing、front matter 的 xxxx、标点混乱，会降低「能讲清楚」的印象。

建议（按面试口述改）

改成 STAR 口述结构：背景（互动服务压力）→ 方案（表 + Kafka + Redis）→ 难点（空 key、重复消费）→ 结果（QPS/延迟/错误率，哪怕是压测数字）。
准备 3 个追问标准答：
- DB/Redis 不一致：异步对账 + 定时校准热点 key
- Kafka 至少一次：消费幂等（唯一键 + Upsert）
- 取消点赞：status 翻转 + 计数 GREATEST(cnt-1,0)，防负值
删掉「大量使用」，改成「在点赞写明细+改计数时用事务；计数更新用 Upsert；缓存用 Lua 保证 key 存在才 HINCRBY」。
补一张口述链路：读请求 → Redis Hash → miss 回源 DB 回填；写请求 → DB Upsert →（可选）发 Kafka → 消费者聚合写计数 → 更新缓存。
亮点换成可量化的 2–3 条：例如「批量聚合把热点文章写放大降到约 1/N」「Lua 避免幽灵 key」「个人态与总数分离降低缓存体积」。

面试官一句话结论

材料有「做过互动域」的骨架，适合当提纲；按现在写法直接上面试，深度和表达大概卡在 及格偏上。把一致性策略、幂等、失败路径和口述结构补齐，冲到 75–80 比较现实。

channel

Mon, 27 Jul 2026 00:00:00 +0000

channel 语法

var ch chan T. 声明 channel

make(chan T) 和 make(chan T, size) 声不带容量和带容量的 channel

ch <- data 发送消息到 channel 里面

val := <- ch 从 channel 里面读取数据

close(ch) 关闭 channel

channel 的 close 问题

close 不是幂等的

当被 close 之后

继续写入数据，会 panic
从 channcel 读取的数据会读到 0 值。 val, ok := <- ch ; ok = 0
再次 close 会 panic

在实践中坚持一个原则 : 谁创建的 channel 谁来关, 可以避免很多 channel 没有正确关闭的问题

channel Loop

我们可以使用 for range 进行读取 channel 的数据

但是需要注意 close 如果不 close channel 会 panic . 因为接收方会一直接受数据，但是发送方没有数据了所以会一直阻塞

func LoopChannel() {
	ch := make(chan int)

	go func() {
		for i := 0; i < 3; i++ {
			ch <- i
			time.Sleep(time.Second)
		}
		close(ch)
	}()

	for val := range ch {
		fmt.Println(val)
	}
	fmt.Println("done")
}

channel & 阻塞

如果接受者读不到数据，就会阻塞
如果发送者写不了消息，就会阻塞

有缓冲和无缓冲的 channel

无缓冲 Channel :

容量: 大小为0，不能存储任何数据
同步性：是同步的。发送者发送数据时，必须有接收者准备好接收，否则发送方会一直阻塞；反之亦然。
作用：提供强同步保证，确保两个 goroutine 在某一时刻完成了数据交接

缓冲 Channel ：

容量：大小大于 0，可以存储指定数量的元素。
同步性：是异步的。只要缓冲区没满，发送数据就可以立刻返回而不阻塞；只要缓冲区不空，读取数据就可以立刻返回值。
作用：解耦生产者和消费者，能够平滑突发流量，提高程序的运行效率。

有缓冲的写法 :

func BufferChannel() {
	ch := make(chan int, 3)
	defer func() {
		close(ch)
	}()
	for i := 1; i <= 3; i++ {
		ch <- i
	}

	for i := 1; i <= 3; i++ {
		val := <-ch
		fmt.Println(val)
	}
}

无缓冲的写法 :

要写进行接收，然后才可以进行发送
并且必须同时处理

func NoBufferChannel() {
	ch := make(chan int)
	defer func() {
		close(ch)
	}()
	for i := 1; i <= 3; i++ {
		go func() {
			val := <-ch
			fmt.Println(val)
		}()
		
		ch <- i
	}

	//for i := 1; i <= 3; i++ {// panic
	//	val := <-ch
	//	fmt.Println(val)
	//}
}

channel 与 select

select-case 用于控制从不同的 channel 中读写数据，只运行一次

语法

select {
	case ch <- val: // 写入
	case val := <- ch2 // 读取
	default : 
}

每一个 case 都可以是读取或者是写入数据到 channel
没有 default 分支的时候, select 就会阻塞
如果有多个分支同时满足会随机执行一个
case 后面不需要break

应用

输出 0 - 100

使用 goroutine, 交替 输出 0 - 100

写法如下 :

func Print100() {
	time := time2.Now()
	even := make(chan int)
	odd := make(chan int)
	wg := sync.WaitGroup{}
	wg.Add(2)

	go func() {
		for i := 0; i <= N; i += 2 {
			<-even
			fmt.Print("p1:", i, "\n")
			if i == N {
				wg.Done()
				close(odd)
				return
			}
			odd <- i
		}
	}()

	go func() {
		for i := 1; i <= N; i += 2 {
			<-odd
			fmt.Print("p2:", i, "\n")

			if i == N-1 {
				wg.Done()
				close(even)
				return
			}
			even <- i
		}
	}()

	even <- 0
	wg.Wait()
	fmt.Println("cost:", time2.Now().Sub(time))
}

我们也可以使用一个 channel 进行

func print100() {
	time := time2.Now()
	ch := make(chan int)
	wg := sync.WaitGroup{}
	wg.Add(1)

	go func() {
		for {
			val, ok := <-ch
			if !ok {
				return
			}
			fmt.Print("p1:", val, "\n")
			if val == N {
				wg.Done()
				close(ch)
				return
			}
			val += 1
			ch <- val
		}
	}()

	go func() {
		for {
			val, ok := <-ch
			if !ok {
				return
			}
			fmt.Print("p2:", val, "\n")
			if val == N {
				wg.Done()
				close(ch)
				return
			}
			val += 1
			ch <- val
		}
	}()

	ch <- 0
	wg.Wait()
	fmt.Println("time:", time2.Now().Sub(time))
}

在 1e7 的数据下 :

2 个协程 : cost: 9.692623833s

顺序遍历 : cost : 6.417589125s

失败的写法

我这里使用使用 for 直接进行输出，但是这里没办法保证是 交替 输出

因为我们这里只是保证了能够存入 channel 而没办法 fmt.Print

func NewPrinter2() *Printer2 {
	p := &Printer2{
		ch: make(chan int),
	}
	return p
}

func (p *Printer2) Print() {
	for val := range p.ch {
		fmt.Println("p2:", val)
	}
}

func SelectChange100() {
	p1 := NewPrinter1()
	p2 := NewPrinter2()
	defer func() {
		close(p1.ch)
		close(p2.ch)
	}()

	go p1.Print()
	go p2.Print()

	for i := 1; i < 100; i++ {
		if i%2 == 1 {
			p1.ch <- i
		} else {
			p2.ch <- i
		}
	}
}

阅读、点赞、收藏 detail

Mon, 27 Jul 2026 00:00:00 +0000

简历 preview

简历上 :

设计并实现了一个高并发的阅读、点赞、收藏服务

需求分析 :

阅读数，每次打开都会加1，但是关掉不会 -1
点赞和收藏都有取消功能

技术分析 :

从使用场景考虑 :

当我们点开一篇文章的时候，会看到这篇文章的阅读、点赞和收藏数量。从这里考虑全部都写在一个服务上会更好处理
用户可以单独查看自己收藏的文章。这个角度考虑收藏单独做成一个服务更合适

从性能的角度考虑 :

拆分成三个服务，三个服务可以独立治理，对于分散读写压力有好处

从研发效率角度来看 :

拆分三个服务对应代码就有三套，研发效率不高

因此最终选择研发合并在一起

阅读计数

业务处理 :

当点击文章服务的 GetPubslishId 的时候进行增加阅读计数
- 先操作数据库再更新缓存
- 如果更新缓存失败会导致不一致，但是其实不用管他，因为阅读数不准确从业务角度考虑没什么问题

数据库操作 :

同样需要考虑是否一个情况

如果新帖子没计数，那么应该 create
否则的话 update

因此这边也是 upsert 的语义 . 另外我们不能给使用取出计数然后+1 的做法会有并发问题。因此使用 gorm.Expr(read_cnt+1)

缓存处理

缓存的设计也会有和数据库一样的问题

如果 Redis key 不存在和 redis 存在的情况
因此需要引入 LUA 脚本解决这种情况

业务处理

需要支持

点赞
统计点赞数量
某个用户是否点赞过，并且用户可以取消点赞

对于点赞计数，同样和阅读处理一样。

点赞和阅读不同，需要支持取消点赞，因此需要额外维护一张用户点赞表，聚合 user_id.

考虑软删除策略，因此需要额外加入一个 status 字段。因为取消点赞和点赞是一个很频繁的业务，如果使用硬删除，数据库会有很多 gap

收藏的处理同上述问题

其他

查询接口

对于 阅读、点赞和收藏 的查询接口这三个是互相独立的，所以可以考虑使用 goroutine 进行异步的获取，使用 error_group 进行等待

缓存一致性

对于更新 DB 和数据库操作会存在缓存一致性问题如下

考虑业务情况

阅读数、点赞数或者是收藏数并不一定要严格准确，即使不准确也不会对用户产生什么不好的影响
只有高并发的文章才会有并发问题，而高并发的文章，阅读数、收藏数、点赞数本来就很多，少一点也无所谓

Kafka

kafka 的基本概念

生产者、消费者、broker、topic 、partition

broker 可以认为是中间人，是一个逻辑概念。 broker 可以认为是一个消息队列进程。

可以简单的认为一个业务就是一个 topic . 一个 topic 有多个分区。

当我们讨论 topic 有多少个分区的时候，我们主要讨论的是有多少个主分区

点赞解耦

我们上面设计的点赞系统是每次请求都进行一次点赞操作，每次都会访问我们的 DB

因此我们需要引入 Kafka 来进行异步的解耦

在调用调用获取文章相信的时候发送对应的阅读事件
mQ消费者端，使用 ctxTimeout + channel 控制批量消费
消费插入数据库中使用map对biz进行一次聚合。然后插入数据库，使用事务进行插入。

主要优化

多个业务读取文章是多行sql，现在改成 N 行 ,n <= 多行sql
开启事务，进行一次提交。少了 MVCC 等操作。

亮点

批量消费和批量生产

面试题

有没有用过 kafka ？用来解决什么问题
你为什么要使用 MQ，使用MQ 等好处是什么。异步，解耦，消峰
介绍一下 kafka :
- 什么是 broker , broker 和分区的关系是什么
- 什么是 topic , topic 和分区的关系是什么
kafka 中 producer 中的 ack 有哪些取值？分别是什么含义？你用了哪些
Kafka 中 ISR 是什么意思？
Kafka 中一个分区可以有多个消费者吗
消息积压了怎么半？
- 增加 topic
- 异步消费
- 批量消费
怎么保证消息的顺序？怎么保证全局有序？怎么保证业务有序。？
- 全局有序 : 只使用一个分区
- 业务有序 : 使用 hash类的算法制定生产者发送消息的分区

Web 治理

Sat, 25 Jul 2026 00:00:00 +0000

限流

单机限流

令牌桶算法

算法思路设计

设计一个带有容量的桶
给定速率的进行生成可用令牌
每次请求消耗对应的令牌，如果没有令牌可用则失败

代码

type TokenBucket struct {
	rate       float64    // 令牌生成速率（每秒生成的令牌数）
	capacity   float64    // 令牌桶容量
	tokens     float64    // 当前令牌数
	lastRefill time.Time  // 上次填充令牌的时间
	mutex      sync.Mutex // 保护令牌桶的互斥锁
}

func (tb *TokenBucket) Allow() bool {
	tb.mutex.Lock()
	defer tb.mutex.Unlock()

	now := time.Now()
	elapsed := now.Sub(tb.lastRefill).Seconds()
	tb.lastRefill = now

	// 计算新增的令牌数
	tb.tokens += elapsed * tb.rate
	if tb.tokens > tb.capacity {
		tb.tokens = tb.capacity
	}

	if tb.tokens >= 1 {
		tb.tokens -= 1
		return true
	}
	return false
}

漏桶算法

漏桶算法是令牌桶算法的反向思路看着 , 令牌桶是生成一定容量的令牌

漏桶算法则是以固定速度进行消耗令牌(漏水), 如果请求过来发现水溢出了则禁止访问

代码

type LeakyBucket struct {
	rate     float64    // 漏出速率（每秒处理请求数）
	capacity float64    // 桶容量
	water    float64    // 当前水量（排队请求数）
	lastLeak time.Time  // 上次漏水时间
	mutex    sync.Mutex // 保护内部状态
}

func (lb *LeakyBucket) Allow() bool {
	lb.mutex.Lock()
	defer lb.mutex.Unlock()

	now := time.Now()
	elapsed := now.Sub(lb.lastLeak).Seconds()
	lb.lastLeak = now

	// 按时间漏水
	lb.water -= elapsed * lb.rate
	if lb.water < 0 {
		lb.water = 0
	}

	if lb.water+1 > lb.capacity {
		return false
	}
	lb.water++
	return true
}

固定窗口限流

顾名思义

我们维护一个固定时间的窗口, 在此期间如果访问请求超过窗口大小则失效否则成功。如果窗口超出设置的窗口时间则清空窗口

代码

type FixedWindow struct {
	limit       int64         // 窗口内最大请求数
	window      time.Duration // 窗口大小
	count       int64         // 当前窗口计数
	windowStart time.Time     // 当前窗口起始时间
	mutex       sync.Mutex    // 保护内部状态
}

func (fw *FixedWindow) Allow() bool {
	fw.mutex.Lock()
	defer fw.mutex.Unlock()

	now := time.Now()
	if now.Sub(fw.windowStart) >= fw.window {
		fw.count = 0
		fw.windowStart = now
	}

	if fw.count >= fw.limit {
		return false
	}
	fw.count++
	return true
}

滑动窗口限流

同滑动窗口，无非是动态维护了一下窗口的请求，不额外补充

算法对比

算法	文件	特点
令牌桶	`token_bucket.go`	恒定投放令牌，允许突发
漏桶	`leaky_bucket.go`	恒定漏出，输出更平滑，不允许突发
固定窗口	`fixed_window.go`	实现简单，窗口边界可能双倍突发
滑动窗口	`sliding_window.go`	日志法精确统计，避免边界问题

基于 Redis 限流

对于多实例部署的应用如果要做到单IP 限流, 需要考虑使用 Redis

根据 Redis 单机单线程的特性可以使用 lua + 滑动窗口进行处理

算法

lua脚本 :

计算 min 即窗口的左边界
然后根据 ZREMRANGEBYSCORE 删掉左边的请求
如果大于阈值，那么返回限流
否则增加计数, 并且设置过期时间

-- 基于 Redis ZSET 的滑动窗口限流脚本。
-- KEYS[1]: 限流对象 key
-- ARGV[1]: 窗口大小（毫秒）
-- ARGV[2]: 阈值
-- ARGV[3]: 当前时间戳（毫秒）
-- 返回 "true" 表示应限流，"false" 表示放行。
local key = KEYS[1]
local window = tonumber(ARGV[1])
local threshold = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local min = now - window

redis.call('ZREMRANGEBYSCORE', key, '-inf', min)
local cnt = redis.call('ZCOUNT', key, '-inf', '+inf')
if cnt >= threshold then
    return "true"
else
    -- member 加入 cnt，避免同一毫秒内多次请求互相覆盖
    redis.call('ZADD', key, now, tostring(now) .. '-' .. tostring(cnt))
    redis.call('PEXPIRE', key, window)
    return "false"
end

Go这边的处理


//go:embed slide_window.lua
var slideWindowLua string

func (r *RedisSlideWindowLimiter) Limited(ctx context.Context, key string) (bool, error) {
	return r.cmd.Eval(ctx, slideWindowLua, []string{key},
		r.interval.Milliseconds(), r.rate, time.Now().UnixMilli()).Bool()
}

熔断

熔断的理解 :

当一个服务已经出现问题的时候, 需要控制住访问该服务的请求。

对于 Gin 层面, 我们要做到的就是, 对于下游一个服务崩溃了，能够在请求发送之前就快速返回错误

详细的说就是 :

例如账户服务如果过载了, 数据库请求很慢. 为了防止大量请求导致请求到数据库上从而崩溃. 需要进行熔断

更简单的就是 :

对于手机号登陆的功能 , 如果腾讯云失连续超时，那么需要熔断腾讯云30s 防止多次请求连续超时

参考 :

https://www.liuvv.com/p/2ca9d630.html

实现

这里不详细说出具体思路, 对于 Gin 层面的熔断

我们可以通过使用 middleware 进行判断, 在请求访问之前判断是否允许访问, 如果不可用则 abort()

否则 next() 进入下一个中间件

记入我们请求成功和失败的次数

func CircuitBreakerMiddleware(cb *CircuitBreaker, opts ...CircuitBreakerOption) gin.HandlerFunc {
	o := &circuitBreakerOptions{
		isFailure: defaultIsFailure,
		fallback:  defaultFallback,
	}
	for _, opt := range opts {
		opt(o)
	}

	return func(c *gin.Context) {
		generation, err := cb.Allow()
		if err != nil {
			o.fallback(c)
			c.Abort()
			return
		}

		c.Next()

		if o.isFailure(c) {
			cb.Failure(generation)
			return
		}
		cb.Success(generation)
	}
}

降级

Gin 层面的限流确实没看懂，不过可以就短信服务谈一下限流

对于默认使用腾讯云的短信服务，如果发生了熔断，那么可以考虑使用阿里云进行 backup 这个过程就是降级

同样的

对于热榜服务，如果热榜服务失效。可以考虑去使用历史的热榜来代替现有的热榜

发帖服务 detail

Sat, 25 Jul 2026 00:00:00 +0000

简历 preview

简历上 :

设计并实现了一个发帖服务

需求分析 :

帖子状态分析 : 未发表 -> 发表 -> 被删除

如果做到一边修改一边可查看

分开存储, 设计一个制作库一个线上库

制作库和线上库的事务问题

我们从 service 的角度考虑，其实并不知道 repository 层面存储的是什么数据。所以就别谈开启事务了

因此我们能做的最好的一点就是 重试 . 对于创作者来说就算线上库失败了其实影响也不大

如果看到发表失败，他可以考虑重试
读者完全看不到这个帖子

如果是站在 repository 的角度考虑就要分 同库不同表 和 不同库 的问题

对于 不同库 的情况，可以考虑分步更新 find - update -> upsert

对于 同库不同表 可以采用数据库事务进行处理

建表

Mongodb

雪花算法

因为系统内增加了 MongoDB 但是我们在 repo 层定义的是 int64 的 ID，因此需要使用雪花算法

OSS

通过 OSS 来维护 content

查询接口

作者的查询接口 :

列表接口 : 看到自己发表的所有文章, 这是一个分页接口

详情接口 : 当作者选中了某篇文章的时候，能看到文章的全部内容

读者的查询接口 :

搜索接口 : 接入搜索模块之后设计

推荐接口 : 再设计

阅读文章接口 : 当选中某篇文章的时候, 可以看到文章的全部内容

分页接口处理

分页接口的三种形态 :

Offset + Limit 的形式
之直接定义一个 Page 的形式。前端传递了 page 之后需要后端计算出对应的 offset 和 limit
直接定义一个 Cursor 的形式。每次查询后，后端控制返回一个 Cursor,让前端使用。

缓存设计

PreCache

缓存第一页

大部分没有什么人会缓存分页结果。但是很多业务场景，用户只看列表内容的第一页，很少会往后翻。因此可以考虑 只缓存第一页

实现逻辑 :

查询接口的时候。优先查缓存然后再查数据库。判断 offset == 0 和 limit < 100 则走缓存
更新/新增操作 : 在对于新写文章、编辑文字、发表文章都要清楚相关的首页缓存

缓存第第一条数据

对于创作者查看文章详情接口，很大概率。创作者在拿到列表之后，只会访问第一条数据。所以我们可以考虑进行缓存预加载。只缓存第一条数据

特点：

因为伴随着预测性质，所以这个过期时间设置的很短。避免内存的开销

改进点 :

不缓存大文档。避免浪费内存

面试

什么是 TDD
TDD 和 DDD 的关系
- DDD 适合战略规划，TDD 适合落地具体功能。
TDD 有什么好处
- 理清思路、查漏补缺、方便重构、测试完善。
有没有用过 MongoDB ？用来解决什么问题？
为什么要用 Mongodb 用 mysql 行不行
解释一下 mongodb 中集合和文档的关系
如何设计 Mongobd 上的索引 ESR 原则
如何数据存储在 MongoDB上怎么生成 ID
MongoDB 是否支持事务，是否支持跨文档事务，是否支持 ACID

缓存方案 : 淘汰策略

LRU(最近最少使用) , LFU (最近不频繁使用)

优先淘汰普通创作者的数据，尽可能保留大 V 的数据。 LFU 能够达到近似效果，LRU 效果会差一些
优先淘汰大对象
优先淘汰小对象

发帖服务 one

Sat, 25 Jul 2026 00:00:00 +0000

简历 preview

简历上 : 设计并实现了一个文章服务

考虑文章的业务属性, 创作者支持保存草稿和发布文章。设计了线上库和制作库两个库表设计。

采用 ESR 原则，考虑会有用户查看自己的文章，用户查看某篇文章详情,以及热榜查看对应时间的文章。设定过了 _create,auth_id . 这两个索引

文章服务支持

制作库保存草稿, 设置隐私文章, 发布制作库内容, 按照 ID 查看文章,或许作者文章列表, 获取发布文章列表

支持 MongoDB 和 OSS 的扩展
设计合理的缓存服务
考虑并发场景

细节

数据库索引设计

主要涉及到的业务有 : 作者查看当前文章，和最近一周的热榜设计

对于作者查看当前文章预计查询是 select from where auth_id = '' and statuts = '' 因此设计了 auth_id 的索引

对于最近一周的热榜设计，因为热榜计算是一个频繁的操作，预计查询是 select from where _create >= now-7week 因此设计了 _create 的索引

数据库并发处理

隐私文章功能 :

需要同步改动制作库和线上库的状态。

系统设计的时候选择的是同库不同表的流程因此采用数据库事务进行一致性处理，对于更新失败的操作进行回滚。从业务角度考虑，就算更新失败了也只是让用户多重试几次。

如果是不同库的情况，可以考虑在接口层面增加多次重试。

发布功能 :

对于发布功能, 线上库存在两个状态,线上没有文章需要create,线上有文章需要 update

防止数据库层面的同一篇文章多次竞态问题使用upsert进行操作。

缓存设计

对于列表接口 :

根据习惯习惯缓存第一页内容,大部分用户只会访问第一页的内容。细节: 缓存之前需要清空文章的content 节省内存资源。

在更新，删除，隐私的接口增加对应的删除缓存的操作。

对于查看detail接口 :

根据用户习惯，往往只会查看列表第一篇文章的内容。因此考虑在拉取列表后，缓存第一篇文章的内容。仅在 content < 1M 的时候进行缓存。缓存设置了一个很短的过期时间，防止浪费。

对于发布接口 :

考虑作者发布文章后就会有人阅读，因此在发布的时候就设置缓存。

其他细节

MongoDB

尝试接入 MongoDB 进行存储文章数据。接入 MongoDB 之后发现，MongoDB 返回的 ID 是 String 类型。破坏了原先接口的定义。因此引入了雪花算法进行对其接口

OSS

接入 OSS，在发布文章之后，对于线上库的文章内容进行优化。线上库不保存文章内容，文章内容全部存储在 OSS 中

对接阅读统计服务

使用 channel + ctxWithTimeout 进行批量发送阅读统计给 MQ。供下游消费

作为 Golang 面试官，我按「2 年经验、能独立负责一个业务模块」的标准，对这份 发帖/文章服务 面试准备稿打分如下。

综合评分：68 / 100

维度	得分	说明
业务理解与架构设计	18/25	制作库/线上库分离思路正确，有业务驱动意识
数据库与索引	12/20	有索引意识，但 ESR 理解偏浅，热榜查询设计不完整
并发与一致性	13/20	提到事务、upsert、重试，但缺少边界与失败场景
缓存设计	14/20	第一页缓存、去 content、失效策略有亮点，缺 key 设计与一致性细节
工程化与 Golang 表达	6/15	几乎无 Go 实现细节，MQ 只一笔带过
面试表达与完整性	5/10	结构尚可，错别字多，placeholder 未填，缺 Q&A 演练

结论：作为 2 年经验候选人，项目经历是真实的、方向也对，但这份准备稿更像「项目笔记摘要」，还不足以支撑 45–60 分钟的深度技术面。能过初筛，若在索引、一致性、缓存、Go 并发等点被追问，容易失分。

优点

1. 业务建模有思考

「制作库 + 线上库」分离是内容类系统的常见做法，能解释：

草稿编辑 vs 线上可读
发布时从制作库同步到线上库

这比只会说「CRUD 增删改查」高一档。

2. 缓存策略贴近真实访问

只缓存第一页 —— 符合大部分用户行为
列表缓存去掉 content —— 说明考虑过内存成本
写操作删缓存 —— 知道 Cache Aside 的基本思路
详情预缓存第一条 + 短 TTL + < 1M 限制 —— 有「预测性缓存」意识

3. 并发场景有触点

发布用 upsert 防竞态
隐私状态双库同步用事务
不同库场景考虑接口层重试

说明不是只写 happy path。

4. 扩展能力有落地

MongoDB 接入 + 雪花 ID 对齐 int64 接口
OSS 存正文、DB 存元数据
channel + ctxWithTimeout 批量发 MQ

有「存储分层 + 异步解耦」的工程感。

缺点

1. ESR 原则理解不准确（高风险扣分点）

文档写「采用 ESR 原则，设计了 _create 和 auth_id 两个索引」。

ESR（Equality / Sort / Range）说的是 复合索引字段顺序，不是两个单列索引。面试官很可能追问：

作者查文章：auth_id = ? AND status = ? → 更合理的是 (auth_id, status) 或 (auth_id, status, ctime DESC)
热榜：ctime >= now-7d 且可能要 status = published → 单列 _create 往往不够，还要考虑排序字段（阅读量、score）

若被问到「为什么不用复合索引」，目前文档撑不住。

2. 热榜设计过于粗糙

now-7week 应为 7 天（笔误会减印象分）
没说明热榜指标（UV、阅读量、点赞、时间衰减）
没说明是实时算还是定时任务 + 缓存
频繁计算却只提 _create 索引，逻辑链不完整

3. 一致性问题讲不深

隐私文章「制作库 + 线上库同步」只说了事务和重试，缺：

同库不同表 vs 跨库：最终一致性怎么做
事务失败后用户看到什么状态
OSS 与 DB 不一致怎么办（DB 更新了，OSS 上传失败）
是否需要 Saga / 补偿 / 幂等键

2 年经验不要求精通分布式事务，但要能讲清 自己的方案边界。

4. 几乎没有 Golang 相关内容

这是 Golang 面试准备，但全文没有：

context 怎么用、超时怎么传
goroutine 泄漏怎么防
errgroup / worker pool 怎么做批量 MQ
接口设计、依赖注入、分层（handler/service/repo）
单元测试、压测数据

channel + ctxWithTimeout 只一句，深度不够。

5. 表达与细节问题

statuts、auth_id/author_id 混用、_create 命名不规范
「习惯习惯」重复
description 仍是 xxxx
相比同系列的 register_login tidy，这篇 没有 Q&A 脱稿演练，面试时容易散

6. 缺少可量化的结果

没有 QPS、P99 延迟、缓存命中率、发布失败率等，「设计合理」缺少说服力。

改进建议

一、把每个技术点补成「STAR + 追问应答」

建议每个模块固定四句话：

背景：为什么这么做
方案：具体怎么实现
取舍：为什么不用别的方案
结果：数据或线上表现

示例（索引）：

作者列表查询是 author_id + status + 按创建时间倒序分页。我用复合索引 (author_id, status, ctime DESC)，遵循 ESR：等值条件在前，排序字段在中间。热榜是近 7 天已发布文章按 score 排序，定时任务每 5 分钟算一次，结果放 Redis ZSet，读路径不走 DB。

二、重点补强 5 个高频追问

追问	建议准备内容
为什么制作库/线上库要分开？	读写隔离、草稿不影响线上、发布可审核
发布接口如何保证幂等？	幂等键、upsert 条件、版本号 / status 机
缓存一致性怎么保证？	key 设计、先更 DB 再删缓存、延迟双删要不要
为什么用 MongoDB？MySQL 行不行？	文档结构、字段变化、大正文；MySQL 可以但 OSS 后 MySQL 更合适
MQ 批量发送失败怎么办？	batch 大小、重试、dead letter、ctx 超时

三、补 Golang 实现细节（至少 3 点）

发布流程：ctx 超时、errgroup 并行写 DB + 上传 OSS
阅读统计：带 buffer 的 worker，select + ctx.Done() 优雅退出
接口层：统一错误码、middleware 鉴权、作者只能改自己的文章

能画一张流程图或贴 20 行核心代码，比纯文字强很多。

四、OSS + DB 一致性单独成段

建议明确：

先发 OSS 还是先写 DB？
发布失败如何回滚 / 清理孤儿文件？
读路径：DB 存 content_url，CDN /cache 怎么处理？

五、参考 `register_login tidy` 的结构改版

那篇有「脱讲稿 + 问题列表 + 标准答法」，这篇建议对齐：

## 30 秒 elevator pitch
## 架构图（制作库/线上库/OSS/缓存/MQ）
## 核心接口（Publish / SaveDraft / SetPrivate / List / Detail）
## 5 个技术亮点（每个 1 分钟）
## 10 个高频面试题 + 参考答案
## 踩坑（MongoDB ObjectId、缓存大对象、双库不一致）

六、修正文档硬伤

统一术语：author_id、status、ctime
修正「7 week」→「7 day」
填满 front matter 的 description
通读去掉错别字

面试官视角的一句话评价

「候选人做过真实的文章发布模块，有制作库/线上库、缓存、OSS、MQ 等完整链路意识；但对索引、一致性、Go 并发和面试表达深度不足。若能在 ESR、发布幂等、缓存 key 设计、双库一致性边界上准备充分，可从『大概做过』提升到『能独立负责』，分数有望到 80+。」

如果你愿意，我可以按面试官口吻，直接把这篇 tidy 文档改成「可背诵版」（含 10 道追问 + 参考答案），或对照 register_login tidy 的结构帮你重写一版。

高可用高扩展高安全的登陆与注册的设计 one

Fri, 24 Jul 2026 00:00:00 +0000

脱讲稿

简介 : 设计并实现了完整的高安全性,高可用,高扩展的登陆与注册服务

自述 :

我给系统设计了一个支持手机号码、微信登陆、邮箱注册的登陆与注册服务。使用长短JWT + Session 控制用户的登陆登出。处理了跨域和限流问题,并且对于手机登陆支持切换云服务商支持 failover 策略。功能拥有完整的链路控制，并且使用 wrk 进行压测。

高安全性 :

做了限流, 手机验证, 设备验证

高可用 :

支持切换多个云服务商

高扩展的 :

基于面向接口编程. 并且采用 DDD 设计支持 repo 层切换多个存储方案，支持 SMS 和微信登陆切换各种服务

问题 1

什么是 Gin 的 middle-ware ？能解决什么问题？

Gin 框架提供的一种 AOP 编程机制, 支持实际业务逻辑前后进行插入额外处理。能够解决以下几类问题

Web治理 : 实现 http 层面的熔断、限流、降级

可观测性 : 可以聚合日志，metrics，tracing

身份的认证与鉴权

什么是跨域问题，怎么解决？

跨域的问题本质是请求发送方和接收方 host 和端口不匹配的问题。对于跨域问题，浏览器会预先发送一个 preflight option方法，询问允许访问的范围。

Gin 框架支持使用 Cros 中间件进行处理跨域问题，设置对应的 allow-origins,allow-headers,allow-method即可

跨域问题需要设置哪些头部？上面的已经回答

什么是 cookie，什么是 session ?

http 本身是无状态协议，为了保护用户的登陆状态，浏览器支持本地存储一个 kv 数据, 这个数据可以理解为 cookie

由于 cookie 的安全性问题，隐私信息一般不存放在 cookie中，因此引入 session 机制

session 机制允许绑定一个 session_id 给前端，具体身份校验逻辑可以存放在后端避免隐私信息泄漏

cookie 和 session 比起来有什么缺点？

cookie 不依赖后端存储，并且本身可以设置一些安全性配置例如 domain,expires,secure

缺点的话就是不允许存放敏感信息，容易丢失

–

Session ID 可以放在哪里？如果Cookie禁用

cookie, header, redis,本地缓存,sql 等各种地方

用户密码加密算法的选取

尽可能选择高安全系数的,不宜破解的。技术选型的时候考虑过 md5,pbkdf2,bcrypt

因为 md5 需要在数据库中额外存储盐值的原因最终选择 bcrypt

使用 wrk 压测的时候，发现密码加密和不加密的情况下性能相差10倍, 但是这是不可避免的

怎么做登陆校验 ?

正确性校验 :

在登陆的时候获取对应的账号和密码，去数据库中查找，并且使用 bcrypt 进行比对正确的话则返回对应的 jwt 用于保护用户状体啊

状态维护:

每次获取对应的短token进行 jwt解析，解析失败则登陆失败

安全性处理:

在 JWT 中维护一个 user-agent字段，每次比对该字段是否相同
使用 Redis 限流控制每次的登陆

刷新 Session 过期时间的几种方案
快要过期的时候刷新 ; 这个可能会有 gap
每次访问都刷新。会频繁的读redis
固定时间刷新，增加 updateAt字段

怎么保护 session_id ?主要还是启用 https协议，设置 cookie 的 secure
怎么做到在session_id 和 jwt-token泄漏之后保护着客户？记录登陆的额外信息
如何保护 Web 服务？针对 IP限流、整个集群限流

这几个问题主要在问题 8 会引申

问题 2

你用 Redis 解决过什么问题？

业务上 :

用来标记某些 handle 是否完成。例如某些需要在全环境修复的任务
分布式锁控制针对于 IP 限流的一些账户创建
Stream 实现的轻量化 mq 队列用于实现异步的消费
存储一些实时性不高的例如快照的信息
使用 Zset 进行热榜功能的排序
使用 Redis 单机线程安全的特性实现限流

你知道 Redis 支持哪些数据结构，用过哪些？用来解决什么问题？

string,list,hash,set,zset . 问题 1 的扩展

各个数据结构的底层实现？

不知道，有对应的 memo 。预计会单独开辟一个文章

当你更新数数据的时候先更新数据库还是先更新缓存，有没有一致性问题

先更新数据库，然后删除缓存。对于更新操作采用 Cahce-Aside 的方式会有一致性问题

我们只有在 Get 操作的时候才会重新写入缓存

(这里说实话，忘记了开发的时候的想法了，创建一个memo处理一下)

如何解决一致性问题

这里主要是 check-do thing 的模型吧。尽可能使用原子操作，例如 lua 或者是 atomic

（同样单独使用 memo 进行处理）

问题 3

什么是依赖注入，如何在 Go 实现依赖注入

依赖注入，就是 A 要调用 B 上面的方法, A 在构造的时候要求传入构造好的 B 而不是自己初始化一个 B 。

通过引入 wire包进行依赖注入

什么是面向接口编程？为什么要面向接口编程？

业务之间组件和组件的通信必须依赖接口。即如果 A 调用 B，那么 B 必须是一个接口。

面向接口编程最主要的一点就是提升扩展性，避免代码堆积。

什么是长短 token ？为什么要用长短两个 token ？

长 token 用于控制短 token 的刷新

短 token 用于进行登陆的校验

长短token的设计是为了安全性，如果只有一个 token 有效期设置的很短用户频繁登陆，很长的话会有安全问题

长短 token 的过期时间应该怎么设置？

根据业务需求和产品经理来判断，长 token 一般会很长例如半年，一个月。短token 可以是 2小时或者是 1天

怎么保证长token的安全性，万一泄漏了怎么办？

携带一些设备信息，例如 user-agent 手机设备号，在对于敏感操作的时候，增加手机号验证

使用 JWT token 怎么退出登陆,使用长短 token 之后怎么退出登陆

增加一个 session_id 进行维护，在 Redis 中维护一个黑名单

扩展问题

Q : 对于系统支持微信、手机号、邮箱注册，数据库表是怎么设计的

A : 对于这三个字段单独设计了唯一索引,我们认为任意一个渠道注册进来就是单独的一个账号

Q : 那么如果我后续想要实现手机号和微信和邮箱是一个账号怎么办

A :

看一下业务层面是否要迁移历史数据

如果不迁移历史数据的话 :

创建部分联合索引加上 _create 限制，保证就新的数据需要遵守该索引
业务层面强制这三类业务注册的时候就一起绑定手机号或者是邮箱

如果要迁移历史数据的话

优先保证内部数据迁移跑完
并且合并多个账户之间的数据。这里可能复杂点预计需要强制用户绑定手机号才可以进行功能操作 xxx
创建索引
改善业务层面的登陆与注册服务

Q : Gin 实现了哪些限流降级熔断

遗留

尝试把 SMS 服务单独在拆一个场景出来，增加异步的内容

可以设置一个同步转异步的容错机制。当第三方不可用的时候，将当前请求存储到数据库中，后续再单独启动一个 gouroutine 异步的发送出去

AI Judge

你现在是 Golang 面试官，下面是一个拥有2年经验的求职者的一个面试准备 。 请你结合现有系统实现 和 xxx.md 给其中的内容进行打分 满分100分，给出 优缺点和建议 。

对照 webook 实现后，这份准备材料按 2 年经验后端面试 标准评分如下。

总分：62 / 100

维度	分数	说明
项目叙事与亮点提炼	14/20	有多通道登录、长短 Token、限流、failover，但「三高」略夸大
与代码一致性	10/15	大方向对，细节与代码不一致，易被追问穿帮
安全与鉴权深度	12/20	知道 bcrypt / JWT / ssid，但机制说不清、有概念混用
Go 工程能力（DI/接口/分层）	12/15	这块相对扎实，和代码匹配
Redis / 中间件深度	7/15	用过什么能说，底层与一致性大量空白
表达与完整度	7/15	错别字多、多题空答、遗留太多

优点

项目选型对得上代码：邮箱密码、短信、微信；长短 JWT + ssid 黑名单；User-Agent 校验；SMS failover；Wire + 接口；Redis 滑动窗口限流；CORS；wrk 压测——这些在仓库里都能找到对应实现。
能讲清楚「为什么做」：长短 Token 的安全/体验权衡、接口便于换 SMS/Repo、bcrypt 有压测体感——比只会背概念强。
扩展题有业务意识：多渠道账号合并、历史数据迁移，这是面试官爱听的「产品 + 工程」题。
工程分层叙事清晰：依赖注入、面向接口，和 wire.go、UserCache 注释里的约束一致。

缺点（面试里会扣分的点）

1. 概念混用，容易被打穿

实际是 JWT 放 Header（x-jwt-token / x-refresh-token）+ Redis users:ssid 黑名单，不是经典 Cookie Session。
Cookie / Session 答得偏教材，和项目实现脱节；面试官一问「你们项目 Session 存在哪」，容易答乱。
「Session ID 可放 redis/本地缓存/sql」把 服务端存储 和 客户端携带位置 混在一起了。

2. 与代码不一致

讲稿说法	代码现实
短 Token 2h / 1 天，长 Token 月/半年	短 30 分钟，长 7 天（`redis_jwt.go`）
设备验证	仅比对 `User-Agent`，不是设备指纹
完整高可用 SMS	有 failover，但 `SendV1` 有逻辑问题；真实多厂商未必接好
DDD	更接近分层 + 接口，不是完整 DDD

短信登录流程本身也不完整：LoginSMS 校验成功后没发 Token，Token 却在 SendLoginSMSCode 里设置——若被问「短信登录时序」，会很难圆。

3. 关键答案有硬伤

bcrypt vs md5：选 bcrypt 主要因为自适应哈希/抗暴力破解，不是「md5 要额外存盐」。bcrypt 自带盐，理由说偏了。
跨域：不只是 host/port，还有 scheme；还缺 Credentials、ExposeHeaders（你们代码里刚好有 ExposeHeaders 暴露 JWT Header）。
缓存一致性：写了「忘了」——2 年经验被问 Cache-Aside / 双写，这是硬伤。
Gin 限流/降级/熔断：空题；项目有限流，没有完整熔断降级，却标题写了「高可用」。

4. 准备完整度不够

Redis 底层、一致性、Gin 治理、遗留 SMS 异步都标了 memo/空答。面试不是写博客进度，空题 = 扣分。

5. 自我包装过满

「完整的高安全性、高可用、高扩展」对学习项目偏重。2 年经验更稳妥的说法是：

练手项目，覆盖多登录方式、长短 Token、限流与 SMS 容错，重点验证接口化扩展。

建议（按优先级）

立刻改讲稿

用代码里的真实数字讲：AT 30min、RT 7 天；退出时 ssid 写入 Redis，TTL 与 RT 对齐。
统一术语：说「JWT + 会话标识（ssid）黑名单」，少说「Session 存在 Cookie」。
删掉或降级「设备验证」：改成「绑定 User-Agent，防简单 Token 盗用，不能防 UA 伪造」。
补齐空题，至少能答 2 分钟：
- Cache-Aside：先写 DB 再删缓存；并发下的短暂不一致
- Redis String/Hash/ZSet 各举一个本项目例子（验证码、用户信息、热榜）
- 限流：滑动窗口；熔断降级诚实说「项目未做，可讲思路」

对着代码能画一张时序图

邮箱登录 → 发 AT/RT → 中间件校验 AT + UA + ssid
Refresh：校验 RT → 查黑名单 → 发新 AT
Logout：ssid 入黑名单

面试官最爱顺着这条链路追问。

主动暴露已知坑（加分）

短信登录时序问题
Failover 主备不均 / SendV1 错误处理
FindOrCreate 主从延迟注释

「我知道问题在哪、怎么改」比「系统很完美」更像有 2 年经验。

表达

错别字（Cros、状体啊、Cahce）和口语化「不知道有 memo」直接改掉；面试可以诚实说「这块我回去补过」，但讲稿里不该留白。

面试官视角的一句话

项目素材够用（约 70 分的料），讲解与掌握大约 55–60 分；合在一起 62。
能过初筛讲项目，但深挖安全、缓存一致性、短信登录细节时风险大。把术语对齐代码、补空题、主动讲缺陷，冲到 75+ 比较现实。

高可用高扩展高安全的登陆与注册的设计 detail

Thu, 23 Jul 2026 00:00:00 +0000

简历 preview

简历上 :

设计并实现了完整的高安全性,高可用,高扩展的登陆与注册服务

面试中 :

系统支持邮箱注册,短信验证登陆,系统扫码登陆的功能, 使用 JWT + Cookie 的形式维护登陆状态, 采用长短Token 进行续期. 采用 Lua+滑动窗口实现非访问登陆的限流
短信验证登陆支持阿里云和腾讯云的切换, 使用负载均衡算法进行处理切换同时设计对应的降级策略 failover 保证服务崩溃也能使得部分功能正常
对接微信开发平台实现微信扫码登陆处理2次回调内容

难点 :

一开始使用 cookie + session 实现的注册与登陆，在使用 wrk 压测的时候发现 redis 有很大的压力. 决定牺牲一点性能采用 JWT
用户表设计的时候由于密码是隐私内容需要考虑加密, 在选择加密算法的时候进行了选择, 经历了xxx,最后选择 bcrypt
使用 wrk 压测的时候发现，登陆接口并没有限制会引入大量异常流量，于是自己设计了一个限流中间件，利用 Redis 本身的单线程特性，采用滑动窗口实现
在对接微信扫码登陆时, 因为需要本地测试，但是微信api返回的是注册域名的跳转链接。最后改了本地的 hosts实现测试。另外因为之前表设计缺陷，实现该功能后额外增加了一列微信，并且重新设计了唯一联合索引
全部开发使用 DDD 模式架构进行整理，使用 TDD 业务开发整个开发过程比较繁琐，另外引入装饰器模式和面向接口编程在牺牲开发效率的情况下保证系统的高扩展性

跨域问题

跨域问题是因为 : 发请求的域名 + 端口和接收请求的域名 + 端口对不上。比如前端 localost:3000 发到 localhost:8080 上

对于跨域问题 : 浏览器会提前发送一个 preflight 询问自己愿意接受的请求

解决的办法 : Gin 提供了解决问题的中间件来处理

通过 middle 设置 :

AllowCrendentials : 允许带上用户认证信息
AllowHeader : 业务请求可以带上的头
AllowOrigin : 哪些来源是可以被允许的

cors.New(cors.Config{
			AllowOrigins:     []string{"http://localhost:3000", "http://localhost:3001"},
			AllowHeaders:     []string{"Content-Type", "Authorization"},
			AllowCredentials: true,
			ExposeHeaders:    []string{"x-jwt-token", "x-refresh-token"},
		})

加密

选择加密算法的标准就一个, 难破解. 需要考虑以下的问题 :

相同的密码
难以通过碰撞来破解

常见的加密算法 :

md5
在 1 的基础上引入 salt 这里需要额外存储
使用 PBKDF2,BCrypt 随机盐值的加密算法进行加密

浏览器存储一些数据到本.

不安全 : 可以通过 cookie-editor插件进行获取

一些设置 :

Domain: cookie 可以用在什么域名下

Path: Cookie 可以用在什么 path 下

max-Age: 过期时间

Http-only: 如果设置为true, js代码无法使用这个 cookie

Secure: 只能使用于 https 协议

一些有意思的问题

Q : 为什么有一些网站喜欢禁用 Cookie

A : 没看懂说实话，安全相关的内容难理解

Session

我的理解就是一个 key-string , 不过他是由后端存储

但是他还是强依赖 cookie , 无非最重要的一点就是 cookie如果存放敏感信息会被获取,所以引入session,传入 session_id 用于后端校验

如何让客户端懈怠 session_id :

最佳的方式就是放在 cookie中, 毕竟 cookie还可以设置 secure

如果禁用了 cookie 可以考虑放在 header 和 sess_id 中

JWT

JWT 由 header+playload+sign 组成

JWT 与 Session 比较 :

优点 :

不依赖第三方存储
适用于分布式环境
提高性能 (没有 Redis 访问)

缺点 :

对加密依赖非常大
最好不要在 JWT 放置敏感信息

退出问题

Session 的退出，需要先把 cookie 删了然后把 session本身删了

但是 JWT 本身是无状态的，所以旧的token在没有过期其实也是能用的

JWT 如果要实现退出登陆，只能够考虑使用 redis 黑名单的机制

但是我们已经实现了长短token, 如果记录黑名单需要在登陆校验的时候也要传入黑名单。这导致长token会被频繁调用

所以考虑 JWT 中存放 session-id 使用 session-id进行黑名单控制

安全性问题

Q : 我们实现登陆与注册系统之后有一个最大的问题就是

任何人都可以注册
任何人都可以登陆

因此我们需要考虑 限流

这里采用 Redis+lua 滑动窗口限流

Q : 如何保证 JWT 或者是 Session 泄漏攻击者假冒你

采用验证码二次验证，对比上一次的信息例如 user-agent

性能问题

使用 wrk 进行性能压测

wrk -t1 -d1s -c2 -s ./script.lua urlpath/signup

参数解释如下. :

-t: 线程数量

-d: 持续时间

-c: 并发数量

-s: 测试脚本

压测下来预计会发现两个问题

加密算法 . JWT 在注册和登录后会进行加密和解密，预计相差 10倍
数据库查询

优化数据库查询

我们常见的一种写法是 cache-db-cache

func FindById() {
	cache.Get()

	db.Get() 

	_ := SetDB()
}

场景问题决策

Q : Session 的过期时间如何刷新 ?

用户每次访问, 都刷新. 如果 session 部署在 redis 上，那么影响很大
快要过期了我再刷新。有 gap
固定时间刷新，引入 updateAt 参数 , 用户每次访问的时候如果超过固定的时间那么刷新

Q : 长短 token

短 token : 用于访问资源

长 token : 短 token 过期之后，生成一个新的短 token

这里其实是依赖的前端，我们在登陆接口的时候返回两个 token

然后提供一个 refresh 接口,如果短token 失效，让前端用长token请求刷新一下

第三方服务治理

整体思路 :

尽量不要搞崩第三方
万一第三方崩了，你的系统还能够稳定运行

failover

failover (失效转移)

如果第三方崩了那么就直接换一个服务商

策略有 :

轮询
- 缺点每次都从头开始，负载不均衡
- 如果 sms svc 很多, 轮询很慢
动态轮询
- 每次使用 i%length的方式进行轮询
- 不过这里需要注意并发问题需要引入 atomic
动态判断第三方
- 真的计算服务商是否还在运作正常 .
- 可以从错误率
- 响应时间判断

OAuth2

微信

微信扫码登陆看着更像是 TCP 链接的三次握手分为

请求登陆
返回确认请求
确认
带上 uuid 进行请求
返回 access token

配置

之前我们一开始使用的是 build tag 进行配置控制

我们如果要优化配置可以从下面的方式进行考虑

启动参数，命令行工具传入的参数。例如 mysqlroot:password
环境变量
配置文件。使用 viper 制定 path 进行读取
远程配置中心。 etcd

配置文件的缺点 :

不够灵活
权限控制
实时更新

日志

使用 zap 进行日志处理, zap 本质上是维护了一个全局 logger

可以考虑使用适配器模式封装一下 zapper

Gin 可以考虑使用 middleware 进行打印日志

通过在 ctx.Next()前后处理对应的数据
但是我们无法获取到 resp,我们需要自己重新实现一个 respWriter

Gorm 可以考虑使用 config.Logger实现

其他的地方只能考虑从 Service 插入 logger 或者是维护全局 logger的形式进行输出com

面试题

什么是 Gin 的 middle-ware ？能解决什么问题？
什么是跨域问题，怎么解决？
跨域问题需要设置哪些头部？
什么是 cookie，什么是 session ?
cookie 和 session 比起来有什么缺点？
Session ID 可以放在哪里？如果Cookie禁用
用户密码加密算法的选取
怎么做登陆校验 ? 利用 Gin 的 middleware
刷新 Session 过期时间的几种方案
增强登陆的安全性

怎么保护 session_id ?主要还是启用 https协议，设置 cookie 的 secure
怎么做到在session_id 和 jwt-token泄漏之后保护着客户？记录登陆的额外信息

如何保护 Web 服务？针对 IP限流、整个集群限流

Redis :

你用 Redis 解决过什么问题？
你知道 Redis 支持哪些数据结构？用过哪些？用来解决什么问题？
各个数据结构的底层实现？
当你更新数数据的时候先更新数据库还是先更新缓存，有没有一致性问题 (这在登陆与注册超纲了吧)
如何解决一致性问题
什么是依赖注入，如何在 Go 实现依赖注入
什么是面向接口编程？为什么要面向接口编程？
什么是 Ioc 控制反转

微信登陆 (TBD)

微信扫码登陆的流程
为什么微信的回掉地址，域名必须是你预先注册的
如果我的临时授权码(code)被黑客拿到了会怎么样
state有什么作用？如何使用 state ?

什么是长短 token ？为什么要用长短两个 token ？
长短 token 的过期时间应该怎么设置？
怎么保证长token的安全性，万一泄漏了怎么办？
使用 JWT token 怎么退出登陆
使用长短 token 之后怎么退出登陆
使用 JWT 还需要再使用 Session 吗

亮点提升

Gin :

Web治理 : 熔断、限流、降级

限流实现：

单机限流 :

令牌桶算法
漏桶算法
滑动窗口算法
固定窗口算法

基于 Redis 限流

基于 Redis IP 限流

Gin插件库

Gorm :

为 Gorm 提供可观测性的插件实现
实现读写分离插件
提供 BeforeFind 函数

第三方服务治理 :

可以设置一个同步转异步的容错机制。当第三方不可用的时候，将当前请求存储到数据库中，后续再单独启动一个 gouroutine 异步的发送出去

考虑布隆过滤器进行黑名单过滤

面经每日一看

Wed, 22 Jul 2026 00:00:00 +0000

本篇面经来自 : https://www.nowcoder.com/feed/main/detail/ac0efc95550947c0a55693799dbfa380?sourceSSR=search

个人背景与项目挖掘

Q : 简单介绍一下目前在职的情况，以及寻找新机会（离职）的原因是什么？

Q : 介绍一下你在做的项目，核心思想和解决的痛点是什么？

两个很普通的问题 : 总结

问题 2 : 预计到时候要准备一篇 500 字的演讲稿方便背诵。已添加到 Memo 中 ddl 预计下个月

Go 语言基础

常识题

Q : 项目里用到了 Gin 框架，请问 Gin 第一层的参数绑定（Parameter Binding）底层是怎么实现的？

Gin 支持 Bind 和 ShouldBind 两种调用

func (c *Context) ShouldBind(obj any) error {
	b := binding.Default(c.Request.Method, c.ContentType())
	return c.ShouldBindWith(obj, b)
}

func (c *Context) Bind(obj any) error {
	b := binding.Default(c.Request.Method, c.ContentType())
	return c.MustBindWith(obj, b)
}

其中通过 Method 来分发对应的实现

func Default(method, contentType string) Binding {
	if method == http.MethodGet {
		return Form
	}
	switch contentType {
// ... 
		return BSON
	default: // case MIMEPOSTForm:
		return Form
	}
}

shouldbind 不额外封装 http-code，但是bind额外封装。

func (c *Context) ShouldBindWith(obj any, b binding.Binding) error {
	return b.Bind(c.Request, obj)
}

func (c *Context) MustBindWith(obj any, b binding.Binding) error {
	err := c.ShouldBindWith(obj, b)
	if err != nil {
		var maxBytesErr *http.MaxBytesError
// ... 
		switch {
		case errors.As(err, &maxBytesErr):
			c.AbortWithError(http.StatusRequestEntityTooLarge, err).SetType(ErrorTypeBind) //nolint: errcheck
		default:
			c.AbortWithError(http.StatusBadRequest, err).SetType(ErrorTypeBind) //nolint: errcheck
		}
		return err
	}
	return nil
}

具体更核心的实现，预计就是读取 http 的请求根据各种字段进行处理。预计只要回答到这一步即可

todo : 整理这部分内容单独到 Gin 中

Q : Go 语言中的 Channel 有什么特点？在使用它的时候需要注意什么？

吐槽一下 : 说实话实际工作中用到 channel 的地方真的很少

目前的印象来说 :

channel 的发送操作和接收操作会相互阻塞直到双方准备完毕

使用它有什么需要注意的：记得 close

todo : 这个后续预计会在系统整理高并发那一块处理，或者是在补充《协程池》这篇文章后进行针对学习

Q : 如果一个 Channel 已经关闭了，再往里面写数据会发生什么情况？

WrongAnser : 从上面的回答来看，如果接收方的channel关闭，但是发送方的没关闭，预计是会一直阻塞，然后程序运行后会出错 all sleep goroutine, deal lock 印象中是这样

True : panic: send on closed channel

todo : 会一并同上面的问题一起处理

代码输出题

1
2
3

有一个切片 s := make([]int, 3)，
然后往里追加数据 s = append(s, 1, 2, 3)，
最终 fmt.Println(s) 打印输出的结果是什么？

这个问题是默认补0吧，println不是sprintf(%v)感觉会输出地址？不过预计答案是 0,0,0,1,2,3

纠正 : fmt.Println 对 slice 用的就是类似 %v 的默认格式，打印的是元素内容：[0 0 0 1 2 3]

Redis

Q : Redis 的分布式锁怎么实现的 ?

不知道，印象中是 setNx 但是没实际实现过

todo : 补在memo中

Q : 如果现在想做一个排行榜功能，应该用 Redis 的哪种数据结构？

Zset, 不过如果要处理 100w 的排行的话需要在业务上额外处理一下，例如定时排序+Zset 不过这个作业目前还没完成只是知道一个概念

todo : 补在memo中

Q : Redis 的字符串类型中，有没有哪个指令能够对已存储的数字进行累加？

没看懂这个什么问题，字符串类型的累加？ IncrBy() 吗，需要注意的是如果没有key和有key的情况。这个在查询和缓存计数的时候有考，预计在下周总结出来

Q : 了解 Redis 的缓存雪崩、缓存穿透和缓存击穿吗？分别是什么以及怎么解决？

吐槽 : 梦会实习面经

缓存雪崩指的是 : 大量数据没有命中缓存导致都打到数据库上

缓存穿透 : 指的是数据在缓存和数据库中都不存在

缓存击穿 : 热点 key 正好过期，此时又有大量数据引入

解决办法忘记的差不多了，不过从现在的业务理解上面看

给数据库进行限流降级，保住一部分用户的使用。另外使用其他可用的Redis
都不存在，那就用布隆过滤器过滤一下，本质上就是给不存在的key增加一个缓存
和方法2差不多，也是缓存一下这个过期的大V key

Kafka

Q : Kafka 是怎么保证消息消费的有序性的？

没用过 Kafka 不知道

todo : 推进 kakfa 的学习

SQL

1
2

假设有一个部门表 department，包含以下四列：ID（主键）、UID、age（年龄）、dept_id（部门 ID）。
需求：查询平均年龄在 20 岁以上的部门 ID。

吐槽 : 没想到 26年的面试也是这么存粹，还有手撕sql的环节

这里简单手撕一下，估计牛客上面有原题输入输出什么的预计，这周末去刷一下

1
2
3

select dept_id from ( 
    select dept_id,avg(age) as avg  from department where avg > 20 group by dept_id
)

猜测是这样

手撕代码

`1`	`golang语言用协程交替打印1-100`

这个炫技做法就是参考我这里的实现吧协程池，用协程池开2个goroutine 输出就行了？不过输出的时候全局变量要上锁

感觉不用搞这么麻烦，直接手动开启两个 gouroutine ，然后用 atomic并发安全的基本类也行？

不过怎么实现交替，用管道通信？一个携程输出完然后传给另外一个直到 100 然后close ?

写了一下没写出来，看着是写入方和接收方不能够同时操作 …

todo: 实现 1-100交替输出

type printer struct {
	numerChan  chan atomic.Int64
	changeFlag atomic.Bool
}

func main() {
	wg := sync.WaitGroup{}
	wg.Add(3)

	p := printer{
		numerChan:  make(chan atomic.Int64),
		changeFlag: atomic.Bool{},
	}

	printNum := atomic.Int64{}
	go func() {
		p.numerChan <- printNum
	}()

	trueGoroutine := func(x atomic.Int64) {
		fmt.Println(x)
	}
	falseGoroutine := func(x atomic.Int64) {
		fmt.Println(x)
	}
	select {
	case printNum = <-p.numerChan:
		if printNum.Load() == 100 {
			defer close(p.numerChan)
			wg.Done()
			wg.Done()
			wg.Done()
		} else if p.changeFlag.Load() {
			go trueGoroutine(printNum)
			printNum.Add(1)
			p.numerChan <- printNum
		} else {
			go falseGoroutine(printNum)
			printNum.Add(1)
			p.numerChan <- printNum
		}
	}
	wg.Wait()
}

AI Summary

总评

答对：4 / 11（另有 2 道半对） 评分：48 / 100

按技术题计（不含自我介绍/项目介绍）。能答对的多是「知道用什么」，卡在「怎么做对 / 边界 / 落地」。

逐题核对

#	题目	判定	说明
1	Gin 参数绑定	✅	Bind/ShouldBind、按 Method/ContentType 分发，方向对，面试够用
2	Channel 特点与注意	⚠️	「互相阻塞」只覆盖无缓冲；「记得 close」不准确
3	往已关闭 channel 写	❌	你自己标了 Wrong；正确是 `panic: send on closed channel`
4	`make([]int,3)` + append	✅	`[0 0 0 1 2 3]` 正确
5	Redis 分布式锁	❌	只想到 setNx，缺过期、value、续期、释放校验
6	排行榜用啥	✅	ZSet 正确
7	字符串累加	✅	INCR/INCRBY 正确
8	雪崩/穿透/击穿	⚠️	定义大致对，方案混、不完整
9	Kafka 有序性	❌	空白
10	SQL 平均年龄	❌	应用 `HAVING`，不能 `WHERE avg > 20`
11	协程交替打印	❌	没写出；现有代码结构也不对

优点

会追源码：Gin 那题不是背概念，而是顺着 ShouldBind → Default → MustBindWith，面试里加分。
知道错在哪：closed channel、slice 打印都能自纠，学习闭环在。
选型直觉还行：排行榜 ZSet、计数 INCR，方向不偏。
有复盘习惯：todo / memo 落点清楚，比「看完就过」强。

缺点

基础边界不熟：channel close、SQL HAVING、手撕交替打印 —— 都是高频送分题。
中间件偏「听过没用过」：Redis 锁、Kafka 几乎空。
缓存三兄弟：定义能背一半，方案和场景对不上（击穿该用互斥/singleflight，不是「再缓存一下」）。
手撕偏复杂：交替打印绕 atomic + channel of atomic，反而写挂；面试要最小正确实现。

建议（按优先级）

本周先补这 4 个，能直接拉到 ~65：

SQL

SELECT dept_id FROM department GROUP BY dept_id HAVING AVG(age) > 20
Channel

无缓冲/有缓冲、close 后读零值、写 panic、nil channel 永久阻塞、谁负责 close
交替打印（双 channel 或一个 channel + 两个 goroutine 即可）

func main() {
	ch1, ch2 := make(chan struct{}), make(chan struct{})
	var wg sync.WaitGroup
	wg.Add(2)
	go func() {
		defer wg.Done()
		for i := 1; i <= 100; i += 2 {
			<-ch1
			fmt.Println("A:", i)
			ch2 <- struct{}{}
		}
	}()
	go func() {
		defer wg.Done()
		for i := 2; i <= 100; i += 2 {
			<-ch2
			fmt.Println("B:", i)
			if i < 100 {
				ch1 <- struct{}{}
			}
		}
	}()
	ch1 <- struct{}{}
	wg.Wait()
}

Redis 锁一句话版

SET key uuid NX EX 30 → 业务 → Lua 校验 uuid 再 DEL；进阶再提 Redlock / 看门狗续期。

下周： Kafka「单分区有序 + 同 key 进同分区」；缓存三兄弟各配 1 个标准方案（随机 TTL / 布隆或空值 / mutex）。

面试表达： Gin、ZSet 这类题用「结论 → 一句原理 → 一句坑」三段式，比贴大段源码更稳。

一句话： 选型感和复盘习惯不错，但基础题失分多；先把 SQL / Channel / 手撕 / Redis 锁补实，分数会比补 Kafka 涨得更快。

战略性调整

Wed, 22 Jul 2026 00:00:00 +0000

我做了什么

可以说, 我持续学习了一周半(今天是周三)

上周学习了 7天, 没什么公司的事无非就是开几个同步会

总共学习时间 39h ，那么一天学习时间大概在 5.7h 左右

大部分实现在 golang 语言上面，少部分在算法和总结上面

一些想说的话

承认我很累:

不得不承认一天学习 6h 很累，超他妈的超级累

我回想一下我每天的生活

早上

9:00 起床 - 9:30 开始学习 - 10:40左右休息

11:00 学习 - 11:40 休息

12:00 吃饭 - 13:00午休结束

早上总共预计 1h + 40min = 1h40min 的学习时间

下午

13:10 学习 - 14:30 结束

14:50 学习 - 15:50 结束

16:00 - 18:00 开始发散

下午的有效学习可能只在 2h 另外2h 印象中不是那么有效

晚上

18:00 - 19:00 期间做饭，无氧锻炼

19:00 - 20:00 洗澡吃饭

20:00 - 21:00 休息，玩游戏

21:00 - 22:00 (可能会跑步或者是散步，跑步的话会要一个小时，散步的话只要半个小时)

22:00 - 23:00 (之前这段时间会去学习算法，但是最近一直在和女朋友聊天)

23:00 - 00:00 (写算法题，总结，这段时间最近也在和女朋友聊天)

00:00 - 0:30 睡觉

晚上的有效学习时间预计也只在 2h ，但是最近一直在和女朋友聊天。

就算是我算上下午的不高效学习时间和女朋友聊天的时间那么一天也有 7h40min 的时间,但是这好累，就是为了多出这 4h

从利益的角度考虑，确实一天多学习了 4h 确实比一天学习 3h 的多一天但是这样好累

另外吐槽一下

自从不上班之后，他妈的周六周天都没了，一直在他妈的学

我方向歪了？

我不知道是不是我方向歪了，说实话我在 Go上面已经投入了 52h

按我之前实习准备来说这52h 都够我写3个项目了

一个博客系统。亮点在于点赞服务的设计，缓存的控制，ES，Grafana QPS的处理
一个 geeRPC 框架
一个基于 RPC的聊天室

但是反观我现在得到了什么

一个只完成了 1/3 的项目，目前只完成了

使用 DDD 进行项目架构, TDD 进行业务开发
支持 微信、SMS、邮箱注册登陆的方式, 使用多种限流算法进行无登陆态的限流 . 自选型通过 cookie+JWT 进行维护登陆权限和状态控制
使用装饰器以及面向接口设计,封装和二次开发 日志组件 和 监控组件 以及配置组件
使用 K8S 进行线上环境的部署
支持分级数据展示,设计线上表和开发表. 实现多台实例上的一致性问题
支持 MySQL 平滑迁移到 Mongodb . 设计并实现 SMS 的熔断以及限流业务

后面还有

`1`	`待实现 Kafka 点赞、榜单设计、微服务拆分、分布式任务调度、ELK、支付、秒杀、Feed流设计`

说实话有点后悔了，我是随便找了一个 24年的训练营的课程走的。当然也不能说是随便只能说是最全面当下最好的系统课了

总共 21周的视频，一周平均 3 个 3h 的视频总共时长 189h

说实话这比当初规划翻了好几倍

而且说实话这个课程有我只能给到中规中矩的评价

优点

资料比较详细
核心场景，面试考点，实际开发中的情况都有介绍

缺点

时长太长了，内容体量很大
多个模块之间可能没什么关联，例如引入了 Mongodb 和 k8s 也只是为了实现 dao层级的切换，以及简单的部署。但是讲完之后后面就再也没用到了
有一些代码并没有在课上完成，也就是就算189h学习完成后，可能还需要多花90h用来处理其他内容

说实话不后悔是假的，如果我真想要找下一份工作

我应该把实习的项目捡起来，花20h记住，然后再花30h-40h的时间准备AI Agent那个仙骨

然后再花 40h准备面经，但是现在好像上了贼船

小总结

我不知道应该怎么走，但是我要继续走

这里简单算一笔账，课时总共 21周，那么一周我学习7周 的内容 3周就能解决

这要求我一天基本上就要解决掉一周的学习内容大概 9h ,算上倍数 4.5h

感觉是可以的

那么我就需要把每天学习的时间 [3h40min , 7h40min] 改成 6h40min

这样子我可以使用多出来的 2h 进行很好的复习和总结

那么如果我把玩游戏的1h拿出来呢？如果我把晚上睡前的1h拿出来呢？

或许学生时代的我有这个精力

总结

简单理清了一下现状

第一个月 :

完成 21周 学习的内容
保证每周平均每天 6h40min的学习时间，其中 4h 放在 go上面，当然如果一天学习了一周的内容，可以考虑往后吞并一周或者是进行总结
其余2h用于算法的学习以及总结

第二个月 :

把原先的精力放在熟悉八股文
模拟面试
面经
算法题

第二个月底+第三个月尝试开始投递

写给我自己 :

我承认这很难，但是计算下来看着也不是没有完成的希望。最近学习破防了好几次，总感觉来不及，但是计算下来发现是可以完成的

我清楚的知道这两个月会很枯燥也会很难可能没有结果也能会有坏结果但是我当下能做的也只有这个

协程池

Mon, 20 Jul 2026 00:00:00 +0000

池化技术

我们对于一个批量操作，例如 批量暂停账户 或者是 批量删除数据

我们很常规的做法就是接口开放 []business_list 然后通过 for 进行处理对应的对应的业务逻辑

func Handler(req) error {
    // ... 
    for _, item := range business_list{
        handle(item)
    }
    // ... 
}

但是这种在数据量大的时候会有一个问题那么就是 前端等待超时, 这个超时我上班的时候看着是 nginx还是前端那边特定组件控制的

这时候可能就会想到

我们只提交 tasks 然后放入到数据库中，单独开启一个 go backend_job 进行处理，并且处理对应的状态流转。这种思路在我们批量处理数据的地方 屡见不鲜
- 这里就需要考虑状态的流转，展示
- 如果进程重启，还需要恢复
- 如果数据量很大很大，是不是要考虑分批分次进行，还需要进度控制
使用 long-task 接口，前端发起req请求，后端返回一个 task-id 然后每次都适用 task-id进行请求查看任务状态。
- 这种做法，我能想到的问题就是，用户会被硬控在前端页面一直loading

池化技术貌似并不能很好的解决第一个方案，如果数据量真的很大很大，感觉还是要进行分批分次进行，并且加上进度控制。顶多优化一下每轮的次数

更多的是优化第二个内容，优化接口的响应和返回

`1`	`[AI Asking]: 池化技术在业务中最多解决哪一类问题？我们什么时候用到池化技术`

突然想起来了 :

这里的池化技术特指 并发池 而不是 连接池 对于连接池的技术不熟悉

GMP

现在我是一个小白, 例如如果我们要实现 清理 100w条数据 那么是否是开 100w 个 gorutine 更好呢，毕竟每一个 gourtine 单独处理最快

我么可以从 GMP设计图 中很直观的看到

全局队列 : 存放等待运行的 G
P的本地队列 : 存放的也是等待运行的 G 。本地队列的限制是 256
P列表 : 可以认为是逻辑上的 CPU . 数量可以认为是 CPU 的核数
M : 线程 ; 想要运行任务就需要获取 P . 并且通过内核线程 Kernel Thread 进行 CPU 的相关调度请求

一些调度关系 :

如果当前 M 绑定的 P 的 G 阻塞了，那么会重新调度一个新的 M 进行后续 G 的运行
G 如果运行完之后会产生对应的 GC 占用一定的内存空间
如果当前本地队列 P 没有可运行的 G, 那么会去全局队列进行寻找
如果当前本地队列 P 没有可运行的 G 并且全局队列为空，那么会去其他队列进行偷取 . (降低性能)

大量创建 go 协程的代价

内存开销:

初始阶段 goroutine 大概只有 2k 的内存开销 . ps : 一个线程大概需要 2M 的开销

/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.23.4.darwin-arm64/src/runtime/runtime2.go:422

调度开销:

我们可以从上面的图中看到，一个G 需要先放到全局队列，然后到本地队列，最后到P 又需要根据M进行绑定最后跑到内核线程。
并且一个很坏的结果是，当我们的G 阻塞后，会创建新的M 来进行执行，导致内核的线程开销也会变大

gc开销:

协程占用的内存最终需要 Gc 来回收

协程池

我们知道

并发可以提高处理请求的速度
但是并发数量并不是越多越好

这是一个 规则怪谈 ，所以这时候引入了 协程池，即固定数量的协程

例如 nginx 最多支持每秒钟并发 5 个请求，那么我们就可以启动一个数量为5的协程池进行批量工作

实现 1

架构

work 实际运行的 gourtine 用于并发处理 func()
JobsChannel 内部任务的队列用于分发任务到 work()中
EntryChannel 对外处理任务的队列，用于对接 JobsChannel 的数据

代码剖析

Task

定义 Task 其中值字段包含一个 func value()

并且支持一个函数用于执行 Execute()

type Task struct {
	f func() error
}

func NewTask(f func() error) *Task {
	return &Task{f: f}
}

func (t *Task) Execute() error {
	return t.f()
}

Pool

整个 pool 定义如下

type Pool struct {
	EntryChannel chan *Task // 对外的任务入口
	JobsChannel  chan *Task // 内部的队列
	workerNum    int        // 协程池最大的数量
}

支持的 Func 如下

单独解释一下 Run 过程

这里先通过遍历workerNum 启动 gourtine
启动之后会进入到 JobsChannel 此时数据里面没有,会进行阻塞

然后下方的数据会进行获取数据并且传入

func (p *Pool) worker(workerId int) {
	for task := range p.JobsChannel {
		task.Execute()
		fmt.Println("worker ID ", workerId, " ")
	}
}

func (p *Pool) Run() {
    defer close(p.JobsChannel)

	for i := 0; i < p.workerNum; i++ {
		go p.worker(i)
	}

	for task := range p.EntryChannel {
		p.JobsChannel <- task
	}
}

完整运行

func Test_ExamplePool(t *testing.T) {
	a := atomic.Int64{}
	task := NewTask(func() error {
		fmt.Println("task :", a.Add(1))
		return nil
	})
	pool := NewPool(3)

	go func() {
		for i := 10; i != 0; i-- {
			pool.EntryChannel <- task
		}
		defer close(pool.EntryChannel)
	}()

	pool.Run()
}

实现 2

手写协程池

协程池的应用

其他

[all_in_ai] AI 名词扫盲 Tool

Sat, 18 Jul 2026 00:00:00 +0000

如果想让 AI 给你输出一套方案或者是分类规则是非常容易的

但是想让他给你查看今天天气，或者是预定明天机票一般来说都不能很完美的进行

而 Tool 就是为了实现这些内容

Agent 和 Tool

Agent在上一篇文章中指出是负责作出决策和调用工具，所以 Agent主要负责的就是调度和决策

用户 : 提供需求

大模型 LLM : 负责决策，先做什么后做什么

Agent : 负责 Tool 的调度，和 LLM 调度

Tool : 实际处理解决问题的操作

具体来说，当你给 Agent 下一条指令：「帮我读取 C 盘目录下的 hello_world.cpp 文件，移动到 D 盘目录下，最后给我总结一下这个文件的核心内容」，整个执行流程是这样的：

Agent 把需求 + 工具清单打包，发给大模型 ：「用户想做这件事，你有这些工具可以用，第一步该怎么做？」
大模型做决策，返回指令 ：「调用【读取文件】工具，路径是 C://hello_world.cpp」
Agent 执行指令，调用工具 ：真正去磁盘上读文件
Agent 把结果回传给大模型 ：「文件读取成功，内容是……」
大模型根据结果，决定下一步 ：「好，现在调用【移动文件】工具，把它移到 D 盘」
循环执行，直到任务完成 ：所有步骤跑完，大模型生成最终总结
Agent 把结果反馈给你 ：任务完成你看，这整个过程里，「决策」始终在大模型，「执行」始终在工具，而 Agent 就是那个来回传话、推进任务的协调员。

Tool

我们在写 skills 的时候，经常会用到 python 处理脚本

那么 python 代码就是 tool 吗

Tool 的四要素

函数本体

函数本体：真正干活的代码

name (名称) : 大模型的识别标签

description (描述) ：整个工具定义最重要的字段

parameters (参数定义) : 告诉大模型我们应该怎么填参数

函数本体 :

# ===== 第一部分：函数本体（大模型看不到，Agent 负责执行）=====
import requests

def get_weather(city: str, date: str) -> dict:
    """调用天气 API，查询指定城市指定日期的天气"""
    response = requests.get(
        "https://api.weather.com/v1/forecast",
        params={"city": city, "date": date}
    )
    data = response.json()
    return {
        "city": city,
        "date": date,
        "weather": data["condition"],   # 晴/多云/雨
        "temperature": data["temp_c"],  # 摄氏度
        "humidity": data["humidity"]    # 湿度百分比
    }

工具说明书包含 name + description + parameters

// ===== 第二三四部分：工具说明书（大模型看到的部分，靠这个决定要不要调用）=====
{
  "name": "get_weather",
  "description": "查询指定城市在指定日期的天气情况。当用户询问某地天气、出行建议、是否需要带伞等问题时使用此工具，返回天气状况、气温和湿度信息。",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "要查询天气的城市名称，例如：北京、上海、广州"
      },
      "date": {
        "type": "string",
        "description": "查询日期，格式：YYYY-MM-DD，例如：2025-03-21"
      }
    },
    "required": ["city", "date"]
  }
}

[webook-tidy] Gin & 基本路由

Fri, 17 Jul 2026 00:00:00 +0000

Gin 入门

Gin-Engine

在 Gin 中, 一个 Web 服务器被抽象成为 Engine

Engine 承担了路由器注册、接入 middleware 的核心职责

func main() {
    server := gin.Default()
}

type Engine struct {
	// ... 
    RouterGroup
	// ...
}

Gin-Context

Gin 封装的上下文, 其中 Request 和 Writer 负责处理请求和返回相应

type Context struct {
    writermem responseWriter
    Request   *http.Request
    Writer    ResponseWriter
    
    Params   Params
    handlers HandlersChain
// ..
}

对于 GET 的参数我们使用 query 进行获取参数

`1`	`code := ctx.Query("code")`

对于 POST 的参数我们使用 Bind 进行获取参数

	type Req struct {
		Code  string `json:"code"`
		Phone string `json:"phone"`
	}
	var req Req
	if err := ctx.Bind(&req); err != nil {

Gin 路由注册

在 Engine 的 RouterGroup 支持注册 Restful 的接口

// ... 
func (group *RouterGroup) POST(relativePath string, handlers ...HandlerFunc) IRoutes {
	return group.handle(http.MethodPost, relativePath, handlers)
}

// GET is a shortcut for router.Handle("GET", path, handlers).
func (group *RouterGroup) GET(relativePath string, handlers ...HandlerFunc) IRoutes {
	return group.handle(http.MethodGet, relativePath, handlers)
}

// DELETE is a shortcut for router.Handle("DELETE", path, handlers).
func (group *RouterGroup) DELETE(relativePath string, handlers ...HandlerFunc) IRoutes {
	return group.handle(http.MethodDelete, relativePath, handlers)
}
// ...

基本路由

跨域请求

前端端口是 localhost:3000 请求到了后端 localhost:8080

对于域名和端口任意一个不同都是跨域请求

跨域请求问题是浏览器那边进行控制的

每次浏览器请求前，会提前发送一个 Option 的方法访问 allow-origins,allow-headers,allow-method

如果不在允许范围内就会失败

中间件

对于请求发送到实际业务逻辑。前后插入的额外处理即是 middleware

也就是 AOP编程。

最常见的 AOP 就是

beforeHook()
do()
afterHook()

限流start --> 熔断start --> handler --> 熔断end --> 限流end

Gin 插件支持使用 Use 进行中间件的注册

func (group *RouterGroup) Use(middleware ...HandlerFunc) IRoutes {
group.Handlers = append(group.Handlers, middleware...)
return group.returnObj()
}

面试

什么是 Gin 的 middleware ？能用来解决什么问题？
什么是跨域问题，怎么解决？
跨域问题需要设置哪些头部？

最后

设计并实现一个 Gin插件库

使用 middleware 机制实现 Gin 插件库支持

Web 治理 ：熔断限流降级
可观测性 : 包括日志、metrics、tracing
身份认证与鉴权 :

[webook-tidy] Gorm & 用户基本功能 & docker

Fri, 17 Jul 2026 00:00:00 +0000

Gorm

Orm (Object Relational Mapping) : 对象关系映射。 Orm框架提供不需要关注实体对象与数据库之间的操作关系

Docker Compose

docker compose 启动 mysql8

基本语法 :

services : 服务列表
image : 镜像
command : 启动命令 (启动命令行参数)
volumes : 挂载文件
ports : 端口映射关系

version: '3.7'
services:
  mysql8:
    image: mysql:8.0.29
    command: --default-authentication-plugin=mysql_native_password
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: root
    volumes:
      - ./script/mysql/:/docker-entrypoint-initdb.d/
    ports:
      - "13316:3306"

基础命令 :

dokcer compose up : 初始化 dokcer-compose 并且懂 docker compose down : 删除 docker-compose 里面创建的容器

项目结构

Service : 代表领域服务完整的业务的处理过程

Repository : 按照 DDD 的说法是代表领域对象的存储，可以认为是存储数据的抽象

Dao : 代表数据库操作

domain : 代表领域对象

├── domain
│   ├── user.go
├── repository
│   ├── cache

│   ├── dao

│   └── user.go
├── service

这里简单提一下 :

我们公司项目的调用逻辑是 :

每一层都有自己相同的 user , 从这里看

htv2-db 操作代表 dao
exgv2 层代表 domain (和 db 弱关联，但是算是底层数据)
cefiacc 即是 Repository
ec代表 service 封装给其他组进行调用

`1`	`ec --> cefiacc --> exgv2 --> htv2(db)`

一些疑问

为什么有了 repository 之后还要有 dao ?
- repository 是一个整体抽象，本质上可以考虑用 ES或者是Mysql或者是 mongoDB 并不代表数据库

HTTP

无状态协议 HTTP

HTTP 是无状态协议，对于连续发送的两次请求, HTTP 并不知道两次都是同一个人发的

只能引入 cookie 和 session 进行记录

浏览器存储一些数据到本地，这些数据就是 Cookie

因为 Cokkie 是放在浏览器本地的，所以很不安全

一些关键配置 :

Domain : cookie 可以用在什么域名下
Path : cookie 可以用在什么路径下
Max-age 和 Expires : 过期时间
Secure : 只用于 HTTPS 协议

func SetCookie(w http.ResponseWriter, r *http.Request) {

 cookie := http.Cookie{
  Name:     "access_token", 
  MaxAge:   3600,       
  Path:     "/",        
  HttpOnly: true,       
  Secure:   true,     
 }

 // send cookie via header
 http.SetCookie(w, &cookie)
 fmt.Fprintln(w, "Cookie has been set!")
}

Session

由于 Cookie 本身不安全的特性，所以大部分我们不把一些关键信息放在 Cookie

关键数据我们希望放在后端，这个存储的东西就是 session

	sess := sessions.Default(ctx)
	sess.Set("userId", user.Id)
	sess.Options(sessions.Options{
		MaxAge: 20,
	})
	sess.Save()

个人理解 :

session也离不开本地化存储，大部分都是放在 cookie中如果禁用了cookie也会考虑放在header或者是query中
使用session无非是把敏感信息的相关校验放在了后端

面试

什么是 cookie 什么是 session ?
cookie 和 Session 比起来有什么缺点
Session ID 可以放在哪里？
用户密码加密算法选取有什么注意事项
怎么做登陆校验

后续

增强扩展 GORM 功能

为 GORM 提供可观测性的插件实现
为 GORM 提供读写分离插件
为 GORM 提供 BeforeFind 功能
为 GORM 提供辅助方法

[webook-tidy] Session & JWT & Security

Fri, 17 Jul 2026 00:00:00 +0000

场景问题

刷新登陆状态

对于一个设置了 10分钟过期时间的 session，我们应该如何采用刷新策略才能够保证用户在用着用着就要重新登陆

用户每次访问，我们都刷新
- 性能差，对 Redis 之类的影响很大。小公司看不出来，但是如果是 10w or 100w用户级别
快要过期了我在刷新，例如 10分钟过期，用户9分钟过来访问的时候刷新
- 如果用户第9分钟没有过来那就寄了

因此只能考虑使用 固定时间间隔刷新,比如每分钟内的第一次访问我们都刷新

即

在sesssion中维护一个 updateAt 的参数
然后在 middleware 中进行更新

JWT

JWT (Json WEB Token) : 很常见的一种机制，主要用于身份认证

基本原理就是通过加密生成一个 token ,每次访问都带上这个token

组成部分 :

Header : JWT 的元数据
Payload : 数据内容
Signature : 签名

基本流程如下 :

使用 NewWithClaims 设定指定的算法
并且传入对应的 userCliams

func (j *jwtHandler) setJWTToken(ctx *gin.Context, uid int64) error {
    userClaims := UserClaims{
    RegisteredClaims: jwt.RegisteredClaims{
    ExpiresAt: jwt.NewNumericDate(time.Now().Add(time.Minute * 30)),
    },
    UserId:     uid,
    UserAgents: ctx.Request.UserAgent(),
    }
    
    token := jwt.NewWithClaims(jwt.SigningMethodHS256, userClaims)
    tokenStr, err := token.SignedString([]byte("secret"))
	
	ctx.Header("x-jwt-token", tokenStr)
//. ..
}

校验方通过同样的 sign-method 和 secret 校验是否正确

JWT 的优缺点

和 Session 比起来优点 :

不依赖第三方存储
适合用于分布式环境
提高性能

缺点 :

对加密依赖非常大
最好不要在 JWT 中存储敏感信息

保护系统

如果有一个人，使用脚本进行大量的发送注册、登陆请求，系统负载会提高所以这时候需要考虑保护系统

最简单的一个办法就是 限流

限流

如何在登陆之前确定限流

我应该怎么认定是哪个用户发送了什么请求？
我应该怎么确定我限流的阈值时多少？

限流对象

IP 是最容易获取的限流方式之一

其中更好的选择还有 MAC 地址 以及 CPU序列号 但是在 web端很难获取

APP端端话可以考虑设备序列号

不过 IP 并不能实际意义上代表一个人，因为两个人可以共用一个 ip 但是这已经是较好的一个选择了

限流阈值

限流阈值时通过 压测 得到的。例如 压测 了整个系统，发现最多只能撑住每秒 1000个请求，那么阈值就是 1000

安全

不管是 JWT 还是 Session 一旦被攻击者拿到关键的 JWT 或 SSid 攻击者就会假冒你

HTTPS 可以有效的阻止攻击者拿到你的 JWT 或者是 ssid

但是如果你电脑中了病毒，那 HTTPS 也无能为力

最好的解决办法是做一个二次校验，即增加 发邮件, 发短信 的形式进行控制

或者是增加一些额信息例如 HTTP 的User-Agent头部，或者是手机硬件信息

面试

刷新 Session 过期时间的几种可行的办法
增强登陆的安全性
- 怎么保护 session id ? 主要还是开启 HTTPS 协议，把 cookie 的 Secure 和 HttpOnly 设置为 true
- 怎么做到在 Session id 或者是 JWT token 泄漏之后保护住用户？要在登陆的时候记录一下登陆的附加信息，例如 user-Agent 在登陆校验的时候统一校验
如何保护 Web 服务？针对 IP 限流、整个集群限

后续

支持 Gin 的限流插件 :

单机限流 :

令牌桶限流
漏桶限流
滑动窗口限流
固定窗口算法

分布式限流 :

基于 Redis 限流
给予 Redis 的 IP 限流

[Acwing] 基础算法(十一) 欧拉函数

Thu, 16 Jul 2026 00:00:00 +0000

欧拉函数

什么是欧拉函数

对于一个数 N, phi(N) = x 其中 x 代表 1~n 中与n 互质的个数

互质的意思就是 n 与 a 没有公因子

算法思路

我们知道一个数 n = p1^a1 * p2^a2 ... pn^an

即对于 p1 有 x1 个数在 1~n中不是互质的因为他是因子，那么不互质的个数就是 y1 = n - n/p1 算个倍数

同理可得其他质因子的算法从而推出 phi = n * (1 - 1/p1) * (1- 1/p2)... (1-1/pn)

代码

int phi(int x) {
  int res = x ;
  for(int i = 2; i <= x/ i ; i ++ ) {
      
    if(x % i == 0 ) {
      res = res - res/i;
      while(x % i == 0 ) x/=i ; 
    }
  }
if(x > 1) res = res  - res / x ;
  return res; 
}

时间复杂度

sqrtN

[Acwing] 基础算法(十) 约数

Wed, 15 Jul 2026 00:00:00 +0000

约数

约数的概念 : 能被整除的数叫做约数即 d|n ,d是 n 的约数

试除法求约数

算法思路

我们在 试除法求质数 的时候，知道如果d|n那么d/n | n 因为一个数的约数最小都是 2倍

所以我们可以通过 for(int i = 2; i <= x/i ; i ++ ) 的方式寻找约数

不过需要注意的是对于 1 可以是任何数的约数

所以我们这里的循环需要从 1 开始取

代码


vector<int> getDiv(int x){ 
    vector<int> ans ;
    for(int i = 1; i <= x/ i ; i ++ ) {
        if(x % i == 0) {
            ans.push_back(i);
            if(i != x /i ) {
                ans.push_back(x/i);
            }
        }
    }
    sort(ans.begin(),ans.end());
    return ans ;
}

int main() {
  ios::sync_with_stdio(false);
  cin.tie(nullptr);
  cin>>n;
  while(n -- ) {
    int x;cin>>x;
    auto ans = getDiv(x);
    for(auto res : ans) {
        cout<<res<<" ";
    }
    cout<<endl;
  }
  return 0;
}

时间复杂度

O sqrtN

约数个数

算法思路

我们知道一个数可以拆分成 n = p1^a1*p2^a2*p3^a3...pn^an 这是质因数分解的章节学到的

同时我们可以知道对于 p1 的幂，取值有 0~a1 种，因为剩下的p2...pn可以被整除

所以根据排列我们知道约数个数为 (a1+1)*(a2+1) ... (an+1)

代码

  int n;
    cin>>n;

    unordered_map<int,int> primes;//映射函数

    while(n--)
    {
        int x;
        scanf("%d",&x);

        for(int i=2;i<=x/i;i++)
        while(x%i==0)
        {
            primes[i]++;
            x/=i;//方便求得约数的数量
        }

        if(x>1) primes[x]++;//x的最大公约数可能大于sqrt(x);
    }

    long long res=1;
    for(auto p:primes) res=res*(p.second+1)%mod;//将统计出来的数按照由图中公式所得出来的结论得出答案

    printf("%lld\n",res);

时间复杂度

o sqrtN

约数之和

算法思路

题目求的是所有约数乘积的和

即 (p0^a1 + p1^a2 .... pn^an+1) * (p?1^b1 + p?2^b2 ... p?n^bn)

根据乘法原理我们可以提取出来

(p0^0 + .. p0 ^(a1 + ???) ) * (pk^0 + ...) 的形式

因此我们只需要做一次质因数分解，然后根据次数进行求质数幂次的乘积和即可

代码

#include <bits/stdc++.h>
#define LL long long
using namespace std;
const int N = 1e6+10, mod = 1e9+7;
int n;

int main() {
  ios::sync_with_stdio(false);
  cin.tie(nullptr);

  cin>>n;
  unordered_map<int,int> mp ;
  while(n -- ) {
    int x;cin>>x;
    for(int i = 2; i <= x / i; i++) {
        while(x % i == 0) {
            x /= i;
            mp[i]++;
        }
    }
    if(x > 1) mp[x]++;
  }
  LL ans  = 1;
  for(auto x : mp) {
    LL t = 1; 
    int a = x.second ; 
    while(a -- ) {
        t = (t * x.first + 1) % mod ;
    }
    ans = ans%mod * t %mod ;
    
  }
  cout<<ans<<endl;
  return 0;
}

时间复杂度

o sqrtN

最大公约数

算法思路

我们知道如果 x | a 并且 x | b 那么 x | a * y + b * k

同理对于 gcd(a,b) = gcd(b, a % b) 为什么等式成立？因为 x | b 那么 x | a + c * b 这里的 c 就是 -a/b

因为 x | a + c *b - c*b 等式成立所以 x|a成立

代码

1
2
3

int gcd(int a,int b) {
  return b ? gcd(b , a %b) : a; 
}

时间复杂度

[all_in_ai] AI 名词扫盲 agent

Wed, 15 Jul 2026 00:00:00 +0000

名词扫盲

Agent

对于 llm 和 prompt 他都只能进行 ask 操作，并不能干，只是能输出

什么是 Agent

Agent (智能体) : 能够自主感知环境，作出决策，调用工具，完成多步骤任务的程序

自主（Autonomously）：不需要人在每一步发指令。你给它一个目标，它自己判断下一步做什么
多步骤（Multi-step）：一个任务可能要走 5 步、10 步，Agent 自己把这些步骤串起来
工具调用（Tool use）：调用真实的函数，查数据库、搜网页、发通知、写文件，不只是"说说"，而是真的去做

一句话总结： Agent = 大模型（大脑）+ 工具（双手）+ 执行循环（思考-行动-观察-再思考）

为什么需要 Agent

之前我们说过大模型的三大短板：

没有执行能力：只能生成文字，不能操作外部系统
知识有截止日期：不知道最新数据，看不到你的私有系统
没有持久记忆：每次调用对它都是全新的，不能积累任务中间状态

Agent 的核心组成

大模型（LLM），大脑

负责理解任务、分析当前状态、决定下一步做什么。所有的"推理"都在这里发生，该查什么、查完之后怎么解读、下一步往哪走，全是大模型来判断。

工具（Tools），双手

一个个可以被调用的真实函数：查数据库、调用搜索引擎、读写文件、发通知、调用 API…… 大模型告诉 Agent “调用这个工具、传这些参数”，代码层面真正去执行。工具的结果会返回给大模型，供它继续推理。大模型不"直接"操作外部系统，它通过工具来"动手"。

记忆（Memory），记事本

短期记忆：当前任务里的对话历史 + 每次工具调用的结果，存在 context window 里。Agent 执行第 5 步时，“记得"第 1 步查到了什么，靠的就是这个
长期记忆：跨会话需要记住的信息，存在外部数据库，需要时检索出来注入 context

为什么需要记忆？多步骤任务里，每一步的结果都是下一步判断的依据。没有记忆，每步都是"从零开始”，Agent 根本没法串联多步骤任务。

执行循环（Loop），节拍器

Agent 的"引擎"。不断重复"思考 → 行动 → 观察"这个循环，直到任务完成。没有这个循环，Agent 只是一次性的问答，无法串联多步骤。这个循环是 Agent 和普通大模型调用之间最根本的区别。

Agent 是怎么工作的. ReAct 循环

目前主流的 Agent 工作范式叫做 ReAct 即 Reasoing+Acting 即推理 + 行动 + 观察 + 在推理 ..

用户：帮我调查今晚 23:00 的数据库报警

[第 1 轮]
Think：需要先拿到具体的报警详情
Act：调用 get_alarm_details(time="23:00")
Observe：返回"连接数突增，连接池耗尽，持续 8 分钟后自动恢复"

[第 2 轮]
Think：连接数突增，需要看是哪些查询造成的
Act：调用 query_slow_log(timerange="22:50-23:10")
Observe：发现 3 条全表扫描的慢查询，来自同一个用户 ID

[第 3 轮]
Think：根因已经清楚，生成分析报告
Act：输出最终分析结论（Final Answer）

几个关键机制：

结果回流：每一轮的工具调用结果都会追加到 context window 里，大模型下一轮能"看到"所有历史。所以它能基于已有发现继续推理，而不是每次都从零开始。这就是为什么前面"记忆"那个组件如此重要。
动态决策：每一步该怎么走，是大模型实时推理出来的，不是你提前写好的。发现是慢查询，它就去查慢查询日志；如果发现是网络问题，它就会去查网络相关的工具。路径是活的，不是死的。
何时停止：大模型判断任务已完成时输出"最终答案"，或者达到预设的最大轮数上限。两个条件任意满足一个，循环结束。这就是"自主"的含义，你给任务目标，它自己决定怎么走到终点。

Agent 的另一个工作模式 Plan and Execute

ReAct 很好用，但有一个先天的弱点。

ReAct 是「边想边做」，每一步只看眼前，这一步的结果决定下一步的方向。对于 2-3 步能解决的短任务，这完全没问题。但如果任务很复杂、步骤很多呢？

问题一：长任务容易「迷路」

ReAct 跑了 8 轮之后，context window 里已经堆满了历史操作记录。大模型要在这一大堆信息里同时维持「当前在第几步」「最终目标是什么」「还缺哪些信息」，注意力越来越稀释，越往后越容易偏离最初的目标。

问题二：容易绕弯路

没有全局规划，每步只看眼前，就像在迷宫里随机探索，走了 5 步之后才发现方向不对，只能回头重来，白白消耗了好几轮 LLM 调用。

问题三：token 消耗滚雪球

ReAct 每一轮都要把完整的对话历史带上。步骤越多，每轮的 context 越长，后期每次 LLM 调用的 token 消耗都很高，成本直线上升。

这三个问题催生了另一种工作模式： Plan and Execute（规划-执行模式） 。

核心思路用一句话说清楚： 先让大模型把整个任务规划成一份清单，再逐步按清单执行，而不是走一步看一步。

Plan and Execute 的两个阶段

第一阶段：Planner（规划阶段）

大模型拿到任务，先不调任何工具，专注做一件事：把任务完整拆解成一份有序的子任务清单。

用户：「帮我调查今晚 23:00 的数据库报警，写一份完整的故障分析报告」

Planner 输出的计划：
  步骤 1：获取 23:00 报警的详细信息（报警类型、持续时间、影响范围）
  步骤 2：查询报警时间段内的慢查询日志，定位异常 SQL
  步骤 3：查询报警时间段内的数据库连接数、CPU、内存指标
  步骤 4：关联步骤 2 和步骤 3 的结果，分析根因
  步骤 5：生成完整的故障分析报告，包含时间线、根因和改进建议

第二阶段：Executor（执行阶段）

执行步骤 1：
  → 调用 get_alarm_details(time="23:00")
  ← 返回「连接数突增，连接池耗尽，持续 8 分钟后自动恢复」

执行步骤 2：
  → 调用 query_slow_log(timerange="22:50-23:10")
  ← 发现 3 条全表扫描的慢查询，来自同一个用户 ID

执行步骤 3：
  → 调用 get_db_metrics(timerange="22:50-23:10")
  ← CPU 正常，连接数峰值达到上限 500，内存无异常

执行步骤 4：
  → 大模型综合步骤 2、3 结果进行分析
  ← 结论：慢查询导致连接长时间占用，连接池耗尽触发报警

执行步骤 5：
  → 生成故障分析报告
  ← 完整报告输出，任务完成

Re-planning （重新规划）

执行中途如果遇到了计划没预料到的情况，比如步骤 2 查不到慢查询，但发现了大量锁等待，Executor 可以把这个新信息反馈给 Planner，重新生成后续步骤的计划，而不是一条路走到黑。

用户任务
  ↓
[Planner]  大模型一次性生成完整计划
  ↓
执行计划 = [步骤1, 步骤2, 步骤3, 步骤4, 步骤5]
  ↓
[Executor] 按顺序执行每个步骤
  步骤1 → 调工具 → 结果
  步骤2 → 调工具 → 结果      ← 遇到意外？触发 Re-planning，重新调整后续计划
  步骤3 → 调工具 → 结果
  ...
  ↓
最终结果汇总 → 输出给用户

ReAct vs Plan and Execute：怎么选？

对比维度	ReAct	Plan and Execute
决策时机	每一步实时决策	开始前一次性规划
全局视野	弱（只看当前这步）	强（提前看到全貌）
灵活性	强（随时根据结果调整）	弱（计划一旦生成，调整成本高）
适合任务步骤	少（3 步以内）	多（5 步以上的复杂任务）
token 消耗	随步数线性增长，后期很贵	规划阶段集中消耗，执行阶段可控
实现难度	低（结构简单）	中（需要管理计划状态和 Re-planning 逻辑）

简单记忆：

任务步骤少、目标模糊、需要随机应变 → 用 ReAct
任务步骤多、目标明确、需要全局把控 → 用 Plan and Execute
系统复杂、两者都需要 → Plan and Execute 做外层框架，每个子任务内部跑 ReAct

最后这种「外层 Plan and Execute + 内层 ReAct」的搭配，在实际生产系统里最常见，用规划保证大方向不跑偏，用 ReAct 保证每个子任务执行时足够灵活。

Agent vs Workflow

Workflow（工作流）是你提前写好所有步骤和分支逻辑的流程：先做 A，再做 B，如果 B 的结果是 X 就走流程 C，否则走流程 D。大模型只是其中某个步骤里被调用一次，整体流程是硬编码的。

Agent 是你只给任务目标，大模型自己实时决定每一步做什么、调用什么工具、根据结果决定下一步。执行路径是动态的，每次运行可能走不同的路径。

对比维度	Workflow	Agent
决策者	你（写死的代码逻辑）	大模型（实时推理）
执行路径	固定	动态
适合场景	步骤明确、重复性高	任务开放、情况多变
可预测性	高	低
成本	低	高（多轮 LLM 调用）

两者没有高下之分，适合不同的场景：

流程能写清楚、步骤是固定的 → 优先用 Workflow ，更稳、更省钱、更可预期
任务是开放式的、需要根据中间结果动态决策 → 用 Agent
最常见的实际架构： Workflow 做骨架，Agent 负责其中需要判断的环节，两者结合，不是非此即彼

一个真是的 agent

def run_agent(user_message):
    messages = [
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user",   "content": user_message},
    ]

    while True:
        # 1. 调用大模型，让它思考下一步
        response = llm.call(messages)

        # 2. 如果大模型说"我完成了"，退出循环
        if response.is_final_answer:
            return response.content

        # 3. 否则，执行大模型指定的工具
        tool_result = execute_tool(response.tool_name, response.tool_args)

        # 4. 把工具结果追加到 messages，供下一轮参考
        messages.append({"role": "tool", "content": tool_result})

总结

整理一下这一章的核心认知：

Agent 是什么 ：以大模型为大脑，能自主调用工具、完成多步骤任务的程序。让大模型从"只能说"变成"能干"。

核心组成 ：大模型（大脑）+ 工具（双手）+ 记忆（记事本）+ 执行循环（节拍器）

核心机制：Think → Act → Observe 循环，每轮工具结果都回流给大模型，直到完成

和 Workflow 的本质区别 ：决策者不同，Workflow 是你提前写好的代码逻辑，Agent 是大模型实时推理。两者不是竞争关系，实际系统里经常结合使用

[all_in_ai] AI 名词扫盲 prompt

Wed, 15 Jul 2026 00:00:00 +0000

名词扫盲

Prompt

Prompts (提示词) ; 对于同一个 LLM , 不同的人用结果天差地别，而 prompt 就是为了统一。

可以是 :

具体的指令
具体的问题
具体的背景
具体的格式要求

messages = [
  { role: "system",  content: "你是一个 OnCall 助理，回答必须简洁" },
  { role: "user",    content: "昨晚数据库报警是什么原因？" },
]

system和user 都是 prompt 的一部分

为什么 prompt 很重要

llm 本质上是一个 next-token 的预测及其。对于模糊的上下文，他往哪里走的方向就越多，输出的就越随机

但是给的上下文越精确，它搜索的范围就越窄

user prompts

大部分 Ai 对话都是 user protmps

好的 User prompts 的三要素 :

目标明确 ：要做什么？分析、总结、改写、生成代码，得明说。“帮我看看这个日志"不是目标，“帮我分析这段日志里的报错原因并给出排查方向"才是。
背景充足 ：大模型不知道你的业务、你的系统架构、你的团队惯例，它只能靠你给的信息推断。背景给得越充分，它越不需要乱猜，幻觉越少。
输出要求 ：格式、长度、风格，不说，它随心所欲。你想要 Markdown 列表？想要 JSON？想要 3 条以内？一定要在 Prompt 里讲清楚。

场景对比 :

❌ 简单版：「数据库怎么了？」大模型不知道你说的是哪个数据库、什么时间发生的、有什么报警信息、你想要什么样的答案。

✅ 完整版：

以下是今天凌晨 2 点的数据库报警日志：

[日志内容]

请分析可能的根本原因，并给出 3 条排查建议，以 Markdown 列表格式输出。

System Prompt

用户层面看不到 system prompt 这是开发提前写进去的一个底层指令

system prompts 的三个核心用途 :

身份设定 ：给模型一个具体的角色

1
2

你是一个 OnCall 助理，专门帮助工程师排查和分析系统故障。
你只处理与系统稳定性、报警分析、故障排查相关的问题。

行为规则：定义模型"能做什么、不能做什么”

不允许回答与系统故障无关的话题。
如果你不确定某个判断，必须说明"我不确定，建议进一步验证"。

不要自行假设任何背景信息，只根据用户提供的内容作答。

输出格式约束 ：让模型每次都按固定格式输出

你的回答必须是 JSON 格式，包含以下字段：
summary：对问题的一句话概括
root_cause：可能的根本原因列表
action_items：建议的排查步骤列表

如何写好一个 pormpts

给模型"角色”
正向约束 > 负向约束

❌不要太啰嗦
✅回答控制在3句话以内

喂足够的信息
指定输出格式
Few-shot . 给几个参考例子
让模型先思考再回答

请先逐步分析，再给出最终结论

[all_in_ai] AI 名词扫盲大模型

Wed, 15 Jul 2026 00:00:00 +0000

名词扫盲

大模型

什么是大模型

LLM (large language Model) 大语言模型。平时说的 [AI 对话] [AI 助手] 都是大模型

大的体现 :

参数量大 : 模型内部有数千亿个参数
训练数据大

根据给的上下文，预测接下来最合理的文字是什么

大模型读文字的基本方式

Token 是大模型处理文本的基本单位。LLM 会把一句话拆分成多个 token 进行读取

对于一句话 hello world ，通常会被切分为 ["hello", "world"] ，大约一个单词对应一个token

Token :

决定模型能处理的文本长度上限 : 最常见的就是 200k
决定 API 调用花费

上下文窗口

上下文窗口，限制了 token 的量。跟达模型聊的越久，越容易忘记前面发生的事

GPT-4 有 128K token 窗口，大约 10w个汉字
Claude 3.5 有 200k 的 token 窗口

不过上下文窗口并不只是包含你询问的数据，它包含 你发出去的所有消息+模型的所有回复+调用工具的结果

大模型是无状态的

LLM 本身没有任何记忆，每次调用 APi 对他来说都是第一次见面

为什么我们在网页端 Gemini 和 Gpt 上面聊天都能记住前面的话，是因为在应用层，代码已经处理了记忆

每次我们发送消息，他都会把历史对话打包成为一个列表传给大模型

这就引入了两件事 :

为什么上下文窗口会写满 : 历史对话越多，上下文窗口会更快的被占满
为什么 Agent 需要管理记忆 : Agent 在执行长任务时，必须主动决定把哪些历史传进去，不然窗口很快就会塞满

对话的角色结构 : system,user,assistant

既然多轮对话是靠 传历史列表实现的，那么列表长什么样

调用大模型 API 时，你传入的不是一段裸文字，而是一个有结构的消息列表，每条消息都有一个角色（role）：

system ：系统提示，给模型的"身份设定和行为规则"。比如「你是一个 OnCall 助理，只能回答和系统故障相关的问题，回答必须简洁」。这部分用户看不见，但模型会严格遵守
user ：用户的输入，就是你说的话
assistant ：模型之前的回复，多轮对话时，把历史回复也打包进来，模型才知道"之前说了什么" 用伪代码表示，大概长这样：

messages = [
  { role: "system",    content: "你是一个 OnCall 助理，回答必须简洁" },
  { role: "user",      content: "昨晚数据库报警是什么原因？" },
  { role: "assistant", content: "是慢查询导致的连接池耗尽。" },
  { role: "user",      content: "怎么预防？" },   // 当前问题
]

https://cloud.tencent.com/developer/article/2643849

大模型能帮我们做什么

使用自然语言，分析意图
会进行逻辑思考，拆解任务和做决策
生成符合要求的内容
看懂规则并且执行

大模型做不到什么

没有执行能力, 只能通过 agent+tool的方式进行调用
知识有保质期，容易瞎编
上下文窗口有限，记不住太长的内容

开发场景

在理解完上面的概念之后，我们可以知道 agent 开发 就是给 llm 增加 Tool 调用,funciton call ,MCP 并且加上 RAG (知识库) 进行应用开发

[Acwing] 基础算法(九) 质数

Tue, 14 Jul 2026 00:00:00 +0000

质数

质数的概念

对于大于 1 的数，其因数只有他自己和1 那么这个数就是质数

试除法判定质数

算法思路

根据质数的定义出发我们可以很简单的想到下面的形式，进行枚举来判断出来是否是质数

  for(int i = ; i <= n ; i ++ ) {
        if(n%i == 0) {
            return false ;
        }
  }

但是这种算法是 on 的

我们根据 d | n 那么 d/n | n 可以得到 d < n^2

这个怎么理解，例如 2 | 8 那么 4 | 8 因为最小的质数是 2 因此肯定存在这种情况

所以我们可以考虑优化 i 的枚举, 从而达到 sqrt(n) 的时间复杂度

  for(int i = ; i <= n/ i ; i ++ ) {
        if(n%i == 0) {
            return false ;
        }
  }

时间复杂度

分解质因数

算法思路

我们需要知道对于一个数 n 他可以拆成多个质数p幂的乘积即 n = p1^a1 * p2^a2.. pn^an

我们需要分解质因数，只需要从小到大枚举出能够整除的数即可,因为我们肯定会先遇到2，3这个质数，除完之后发现剩下的数也都是质数

代码

void SplitPrime(int x) {
    for(int i = 2 ;i <=  x / i ; i ++ ) {
        if(n % i == 0 ) {
            int s = 0 ;
            while(x % i == 0 ) {
                x /= i ;
                s ++ ;
            }
            cout<<i<<" "<<s<<endl;
        }
    }
    if(x > 1) {
        cout<<x<<" "<<1<<endl;
    }
}

时间复杂度

logn ~ sqrt(n) 之间

筛质数

埃及筛

算法思路

我们知道一个质数 i ，他的倍数 2*i,n*i 的因数肯定是 i

所以我们可以根据这个性质过滤掉 i 的倍数

代码

void filterPrime() {
    int cnt = 0 ;
    for(int i  = 2; i <=  n ; i ++ ) {
        if(!st[i]) {
            for(int j = i ; j <= n ; j += i  ) st[j] = 1;
            cnt ++ ;
         }
    }
    cout<<cnt<<endl;
}

时间复杂度

o (nlnln)

线性筛

线性筛是对埃及筛的一个优化，我们每次都用 最小质因子进行优化

代码

void filterPrime() {
    int cnt = 0 ;
    for(int i = 2; i <= n; i ++ )  {
        if(!st[i]) prime[++cnt] = i ;
        for(int j = 1 ; prime[j] <= n / i  ; j ++ ) {
            st[prime[j] * i] = 1 ;
            if(i % prime[j] == 0) break; 
        }
    }
    cout<<cnt<<endl;
}

时间复杂度

[webook-tidy] Golang 基础语法

Tue, 14 Jul 2026 00:00:00 +0000

函数式编程

Golang 支持定义方法作为变量即 myFunc = func(){}, myFunc() 的形式

同样方法也可以作为返回值

func Say() func(name string) string {
    return func(name string)string {
        return "hello," + name
    }
}

闭包

closure ：方法+它绑定的上下文

组成如下 :

方法
运行时上下文 : 即 name 变量

func Closure(name string) func() string {
	return func() string {
		return "hello " + name
	}
}

闭包如果使用不当会造成内存泄漏, 因为外层 Func 的name变量被直接使用传递出去了。如果一个对象被闭包引用，他是不会被垃圾回收的

不定参数

Golang 支持不定参数传递即,使用...进行，不定参数可以当作切片进行使用

1
2
3

func hanlder(name string ,alias ...string) {
    println(alias[0])
}

其中 Option模式 大量应用了不定参数

Defer

Golang 允许你从方法返回前一刻执行一段逻辑

Defer 的运行逻辑类似于栈即 后进先出

func Defer() {
    defer func() {
        println("第一个defer")
    }()
    defer func() {
        println("第二个defer")
    }()
}

输出如下

1
2

第二个 defer 
第一个 defer

问题

defer 有一个 catch 的机制，主要考 for 中的内容，如果是通过闭包传递或者是通过拷贝变量进行copy 他会catch到当前值而不是最后值

func DeferClosureLoopV1() {
	println()
	for i := 0; i < 10; i++ {
		defer func() {
			print(i)
			print(" ")
		}()
	}
}

// 预计是 10,10,10,10 拿到的是最后一个

func DeferClosureLoopV2() {
	println()
	for i := 0; i < 10; i++ {
		defer func(val int) {
			print(val)
			print(" ")
		}(i)
	}
}

// 预计是 1,2,3... 10
// 实际是 9,8 ,7 ,6 ,5,4,3,2,1

func DeferClosureLoopV3() {
	println()
	for i := 0; i < 10; i++ {
		j := i
		defer func() {
			print(j)
			print(" ")
		}()
	}
}

// 预计是 10，10，10 ？
// 实际上是 9,8,7,6,5,4,3,2,1

基本数据结构

切片

语法 []type ,数组的话是 [int]type

初始化方式 :

`1`	`s1 := []int{1,2,3} //创建了一个 3个亚孙的切片`

1
2

s1 := make([]int,3,4) // 初始化 3个元素，这时候访问 s1[0] = 0 
s2 := make([]int,4) // 创建一个 4个元素的切片， 这时候访问 s1[0] panic

推荐使用 s1 := make([]type,0,cap) 的方式进行创建

子切片

切片可以通过 [start:end] 的形式获取子切片，其中范围是 左闭右开 的

内存共享问题 :

在没有发生扩容的情况下，子切片和切片是共享一个数组的
即如果子切改变了一个数，那么原本的切片也会改变

map

初始化方法

1
2
3

m1 := map[string]string {
    "key": "value"
}

对于 for k,v := range map 来说，每次结果都是不一样的

接口 & 结构体

接口是 一组行为的抽象

type name interface{}

结构体

1
2
3

type a struct {

}

衍生类型

如果我们想使用第三方库，但是又没办法修改代码，又想扩展这个库的结构体，我们会使用到这个

衍生类型只共享字段并不共享实现的方法

即 typeB 拥有的方法 , typeA并不能够调用

`1`	`type typeA typeB`

类型别名

不同于衍生类型，可以说是一个别名类型本质上是没有变的

`1`	`type typeA = typeB`

泛型

对于下面这个例子，其中 T 就是泛型可以是任意类型

1
2

type List[T any] interface {
}

泛型语法

对于 Number 来说就是一个泛型约束

func Sum[T Number](vals ...T) T {
	var res T
	for _, val := range vals {
		res += val
	}
	return res
}

type Number interface {
	int | int64
}

面试重点

[✅] 什么是闭包？闭包有什么缺陷
[✅] 什么情况下会栈溢出
- 自己循环调用自己
[✅] 什么是不定参数？调用方法的时候不定参数可以传入 0个值吗？方法内部怎么使用不定参数？
- 函数参数以 … 方式进行传递就是不定参数
- 0值预计是个nil ,会自动初始化
- 和切片一样使用即可

什么是 defer ? 能解释一下 defer 的运行机制吗？
- Go 语言提供的一种延迟调用机制。它通常用于处理成对出现的操作，比如打开/关闭连接、加锁/释放锁。无论函数是正常执行结束还是发生了 panic，defer 注册的函数都会被确保执行，这能有效防止资源泄漏。

[已删除] 一个方法内部 defer 能不能超过 8个？
[待定] defer 内部能不能修改返回值? 怎么改？

数组和切片有什么区别？
- 类型与长度限制：
  - 数组是定长的，长度是其类型的一部分（[3]int 和 [4]int 是不同类型）
  - 切片是动态的，长度不属于类型的一部分（类型统称为 []T）
- 底层数据结构：
  - 数组是一段连续的内存空间，直接存储了所有的元素。
  - 切片本质上是一个引用类型（描述符），它的底层结构包含三个字段：一个指向底层数组的指针（Pointer）、切片的长度（Len）和容量（Cap）。
- 函数传参的性能开销:
  - Go 语言是值传递。如果把数组作为参数传递，会触发整个数组的深拷贝，对于大数组来说内存和 CPU 开销很大。
  - 传递切片时，只会拷贝切片头部的三个字段（指针、长度、容量），开销非常小。并且在函数内部修改切片的元素，会直接影响到底层的真实数组。
- 扩容机制：
  - 数组创建后不可扩容。切片支持使用 append 函数追加元素，当容量不足时，Go 运行时会自动分配一块更大的新内存，将旧数组的数据拷贝过去，并让切片的指针指向新数组。
切片怎么扩容？
- 在 256 以下进行双倍扩容
- 在 256 以上进行 (原容量 + 3 * 256) / 4 即 1.25倍的扩容

最后

了解函数式编程在在业务中的使用
了解内存泄漏，业务上的内存泄漏，排查方法，解决办法
了解垃圾回收的机制
了解 Option 模式
slice 的底层实现
map 的底层实现
defer 的实现原理和机制
闭包

写出一个泛型工具支持

切片的辅助方法 : 添加、删除、查找、求并集、交集、map reduce API
map 辅助方法
扩展 map 实现 : 接受任意类型的 HashMap, TreeMap, LinkedMap
List 实现 : LinkedList, ArraryList 和 SkipList
Set: 包括 HashSet 和 TreeSet, SortedSet
队列: 普通队列,优先队列
bean 操作操作辅助类 : 高性能高扩展的 bean copier机制
并发扩展工具 : 包括并发队列,并发阻塞队列,并发阻塞优先队列
协程池

闭包

Tue, 14 Jul 2026 00:00:00 +0000

基础概念

闭包 : 引用了自由变量的函数，即函数 + 引用环境

例子 :

func intSeq() func() int {

	i := 0
	return func() int {
		i++
		return i
	}
}

func main() {
	nextInt := intSeq()

	fmt.Println(nextInt())
	fmt.Println(nextInt())

	nextInt2 := intSeq()
	fmt.Println(nextInt2())
}

输出如下

1
2
3

1
2
1

我们发现，对于程序内定义的变量 i, 他被外部函数引用了。并且对于 nextInt 和 nextIn2 是两个不同的环境，他们拥有不同的 i

怎么理解这个过程 :

函数的局部变量是分配在栈上面的
但是闭包上的变量会逃逸到堆上

原理如下 :

对于一个以函数返回到形式的 Func，我们称为 FuncValue 其分配是在堆上
当我们通过其他变量进行接收的时候，会先去堆上找到该 FuncValue 的地址，由于闭包 Capture 了局部变量所以会在堆上额外分配一块地址

垃圾回收

以下是一些概念

逃逸 :

变量生命周期超出声明它的函数栈帧，编译器不得不把它放到堆上

GC回收 :

堆上对象在没人引用后，由 GC 回收；程序结束进程退出时也会一起释放

对于下面这种形式，因为 nextInt 已经输出完成了，虽然main函数没有退出，但是已经没有引用了，虽然产生了逃逸但是同样会被回收

func main(){
	nextInt := intSeq()
	fmt.Println(nextInt())
	fmt.Println(nextInt())

	nextInt2 := intSeq()
	fmt.Println(nextInt2())

	for {} // 卡住不让 main 退出
}

只有在循环内一直被引用，以及包级变量引用的时候才不会被回收。

1
2
3

for {
    _ = nextInt() // 循环里还在用 → 仍存活
}

var keep func() int // 包级变量

nextInt := intSeq()
fmt.Println(nextInt())
keep = nextInt       // 挂到全局 → 一直可达

for {}

包级变量理论上来说是和当前进程一起存活的。但是如果在引用期间，主动进行解引用同样也会被回收

var keep func() int

func main() {
	keep = intSeq()
	fmt.Println(keep())

	keep = nil        // 断掉引用
	runtime.GC()      // 演示用；生产里不必手动调

	for {}            // 之后闭包就可能已被回收
}

应用场景

隔离数据

如果不想让其他人访问该数据,例如生成一个斐波那契数列，但是不想让其他人更改其 value

func main() {
  gen := makeFibGen()
  for i := 0; i < 10; i++ {
    fmt.Println(gen())
  }
}

func makeFibGen() func() int {
  f1 := 0
  f2 := 1
  return func() int {
    f2, f1 = (f1 + f2), f2
    return f1
  }
}

封装函数和创建中间件

Go 的函数是一等公民，如果我们想要实现一个，接口在运行前后的请求耗时中间件的话

我们需要使用到闭包进行处理，因为 handleFunc 需要接受一个 FuncValue

func main() {
  http.HandleFunc("/hello", timed(hello))
  http.ListenAndServe(":3000", nil)
}

func timed(f func(http.ResponseWriter, *http.Request)) func(http.ResponseWriter, *http.Request) {
  return func(w http.ResponseWriter, r *http.Request) {
    start := time.Now()
    f(w, r)
    end := time.Now()
    fmt.Println("The request took", end.Sub(start))
  }
}

func hello(w http.ResponseWriter, r *http.Request) {
  fmt.Fprintln(w, "<h1>Hello!</h1>")
}

不过这并不会产生 OOM ，因为端口一直监听，但是堆上的逃逸只产生了一次

同理可以分析下面这两个情况，对于第一个场景，我们只产生了一个新的环境，而对于第二个场景我们每次都产生了新环境

nextInt := intSeq()
for {
	nextInt()
} 

for {
	nextInt := intSeq() // 每次新环境
	_ = nextInt
	// 若再塞进全局 cache / 切片 → 环境越堆越多 → 可能 OOM
}

sort 包

people := []string{"Alice", "Bob", "Dave"}
sort.Slice(people, func(i, j int) bool {
    return len(people[i]) < len(people[j])
} )
fmt.Println(people)

面试

什么是闭包？闭包有什么缺陷？

闭包的本质是引用了自由变量的函数，即函数+引用环境是闭包

闭包有什么缺陷 : 在我们反复使用新环境引用闭包变量的时候，会产生大量的内存逃逸从而使得CPU上涨和OOM

闭包的优点 :

可以规避一些函数定义的接收器不允许传入的参数, 例如中间件只允许传入 Write 和Request .但是我们如果想要引用其他 Param，那么就需要定义一个 FuncValue的返回， func(otherParm) FuncValue
做数据的隔离防止一些不想让其他人访问该数据。例如 Sort

🛠️ 改进项与“满分回答”建议 (Improvements)
为了在面试中拿到 9-10 分，你可以将回答按照“定义 -> 常见应用(优点) -> 底层代价(缺陷) -> 语言特有陷阱”的逻辑来组织。

你可以参考以下改进后的表述：

1. 什么是闭包？（保持你的精准定义）
闭包的本质是函数体加上它所引用的外部环境（自由变量）的结合体。在 Go 中，当一个匿名函数引用了它外部作用域的变量时，就形成了闭包。

2. 闭包的优点（优化你的实战案例）
函数签名适配与状态保持（柯里化）：在 Web 开发中，标准库的 http.HandlerFunc 只接受 ResponseWriter 和 Request。我们可以利用闭包将外部配置（如 DB 连接池、日志记录器）封装进去，返回一个符合签名的函数。

数据封装与隔离：闭包可以用来隐藏状态，实现类似面向对象中“私有变量”的效果。比如实现一个计数器生成器，每次调用返回的函数都能修改外层的局部变量，而这个变量对全局是不可见的。同时，在使用 sort.Slice 时，闭包能直接捕获并操作外部的切片，免去了繁琐的参数传递。

3. 闭包的缺陷与坑（重点重构）
性能代价（内存逃逸与 GC 压力）：
闭包引用的外部变量，其生命周期会超越原本的函数调用栈。因此，Go 编译器会通过逃逸分析将这些变量分配到堆上，而不是栈上。如果高频创建闭包，会导致堆内存分配增多，加重 GC（垃圾回收）的负担，进而可能引发 CPU 占用率上升。

经典陷阱：循环变量捕获问题：
(重点展示你的技术深度和对 Go 版本更迭的了解)
在 Go 1.22 之前，for 循环中的迭代变量是共享同一个内存地址的。如果在循环里启动 Goroutine 并使用闭包引用该变量，往往会导致所有 Goroutine 最终打印的都是最后一个元素的值。
补充加分项：不过，自 Go 1.22 起，官方已经修改了 for 循环的语义，每次迭代都会创建一个新的变量，从而从根本上解决了这个经典的闭包陷阱。

面试官点评：如果你能在面试中流利地按照上述逻辑回答，不仅展现了你扎实的理论功底和实战经验，还顺带秀了一把底层（逃逸分析、GC）原理，以及对 Go 语言最新版本（1.22+）演进的关注。这绝对是一个一锤定音的高分回答！

其他

多协程快排的实现闭包

[Acwing] 基础算法(八) 堆

Mon, 13 Jul 2026 00:00:00 +0000

Heap

算法思路

我们使用一维数组来表示一个堆,堆的性质是一个完全二叉树，其中根是最小值，左右节点均小于父节点

我们使用 x表示根节点，则 2*x表示左节点 , 2*x+1 表示右节点

考虑

插入一个数
删除最小值
求最小值

对于插入一个数 :

因为是使用一维数组进行存储的，所以插入的数会在末尾，我们需要考虑进行 up 操作，将其和其父节点进行比较，如果比父节点小那么交换

void up(int u ) {
    while(u/2 && h[u/2] > h[u]) {
        heap_swap(u/2,u);
        u /= 2 ;
    }
}

对于删除最小值

因为最小值在 h[1] 所以考虑删除的时候，应该交换h[size] ，然后size-- 最后将 size 进行一次down操作

down操作也是很简单就能想到是和 左右节点进行比较 ,如果比左右节点大那么进行交换

代码

int n,m;
int h[N],sz ;

void down(int x) {
    int t = x;
    if(x * 2 <= sz && h[t] > h[x * 2]) t = x * 2;
    if(x * 2 + 1 <= sz && h[t] > h[x*2 + 1] ) t = x*2+ 1;
    if(h[x] != h[t]) {
        swap(h[x],h[t]);
        down(t);
    }
}

int main() {
  ios::sync_with_stdio(false);
  cin.tie(nullptr);

  cin>>n>>m;
  for(int i = 1; i <= n ; i ++ ) cin>>h[i];
  sz = n ;
  for(int i = n/2; i ; i -- ) down(i);
  while(m -- ) {
    cout<<h[sz]<<" ";
    h[1] = h[sz];
    sz -- ;
    down(1);
  }
  return 0;
}

时间复杂度分析

建树的时候是 o(n) 的遍历树的时候是 ologn

模拟堆

在普通堆的基础上增加了

删除第 k 个数
修改第 k 个数

对于删除第 k 个数

我们需要考虑存储 , 第k个数对应在 heap中的下标是什么即 ph[k]
同时因为涉及到交换，我们需要在 o(1) 的时间复杂度知道堆下标i = 2*x? 2*x+1 上堆元素，是第几次插入的 hp

因为如果不知道 hp 元素

我们在交换的时候会遇到

原来：第 m 次插入在位置 a  →  ph[m] = a
      第 n 次插入在位置 b  →  ph[n] = b

交换后：第 m 次插入到了 b  →  ph[m] = b
        第 n 次插入到了 a  →  ph[n] = a

这种奇异的问题，原本第m次插入的a 变成了第n次插入的

除非我们进行 oN 的处理

// 没有 hp 时，每次 swap 都要扫一遍
for (int k = 1; k <= m; k++)
    if (ph[k] == a) ph[k] = b;
    else if (ph[k] == b) ph[k] = a;

但是我们如果引入了 hp 后只需要进行更换即可

void heap_swap(int a, int b)
{
    swap(ph[hp[a]], ph[hp[b]]);  // ph[hp[a]]=a, ph[hp[b]]=b → 交换后变成 b 和 a
    swap(hp[a], hp[b]);
    swap(h[a], h[b]);
}

代码


int n,m;
int h[N],sz , hp[N], ph[N];

void heap_swap(int a,int b)  {
    swap(h[a],h[b]);
    swap(ph[hp[a]], ph[hp[b]]);
    swap(hp[a],hp[b]);
}

void down(int x) {
    int t = x;
    if(x * 2 <= sz && h[t] > h[x * 2]) t = x * 2;
    if(x * 2 + 1 <= sz && h[t] > h[x*2 + 1] + 1) t = x*2+ 1;
    if(x != t) {
       heap_swap(x,t);
    }
    down(t);
}

void up(int u ) {
    while(u/2 && h[u/2] > h[u]) {
        heap_swap(u/2,u);
        u /= 2 ;
    }
}

int main() {
  ios::sync_with_stdio(false);
  cin.tie(nullptr);

  int n;cin>>n;
  while(n -- ) {
    string op;cin>>op;
    if(op == "I") {
        int x;cin>>x;
        h[++sz] = x ;
        m ++ ;

        ph[m] = sz ;
        hp[sz] = m ;

        up(sz);
    }else if(op == "PM") {
        cout<<h[1]<<endl;
    }else if(op == "DM") {
        heap_swap(1,sz);
        sz -- ;
        down(1);
    }else if(op == "D") {
        int k;cin>>k;
        k = ph[k];
        heap_swap(k,sz);
        sz -- ;
        up(k);
        down(k);
    }else {
        int k,x;cin>>k>>x;
        k = ph[k];
        h[k] = x;
        up(k);
        down(k);
    }
  }
  return 0;
}

一些感想

好难，说实话涉及到一些指针的来回跳动就完全不会了

[Acwing] 基础算法(七) Tire 树

Sun, 12 Jul 2026 00:00:00 +0000

Tire

算法思路

解决问题 :

解决单词统计类型的问题，或者是说有多少 prefix 是以当前字符串为前缀的串

算法思路：

由于这种题目出现会控制单词长度，所以我们考虑开一个 [N][26] 树用于存储

对于一个单词，相当于一个单边树
对于 abc ,abcd 树会在 c 处进行分叉
每个节点单独赋值 idx
对于访问一个字符串我们可以从根节点开始访问，对于其子串可以使用 p = tire[p][u] 的形式进行递归访问

代码展示


int son[N][26], n, idx ; 
int cnt[N];
char str[N];

void insert(char str[]) {
    int p = 0 ;
    for(int i = 0 ; str[i] ; i ++ ) {
        int u = str[i] - 'a';
        if(!son[p][u]) son[p][u] = ++idx ; 
        p = son[p][u];
    }
    cnt[p] ++ ;
}

int query(char str[]) {
    int p = 0 ;
    for(int i = 0 ; str[i] ; i ++ ) {
        int u = str[i] - 'a';
        if(!son[p][u]) return 0;
        p = son[p][u];
    }
    return cnt[p];
}

int main() {
  cin>>n ;
  while(n -- ) {
    char op[2];
    scanf("%s%s", op, str);
    if (*op == 'I') insert(str);
    else cout<<query(str)<<endl;
  }
}

[Acwing] 基础算法（七) 并查集

Sun, 12 Jul 2026 00:00:00 +0000

并查集

算法思路

使用场景

将两个集合进行合并
询问两个元素是否在一个集合中

我们很简单的可以想到判断两个元素是否在一个集合中可以使用map进行 o1 的判断，但是对于合并集合无法避免是 o(n) 的

因此我们考虑使用树的形式存储集合

对于一个集合，其根节点代表整个集合编号
使用 p[x] 表示其父节点

对于一个单边集合

`1`	`1 → 2 → 3 → 4`

我们如果要找到 1 的集合，那么需要从 p[1],p[2],p[3]一直寻找

但是我们可以考虑进行优化，对于找到根节点的集合，我们将其全部转移到根节点，即路径压缩

1
2
3

1 ──┐
2 ──┼──→ 4
3 ──┘

代码

其中 p[x] = find(p[x]) 代表路径压缩

int p[N] ;

int find(int x) {
    if(p[x]!= x) {
        return p[x] = find(p[x]);
    }
    return p[x];
}

int main() {
  ios::sync_with_stdio(false);
  cin.tie(nullptr);

  int n,m;cin>>n>>m;
  for(int  i = 1 ; i <= n ; i ++ ) {
     p[i] = i ;
  }
  for(int i = 1 ; i <= m ; i ++ ) {
    char op;cin>>op ;
    int a,b;cin>>a>>b;
    int fa = find(a);
    int fb = find(b);
    if(op == 'M') {
        p[fa] = fb;
    }else if(op == 'Q') {
        if (fa == fb) {
            cout<<"Yes"<<endl;
        }else {
            cout<<"No"<<endl;
        }
    }
  }
}

2026-07-12 不定时复盘

Sun, 12 Jul 2026 00:00:00 +0000

写在前头 :

最近生活没有了特别明确的目标，活着确实有点不自在

反差

离职的时候写了2-3篇文章说是已经规划好了，但是实际只是简单算了一下故事点和整合内容

实际任务编排并没有特别有规划或者是目的的进行

当然并不是说我没有做，我确实是做了，我在整理完之后就开始寻找能够平替飞书甘特图的内容

毕竟之前上班都是用的那个，每天上班无非就是打开甘特图，打开backlog 看一下要做什么昨天有什么没做的，都是安排好的

我记得我找了好久，最后使用石墨文档的甘特图，然后排了这两周的任务，但是实际排完之后第二天就没运行了

我排了两个3个任务

完成 Acwing AI Chat 项目
- 周一做完XXX模块
- 周二做完XXX模块
算法学习项目
- 周一学XXX算法
- 周二学XXX算法
Tidy 任务
- 整理个人todo
- 整理公司todo
- 整理规划这几个月发展
- 整理个人业务闪光点

但是最终没运行

我的一天

昨天因为要吃一顿散伙饭所以没有特地记录，今天的话可以说是可以好好记录一下

今天早上 10:00 左右起床的，不过9:00就起来了，昨天在玩堆叠大陆，买了2个DLC，然后熬了会夜看攻略

今天早上起来还在看大概看到了 10:00 然后起床洗漱

然后开始玩游戏玩到了中午12:30 开始吃饭，点的外卖不想自己做饭

然后吃完饭后，看了会抖音大概看到了 13:30. 然后好像就去看电视剧去了大概看了2个小时看到了 15:30

然后开始打开百度云看一个《golang训练营从0到1》总共28周，我预计是想要一天学一周的内容，这样子可以控制在一个月内学完，但是因为昨天耽搁了，所以今天在赶昨天的进度

现在还是很简单的内容今天主要学习了

项目结构
普通的登陆和注册
错误的基本处理
数据库的连接
session 和 cookie
以及密码加密什么的

都是一些大学阶段就应该掌握的内容，我现在2年后又重新掌握一遍，但是我并没有把我的commit推送，我甚至没有把这个项目当作我的仓库项目，只是放在那里

也就是说需要更新到我简历的项目目前还没有开始写

然后18:30左右开始做饭，今天正常无氧 20分钟

然后吃饭，吃完饭后洗澡，打游戏，刷抖音。大概好像就到了21:00左右了

出门跑步，跑了半个小时，最近拉肚子，跑步跑的不是很得劲，然后走了1.5公里回去，大概 22:10左右回到家

然后洗澡，再清一会游戏体力

大概到了23:00开始学习算法，学了预计半小时吧还是40分钟

学完之后补一下 commit 和 blog 然后开始写这篇随便总结的文章

下一步

下一周其实还有一些公司的活需要干，例如写交接文档，完成todo

但是我的心思已经不在公司那边了

随便写点

说实话我原本预计一天学习8小时的，这样子可以在一个半月内追完进度

但是实际今天只学习了4个小时，也就是说在buffer范围内，我需要花费 3个月的时间才行，这很显然对我来说不是很乐观

随便写点，或许明天有空会继续补内容，因为正好 0:00 了我要上床了，这是习惯

[Acwing] 基础算法(六) 数据结构栈&队列

Sat, 11 Jul 2026 00:00:00 +0000

栈

算法思路

我们使用 stk[N],tt 表示栈数组和栈顶指针

对于插入操作 stk[++tt] = x 即可

对于查询是否为空的操作判断 tt != 0 即可

对于删除操作 tt-- 即可

比较简单的一个模拟

待会中午约了散伙饭先收拾去了~

代码

bool checkEmpty() {
    return (tt == 0); 
}

void push(int x) {
    stk[++tt] = x; 
}

int pop() {
    int x = stk[tt];
    tt -- ;
    return x; 
}

int query() {
    return stk[tt];
}

int main() {
    int m; cin>>m ;
    while(m -- ) {
        string op;cin>>op;
        if(op == "push") {
            int x;cin>>x;
            push(x);
        }else if (op == "pop")  {
            pop();
        }else if(op == "empty") {
            if (checkEmpty()) {
                cout<<"YES"<<endl;
            }else {
                cout<<"NO"<<endl;
            }
        }else if(op == "query") {
            cout<<query()<<endl;
        }
    }
    return 0;
}

队列

算法思路

我们通过 hh,tt 表示队头和队尾, 维护一段连续区间

对于弹出操作，我们使用 hh++

对于插入操作, 我们使用 q[++tt]=x

对于查询是否为空的操作，我们使用 hh<=tt

代码

int q[N];

int tt,hh;

void init() {
    tt = -1;
}

bool empty() {
    return (hh <= tt);
}

void add(int x) {
    q[++tt] = x;
}

void pop() {
    hh ++ ;
}

int query() {
    return q[hh];
}


int main() {
    init();
    int m;cin>>m;
    while(m -- ) {
        string op;cin>>op;
        if(op == "push") {
            int x;cin>>x;
            add(x);
        }else if(op == "pop"){
            pop();
        }else if(op == "empty") {
            if(empty()) {
                cout<<"NO"<<endl;
            }else {
                cout<<"YES"<<endl;
            }
        }else if(op == "query") {
            cout<<query()<<endl;
        }
    }
    return 0;
}

单调栈

算法思路

顾名思义，我们维护的是一个 单调递增 or 单调递减 的一个内容

一般情况下我们会考虑一种提醒题型,即找到 当前数左边比自己小的数是什么

那么我们可以考虑维护一个 maxValue 是当前数的栈,对于大于自己的数都出栈，从而保证整个栈的值是递增的

代码

int main() {
    cin>>n;
    for(int i = 1; i <= n ;i ++ ) {
        int x;cin>>x;
        while(tt&&stk[tt] >= x) {
            tt -- ;
        }
        if(!tt) {
            cout<<-1<<" ";
        }else {
            cout<<stk[tt]<<" ";
        }
        stk[++tt] = x;
    }
    return 0;
}

时间复杂度分析

对于我们想要解决这个问题，暴力做法是 n^2 的

但是如果我们对于 a3>a5 的话，我们会发现我们永远用不到 a3 所以我们并不需要单独去遍历他，在最坏情况下也是 2n 的

单调队列

算法思路

同样以 滑动窗口举例 ,我们需要快速的求出一个固定窗口的最大最小值

我们对于 [1 3 -1 -3 5 3 6 7] 这个窗口,在[3,-1,-3] 窗口大小为 3 的时候，我们可以发现，其实-3是最小值，其中3,-1都没有用，因为后面的序列也用不到

所以我们可以维护一个最小值的窗口

考虑

当队头超出窗口那么移出队头
当队内元素大于当前数，那么移除当前元素。因为我们维护的是一个从小到大的序列，所以这里从队尾开始删除
然后把当前数插入进去
并且窗口有输出的时候进行输出

代码

int main() {
    cin>>n>>k;
    int hh = 0 ,tt = -1;
    for(int i = 1 ; i <= n ; i ++ ) cin>>a[i];
    for(int i = 1; i <= n ; i ++ ) {
        if(hh <= tt && i - k  >= q[hh]) hh ++ ;
        while(hh <= tt && a[q[tt]] >= a[i]) tt -- ; // 5 6 2
        q[++tt] = i ;
        if(i-k >= 0) cout<<a[q[hh]]<<" "; 
    }
    hh = 0, tt = -1;
    cout<<endl;

    for(int i = 1; i <= n ; i ++ ) {
        if(hh <= tt && i - k  >= q[hh]) hh ++ ;
        while(hh <= tt && a[q[tt]] <= a[i]) tt -- ; // 5 6 2
        q[++tt] = i ;
        if(i-k >= 0) cout<<a[q[hh]]<<" "; 
    }
}

[Acwing] 基础算法（五) 数据结构链表

Fri, 10 Jul 2026 00:00:00 +0000

链表

单链表

算法思路

我们使用

head 存储头节点

e[i] 存储下标 i 节点的值

ne[i] 表示 i 的后继节点在哪

idx 表示当前点位

对于插入头部的操作

e[idx] = x, ne[idx] = head, head = idx++;

中间插入的操作

e[idx] = x, ne[idx] = ne[k], ne[k] = idx++;

删除的操作

ne[k] = ne[ne[k]];

下面是一个演示过程 :

头插入

1
2
3

H 1:  e[0]=1, ne[0]=-1, head=0        → 链表: 1
H 2:  e[1]=2, ne[1]=0,  head=1        → 链表: 2 → 1
H 3:  e[2]=3, ne[2]=1,  head=2        → 链表: 3 → 2 → 1

调用 Insert 3 5 在第三个数后面插入5

1
2
3

e[3] = 5
ne[3] = ne[2] = 1    // 新节点先接上原来的后继
ne[2] = 3            // 节点 2 改指向新节点

调用 Insert 4 4

1
2
3

e[3] = 5
ne[3] = ne[2] = 1    // 新节点先接上原来的后继
ne[2] = 3            // 节点 2 改指向新节点

最终情况

逻辑链表:  head
              ↓
         ┌────┐    ┌────┐    ┌────┐    ┌────┐    ┌────┐
         │ 3  │ →  │ 5  │ →  │ 4  │ →  │ 2  │ →  │ 1  │ → NULL
         └────┘    └────┘    └────┘    └────┘    └────┘
         下标2     下标3     下标4     下标1     下标0

数组状态:
  i:    0    1    2    3    4
 e[i]:  1    2    3    5    4
ne[i]: -1    0    3    4    1
              ↑    ↑    ↑
              │    │    └─ head=2
              │    └─ ne[2]=3 指向节点5
              └─ ne[4]=1 指向节点2

完整代码

#include <bits/stdc++.h>
#define LL long long
using namespace std;
const int N = 1e5+10;
 
int head, e[N], ne[N], idx ;

void init() {
    head = -1 ;
    idx = 0 ;
}


void add_to_head(int x) {
    e[idx] = x;
    ne[idx] = head ;
    head = idx ++ ;
}

void add(int k ,int x) {
    e[idx] = x ;
    ne[idx] = ne[k];
    ne[k] = idx ++ ; 
}
// 1 , ne[0] = -1
// 2 , ne[1] = 0
// 3 , ne[2] = 1

// 5 , ne[4] = ne[3-1] = 1 ; 3, 1 (ne[3] = 5)

// 4 , ne[3] = 2


void remove(int k) {
    ne[k] = ne[ne[k]];
}

int main() {
    int n;cin>>n;
    init();
    for(int i = 1 ; i<= n ; i ++ ) {
        char op ;cin >> op ;
        if (op == 'H') {
            int x;cin>>x;
            add_to_head(x);
        }else if (op == 'D') {
            int x;cin>>x;
            if (!x) head = ne[head]; 
            else remove(x-1);
        }else if (op == 'I') {
            int k,x;cin>>k>>x;
            add(k-1,x);
        }
    }

    for(int i = head ; i != -1 ; i = ne[i]) {
        cout<<e[i]<<" ";
    }

    return 0;
}

双链表

算法思路

我们假设 [0] [1] 代表我们的左右端点

初始化的时候 r[0] = 1 , l[1] = 0, idx = 2

对于插入操作

我们需要给当前节点赋值
并且使得当前节点的左右指针指向上下两个数
- l[idx] = k, r[idx] = r[k]
同时修改两个被影响的指针
- l[r[k]] = idx, r[k] = idx

这是插入右端点的思路，插入左端点可以认为是在前一个节点插入右端点即inser(l[k],x)

对于删除操作,我们需要把当前节点的上一个节点和下一个节点互相建立关系

将当前节点的左节点的右节点指向下一个节点
- r[l[k]] = r[k]
将当前节点的右节点的左节点指向上一个节点
- l[r[k]] = l[k]

另外需要注意的是，我们一开始就使用了两个节点所以对于操作的节点我们应该认为是 k+1

代码


int e[N],l[N],r[N],idx; 

void init() {
    r[0] = 1, l[1] = 0 ;
    idx = 2;
}

void add(int k,int x) {
    e[idx] = x;

    l[idx] = k ,r[idx] = r[k];

    l[r[k]] = idx, r[k] = idx;
    idx ++ ; 
}

void remove(int k) {
    l[r[k]] = l[k];
    r[l[k]] = r[k];
}

int main() {
    init() ;
    int n;cin>>n;
    for(int i = 1 ; i<= n ;i ++ ) {
        string op;cin>>op;
        if(op == "L") {
            int x;cin>>x;
            add(0,x);
        }else if(op == "R") {
            int x;cin>>x;
            add(l[1], x);
        }else if(op == "D") {
            int k;cin>>k;
            remove(k + 1);
        }else if(op == "IL") {
            int k,x;cin>>k>>x;
            add(l[k+1], x);
        }else {
            int k,x;cin>>k>>x;
            add(k+1,x);
        }
    }
    for(int i = r[0] ; i!= 1; i = r[i]) cout<<e[i]<<" ";
    return 0;
}