Golang on Vincent's Blog

Kubernetes leader election 使用

Thu, 09 May 2024 20:20:45 +0800

租约（Lease）

Kubernetes 的 Lease 资源是一种轻量级的机制，用于在集群中的各个节点之间进行领导者选举或协调访问共享资源。它属于 coordination.k8s.io API 组，主要用于在多个客户端之间同步状态，确保只有一个客户端（或节点）在特定时间内承担某个任务或控制特定资源。

官方文档中提及的Lease用途包括

节点心跳：对于每个node都有对应的Lease资源，节点心跳定期更新Leasespec.renewTime 字段Kubernetes 控制平面使用此字段的时间戳来确定此 node 的可用性。
领导者选举：Lease 资源常用于 Kubernetes 控制平面组件的领导者选举，例如 kube-scheduler 或 kube-controller-manager。这些组件使用 Lease 来确保集群中只有一个活跃的领导者实例在执行任务。通过 Lease 机制，当当前领导者因为故障或其他原因失去活跃状态时，另一个实例可以接管成为新的领导者。
API 服务器身份：从 Kubernetes v1.26 开始，每个 kube-apiserver 都使用 Lease API 将其身份发布到系统中的其他位置。
工作负载：开发者可以定义自己使用的Lease，进而使用 Kubernetes API 进行多实例程序的协调。

Kubernetes资源并发控制

当两个客户端使用 Kubernetes API 同时尝试更新同一个资源对象时，Kubernetes API 服务器使用乐观锁机制来处理这种并发更新。这个机制确保了资源更新的一致性和完整性。

资源版本控制

每个 Kubernetes 资源都有一个 resourceVersion 字段，这是一个在每次资源被修改时自动递增的版本号。客户端在发送更新请求时会包括这个版本号。

乐观锁

Kubernetes 使用乐观锁来处理资源的并发更新。当一个客户端尝试更新资源时，它必须提供它所基于的资源的当前版本号。这个版本号随请求一起发送给 API 服务器。

更新处理流程

成功情况：如果提供的版本号与服务器上当前资源的版本号一致，API 服务器接受更新，应用更改，并将资源的版本号递增。
冲突情况：如果提供的版本号与服务器上的版本号不匹配（说明在客户端读取资源后和发送更新请求之间，资源已被另一个客户端更改），API 服务器将拒绝请求并返回一个冲突错误（ HTTP 409 Conflict）。这时，客户端通常需要重新获取最新的资源版本，重新应用其更改，并再次尝试更新。

leader election

client-go提供了leader election的简单示例。基本原理如下图：

多实例启动。
所有实例尝试获取到租期锁，但只有一个实例会成功获取锁，成为领导者。
领导者定时更新租期到期时间，同时其他实例定时轮询租期到期时间，若发现租期已到期则会发生领导权转移。

运行示例

程序的入参包括：

kubeconfig：集群kubeconfig文件路径
lease-lock-name：租赁锁名称
lease-lock-namespace：租赁锁所在的命名空间
id：程序实例的id，每个运行的程序都需要有唯一的id

go run main.go -kubeconfig=/path/to/kubeconfig -logtostderr=true -lease-lock-name=example -lease-lock-namespace=default -id=1
go run main.go -kubeconfig=/path/to/kubeconfig -logtostderr=true -lease-lock-name=example -lease-lock-namespace=default -id=2
go run main.go -kubeconfig=/path/to/kubeconfig -logtostderr=true -lease-lock-name=example -lease-lock-namespace=default -id=3

go run cmd/lead/main.go -kubeconfig=/Users/vincent/Documents/work/ai-poc.yaml -logtostderr=true -lease-lock-name=example -lease-lock-namespace=default -id=1
go run cmd/lead/main.go -kubeconfig=/Users/vincent/Documents/work/ai-poc.yaml -logtostderr=true -lease-lock-name=example -lease-lock-namespace=default -id=2
go run cmd/lead/main.go -kubeconfig=/Users/vincent/Documents/work/ai-poc.yaml -logtostderr=true -lease-lock-name=example -lease-lock-namespace=default -id=3

启动3个实例

相继执行命令，得到以下输出

# id=1
I0507 09:46:16.357422    3102 leaderelection.go:248] attempting to acquire leader lease default/example...
I0507 09:46:16.425337    3102 leaderelection.go:258] successfully acquired lease default/example
I0507 09:46:16.425443    3102 main.go:71] Controller loop...
# id=2
I0507 09:46:41.761138    3166 leaderelection.go:248] attempting to acquire leader lease default/example...
I0507 09:46:41.802702    3166 main.go:135] new leader elected: 1
# id=3
I0507 09:46:51.877957    3223 leaderelection.go:248] attempting to acquire leader lease default/example...
I0507 09:46:51.913119    3223 main.go:135] new leader elected: 1

可见id=1的实例当选领导者。此时我们在kubeconfig指定的集群里，执行kubectl get leases -n default example -oyaml 可以看到Lease对象被创建，并且在spec中包括了租期获取时间、到期时间、当前保存的id等信息。

apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
  creationTimestamp: "2024-05-07T01:46:16Z"
  name: example
  namespace: default
  resourceVersion: "2113597"
  uid: baad0d51-7676-4e7a-83fc-44241e7a8185
spec:
  acquireTime: "2024-05-07T01:46:16.357501Z"
  holderIdentity: "1"
  leaseDurationSeconds: 60
  leaseTransitions: 0
  renewTime: "2024-05-07T02:02:27.633970Z"

关闭主程序，触发领导权变更

