详解 Kubernetes StatefulSet 实现原理

发布于

在 Kubernetes 的世界中，ReplicaSet 和 Deployment 主要用于处理无状态的服务，无状态服务的需求往往非常简单并且轻量，每一个无状态节点存储的数据在重启之后就会被删除，虽然这种服务虽然常见，但是我们仍然需要有状态的服务来实现一些特殊的需求，StatefulSet 就是 Kubernetes 为了运行有状态服务引入的资源，例如 Zookeeper、Kafka 等。

这篇文章会介绍 Kubernetes 如何在集群中运行有状态服务，同时会分析这些有状态服务 StatefulSet 的同步过程以及实现原理。

概述

StatefulSet 是用于管理有状态应用的工作负载对象，与 ReplicaSet 和 Deployment 这两个对象不同，StatefulSet 不仅能管理 Pod 的对象，还它能够保证这些 Pod 的顺序性和唯一性。

与 Deployment 一样，StatefulSet 也使用规格中声明的 template 模板来创建 Pod 资源，但是这些 Pod 相互之间是不能替换的；除此之外 StatefulSet 会为每个 Pod 设置一个单独的持久标识符，这些用于标识序列的标识符在发生调度时也不会丢失。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

如果我们在 Kubernetes 集群中创建如上所示的 StatefulSet 对象，会得到以下结果，Kubernetes 不仅会创建 StatefulSet 对象，还会自动创建两个 Pod 副本：

$ kubectl get statefulsets.apps
kNAME   READY   AGE
web    2/2     2m27s

$ kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
web-0   1/1     Running   0          2m31s
web-1   1/1     Running   0          105s

$ kubectl get persistentvolumes
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS       REASON   AGE
pvc-19ef374f-39d1-11e9-b870-9efb418608da   1Gi        RWO            Delete           Bound    default/www-web-1   do-block-storage            21m
pvc-fe53d5f7-39d0-11e9-b870-9efb418608da   1Gi        RWO            Delete           Bound    default/www-web-0   do-block-storage            21m

$ kubectl get persistentvolumeclaims
NAME        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
www-web-0   Bound    pvc-fe53d5f7-39d0-11e9-b870-9efb418608da   1Gi        RWO            do-block-storage   21m
www-web-1   Bound    pvc-19ef374f-39d1-11e9-b870-9efb418608da   1Gi        RWO            do-block-storage   21m

除此之外，上述 YAML 文件中的 volumeClaimTemplates 配置还会创建持久卷PersistentVolume 和用于绑定持久卷和 Pod 的 PersistentVolumeClaim 资源；两个 Pod 对象名中包含了它们的序列号，该序列号会在 StatefulSet 存在的时间内保持不变，哪怕 Pod 被重启或者重新调度，也不会出现任何的改变。

graph TD
  SS[StatefulSet]-.->Pod1
  SS[StatefulSet]-.->Pod2
  Pod1-.-PersistentVolumeClaim1
  Pod2-.-PersistentVolumeClaim2
  PersistentVolumeClaim1-.->PersistentVolume1
  PersistentVolumeClaim2-.->PersistentVolume2

StatefulSet 的拓扑结构和其他用于部署的资源其实比较类似，比较大的区别在于 StatefulSet 引入了 PV 和 PVC 对象来持久存储服务产生的状态，这样所有的服务虽然可以被杀掉或者重启，但是其中的数据由于 PV 的原因不会丢失。

这里不会展开介绍 PV 和 PVC，感兴趣的读者可以阅读 详解 Kubernetes Volume 的实现原理 了解 Kubernetes 存储系统的实现原理。

实现原理

与 ReplicaSet 和 Deployment 资源一样，StatefulSet 也使用控制器的方式实现，它主要由 StatefulSetController、StatefulSetControl 和 StatefulPodControl 三个组件协作来完成 StatefulSet 的管理，StatefulSetController 会同时从 PodInformer 和 ReplicaSetInformer 中接受增删改事件并将事件推送到队列中：

graph TD
    PI[PodInformer]-. Add/Update/Delete .->SSC[StatefulSetController]
    RSI[ReplicaSetInformer]-. Add/Update/Delete .->SSC
    SSC-->worker1
    SSC-. Add StatefulSet .->queue
    worker1-. Loop .->worker1
    queue-. Get StatefulSet .->worker1
    SSC-->worker2
    worker2-. Loop .->worker2
    queue-. Get StatefulSet .->worker2
    style worker1 fill:#fffede,stroke:#ebebb7
    style worker2 fill:#fffede,stroke:#ebebb7

