K8s 的 HPA (Horizontal Pod Autoscaler) 自动扩缩容在 kube-controller-manager 中的 HPA Controller 中实现，它通过 APIServer 的 *metrics.k8s.io APISerice 访问 各种 metrics 提供者，其中基础 CPU 内存 的 resource metrics 由 metrics-server 组件提供，它会定时查询各个节点 kubelet 缩暴露的容器监控数据并保存到内存中以供获取，除 HPA 外，kubectl top 命令也依赖它。

HPA 架构图如下：

NewHorizontalController

HPA Controller 使用的 informer 有两个

• hpaInformer
• podInformer

其中 hpaInformer 有 EventHandler，用于监听 HPA 变化定时抓取 metrics 计算预期的实例数量，podInformer 仅用于 list

Run

和其他 Controller 无异，启动 worker 并从 workqueue 中取出任务执行，但对于 HPA Controller，有两点不同之处

• 启动的 worker 只有一个
• workqueue 是一个固定时间参数（默认 15s，也就是 HPA 的评估评率）的限速队列，以实现类似 Ticker 定时执行的效果

worker 工作逻辑

func (a *HorizontalController) processNextWorkItem() bool {
	key, quit := a.queue.Get()
	if quit {
		return false
	}
	defer a.queue.Done(key)
	deleted, err := a.reconcileKey(key.(string))
	if err != nil {
		utilruntime.HandleError(err)
	}
	// 周期性对 HPA 进行扩缩容判断的实现，processNextWorkItem 每处理完一个 HPA 对象
	// 若此对象未被删除，则继续添加到 RateLimited 队列中等待下一次执行
	if !deleted {
		a.queue.AddRateLimited(key)
	}
	return true
}

从队列中取得一个 HPA 对象在方法 reconcileKey 中评估执行扩缩容，返回了一个 delete 表示该 HPA 对象是否被删除，若未被删除则处理完后继续添加到这个 rateLimit 队列中，等待下一个时间周期到来后取出再次执行。

如何计算 HPA 推荐的实例数量

整体判断逻辑主要有四步

1. 实例数量为 0 时不进行判断，禁用自动扩缩容，因此原生 HPA 不适用于 Scale From Zero
2. 实例数量大于 max 时，缩容到上限
3. 实例数量小于 min 时，扩容到下限
4. 通过 HPA 指定的 Metrics 计算期望实例数量

// 1. 当前实例数量为 0，但是 HPA min 不为零时，禁用此 HPA 停止自动扩缩容
if scale.Spec.Replicas == 0 && minReplicas != 0 {
	// Autoscaling is disabled for this resource
	desiredReplicas = 0
	rescale = false
} else if currentReplicas > hpa.Spec.MaxReplicas {
	// 2. 当前实例数量大于 HPA max 时，缩容到上限
	desiredReplicas = hpa.Spec.MaxReplicas
} else if currentReplicas < minReplicas {
	// 3. 当前实例数量小于 HPA min 时，扩容到下限
	desiredReplicas = minReplicas
} else {
	var metricTimestamp time.Time
	// 4. 通过指定的 metrics 计算出期望的实例数量 metricDesiredReplicas
	// 但还并不是最终决定期望的数量，目前期望结果 desiredReplicas 还是 0
	metricDesiredReplicas, metricName, metricStatuses, metricTimestamp, err = a.computeReplicasForMetrics(hpa, scale, hpa.Spec.Metrics)
	//...
}

通过 Metrics 计算期望实例数量时，会计算 HPA 中定义的所有 Metric 类型，并取出其中得到最高数量的实例数作为本次推荐值的计算结果：

for i, metricSpec := range metricSpecs {
	replicaCountProposal, metricNameProposal, timestampProposal, condition, err := a.computeReplicasForMetric(hpa, metricSpec, specReplicas, statusReplicas, selector, &statuses[i])

	if err != nil {
		if invalidMetricsCount <= 0 {
			invalidMetricCondition = condition
			invalidMetricError = err
		}
		invalidMetricsCount++
	}
	// 取所有 metrics 结果的最大值
	if err == nil && (replicas == 0 || replicaCountProposal > replicas) {
		timestamp = timestampProposal
		replicas = replicaCountProposal
		metric = metricNameProposal
	}
}

缩容稳定窗口

HPA 在执行扩容时，若此次计算出的实例数量大于当前实例数，则会立即触发扩容，但缩容并不是低于当前实例数量就立即触发，为了避免 Pod 资源利用率的常规抖动而频繁进行扩缩容，可指定 downscaleStabilisationWindow 缩容稳定窗口 参数来进行稳定。具体原理是，每次评估完推荐值时不会直接使用此推荐值进行扩缩容操作，而是需要根据历史的推荐值记录重新评估一遍，保证此次使用的推荐实例数不会低于历史稳定窗口内任何一次历史推荐值，即取窗口内的历史最高值。

在 HPA Controller 使用一个 recommendations map 保存历史的扩缩容计算推荐值

recommendations map[string][]timestampedRecommendation

type timestampedRecommendation struct {
	recommendation int32
	timestamp      time.Time
}

实现稳定扩缩容的方法为 stabilizeRecommendation，主要有两个逻辑

1. 判断稳定窗口内所有历史推荐值，取最大值作为本次的推荐
2. 将稳定窗口前最旧的推荐值替换为计算出来最新的推荐值，轮转避免历史数据无限增长消耗内存

func (a *HorizontalController) stabilizeRecommendation(key string, prenormalizedDesiredReplicas int32) int32 {
	maxRecommendation := prenormalizedDesiredReplicas
	foundOldSample := false
	oldSampleIndex := 0
	cutoff := time.Now().Add(-a.downscaleStabilisationWindow)
	for i, rec := range a.recommendations[key] {
		if rec.timestamp.Before(cutoff) {
			// 窗口时间之前的数据（旧数据）
			foundOldSample = true
			oldSampleIndex = i
		} else if rec.recommendation > maxRecommendation {
			// 窗口时间内的数据，每一个均需要判断是否比此次推荐数据大，若存在更大的则取历史中最大的那条
			// max(currentRec, historyRec...)
			maxRecommendation = rec.recommendation
		}
	}
	if foundOldSample {
		// 替换窗口外不需要的旧数据为最新一次的推荐值
		a.recommendations[key][oldSampleIndex] = timestampedRecommendation{prenormalizedDesiredReplicas, time.Now()}
	} else {
		a.recommendations[key] = append(a.recommendations[key], timestampedRecommendation{prenormalizedDesiredReplicas, time.Now()})
	}
	return maxRecommendation
}

两个参数

Pod 在其生命周期中随时可能会有各种状态的变化，以下两个参数决定了 Pod 哪些状态的 Pod 不会被纳入 HPA 的计算中

• cpuInitializationPeriod Default: 5m0s The period after pod start when CPU samples might be skipped.
• delayOfInitialReadinessStatus Default: 30s The period after pod start during which readiness changes will be treated as initial readiness.

相关 PR：kubernetes/kubernetes#68068 中说明，忽略以下情况的 Pod

• Pod is beeing initalized - 5 minutes from start defined by flag
• Pod is unready
• Pod is ready but full window of metric hasn't been colected since transition
• Pod is initialized - 5 minutes from start defined by flag:
• Pod has never been ready after initial readiness period.

但是其描述的说法并不太准确，通过阅读源码得知，cpuInitializationPeriod (5min) 参数将 Pod 生命周期分为两个时段来判断是否要纳入计算

Pod 启动前 5min

• 若 Pod 当前状态是 Unready 则直接视为 Unready
• 若 Pod 当前状态是 Ready 且其 ReadyCondition 变为 true 的时间已经超过 metric.Window (30s)，才会被视为 Ready，即就算短时间内的探针通过也不算，必须要保证上次抓取到 metric 时该 Pod 也需要是 Ready 状态

Pod 启动 5min 后

这里则用到了 delayOfInitialReadinessStatus (30s) 参数，

• 若 Pod 当前状态是 Ready，直接视为 Ready 纳入计算
• 若 Pod 当前状态是 Unready ，且 ReadyCondition 上次变化的时间在 Pod 启动的 30s 之后，视为 Ready 都需要纳入 HPA 计算
• 若 Pod 当前状态是 Unready ，且 ReadyCondition 上次变化的时间在 Pod 启动的 30s 内，HPA 认为这个 Pod 从未 Ready 过，此情况视为 Unready 需要忽略掉

例如对于以下两个 Pod

• POD1: 10min 前启动、Unready、9min55（启动后 5s < 30s）前变为的 Unready，则视为 Unready => 忽略
• POD2: 10min 前启动、Unready、9min05（启动后 55s > 30s）前变为的 Unready，则视为 Ready => 不忽略

参考源码如下：

if resource == v1.ResourceCPU {
	var unready bool
	_, condition := podutil.GetPodCondition(&pod.Status, v1.PodReady)
	if condition == nil || pod.Status.StartTime == nil {
		unready = true
	} else {
		if pod.Status.StartTime.Add(cpuInitializationPeriod).After(time.Now()) {
			// Pod 在启动前 cpuInitializationPeriod (默认5min) 内
			// 若 Pod Unready 则忽略
			// 若 Pod Ready，且在 metric.Window (默认30s) 时间内的 PodReady 状态变化也计为 Unready
			unready = condition.Status == v1.ConditionFalse || metric.Timestamp.Before(condition.LastTransitionTime.Time.Add(metric.Window))
		} else {
			// Pod 在启动 cpuInitializationPeriod (默认5min)  后
			// 当前 Unready，且是从启动后的 delayOfInitialReadinessStatus(默认30s) 内就 Unready 一直持续到现在，才忽略
			// 即启动 5min 之后，对于 LastTransitionTime 在启动 30s 后变化的 Pod 不论现在是否是 ready 均视为 ready，要计入 HPA 计算中
			unready = condition.Status == v1.ConditionFalse && pod.Status.StartTime.Add(delayOfInitialReadinessStatus).After(conditioLastTransitionTime.Time)
		}
	}
	if unready {
		unreadyPods.Insert(pod.Name)
		continue
	}
}

Kubernetes 高可用集群的控制面组件里，除了 kube-apiserver 是多副本负载均衡同时提供服务之外，还有两个组件： kube-scheduler 和 kube-controller-manager ，它们虽然在三个 master 中均部署了三份副本，但是实际上只有一个在真正工作。三个组件如何在集群中相互协调决定哪一个真正工作，其背后原理是 leader election，使用了 client-go 中的 tools/leaderelection 包完成选举的行为。

基本概念

多个成员参与 leader election 的行为中，成为分为两类：

• leader
• candidate

其中 leader 为真正工作的成员，其他成员为 candidate ，它们并没有在执行工作而是随时等待成为 leader 并开始工作。在它们运行之初都是 candidate，初始化时都会去获取一个唯一的锁，谁抢到谁就成为 leader 并开始工作，在 client-go 中这个锁就是 apiserver 中的一个资源，资源类型一般是 CoordinationV1() 资源组中的 Lease 资源。