# id=1
I0507 09:46:16.357422    3102 leaderelection.go:248] attempting to acquire leader lease default/example...
I0507 09:46:16.425337    3102 leaderelection.go:258] successfully acquired lease default/example
I0507 09:46:16.425443    3102 main.go:71] Controller loop...
# ---new---
^CI0507 10:05:03.735993    3102 main.go:88] Received termination, signaling shutdown
I0507 10:05:03.752979    3102 main.go:126] leader lost: 1

# id=2
I0507 09:46:41.761138    3166 leaderelection.go:248] attempting to acquire leader lease default/example...
I0507 09:46:41.802702    3166 main.go:135] new leader elected: 1
# ---new---
I0507 10:05:08.209963    3166 main.go:135] new leader elected: 3

# id=3
I0507 09:46:51.877957    3223 leaderelection.go:248] attempting to acquire leader lease default/example...
I0507 09:46:51.913119    3223 main.go:135] new leader elected: 1
# ---new---
I0507 10:05:07.193674    3223 leaderelection.go:258] successfully acquired lease default/example
I0507 10:05:07.194014    3223 main.go:71] Controller loop...

可以发现id=3的程序被选为了领导者，此时查看leases对象，发现holderIdentity已经变更为3，且leaseTransitions被加一。

apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
  creationTimestamp: "2024-05-07T01:46:16Z"
  name: example
  namespace: default
  resourceVersion: "2114958"
  uid: baad0d51-7676-4e7a-83fc-44241e7a8185
spec:
  acquireTime: "2024-05-07T02:05:07.154433Z"
  holderIdentity: "3"
  leaseDurationSeconds: 60
  leaseTransitions: 1
  renewTime: "2024-05-07T02:11:14.792591Z"

分析主程序

下面给出了程序的主流程，可以发现核心代码非常短小，对业务流程的侵入性也很小，只需要将业务逻辑放在LeaderCallbacks的函数中即可。流程如下：

初始化client-go
定义核心业务逻辑
定义LeaseLock
定义LeaderElectionConfig，并进入主流程

func main() {
    // ...折叠初始化
		// 通过kubeconfig获取client-go示例
    client := clientset.NewForConfigOrDie(config)
  	// 定义核心业务逻辑
    run := func(ctx context.Context) {
       klog.Info("Controller loop...")
       select {}
    }

    // 定义租约锁
    lock := &resourcelock.LeaseLock{
       LeaseMeta: metav1.ObjectMeta{
          Name:      leaseLockName,
          Namespace: leaseLockNamespace,
       },
       Client: client.CoordinationV1(),
       LockConfig: resourcelock.ResourceLockConfig{
          Identity: id,
       },
    }

    // 开始主循环
    leaderelection.RunOrDie(ctx, leaderelection.LeaderElectionConfig{
       Lock: lock,
       ReleaseOnCancel: true,
       LeaseDuration:   60 * time.Second,
       RenewDeadline:   15 * time.Second,
       RetryPeriod:     5 * time.Second,
       Callbacks: leaderelection.LeaderCallbacks{
          OnStartedLeading: func(ctx context.Context) {
             run(ctx)
          },
          OnStoppedLeading: func() {
             klog.Infof("leader lost: %s", id)
             os.Exit(0)
          },
          OnNewLeader: func(identity string) {
             if identity == id {
                return
             }
             klog.Infof("new leader elected: %s", identity)
          },
       },
    })
}

LeaseLock中定义了Lease的name和namespace、用于增删改查Lease的Client以及id

lock := &resourcelock.LeaseLock{
   LeaseMeta: metav1.ObjectMeta{
      Name:      leaseLockName,
      Namespace: leaseLockNamespace,
   },
   Client: client.CoordinationV1(),
   LockConfig: resourcelock.ResourceLockConfig{
      Identity: id,
   },
}

LeaderElectionConfig定义了选主配置，包括租赁锁、租期过期时间、回调函数等

leaderelection.LeaderElectionConfig{
	// 传入LeaseLock
   Lock: lock,
  // 是否在context被cancel时释放租赁锁
   ReleaseOnCancel: true,
  // 当候选者观察到领导者未及时更新租期时间时，强制获取领导权需要等待的时间
   LeaseDuration:   60 * time.Second,
  // 领导者重新声明领导权的持续时间
   RenewDeadline:   15 * time.Second,
  // 候选者重试周期
   RetryPeriod:     5 * time.Second,
   Callbacks: leaderelection.LeaderCallbacks{
     // 当选领导者时触发的回调
      OnStartedLeading: func(ctx context.Context) {
         run(ctx)
      },
     // 失去领导权时触发的回调
      OnStoppedLeading: func() {
         klog.Infof("leader lost: %s", id)
         os.Exit(0)
      },
     // 领导权变更时触发的回调
      OnNewLeader: func(identity string) {
         if identity == id {
            return
         }
         klog.Infof("new leader elected: %s", identity)
      },
   },
}

LeaderElector核心流程

程序启动，获取领导选举记录
根据记录中的内容做不同操作
- 若记录不存在或记录中的领导权已过期，则尝试获取领导权
- 若记录中的领导权归属于自身（通过id判断），则刷新领导权。否则，说明有一个leader持有领导权，在等待RetryPeriod后，重新尝试获取记录。
领导权成功转移/续期后
- 领导者：调用OnStart回调，执行业务逻辑，同时按照RetryPeriod的间隔，不间断地续期领导权
- 候选者：按照RetryPeriod的间隔，不断获取领导选举记录，查看领导权是否过期（说明领导者出现了某些意外，无法正常完成需求操作），若领导权过期，则尝试获取，进而成为领导者。