控制器 StatefulSetController 会在 Run 方法中启动多个 Goroutine 协程，这些协程会从队列中获取待处理的 StatefulSet 资源进行同步，接下来我们会先介绍 Kubernetes 同步 StatefulSet 的过程。

同步

StatefulSetController 使用 sync 方法同步 StatefulSet 资源，这是同步该资源的唯一入口，下面是这个方法的具体实现：

func (ssc *StatefulSetController) sync(key string) error {
	namespace, name, _ := cache.SplitMetaNamespaceKey(key)
	set, _ := ssc.setLister.StatefulSets(namespace).Get(name)

	ssc.adoptOrphanRevisions(set)

	selector, _ := metav1.LabelSelectorAsSelector(set.Spec.Selector)
	pods, _ := ssc.getPodsForStatefulSet(set, selector)

	return ssc.syncStatefulSet(set, pods)
}

func (ssc *StatefulSetController) syncStatefulSet(set *apps.StatefulSet, pods []*v1.Pod) error {
	ssc.control.UpdateStatefulSet(set.DeepCopy(), pods); err != nil
	return nil
}
  1. 先重新获取 StatefulSet 对象；
  2. 收养集群中与 StatefulSet 有关的孤立控制器版本；
  3. 获取当前 StatefulSet 对应的全部 Pod 副本；
  4. 调用 syncStatefulSet 方法同步资源；

syncStatefulSet 方法只是将方法的调用转发到了一个 StatefulSetControlInterface 的实现 defaultStatefulSetControl 上，StatefulSetControlInterface 定义了用与控制 StatefulSet 和 Pod 副本的接口，这里调用的 UpdateStatefulSet 函数执行了一个 StatefulSet 的核心逻辑，它会负责获取 StatefulSet 版本、更新 StatefulSet 以及它的状态和历史：

func (ssc *defaultStatefulSetControl) UpdateStatefulSet(set *apps.StatefulSet, pods []*v1.Pod) error {
	revisions, err := ssc.ListRevisions(set)
	history.SortControllerRevisions(revisions)

	currentRevision, updateRevision, collisionCount, err := ssc.getStatefulSetRevisions(set, revisions)

	status, err := ssc.updateStatefulSet(set, currentRevision, updateRevision, collisionCount, pods)

	ssc.updateStatefulSetStatus(set, status)

	return ssc.truncateHistory(set, pods, revisions, currentRevision, updateRevision)
}

它会使用默认的单调递增策略，按照升序依次创建副本并按照降序删除副本，当出现 Pod 处于不健康的状态时，那么新的 Pod 就不会被创建，StatefulSetController 会等待 Pod 恢复后继续执行下面的逻辑。

上述代码会在获取 StatefulSet 的历史版本之后调用 updateStatefulSet 方法开始更新 StatefulSet，这个将近 300 行的代码会按照执行以下的执行：

  1. 将当前 StatefulSet 持有的 Pod 副本按照序列号进行分组，超出数量的副本将被分入 condemned 中等待后续的删除操作，这次同步中需要保留的副本将进入 replicas 分组；
  2. 对当前的 StatefulSet 进行扩容，让集群达到目标的副本数；
  3. 获取副本数组中第一个不健康的 Pod；
  4. 根据副本的序列号检查各个副本的状态；
    • 如果发现了失败的副本就会进行重启；
    • 如果当前副本没有正常运行就会退出循环，直到当前副本达到正常运行的状态；
  5. 按照降序依次删除 condemned 数组中的副本；
  6. 按照降序依次更新 replicas 数组中的副本；
