Gold on GzzhM

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+。

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

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
怎么在线上做灰度发布？
- 阈值+随机数

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

我做了什么

可以说, 我持续学习了一周半(今天是周三)

上周学习了 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()
}