在 leader 被选举成功之后，leader 为了保住自己的位置，需要定时去更新这个 Lease 资源的状态，即一个时间戳信息，表明自己有在一直工作没有出现故障，这一操作称为续约。其他 candidate 也不是完全闲着，而是也会定期尝试获取这个资源，检查资源的信息，时间戳有没有太久没更新，否则认为原来的 leader 故障失联无法正常工作，并更新此资源的 holder 为自己，成为 leader 开始工作并同时定期续约。

三个时间参数

• leaseDuration leader 续约一次的有效期
• RenewDeadline 续租超时时间，leader 每次续租执行时间超过此时间认为失败，将 lease 释放
• RetryPeriod leader 续约周期，candidate 循环获取锁的周期

源码

kube-controller-manager 组件在初始化时时如何使用 client-go 进行选举的，参考代码： https://github.com/kubernetes/kubernetes/blob/v1.18.5/cmd/kube-controller-manager/app/controllermanager.go#L245-L285

// leaderElect 可选配置，通过命令行参数传入，若未开启直接运行run()开始工作
if !c.ComponentConfig.Generic.LeaderElection.LeaderElect {
    run(context.TODO())
    panic("unreachable")
}

// 开启 leaderElection，下面为使用leaderElection的步骤
// 首先为自己选定一个ID，此ID必须要在所有成员中是唯一的，这里使用 Hostname + UUID
id, err := os.Hostname()
if err != nil {
    return err
}
id = id + "_" + string(uuid.NewUUID())

// 创建一个资源锁，resourcelock也是client-go中的工具，选定哪个资源是leaderElection的竞争目标
rl, err := resourcelock.New(c.ComponentConfig.Generic.LeaderElection.ResourceLock,
    c.ComponentConfig.Generic.LeaderElection.ResourceNamespace,
    c.ComponentConfig.Generic.LeaderElection.ResourceName,
    c.LeaderElectionClient.CoreV1(),
    c.LeaderElectionClient.CoordinationV1(),
    resourcelock.ResourceLockConfig{
        Identity:      id,
        EventRecorder: c.EventRecorder,
    })
if err != nil {
    klog.Fatalf("error creating lock: %v", err)
}

// 开始进行选举，并注册回调函数
leaderelection.RunOrDie(context.TODO(), leaderelection.LeaderElectionConfig{
    Lock:          rl,
    LeaseDuration: c.ComponentConfig.Generic.LeaderElection.LeaseDuration.Duration,
    RenewDeadline: c.ComponentConfig.Generic.LeaderElection.RenewDeadline.Duration,
    RetryPeriod:   c.ComponentConfig.Generic.LeaderElection.RetryPeriod.Duration,
    Callbacks: leaderelection.LeaderCallbacks{
        OnStartedLeading: run,
        OnStoppedLeading: func() {
            klog.Fatalf("leaderelection lost")
        },
    },
    WatchDog: electionChecker,
    Name:     "kube-controller-manager",
})

client-go 实现细节

代码位置 https://github.com/kubernetes/client-go/blob/v0.18.5/tools/leaderelection/leaderelection.go ，开始选举的入口函数为：

leaderelection.RunOrDie(context, cfg)

Run 方法的核心逻辑，尝试获取资源，获取到则成为 leader，获取失败重试：

func (le *LeaderElector) Run(ctx context.Context) {
	// 结束时，处理panic，以及调用StoppedLeading回调函数
	defer func() {
		runtime.HandleCrash()
		le.config.Callbacks.OnStoppedLeading()
	}()

	// loop，循环尝试获取锁，若已经有master拿到锁，则此candidate始终在此循环里没有返回
	if !le.acquire(ctx) {
		return // ctx signalled done
	}

	// 到这里说明此candidate已经成功获取到锁，并成为master正式开始工作
    // 调用开始的回调函数，一般控制器的入口函数会注册到此StartLeading回调函数中
	ctx, cancel := context.WithCancel(ctx)
	defer cancel()
	go le.config.Callbacks.OnStartedLeading(ctx)

    // 也是一个循环，master在获取到锁之后也需要不停地去续租，相当于是发送心跳包表明自己在正常工作
	le.renew(ctx)
}

acquire 和 renew 两个方法的循环周期都是配置中的 RetryPeriod 参数，其中 aquire 的循环中调用的核心方法是 tryAcquireOrRenew 返回 true 表示拿到锁并成为了新的 leader，反之返回 false，自己还是 candidate，成功 aquire 之后便会退出循环:

func (le *LeaderElector) tryAcquireOrRenew(ctx context.Context) bool {
    // 先实例化leaderElectionRecord 若真的获取到里就将资源更新为此实例
	now := metav1.Now()
	leaderElectionRecord := rl.LeaderElectionRecord{
		HolderIdentity:       le.config.Lock.Identity(),
		LeaseDurationSeconds: int(le.config.LeaseDuration / time.Second),
		RenewTime:            now,
		AcquireTime:          now,
	}

	// 1. 尝试获取目标资源，若没有找到，则说明还没有其他成员占用切成为leader，直接创建并更新即可
	oldLeaderElectionRecord, oldLeaderElectionRawRecord, err := le.config.Lock.Get(ctx)
	if err != nil {
		if !errors.IsNotFound(err) {
			klog.Errorf("error retrieving resource lock %v: %v", le.config.Lock.Describe(), err)
			return false
		}
		if err = le.config.Lock.Create(ctx, leaderElectionRecord); err != nil {
			klog.Errorf("error initially creating leader election record: %v", err)
			return false
		}
		le.observedRecord = leaderElectionRecord
		le.observedTime = le.clock.Now()
		return true
	}

	// 2. 获取到目标锁记录, 检查ID和时间
	if !bytes.Equal(le.observedRawRecord, oldLeaderElectionRawRecord) {
		le.observedRecord = *oldLeaderElectionRecord
		le.observedRawRecord = oldLeaderElectionRawRecord
		le.observedTime = le.clock.Now()
	}
    // holderID不为空 && 目标租约还没有过期 && ID不是自己，三项其中任何一项不满足都表明自己有资格成为leader
	if len(oldLeaderElectionRecord.HolderIdentity) > 0 &&
		le.observedTime.Add(le.config.LeaseDuration).After(now.Time) &&
		!le.IsLeader() {
		klog.V(4).Infof("lock is held by %v and has not yet expired", oldLeaderElectionRecord.HolderIdentity)
		return false
	}

    // 通过获取到的lease记录发现自己可以成为leader，下面开始执行成为leader的逻辑
	// 3. 若自己本身之前就是leader，则更新acquireTime，transition记录leader变化的次数
	if le.IsLeader() {
		leaderElectionRecord.AcquireTime = oldLeaderElectionRecord.AcquireTime
		leaderElectionRecord.LeaderTransitions = oldLeaderElectionRecord.LeaderTransitions
	} else {
		leaderElectionRecord.LeaderTransitions = oldLeaderElectionRecord.LeaderTransitions + 1
	}

	// 更新lease资源
	if err = le.config.Lock.Update(ctx, leaderElectionRecord); err != nil {
		klog.Errorf("Failed to update lock: %v", err)
		return false
	}

	le.observedRecord = leaderElectionRecord
	le.observedTime = le.clock.Now()
	return true
}

leader 在 renew 方法的循环中调用的实际上也是上面的 tryAcquireOrRenew 方法，只不过不出意外每次都到第 3 步更新一下时间续租即可。

自己尝试使用

近期写了一个小组件，收集 Kubernetes 集群中的 Events 并存入持久化储存如 ES 中以供快速查询。此组件本身并没有什么复杂度，实际上就是一个 informer + watch + workqueue 入库，可以算是一个自定义 controller 最基本简单的模型了。组件本身故障挂掉也不会有太大的影响，由 k8s 本身故障自愈重启启动 Pod 即可，虽然说可能会丢一些日志，但是问题也不算太大。但是开始尝试使用了 Leader Election 可能有一些大材小用吧，但是也当是熟悉练手了。

组件代码开源在 https://github.com/abowloflrf/k8s-events-dispatcher ，Leader Election 部分就在入口函数 main.go 中，实现可供参考。

参考

• Package tools/leaderelection Docs
• kubernetes/client-go Example

实时性是什么？

HTTP 协议被认为是一种无状态协议：客户端发出请求，随之服务端对这次请求返回响应，一来一回为一次 HTTP 请求的过程。但是基本的 HTTP 请求往往无法高效优雅地满足 Web 中需要的各种功能。例如各种实时性要求的场景，在线聊天是最为经典的例子，A 发送消息给 B 后，B 如何能实时地拿到 A 发送的这条消息？按最简单最传统的思路，需要 B 的浏览器端去请求服务器看看是否有新的消息，HTTP 接口可能被设计成：

POST /send
{
  "to":"user_b",
  "msg":"hello"
}

GET /message
{
  "messages":[
    {
      "from":"user_a",
      "msg":"hello"
    }
  ]
}

用户 A 调用 send 发送消息，然后用户 B 的浏览器中有一个按钮 - 获取最新消息 来调用 message 获取消息列表，这样 A 发送消息之后 B 没法直接知道谁在何时发送了消息，必须手动去点击按钮发送请求从服务器拉取消息，显然这样是一个很不合理的技术实现，完全不具有任何实时性。

要在 Web 中达到实时性首先需要需要思考它的实时性的根源问题：服务端是知道一个事件发生的第一人，它如何将这个事件在第一时间让客户端（浏览器）知道？

可以肯定的是做这件事只有两种最基本的方式：

1. Client Pull
2. Server Push

具体来说，Web 中有实现实时性的几种方式，本篇文章会对这些方法做一些简单的介绍：

1. Polling (Client Pull)
2. Websocket (Client Pull + Server Push)
3. SSE (Server Push)

Polling

Polling 即所谓的轮询，是最基础的方式，它不需要额外的兼容性支持，最简单的 HTTP 协议就能完成，因此后面所要介绍的几种较为高级的实时性实现方式都会做一些 fallback 兼容的方法即退化到 Polling 方式以兼容不受支持的浏览器设备。

Polling 又可以细分为长轮询（Long Polling）和短轮询（Short Polling）。其中短轮询最好理解，就是每隔一段时间浏览器自动发送 HTTP 请求向服务端拉数据，但是这并没有做到太高的实时性，因为它取决于客户端的 interval，若 5 秒一次请求，那么在 3 秒时 A 发送的消息在 5s 时 B 才会去请求拿到消息，这样就有了 2s 的延迟，但是相比开头中所设计的让用户傻乎乎的点按钮至少进步了，即浏览器去每隔一段时间自动帮用户去点按钮。长轮询的出现则解决这个 2s 的延迟，提高实时性。连接在一开始 B 就发送了一个 HTTP 请求，在 A 还没有发消息时这个请求会一直阻塞，直到 A 发送了消息服务端就会立马将 A 发送的消息作为那个阻塞的 HTTP 请求的返回给 B。B 在收到 HTTP 响应之后又会立刻再发送 HTTP 请求如此往复。这样实时性就已经得到了非常大的提高，其延时就只在网络延迟、TCP 握手、SSL 握手等连接建立的时间消耗上了。