func (ssc *defaultStatefulSetControl) updateStatefulSet(set *apps.StatefulSet, currentRevision *apps.ControllerRevision, updateRevision *apps.ControllerRevision, collisionCount int32, pods []*v1.Pod) (*apps.StatefulSetStatus, error) {
	currentSet, _ := ApplyRevision(set, currentRevision)
	updateSet, _ := ApplyRevision(set, updateRevision)

	status := apps.StatefulSetStatus{}
	// ...

	replicaCount := int(*set.Spec.Replicas)
	replicas := make([]*v1.Pod, replicaCount)
	condemned := make([]*v1.Pod, 0, len(pods))
	unhealthy := 0
	var firstUnhealthyPod *v1.Pod

	for i := range pods {
		if ord := getOrdinal(pods[i]); 0 <= ord && ord < replicaCount {
			replicas[ord] = pods[i]
		} else if ord >= replicaCount {
			condemned = append(condemned, pods[i])
		}
	}

	sort.Sort(ascendingOrdinal(condemned))

	for ord := 0; ord < replicaCount; ord++ {
		if replicas[ord] == nil {
			replicas[ord] = newVersionedStatefulSetPod(currentSet, updateSet, currentRevision.Name, updateRevision.Name, ord)
		}
	}

这里通过 StatefulSet 应该持有的副本数对当前的副本进行分组，一部分是需要保证存活的 replicas，另一部分是需要被终止的副本 condemned，如果分组后的 replicas 数量不足，就会通过 newVersionedStatefulSetPod 函数创建新的 Pod，不过这里的 Pod 也只是待创建的模板。

kubernetes-statefulset-parititon

拿到线上应该存在的 replicas 数组时，我们就可以进行通过 CreateStatefulPod 进行扩容了，每个 Pod 的更新和创建都会等待前面所有 Pod 正常运行，它会调用 isFailed、isCreated、isTerminating 等方法保证每一个 Pod 都正常运行时才会继续处理下一个 Pod，如果使用滚动更新策略，那么会在完成扩容之后才会对当前的 Pod 进行更新：

	for i := range replicas {
		if isFailed(replicas[i]) {
			ssc.podControl.DeleteStatefulPod(set, replicas[i])
			replicas[i] = newVersionedStatefulSetPod(i)
		}
		if !isCreated(replicas[i]) {
			ssc.podControl.CreateStatefulPod(set, replicas[i])
			return &status, nil
		}
		if isTerminating(replicas[i]) || !isRunningAndReady(replicas[i]) {
			return &status, nil
		}
		if identityMatches(set, replicas[i]) && storageMatches(set, replicas[i]) {
			continue
		}
		replica := replicas[i].DeepCopy()
		ssc.podControl.UpdateStatefulPod(updateSet, replica)
	}

当 StatefulSetController 处理完副本的创建和更新任务之后，就开始删除需要抛弃的节点了，节点的删除也需要确定按照降序依次进行：

	for target := len(condemned) - 1; target >= 0; target-- {
		if isTerminating(condemned[target]) {
			return &status, nil
		}
		if !isRunningAndReady(condemned[target]) && condemned[target] != firstUnhealthyPod {
			return &status, nil
		}

		ssc.podControl.DeleteStatefulPod(set, condemned[target])
		return &status, nil
	}

	updateMin := 0
	if set.Spec.UpdateStrategy.RollingUpdate != nil {
		updateMin = int(*set.Spec.UpdateStrategy.RollingUpdate.Partition)
	}
	for target := len(replicas) - 1; target >= updateMin; target-- {
		if getPodRevision(replicas[target]) != updateRevision.Name && !isTerminating(replicas[target]) {
			ssc.podControl.DeleteStatefulPod(set, replicas[target])
			return &status, err
		}

		if !isHealthy(replicas[target]) {
			return &status, nil
		}
	}
	return &status, nil
}

我们首先会删除待抛弃列表中的副本，其次根据滚动更新 RollingUpdate 的配置从高到低依次删除所有 Pod 版本已经过时的节点，所有删除节点的方式都会通过 DeleteStatefulPod 方法进行，该方法会通过客户端的接口直接根据 Pod 名称删除对应的资源。

序列号

Pod 的序列号（Ordinal）是其唯一性和顺序性的保证，在创建和删除 StatefulSet 的副本时，我们都需要按照 Pod 的序列号对它们按照顺序操作，副本的创建会按照序列号升序处理，副本的更新和删除会按照序列号降序处理。

kubernetes-statefulset-ordina

创建 StatefulSet 中的副本时，就会在 newStatefulSetPod 函数中传入当前 Pod 的 ordinal 信息，该方法会调用 GetPodFromTemplate 获取 StatefulSet 中的 Pod 模板并且初始化 Pod 的 metadata 和引用等配置：

func newStatefulSetPod(set *apps.StatefulSet, ordinal int) *v1.Pod {
	pod, _ := controller.GetPodFromTemplate(&set.Spec.Template, set, metav1.NewControllerRef(set, controllerKind))
	pod.Name = getPodName(set, ordinal)
	initIdentity(set, pod)
	updateStorage(set, pod)
	return pod
}