由于Kubernetes对资源有乐观锁的并发控制，如果同时有多个候选者试图获取锁，那么只有一个候选者会成功，其余候选者将返回失败并在等待RetryPeriod后重新获取领导权记录。

服务路由

若通过leader election的方式提高应用的可用性，则服务路由与常规的多实例应用不同，部分或全部请求只能被发送到leader。为了实现这样的流量控制需要一下额外的手段，比如利用Pod 就绪探针（Readiness Probe）、手动修改Service和Endpoint、应用间流量转发等

Pod就绪探针

就绪探针文档

Kubernetes只会将处于ready状态的pod加入到endpoint列表，并将对service的流量转发到列表中的pod。因此我们可以在程序中配置就绪探针，并且仅当获取领导权后才上报程序处于ready状态。这样流量只会被转发到leader。

优点
- 简单，易于实现，只需要提供一个简单http接口
缺点
- 无法正常进行deployment的滚动更新

手动修改Service和Endpoint

没有选择算符的 Service

使用没有选择算符的 Service 我们可以手动操作Service对应的endpoint，进而控制流量只被转发到leader。每当一个候选者获取领导权变为领导者时，需要修改EndpointSlice中的ip地址为自身的地址。

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  ports:
  - name: http
    nodePort: 32088
    port: 8000
    protocol: TCP
    targetPort: http
---
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: my-service-1
  labels:
    kubernetes.io/service-name: my-service
addressType: IPv4
ports:
  - name: 'http' # 应与上面定义的服务端口的名称匹配
    appProtocol: http
    protocol: TCP
    port: 8000
endpoints:
  - addresses:
      - "192.168.127.152"

优点：
- 灵活，可以同时存在一个普通service和一个没有选择算符的 Service，实现全部实例可读，仅leader可写的效果
缺点：
- 就绪探针失效，无论pod是否ready，流量都将被转发到EndpointSlice指定的地址

应用间流量转发

对于请求量较小、请求体不大、不需要持久化连接（如websocket）的情况下，可以考虑直接将leader才能处理的请求从其他实例转发到leader。我们可以将pod的ip作为lease中的holderIdentity，其他实例感知到leader变更后，可以直接通过id来确定leader id。或者使用statefulset的形式部署应用，使用statefulsets稳定的dns名称确定leader的地址。

优点：
- 灵活，同样可以实现全部实例可读，仅leader可写的效果
- 对客户端来说，无感知应用内部架构
缺点：
- 对业务代码入侵较大

总结

我们首先介绍了client-go leader election所依赖的Lease资源和Kubernetes乐观锁机制。

Lease资源：一种用于领导者选举或协调访问集群共享资源的资源对象
Kubernetes乐观锁机制：通过资源版本号来控制并发更新，确保在资源被修改期间数据不会因并发操作而产生冲突。

client-go提供的 leader election使候选者不断轮询领导权记录，领导者不断续期领导权来维持心跳，进而维持领导者权限归属。领导权记录可以借助lease、configmap或endpoint资源对象。

参考

k8s-await-election：client-go leader election的封装
kubernetes简单的leader election：提供leader election镜像，以sidecar的形式完成选主逻辑，对业务逻辑侵入小，并且不依赖于主应用语言。

xclipboard 剪切板同步工具

Sat, 16 Jul 2022 10:58:38 +0800

对于

在nat网关下的2台设备，如何相互传输数据？最常见的方法就是就是使用一个中继服务器，例如frp。

syncthing是一个文件同步

方法

在这篇文章中，已经说明了为什么使用syncthing公开中继服务器传输数据，不在赘述

发现协议

在syncthing中，分别使用了全局发现协议和本地发现协议，我们仅实现其中的发现协议，实现代码参考syncthing源码

协议详情链接

中继协议

中继协议

秒杀微服务设计

Tue, 07 Jun 2022 17:20:45 +0800

微服务架构设计

微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的 API 进行通信的小型独立服务组成。这些服务可以由各个小型独立团队负责。微服务架构使应用程序更易于扩展和更快地开发。 —AWS

系统一共使用了如下5个微服务，相互直接通过grpc直接通信，或通过中间件间接传递数据。

用户(user)
- 登录
- 注册
- 刷新token
秒杀(spike)
- 获取秒杀token
- 秒杀
  - 与准入服务通信，确认用户是否有资格参与活动
  - 将订单减扣的消息发送到消息队列
准入(access)
- 对指定的秒杀，根据灵活的规则配置来判断用户是否有资格参与活动
管理(admin)
- 管理秒杀活动(CRUD)
订单(order)
- 查询订单
- 付款或取消订单
- 接收消息队列的消息，生成订单插入数据库

使用的中间件

Mysql 数据库
Redis 缓存
Rabbitmq 消息队列

用户正常秒杀流程

登录，获取jwt token，token中保存用户id，后续请求需要携带token
通过前端页面点击秒杀预览，后端验证用户参入资格，准入则进入活动详情页
到达秒杀预设时间，点击秒杀按钮，前端发起两个请求
1. 获取秒杀活动的随机token
2. 使用token访问后端秒杀接口
若抢到，则前端轮询等待订单生成（因为订单生成是异步的）

并发优化

多级缓存

秒杀系统是一个典型的读多写少应用，1万个人抢100个商品，最后可以做的写操作只有100次，而读取可能几倍于用户数。所以使用缓存可以极大提升系统并发性能

执行环境本地缓存

使用了go-cache库，和go本身提供的map相比，它提供了过期时间和并发安全的特性。

准入服务中，缓存了被构建的过滤器，这样在流量高峰到来时不需要重复构建过滤器