Websocket

Websocket 是一个解决 Web 中实时性数据传输问题的最为广泛使用的方式。它使用 HTTP 协议进行握手，浏览器建立 Websocket 通信的 HTTP 请求头部如下：

GET /websocket HTTP/1.1
Host: 127.0.0.1:8000
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://127.0.0.1:8000
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7
Sec-WebSocket-Key: umeTOPSdULFnza3ucv1Izw==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

其中主要在 Connection:Upgrade 这个字段，告诉服务端要进行一次连接的升级，但是所谓升级，从网络协议栈上来看实际上是一次降级：从 7 层的 HTTP 协议降级为原始的 TCP 协议。服务端返回的状态码为 101 :

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: 96PLAgW2q+VO9O7ubrmfQB6jhyY=

随后浏览器和服务端就以 Websocket 协议（https://tools.ietf.org/html/rfc6455）在这个 TCP 连接上进行通信，不再是 HTTP 的形式而是 TCP 的形式进行数据传输。而且这个 TCP 连接可以是全双工的，也就是说不仅客户端可以发送 Frame，服务端还可以在这个 TCP 连接上向浏览器推送数据。相比 Polling，它的优势提升在：

1. 提供一个双向流同时支持 Server Push 和 Client Push
2. 一次 HTTP 握手后就建立了 TCP 连接，减少了 Polling 中重复的 HTTP 建立过程
3. 直接使用 TCP 连接传输数据，没有 HTTP 多余的头部信息，数据量小传输快

使用 Python 的 Sanic 框架中提供的 Webscoket：

@app.websocket("/websocket")
async def feed(req, ws):
    while True:
        now = datetime.datetime.now().isoformat()
        await ws.send(json.dumps({"now": now}))
        await asyncio.sleep(5)

浏览器客户端中的使用也很方便，new 一个原生的 Websocket 类然后传入几个 on 事件的函数即可：

//点击按钮与服务端建立Websocket连接
document.getElementById("btn-ws").onclick = () => {
    var loc = window.location
    var ws_protocol = loc.protocol === "https" ? "wss://" : "ws://"
    var ws = new WebSocket(ws_protocol + loc.host + "/websocket")
    ws.onopen = ev => {
        console.log("Websocket open")
    }
    ws.onclose = ev => {
        console.log("Websocket close")
    }
    ws.onmessage = ev => {
        console.log(ev.data)
    }
}

使用 Chrome 开发者工具可直观看到 Websocket 的数据传输情况：

SSE(Server-Send-Events)

SSE 是一个比较少见的实现方案，这是我最近在做构建日志展示相关业务时想实时展示构建日志于是去看了我们所使用的构建系统 DroneCI 怎么实现的，才发现他们实时展示日志是使用的这个方案。相比 Websocket 它仅支持 Server Push，理解它的原理也比较简单，它还是基于一个正常的 HTTP 的请求，它利用 HTTP 协议传输数据是流式的特征，服务端在响应中去实时写内容，为了在这个流上区分消息和标示一些信息，这个标准只做了一些简单的约束：

以 data: xxxx\n\n 的形式传输数据，其中 xxxx 是内容， \n\n 来分割不同的消息，另外还提供两个可选的标示 id: 1\n 标识消息 id， event: xxx\n 标识时间类型，这样在 HTTP 流中一个完整的消息可能长这样：

id:1\n
event:message\n
data:helloworld\n\n

使用 Python 的 Sanic 框架的一个简单的写法如下：

@app.get("/sse")
async def sse_handler(req):
    """
    Server-Send-Event
    """

    def sse_data(data: str, event: str = None, id: int = None) -> str:
        """
        组装sse信息
        """
        resp = "data: %s\n\n" % data
        if event is not None and event != "":
            resp = "event: %s\n" % event + resp
        if id is not None:
            resp = "id: %d\n" % id + resp
        return resp

    async def streaming(resp):
        for i in range(1, 10):
            now = datetime.datetime.now().isoformat()
            await resp.write(sse_data(data=json.dumps({"now": now}), event="timenow", id=i))
            await asyncio.sleep(5)

    return response.stream(streaming, content_type="text/event-stream")

客户端 JS 使用原生的 EventSouce （https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events）对象：

var source = new EventSource("/sse")
source.onopen = e => {
    // Event type=open
    console.log("SSE open")
}
source.onerror = e => {
    // Event type=error
    console.log("SSE error")
}
source.onmessage = e => {
    // MessageEvent type=message
    console.log("SSE message: " + e.data)
}

使用 Chrome 开发者工具观察 SSE 请求：

因为它从原理上比 Websocket 要简单一些，因此若是只需要服务端推送数据的场景，比如上面所说的实时获取一些日志，使用 SSE 也是一种可选的方案。

一个很棒的时序图

有一个比较直观易懂的网络请求时序图去对比了解其中几种方式的原理：

参考

1. https://codeburst.io/polling-vs-sse-vs-websocket-how-to-choose-the-right-one-1859e4e13bd9
2. https://tools.ietf.org/html/rfc6455
3. https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events

在公司实习接触到 istio 这个强大的微服务框架，作为一个微服务框架，核心功能之一就是服务发现（Service Discovery），在istio中负责服务发现的核心组件就是 istio-pilot ，它是如何管理集群中的服务并将各个服务的具体信息下发到所有其他服务的呢以流畅管理整个服务网格之间的请求的顺利进行呢。于是前几周很长一段时间我都在阅读 isito-pilot 部分的源码，尝试理解其配置更新推送的原理，下面是一些粗浅的解读与总结。

配置更新的情景

• pilot-discovery 监听到 k8s 内 Pod 的变化，将新的 endpoint 信息推送给所有 envoy
• envoy 发送 DiscoveryRequest 请求到 pilot-dicovery，查询配置信息
• 即使配置没有更新，pilot-discovery 也会周期性推送配置给所有 envoy（默认禁用）

其中主要研究第一种场景，即 pilot-discovery 主动推送配置给所有 envoy，因为这个场景是服务的运行中会随时发生的，非常普遍，而且它对与服务运行的稳定性是息息相关的，尤其是在扩容缩容、意外宕机、流量配置变更等等时刻，时需要保证所有的 sidecar 能够在第一时间得到这一变更信息。

在集群中，每个 Pod 启动时其 sidecar 都会与 pilot-discovery 建立一个双向 gRPC 连接，server 端会（pilot-discovery）在一个 select 中接收两种通道的信息，分别对应 响应查询请求 与 主动推送配置，源代码位置如下：

首先是初始化发现服务initDiscoveryService

initDiscoveryService

func (s *Server) initDiscoveryService(args *PilotArgs) error {

	//前面会有一些获取参数、新建旧版本v1的DiscoveryServer，用于一些旧版本兼容还有debug操作
	...

	//启动envoy api v2版本的DiscoveryServer
	s.EnvoyXdsServer = envoyv2.NewDiscoveryServer(environment, istio_networking.NewConfigGenerator(args.Plugins))
	envoy.V2ClearCache = s.EnvoyXdsServer.ClearCacheFunc()
	s.EnvoyXdsServer.Register(s.grpcServer)
	//Register这里主要是注册了两种gRPC stream
	//1. StreamAggregatedResources      实现ADS接口，主要关注这里
	//2. IncrementalAggregatedResources 用于增量更新，push效率更高，在1.0.3中实现了EDS的增量更新

	...

	//在这个init中添加StartFunc，启动了各种HTTP、gRPC Server
	s.addStartFunc(func(stop <-chan struct{}) error {
		log.Infof("Discovery service started at http=%s grpc=%s", listener.Addr().String(), grpcListener.Addr().String())
		...
		go func() {
			if err = s.grpcServer.Serve(grpcListener); err != nil {
				log.Warna(err)
			}
		}()
		...

		return err
	})

	return nil
}

然后在StreamAggregatedResources中主要在一个 select 中接收两个通道的消息进行处理

case discReq, ok = <-reqChannel 用于接收 envoy 的请求被动推送

case pushEv, _ := <-con.pushChannel 用于接收 watch 的配置变化然后主动向 envoy 推送更新

监听并推送过程

pilot-discovery 在启动时会初始化一个 ServiceController 它会去与 k8s 对接同步其相关的服务注册信息，在NewController方法中会对这些资源：

• Service
• Endpoint
• Node
• Pod

进行一个 watch/inform 的操作，在初始化时会执行List以获取所有需要的服务注册信息然后保存在自己的一个 Cache 中，随后会进行Watch来监听变更来更新这个 Cache，这个 watch 操作实际上是 k8s 集群的 apiserver 所提供的一个高效监听变化的方式。

在NewController 中，即在server.go里创建createK8sServiceController时会对这些资源创建  相应的 watch/informer

out.services = out.createInformer(&v1.Service{}, "Service", options.ResyncPeriod,
	func(opts meta_v1.ListOptions) (runtime.Object, error) {
		return client.CoreV1().Services(options.WatchedNamespace).List(opts)
	},
	func(opts meta_v1.ListOptions) (watch.Interface, error) {
		return client.CoreV1().Services(options.WatchedNamespace).Watch(opts)
	})
// out.endpoints=...
// out.nodes=...
// out.pods=...

在对每个类型资源的createInformer时，会添加 handler：

kube/controller.go#L165

informer.AddEventHandler(
    cache.ResourceEventHandlerFuncs{
        AddFunc: func(obj interface{}) {
            k8sEvents.With(prometheus.Labels{"type": otype, "event": "add"}).Add(1)
            c.queue.Push(Task{handler: handler.Apply, obj: obj, event: model.EventAdd})
        },
        UpdateFunc: func(old, cur interface{}) {
            if !reflect.DeepEqual(old, cur) {
                k8sEvents.With(prometheus.Labels{"type": otype, "event": "update"}).Add(1)
                c.queue.Push(Task{handler: handler.Apply, obj: cur, event: model.EventUpdate})
            } else {
                k8sEvents.With(prometheus.Labels{"type": otype, "event": "updateSame"}).Add(1)
            }
        },
        DeleteFunc: func(obj interface{}) {
            k8sEvents.With(prometheus.Labels{"type": otype, "event": "add"}).Add(1)
            c.queue.Push(Task{handler: handler.Apply, obj: obj, event: model.EventDelete})
        },
    })

一共有三种类型的事件：Add、Update、Delete。然后将事件的详细内容（要推送的内容），添加到 Controller 中的一个 task queue 中。

这个 task queue 执行的源码如下：

kube/queue.go#74