func getPodName(set *apps.StatefulSet, ordinal int) string {
	return fmt.Sprintf("%s-%d", set.Name, ordinal)
}

getPodName 函数的实现非常简单，它将 StatefulSet 的名字和传入的序列号通过破折号连接起来组成我们经常见到的 web-0、web-1 等形式的副本名；initIdentity 会更新 Pod 的主机名、资源名、命名空间标签，而 updateStorage 会为待创建的副本设置卷：

func updateStorage(set *apps.StatefulSet, pod *v1.Pod) {
	currentVolumes := pod.Spec.Volumes
	claims := getPersistentVolumeClaims(set, pod)
	newVolumes := make([]v1.Volume, 0, len(claims))
	for name, claim := range claims {
		newVolumes = append(newVolumes, v1.Volume{
			Name: name,
			VolumeSource: v1.VolumeSource{
				PersistentVolumeClaim: &v1.PersistentVolumeClaimVolumeSource{
					ClaimName: claim.Name,
					ReadOnly: false,
				},
			},
		})
	}
	for i := range currentVolumes {
		if _, ok := claims[currentVolumes[i].Name]; !ok {
			newVolumes = append(newVolumes, currentVolumes[i])
		}
	}
	pod.Spec.Volumes = newVolumes
}

设置卷的配置主要来自于 StatefulSet 规格中的 volumeClaimTemplates 模板，所有卷相关的配置信息都会通过该方法传递过来。

Pod 通过当前名字存储自己对应的序列号，在 StatefulSetController 同步时就会从 Pod 的名字中取出序列号并进行排序，随后的各种循环就可以选择使用正序或者倒序的方式依次处理各个节点了。

删除

当我们删除一个 Kubernetes 中的 StatefulSet 资源时，它对应的全部 Pod 副本都会被 垃圾收集器 自动删除，该收集器在检查到当前 Pod 的 metadata.ownerReferences 已经不再存在时就会删除 Pod 资源，读者可以阅读 垃圾收集器 了解具体的执行过程和实现原理。

$ kubectl delete statefulsets.apps web
statefulset.apps "web" deleted

$ kubectl get pods --watch
NAME    READY   STATUS    RESTARTS   AGE
web-2   1/1   Terminating   0     14h
web-1   1/1   Terminating   0     14h
web-0   1/1   Terminating   0     14h

我们会发现除了 StatefulSet 和 Pod 之外的任何其他资源都没有被删除，之前创建的 PersistentVolume 和 PersistentVolumeClaim 对象都没有发生任何的变化，这也是 StatefulSet 的行为，它会在服务被删除之后仍然保留其中的状态，也就是数据，这些数据就都存储在 PersistentVolume 中。

如果我们重新创建相同的 StatefulSet，它还会使用之前的 PV 和 PVC 对象，不过也可以选择手动删除所有的 PV 和 PVC 来生成新的存储，这两个对象都属于 Kubernetes 的存储系统，感兴趣的读者可以通过 存储系统 了解 Kubernetes 中 Volume 的设计和实现。

总结

StatefulSet 是 Kubernetes 为了处理有状态服务引入的概念，在有状态服务中，它为无序和短暂的 Pod 引入了顺序性和唯一性，使得 Pod 的创建和删除更容易被掌控和预测，同时加入 PV 和 PVC 对象来存储这些 Pod 的状态，我们可以使用 StatefulSet 实现一些偏存储的有状态系统，例如 Zookeeper、Kafka、MongoDB 等，这些系统大多数都需要持久化的存储数据，防止在服务宕机时发生数据丢失。

来源：https://draveness.me/kubernetes-statefulset/

评论

发表评论

此博客中的热门博文

百度网盘资源搜索网站大全