filterCache = cache.New(5*time.Minute, 10*time.Minute)
filterCache.Set(req.SpikeId, ft, cache.DefaultExpiration)
f, isFound := filterCache.Get(req.SpikeId)

在秒杀服务中，缓存了秒杀url随机token，而不需要每次都到redis获取，减轻redis压力，并减少网络消耗，加快处理时间
```
spikeUtilCache = cache.New(10*time.Minute, 20*time.Minute)
type spikeUtil struct {
	token   string
	limiter *rate.Limiter
}
```

redis缓存

在准入服务当中，将准入服务的结果缓存到redis，基于以下两点：
- 准入结果在短时间内不会变化
- 对于某个用户，在短时间内可能多次使用到准入服务，(如反复进入秒杀界面，多次点击秒杀按钮)
```
redisx.SetAccess(ctx, redisId, map[string]string{"result": strconv.FormatBool(res), "reason": reason}, time.Second*30)
```
在秒杀服务中缓存秒杀url随机token，若未在本地成功获取到token则在redis中获取
```
randStr, err = redisx.Get(c, redisx.RandKey+spikeId)
```

CDN缓存

未实现

前端文件大多是静态文件，可以将其放置在云服务提供商提供的CDN服务上，来减轻流量高峰期的服务器压力，减少带宽压力，加快用户页面加载速度

多级流量过滤

对于秒杀服务来说，大多数请求最终都是失败的，要尽早抛弃，以减轻后端压力

令牌桶(本地环境)

对于每次秒杀活动，都会在每个秒杀服务实例本地环境创建一个令牌桶

su := &spikeUtil{
			token:   "",
			limiter: rate.NewLimiter(defaultLimit, defaultMaxRequestNum),
		}

对于超出库存量2倍的请求，直接返回503

库存判断(redis)

成功进入秒杀接口的请求，会首先进行库存的判断，不足则直接返回

if getRestStock(c, spikeId) <= 0 {
    c.JSON(200, gin.H{"status": "fail", "msg": "sold out"})
    return
}

准入判断(db/redis)

调用准入服务rpc，对不准入的用户请求进行拦截

accessible, err := client.IsAccessible(c, &access.AccessReq{
    UserId:  user.ID,
    SpikeId: spikeId,
})
if !accessible.Result {
    c.JSON(403, gin.H{"error": "no access: " + accessible.Reason})
    return
}

订单判断(db)
```
res, err := db.InsertOrderAffair(order)
```
在插入订单时，会将订单是否已经存在的判断加入其中，组成一个事务

可以发现，请求过滤时，将代价越小的判断放置在了前面，这样充分利用了业务特性减轻服务器压力

redis分布式锁

在此设计当中许多微服务之间的通信/同步都是由中间件来完成的，redis作为一个单线程的应用(暂不考虑集群部署的情况)，天生没有并发问题

秒杀url随机token

由于改token是lazy load的，需要第一个拿到锁的协程进行初始化
```
ok, err := redisx.SetNX(c, redisx.RandKey+s.ID, randStr, s.EndTime.Sub(time.Now()))
```
使用了redis的SetNX功能，当key不存在时，写入值，否则失败

库存初始化

与token初始化同理

ok, err := redisx.SetNX(ctx, redisx.SpikeStoreKey+spikeId, numStr, s.EndTime.Sub(time.Now()))

加减预扣库存lua脚本

if (redis.call('exists', KEYS[1]) == 1) then
    local stock = redis.call('get', KEYS[1]);
    if (stock - KEYS[2] >= 0) then
        local leftStock = redis.call('DecrBy', KEYS[1], KEYS[2]);
        return leftStock;
    end;
    return -1;
end;
return -1;

redis支持lua脚本，lua脚本中的命令将被视为一个整体运行，所以我们可以将其看作一个简单的事务

如此保证了数据访问的互斥性，不会出现超卖

消息队列

秒杀系统的典型特征之一就是短时间的瞬时流量，会导致数据库访问压力骤增，为此，我们使用了rabbitmq消息队列，来让这些流量平滑流到数据库中，起到削峰填谷的作用，异步化用户请求

// 生产者
err = sender.Publish(&order.OrderInfo{
    UserId:   user.ID,
    SpikeId:  spikeId,
    Quantity: 1,
})

// 消费者
func dealMqOrder(ch <-chan *order.OrderInfo) {
	go func() {
		for info := range ch {
			// 判断订单是否存在
			o := &orm.Order{
				UserID:     info.UserId,
				SpikeID:    info.SpikeId,
				Quantity:   int(info.Quantity),
				State:      orm.OrderOrdered,
				CreateTime: time.Now(),
			}
			res, err := db.InsertOrderAffair(o)
			log.Println("success create id: " + o.ID)
		}
	}()
}

singleflight

在初始化库存或者随机url token时，都需要访问数据库获取spike数据，因为此时redis为空，在并发的流量下，会导致众多的请求打到数据库(缓存击穿)导致数据库崩溃，而且从逻辑上考虑，每个请求访问的其实是相同的数据，完全可以做到复用请求的结果。因此使用singleflight

spike, err := loader.Do(spikeId, func() (interface{}, error) {
    spike, err := db.GetSpikeById(spikeId)
    if err != nil {
        return nil, err
    }
    return spike, nil
})

构建&部署

kubernetes & helm 部署

kubernets

Kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。 —k8s中文社区

我们的微服务完全运行在容器化的环境中，核心程序都被部署到k8s中，中间件(mysql、redis、rabbitmq)不在k8s中运行(但在docker中)

容器化的环境抹平不同操作系统、硬件架构上的差异，让应用可以轻松运行。

k8s提供了重要的服务发现、负载均衡、流量转发等功能。

