Webook-Detail on GzzhM

关注 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 又是什么？用来解决什么问题？

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 里面应该用推模型还是拉模型？
为什么大部分平台都是使用推和拉模型

用户关系 detail

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

简历 preview

搜索 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 的查询场景？

评论 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 批量提交
如果在自己业务里面，有明显的部分失败的场景，怎么补偿
怎么保证幂等？你有什么方案？能不能撑住高并发
- 唯一索引处理
- 二话不说先插入一个数据，保证坐在一个本地事务里面，如果有冲突那么就说明做过了
- 不拢过滤器去重

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

热榜 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

阅读、点赞、收藏 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类的算法制定生产者发送消息的分区

发帖服务 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 效果会差一些
优先淘汰大对象
优先淘汰小对象

高可用高扩展高安全的登陆与注册的设计 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 异步的发送出去

考虑布隆过滤器进行黑名单过滤