发布于
https://www.h2ero.com/    [闪电云]  https://www.aisouziyuan.com/    [爱搜资源]  http://www.pansoso.com/    [盘搜搜]  https://www.yunpanjingling.com/    [云盘精灵]  https://www.52sopan.com/    [我爱搜盘]  https://yunpanem.com/    [云盘恶魔]  http://www.xiaobaipan.com/    [小白盘]  https://nyaso.com/    [喵搜动漫]  https://www.fqsousou.com/    [番茄搜搜]  http://www.shiyue.org/    [十月搜索]  http://www.sopanba.com/    [搜盘吧]  https://www.xiaobd.net/    [小不点搜索]  http://www.panduoduo.net/    [盘多多]  http://www.slimego.cn/    [史莱姆]  http://www.kengso.com/    [坑搜网]  http://www.repanso.com    [热盘搜]  http://www.panmeme.com/    [盘么么]  http://wx01.51caichang.com/    [51网盘]  http://wx.haogow.com/    [西部维度]  http://wx.xingtuhua.com/    [商务中国]...
阅读全文

awk查看与统计nginx访问日志

发布于
切割日志 查找7月16日访问log导出到17.log文件中： cat web_access.log | egrep "17/Jul/2017" | sed -n '/00:00:00/,/23:59:59/p' > /tmp/16.log 查看访问量前10的IP awk '{print $1}' web_access.log | sort | uniq -c | sort -nr | head -n 10 查看访问前10的URL awk '{print $11}' web_access.log | sort | uniq -c | sort -nr | head -n 10 查询访问最频繁的URL awk '{print $7}' web_access.log | sort | uniq -c | sort -n -k 1 -r | more 查询访问最频繁的IP awk '{print $1}' web_access.log | sort | uniq -c | sort -n -k 1 -r | more 根据访问IP统计UV awk '{print $1}' web_access.log | sort | uniq -c | wc -l 统计访问URL统计PV awk '{print $7}' web_access.log | wc -l 根据时间段统计查看日志 cat web_access.log | sed -n '/17\/Jul\/2017:12/,/17\/Jul\/2017:13/p' | more https://blog.csdn.net/zhengholien/article/details/78006887
阅读全文

ELK实时分析之php的laravel项目日志

发布于
最近因公司项目增多，且环境也越来复杂，开发人员找我查看错误日志越来越频繁，心里便念想到ELK，心之所想，念之所达，快来get一项新技能吧 1、系统架构组成 laravel日志：日志源通过filebeat将日志写进redis中间件 logstsh：logstash通过input将redis数据拿来分析，通过其filter模块分析所需要的语句，然后输出到elasticsearch 3.elasticsearch 接收logstash发送过来的数据，并提供了一个分布式多用户能力的全文搜索引擎 Kibana是一个优秀的前端日志展示框架，它可以非常详细的将日志转化为各种图表，为用户提供强大的数据可视化支持。 二、各个服务的ip地址 laravel: 172.18.109.227 redis: 172.18.215.207 elasticsearch: 172.18.215.207 kibana: 172.18.215.207 复制代码 三、laravel日志服务器配置： 配置filebeat yum源文件 [elastic-5.x] name=Elastic repository for 5.x packages baseurl=https://artifacts.elastic.co/packages/5.x/yum gpgcheck=1 gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch enabled=1 autorefresh=1 type =rpm-md 复制代码 安装filebeat yum install filebeat 复制代码 配置filebeat配置文件 ... #写入源 - input_type: log paths: - /var/www/html/*/storage/logs/laravel-2018-12-29.log ... #输出至redis output.redis: # Array of hosts to connect to. hosts: [ "172.18.215.207:6379" ] password: "***********" db: 0 timeout: 5...
阅读全文

Windows 操作系统微软官方镜像

发布于
  Windows 发布信息详细版本 常用系统版本（按发布日期最新到最旧） 系统大小(ISO) 是否需要激活 ISO文件SHA-1 相关工具 Windows 10 简体中文企业版2019长期服务版64位 4.71GB 是 24B59706D5EDED392423936C82BA5A83596B50CC HEU_KMS & MAS Windows 10 简体中文企业版2019长期服务版32位 2.98GB 是 BA2169EDD94F123211CD4AACA68352F1AB6195D9 HEU_KMS & MAS Windows 10 简体中文企业版2016长期服务版64位 3.56GB 是 9E405E950890D2A196565BCA35E152F9CFAD296D HEU_KMS & MAS Windows 10 简体中文企业版2016长期服务版32位 2.62GB 是 0422052F25C9C8DF983F3B287F725860AAB907CF HEU_KMS & MAS Windows 7 With SP1 简体中文旗舰版64位 3.19GB 是 2CE0B2DB34D76ED3F697CE148CB7594432405E23 小马OEM7F周年纪念版 & Chew-WGA Windows 7 With SP1 简体中文旗舰版32位 2.47GB 是 B92119F5B732ECE1C0850EDA30134536E18CCCE7 小马OEM7F周年纪念版 & Chew-WGA Windows XP SP3 简体中文专业版 601.04MB 是(也可说否) D142469D0C3953D8E4A6A490A58052EF52837F0F MRX3F-47B9T-2487J-KWKMF-RPWBY Microsoft VC++ 运行库官方安装包 Microsoft Visual C++ Redistributable 所有历史版本官方下载连接 https://cdn.jsdelivr.net/gh/abbodi1406/vcredist...