由于没有多台机器运行一个标准的Kubernetes，我们使用了更为轻量的k3s(一个符合Kubernetes标准的发行版)

kubernets 安装

只需要一行命令即可启动一个单节点的k3s

curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn sh -

再安装一些辅助工具

snap install kubectl --classic
snap install helm --classic

helm

Helm 帮助您管理 Kubernetes 应用—— Helm Chart，即使是最复杂的 Kubernetes 应用程序，都可以帮助您定义，安装和升级。

—helm官网

如果将k8s看作一个操作系统(如ubuntu)，那么helm可以看成这个操作系统的包管理器(如ubuntu的apt)。helm可以帮助定义、部署、升级一个k8s应用，还提供了诸如金丝雀发布这样的高级功能

helm chart中使用了

5个deployment，分别对应5个微服务
5个service，分别对应5个deployment
1个statefulset，启动了1个nginx，让用户可以访问前端文件
1个configmap，为服务提供配置文件，并且支持热更新
ingress，提供路由转发和负载均衡功能，将用户的请求，通过路径区别分发到对应的微服务
- k3s默认使用traefik，提供了轮询负载均衡

在value.yaml中，只要定义好微服务的镜像启动命令和参数，已经服务端口，即可创建对应的deployment、service

microservices:
  - name: access-service
    replicaCount: 1
    image: registry.cn-qingdao.aliyuncs.com/adpc/spike-access-service:latest
    command:
      - /access-service
      - --rpc-port=8081
      - --config-path=/configs/config.yaml
    service:
      - 8081
  - name: spike-service
    replicaCount: 2
    image: registry.cn-qingdao.aliyuncs.com/adpc/spike-spike-service:latest
    command:
      - /spike-service
      - --port=8080
      - --config-path=/configs/config.yaml
      - --access-endpoint=spike-access-service.default.svc:8081
    service:
      - 8080
# ...

在ingress中定义了host，已经路径、对应的服务和端口

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: spike-backend-ingress
  annotations:
    kubernetes.io/ingress.class: "traefik"
spec:
  rules:
    - host: spike.vinf.top
      http:
        paths:
          - path: /users
            pathType: Prefix
            backend:
              service:
                name: spike-user-service
                port:
                  number: 8080
          - path: /spike
            pathType: Prefix
            backend:
              service:
                name: spike-spike-service
                port:
                  number: 8080
# ...

将helm chart上传到服务器后，运行helm install即可部署

helm install spike spike-chart-latest.tar.gz

docker image 构建

FROM golang:1.17 as builder
WORKDIR /app
COPY go.mod ./
COPY go.sum ./
RUN go env -w  GOPROXY=https://goproxy.cn,direct
RUN go mod download

COPY cmd/ cmd/
COPY internal/ internal/
COPY pkg/ pkg/

RUN mkdir -p "bin" && \
    go build -o bin/access-service cmd/access/main.go && \
    go build -o bin/spike-service cmd/spike/main.go && \
    go build -o bin/user-service cmd/user/main.go && \
    go build -o bin/admin-service cmd/admin/main.go && \
    go build -o bin/order-service cmd/order/main.go
# access
FROM debian as access
WORKDIR /
COPY --from=builder /app/bin/access-service /
USER root
# ...

dockerfile中使用了golang:1.17作为第一层镜像，将go.mod复制到环境，并运行go mod download自动下载依赖
复制代码文件
运行go build
使用debian作为发布镜像，将编译后的可执行文件复制到debian镜像中，这样可以极大减小最终镜像的尺寸

为了方便，编写了一个简单的makefile，只需要运行如下命令就可以自动完成构建和上传镜像

make build_push

中间件部署

mysql

docker run -d --restart=always --name mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=<passwd> mysql

redis

写入/root/redis.conf

bind 0.0.0.0
daemonize NO
protected-mode no
requirepass <passwd>

docker run -d --restart=always --name redis -p 6379:6379 -v /root/redis.conf:/etc/redis/redis.conf -d redis /etc/redis/redis.conf

rabbitmq

docker run -d --restart=always --name rabbitmq -p 15672:15672 -p 5672:5672 -e RABBITMQ_DEFAULT_USER=<username> -e RABBITMQ_DEFAULT_PASS=<passwd> rabbitmq:management

简易的groupcache实现

Thu, 17 Mar 2022 19:18:58 +0800

缓存

缓存原理与作用

起初缓存(cache)指的是在cpu和内存之间放置一个更高速的储存器(但更小也更昂贵)，如果数据因之前的操作已经读取而被暂存其中，则下一次访问的开销会小很多。原理基于"程序执行与数据访问的局域性行为"，又分为

时间局部性，刚刚被访问的数据，有更大的概率被访问
空间局部性，在被访问数据附近的数据，更可能被访问

import "testing"

func TestI(t *testing.T) {
	var arr [10000][10000]int
	sum := 0
	for i := 0; i < len(arr); i++ {
		for j := 0; j < len(arr[0]); j++ {
			sum += arr[i][j]
		}
	}
}

func TestJ(t *testing.T) {
	var arr [10000][10000]int
	sum := 0
	for j := 0; j < len(arr[0]); j++ {
		for i := 0; i < len(arr); i++ {
			sum += arr[i][j]
		}
	}
}

测试结果：

=== RUN   TestI
--- PASS: TestI (0.04s)
=== RUN   TestJ
--- PASS: TestJ (0.40s)
PASS

故意使得局部性失效时，程序运行效率变慢了10倍，可见缓存对性能有着很大提升。

现如今，缓存的概念已经被扩展，不仅仅存在与cpu中。比如