func (q *queueImpl) Run(stop <-chan struct{}) {
	// 开始对任务队列进行处理时对队列加锁，这是一次推送任务
	go func() {
		<-stop
		q.cond.L.Lock()
		q.closing = true
		q.cond.L.Unlock()
	}()

	for {
		q.cond.L.Lock()
		for !q.closing && len(q.queue) == 0 {
			q.cond.Wait()
		}
		//一次推送任务全部完成则退出运行
		if len(q.queue) == 0 {
			q.cond.L.Unlock()
			return
		}
		// 从队列中取出一个任务
		var item Task
		item, q.queue = q.queue[0], q.queue[1:]
		q.cond.L.Unlock()
		// 执行task，若执行失败则延迟一定时间将任务重新加入到队列
		if err := item.handler(item.obj, item.event); err != nil {
			log.Infof("Work item handle failed (%v), retry after delay %v", err, q.delay)
			time.AfterFunc(q.delay, func() {
				q.Push(item)
			})
		}

	}
}

item.hander实际执行的是 Task 中的handler.Apply

// 其中有一组function被依次执行
func (ch *ChainHandler) Apply(obj interface{}, event model.Event) error {
	for _, f := range ch.funcs {
		if err := f(obj, event); err != nil {
			return err
		}
	}
	return nil
}

至于这些 handler 具体要执行  的是什么，它们是上面在初始化 Discovery Service 时所定义的 handler：clearCache()

NewDiscoveryService

// Flush cached discovery responses whenever services, service
// instances, or routing configuration changes.
serviceHandler := func(*model.Service, model.Event) { out.clearCache() }
if err := ctl.AppendServiceHandler(serviceHandler); err != nil {
	return nil, err
}
instanceHandler := func(*model.ServiceInstance, model.Event) { out.clearCache() }
if err := ctl.AppendInstanceHandler(instanceHandler); err != nil {
	return nil, err
}

envoy/discovery.go中的 clearCache，这个方法主要实现了一个debounce机制，有一个DebounceAfter默认是 100ms，也就是每次 push 都会先推迟这个时间，并设置一个全局的变量clearCacheTimerSet记录此时是否有一个正在进行 debounce push 的，若有的话只直接放弃这个 push，并将全局变量lastClearCacheEvent重新设置为当前时间，在那个 debounce push 任务中会计算新的since时间，也就是距离新的 push 任务到来的时间，知道这个时间大于 200ms 才会真正执行 push，若短时间内一直有频繁的配置更新而刷新这个lastClearCacheEvent会导致 push 任务持续被推迟。因为 envoy 需要的只是最新的配置信息，减少了配置频繁更新时而多次推送导致的不必要的负载。

这里有一个问题就是，如果配置确实在短时间内频繁更新了，那么缓存和推送时间迟迟不执行，这时所有的 envoy 就无法及时得到最新的配置信息，也是影响配置生效的一个比较重要的原因。

// debouncePush is called on clear cache, to initiate a push.
func debouncePush(startDebounce time.Time) {
	clearCacheMutex.Lock()
	// 已经在这个debounce push的任务中又有新的push任务到来，这个lastClearCacheEvent时间被更新
	// 实现的功能就是debounce time内做一个简单的限频，时间内若有新的push，则会持续debounce
	since := time.Since(lastClearCacheEvent)
	events := clearCacheEvents
	clearCacheMutex.Unlock()
	// 若自从这个debounce push开始的时间已经经过了200ms就开始执行push
	if since > 2*DebounceAfter ||
		time.Since(startDebounce) > DebounceMax {

		log.Infof("Push debounce stable %d: %v since last change, %v since last push",
			events,
			since, time.Since(lastClearCache))
		clearCacheMutex.Lock()
		// 将这个表示是否有正在进行push的全局变量置为false以允许下一个新的push的进行
		clearCacheTimerSet = false
		lastClearCache = time.Now()
		clearCacheMutex.Unlock()
		V2ClearCache()
	// 否则推迟100ms
	} else {
		log.Infof("Push debounce %d: %v since last change, %v since last push",
			events,
			since, time.Since(lastClearCache))
		time.AfterFunc(DebounceAfter, func() {
			debouncePush(startDebounce)
		})
	}
}
// clearCache will clear all envoy caches. Called by service, instance and config handlers.
// This will impact the performance, since envoy will need to recalculate.
func (ds *DiscoveryService) clearCache() {
	clearCacheMutex.Lock()
	defer clearCacheMutex.Unlock()

	clearCacheEvents++
	// 这里的DebounceAfter默认被设置为100ms
	if DebounceAfter > 0 {
		// 记录一下时间【注意这是一个全局的变量】
		lastClearCacheEvent = time.Now()
		// clearCahceTimerSet 表明又没有一个正在debounce递归中的push任务
		// 若为true则直接放弃这个push
		if !clearCacheTimerSet {
			// 开始一个debounce push
			clearCacheTimerSet = true
			startDebounce := lastClearCacheEvent
			time.AfterFunc(DebounceAfter, func() {
				debouncePush(startDebounce)
			})
		}

		return
	}
	// 后面源码中有一些原来实现类似debounce的方式，当debounceAfter被设置为0时，执行到后面的代码
}

envoy/v2/discovery.go中的ClearCacheFunc()，就是上面的V2ClearCache()，这里主要进行一些 pushContext 的初始化的操作，最后会起一个协程调用adsPushAll去以 ADS 协议执行推送

// ClearCacheFunc returns a function that invalidates v2 caches and triggers a push.
// This is used for transition, once the new config model is in place we'll have separate
// functions for each event and push only configs that need to be pushed.
// This is currently called from v1 and has attenuation/throttling.
func (s *DiscoveryServer) ClearCacheFunc() func() {
	return func() {
		...
		go s.AdsPushAll(versionLocal, push)
	}
}

对当前所有与 pilot-discovery 建立连接的 envoy 客户端执行配置推送ads.go

// AdsPushAll implements old style invalidation, generated when any rule or endpoint changes.
// Primary code path is from v1 discoveryService.clearCache(), which is added as a handler
// to the model ConfigStorageCache and Controller.
func (s *DiscoveryServer) AdsPushAll(version string, push *model.PushContext) {
	...
	// 获取所有待推送的xds连接，对应pilot-disovery来说就是所有与之建立连接的Pod的envoy
	adsClientsMutex.RLock()
	pending := []*XdsConnection{}
	for _, v := range adsClients {
		pending = append(pending, v)
	}
	adsClientsMutex.RUnlock()

	// 在for中持续对xdsConnection列表逐一进行推送
	for {
		//等待推送的连接数为0，即已经全部推送完毕
		if len(pending) == 0 {
			adsLog.Infof("PushAll done %s %v", version, time.Since(tstart))
			return
		}
		...
		// 取出一个pending的连接
		c := pending[0]
		pending = pending[1:]

		// Using non-blocking push has problems if 2 pushes happen too close to each other
		client := c
		// this should be in a thread group, to do multiple pushes in parallel.
		// 官方的todo表示进行推送的操作应该在一个线程组中来并行执行多个推送任务，这里有待改进

		// 设置一个单次推送超时时间5s
		to := time.After(PushTimeout)
		select {
		// client.pushChannel是一个缓冲为0的通道，通道为空表明没有推送任务，这里向其发送了一项XdsEvent其中包括了需要执行的推送任务
		// client端会接收这个通道的信号然后执行推送
		// 在asd.go的StreamAggregatedResources方法中会select两种配置推送情景如最上面所说，接收到了pushChennel的信息
		case client.pushChannel <- &XdsEvent{
			push:    pushContext,
			pending: &pendingPush,
			version: version,
		}:
			client.LastPush = time.Now()
			client.LastPushFailure = timeZero
		case <-client.doneChannel: // connection was closed
			adsLog.Infof("Client closed connection %v", client.ConID)
		case <-to:
			pushTimeouts.Add(1)
			//default:
			// This may happen to some clients if the other side is in a bad state and can't receive.
			// The tests were catching this - one of the client was not reading.
			pending = append(pending, c)
			...
		}
	}
}

pushAll

// Compute and send the new configuration. This is blocking and may be slow
// for large configs.
func (s *DiscoveryServer) pushAll(con *XdsConnection, pushEv *XdsEvent) error {
	...
	//分别对CDS，RDS，LDS，EDS进行判断并执行不同xDS的实际响应封装
	if con.CDSWatch {
		err := s.pushCds(con, pushEv.push, pushEv.version)
		if err != nil {
			return err
		}
	}
	if len(con.Routes) > 0 {
		err := s.pushRoute(con, pushEv.push)
		if err != nil {
			return err
		}
	}
	if len(con.Clusters) > 0 {
		err := s.pushEds(pushEv.push, con)
		if err != nil {
			return err
		}
	}
	if con.LDSWatch {
		err := s.pushLds(con, pushEv.push, false, pushEv.version)
		if err != nil {
			return err
		}
	}
	return nil
}

例如对与 eds 配置进行推送：

func (s *DiscoveryServer) pushEds(push *model.PushContext, con *XdsConnection) error {
	...
	//前面是对结构体的一些封装组成EDS的DiscoveryResponse
	response := s.endpoints(con.Clusters, resAny)
	//终于发送了。。。
	err := con.send(response)
	if err != nil {
		adsLog.Warnf("EDS: Send failure, closing grpc %v", err)
		pushes.With(prometheus.Labels{"type": "eds_senderr"}).Add(1)
		return err
	}
	...
}

一次 endpoint 改变 pushAll 的时间

在本次测试的集群中，一共有三个 pilot 实例，分别连接着 54、4、45 个 envoy clients

• 54 istio-pilot-6c9f665466-5b49s （push 时间大致在 600-700ms）
• 4 istio-pilot-6c9f665466-hgz7k （push 时间大致在 180-200ms）
• 45 istio-pilot-6c9f665466-jxtpw （push 时间大致在 500-600ms）

大致计算每多一个 Pod，push 的时间开销会多 10ms 左右，因此 Pod 数量过多导致 push 速度下降可以添加 istio-pilot 的副本个数解决以均衡每个 istio-pilot 连接的 envoy 数目

Push 生效时间会导致的问题

在进行 scale down 操作时，由于 endpoint 配置没有及时的推送到 envoy 中，因此用户在访问时会导致少量的 503 错误。

可以使用考虑 istio 的 HTTPRetry 配置，其本质是传送了一个 HTTP 头部给 envoy 进行一个配置信息，envoy 收到后会根据指定的错误如 5XX 进行 retry 直到正确返回。但是根据推送时间在 500ms 上下，istio 文档中每次 retry 的时间大约在 25ms+，所以难道要进行这么多次 retry 才能正确收到请求？更加需要注意的是，如果在生产环境中真的有服务 down 了，那么所有的错误请求都会成倍的增加，导致整个集群的压力增大，也是一个需要考虑的问题。

相关 issue 的讨论503 errors when scaling down, or rolling out a new application version #7665

Don't Repeat Yourself

在 Python 中一个与其他语言较为特殊的语法糖就是 Decorator 了，就如同它的名字，一个函数的 decorator 的作用就是将其做一层包装，可以定义在这个函数执行之前做一些什么工作，如检查传入参数等，执行完函数之后做一些定义的操作。比如说对一个函数的做一些额外的操作，记录日志，计算函数运行时间，这些与函数的核心运行逻辑不相关，而且是可以能够被多个函数所使用的小包装，因此可以单独定义一个这么一个装饰器以供不同的函数复用。