阅读全文

kubernetes的Headless Services

发布于
1.什么是Headless Services Headless Services是一种特殊的service，其spec:clusterIP表示为None，这样在实际运行时就不会被分配ClusterIP。 2.Headless Services使用场景（客户端负载） 服务端负载：正常的service 下面挂的是Endpoints（podIP数组），通过iptables规则转发到实际的POD上 客户端负载：Headless Services不会分配ClusterIP,而是将Endpoints（即podIP数组）返回，也就将服务端的所有节点地址返回，让客户端自行要通过负载策略完成负载均衡。 3.实践 #nginx yaml [ root@node1 yaml ] # cat nginx . yaml apiVersion : v1 kind : Service metadata : name : nginx - service spec : selector : app : nginx - demo ports : - port : 80 name : nginx clusterIP : None -- - apiVersion : apps / v1beta1 kind : Deployment metadata : name : nginx - dp spec : serviceName : "nginx-service" replicas : 1 template : metadata : labels : app : nginx - demo spec : containers : - name : nginx image : nginx : 1.7 .9 ports : - containerPort : 80 name : web [ root@node1 ~ ] # kubectl get svc NAME TYPE ...
阅读全文

Tailscale 开源版中文部署指南（支持无限设备数、自定义多网段 、自建中继等高级特性）

发布于
目前国家工信部在大力推动三大运营商发展 IPv6，对家用宽带而言，可以使用的 IPv4 公网 IP 会越来越少。有部分地区即使拿到了公网 IPv4 地址，也是个大内网地址，根本不是真正的公网 IP，访问家庭内网的资源将会变得越来越困难。 部分小伙伴可能会选择使用 frp 等针对特定协议和端口的内网穿透方案，但这种方案还是不够酸爽，无法访问家庭内网任意设备的任意端口。更佳的选择还是通过 VPN 来组建大内网。至于该选择哪种 VPN，毫无疑问肯定是 WireGuard，WireGuard 就是 VPN 的未来。 我已经不止一次向大家推荐使用 WireGuard 了，我累了，不想再讲了，你爱 JB 用辣鸡 OpenVPN 之类的就用吧，你开心就好。 WireGuard 相比于传统 VPN 的核心优势是没有 VPN 网关，所有节点之间都可以点对点（P2P）连接，也就是我之前提到的  全互联模式（full mesh） ，效率更高，速度更快，成本更低。 WireGuard 目前最大的痛点就是上层应用的功能不够健全，因为 WireGuard 推崇的是 Unix 的哲学，WireGuard 本身只是一个内核级别的模块，只是一个数据平面，至于上层的更高级的功能（比如秘钥交换机制，UDP 打洞，ACL 等），需要通过用户空间的应用来实现。 所以为了基于 WireGuard 实现更完美的 VPN 工具，现在已经涌现出了很多项目在互相厮杀。笔者前段时间一直在推崇  Netmaker ，它通过可视化界面来配置 WireGuard 的全互联模式，它支持 UDP 打洞、多租户等各种高端功能，几乎适配所有平台，非常强大。然而现实世界是复杂的，无法保证所有的 NAT 都能打洞成功，且 Netmaker 目前还没有 fallback 机制，如果打洞失败，无法 fallback 改成走中继节点。Tailscale 在这一点上比 Netmaker 高明许多，它支持 fallback 机制，可以尽最大努力实现全互联模式，部分节点即使打洞不成功，也能通过中继节点在这个虚拟网络中畅通无阻。 没错，我移情别恋了，从 Netmaker 阵营转向了 Tailscale，是渣男没错了。 Tailscale 是什么 Tailscale 是一种基于 WireGuard 的虚拟组网工具，和 Netmaker...
阅读全文

数据库逻辑设计之三大范式通俗理解