硬盘和内存之间的缓存(硬盘缓存)
硬盘和网络之间也存在缓存关系(浏览器会缓存网络资源，比如图片)
DNS系统中，下级dns系统会缓存最近的查询，加速dns查询

groupcache被用来当作数据库/文件缓存。

缓存替换策略

wiki 缓存替换策略

缓存主要有2个质量因素：延迟和命中率。

为了提高命中率需要收集并维护更多的信息，而这会导致缓存的延迟增加，每个替换策略都是命中率和延迟之间的折中。

常见的缓存替换策略

随机替换 RR
先进先出 FIFO
最近最少使用 LRU
最少使用 LFU，与LRU不同，基于频率统计

缓存一致性

2个缓存中都持有内存数据的副本，当一个缓存中数据被更改，另一个却得不到通知，缓存不一致。

解决一致性的方法

写无效

当某处的缓存被更新时，所有其他位置的缓存均无效

写更新

当缓存更新时，一并更新所有缓存副本

缓存问题名词解释

缓存穿透

查询一个数据库和缓存均没有数据

缓存击穿

未缓存的数据短时间被高并发访问，导致大量请求穿透缓存层，直接打到数据库

缓存雪崩

大量数据在短时间内过期，大量请求落到数据库

Simple Groupcache

groupcache是一个用go编写的高效的缓存库，旨在在某些场景下代替memcached。

groupcache最大的特点是它不提供主动取消缓存的方法(也无法主动更新)。这样的设计使得它只适合静态资源的缓存，优点是简化了设计，提高了效率。

LRU缓存更新策略
热点数据多点缓存
未命中的缓存，加锁请求，防止多个重复请求击穿
使用protobuf的高效节点间通信
支持单机/分布式缓存

LRU 实现

使用一个双链表和一个哈希表实现可以LRU。

get

使用key查找map，获取到链表节点
通过链表节点获取值

put

使用key查找map
- 存在：更新值，返回
容量溢出？
- 是：清除最近最少使用的缓存数据(链表头部)
new链表节点，插入到链表尾部
将链表节点插入到map中

为什么在链表中存储键值对而不是单纯的值？

为了实现反向由链表找到map中存的链表节点。否则在删除最近最少使用的缓存数据时无法同步删除map中的值

leetcode LRU算法实现

import "container/list"

const NotFind = -1

type LRUCache struct {
    // 容量，用key的数量简单表示
	capacity int
    // 链表用以维护最近最少使用的信息，最新访问过的数据被移动到队列尾部
	ll       *list.List
    // 从key到链表元素的映射
	cache    map[int]*list.Element
}

// 键值对
type entry struct {
	key   int
	value int
}

func Constructor(capacity int) LRUCache {
	return LRUCache{
		capacity: capacity,
		ll:       list.New(),
		cache:    make(map[int]*list.Element, capacity),
	}
}

func (c *LRUCache) Get(key int) int {
	// key存在，将对应的键值对移动到链表尾部
	if ele, ok := c.cache[key]; ok {
		c.ll.MoveToBack(ele)
		kv := ele.Value.(*entry)
		return kv.value
	}
	return NotFind
}

func (c *LRUCache) Put(key int, value int) {
	// key已经存在，更新值
	if ele, ok := c.cache[key]; ok {
		kv := ele.Value.(*entry)
		kv.value = value
		c.ll.MoveToBack(ele)
		return
	}
	// key不存在
	// 容量已满删除链表头部元素
	for len(c.cache) >= c.capacity {
		e := c.ll.Front()
		c.ll.Remove(e)
		delete(c.cache, e.Value.(*entry).key)
	}
	// 插入链表尾部
	e := c.ll.PushBack(&entry{
		key:   key,
		value: value,
	})
	c.cache[key] = e
}

缓存数据抽象

type ByteView struct {
	data []byte
}

func (v ByteView) Len() int {
	return len(v.data)
}

func (v ByteView) ByteSlice() []byte {
	cp := make([]byte, v.Len())
	copy(cp, v.data)
	return cp
}

groupcache原设计中，ByteView同时维护了一个字符串和一个字节数组(同一时刻只要一个有效，另一个为空)，这样抹平了string和[]byte的差距，且为了防止直接从缓存中返回的切片(内部的数组)被外部更改，使用ByteSlice()拷贝了一份数据，并返回，使得缓存内部数据对外只读。

并发访问

使用sync.Mutex封装lru，使其支持并发访问

// 对lru进行封装使其支持并发读写
type cache struct {
   mu  sync.Mutex
   lru *lru.Cache
   // 直接用键值对数量来限制缓存大小，实际应该统计key value的内存占用
   maxEntries int
}

func (c *cache) add(key string, value ByteView) {
   c.mu.Lock()
   defer c.mu.Unlock()
   // 延迟初始化
   if c.lru == nil {
      c.lru = lru.New(c.maxEntries)
   }
   c.lru.Put(key, value)
}

func (c *cache) get(key string) (value ByteView, ok bool) {
   c.mu.Lock()
   defer c.mu.Unlock()
   if c.lru == nil {
      return
   }
   v, ok := c.lru.Get(key)
   if !ok {
      return
   }
   return v.(ByteView), ok
}

源数据获取

groupcache与memcache、redis的一大不同之处在于，它并不是以一个单独的服务运行，而是作为一个库嵌入到代码中，既作为服务器，也作为客户端。所以在获取数据的方式上，它定义了一个接口，类似下面这样。当缓存被使用时，发现数据不存在，则调用下面的接口获取源数据缓存。

type Getter interface {
	Get(ctx context.Context, key string) ([]byte, error)
}