在 web 开发中更为常见的情景就是在处理请求对传入 request 数据进行校验、用户身份的校验，如果不符合则直接在 decorator 中 abort 这个请求即可。

decorator 的使用就是在定义函数的上面一行加入@装饰器名

@timethis
def countdown(n):
		pass

这个@说明其实仅仅是一个语法糖，它的效果和下面的定义是完全一样的：

def countdown(n):
		pass
countdown = timethis(countdown)

一个简单的计时装饰器

计时器可以算是最简单且经典的装饰器例子了，因为它在函数的执行前，执行后分别有获取时间、计算时间差并输出的操作，同时对函数内部逻辑没有侵入。

import time
from functools import wraps
def timethis(func):# 传入的是要被装饰的原函数
    '''
    Decorator that reports the execution time.
    '''
    @wraps(func)
    def wrapper(*args, **kwargs):# 这样定义wrapper函数的参数是为来能够正常接收原函数的参数
        start = time.time() # 这个wrapper内定义的在这个原函数执行前执行的代码
        result = func(*args, **kwargs)# 执行原函数，并保存执行结果
        end = time.time() # 这个wrapper内定义的在这个原函数执行后执行的代码
        print(func.__name__, end - start)

        return result # 返回值，即原函数被包装后的返回值
    return wrapper

使用方法：

>>> @timethis
... def countdown(n):
...     '''
...     Counts down
...     '''
...     whilen>0:
...     n -= 1
...
>>> countdown(100000)
countdown 0.008917808532714844
>>> countdown(10000000)
countdown 0.87188299392912 >>>

使用functools库中的@wraps

需要注意的是，在定义任何装饰器时都应该使用 functools 库中的 @wraps 来注解 wrap 函数，使用 @wraps 的重要原因之一是可以保留原函数的元信息，如 __name 和 __doc__ 等。

还可以使用 __wrapped__ 来直接访问被包装的原始函数：

countdown.__wrapped__(1000000) # 去掉了一个装饰器，不会进行计时输出

多个装饰器

最上面定义的装饰器最先执行，然后依次向下

# d1 先与 d2 执行
@decorator1
@decorator2
def add(x, y):
    return x + y

同样地，若要使用__wrapped__，要连续使用两次才能去除刚刚定义的两个装饰器。

# 一个 __wrapped__ 只取消了d1，即最上面的decorator
add.__wrapped__(2, 3)
# 取消两个decorator
add.__wrapped__.__wrapped__(2, 3)

可传入参数的 decorator

例如在使用一个记录日志的 decorator 时，需要指定 log 的级别

from functools import wraps
import logging

#  在这里定义要传入decorator的参数，对decorator再进行一次包装
def logged(level, name=None, message=None):
    """
    Add logging to a function.
    """
    # 传入原函数的decorator
    def decorator(func):
        # 默认值
        logname = name if name else func.__module__
        log = logging.getLogger(logname)
        logmsg = message if message else func.__name__

        @wraps(func)
        def wrapper(*args, **kwargs):
            log.log(level, logmsg)
            return func(*args, **kwargs)

        return wrapper

    return decorator


@logged(logging.DEBUG)
def add(x, y):
    return x + y


if __name__ == "__main__":
    add(1, 2)

在 flask 中使用 decorator 前置检查用户是否认证

在使用 flask 开发 api 时，比较常见的用户认证方法之一是在 HTTP Header 中带入一个 Token，这里我举了一个简单的例子来给 flask 写一个以验证用户认证的装饰器

from functools import wraps
from flask import request, make_response, jsonify


def must_auth(f):
    @wraps(f)
    def decorate(*args, **kwargs):
        hdrs = request.headers
        token = hdrs.get('Authorization')
        # 检查 request header 的 Authorization 部分
        if token != 'Bearer 123456':
            # 校验失败则返回401错误
            return make_response(jsonify({'errno': -1, 'msg': 'not auth'}), 401)
        return f(*args, **kwargs)

    return decorate

# 在路由方法中使用must_auth装饰器
@app.route('/api/auth')
@must_auth
def auth_route():
    return res_data({'foo': 'bar'})

最近在接触一个重构项目，主要是进行一次语言的切换，从 PHP 迁移到 Python。对于 Python 这门语言自己此前只是非常简单地接触过，仅限于写了一些单文件算法练手等等，并没有实际使用它做过工程项目。这次要从零开始对一个项目进行重构，这个时候编码的任务往往是最不重要的，更多的是对与其整个项目结构的设计与思考。因此，了解 Python 的模块与包的机制成了第一个要仔细了解的任务。

Module

一个模块是一个单独的 Python 文件，模块名即为文件名，在这个模块中可以使用全局变量__name__来访问模块名。例如现在有两个文件一个入口文件app.py与另外编写的一个简单的模块firstmode.py

# firstmode.py
first_var = 100

def firstfunc1():
    print('hello from func1')
    print('I\'m in ' + __name__)

def firstfunc2():
    print('hello from func2')

def _privatefunc3():
    print('i m a private func')

class FirstClass():
    pass

在app.py中可以这样引入这个模块，这样模块中所定义的变量、函数则可以在其中使用模块名调用， 在 vscode 中自动补全还有_privatefunc3，但是实际上在 Python 中以下划线开头的函数是被约定为私有的，并不允许从模块外调用。

或者只想引入这个模块中的某一个函数，为了减少引入多余部分的开始，还可以使用：

from firstmod import firstfunc1

# 就可以直接使用firstfunc1名字了不用加上模块名来限定
firstfunc1()

还有更多方式：

# 逗号分隔以引入一个模块中的多个内容
from firstmod import firstfunc1, firstfunc2
# 引入了firstmod中的所有内容，且使用时不需要在前面加上模块名
from firstmod import *
# 为引入的内容设定一个别名，在下面直接使用自定义的别名func1就可以
from firstmode import firstfunc1 as func1

Package

Package(包)，是 Python 中用于组织多个模块的方式，可以使用形如A.B的方式使用，意味子模块B位于名为A的包中。定义一个包需要新建一个目录为包名，在目录下必须有一个__init__.py的文件，用于初始化一些引入包的工作，一般可以留空。下面有一个简单的目录结构。

.
├── app.py
├── firstmod.py
└── mypackage
    ├── __init__.py
    ├── secondmod.py
    └── subpackage1
        ├── __init__.py
        └── thirdmod.py

定义了多个层级的包来管理模块，为了简单，在 secondmode 中只定义了一个second_var的变量，thirdmod.py中只定义了third_var变量。那么在入口文件app.py，则可以这样使用：

# 只引入最上层的包
import mypackage
# 可以调用这个包下的所有子模块的内容
print(mypackage.secondmod.second_var)
# 但是这样调用包下面的子包下的模块的内容就会出错
# AttributeError: module 'mypackage' has no attribute 'subpackage1'
print(mypackage.subpackage1.thirdmod.third_var)

# 使用from
from mypackage import secondmod
print(secondmod.second_var)

简而言之，使用from a import b，若a是一个模块名，那么就引入了模块a下的一个名为b的函数、变量、或类；若a是一个包名，那么就引入了包a下的一个模块b。

*的使用

很多时候为了方便在引入包时使用*，但是它并不是一个好方法，因为这样使用不可控且可读性差，若一定要使用*，可以在模块下定一个 list__all__，如在firstmod.py中定义一个：

__all__ = ['firstfunc1', 'firstfunc2']

那么在使用from firstmod import *时，就只有定义在__all__中的两个方法被引入了。

相对引入

就如在表示目录时使用.表示当前目录，..表示上一级目录一样，Python 在 import 时也可以有这样的操作

# 在thirdmod.py中
from .. import secondmod
print(secondmod.second_var)

dir()

内置函数dir()可以查看在当前模块中定义了哪些名字，或者可以使用参数指定一个模块