发布于
一、第一范式 1NF是对属性的 原子性 ，要求属性具有原子性，不可再分解； 表：字段1、 字段2(字段2.1、字段2.2)、字段3 ...... 如学生（学号，姓名，性别，出生年月日），如果认为最后一列还可以再分成（出生年，出生月，出生日），它就不是一范式了，否则就是； 二、第二范式 2NF是对记录的 唯一性 ，要求记录有唯一标识，即实体的唯一性，即 不存在部分依赖 ； 表：学号、课程号、姓名、学分; 这个表明显说明了两个事务:学生信息, 课程信息;由于非主键字段必须依赖主键，这里 学分依赖课程号 ， 姓名依赖与学号 ，所以不符合二范式。 可能会存在问题： 数据冗余: ，每条记录都含有相同信息； 删除异常： 删除所有学生成绩，就把课程信息全删除了； 插入异常： 学生未选课，无法记录进数据库； 更新异常： 调整课程学分，所有行都调整。 正确做法: 学生： Student (学号, 姓名)； 课程： Course (课程号, 学分)； 选课关系： StudentCourse (学号, 课程号, 成绩)。 三、第三范式 3NF是对字段的 冗余性 ，要求任何字段不能由其他字段派生出来，它要求字段没有冗余，即 不存在传递依赖 ； 表: 学号, 姓名, 年龄, 学院名称, 学院电话 因为存在 依赖传递 : (学号) → (学生)→(所在学院) → (学院电话) 。 可能会存在问题： 数据冗余: 有重复值； 更新异常： 有重复的冗余信息，修改时需要同时修改多条记录，否则会出现 数据不一致的情况 。 正确做法： 学生：(学号, 姓名, 年龄, 所在学院)； 学院：(学院, 电话)。 四、反范式化 一般说来，数据库只需满足第三范式（ 3NF ）就行了。 没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余， 达到以空间换时间的目的 。 〖例〗：如订单表，“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。 在 Rose 2002 中...
阅读全文

MIUI EU 欧洲版/国际版 本地化 Magisk 模块

发布于
一、前言 刷机有风险，ROOT需谨慎！搞机不规范，wipe两行泪！ 博主买了一台K30 5G，在使用过程中发现谷歌全家桶在MIUI大陆版上很不正常，非常影响日常使用，经朋友推荐了MIUI EU。虽然Google全家桶都正常了，但是没有小米公交属实有点拉垮，遂决定制作一个Magisk模块，将大陆版MIUI的功能搬到MIUI EU上。 这并不是重复造轮子，就目前而言，博主并没有找到一个本地化模块能将大部分特性移植到MIUI EU，所以自己又写了一个轮子。 二、正文 当前最新版本：v0.33 2020-12-01 请尊重他人的劳动成果，对本模块进行再发布或者修改请不要抹去原作者的信息，转载请注明来源，谢谢。 1.模块介绍 将部分MIUI大陆版特性移植到MIUI EU上。 更新将发布在个人博客 https://blog.minamigo.moe 。 交流QQ群：1012211595 ———— 目前支持的特性有： 小米兰亭Pro字体、小米钱包、应用商店、小爱同学、快应用（未测试）、黄页、传送门、全球上网（一元流量，需要自行从应用商店中安装）。 ———— 部分应用调整为大陆版： 拨号、短信、负一屏、mipush、下载管理（迅雷加速）、日历（农历）。 ———— 注意事项： * 部分应用的广告会回归 * 如果提示需要授权小米智能卡权限，请选择“总是允许”，否则会无法正常工作。如果错误授权，可以清除小米智能卡的数据。 * mipush切换到大陆地区需要手动删除/data/data/com.xiaomi.xmsf 已知问题： * 小爱同学无法使用语音唤醒 * 长按选词翻译功能无法使用 ———— 模块版本：v0.33  系统版本：20.11.18 Android 11 目前未完成的功能： 黄页（可能无法正常工作） 负一屏（未添加） ———————— 当前计划： * 增加可以根据自己需求选择性的恢复本地化功能 * 开始适配Android 11 2.下载安装 此处将不再赘述如何安装Magisk，仅提供下载连接。 Mega网盘： 传送门 阁下可能需要使用代理才能访问mega网盘。如果有朋友可以代传至其它网盘可以与博主联系。 ———— 安装/更新系统顺序： 刷入MIUI EU系统，并成功开机 刷入...
阅读全文