type GetterFunc func(ctx context.Context, key string) ([]byte, error)

func (f GetterFunc) Get(ctx context.Context, key string) ([]byte, error) {
	return f(ctx, key)
}

这里使用了go的接口型函数编码技巧。如果直接定义一个Getter接口，则需要我们定义一个空结构体实现Getter方法，并使用。而通过如上的代码，我们可以同时使用结构体/函数作为参数，大大方便了接口的使用

type T struct {
	getter Getter
}
// 直接显示类型转换使用函数
t1 := &T{getter: GetterFunc(func(ctx context.Context, key string) ([]byte, error) {
    return []byte{}, nil
})}

// 或是使用符合接口的结构体
type G struct{}
func (g G) Get(ctx context.Context, key string) ([]byte, error) {
	return []byte{}, nil
}

t2 := &T{
    getter: G{},
}

Group

group是提供服务的核心结构体，起到管理缓存，区分命名空间，联系对等点获取数据等作用。

全局变量管理多个group

var (
	mu       = sync.RWMutex{}
	groupMap = make(map[string]*Group)
)

// A Group is a cache namespace and associated data loaded spread over
type Group struct {
	name      string
	getter    Getter
	mainCache *cache
	// groupcache还提供了热点数据多点缓存的功能
	// hotCache *cache
}

group的结构：

缓存逻辑：

缓存命中的情况下直接返回结果。当缓存未命中，会从对等点或者用户设置的getter出获取数据。节点的选择通过一致性哈希算法实现，如果key被分配到了当前节点，节点会通过getter获取数据并缓存，否则就直接从对等点处获取直接返回。

一致性哈希

一致哈希 是一种特殊的哈希算法。在使用一致哈希算法后，哈希表槽位数（大小）的改变平均只需要对 k/n个关键字重新映射，其中 k是关键字的数量，n是槽位数量。然而在传统的哈希表中，添加或删除一个槽位的几乎需要对所有关键字进行重新映射。 –wiki

如果在节点选择中，采用普通哈希，则缓存会在节点数量变更时几乎全部失效，导致后端压力激增。

一致哈希尽可能使同一个资源映射到同一台缓存服务器。这种方式要求增加一台缓存服务器时，新的服务器尽量分担存储其他所有服务器的缓存资源。减少一台缓存服务器时，其他所有服务器也可以尽量分担存储它的缓存资源。一致哈希算法的主要思想是将每个缓存服务器与一个或多个哈希值域区间关联起来，其中区间边界通过计算缓存服务器对应的哈希值来决定。

var hash = crc32.ChecksumIEEE

type Map struct {
   // 在节点数量比较少的时候，容易出现节点映射不均衡的现象，可以插入多个虚拟节点
   replicas int
   // 虚拟节点hash值对应的实际节点
   hashMap map[int]string
   // 虚拟节点的哈希值，需要排序
   // 通过二分查找更快找到 目标key 所归属的节点
   keys []int
}

func New(replicas int) *Map {
   return &Map{
      replicas: replicas,
      hashMap:  make(map[int]string),
      keys:     []int{},
   }
}

func (m *Map) AddNode(keys ...string) {
   for _, key := range keys {
      for i := 0; i < m.replicas; i++ {
         // 拼接编号和节点名称，获得hash值
         h := int(hash([]byte(strconv.Itoa(i) + key)))
         // 插入map和keys中
         m.hashMap[h] = key
         m.keys = append(m.keys, h)
      }
   }
   // 排序
   sort.Ints(m.keys)
}

func (m *Map) Get(key string) string {
   h := int(hash([]byte(key)))
   idx := sort.Search(len(m.keys), func(i int) bool { return m.keys[i] >= h })
   // 因为是个环，下标等于长度时，就折回到0，归属0号节点
   if idx == len(m.keys) {
      idx = 0
   }
   return m.hashMap[m.keys[idx]]
}

HTTP服务器&客户端

每一个节点既是服务器又是客户端，节点都开启一个http服务。

在实现http服务之前，我们需要先抽象节点选择接口和节点数据获取接口

type PeerGetter interface {
	Get(cxt context.Context, group string, key string) ([]byte, error)
}

type PeerPicker interface {
	PickPeer(key string) (peer PeerGetter, ok bool)
}

type Group struct {
	// 节点选择接口
	peers PeerPicker
	......
}

对于group，我们需要依赖一个实现PeerPicker接口的实例，来选择对等点获取一个PeerGetter实例，并调用Get方法，完成从对等点获取数据的能力。

接下来实现http服务器和客户端。服务器实现PeerPicker，客户端实现PeerGetter。而如果我们需要实现rpc通信，只需要修改这两个接口对应的实现，非常方便

const (
	defaultBasePath = "/cache/"
	defaultReplicas = 50
)

type HTTPPool struct {
	basePath string
	self     string
	// 节点选择功能
	mu          sync.Mutex
	peers       *consistenthash.Map
	httpGetters map[string]*httpGetter
}

func NewHTTPPool(self string, path string) *HTTPPool {
	p := &HTTPPool{
		self: self,
		mu:   sync.Mutex{},
	}
	if path != "" {
		p.basePath = path
	} else {
		p.basePath = defaultBasePath
	}
	http.Handle(self, p)
	return p
}

func (p *HTTPPool) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	parts := strings.SplitN(r.URL.Path[len(p.basePath):], "/", 2)
	groupName := parts[0]
	key := parts[1]
	// 获取group
	group := GetGroup(groupName)
	ctx := r.Context()
	data, err := group.Get(ctx, key)
	//w.Header().Set("Content-Type", "application/x-protobuf")
	// 设置http请求标头为8位字节流
	w.Header().Set("Content-Type", "application/octet-stream")
	w.Write(data)
}