>>> import flask
>>> dir(flask)
['Blueprint', 'Config', 'Flask', 'Markup', 'Request', 'Response', 'Session', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__path__', '__spec__', '__version__', '_app_ctx_stack', '_compat', '_request_ctx_stack', 'abort', 'after_this_request', 'app', 'appcontext_popped', 'appcontext_pushed', 'appcontext_tearing_down', 'before_render_template', 'blueprints', 'cli', 'config', 'copy_current_request_context', 'ctx', 'current_app', 'escape', 'flash', 'g', 'get_flashed_messages', 'get_template_attribute', 'globals', 'got_request_exception', 'has_app_context', 'has_request_context', 'helpers', 'json', 'json_available', 'jsonify', 'logging', 'make_response', 'message_flashed', 'redirect', 'render_template', 'render_template_string', 'request', 'request_finished', 'request_started', 'request_tearing_down', 'safe_join', 'send_file', 'send_from_directory', 'session', 'sessions', 'signals', 'signals_available', 'stream_with_context', 'template_rendered', 'templating', 'url_for', 'wrappers']
>>>

近日在研究微服务架构中的 Distributed Tracing 时，遇到了一些问题，需要深入到底层去进行网络抓包分析报文。但是应用时运行在 k8s 集群中的，与传统的在一台机器上跑一个进程直接通过 tcpdump 抓包方式略有不同。最初对容器的理解不深刻认为一定要进入到这个容器抓包，而进入容器内并没有 tcpdump 等基础工具，相当于自己还是把容器当作虚拟机在看待。而实际上 它们只是在宿主机上不同 namespace 运行的进程而已 。因此要在不同的容器抓包可以简单地使用命令切换 network namespace 即可，可以使用在宿主机上的 tcpdump 等应用。

查看指定 pod 运行在哪个宿主机上

kubctl describe pod <pod> -n mservice

获得容器的 pid

docker inspect -f {{.State.Pid}} <container>

进入该容器的 network namespace

nsenter --target <PID> -n

使用 tcpdump 抓包，指定 eth0 网卡

tcpdump -i eth0 tcp and port 80 -vvv

或者直接抓包并导出到文件

tcpdump -i eth0 -w ./out.cap

从远程 scp 到本地

scp ruofeng@ipaddr:/home/ruofeng/out.cap ./

之后在 Wireshark 中可以打开文件非常直观得查看过滤抓到的数据。

由于当时读题理解题意第一时间没有很好的将题目抽象成良好的数据结构模型，加上右上角的时间倒计时看得心慌，整个过程中心态很不好，导致没做出来，最后也将题目复制了下来当天晚上进行了好好的反思。为了防止被检索，这里就不贴处详细的内容了，仅仅描述一下题目本意：

给定一个 有向无环图 ，这个图的每个节点中有一个数值，需要求出的是从入度为 0 的节点开始遍历整张图的所有路径的条数，以及所经过路径之和的最大值。

图节点的表示

确实也是因为最近接触到的图论的题目太少了，抽象能力不够，甚至想到图都第一时间没想到图节点是如何表示的

class DirectedGraphNode {
  public:
    int tag;    //为了方便调试，这里标识一下是第几个节点
    int val;    //节点记录的值
    vector<DirectedGraphNode *> neighbors;                  //用vector记录其指向的所有下一个节点
    DirectedGraphNode(int t, int x) : tag(t), val(x) {};   //构造函数
};

计算并保存入度

由于这道题涉及到递归，已经记录一些全局的关键属性（路径条数还有最大值），因此在一个类中完成这个计算函数的编写，首先记录四个属性：

1. 图
2. 入度（可以在构造函数中完成计算）
3. 最大路径和
4. 路径数量

vector<DirectedGraphNode *> graph;
unordered_map<DirectedGraphNode *, int> degrees;
int maxSum;
int pathCount;

其中入度用一个图节点与整数的对应 map 记录，构造方式为首先遍历整个图的所有节点，在 map 中若没有这个节点的 key 则初始化为 0，若有则遍历这个节点是所有 neighbor 即指向的所有下一节点，并为其递增 1
，代码表示如下：

for (auto node: graph) {
    if (degrees.find(node) == degrees.end()) {
        degrees[node] = 0;
    }
    for (auto n:node->neighbors) {
        degrees[n]++;
    }
}

从入度为 0 的节点开始遍历

只有入度为 0 的节点能够被当作一条路径的起始节点

void findFromStart() {
    for (auto node:graph) {
        if (degrees[node] == 0) {
            //初始化一条路径
            vector<DirectedGraphNode *> path;
            //初始化这条路径的和
            int currentSum = 0;
            findPath(node, path, currentSum);
        }
    }
}

需要判断是否走到尽头，若走到尽头则需要决定是否记录这条路径的最大值以及路径总条数累加，若未走到尽头则递归调用：

void findPath(DirectedGraphNode *currentNode, vector<DirectedGraphNode *> currentPath, int currentSum) {
    //访问到这个节点，则将当前节点加入到路径中，当前节点的值也累加
    currentPath.push_back(currentNode);
    currentSum += currentNode->val;
    //走到路径尽头（出度为0）
    if (currentNode->neighbors.size() == 0) {
        //路径数目+1
        pathCount++;
        //计算并决定是否保留最大值
        if (currentSum > maxSum)
            maxSum = currentSum;
        return;
    }
    //继续向下寻找，并递归调用
    for (auto node:currentNode->neighbors) {
        findPath(node, currentPath, currentSum);
    }
}

总结并反思

首先是练习过少，这题其实是非常基础的图论算法题，仅仅是一个图的遍历而已，只是因为自己最近所做相关类型题目太少了于是短时间内没能想到比较好的思路。第二点就是最近所做的题都是类似 Leetcode 中非常直观的的给出了数据结构与算法需要完成什么，而这道题则有一个情景，并不是那么直接，于是自己理解题意与抽象数据结构有点失败。

秋招继续加油把，不要让我失望。

C 语言中变量可能并不是按照代码中声明变量的顺序分配在内存中的。

问题的发生

今天在读 C 陷阱与缺陷 一书时了解到数组边界赋值溢出时会覆盖其他变量的问题，书中例子是这样的，在a[10]的地方，数组a实际上一共只有 10 个元素而第十一个会溢出导致覆盖 i 被覆盖为 0 然后进入死循环：

int i, a[10];
for (i = 1; i <= 10; i++)
    a[i] = 0;

编译运行后并没有发生死循环，于是使用 gdb 调试看了看变量的地址：

发现变量 i 的地址在数组 a 的前面，想着可能是编译器不同顺序不太一样？于是我交换了顺序：

int a[10], i;
for (i = 1; i <= 10; i++)
    a[i] = 0;

i 的地址依然在 a 前面

这就让我比较疑惑了，我在代码中声明的顺序两次都不一样，为何编译运行两次结果都是 i 的地址在 a 的前面呢？

再次尝试

于是我又写下这样的代码，多定义几个变量，然后打印它们的地址试试：

int main(){
    int m=0;
    int n=0;
    int a[4]={1,2,3,4};
    int i=0;
    int j=0;
    int b[4]={5,6,7,8};
    printf("m: %p\n",&m);
    printf("n: %p\n",&n);
    printf("a[0]: %p\n",&(a[0]));
    printf("a[3]: %p\n",&(a[3]));
    printf("i: %p\n",&i);
    printf("j: %p\n",&j);
    printf("b[0]: %p\n",&(b[0]));
    printf("b[3]: %p\n",&(b[3]));
    return 0;

结果如下：

惊奇的发现，尽管我在代码中定义变量的顺序是m->n->a[4]->i->j->[b]，实际上它们在内存中按地址由低到高分布的顺序是m->n->i->j->a[4]->b[4]。经过多次尝试，发现这样不管我在代码中变量声明的顺序如何，整型数组的内存地址总是在单个整型变量的后面。

也许是在编译过程中做啦某些优化？随后尝试在编译时添加-O0关闭优化、以及输出预处理的代码结果都没有发现这个问题的所在。

问题所在：GCC 的栈溢出保护

在 Google 搜索许久只得到信息：C 的标准中并没有对局部变量的内存分配顺序有任何定义，因此不同的编译器完全有可以有自己的做法。

随后 V 站上朋友有提到 缓冲区溢出攻击 这个概念，突然就意识到了 GCC 可能就是为了安全起见作出的一些调整优化以避免栈溢出攻击。带着这个概念继续在 Google 上检索，GCC 确实有默认开启对栈溢出攻击的保护，并得到了 GCC 的一个编译选项可以强制关闭栈溢出保护：-fno-stack-protector。

重新编译运行：

按照变量在代码中定义的顺序，其在运行时内存分配的地址果然也变成了从高地址到低地址顺序分布了，不过仔细观察还是发现数组最后一个元素与下一个整型变量地址并不是连续的，中间还间隔了几个字节，也许是像结构体中内存对齐吧，不过我也不深究了。至于 GCC 是具体作出怎样的优化调整顺序来保护栈溢出，其文档上应该有所描述，我也不去详细查询了，了解到这里就好。

Least recently used (LRU) 最近最少使用的缓存替换策略，一次 get 或一次 put 都被称为使用。这个算法策略主要是记录容量有限的缓存中每个元素是都是何时使用的。

为了实现记录使用时序，我们可以使用一个list来记录 key-value pair，每次使用时都将这个 pair 移动到 list 的首部，为了什么要使用 list 而不是 array 或 vector 呢，正是因为我们的缓存的每次操作均会移动 list 中的元素位置，而元素位置移动频繁的情况下使用双向链表是最佳的选择，因为这个数据结构移动元素位置的开销是最小的，仅仅是改变了指针而已。

但是仅仅使用一个 list 还是做不到高效的查找，要做到平均时间复杂度为 O(1)的查找，就需要使用 map，因此还需要unordered_map结构来完成查询的操作，而需要注意的是其储存的不是 key-value 的键值对数据，因为需要的数据已经在上面的 list 中储存了，key 所对应储存的数据是上面 list 结构的迭代器，因此在查询值可以在平均 O(1)的时间内拿到一个 list 的迭代器，再通过这个迭代器以 O(1)的时间在 list 中获取 value。同时移动 list 的位置的开销依然是常数时间复杂度。

这个结构可以形象得以这张图表示：

基本数据结构声明

我们默认为 key-value 均储存的是 string 类型的数据

// cache的最大容量
size_t capacity;
// list 中储存的的是需要保存的键值对
// 读取时会将目标项移动到头部
// 写入是直接插入到头部
list<pair<string, string>> dataList;
// map 保存查找表，保存的是key与list迭代器的对应
// 每次查询时根据key从map拿到迭代器可以直接在list中得到相应value
unordered_map<string, list<pair<string, string>>::iterator> positionMap;

put 操作

向 LRU-Cache 中插入数据时，可以直接将 key-value 插入到 list 的首部，然后在 map 中查找给定的 key 是否已经存在，若已存在我们可以看作是替换 value 的操作，可以直接删除 map 与 list 中的原内容。然后再将新的 key 与指向 list 项的指针记录到 map 中

void put(string key, string value) {
    auto it = positionMap.find(key);
    //将 pair 插入到列表头部
    dataList.push_front({key, value});
    if (it != positionMap.end()) {
        dataList.erase(it->second);
        positionMap.erase(it);
    }
    positionMap[key] = dataList.begin();
}

get 操作

查找数据时，首先在 map 中查找 key 对应的内容是否存在，若不存在则表明 cache 中没有这一项内容，直接抛出错误，若存在则在 list 中的找到这一项，并使用splice将这一项移动到 list 的首部，因为我们最近使用它了，然后返回其 value。

string get(string key) {
    auto it = positionMap.find(key);
    //若map中未找到key，则返回错误信息
    if (it == positionMap.end()) {
        return "NotFound";
    }
    //在list中找到get的pair并将它移动并插入到list头部
    dataList.splice(dataList.begin(), dataList, it->second);
    return it->second->second;
}

put 时达到容量上限

若容量已满，则将 list 中最后一位（最近最久未使用的一项）从 list 与 map 中移除

if (positionMap.size() > capacity) {
    positionMap.erase(dataList.back().first);
    dataList.pop_back();
}

完整源代码

// LRU - Least Recently Used
#include <iostream>
#include <list>
#include <string>
#include <unordered_map>

using namespace std;

class LRUCache {
   public:
    LRUCache(int capacity) : capacity(capacity){};
    string get(string key) {
        auto it = positionMap.find(key);
        if (it == positionMap.end()) {
            return "NotFound";
        }
        dataList.splice(dataList.begin(), dataList, it->second);
        return it->second->second;
    }
    void put(string key, string value) {
        auto it = positionMap.find(key);
        dataList.push_front({key, value});
        if (it != positionMap.end()) {
            dataList.erase(it->second);
            positionMap.erase(it);
        }
        positionMap[key] = dataList.begin();
        if (positionMap.size() > capacity) {
            positionMap.erase(dataList.back().first);
            dataList.pop_back();
        }
    }

   private:
    size_t capacity;
    list<pair<string, string>> dataList;
    unordered_map<string, list<pair<string, string>>::iterator> positionMap;
};

int main() {
    LRUCache cache(10);
    cache.put("foo", "bar");
    cache.put("name", "ruofeng");
    cache.put("phone", "iPhone 7");
    cache.put("PC", "XPS 13");
    cache.put("CPU", "i5 7200U");
    cout << cache.get("name") << endl;
    cout << cache.get("PC") << endl;
    return 0;
}

哈希表 HashTable 是一个非常常用的数据结构，用于储存 k-v 键值对的数据。而且其插入、查找、删除的平均时间复杂度均为O(1)。为了了解到其内部实现，是如何实现高效的查询方式，参考了 https://github.com/jamesroutley/write-a-hash-table 使用 C 语言实现了一个简易的 HashTable。

基本结构

HashTable 中元素的最基本单位是 k-v 键值对，我们将其视为字符串，则有这样的结构：

typedef struct {
    char* key;
    char* value;
} ht_item;

HashTable 的基本表结构中包含表最大容量size、当前表中元素个数count，以及一个储存元素指针的数组ht_item** items：

typedef struct {
    int size;
    int count;
    ht_item** items;
} ht_hash_table;

新建与删除

对于每个表元素，与表本身，我们需要分别为其定义初始化的函数与删除结构的函数，初始化即分配内存，删除即释放内存。函数表示为static意味仅供内部调用，不允许外部调用，和面向对象中的private访问控制标识类似。

新建元素，参数为 k-v 字符串，主要为字符串分配内存

static ht_item* ht_new_item(const char* k, const char* v) {
    ht_item* i = malloc(sizeof(ht_item));
    i->key = malloc(strlen(k) + 1);
    strcpy(i->key, k);
    i->value = malloc(strlen(v) + 1);
    strcpy(i->value, v);
    return i;
}

新建表，初始化表空间大小，这里设定为 53，数量初始化为 0，并根据 size 给保存元素数组的items指针分配一定的内存并初始化

ht_hash_table* ht_new() {
    ht_hash_table* ht = malloc(sizeof(ht_hash_table));
    ht->size = 53;
    ht->count = 0;
    ht->items = calloc((size_t)ht->size, sizeof(ht_item*));
    return ht;
}

删除元素，直接释放内存

static void ht_del_item(ht_item* i) {
    free(i->key);
    free(i->value);
    free(i);
}

删除表，遍历整个表逐个释放元素内存，然后释放数组以及本身

void ht_del_hash_table(ht_hash_table* ht) {
    for (int i = 0; i < ht->size; i++) {
        ht_item* item = ht->items[i];
        if (item != NULL) {
            ht_del_item(item);
        }
    }
    free(ht->items);
    free(ht);
}

哈希函数

哈希表正是因为其索引的构建过程使用了哈希函数因此而得名。简单来讲，在向哈希表中插入一个 k-v 键值对时，首先需要对其 key 进行 hash，得到一个数，最为表中保存数组ht->items的索引即数组下标，然后再将 value 赋值给指定索引所指向元素的 value 中。hash 函数是单向的，对于不同的给定值通过 hash 后会得到不同的确定结果，且理想的 hash 函数，对于所有不同的给定值经过 hash 之后均会得到不同的结果。因此利用这一特性我们需要的 hash 函数将 key 计算后返回得到的是大小在表容量之内的一个确定结果作为储存的索引，在查询时也是计算 hash 然后将计算结果作为索引直接在数组中取值即可，这就是时间复杂度O(1)的原因。

这里实现一个对字符串的建议 hash 函数，这个 hash 函数需要这些参数，s为目标字符串，a为一个大于字母表的素数，我们需要 hash 的字符串是 ASCII 字符串，而 ASCII 大小为 128，这里可以取一个 151，m为容量，因为结果是数组的下标，计算结果不能够大于它，因此在运算中会与m进行求余运算：

static int ht_hash(const char* s, const int a, const int m) {
    long hash = 0;
    const int len_s = strlen(s);
    for (int i = 0; i < len_s; i++) {
        hash += (long)pow(a, len_s - (i+1)) * s[i];
        hash = hash % m;
    }
    return (int)hash;
}

这个函数给定一个字符串，会返回一个在 0-m 之间的数组作为索引。

哈希冲突

但是并不是所有的 hash 函数都是完美的，有可能发生冲突，即给定不同的输入，有一定可能返回了相同的 hash 结果。而且对于一个容量较小，储存数量较多的哈希表，添加新元素时，发生冲突的概率变得很大。因此我们需要解决并减少发生冲突的情况：

• 使用 开放地址 + 双重 HASH 的方法解决冲突
• 在容量达到一定阈值时，需要 resize 整张表

其中双重 HASH 在使用时会多一个参数i，并且会使用到两个不同的 hash 函数分别为hash_a与hash_b，最基本的形式如下：

index = hash_a(string) + i * hash_b(string) % num_buckets;

首次 hash 一个 key 时这个参数为 0，当没有冲突时，结果就是hash_a的结果；当发生冲突时，将 i 自增并计算两个 hash，但是hash_b的结果有一定可能为 0，此时的结果仍然是冲突的，因此作一点处理以保证其结果不会为 0：

index = (hash_a(string) + i * (hash_b(string) + 1)) % num_buckets;

具体实现如下，将原来函数的第二个参数改为两个不同的素数HT_PRIME_1、HT_PRIME_2作为两个 hash 函数

static int ht_get_hash(
    const char* s, const int num_buckets, const int attempt
) {
    const int hash_a = ht_hash(s, HT_PRIME_1, num_buckets);
    const int hash_b = ht_hash(s, HT_PRIME_2, num_buckets);
    return (hash_a + (attempt * (hash_b + 1))) % num_buckets;
}

基本操作

接下来是实现一个哈希表的基本操作：

• 插入
• 查找
• 删除
• 更新

插入（与更新）

插入操作首先初始化并对一个基本元素赋值，然后调用上一步完成的 hash 函数对 key 进行计算得到 index，然后拿到这个index在表中进行访问，若访问目标为NULL，表示这个地方是空闲的可以直接插入；若不为NULL代表发生了冲突，将 i 自增并再次 hash 并在表中查找，知道找到一个空地址可以进行插入。

更新操作可以在这里实现，直接替换原value即可。

void ht_insert(ht_hash_table* ht, const char* key, const char* value) {
    //新建元素结构
    ht_item* item = ht_new_item(key, value);
    //调用double hash返回作为hash表的索引
    int index = ht_get_hash(item->key, ht->size, 0);
    ht_item* cur_item = ht->items[index];
    int i = 1;
    // iterate through indexes until we find an empty bucket
    while (cur_item != NULL) {
        //找到匹配的key则覆盖value作为更新操作
        if (strcmp(cur_item->key, key) == 0) {
            ht_del_item(cur_item);
            ht->items[index] = item;
            return;
        }
        index = ht_get_hash(item->key, ht->size, i);
        cur_item = ht->items[index];
        i++;
    }
    //插入元素内容
    ht->items[index] = item;
    ht->count++;
}

查找

查找与插入的算法大致相同，只是在循环中判断索引处的 key 值是否匹配，若找到NULL则代表表中没有此项，直接返回空指针。

char* ht_search(ht_hash_table* ht, const char* key) {
    int index = ht_get_hash(key, ht->size, 0);
    ht_item* item = ht->items[index];
    int i = 1;
    //与插入元素类似，不过在循环中需要判断索引处的key值是否匹配
    //若索引处为NULL，则跳出循环直接返回NULL，表示未找到
    while (item != NULL) {
        if (strcmp(item->key, key) == 0) {
            return item->value;
        }
        index = ht_get_hash(key, ht->size, i);
        item = ht->items[index];
        i++;
    }
    return NULL;
}

删除

删除操作相对于插入与查找复杂一些，因为在找到对应 key 的元素时，不能直接将这个元素删除，因为这个元素可能位于冲突链的一部分，若是这样，将其释放为NULL，当下次查找这个冲突链删除掉的元素后面一个元素时，找到前面被删除的元素发现为NULL就会直接返回未找到了，而不会继续在冲突链中计算 hash 并继续查找。因此需要使用标识删除 instead of 直接删除。方式可以将这个节点指向一个定义的全局的代表以删除的节点即可：

//删除标记
static ht_item HT_DELETED_ITEM = {NULL, NULL};
//删除操作
void ht_delete(ht_hash_table* ht, const char* key) {
    //先搜索到
    int index = ht_get_hash(key, ht->size, 0);
    ht_item* item = ht->items[index];
    int i = 1;
    while (item != NULL) {
        if (item != &HT_DELETED_ITEM) {
            if (strcmp(item->key, key) == 0) {
                ht_del_item(item);
                //置删除标志
                ht->items[index] = &HT_DELETED_ITEM;
            }
        }
        index = ht_get_hash(key, ht->size, i);
        item = ht->items[index];
        i++;
    }
    ht->count--;
}

改进删除方式后，在前面的插入与查找操作中就要作一定的改进。这里不做具体描述。

更新表大小

前面知道，当一个表在快要满时，hash 冲突的概率会变大，因此在这个时候我们需要重新修改表的容量，以容纳更多的元素与减少冲突概率。可以在每次插入与删除时计算一个load=count/size作为 resize 的标准，

• load > 0.7 则容量翻倍
• load < 0.1 则容量减半

更改容量大小的操作即新建一个目标容量的表作然后将原表内容复制过去，然后交换表中的属性（size与base_size）与所有内容（items），然后删除新表，这样原来表的容量被改变但是指向原表的指针未变。然而这个操作是比较耗时的，因此也需要根据使用情景设定合理的阈值、增大减小容量的标准、初始容量，来尽量避免在使用时的 resize 操作。

在实现 resize 操作时，在表结构体中新增加一个base_size作为基础容量，size为实际容量（大于base_size的第一个素数）

//重新分配大小
static void ht_resize(ht_hash_table* ht, const int base_size) {
    //size小于初始容量时不再减少
    if (base_size < HT_INITIAL_BASE_SIZE) {
        return;
    }
    //新建一张表，并复制原表的所有数据
    ht_hash_table* new_ht = ht_new_sized(base_size);
    for (int i = 0; i < ht->size; i++) {
        ht_item* item = ht->items[i];
        if (item != NULL && item != &HT_DELETED_ITEM) {
            ht_insert(new_ht, item->key, item->value);
        }
    }

    //修改原表的属性
    ht->base_size = new_ht->base_size;
    ht->count = new_ht->count;

    //为了删除新表，将原表的size与base_size属性赋值给新表
    const int tmp_size = ht->size;
    ht->size = new_ht->size;
    new_ht->size = tmp_size;

    //将原表与新表的内容items交换
    ht_item** tmp_items = ht->items;
    ht->items = new_ht->items;
    new_ht->items = tmp_items;

    //删除新表
    ht_del_hash_table(new_ht);
}

//增大容量
static void ht_resize_up(ht_hash_table* ht) {
    const int new_size = ht->base_size * 2;
    ht_resize(ht, new_size);
}

//缩小容量
static void ht_resize_down(ht_hash_table* ht) {
    const int new_size = ht->base_size / 2;
    ht_resize(ht, new_size);
}

在插入删除元素时之前需要计算load并判断是否需要 resize：

void ht_insert(ht_hash_table* ht, const char* key, const char* value) {
    const int load = ht->count * 100 / ht->size;
    if (load > 70) {
        ht_resize_up(ht);
    }
    // ...
}

void ht_delete(ht_hash_table* ht, const char* key) {
    const int load = ht->count * 100 / ht->size;
    if (load < 10) {
        ht_resize_down(ht);
    }
    // ...
}

测试

接下来在 main 函数中进行测试：

#include <stdio.h>
#include <stdlib.h>
#include "src/hash_table.h"

int main(int argc, char const* argv[]) {
    // new hashtable
    ht_hash_table* ht = ht_new();

    // insert into hashtable
    ht_insert(ht, "foo", "bar");
    ht_insert(ht, "name", "ruofeng");
    ht_insert(ht, "number", "41524226");

    // search from hashtable
    printf("%s\n", ht_search(ht, "foo"));
    printf("%s\n", ht_search(ht, "name"));

    // update test
    ht_insert(ht, "foo", "barr");
    printf("%s\n", ht_search(ht, "foo"));

    // key not exsit test
    if (ht_search(ht, "not") == NULL) printf("%s\n", "key(not) doesn't exist");

    // delete key test
    ht_delete(ht, "foo");
    if (ht_search(ht, "foo") == NULL) printf("%s\n", "key(foo) doesn't exist");

    // delete hash table
    ht_del_hash_table(ht);

    return 0;
}

编译并运行：

gcc -g ./src/hash_table.c ./src/prime.c main.c -std=c11 -o ./build/main -lm
./build/main

运行结果

$ ./build/main
bar
ruofeng
barr
key(not) doesn't exist
key(foo) doesn't exist

源代码

所有可执行源代码可在我的 GitHub 找到：

https://github.com/abowloflrf/hash-table

其实从去年年底开始就发现，站点上了 HTTPS 之后就会间歇性得无法访问，而同时 HTTP 访问却正常，初步觉得是位服务器于机场横行的日本，丢包拥塞极高导致的问题，于是就迁移过一次服务器，从日本到了美西，延迟上来了但是丢包低点不过访问暂时也正常了。

不过最近两个月又开始如此抽风，而且V站上也逐渐有发帖，有挺多人发现了这个情况，具体原因并不好查明，但是确实是国外一些服务商或 IP 会被重点照顾，在 TLS 握手的时候，只有一个 Client Hello，Server Hello 不知道死在了回国的哪一条路由上，导致 TLS 握手失败，Chrome 永远卡在 Establishing Secure Connection 上。作为个人技术博客，要回到 HTTP 确实会能稳定访问，可是似乎显得又不太合适，Not Secure 挂在地址栏过于丑陋。想着，再迁一次站吧，看看会不会好些吧，也许呢。

还好 Ghost 的迁移过程很顺利，需要备份的数据就两样：

1. 文本数据（直接在 Ghost 后台 export 打包成 json 就可以了，不需要去数据库备份）
2. 图片（content/images 打个包）

具体过程

1. 导出 json
2. 打包图片
3. 修改域名 DNS 指向新服务器
4. 新服务器安装 Node，ghost-cli 后新建一个站
5. 进入新站目录解压图片
6. 进入新站后台，导入 json
7. 使用acme.sh签新证书（顺便试试野卡）
8. 配置 Nginx 证书
9. ghost config将域名修改为https
10. 完成

高性能缓存数据库一般我们使用的有两种，一个是 Redis，一个就是 Memcached，其中 Redis 支持 5 种不同的数据类型操作，除了缓存外还支持数据持久化，甚至可以当作一个高性能 K-V 数据库来使用；Memcached 则是一个更加纯粹的缓存，只有 K-V 储存结构，不支持持久化，使用起来也非常简单。

在 Memcached 官网 中是这样描述它的：

memcached is a high-performance, distributed memory object caching system, generic in nature, but originally intended for use in speeding up dynamic web applications by alleviating database load.

PHP 中的使用

在 PHP 中使用 Memcached 有两种方式：

• memcached 使用 libmemcached 实现，支持操作多性能高
• memcache 使用纯 PHP 实现，最初的 PHP 操作 memcached 扩展

这里直接使用 C 语言实现的 PHP 扩展 php-memcached，为了方便直接只用包管理工具安装：

sudo apt install memcached
sudo apt install php-memcached

使用举例

在了解到 Memcached 的基本使用操作之后，我在之前写过的一个短链实现中加入的一层缓存的操作，在短链数据量巨大时每次从一个巨大的表中查询一条短链明显会非常耗时，而在这种典型的 读>>写 的操作中，使用缓存是一个很不错的选择。

典型的缓存使用流程图

在 Slim Framework 中加入依赖

在dependencies.php中加入：

//Memcached
$container['memcached'] = function ($container) {
    $mc = new Memcached();
    $mc->addServer("127.0.0.1", 11211);
    return $mc;
};

加入缓存使用逻辑

最初实现的短链接跳转中，是很直接的读取到路由中的参数然后将这个参数在 MySQL 中查询对应的完整链接返回然后跳转，现在加入缓存机制后，首先是在 Memcached 中查询短链接对应的缓存是否存在，若存在则直接读取数据并返回跳转即可，若不存在则在 MySQL 中查询，得到完整链接后，将这条记录种在 Memcached 中，再返回响应。

    //使用Mamcached作为缓存
    public function redirect(Request $request, Response $response, array $args)
    {
        //短域名格式不匹配，返回404
        if (!preg_match('/^[a-zA-Z0-9]{6}$/', $args['url'])) {
            return $response->withStatus(404)
                ->withHeader('Content-Type', 'text/html')
                ->write('404 Page not found');
        }
        //从缓存中查找
        $inCache = $this->mc->get('url_' . $args['url']);
        if ($inCache) {
            return $response->withRedirect($inCache, 301);
        } else {
            //从数据库中查询完整域名并跳转
            $result = $this->url->where('url_short', $args['url'])->first();
            if ($result) {
                //种缓存
                $this->mc->set('url_' . $args['url'], $result->url_full);
                //跳转到目标链接
                return $response->withRedirect($result->url_full, 301);
            }
            //未查询到域名则跳转到首页
            else {
                return $response->withRedirect('/', 301);
            }
        }
    }

对比压测

我同时保留了一个不读取缓存的路由/s/URL_S，来与加入缓存后进行对比测试:

• ab -n1000 http://127.0.0.1:8080/mN8r9q

Concurrency Level:      1
Time taken for tests:   2.388 seconds
Complete requests:      1000
Failed requests:        0
Non-2xx responses:      1000
Total transferred:      349000 bytes
HTML transferred:       0 bytes
Requests per second:    418.83 [#/sec] (mean)
Time per request:       2.388 [ms] (mean)
Time per request:       2.388 [ms] (mean, across all concurrent requests)
Transfer rate:          142.75 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     2    2   1.2      2      30
Waiting:        0    2   1.2      2      30
Total:          2    2   1.2      2      30

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      3
  75%      3
  80%      3
  90%      3
  95%      3
  98%      4
  99%      4
 100%     30 (longest request)

• ab -n1000 http://127.0.0.1:8080/s/mN8r9q

Concurrency Level:      1
Time taken for tests:   3.537 seconds
Complete requests:      1000
Failed requests:        0
Non-2xx responses:      1000
Total transferred:      349000 bytes
HTML transferred:       0 bytes
Requests per second:    282.73 [#/sec] (mean)
Time per request:       3.537 [ms] (mean)
Time per request:       3.537 [ms] (mean, across all concurrent requests)
Transfer rate:          96.36 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     2    3  17.9      3     567
Waiting:        2    3  17.7      3     564
Total:          2    4  17.9      3     567

Percentage of the requests served within a certain time (ms)
  50%      3
  66%      3
  75%      3
  80%      3
  90%      3
  95%      4
  98%      4
  99%      5
 100%    567 (longest request)

每秒请求分别为418与282，不过由于 MySQL 本身就应该有查询缓存的机制，差距可能不是太明显，不过显然性能差距还是在这里体现出来了。

在谈论数据库中的索引时，一般所指的是B-Tree索引

B-Tree

• 正整数 d 定义为 B-Tree 的度 Degree
• 也有一个定义 B-Tree 的属性称为阶 Order，其值为 2d
• 每个非叶子节点有 n-1 个 key 与 n 个指针，key 与指针相互间隔，key 的两端是指针，d≤n≤2d
• 每个叶子节点至少包含一个 key 和两个指针，最多包含 2d-1 个 key 与 2d 个指针，叶子节点的指针均为 null
• 每个节点中 key 从左至右非递减排序
• 所有叶子节点的深度相同，等于树高 h

B-Tree 的检索

查找：首先在根节点二分查找，找到则返回响应节点的数据，未找到则在相应区间指针指向的子节点中递归二分查找，直到查找到指定的 key 表明查找成功，或者到 null 表示查找失败。

插入：我们知道在一个度为 d 的 B-Tree 里，每个节点最多 2d 个子节点，同时除了根节点和叶子节点每个节点至少有 d 个子节点（d≤n≤2d），若根节点不是叶子节点则至少应该有 2 个子节点。要向 B-Tree 中插入一个元素时，首先从根节点查找到这个元素应该位于的位置，若这个节点的子节点数小于最大容量，则可以直接将这个元素插入到应该的位置；若这个节点的子节点数已经到了最大容量，则应当将其插入后从中间一个元素分裂，中间的元素移动到父节点，左边的元素组合作为其左子节点，右边的元素组合作为其右子节点。同样地，若父节点也满，则按照同样的分裂方式继续向上分裂。若到了根节点发现根节点也满了，则将根节点也分裂，中间元素作为顶部一个新的根节点。

删除：在 B-Tree 中删除一个元素时，首先同样地在树中查找到目标元素，然后将其删除，但是由于 B-Tree 的限制：除了根节点与叶子节点每个节点至少有 d 个子节点，根节点至少有 2 个子节点。所以删除后若不满足这个条件即 key 过少，则应首先从子节点取一个元素，若子节点无法取，则向父节点取，然后再将子节点中的中间值替换到原来父节点元素的位置。

B+Tree

与 B-Tree 相比，B+Tree 索引有以下特点

• 非叶子节点只保存 key 而不保存 data
• 叶子节点只保存 data
• B+Tree 的非叶子节点只进行索引不会保存实际记录的指针，所有数据必须要访问到叶子节点才能得到
• B+Tree 的根节点的 Key 数与子节点数相等
• 一般会将 B+Tree 进行优化：在叶子节点新增了一个顺序访问的指针，方便对所有的叶子节点进行遍历，提高区间访问的性能

B-Tree 在 MySQL 的索引中的实现

有这样一个数据表：

CRETE TABLE People(
    last_name varchar(50) not null,
    first_name varchar(50) not null,
    dob date not null,
    gender enum('m','f') not null,
    key(last_name, first_name, dob)
);

对于这个表中的每一行数据，索引中包含了 last_name , first_name , dob 列的值

如图所示，索引对多个值排序的依据是 create 语句中定义索引时的顺序，如这个表中两个人的姓名均一样，则按照其生日来排序。

可以使用 B-Tree 索引的查询类型

• 全值匹配
• 匹配最左前缀
• 匹配列前缀
• 匹配范围值
• 精确匹配某一列并范围匹配另一列
• 只访问索引的查询

使用 B-Tree 索引的一些限制

• 如果不是按照索引的最左列开始查找则无法使用索引，例如上面例子中无法查找名为 Bill 的人，也无法查找特定生日的人
• 不能跳过索引中的列，上例中索引无法用于查找某确定姓氏，同时又是某日生日的人，因为其跳过了中间一列
• 如果查询中有某个列的范围查询，则其右边的列都无法使用索引优化查找