func (p *HTTPPool) PickPeer(key string) (PeerGetter, bool) {
	p.mu.Lock()
	defer p.mu.Unlock()
	u := p.peers.Get(key)
	log.Println(u)
	if u == p.self {
		return nil, false
	}
	return p.httpGetters[u], true
}

func (p *HTTPPool) Set(peers ...string) {
	p.mu.Lock()
	defer p.mu.Unlock()
	p.peers = consistenthash.New(defaultReplicas)
	p.peers.AddNode(peers...)
	p.httpGetters = make(map[string]*httpGetter, len(peers))
	for _, peer := range peers {
		p.httpGetters[peer] = &httpGetter{baseUrl: peer + p.basePath}
	}
}

// http客户端
type httpGetter struct {
	baseUrl string
}

func (g *httpGetter) Get(ctx context.Context, group string, key string) ([]byte, error) {
	u := fmt.Sprintf(
		"%v%v/%v",
		g.baseUrl,
		url.QueryEscape(group),
		url.QueryEscape(key),
	)
	res, err := http.Get(u)
	log.Println(u)
	if err != nil {
		return nil, err
	}
	defer res.Body.Close()
	bytes, err := ioutil.ReadAll(res.Body)
	return bytes, nil
}

http内容请求标头： http Content-Type

example.com:8000/cache/test-group/key，请求的url中包括了域名，端口，起到标识作用的path，group名称，key

Protobuf

Protobuf是一个数据结构序列化库，和常见的json功能类似。

protobuf对比json：

优点：

序列与反序列化效率更高
算法优势使其对数据有压缩能力，减小带宽压力
不仅仅包含消息，也包含服务的定义

确定：

二进制序列人类不可读
灵活性较低

两者适合的应用场景不同，protobuf更适合内部环境，比如rpc。而json更适合web应用。

syntax = "proto2";

package protobuf;
option go_package = "../pb";

message GetRequest {
  required string group = 1;
  required string key = 2;
}

message GetResponse {
  optional bytes value = 1;
}

google protobuf 文档

protoc --go_out=. *.proto

生成对应的go代码。

原本服务的响应是放置在body中的二进制流，现在将其通过protobuf编码

分别修改请求、服务、接口

func (g *httpGetter) Get(ctx context.Context, in *pb.GetRequest, out *pb.GetResponse) error{
    ......
    bytes, err := ioutil.ReadAll(res.Body)
	err = proto.Unmarshal(bytes, out)
}

func (p *HTTPPool) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	.....
	w.Header().Set("Content-Type", "application/x-pb")
	body, err := proto.Marshal(&pb.GetResponse{Value: data})
	w.Write(body)
}

type PeerGetter interface {
	Get(ctx context.Context, in *pb.GetRequest, out *pb.GetResponse) error
}

singleflight

缓存击穿

未缓存的数据短时间被高并发访问，导致大量请求穿透缓存层，直接打到数据库

如果一个数据不在缓存中，而瞬时又有了很大的并发请求(比如秒杀活动前的一些数据)，缓存会向数据库发起多次相同的请求，数据库可能因此奔溃。而singleflight通过阻塞后续同样的请求，来防止缓存击穿。

// 保存请求的返回值供其他请求使用，并用WaitGroup阻塞其他请求
type call struct {
	wg  sync.WaitGroup
	val interface{}
	err error
}

// 维护一个map，通过key找到请求
// Mutex用来保证map的线程安全
type Group struct {
	m  map[string]*call
	mu sync.Mutex
}

// 传入一个key，和一个函数，函数只会被执行第一次
// 后来的请求会被阻塞，待第一个请求完成后，后续的请求使用相同的返回值
func (g *Group) Do(key string, fn func() (interface{}, error)) (interface{}, error) {
	g.mu.Lock()
	if g.m == nil {
		g.m = make(map[string]*call)
	}
	if c, ok := g.m[key]; ok {
		g.mu.Unlock()
		// 阻塞
		c.wg.Wait()
		return c.val, c.err
	}
	c := &call{}
	c.wg.Add(1)
	g.m[key] = c
	g.mu.Unlock()
	// 执行
	c.val, c.err = fn()
	c.wg.Done()

	g.mu.Lock()
	delete(g.m, key)
	g.mu.Unlock()

	return c.val, c.err
}

使用时只需要代码包裹在do中，并处理一下返回值

func (g *Group) load(ctx context.Context, key string) (ByteView, error) {
	val, err := g.loader.Do(key, func() (interface{}, error) {
		p, ok := g.peers.PickPeer(key)
		if !ok {
			bv, err := g.getLocally(ctx, key)
			if err != nil {
				return ByteView{}, err
			}
			g.populateCache(key, bv)
			return bv, err
		}
		return g.getPeer(ctx, key, p)
	})
	if err != nil {
		return ByteView{}, err
	}
	return val.(ByteView), nil
}

附注

完整代码：

https://github.com/vincent-vinf/simple_groupcache

参考链接：

https://zh.wikipedia.org/wiki/%E7%BC%93%E5%AD%98

https://aws.amazon.com/caching/

https://github.com/golang/groupcache

https://geektutu.com/post/geecache.html

图片来源：

封面来源

By Dennis - Own work, Public Domain, https://commons.wikimedia.org/w/index.php?curid=31541

https://hihcys.github.io/2020/03/17/%E4%B8%80%E8%87%B4%E6%80%A7hash%E7%8E%AF%E5%8F%8A%E4%BC%98%E5%8C%96%E6%96%B9%E6%B3%95/