Ackerr. 2022-04-05T08:05:52.185Z https://www.wzmmmmj.com/ ZmJ Hexo Golang中 println 与 fmt.Println 有什么区别 https://www.wzmmmmj.com/2021/07/06/println-and-Println/ 2021-07-06T23:46:49.000Z 2022-04-05T08:05:52.185Z 前言

在之前写的一个命令行工具，其中一个功能点是选择某个项目，并切换至该项目目录 （对应CLI的lab cs命令）。因为程序中不能直接修改shell当前路径，只好在命令执行后输出内容，再与shell内置命令搭配使用来实现。

伪代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
package main

import "fmt"

func main() {
path := GetPath()
fmt.Println(path)
}

func GetPath() string {
// do something
return "/usr/local/bin/"
}

正常情况下，执行cd $(go run main.go)后，shell路径会切换到/usr/local/bin。

但在一次修改中，年轻的我以为println与fmt.Println的输出是等价的，都是写入标准输出，但println是内置函数，不需要额外导入fmt包，就把项目中使用fmt.Println的地方都替换成println，从而埋下祸根。

今早在本地更新了该命令行后，发现lab cs命令不好使了，虽然能在终端下看到该命令输出路径，但结合cd使用却没有效果，然而前一个版本，没问题的，间接定位到BUG是到改println的pr引入的。

1.输出位置不同

经紫月提醒，发现使用cd $(lab cs 2&>1)能正确切换路径了，那么原因很明确了，println把内容输出到标准错误中了。

查看fmt.Println的源码，注释和代码中都很明显：writes to standard output，内容输出到了os.Stdout，也就是标准输出。

1
2
3
4
5
6
// Println formats using the default formats for its operands and writes to standard output.
// Spaces are always added between operands and a newline is appended.
// It returns the number of bytes written and any write error encountered.
func Println(a ...interface{}) (n int, err error) {
return Fprintln(os.Stdout, a...)
}

再来看看println，因为是内置函数，这里只写了函数说明，不过在注释中，可以找到这句：writes the result to standard error。说明println/print确实是输出到stderr，也就是标准错误输出。

1
2
3
4
5
6
// The println built-in function formats its arguments in an
// implementation-specific way and writes the result to standard error.
// Spaces are always added between arguments and a newline is appended.
// Println is useful for bootstrapping and debugging; it is not guaranteed
// to stay in the language.
func println(args ...Type)

我们可以在go源码的 runtime/print.go找到println的具体实现。代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
func printnl() {
printstring("\n")
}

func printstring(s string) {
gwrite(bytes(s))
}

// write to goroutine-local buffer if diverting output,
// or else standard error.
func gwrite(b []byte) {
if len(b) == 0 {
return
}
recordForPanic(b)
gp := getg()
// Don't use the writebuf if gp.m is dying. We want anything
// written through gwrite to appear in the terminal rather
// than be written to in some buffer, if we're in a panicking state.
// Note that we can't just clear writebuf in the gp.m.dying case
// because a panic isn't allowed to have any write barriers.
if gp == nil || gp.writebuf == nil || gp.m.dying > 0 {
writeErr(b)
return
}
n := copy(gp.writebuf[len(gp.writebuf):cap(gp.writebuf)], b)
gp.writebuf = gp.writebuf[:len(gp.writebuf)+n]
}

在gwrite函数中，这里主要看下writeErr

1
2
3
4
5
6
7
8
9
func writeErr(b []byte) {
write(2, unsafe.Pointer(&b[0]), int32(len(b)))
}

func write(fd uintptr, p unsafe.Pointer, n int32) int32 {
return write1(fd, p, n)
}

func write1(fd uintptr, p unsafe.Pointer, n int32) int32

可以看到writeErr传递了unitptr为2的fd参数，最终在write1处进行系统调用。而标准错误输出的文件描述符刚好是2。

在unix中，stdin，stdout，stderr三者对应三个文件描述符，分别是0，1，2

2.函数定义不同

平时都是直接使用println("?") 或 fmt.Println("?") ，不过两者的函数定义也有些不同。

1
2
3
4
5
// println
func println(args ...Type)

// fmt.Println
func Println(a ...interface{}) (n int, err error)

虽然两者都接受多个传参，但只有fmt.Println是具有返回值的，其中第一位返回输出内容的字节数，对于Println还需要加上末尾换行符\n的一字节。

除此之外，println/print 不接受数组和结构体参数。

3.输出格式不同

如果实参实现了String()或Error()方法时，在调用fmt.Println打印该参数时，会调用这两个方法，而内置的println/print则不会使用。

参考

  1. https://github.com/golang/go/blob/master/src/runtime/print.go#L86
  2. https://gfw.go101.org/article/unofficial-faq.html#print-builtin-fmt-log
  3. https://www.zhihu.com/question/335186436
]]> <h2 id="前言"><a href="#前言" class="headerlink" title="前言"></a>前言</h2><p>在之前写的一个<a href="https://github.com/Ackerr/lab/" target="_blank" rel="n 深入浅出Golang之Context https://www.wzmmmmj.com/2021/01/24/golang-context/ 2021-01-24T22:26:09.000Z 2022-04-05T08:05:52.183Z 通过context.Context ，我们可以在 goruntine 中传递上下文参数以及同步取消信号。例如在处理http请求或记录请求链路时，可通过 Context 在goruntine间传递信息。也可以通过Context的超时取消，实现graceful shutdown。本文从源码角度，分析context.Context是如何实现上下文传递以及同步取消信号。

后遗症：具有网络请求的第三方库，如果无法传递Context，都不太想用，因为路径追踪中无法显示。

接口实现

context.Context接口

1
2
3
4
5
6
type Context interface {
Deadline() (deadline time.Time, ok bool)
Done() <-chan struct{}
Err() error
Value(key interface{}) interface{}
}
  • Deadline：返回Context被取消的截止时间，如果第二个参数返回fasle，则说明未设置截止时间；
  • Done：返回一个channel对象，Context被取消后，该channel会被close；
  • Err：返回Context结束原因。当Done返回的channel未被取消时，返回nil，被取消则返回取消原因。例如Context因为超时关闭，返回DeadlineExceeded；
  • Value：返回Context中保存的键值；

context.canceler接口

1
2
3
4
type canceler interface {
cancel(removeFromParent bool, err error)
Done() <-chan struct{}
}
  • cancel：取消当前Context;
  • Done：与Context接口一致，返回一个channel对象

基本原理

context包中提供了两个常用方法，context.Background和context.TODO。

1
2
3
4
5
6
7
8
9
10
11
12
var (
background = new(emptyCtx)
todo       = new(emptyCtx)
)

func Background() Context {
return background
}

func TODO() Context {
return todo
}

从源码上看，两者并没什么不同，均通过new(emptyCtx)初始化。使用场景上，context.Backgound常用于主函数、初始化、以及测试用例中，作为顶层上下文进行传递，仅当不确定使用哪种Context时，才通过context.TODO占坑。对应emptyCtx实现如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
type emptyCtx int

func (*emptyCtx) Deadline() (deadline time.Time, ok bool) {
return
}

func (*emptyCtx) Done() <-chan struct{} {
return nil
}

func (*emptyCtx) Err() error {
return nil
}

func (*emptyCtx) Value(key interface{}) interface{} {
return nil
}

不难发现，这两个 Context 啥都没干，没有截止时间，不能被取消，也不能设置上下文参数，仅仅通过空方法实现了Context接口。如果需要实现传递上下文、同步取消信号等额外功能，可通过context包中提供的方法进行拓展，当然也可以自己实现Context接口。

WithValue

context.WithValue基于parent Context，生成valueCtx类型Context，并保留一对键值，常用来传递上下文。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
func WithValue(parent Context, key, val interface{}) Context {
if parent == nil {
panic("cannot create context from nil parent")
}
if key == nil {
panic("nil key")
}
    // 因为传递的是interface，这里通过反射，判断key类型能否进行比较
if !reflectlite.TypeOf(key).Comparable() {
panic("key is not comparable")
}
return &valueCtx{parent, key, val}
}

type valueCtx struct {
Context
key, val interface{}
}

func (c *valueCtx) Value(key interface{}) interface{} {
// 比较key是否等于当前context key，如果不是则向父context查询
    if c.key == key {
return c.val
}
return c.Context.Value(key)
}

需要注意的是，valueCtx.Value实现了链式查找，如果当前context中为找到为符合的key值，则会向父context中继续。

举个例子

示例代码中，ctx获取到grandparent context的value。

1
2
3
4
5
6
7
8
9
10
11
package main

import "context"

func main() {
ctx := context.Background()
ctx = context.WithValue(ctx, "key1", "1")
ctx = context.WithValue(ctx, "key2", "2")
ctx = context.WithValue(ctx, "key3", "3")
println(ctx.Value("key1").(string))  // "1"
}

WithCancel

context.WithCancel常用于控制派生 goruntine，通过接收parent Context，返回两个参数ctx cancelCtx和cancel cancelFunc。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
type CancelFunc func()

func WithCancel(parent Context) (ctx Context, cancel CancelFunc) {
if parent == nil {
panic("cannot create context from nil parent")
}
    // 通过parent生成一个cancelCtx，会设置一个新的done channel对象
c := newCancelCtx(parent)
    // 与parent关联
propagateCancel(parent, &c)
return &c, func() { c.cancel(true, Canceled) }
}

func newCancelCtx(parent Context) cancelCtx {
return cancelCtx{Context: parent}
}

type cancelCtx struct {
Context

mu       sync.Mutex
done     chan struct{}
children map[canceler]struct{}
err      error
}

这里主要看下propagateCancel的实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// parent 父上下文
// child  当前上下文
func propagateCancel(parent Context, child canceler) {
done := parent.Done()
    // parent不会触发cancel，直接返回
    // 例如context.Background()这种Done方法直接返回nil的
if done == nil {
return
}

select {
    // parent已经被cancel，child直接执行cancel
case <-done:
child.cancel(false, parent.Err())
return
default:
}
    // 判断parent是否是cancelCtx类型
if p, ok := parentCancelCtx(parent); ok {
        // parent是cancelCtx类型
p.mu.Lock()
if p.err != nil {
// 该ctx已经被cancel
child.cancel(false, p.err)
} else {
            // 将当前context加入到上层cancelCtx的children中
if p.children == nil {
p.children = make(map[canceler]struct{})
}
p.children[child] = struct{}{}
}
p.mu.Unlock()
} else {
        // parent不是cancelCtx类型，但可被cancel，监听parent和child是否被取消
go func() {
select {
case <-parent.Done():
child.cancel(false, parent.Err())
case <-child.Done():
}
}()
}
}

通过源码，propagateCancel函数主要作用就是关联当前context和父context，如果父context是cancelCtx类型并且未被cancel，则加入到它的children字段中。当执行 cancel 函数时，除了关闭自身done channel外，还会为 children 中关联的所有context执行 cancel 方法。通过Err方法，可获取context.Canceled 错误。cancelCtx.cancel实现如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
var Canceled = errors.New("context canceled")

// removeFromParent 是否需要从parent.children中移除
func (c *cancelCtx) cancel(removeFromParent bool, err error) {
if err == nil {
panic("context: internal error: missing cancel error")
}
c.mu.Lock()
    // err不为nil，说明已经被取消，直接返回
if c.err != nil {
c.mu.Unlock()
return
}
    // 设置err，并关闭done chan
c.err = err
if c.done == nil {
c.done = closedchan
} else {
close(c.done)
}
    // 关联的所有子context依次执行cancel
for child := range c.children {
child.cancel(false, err)
}
c.children = nil
c.mu.Unlock()
    
if removeFromParent {
        // 在parent的children字段中移除该context
removeChild(c.Context, c)
}
}

举个例子

示例代码，sleep 3秒后，因为执行 cancel，ctx.Err()输出context canceled。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
package main

import (
"context"
"fmt"
"time"
)

func main() {
ctx := context.Background()
ctx, cancel := context.WithCancel(ctx)
go f(ctx)
time.Sleep(time.Second * 3)
cancel()
time.Sleep(time.Second * 1)
}

func f(ctx context.Context) {
i := 1
for {
select {
case <-ctx.Done():
fmt.Println(ctx.Err())
return
default:
fmt.Println(i)
time.Sleep(time.Second * 1)
i++
}
}
}

WithDeadline

context.WithDeadline常用于需要超时关闭的场景。通过设置截止时间，起到超时自动取消context以及子context的效果。当context因为超时被 cancel 时，通过Err方法，可获取context.DeadlineExceeded 错误，代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
func WithDeadline(parent Context, d time.Time) (Context, CancelFunc) {
if parent == nil {
panic("cannot create context from nil parent")
}
    // 判断parent是否设置截止时间，并且是否达到该时间
if cur, ok := parent.Deadline(); ok && cur.Before(d) {
        // 如果d时间已过，则返回cancelCtx类型context，截止时间使用parent的
return WithCancel(parent)
}
    // 将父级context先包装成cancelCtx类型
c := &timerCtx{
cancelCtx: newCancelCtx(parent),
deadline:  d,
}
    // 关联parent
propagateCancel(parent, c)
    // 如果当前时间已经超过了截止时间，执行cancel，直接返回一个已经被 cancel 的 timerCtx
dur := time.Until(d)
if dur <= 0 {
c.cancel(true, DeadlineExceeded)
return c, func() { c.cancel(false, Canceled) }
}
c.mu.Lock()
defer c.mu.Unlock()
if c.err == nil {
        // 启动一个定时器，到截止时间自动取消这个 timerCtx
c.timer = time.AfterFunc(dur, func() {
c.cancel(true, DeadlineExceeded)
})
}
return c, func() { c.cancel(true, Canceled) }
}

举个例子

示例代码，执行3秒后，定时器执行 cancel，ctx.Err()输出context deadline exceeded。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
package main

import (
"context"
"fmt"
"time"
)

func main() {
ctx := context.Background()
    ctx, cancel := context.WithDeadline(ctx, time.Now().Add(time.Second * 3))
defer cancel()
go f(ctx)
time.Sleep(time.Second * 5)
}

func f(ctx context.Context) {
i := 1
for {
select {
case <-ctx.Done():
fmt.Println(ctx.Err())
return
default:
fmt.Println(i)
time.Sleep(time.Second * 1)
i++
}
}
}

WithTimeout

与context.WithDeadline函数类似，只不过传参从time.Time类型该为time.Duration，也就是截止时间改为超时时间。实际调用的其实还是context.WithDeadline

1
2
3
func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc) {
return WithDeadline(parent, time.Now().Add(timeout))
}
]]> <p>通过<code>context.Context</code> ，我们可以在 goruntine 中传递上下文参数以及同步取消信号。例如在处理http请求或记录请求链路时，可通过 Context 在goruntine间传递信息。也可以通过Context的超时取消，实现<a h 装机实录之超频篇 https://www.wzmmmmj.com/2021/01/10/overclock/ 2021-01-10T23:51:41.000Z 2022-04-05T08:05:52.185Z 经历一天多次黑屏重启，初步完成了首次超频之旅。本文记录一下作为萌新超频的整个过程，就当图一乐，真正学技术还得看贴吧。

前言

先介绍一下平台

  • CPU：AMD Ryzen 5800x
  • 主板：微星B550-M
  • 显卡：微星RTX 3070
  • 内存：芝奇幻光戟3200MHz c16

本篇文章中使用到的软件及在本文中的用途

  • AIDA64：硬件检测工具，对CPU进行压力测试，判断CPU稳定性
  • CPU-Z：侦察CPU信息，对CPU进行单核/多核评分和稳定性测试
  • AMD Ryzen Master：AMD官方提供的锐龙系CPU超频工具
  • GPU-Z：侦察显卡信息
  • 3DMark：通过Time spy压力测试，判断显卡稳定性
  • Afterburner：显卡超频工具，监控硬件图标
  • RTSS：显示Afterburner中监控的硬件指标

CPU超频

CPU下的超频需要主板和CPU同时支持，Intel这边需要型号末尾为K，Z系列主板，而AMD锐龙全系列支持，除部分A系列主板外。

通过CPU-Z查看默频下的cpu信息，顺便记一下默频跑分（单核661.5/多核6584.4），如下图所示

默频跑分

大部分教程中，会通过BIOS修改参数进行超频，但此方法需要来回重启电脑进入BIOS，许多主板产商会提供相关的超频工具，这里我们用AMD官方的超频工具AMD Ryzen Master进行超频。

打开AMD Ryzen Master，面板中可看到当前CPU核心频率和电压以及它们的最大值，如下图

默频

如果想要超频，只需调整上图右侧控制模式为手动，微调频率和电压即可。这里推荐核心频率每次增加200MHz，点击运行和测试，如果测试过程中出现死机或重启的情况，适当的上调电压，再重复上述过程，直达达到预期频率。至于CPU的最佳频率请自行搜索。如下图所示，CPU核心频率从默频3.8GHz提高到了4.6GHz，并通过测试。

超频后

接着再通过CPU-Z测试一下当前频率的跑分（单核631.1/多核6681.0），对比默频下的跑分，发现虽然多核分数提高了，但单核分数反而降低了。这里可能是因为CPU默频，在高负载下会自动睿频到4.8Ghz，从而提升了单核性能。

超频后跑分

通过Ryzen Master以及CPU-Z的粗略的压力测试后，再通过AIDA64中的进行稳定性测试，勾选Stress FPU，点击Start，观察CPU-Z中的频率以及电压看是否稳定，CPU温度是否在合理范围内。在稳定跑半个小时左右，基本宣告超频完成，如果途中出现黑屏重启或死机，适当调高电压，最好不超过1.45v，不然你懂得。如果希望进一步提升频率，重复上述步骤即可。

AIDA64

由于Ryzen Master重启后需要手动启动才能生效，在确定CPU核心频率及电压后，只需要进一次BIOS，在对应的位置上设置好参数即可。

显卡超频

显卡超频与CPU超频类似，也是通过调整核心频率，再执行对应的压力测试即可。

通过MSI Afterburner来提高核心频率，如下图所示，先将功耗限制以及温度限制拉满。

Afterburner

按照每次提高50MHz核心频率，如果对显卡自信的话，也可以提高多一些。设置完成后点击右下角保存，接下来只需通过显卡压测软件进行压测即可。这里推荐 FurMark 或 3DMark的Time Spy压力测试，如果设置的频率未通过压测，就降低20MHz，如此反复，直到通过压测。

3DMark

通过压测后，如需开机启动超频配置，只需要对相应的配置点击startup即可

startup

另外，在许多评测视频中，经常能看到在游戏画面中显示硬件信息，就是通过MSI Afterburner的硬件实时监控功能，如果想在游戏中显示各类硬件信息，可在MSI Afterburner设置中，开启OSD显示。

Afterburner OSD

开启OSD并启动RTSS后，即可在游戏中显示数据，如下图左上角。

OSD

内存超频

由于CPU具有默认支持的内存频率，例如DDR4可能是2133MHz，如果购买了DDR4 3200MHz或更高，在未修改BIOS的前提下，开机内存频率只会是2133MHz。而达到3200MHz，则需要我们手动进入BIOS，开启XMP，也就是内存预设超频。

XMP设置

开启XMP后的内存频率

当然内存也支持手动超频，具体的超频能力实际跟购买内存颗粒有关。但在体验了一次扣主板电池后，我放弃了这个选项，不然不知道又要重置多少次BIOS，只能自我安慰，预设超频挺好的：）。具体的手动超频可参考这篇文章。

总结

相对于内存超频，会导致电脑无法开机，需要重置BIOS，CPU和显卡则安心的多，大不了就是黑屏重启。可能本身性能过剩的原因，也可能是操作不到位，超频并没有给我太多直观上的提升。当然喜欢折腾的人可以来试试看

]]> <p>经历一天多次黑屏重启，初步完成了首次超频之旅。本文记录一下作为萌新超频的整个过程，就当图一乐，真正学技术还得看贴吧。</p> <h2 id="前言"><a href="#前言" class="headerlink" title="前言"></a>前言</h2><p>先介绍一 装机实录之组装篇 https://www.wzmmmmj.com/2020/12/13/diy-computer-install/ 2020-12-13T23:45:06.000Z 2022-04-05T08:05:52.181Z 本篇依旧是装机时个人觉得特别重要的几点注意事项。对于配件安装这里就不赘述，网上有很多装机视频，安装操作都有比较细致的讲解，B站搜索装机教程即可。

按照惯例，先展示包装（空壳）全家福以及机箱图

包装图

开机机箱图

风扇没有RGB感觉还是差点意思

风道

合理的风道设计，有利于机箱散热，不然容易使机箱变成闷罐，动不动就高温降频。对于风道设计，推荐遵循前进后出，下进上出。对于单风扇水冷，直接安装在主板左侧即可。因为我买的一体式240水冷，还需要考虑冷排放置，而我的机箱并不支持机箱顶部放置水冷，所以只能安装在机箱前面板。参考此篇文章，最终选择吹风式（冷排|风扇|前面板）。当然如何是RGB的风扇，机箱前面板不透光的情况，肯定选择抽风式，而如果有多余风扇则可以采取夹汉堡方式，在冷排两侧都安装风扇。

接线

装机时，推荐先接线，待点亮电脑后，再调整走线。正常情况下会有以下几种线材：

  1. 电源供电线
  2. 机箱IO跳线
  3. 风扇fan线
  4. 硬盘SATA线

各种线材的接线方式请反复观看此视频，配合主板说明书中的接口图效果更佳。小弟认全电源供电线就看了不下10遍，这里推荐购买全模组电源，对于多余的供电线，可以拆卸，方便后续理线。

系统

首先准备一个16gb的u盘，安装windows系统，最方便的方式就是在微软官方下载iso文件到u盘中。如果有其他系统需求，也可以通过 Rufus 制作系统盘，使用方式可参考知乎回答。至于那些带有捆绑软件的系统安装工具能不碰就不碰。当然如果嫌麻烦，也可以问问身边朋友有没有可用的系统盘，或者购买固态硬盘时，顺便买一个系统盘或直接让商家帮忙安装好系统。

BIOS

安装好所有配件，接上电源，显示器后，插上系统u盘，启动开机键后，猛按F11 (不同主板的快捷键可能不同，请查看主板说明书或自己搜索)。正常情况会出现 开机启动设备界面，选择需要安装系统的硬盘即可。如果未出现设备，需要进入BIOS设置界面查看设置是否正确：

  • BIOS Mode 设置为UEFI
  • SATA Mode 设置为 AHCI

修改设置重启后，正常情况下就会进入安装系统的傻瓜界面了。

BIOS

小弟第一次到这步时，启动后长时间停留在logo界面，原本以为是正常现象，结果出门吃个饭回来还在logo界面。刚开始以为是固态问题，因为BIOS中主板没有识别出固态，如上图，截图给固态客服后，发现设置并没有什么问题。尝试取下固态再安装，折腾了半天还是识别不了，一度让我以为固态有问题，差点去退货了。而后又去问了主板客服，让我尝试升级主板BIOS，通过官网中下载新的主板BIOS版本至u盘中，并在BIOS中加载该版本。一顿操作之后，终于识别出固态。

理线

此处灵魂走线大师上线。理线推荐购买扎线带和魔术贴，一般购买的电源中也会附赠。秉承着能看就行的原则，尝试性的理了一回线，只能说尽力了，反正背板一盖，啥都看不到（自暴自弃）。

理线前：

理线前

理线后：

理线后

最后附上一篇个人感觉还不错的理线教程

]]> <p>本篇依旧是装机时个人觉得特别重要的几点注意事项。对于配件安装这里就不赘述，网上有很多装机视频，安装操作都有比较细致的讲解，B站搜索<a href="https://search.bilibili.com/all?keyword=%E8%A3%85%E6%9C%BA%E6%9 常用依赖镜像源 https://www.wzmmmmj.com/2020/11/29/mirror-source/ 2020-11-29T19:50:16.000Z 2022-04-05T08:05:52.184Z

一句话：从右边几个源中寻找对应软件即可 清华源 中科大源 阿里源 淘宝源 。当然如果能科学上网可忽略，不过大多数时候使用国内镜像源会更快一些。

趁这波换电脑，顺便整理了一番个人日常开发中需要替换的国内镜像源。

Python

pip

以下命令会添加配置至$HOME/.config/pip/pip.conf

1
2
pip install -i https://pypi.tuna.tsinghua.edu.cn/simple pip -U
pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple

pyenv

修改v变量，一键安装对应Python版本

1
v=3.8.3;wget https://npm.taobao.org/mirrors/python/$v/Python-$v.tar.xz -P $(pyenv root)/cache/;pyenv install $v

Golang

go module

1
2
export GO111MODULE=on
export GOPROXY='https://goproxy.cn'

Node.js

npm

1
npm config set registry https://registry.npm.taobao.org

yarn

1
yarn config set registry https://registry.npm.taobao.org/

Arch

pacman

覆盖原有/etc/pacman.d/mirrorlist，可以先备份原有文件

1
2
Server = https://mirrors.tuna.tsinghua.edu.cn/archlinux/$repo/os/$arch
Server = http://mirrors.aliyun.com/archlinux/$repo/os/$arch

archlinuxcn

添加至原/etc/pacman.conf末尾

1
2
[archlinuxcn]
Server = https://mirrors.tuna.tsinghua.edu.cn/archlinuxcn/$arch

AUR

1
yay --aururl "https://aur.tuna.tsinghua.edu.cn" --save

Ubuntu

20.04LTS

覆盖原有/etc/apt/srouces.list

1
2
3
4
5
6
7
8
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal main restricted universe multiverse
deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-updates main restricted universe multiverse
deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-updates main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-backports main restricted universe multiverse
deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-backports main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-security main restricted universe multiverse
deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-security main restricted universe multiverse

18.04LTS版本将所有 focal 替换成 bionic 即可

Alpine

1
sed -i 's/dl-cdn.alpinelinux.org/mirrors.tuna.tsinghua.edu.cn/g' /etc/apk/repositories

Homebrew

Core

1
2
cd "$(brew --repo)/Library/Taps/homebrew/homebrew-core"
git remote set-url origin https://mirrors.ustc.edu.cn/homebrew-core.git

Cask

1
2
cd "$(brew --repo)"/Library/Taps/homebrew/homebrew-cask
git remote set-url origin https://mirrors.ustc.edu.cn/homebrew-cask.git

不定时更新中…

]]> <blockquote> <p>一句话：从右边几个源中寻找对应软件即可 <a href="https://mirror.tuna.tsinghua.edu.cn/help/" target="_blank" rel="noopener">清华源</a> <a href="ht 装机实录之选购篇 https://www.wzmmmmj.com/2020/11/22/diy-computer-setup/ 2020-11-22T20:49:21.000Z 2022-04-05T08:05:52.182Z 作为早在去年双11嚷嚷着要装机的等等党本党，在NVIDIA 30系显卡/AMD 4代锐龙发布后，坐不住了，开启了首次装机之旅。在踩了一遍坑后，特地来水一篇，记录一些注意事项。

用途

买前生产力：

我要搞机器学习，TensorFlow启动，顺便学学剪辑，Adobe启动。

买后打游戏：

狂战士信条真好玩，赛博朋克2077怎么又跳票了。

选配件前，先明确装机用途，到底是臭打游戏的，还是臭打游戏，还是臭打游戏。大部分情况下，臭打游戏吃显卡，生产力吃CPU。不过游戏性能过得去，也勉强能搞搞生产力，反过来就不一定了。当然预算充足，适度游戏，可以考虑双修。

预算

三千预算进卡吧, 加钱加到九万八

预算只能说量力而行吧。按CPU与显卡占预算的70%，进行选购。例如小弟预算一万，其实选择锐龙3700x或英特尔i5-10400配3080可能更适合臭打游戏，奈何3080缺货，秉承买新不买旧，最终选择了锐龙5800x跟3070，被迫双修，预算也超了10%。

当然不差钱的话，天梯图一逛，配置拉满即可，阿苏斯全家桶带回家。

板U

CPU与主板可以购买板U套装。主板根据CPU厂商，分为两大平台，不同主板对应CPU的插槽不同，大部分商家都会搭配可用的板U套装，因为限价原因，板U套餐都比分开购买相对更实惠一些。

内存

关于内存选择，涉及到内存颗粒以及内存频率等，就不误人子弟了，这里放一篇专业的，如何挑选内存

电源

选定其余硬件后，通过每个配件的额定功率，适当加50%余量，即可推算出大致需要选择的电源功率，推荐使用功率计算器，当然预算足够，可以适当买大功率的电源，毕竟电源保修时间长也不太容易坏，下次升级换代时，电源还可以接着用。

机箱

虽然机箱本质上不会影响电脑性能，但在选择机箱时，除了考虑机箱外观，还需要额外考虑以下几点：

  1. 支持的主板尺寸，主板根据大小分为ITX，M-ATX，ATX以及更大的E-ATX。
  2. 支持的显卡尺寸，如果前置水冷，可能支持的显卡尺寸会更小
  3. 是否支持一体式水冷
  4. 一体式水冷尺寸，240、280还是320
  5. 一体式水冷的摆放，有些机箱只支持前置水冷。
  6. 附赠的风扇个数
  7. 风道设计以及静音效果

RGB

RGB提升电脑百分之六十的性能。

轻度RGB确实赏心悦目，但需要选择侧透机箱，不要拿个静音机箱来哄人。R不RGB，纯看个人喜好，预算充足，就购买支持神光同步的主板以及ARGB风扇和内存条，足够花里胡哨了。但如果预算吃紧，RGB溢价10%，不如拿来提升显卡。

小结

具体如何选购电脑配件，参考下列文章

]]> <p>作为早在去年双11嚷嚷着要装机的等等党本党，在NVIDIA 30系显卡/AMD 4代锐龙发布后，坐不住了，开启了首次装机之旅。在踩了一遍坑后，特地来水一篇，记录一些注意事项。</p> <h3 id="用途"><a href="#用途" class="headerlink" gRPC之interceptor https://www.wzmmmmj.com/2020/11/08/grpc-interceptor/ 2020-11-08T21:13:25.000Z 2022-04-05T08:05:52.184Z 在Web服务中，除了实际的业务代码，经常还需要实现统一记录请求日志，权限管理或异常处理等功能，这些在web框架Gin或Django中可通过middleware实现，而gRPC中则可使用interceptor，对rpc请求或响应进行拦截处理。

gRPC服务端跟客户端均可实现各自的拦截器，根据rpc的两种请求方式可分为两种。

  • Unary Interceptor（一元拦截器）
  • Stream Interceptor（流式拦截器）

一元拦截器

对于一元服务器拦截器，只需要定义UnaryServerInterceptor方法即可，其中，handler(ctx, req)即调用rpc方法。

1
2
3
4
5
6
7
8
type UnaryServerInterceptor func(
    ctx context.Context,    // rpc上下文
    req interface{},        // rpc请求参数
    info *UnaryServerInfo,  // rpc方法信息
    handler UnaryHandler    // rpc方法本身
) (interface{}, error){
return handler(ctx, req)
}

而对于一元客户端拦截器，一样需要定义一个方法UnaryClientInterceptor，其中执行invoker()才真正请求rpc。

1
2
3
4
5
6
7
8
9
10
11
type UnaryClientInterceptor func(
    ctx context.Context,  // rpc上下文
    method string,        // 调用方法名
    req,                  // rpc请求参数
    reply interface{},    // rpc响应结果
    cc *ClientConn,       // 连接句柄
    invoker UnaryInvoker, // 调用rpc方法本身
    opts ...CallOption    // 调用配置
) error {
    return invoker(ctx, method, req, reply, cc, opts...)
}

一元拦截器的实现，根据调用handler或invoker的前后，可分为三部分：调用前预处理，调用rpc方法，调用后处理。

流式拦截器

流式拦截器的实现，与一元拦截器一致，实现提供的方法即可，方法参数含义如下：

1
2
3
4
5
6
7
8
type StreamServerInterceptor func(
    srv interface{},        // rpc请求参数
    ss ServerStream,        // 服务端stream对象
    info *StreamServerInfo, // rpc方法信息
    handler StreamHandler   // rpc方法本身
) (err error){
    return handler(src, ss)
}
1
2
3
4
5
6
7
8
9
10
11
12
13
type StreamClientInterceptor func(
    ctx context.Context,   // rpc上下文
    desc *StreamDesc,      // 流信息
    cc *ClientConn,        // 连接句柄
    method string,         // 调用方法名
    streamer Streamer,     // 调用rpc方法本身
    opts ...CallOption     // 调用配置
)(ClientStream, error){
    // 流操作预处理
    clientStream, err := streamer(ctx, desc, cc, method, opts...)
    // 根据某些条件，通过clientStream拦截流操作
    return clientStream, err
}

与其他拦截器不同，客户端流式拦截器的实现分为两部分，流操作预处理和流操作拦截，其不能在事后进行rpc方法调用和后处理，只能通过ClientStream对象进行流操作拦截，例如根据特定的metadata，调用ClientStream.CloseSend()终止流操作。

举个例子

这里我们将上述四种拦截器都写一个简单输出请求日志的demo，看看实际效果

demo目录结构如下

1
2
3
4
5
6
7
8
9
10
11
rpc
├── base.proto
├── base
│   ├── base.pb.go
│   └── base_grpc.pb.go
├── client
│   └── main.go
├── server
│    └── main.go
├── go.mod
├── go.sum

base.proto文件如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
syntax = "proto3";

package proto;

option go_package = "base;base";


service BaseService {
  rpc GetTime (TimeRequest) returns (TimeResponse){}
  rpc Streaming (stream StreamRequest) returns (stream StreamResponse){}
}

message TimeRequest {}

message TimeResponse {
  string time = 1;
}

message StreamRequest{
  string input = 1;
}

message StreamResponse{
  string output = 1;
}

执行命令protoc --go_out=. --go-grpc_out=. base.prto生成对应的pb文件。

server.go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
package main

import (
"context"
"log"
"io"
"net"
"strconv"
"time"

pb "rpc/base"

"google.golang.org/grpc"
"google.golang.org/grpc/reflection"
)

type service struct {
pb.UnimplementedBaseServiceServer
}

func main() {
listen, err := net.Listen("tcp", ":50051")
if err != nil {
fmt.Println(err)
}
s := grpc.NewServer(grpc.UnaryInterceptor(UnaryServerInterceptor), grpc.StreamInterceptor(StreamServerInterceptor))
reflection.Register(s)
pb.RegisterBaseServiceServer(s, &service{})
s.Serve(listen)
}

func UnaryServerInterceptor(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (resp interface{}, err error) {
log.Println("start unary")
resp, err = handler(ctx, req)
log.Printf("end unary %v\n", resp)
return resp, err
}

func StreamServerInterceptor(srv interface{}, ss grpc.ServerStream, info *grpc.StreamServerInfo, handler grpc.StreamHandler) error {
log.Println("before stream")
err := handler(srv, ss)
log.Println("after stream")
return err
}

// 具体接口实现
func (s *service) GetTime(ctx context.Context, in *pb.TimeRequest) (*pb.TimeResponse, error) {
now := time.Now().Format("2006-01-02 15:04:05")
return &pb.TimeResponse{Time: now}, nil
}

func (s *service) Streaming(stream pb.BaseService_StreamingServer) error {
for n := 0; ; {
res, err := stream.Recv()
if err == io.EOF {
return nil
}
if err != nil {
return err
}
v, _ := strconv.Atoi(res.Input)
        log.Println(v)
n += v
stream.Send(&pb.StreamResponse{Output: strconv.Itoa(n)})
}
}

client.go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
package main

import (
"context"
"io"
"log"
"strconv"

pb "rpc/base"

"google.golang.org/grpc"
)

func main() {
conn, err := grpc.Dial(":50051", grpc.WithInsecure(), grpc.WithBlock(), grpc.WithUnaryInterceptor(UnaryClientInterceptor), grpc.WithStreamInterceptor(StreamClientInterceptor))
if err != nil {
log.Println(err)
}
defer conn.Close()

c := pb.NewBaseServiceClient(conn)

    // 依次执行unary，stream
    _, err = c.GetTime(context.Background(), &pb.TimeRequest{})
if err != nil {
log.Fatal(err)
}
    print("===============\n")
    streaming(c)
}

func UnaryClientInterceptor(ctx context.Context, method string, req, reply interface{}, cc *grpc.ClientConn, invoker grpc.UnaryInvoker, opts ...grpc.CallOption) error {
log.Println("before unary")
err := invoker(ctx, method, req, reply, cc, opts...)
log.Printf("end unary %v\n", reply)
return err
}

func StreamClientInterceptor(ctx context.Context, desc *grpc.StreamDesc, cc *grpc.ClientConn, method string, streamer grpc.Streamer, opts ...grpc.CallOption) (grpc.ClientStream, error) {
log.Println("before stream")
clientStream, err := streamer(ctx, desc, cc, method, opts...)
log.Println("check metadata")
return clientStream, err
}

func streaming(client pb.BaseServiceClient) error {
stream, _ := client.Streaming(context.Background())
for n := 0; n < 10; n++ {
log.Println("Streaming Send:", n)
err := stream.Send(&pb.StreamRequest{Input: strconv.Itoa(n)})
if err != nil {
return err
}
res, err := stream.Recv()
if err == io.EOF {
break
}
if err != nil {
return err
}
log.Println("Streaming Recv:", res.Output)
}
stream.CloseSend()
return nil
}

rpc目录下依次执行go run server/main.go 和 go run client/main.go，输出效果如下

输出结果

可以明显看出StreamClientInterceptor则是在流处理开始时就输出了两次日志，其余三种拦截器则在请求前后输出两次。

小结

如果需要使用多个拦截器，grpc-go中提供了相应的四种链接器

  • grpc.ChainUnaryInterceptor(i ...UnaryServerInterceptor)
  • grpc.ChainStreamInterceptor(i ...StreamServerInterceptor)
  • grpc.WithChainUnaryInterceptor(i ...UnaryClientInterceptor)
  • grpc.WithChainStreamInterceptor(i ...StreamClientInterceptor)

如果grpc版本过老，可能还未提供chain api，可以使用第三方库grpc-ecosystem/go-grpc-middleware。除了链接器，库中还提供了许多常用的拦截器，例如grpc_zap，grpc_recovery等。当然，特殊需求也可以通过实现对应方法，实现自定义interceptor。

]]> <p>在Web服务中，除了实际的业务代码，经常还需要实现统一记录请求日志，权限管理或异常处理等功能，这些在web框架Gin或Django中可通过middleware实现，而gRPC中则可使用interceptor，对rpc请求或响应进行拦截处理。</p> <p>gRPC服务端跟客 Golang中实现平滑发版 https://www.wzmmmmj.com/2020/10/31/golang-gracefully-upgrade/ 2020-10-31T21:48:14.000Z 2022-04-05T08:05:52.184Z 关于平滑发版，紫月写过一篇博客《软件工程实践之平滑发版》，其中讲解了为什么需要平滑发版以及服务中如何实现。总结下来，平滑发版中会经历的几个步骤：

  1. 启动新进程，旧进程停止监听请求，新请求由新进程监听
  2. 旧进程等待已连接的请求结束
  3. 待请求全部执行完毕或超过超时时间，关闭进程

而进程什么时候停止监听，什么时候关闭进程，则可以通过Signal来实现。
以k8s为例，在执行kubectl rollout restart后，

  1. 旧pod会接收到SIGTERM信号，pod status变为Terminating
  2. 旧pod等待处理的中的请求结束
  3. 待处理中的请求结束或超过预设的terminationGracePeriodSeconds时间
  4. 旧pod接收到SIGKILL信号后被移除

一般来说，通过守护进程进行部署的方式，只需要正确处理Signal，即可实现服务业务平滑发版，例如最近整的项目中，由四部分组成：

其中machinery本身就实现了gracefully shutdown，调用api即可，后文将依次介绍其他三个部分如何实现平滑发版。

gin

Gin官方提供了gracefully shutdown的例子，代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
package main

import (
    "context"
    "log"
    "net/http"
    "os"
    "os/signal"
    "syscall"
    "time"

    "github.com/gin-gonic/gin"
)

func main() {
    router := gin.Default()
    router.GET("/", func(c *gin.Context) {
        time.Sleep(5 * time.Second)
        c.String(http.StatusOK, "Hello World")
    })

    srv := &http.Server{
        Addr:    ":8080",
        Handler: router,
    }
    go func() {
        if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
            log.Fatalf("listen: %s\n", err)
        }
    }()

    quit := make(chan os.Signal)
    signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
    <-quit
    log.Println("Shutting down server...")

    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()
    if err := srv.Shutdown(ctx); err != nil {
        log.Fatal("Server forced to shutdown:", err)
    }
    log.Println("Server exiting")
}

例子中通过主goroutine通过signal.Notify()监听， <-quit进行阻塞，另外一个goroutine启动http server，当接收到SIGINT或SIGTERM信号后，http.ListenAndServe()返回http.ErrServerClosed，此时httpserver不再接受新请求，并创建一个超时时间为5s的context，通过http.Server的Shutdown，并阻塞等待连接释放或context超时。

grpc-go

grpc-go中提供了GracefulStop，我们只需要监听Signal，接受到后，由GracefulStop来处理连接中的请求

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
package main

import (
    "log"
    "net"
    "os"
    "os/signal"
    "syscall"

    "google.golang.org/grpc"
)

func main() {
    listen, err := net.Listen("tcp", ":8080")
    if err != nil {
        panic(err)
    }
    server := grpc.NewServer()
    // something...
    
    go func() {
        if err = server.Serve(listen); err != nil {
              panic(err)
        }
    }()
    quit := make(chan os.Signal, 1)
    signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
    <-quit
    log.Println("Shutting down gRPC server...")
    server.GracefulStop()
    log.Println("gRPC server exiting...")
}

cron

robfig/cron包中虽然没提供关于gracefully shutdown的内容，至少提供了Start以及Stop方法，按照前几个实现的套路，我们可以自己动手实现一下gracefully shutdown。因为cron.Start本身会新起一个的goroutine启动server，所以我们在主goroutine中监听signal，在收到Signal后，执行cron.Stop()，而cron.Stop()会返回一个context，后续通过select监听context结束或者通过time.After等待超时，待当前所有定时任务结束后，进程结束。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
package main

import (
    "log"
    "os"
    "os/signal"
    "syscall"
    "time"
)

func main() {
    cronjob := cron.New()
    cronjob.AddFunc("@every 5s", func() { time.Sleep(10 * time.Second) })
    cronjob.Start()

    quit := make(chan os.Signal, 1)
    signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
    <-quit
    ctx := cronjob.Stop()
    log.Println("Shutting down cron...")
    select {
    case <-time.After(10 * time.Second):
        log.Fatal("Cron forced to shutdown...")
    case <-ctx.Done():
        log.Println("Cron exiting...")
    }
}

小结

本文只介绍了golang中如何实现平滑发版，一般框架都会给出关于gracefully shutdown的api，没有也没关系，套路就是正常启动server后，通过监听Signal并阻塞主goroutine，待接收到SIGNTERM等信号后，通过time.After或context.WithTimeout，作为超时处理，并等待进行中的goroutine全部结束。有兴趣可以查看各个类库中如何等待处理进行中的连接。

]]> <p>关于平滑发版，<a href="https://github.com/LKI" target="_blank" rel="noopener">紫月</a>写过一篇博客《<a href="https://liriansu.com/posts/2019-12-09-gracef Golang实现git-open https://www.wzmmmmj.com/2020/09/20/git-open/ 2020-09-20T23:44:28.000Z 2022-04-05T08:05:52.183Z git-open是GitHub上开源的一个git相关命令行工具，终端通过键入git open，会在浏览器中打开当前路径所在git项目的远端页面，支持多种代码托管平台，具体可查看官方文档。本质上git-open是一个shell脚本，核心代码仅有200+行。在无参数的前提下，主要有以下几步

  1. 判断当前路径是否在git工作区内
  2. 获取当前branch的remote-url
  3. 转换remote-url为托管仓库的页面地址
  4. 根据不同平台，命令行唤起浏览器

下文将依照以上步骤，通过Golang第三方库cobra来实现类似命令行功能，具体cobra用法，可移步官方文档

完整代码放置文章结尾，git open功能也已集成至ackerr/lab。

Step.0

首先建立好基础代码结构，并简单实现了两个工具函数

  • GitCommand: 简单封装Golang中执行git命令行
  • Err: 返回error时，输出报错信息，直接退出程序

具体代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
package main

import (
"github.com/spf13/cobra"
"os"
"os/exec"
)

func main() {
if err := rootCmd.Execute(); err != nil {
os.Exit(1)
}
}

// 定义命令
var rootCmd = &cobra.Command{
Use:  "git-open",
Run: openCurrentRepo,
}

// 核心逻辑
func openCurrentRepo(cmd *cobra.Command, args []string) {
    // do something
}

// 稍微封装一下git command
func GitCommand(args ...string) (string, error) {
cmd := exec.Command("git", args...)
output, err := cmd.Output()
return string(output), err
}

// 快捷退出
func Err(msg ...interface{}) {
fmt.Println(msg...)
os.Exit(1)
}

Step.1

通过git rev-parse，获取当前路径与.git目录相关信息，例如以下命令

判断当前路径是否在git工作区内

1
git rev-parse --is-inside-work-tree

获取.git目录路径

1
git rev-parse --git-dir

获取git项目绝对路径

1
git rev-parse --show-toplevel

更多git rev-parse命令可查看官方文档

从以上命令挑选一个判断当前是否在工作区中即可，伪代码如下

1
2
3
4
func CurrentGitRepo() (string, error) {
output, err := GitCommand("rev-parse", "-q", "--show-toplevel")
return output, err
}

Step.2

在git中，通过HEAD指针来指向当前分支或指向某个commit，来确定当前索引位置，记录在.git/HEAD文件中，而通过git symbolic-ref命令，可获取当前HEAD信息

获取当前分支名

1
git symbolic-ref --short HEAD

获取当前分支remote

1
git config branch.<branch>.remote

获取remote-url

1
git ls-remote --get-url <remote>

返回的remote-url即执行git remote add <remote-url>时，添加的那串url，一般有https或ssh两种形式，格式如下

1
2
3
4
5
# ssh  
git@github.com:Ackerr/lab.git

# https
https://github.com/Ackerr/lab.git

伪代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// 获取当前分支，如果不存在则使用master
func CurrentBranch() string {
branch, err := SymbolicRef("HEAD", true)
if branch == "" || err != nil {
branch = "master"
}
return branch
}

// 执行symbolic-ref命令
func SymbolicRef(ref string, short bool) (string, error) {
args := []string{"symbolic-ref"}
if short {
args = append(args, "--short")
}
args = append(args, ref)
output, err := GitCommand(args...)
return firstLine(output), err
}

// 通过分支获取当前remote，默认为origin
func CurrentRemote(branch string) string {
remote, err := GitCommand("config", fmt.Sprintf("branch.%s.remote", branch))
remote = firstLine(remote)
if remote == "" || err != nil {
remote = "origin"
}
return remote
}

// 通过remote获取remote-url，如果使用错误的remote，则报错退出
func RemoteURL(remote string) string {
gitURL, err := GitCommand("ls-remote", "--get-url", remote)
if err != nil {
Err("git remote is not set for", remote)
}
gitURL = firstLine(gitURL)
if gitURL == remote {
Err(remote, "is a wrong remote")
}
return gitURL
}

// 移除末尾换行符
func firstLine(output string) string {
if i := strings.Index(output, "\n"); i >= 0 {
return output[0:i]
}
return output
}

需要注意的一点，通过exec执行的git命令，返回值会在末尾添加换行符’\n’，所以每个命令结束都需要调用firstLine移除

Step.3

正常情况下，远端仓库页面地址结构为 <protocol>/<domain>/<repo path>，一般情况下protocol为https，GitLab与GitHub类型，转换代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// for example:
// git@github.com/Ackerr:lab.git     -> https://github.com/Ackerr/lab            
// https://github.com/Ackerr/lab.git -> https://github.com/Ackerr/lab
func TransferToURL(gitURL string) string {                                         
    var url string
    if strings.HasPrefix(gitURL, "https://") {
        url = gitURL[:len(gitURL)-4]
    }
    if strings.HasPrefix(gitURL, "git@") {
        url = gitURL[:len(gitURL)-4]
        url = strings.Replace(url, ":", "/", 1)
        url = strings.Replace(url, "git@", "https://", 1)
    }
    return url
}

Step.4

对于不同操作系统，可能使用不同的命令唤起浏览器，例如macOS默认通过open，而windows则通过start，当然也可以通过设置环境变量$BROWSER，切换默认命令，代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13
func searchBrowserLauncher() (browser string) {
    switch runtime.GOOS {
    case "darwin":
        browser = "open"
    case "windows":
        browser = "cmd /c start"
    case "linux":
        browser = "xdg-open"
    default:
        browser = ""
    }
    return browser
}

通过以上几步，git open的核心伪代码大致完成，接下来微调即可，完整代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
package main

import (
"errors"
"fmt"
"github.com/kballard/go-shellquote"
"github.com/spf13/cobra"
"os"
"os/exec"
"runtime"
"strings"
)

func main() {
if err := rootCmd.Execute(); err != nil {
os.Exit(1)
}
}

var rootCmd = &cobra.Command{
Use:  "git-open",
Run: openCurrentRepo,
}

func openCurrentRepo(cmd *cobra.Command, args []string) {
var remote string
if len(args) > 0 {
remote = args[0]
}
_, err := CurrentGitRepo()
if err != nil {
Err("not a git repository")
}
if remote == "" {
branch := CurrentBranch()
remote = CurrentRemote(branch)
}
gitURL := RemoteURL(remote)
url := TransferToURL(gitURL)
_ = OpenBrowser(url)
}

func GitCommand(args ...string) (string, error) {
cmd := exec.Command("git", args...)
cmd.Stderr = os.Stderr
output, err := cmd.Output()
return string(output), err
}

// 获取当前git项目路径
func CurrentGitRepo() (string, error) {
output, err := GitCommand("rev-parse", "-q", "--show-toplevel")
return output, err
}

// 获取当前分支，如果不存在则使用master
func CurrentBranch() string {
branch, err := SymbolicRef("HEAD", true)
if branch == "" || err != nil {
branch = "master"
}
return branch
}

func SymbolicRef(ref string, short bool) (string, error) {
args := []string{"symbolic-ref"}
if short {
args = append(args, "--short")
}
args = append(args, ref)
output, err := GitCommand(args...)
return firstLine(output), err
}

// 通过分支获取当前remote，默认为origin
func CurrentRemote(branch string) string {
remote, err := GitCommand("config", fmt.Sprintf("branch.%s.remote", branch))
remote = firstLine(remote)
if remote == "" || err != nil {
remote = "origin"
}
return remote
}

// 通过remote获取remote-url，如果使用错误的remote，则报错退出
func RemoteURL(remote string) string {
gitURL, err := GitCommand("ls-remote", "--get-url", remote)
if err != nil {
Err("git remote is not set for", remote)
}
gitURL = firstLine(gitURL)
if gitURL == remote {
Err(remote, "is a wrong remote")
}
return gitURL
}

// 移除末尾换行符
func firstLine(output string) string {
if i := strings.Index(output, "\n"); i >= 0 {
return output[0:i]
}
return output
}

// remote url转换为web url
func TransferToURL(gitURL string) string {
var url string
if strings.HasPrefix(gitURL, "https://") {
url = gitURL[:len(gitURL)-4]
}
if strings.HasPrefix(gitURL, "git@") {
url = gitURL[:len(gitURL)-4]
url = strings.Replace(url, ":", "/", 1)
url = strings.Replace(url, "git@", "https://", 1)
}
return url
}

// 输出报错，结束程序
func Err(msg ...interface{}) {
fmt.Println(msg...)
os.Exit(1)
}


// 唤起浏览器，打开url
func OpenBrowser(url string) error {
launcher, err := browserLauncher()
if err != nil {
return err
}
args := append(launcher, url)
cmd := exec.Command(args[0], args[1:]...)
return cmd.Run()
}

// 切分命令为数组，方便exec.Command执行
func browserLauncher() ([]string, error) {
browser := os.Getenv("BROWSER")
if browser == "" {
browser = searchBrowserLauncher()
} else {
browser = os.ExpandEnv(browser)
}

if browser == "" {
return nil, errors.New("please set $BROWSER to a web launcher")
}
return shellquote.Split(browser)
}

// 根据操作系统，返回默认browser command
func searchBrowserLauncher() (browser string) {
switch runtime.GOOS {
case "darwin":
browser = "open"
case "windows":
browser = "cmd /c start"
case "linux":
browser = "xdg-open"
default:
browser = ""
}
return browser
}

最后通过go build -o git-open，即可通过git-open，在浏览器中打开当前项目的远端页面。

]]> <p><a href="https://github.com/paulirish/git-open" target="_blank" rel="noopener">git-open</a>是GitHub上开源的一个git相关命令行工具，终端通过键入<code>git open</ gRPC之stream https://www.wzmmmmj.com/2020/09/06/grpc-stream/ 2020-09-06T23:48:06.000Z 2022-04-05T08:05:52.184Z HTTP/2中有两个概念，流（stream）与帧（frame），其中帧作为HTTP/2中通信的最小传输单位，通常一个请求或响应会被分为一个或多个帧传输，流则表示已建立连接的虚拟通道，可以传输多次请求或响应。每个帧中包含Stream Identifier，标志所属流。HTTP/2通过流与帧实现多路复用，对于相同域名的请求，通过Stream Identifier标识可在同一个流中进行，从而减少连接开销。 而gRPC基于HTTP/2协议传输，自然而然也实现了流式传输，其中gRPC中共有以下三种类型的流

  1. 服务端流式响应
  2. 客户端流式请求
  3. 两端双向流式

本篇主要讲讲如何实现gRPC三种流式处理。

Proto

通过在请求体或响应体前添加关键词stream，即可定义该消息体为流传输，base.proto如下所示

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
syntax = "proto3";

package proto;

option go_package = "base;base";


service BaseService {
    // 服务端流式响应
    rpc ServerStream (StreamRequest) returns (stream StreamResponse){}
    // 客户端流式请求
    rpc ClientStream (stream StreamRequest) returns (StreamResponse){}
    // 双向流式
    rpc Streaming (stream StreamRequest) returns (stream StreamResponse){}
}

message StreamRequest{
  string input = 1;
}

message StreamResponse{
  string output = 1;
}

执行protoc --go_out=. --go-grpc_out=. stream.prto，生成对应的Go Stub。

基础代码

这里先将附上代码模板
server.go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
package main

import (
"context"
"fmt"
"net"
"time"

pb "rpc/base"

"google.golang.org/grpc"
"google.golang.org/grpc/reflection"
)

type service struct {
pb.UnimplementedBaseServiceServer
}

func main() {
listen, err := net.Listen("tcp", ":50051")
if err != nil {
fmt.Println(err)
}
s := grpc.NewServer()
reflection.Register(s)
pb.RegisterBaseServiceServer(s, &service{})
s.Serve(listen)
}

func (s *service) ClientStream(stream pb.BaseService_ClientStreamServer) error {
    return nil 
}

func (s *service) ServerStream(in *pb.StreamRequest, stream pb.BaseService_ServerStreamServer) error {
  return nil
}

func (s *service) Streaming(stream pb.BaseService_StreamingServer) error {
    return nil
}

client.go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
package main

import (
"context"
"fmt"
"io"
"strconv"

pb "rpc/base"

"google.golang.org/grpc"
)

func main() {
conn, err := grpc.Dial(":50051", grpc.WithInsecure(), grpc.WithBlock())
if err != nil {
fmt.Println(err)
}
defer conn.Close()

c := pb.NewBaseServiceClient(conn)
}

func clientStream(client pb.BaseServiceClient, input string) error {
  return nil
}

func serverStream(client pb.BaseServiceClient, r *pb.StreamRequest) error {
  return nil
}

func stream(client pb.BaseServiceClient) error {
  return nil
}

服务端流式响应

与普通的gRPC代码不同的是，普通gRPC一次请求只会返回一次响应，而服务端流式响应通过调用stream.Send()，返回多次``StreamResponse`

1
2
3
4
5
6
7
8
9
10
// 服务端
func (s *service) ServerStream(in *pb.StreamRequest, stream pb.BaseService_ServerStreamServer) error {
    input := in.Input
    var output string
    for i := 0; i < len(input); i++ {
      output = fmt.Sprintf("index: %d, result: %s", i, string(input[i]))
     stream.Send(&pb.StreamResponse{Output: output})
    }
    return nil
}

客户端代码如下，通过for循环调用stream.Recv()，等待接收服务端响应并阻塞，直到出错或流结束。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 客户端
func serverStream(client pb.BaseServiceClient, r *pb.StreamRequest) error {
    fmt.Println("Server Stream Send:", r.Input)
    stream, _ := client.ServerStream(context.Background(), r)
    for {
        res, err := stream.Recv()
        if err == io.EOF {
            break
        }
        if err != nil {
            return err
        }
        fmt.Println("Server Stream Recv:", res.Output)
    }
    return nil
}

启动服务端，客户端执行serverStream(c, &pb.StreamRequest{Input: "something"})，输出如下：

1
2
3
4
5
6
7
8
9
10
Server Stream Send: something
Server Stream Recv: index: 0, result: s
Server Stream Recv: index: 1, result: o
Server Stream Recv: index: 2, result: m
Server Stream Recv: index: 3, result: e
Server Stream Recv: index: 4, result: t
Server Stream Recv: index: 5, result: h
Server Stream Recv: index: 6, result: i
Server Stream Recv: index: 7, result: n
Server Stream Recv: index: 8, result: g

不难看出，客户端一次请求，服务端将数据多次返回，从而实现服务端流式响应

客户端流式请求

与服务端流式响应类似，只不过转变为服务端for循环调用stream.Rece()，接收客户端消息并阻塞，等客户端调用stream.CloseAndRecv()，关闭流的发送后进入阻塞监听，服务端调用stream.SendAndClose()，返回响应体并关闭流。此方式客户端只负责发送流的结束，服务端可以在中途结束整个流处理。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 服务端
func (s *service) ClientStream(stream pb.BaseService_ClientStreamServer) error {
    output := ""
    for {
        r, err := stream.Recv()
        if err == io.EOF {
          return stream.SendAndClose(&pb.StreamResponse{Output: output})
        }
        if err != nil {
          fmt.Println(err)
        }
        output += r.Input
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// 客户端
func clientStream(client pb.BaseServiceClient, input string) error {
    stream, _ := client.ClientStream(context.Background())
    for _, s := range input {
        fmt.Println("Client Stream Send:", string(s))
        err := stream.Send(&pb.StreamRequest{Input: string(s)})
        if err != nil {
           return err
        }
    }
    res, err := stream.CloseAndRecv()
    if err != nil {
       fmt.Println(err)
    }
    fmt.Println("Client Stream Recv:", res.Output)
    return nil
}

客户端执行clientStream(c, "something")，输出如下：

1
2
3
4
5
6
7
8
9
10
Client Stream Send: s
Client Stream Send: o
Client Stream Send: m
Client Stream Send: e
Client Stream Send: t
Client Stream Send: h
Client Stream Send: i
Client Stream Send: n
Client Stream Send: g
Client Stream Recv: something

双向流式

由客户端发送流式请求，服务端通过流式响应，但具体的交互方式，根据编写的逻辑不同，效果也不同，类似于聊天室，开启聊天室后，怎么回复，回复多少，何时关闭，谁来关闭，根据适用场景而定。以下事例代码，客户端通过发送0-10，服务端累加返回。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// 客户端
func streaming(client pb.BaseServiceClient) error {
    stream, _ := client.Streaming(context.Background())
    for n := 0; n < 10; n++ {
        fmt.Println("Streaming Send:", n)
        err := stream.Send(&pb.StreamRequest{Input: strconv.Itoa(n)})
        if err != nil {
            return err
        }
        res, err := stream.Recv()
        if err == io.EOF {
            break
        }
        if err != nil {
            return err
        }
        fmt.Println("Streaming Recv:", res.Output)
    }
    stream.CloseSend()
    return nil
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 服务端
func (s *service) Streaming(stream pb.BaseService_StreamingServer) error {
    for n := 0; ; {
      res, err := stream.Recv()
      if err == io.EOF {
          return nil
      }
      if err != nil {
          return err
      }
      v, _ := strconv.Atoi(res.Input)
      n += v
      stream.Send(&pb.StreamResponse{Output: strconv.Itoa(n)})
  }
}

客户端执行streaming(c)，输出如下：

1
2
3
4
5
6
7
8
9
10
11
Streaming Send: 0
Streaming Recv: 0
Streaming Send: 1
Streaming Recv: 1
Streaming Send: 2
Streaming Recv: 3
Streaming Send: 3
Streaming Recv: 6
Streaming Send: 4
Streaming Recv: 10
.....

小结

本篇只是写了gRPC三种流式处理的简单demo，实际情况下，根据业务背景来选择该使用哪种流。例如双向流就类似于聊天室，或保持长连接类型，而传输数量量大时，可选择单向流，让接收方批量处理。

参考

]]> <p>HTTP/2中有两个概念，流（stream）与帧（frame），其中帧作为HTTP/2中通信的最小传输单位，通常一个请求或响应会被分为一个或多个帧传输，流则表示已建立连接的虚拟通道，可以传输多次请求或响应。每个帧中包含<strong>Stream Identifier</s 初识gRPC https://www.wzmmmmj.com/2020/08/23/rpc-and-grpc/ 2020-08-23T23:56:46.000Z 2022-04-05T08:05:52.187Z 前言

最近我司技术栈新增加了gRPC，小弟有幸使用gRPC实现了几个业务需求，本篇文章记录对RPC以及gRPC的一些浅显认知。

RPC

RPC，全称remote procedure call，即远程过程调用，也是一种客户端-服务器（client/server）模型，通俗讲RPC就是客户端像调用本地方法一样调用了远端服务中的方法，而无需关心具体调用细节。

这里先看看本地是如何调用函数的，伪代码如下：

1
2
3
4
5
def add(x, y):
    return x + y

a, b = 5, 10
result = add(a, b)

执行上述代码，大致经过以下步骤

  1. 定义a,b变量并赋值
  2. 执行add函数，将a,b值，赋值给x,y
  3. 执行x+y
  4. 退出add函数，将结果赋值给result

以上4步就是本地调用的过程。在不考虑调用函数逻辑情况下，调用RPC方法体验与本地函数调用基本一致。

不过因为RPC涉及网络调用，服务两端并不存在一个内存空间内，这样就会带来一些新问题

1.服务之间方法如何映射？

本地调用通过函数指针指定调用的函数，而RPC调用为了确保执行正确的函数，则需要客户端与服务端有一致函数映射，确保服务端执行的是客户端调用的，简单实现可以用过双方维护一套映射表，一般通过动态代理实现。

2.服务之间传输的信息结构？

本地调用只需将参数压入栈中，函数从栈中读取即可。而RPC调用，因为不在相同的内存空间，无法通过内存传递参数，并且需要通过网络传输，则需要一套序列化/反序列化机制，确保服务端将收到的 客户端的序列化后的参数 反序列化后 与 实际传参 意义一致。

3.服务之间如何通信？

客户端需要通过网络传输，将函数映射以及序列化后的内容发送给服务端，而服务端则需要返回内容给客户端。中间则需要选择传输协议，可以是传输层协议，也可以是应用层协议，如gRPC就使用HTTP/2。

解决了上述三个问题，也就实现了一个基础的RPC框架。

RPC调用流程

下图为一个完成的RPC过程：

image

笼统的讲，封装好的HTTP接口形式也可算作RPC的一种

gRPC

gRPC是google与2015年开源的RPC框架，相比于其他RPC框架，最显著的三大特点：

  1. ProtoBuf作为默认IDL
  2. 基于HTTP/2协议，具体HTTP/2实现可移步lxkaka
  3. 支持多种开发语言

gRPC交互流程

gRPC vs REST

高性能

基于HTTP/2的多路复用，减少TCP连接，首部压缩等特性以及ProtoBuf高效的二进制序列化，更高效的传输消息，节省带宽，从而提高吞吐量。

流处理

HTTP/2为实时通信流提供了基础。除了简单的RPC，gRPC中支持三种流组合：

  • 服务器流式响应
  • 客户端流式发送
  • 双向流

开发流程简单

相比于RESTful接口，无需思考请求方式，URL路径等规范，定义好proto请求响应结构，生成对应pb文件即可。

支持多语言

只需编写一份proto，通过命令行生成对应语言的Stub代码即可调用，而RESTful接口，每个调用方都需要实现一套基础调用类。

开发流程

体验下来，gRPC大致的开发流程如下：

  1. 定义proto文件，即定义Request和Response结构，以及包含多个方法的服务Service
  2. 通过protoc工具生成对应语言的Stub
  3. server实现proto中定义的接口，编写逻辑代码
  4. client通过生成的Stub调用server

示例代码

Go编写一个获取服务器时间的rpc接口，示例代码如下：

time.proto

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
syntax = "proto3";

package proto;

option go_package = "base;base";

service BaseService {
    rpc GetTime (TimeRequest) returns (TimeResponse){}
}

message TimeRequest {}

message TimeResponse {
  string time = 1;
}

通过protoc生成服务端以及客户端的Stub代码

1
protoc --go_out=. --go-grpc_out=.  time.proto

server.go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
package main

import (
"context"
"fmt"
"net"
"time"

pb "rpc/base"

"google.golang.org/grpc"
"google.golang.org/grpc/reflection"
)

type service struct {
pb.UnimplementedBaseServiceServer
}

func main() {
listen, err := net.Listen("tcp", ":50051")
if err != nil {
fmt.Println(err)
}
s := grpc.NewServer()
reflection.Register(s)
pb.RegisterBaseServiceServer(s, &service{})
s.Serve(listen)
}

func (s *service) GetTime(ctx context.Context, in *pb.TimeRequest) (*pb.TimeResponse, error) {
now := time.Now().Format("2006-01-02 15:04:05")
return &pb.TimeResponse{Time: now}, nil
}

client.go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
package main

import (
"context"
"fmt"
"time"

pb "rpc/base"

"google.golang.org/grpc"
)

func main() {
conn, err := grpc.Dial(":50051", grpc.WithInsecure(), grpc.WithBlock())
if err != nil {
fmt.Println(err)
}
defer conn.Close()

c := pb.NewBaseServiceClient(conn)

getTime(c)
}

func getTime(client pb.BaseServiceClient) error {
ctx, cancel := context.WithTimeout(context.Background(), time.Second)
defer cancel()
r, _ := client.GetTime(ctx, &pb.TimeRequest{})
fmt.Println("Time:", r.Time)
return nil
}

小结

对于简单的需求实现，gRPC很容易上手，编写protobuf并不需要额外去了解什么语法，类似interface。而如果要实现gRPC高可用，还有很多路要走。

参考

]]> <h2 id="前言"><a href="#前言" class="headerlink" title="前言"></a>前言</h2><p>最近我司技术栈新增加了gRPC，小弟有幸使用gRPC实现了几个业务需求，本篇文章记录对RPC以及gRPC的一些浅显认知。</p> <h2 i 深入浅出Redis之ziplist https://www.wzmmmmj.com/2020/08/02/redis-ziplist/ 2020-08-02T21:55:29.000Z 2022-04-05T08:05:52.187Z Ziplist是Redis中为了节约内存空间而实现的顺序性数据结构，通过一系列特殊编码，将数据与其编码信息存储在连续内存中，一个ziplist可以包含多个节点，每个节点可存储一个字节数组或一个整数值，其中对于节点值类型存储还采用了变长的编码方式。具体实现在ziplist.c和ziplist.h文件中。

Redis3.2版本前，ziplist与adlist作为列表对象的底层实现，而3.2后列表对象的底层实现改为quciklist，而ziplist则在quicklist中被应用，除了quicklist，ziplist还被用于zset的底层实现。

数据结构

列表构成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#define ZIPLIST_HEADER_SIZE     (sizeof(uint32_t)*2+sizeof(uint16_t))
#define ZIPLIST_END_SIZE        (sizeof(uint8_t))
#define ZIPLIST_BYTES(zl)       (*((uint32_t*)(zl)))
#define ZIPLIST_LENGTH(zl)      (*((uint16_t*)((zl)+sizeof(uint32_t)*2)))
#define ZIPLIST_TAIL_OFFSET(zl) (*((uint32_t*)((zl)+sizeof(uint32_t))))
#define ZIP_END 255

unsigned char *ziplistNew(void) {
    /* 内存申请 */
    unsigned int bytes = ZIPLIST_HEADER_SIZE+ZIPLIST_END_SIZE;
    unsigned char *zl = zmalloc(bytes);
    /* 默认值赋值 */
    ZIPLIST_BYTES(zl) = intrev32ifbe(bytes);
    ZIPLIST_TAIL_OFFSET(zl) = intrev32ifbe(ZIPLIST_HEADER_SIZE);
    ZIPLIST_LENGTH(zl) = 0;
    zl[bytes-1] = ZIP_END;
    return zl;
}

通过初始化函数ziplistNew，可知压缩列表本质上是一个字节数组。初始化ziplist过程，一共申请了11字节的内存空间，其中包括两个uint32_t，一个uint16_t，一个uint8_t。初始化后压缩列表内部内存分布如下

组成部分含义：

  • zlbytes，表示整个压缩列表占用字节数，包括其自身4字节
  • zltail，表示到最后一位节点的偏移量，从而能O(1)复杂度获取末尾节点
  • zllen，表示压缩列表中节点个数。
  • entry，压缩列表中的每个节点，其中节点长度由保存内容定义
  • zlend，用于标记压缩列表结尾，使用特殊值255

其中，因为zllen只有两个字节，当压缩列表中节点数大于65534（2^16 - 2）时，都记为65535，而节点的真实数量需要遍历整个压缩列表，此时获取元素个数的时间复杂度从O(1)上升为O(n)。

列表节点构成

列表节点entry，其中逻辑结构如下：

1
<prevlen> <encoding> <content>

prevlen

prevlen表示前节点的节点长度，方便反向遍历。根据前一个节点的长度，分为两种情况：

  • 前节点长度小于254时，占用1字节，用来表示前节点长度
  • 前节点长度大于等于254时，占用5字节，其中第1个字节为特殊值0xFE(254)，后面4字节用来表示实际长度

如下源码所示，判断节点的第1个字节，如果其小于254，则该值为前节点长度，否则后4字节的值，为前节点长度。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#define ZIP_BIG_PREVLEN 254

/* prevlen内存占用字节数 */
#define ZIP_DECODE_PREVLENSIZE(ptr, prevlensize) do {                          \
    if ((ptr)[0] < ZIP_BIG_PREVLEN) {                                          \
        (prevlensize) = 1;                                                     \
    } else {                                                                   \
        (prevlensize) = 5;                                                     \
    }                                                                          \
} while(0);

/* 前节点内存占用 */
#define ZIP_DECODE_PREVLEN(ptr, prevlensize, prevlen) do {                     \
    ZIP_DECODE_PREVLENSIZE(ptr, prevlensize);                                  \
    if ((prevlensize) == 1) {                                                  \
        (prevlen) = (ptr)[0];                                                  \
    } else if ((prevlensize) == 5) {                                           \
        assert(sizeof((prevlen)) == 4);                                        \
        memcpy(&(prevlen), ((char*)(ptr)) + 1, 4);                             \
        memrev32ifbe(&prevlen);                                                \
    }                                                                          \
} while(0);

content

节点的content负责保存节点的值，节点值可以是一个字节数组或者整数，值的类型和长度由节点的encoding属性决定

encoding

encoding表示当前节点的数据类型以及长度，其中整数节点，encoding均为1字节，而字符串根据长度不同，可能为1，2，5字节。具体的encoding值与数据类型对照表如下

字节值占用字节数据长度特别说明
110000001int16_t类型的整数
110100001int32_t类型的整数
111000001int64_t类型的整数
11110000124位有符号整数
1111111018位有符号整数
1111xxxx10-12的无符号整数数据存储在encoding部分的后4位，使用0001-1101表示0-12
00xxxxxx1<=6bits的字节数组前两位表示类型，后6位为数据长度
01xxxxxx+<1 bytes>2<=14bits的字节数组前两位表示类型，后14位为数据长度
10000000+<4 bytes>5<=32bits的字节数组前两位表示类型，接着6位留空，后32位为数据长度

zlentry

因为压缩列表本质只是字节数组，为了方便操作，redis还定义了zlentry结构体，操作时，将每个节点包含信息按照一定规则写入zlentry中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
typedef struct zlentry {
    unsigned int prevrawlensize; /* Bytes used to encode the previous entry len*/
    unsigned int prevrawlen;     /* Previous entry len. */
    unsigned int lensize;        /* Bytes used to encode this entry type/len.
                                    For example strings have a 1, 2 or 5 bytes
                                    header. Integers always use a single byte.*/
    unsigned int len;            /* Bytes used to represent the actual entry.
                                    For strings this is just the string length
                                    while for integers it is 1, 2, 3, 4, 8 or
                                    0 (for 4 bit immediate) depending on the
                                    number range. */
    unsigned int headersize;     /* prevrawlensize + lensize. */
    unsigned char encoding;      /* Set to ZIP_STR_* or ZIP_INT_* depending on
                                    the entry encoding. However for 4 bits
                                    immediate integers this can assume a range
                                    of values and must be range-checked. */
    unsigned char *p;            /* Pointer to the very start of the entry, that
                                    is, this points to prev-entry-len field. */
} zlentry;

/* 将包含节点信息的字节数组属性 写入zlentry结构体中 */
void zipEntry(unsigned char *p, zlentry *e) {

    ZIP_DECODE_PREVLEN(p, e->prevrawlensize, e->prevrawlen);
    ZIP_DECODE_LENGTH(p + e->prevrawlensize, e->encoding, e->lensize, e->len);
    e->headersize = e->prevrawlensize + e->lensize;
    e->p = p;
}

连锁更新

每个节点会存在prevlen属性，用来记录前置节点的长度，根据前置节点长度还分为两种情况，当长度大于等于254时，占用空间会从1字节扩大到5字节。所谓连锁更新，就是多个长度处于250字节~253字节之间的连续节点，当一个节点更新后，导致下一个节点prevlen由1字节变为5字节，从而导致下下一个节点prevlen值增大，产生连锁反应。因为连锁更新在最坏情况下需要对压缩列表执行N次空间预分配，而每次空间预分配的最坏复杂度为O(n)，所以连锁更新的最坏复杂度为O(n^2)。不过，虽然连锁更新的复杂度高，但出现的几率较低，需要多个特殊长度的节点，所以插入删除命令的平均复杂度均为O(n)，最坏复杂度为O(n^2)。
以下是连锁更新的部分源码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
unsigned char *__ziplistCascadeUpdate(unsigned char *zl, unsigned char *p) {
    size_t curlen = intrev32ifbe(ZIPLIST_BYTES(zl)), rawlen, rawlensize;
    size_t offset, noffset, extra;
    unsigned char *np;
    zlentry cur, next;

    /* 是否到末尾 */
    while (p[0] != ZIP_END) {
        /* 解析当前节点信息 */
        zipEntry(p, &cur);
        /* 当前节点长度 */
        rawlen = cur.headersize + cur.len;
        /* 当前节点长度信息需要的长度 */
        rawlensize = zipStorePrevEntryLength(NULL,rawlen);

        /* 列表末尾 */
        if (p[rawlen] == ZIP_END) break;
        /* 解析下一个节点信息 */
        zipEntry(p+rawlen, &next);

        /* 下一个节点prevlen未发生更新 */
        if (next.prevrawlen == rawlen) break;

        /* prevlen发生更新 */
        if (next.prevrawlensize < rawlensize) {
            /* 当前节点与ziplist的偏移量 */
            offset = p-zl;
            /* 重新更大的内存空间 */
            extra = rawlensize-next.prevrawlensize;
            zl = ziplistResize(zl,curlen+extra);
            /* p新内存地址 */
            p = zl+offset;

            /* 下一个节点 */
            np = p+rawlen;
            noffset = np-zl;

            /* 如果下一个节点还不是末尾节点，则更新ziplist的zltail属性*/
            if ((zl+intrev32ifbe(ZIPLIST_TAIL_OFFSET(zl))) != np) {
                ZIPLIST_TAIL_OFFSET(zl) =
                    intrev32ifbe(intrev32ifbe(ZIPLIST_TAIL_OFFSET(zl))+extra);
            }

            /* 内存向后移动 */
            memmove(np+rawlensize,
                np+next.prevrawlensize,
                curlen-noffset-next.prevrawlensize-1);
            /* 记录新的prevlen */
            zipStorePrevEntryLength(np,rawlen);

            /* 向下一个节点移动 */
            p += rawlen;
            curlen += extra;
        } else {
            /* 如果下一个节点原本的prevlen字段可以容纳新节点长度信息，则直接写入 */
            if (next.prevrawlensize > rawlensize) {
                zipStorePrevEntryLengthLarge(p+rawlen,rawlen);
            } else {
                zipStorePrevEntryLength(p+rawlen,rawlen);
            }

            /* 更新结束，退出遍历 */
            break;
        }
    }
    return zl;
}

int zipStorePrevEntryLengthLarge(unsigned char *p, unsigned int len) {
    if (p != NULL) {
        p[0] = ZIP_BIG_PREVLEN;
        memcpy(p+1,&len,sizeof(len));
        memrev32ifbe(p+1);
    }
    return 1+sizeof(len);
}

unsigned int zipStorePrevEntryLength(unsigned char *p, unsigned int len) {
    if (p == NULL) {
        return (len < ZIP_BIG_PREVLEN) ? 1 : sizeof(len)+1;
    } else {
        if (len < ZIP_BIG_PREVLEN) {
            p[0] = len;
            return 1;
        } else {
            return zipStorePrevEntryLengthLarge(p,len);
        }
    }
}

小结

ziplist是Redis为了节省内存而自定义的一种特殊编码的顺序性数据结构，与双端链表adlist相比，具有以下特点：

  • 整个ziplist存在一个连续内存中
  • 通过固定内存偏移量获取头节点，保留与尾节点的偏移量zltail，而不像双端链表存储头尾节点
  • 每个节点保留前置节点的长度，从而实现反向遍历，而不像双端链表存储前置节点指针
  • 每个节点采用变长的编码方式，存储字符串或整数值
  • 在特定条件下，ziplist会发生连锁更新，导致增删操作时间复杂度由O(n)变为O(n^2)

参考

]]> <p>Ziplist是Redis中为了节约内存空间而实现的顺序性数据结构，通过一系列特殊编码，将数据与其编码信息存储在连续内存中，一个ziplist可以包含多个节点，每个节点可存储一个字节数组或一个整数值，其中对于节点值类型存储还采用了变长的编码方式。具体实现在ziplist.c 深入浅出Redis之adlist https://www.wzmmmmj.com/2020/07/19/redis-adlist/ 2020-07-19T22:32:18.000Z 2022-04-05T08:05:52.186Z Adlist，全称A generic doubly linked list，其实就是Redis中自定义的双端链表，作为一个通用数据结构，主要作用于一些Redis的功能模块，例如RedisServer中关联多个client或者RedisClient中的输出缓冲区等。具体adlist源码实现在adlist.c和adlist.h文件中。

Redis3.2版本前，列表的底层实现是由adlist和ziplist组成，后被quicklist取代，关于quicklist与ziplist后续会单独讲。

数据结构

首先查看头文件adlist.h，对listNode的类型定义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
typedef struct listNode {
    struct listNode *prev;  /* 前驱节点 */
    struct listNode *next;  /* 后驱节点 */
    void *value;  /* 节点值 */
} listNode;

typedef struct list {
    listNode *head;  /* 链表头结点 */
    listNode *tail;  /* 链表尾结点 */
    void *(*dup)(void *ptr);  /* 自定义复制函数 */
    void (*free)(void *ptr);  /* 自定义释放函数 */
    int (*match)(void *ptr, void *key);  /* 自定义比较函数 */
    unsigned long len;  /* 链表长度 */
} list;

通过前驱节点prev与后驱节点next连接多个listNode，即可实现双端链表，不过adlist中还定义了结构体list，字段含义如下：

  • head/tail：分别指向链表的头尾节点，从而更方便获取头尾节点进行操作
  • len：保存链表长度，使查询链表长度只需要O(1)时间复杂度

对于表头节点的prev指针，以及表尾节点的next指针都会指向NULL，所以adlist还是一个无环链表。

listNode中使用void *指针保存节点值，对节点值的类型不做限制，从而实现多态链表。而对于不同类型的节点值，需要类型特定函数来处理某些操作，所以list中可自定义三类函数指针，这些函数指针也是通过void *进行保存，对函数类型不做限制。

  • dup：自定义复制函数，未定义时，默认的复制方式是同享数据
  • free：自定义释放函数，对于一些复杂节点值，可能会需要额外释放内存，未定义时，只释放list本身
  • match：自定义比较函数，例如调用listSearchKey时，会调用该函数查看结果是否为true，未定义时，比较数据的指针值

综上，Redis中adlist的结构如下图所示：

redis adlist

迭代器

除了双端链表的基本结构外，adlist.h中还定义了双端链表的迭代器，对于链表遍历操作，都需要通过listIter实例进行，而list则专注于保存节点值。数据结构如下：

1
2
3
4
5
6
7
#define AL_START_HEAD 0  /* 从头开始 */
#define AL_START_TAIL 1  /* 从尾开始 */

typedef struct listIter {
    listNode *next; /* 下一个节点指针 */
    int direction;  /* 遍历方向 */
} listIter;

其中，listIter对象根据变量direction，判断遍历方向。以下是listIter对象的创建及使用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
/* 根据传参返回链表迭代器 */
listIter *listGetIterator(list *list, int direction)
{
    listIter *iter;
    /* 分配内存 */
    if ((iter = zmalloc(sizeof(*iter))) == NULL) return NULL;
    /* 根据传参direction，判断遍历方向  */
    if (direction == AL_START_HEAD)
        iter->next = list->head;
    else
        iter->next = list->tail;
    iter->direction = direction;
    return iter;
}

/* 获取下一个节点 */
listNode *listNext(listIter *iter)
{
    listNode *current = iter->next;
    /* 判断是否到头 or 尾节点 */
    if (current != NULL) {
        /* 判断遍历方向 */
        if (iter->direction == AL_START_HEAD)
            iter->next = current->next;
        else
            iter->next = current->prev;
    }
    return current;
}

adlist的一些操作

Redis中adlist的创建，添加节点无异于其他双端链表，感兴趣可以自行查看。这里列举一些与dup/free/match函数相关的api源码，加深对这三类函数指针的理解。

清空

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
/* 清空链表所有节点内存 */
void listEmpty(list *list)
{
    unsigned long len;
    listNode *current, *next;

    current = list->head;
    len = list->len;
    /* 递归释放节点值 */
    while(len--) {
        next = current->next;
        /* 判断free是否定义，如果定义，则传入调用free，释放节点值内存 */
        if (list->free) list->free(current->value);
        /* 释放节点本身内存 */
        zfree(current);
        current = next;
    }
    /* 清空链表节点 */
    list->head = list->tail = NULL;
    list->len = 0;
}

/* 先调用listEmpty释放每个节点的内存，在调用zfree释放list本身内存 */
void listRelease(list *list)
{
    listEmpty(list);
    zfree(list);
}

复制

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
/* 复制一个相同的list */
list *listDup(list *orig)
{
    list *copy;
    listIter iter;
    listNode *node;

    /* 新建list，将dup/free/match函数赋值 */
    if ((copy = listCreate()) == NULL)
        return NULL;
    copy->dup = orig->dup;
    copy->free = orig->free;
    copy->match = orig->match;
    /* 初始化迭代器 */
    listRewind(orig, &iter);
    /* 递归迭代器，主要是复制节点值 */
    while((node = listNext(&iter)) != NULL) {
        void *value;
        /* 判断dup函数是否定义 */
        if (copy->dup) {
            /* 如果有，则通过dup进行赋值节点值 */
            value = copy->dup(node->value);
            if (value == NULL) {  /* 如果失败则释放内存，并直接return */
                listRelease(copy);
                return NULL;
            }
        } else
            /* 未定义dup函数，则共享节点值指针 */
            value = node->value;
        /* 将节点添加到链表尾部，如果失败则释放内存，并直接return */
        if (listAddNodeTail(copy, value) == NULL) {
            listRelease(copy);
            return NULL;
        }
    }
    return copy;
}

查找

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
/* 链表中查看是否存在与key相同的值 */
listNode *listSearchKey(list *list, void *key)
{
    listIter iter;
    listNode *node;
    /* 初始化迭代器 */
    listRewind(list, &iter);
    /* 递归迭代器，主要是比较节点值与key，如果相同则直接return */
    while((node = listNext(&iter)) != NULL) {
        /* 判断是否定义match函数 */
        if (list->match) {
            /* 如果有，则通过match，比较节点值与key是否"相同" */
            if (list->match(node->value, key)) {
                return node;
            }
        } else {
            /* 未定义，则直接比较节点值与key是否相同 */
            if (key == node->value) {
                return node;
            }
        }
    }
    /* 未找到则返回NULL */
    return NULL;
}

小结

Redis中实现的双端链表adlist，相同于基础的双端链表，具有以下几个特点：

  1. 节点值为void *类型，可为任意类型;
  2. list结构中dup/free/match属性，也为void *类型，可以为链表设置类型特定函数，从而处理不同类型的节点值;
  3. list结构中head/tail属性，使得获取头尾节点以只需要O(1)的时间复杂度，并且可以正序/倒序访问;
  4. list结构中len属性，使得获取链表长度只需要O(1)的时间复杂度；
  5. 链表表头节点的prev指针与表尾节点next都指向NULL，从而adlist为无环链表;
  6. 链表的迭代操作由迭代器listIter对象完成。

参考

]]> <p>Adlist，全称A generic doubly linked list，其实就是Redis中自定义的双端链表，作为一个通用数据结构，主要作用于一些Redis的功能模块，例如RedisServer中关联多个client或者RedisClient中的输出缓冲区等。具体adl 深入浅出Redis之sds https://www.wzmmmmj.com/2020/07/12/redis-sds/ 2020-07-12T23:25:24.000Z 2022-04-05T08:05:52.186Z

最近在看《Redis的设计与实现》，感觉书还不错，但由于书中讲解的Redis版本较低，有些地方与现版本有出入，所以通过简单浏览源码，加深理解。本文代码使用Redis6.0

SDS，全称Simple Dynamic String，作为Redis中的字符串表示，主要作用于Redis中字符串对象StringObject的底层实现，以及Redis内部作为char*类型的替代品。具体sds源码实现在sds.c和sds.h文件中。

数据结构

查看sds.h文件，不难发现对sds的类型定义，其实就是char *的一个alias。

1
typedef char *sds;

尽管C语言字符串本质上也是char *，不过与之不同的是，一个sds的完整结构，分为两块部分，sdshdr结构和字符数组。以下为sdshdr结构体：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
struct __attribute__ ((__packed__)) sdshdr5 {
    unsigned char flags; /* 3 lsb of type, and 5 msb of string length */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len; /* used */
    uint8_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr16 {
    uint16_t len;
    uint16_t alloc;
    unsigned char flags;
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr32 {
    uint32_t len;
    uint32_t alloc;
    unsigned char flags;
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr64 {
    uint64_t len;
    uint64_t alloc;
    unsigned char flags;
    char buf[];
};

/* flags常量 */
#define SDS_TYPE_5  0
#define SDS_TYPE_8  1
#define SDS_TYPE_16 2
#define SDS_TYPE_32 3
#define SDS_TYPE_64 4

sds针对不同的字符串长度，为了节省内存，定义了五种类型的header，其中sdshdr5较为特殊，与其他header结构不同，它并没有alloc和len字段，所以flags字段被分为两部分，低三位作为header类型，高五位记录字符串长度。因为不具备alloc字段，所以sdshdr5不会预分配空间，如果字符串动态增加，则需要重新分配内存，大部分场景不太会使用sdshdr5。其余4个header的结构类似，字段含义如下

  • len： 字符串真实长度
  • alloc：字符串当前可使用的最大容量
  • flags：占一字节，前三位表示header类型

其中结构体中，有几个特殊的点

  • __attribute__ ((__packed__))表示编译器不需要对结构体进行内存对齐，从而使字段内存连续
  • char buf[]，未指定长度且定义在结构体的最后一个字段，是一个柔性数组，表示flags字段后是一个字符数组，而柔性数组buf[]只作为一个符号地址存在，通过sizeof 返回的结构大小不包括柔性数组的内存大小

对内存对齐与柔性数组的详细解释：内存对齐与柔性数组

通过源码中定义的宏以及sdslen方法不难看出这两点

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#define SDS_TYPE_MASK 7
#define SDS_TYPE_BITS 3

#define SDS_HDR_VAR(T,s) struct sdshdr##T *sh = (void*)((s)-(sizeof(struct sdshdr##T)));
#define SDS_HDR(T,s) ((struct sdshdr##T *)((s)-(sizeof(struct sdshdr##T))))
#define SDS_TYPE_5_LEN(f) ((f)>>SDS_TYPE_BITS)

static inline size_t sdslen(const sds s) {
    unsigned char flags = s[-1];
    switch(flags&SDS_TYPE_MASK) {
        case SDS_TYPE_5:
            return SDS_TYPE_5_LEN(flags);  /* sdshdr5 len保存在flags的高五位中*/
        case SDS_TYPE_8:
            return SDS_HDR(8,s)->len;
        case SDS_TYPE_16:
            return SDS_HDR(16,s)->len;
        case SDS_TYPE_32:
            return SDS_HDR(32,s)->len;
        case SDS_TYPE_64:
            return SDS_HDR(64,s)->len;
    }
    return 0;
}

”##“ 连接符，预处理运算符，例如SDS_HDR(8,s)宏展开后是((struct sdshdr8 *)((s)-(sizeof(struct sdshdr8))))

其中因为buf[]是柔性数组，sizeof(struct sdshdr8)不会包含数组大小，SDS_HDR即表示字符串向前偏移结构体的大小，从而获得header起始位置的指针。而flags则可以通过s向前偏移一个字节获得，即flags=s[-1]

综上，不难看出sds结构体中的header部分，实际存储在字符数组之前，如下图所示

1
2
3
4
5
+---------------------+-------------------------------+-----------+
| len | alloc | flags | Binary safe C alike string... | Null term |
+---------------------+-------------------------------+-----------+
          |           |
          `->Header   `-> Pointer returned to the user.

SDS的一些操作

创建

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
/* 通过sdsnew函数为字符数组创建一个sds */
sds sdsnew(const char *init) {
    size_t initlen = (init == NULL) ? 0 : strlen(init);
    return sdsnewlen(init, initlen);
}

sds sdsnewlen(const void *init, size_t initlen) {
    void *sh;
    sds s;
    char type = sdsReqType(initlen);  /* 根据所给字符串长度给出适合的sds类型 */
    /* 长度为0时，由于可能会进行追加操作，而SDS_TYPE_5不适合追加数据，所以sds类型为SDS_TYPE_8*/
    if (type == SDS_TYPE_5 && initlen == 0) type = SDS_TYPE_8;
    int hdrlen = sdsHdrSize(type); /* 根据sds类型返回对应的sdshdr大小 */
    unsigned char *fp; /* flags pointer. */

    sh = s_malloc(hdrlen+initlen+1); /* 申请内存，需要为终止符\0额外申请1字节*/
    if (sh == NULL) return NULL;
    if (init==SDS_NOINIT)
        init = NULL;
    else if (!init)
        memset(sh, 0, hdrlen+initlen+1); /* 分配内存 */
    s = (char*)sh+hdrlen; /* 内存向右偏移sdshdr大小，获取数组指针 */
    fp = ((unsigned char*)s)-1; /* 数组指针向左偏移一位，获取flags指针 */
    switch(type) {  /* 根据sds类型，设置sdshdr alloc len flags 值 */
        case SDS_TYPE_5: {
            *fp = type | (initlen << SDS_TYPE_BITS);
            break;
        }
        case SDS_TYPE_8: {
            SDS_HDR_VAR(8,s);
            sh->len = initlen;
            sh->alloc = initlen;
            *fp = type;
            break;
        }
        ...
    }
    if (initlen && init)
        memcpy(s, init, initlen);
    s[initlen] = '\0';  /* 字符结尾设置\0终止符 */
    return s;
}

扩容&空间预分配

大多数追加操作中，都会调用到扩容，其中根据新长度的大小，扩容大小也不同，一般为新长度的两倍，在大小为1Mb后，每次扩容变为增加1Mb，从而实现内存预分配内存

1
2
3
4
5
6
#define SDS_MAX_PREALLOC (1024*1024)

if (newlen < SDS_MAX_PREALLOC)
    newlen *= 2;
else
    newlen += SDS_MAX_PREALLOC;

完整代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
sds sdsMakeRoomFor(sds s, size_t addlen) {
    void *sh, *newsh;
    size_t avail = sdsavail(s);  /* sds剩余可用 即s.alloc - s.len */
    size_t len, newlen;
    char type, oldtype = s[-1] & SDS_TYPE_MASK;
    int hdrlen;

    /* 有足够空间则返回 */
    if (avail >= addlen) return s;

    len = sdslen(s); /* 字符串长度 */
    sh = (char*)s-sdsHdrSize(oldtype);  /* sdshdr指针 */
    newlen = (len+addlen);  /* 新长度 */
    if (newlen < SDS_MAX_PREALLOC)
        newlen *= 2;
    else
        newlen += SDS_MAX_PREALLOC;

    type = sdsReqType(newlen); /* 新长度合适的sds类型 */

    /* 扩容时一般不为SDS_TYPE_5 */
    if (type == SDS_TYPE_5) type = SDS_TYPE_8;

    hdrlen = sdsHdrSize(type); /* 新sdshdr大小 */
    if (oldtype==type) {
        newsh = s_realloc(sh, hdrlen+newlen+1);
        if (newsh == NULL) return NULL;
        s = (char*)newsh+hdrlen;
    } else {
        /* 分配内存，拷贝原字符串，释放原sds内存，并设置好flags以及len */
        newsh = s_malloc(hdrlen+newlen+1);
        if (newsh == NULL) return NULL;
        memcpy((char*)newsh+hdrlen, s, len+1);
        s_free(sh);
        s = (char*)newsh+hdrlen;
        s[-1] = type;
        sdssetlen(s, len);
    }
    sdssetalloc(s, newlen);
    return s;
}

缩容&惰性空间释放

当某些操作后，减少了原有字符串大小，sds并不会立即重新释放空间，重新分配内存，而是继续保留那么多空间，说不定下次就用上了。例如sdsclear操作

1
2
3
4
5
// 将len字段设置为0，但内存空间不释放。
void sdsclear(sds s) {
    sdssetlen(s, 0);
    s[0] = '\0';
}

当然必要的时候也可以调用sdsRemoveFreeSpace，主动缩容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
sds sdsRemoveFreeSpace(sds s) {
    void *sh, *newsh;
    char type, oldtype = s[-1] & SDS_TYPE_MASK;
    int hdrlen, oldhdrlen = sdsHdrSize(oldtype);
    size_t len = sdslen(s);
    size_t avail = sdsavail(s);
    sh = (char*)s-oldhdrlen;

    /* 可用空间为0，说明没必要缩容 */
    if (avail == 0) return s;

    /* 通过比较sdshdrd大小*/
    type = sdsReqType(len);
    hdrlen = sdsHdrSize(type);

    /* If the type is the same, or at least a large enough type is still
     * required, we just realloc(), letting the allocator to do the copy
     * only if really needed. Otherwise if the change is huge, we manually
     * reallocate the string to use the different header type. */
    if (oldtype==type || type > SDS_TYPE_8) {
        newsh = s_realloc(sh, oldhdrlen+len+1);
        if (newsh == NULL) return NULL;
        s = (char*)newsh+oldhdrlen;
    } else { /* 空余空间较大，直接重新分配内存 */
        newsh = s_malloc(hdrlen+len+1);
        if (newsh == NULL) return NULL;
        memcpy((char*)newsh+hdrlen, s, len+1);
        s_free(sh);
        s = (char*)newsh+hdrlen;
        s[-1] = type;
        sdssetlen(s, len);
    }
    sdssetalloc(s, len);
    return s;
}

小结

sds相比于C语言字符串，具有以下几个显著的特点：

  1. 结构中存储字符串长度，获取字符长度只需要常量时间复杂度，而原生字符串则需要遍历数组；
  2. 二进制安全，可以存储字节数据，因为存储字符串长度，不会提前遇到\0字符而终止；
  3. 杜绝缓冲区溢出，C语言字符串本身不记录数组长度，增加操作时，分配内存不足时容易造成缓冲区溢出，而sds因为存在alloc，会在修改时，检查空间大小是否满足；
  4. 内存预分配以及惰性删除，减少内存重新分配次数；
  5. 兼容C标准库中的部分字符串函数。

参考

]]> <blockquote> <p>最近在看《Redis的设计与实现》，感觉书还不错，但由于书中讲解的Redis版本较低，有些地方与现版本有出入，所以通过简单浏览源码，加深理解。本文代码使用<a href="https://github.com/redis/redis/tree/6. Vim中的寄存器：Register https://www.wzmmmmj.com/2020/05/18/vim-register/ 2020-05-18T00:27:57.000Z 2022-04-05T08:05:52.188Z 刚接触vim时，相信多多少少都会遇到关于复制粘贴的问题，例如以下两个问题

  1. Vim编辑的内容如何复制到其他地方？
  2. Vim中如何复制(y)一段内容后，多次复用，而不会被替换内容覆盖？

其实这些问题都可能跟Vim中的寄存器有关，寄存器可以想象成内存中存储某些文本的空间，类似于粘贴板。在使用y，p，d等命令时，都会不经意间的操作Vim的寄存器。

基本用法

Normal模式下，使用"{register}{command}， 例如"add，表示删除当前行内容，并将内容保存至"a寄存器中，而使用"ap，则可以粘贴"a寄存器中的内容。而插入模式下，使用ctrl-r a来表示粘贴"a寄存器中的内容。

Vim中输入:register，会输出使用中的寄存器以及其保存的值，或者:register x指定输出某些寄存器。

寄存器类型

Vim中输入 :help registers，其中介绍了vim中10种类型的寄存器

1
2
3
4
5
6
7
8
9
10
11
There are ten types of registers:*registers* *{register}* *E354*
1. The unnamed register ""
2. 10 numbered registers "0 to "9
3. The small delete register "-
4. 26 named registers "a to "z or "A to "Z
5. Three read-only registers ":, "., "%
6. Alternate buffer register "#
7. The expression register "=
8. The selection and drop registers "*, "+ and "~
9. The black hole register "_
10. Last search pattern register "/

匿名寄存器

当使用d，c，s，x，y等操作时，内容会存储在匿名寄存器""中，如果操作指定寄存器"add，除了"a寄存器，内容也会存入匿名寄存器中。p(aste)默认使用匿名寄存器。

数字寄存器

“0至”9，其中”0会保留最近一次复制的内容，而”1至 “9则会保存最近9次删除操作的内容。当指定拷贝操作的寄存器时，不会写入”0中，但删除操作一定会写入”1中。使用y(ank)命令未指定寄存器时，会将内容保存至”0寄存器，同时””具有相同的内容。

短删除寄存器

顾名思义，对于少于一行的内容操作，除非指定寄存器，否则内容都会被存入 "- 寄存器中。

具名寄存器

通过26个英文字母，指定寄存器，例如”add ，如果原有”a寄存器中含有内容，则会被覆盖，而执行”Add则会在原有内容后追加内容。

只读寄存器

":, "., "%，这三种寄存器读取内容，其中": 表示上次执行的命令行，"% 表示当前编辑文件名，". 表示最近插入的内容。

交替文件寄存器

一般我们会使用ctrl-^来回切换buffer，其中原理则是在"#寄存器中存放交替文件。

表达式寄存器

normal模式下，输入"=，在命令行中输入任何Vim script的表达式，通过使用p(aste)，插入表达式结果。

选择拖入寄存器

"* 与 "+ 寄存器, 对于maxOS与windows系统都可以表示为系统粘贴板，而在linux中，会有两种不同的意义，使用"+yy，则可以将vim中的文本，粘贴至其他程序，其他程序复制的内容，也会同步到该寄存器中。而当有文本被拖入Vim中时，文本将会存储在"~寄存器中

黑洞寄存器

"_ 对于所有删除或拷贝到该寄存器的内容，都会消失，从而不会影响其他寄存器；例如删除操作，会影响其他数字寄存器，导致原”9寄存器内容被覆盖，而复制操作，则会改变”0寄存器。

搜索寄存器

normal模式下，通过/{something}搜索，最近一次的关键词会被存放在"/寄存器中。

小结

通过简单了解vim中所有类型的寄存器，大致能解答文章开头的两个问题，也可以实现更多的骚操作。

Vim编辑的内容如何复制到其他地方？

通过”+ 或 “* 寄存器，使用系统粘贴板，当然也可以通过设置

1
set clipboard=unnamed

Vim中如何复制一段内容后，多次复用，而不会被替换内容覆盖？

前文讲到数字寄存器，复制操作时，会保存内容至匿名寄存器以及”0寄存器，而在每次删除操作时，会更新”1-“9寄存器以及匿名寄存器，而p(aste)时，会使用匿名寄存器，所以如果p(aste)操作时，如果有替换内容，匿名寄存器内容会变为替换的内容，不过”0寄存器还是最近一次y(arn)的内容，所以可以使用"0p。或者设置一个map

1
xnoremap p "0p

不过这样会导致 d(elete)操作的内容无法被p(aste)使用，所以只需要使用p(aste)时，替换内容不覆盖匿名寄存器即可。前文有讲到黑洞寄存器"_，不保留不需要的内容，所以我们只需要魔改p(aste)操作，将替换内容删除至黑洞寄存器中，再粘贴内容即可。map如下：

1
xnoremap p "_dP  # 这里因为先删除，所以需要使用大写P

参考

http://einverne.github.io/post/2017/11/vim-registers.html

vim :help registers

]]> <p>刚接触vim时，相信多多少少都会遇到关于复制粘贴的问题，例如以下两个问题</p> <ol> <li>Vim编辑的内容如何复制到其他地方？</li> <li>Vim中如何复制(y)一段内容后，多次复用，而不会被替换内容覆盖？</li> </ol> <p>其实这些问题都可能跟V 记一次优化Vim启动速度 https://www.wzmmmmj.com/2020/03/28/vim-startuptime-optimize/ 2020-03-28T23:55:57.000Z 2022-04-05T08:05:52.188Z 最近宅家捣鼓了一段时间Vim，原打算试试Vim作为开发IDE，随着Vim Plugin增多，基本有个IDE的雏形，开发体验上有所改善，但也导致一个问题，启动Vim时变慢了，所以又花了点时间捣鼓优化。（PS：用什么Vim当IDE，Pycharm不香吗?）

startuptime

在Vim7.2版本后自带了startuptime参数，可以输出Vim启动过程中的耗时

1
2
3
4
5
6
7
--startuptime {fname}                                   --startuptime
      During startup write timing messages to the file {fname}.
      This can be used to find out where time is spent while loading
      your .vimrc, plugins and opening the first file.
      When {fname} already exists new messages are appended.
      {only available when compiled with the +startuptime
      feature}

例如：

1
2
vim --startuptime time.log
vim --startuptime time.log ~/.vimrc

这里先上一组优化前的启动耗时

  • 空白文件
1
2
3
221.131  000.229  000.229: sourcing /Users/a1/.vim/plugged/vim-airline/autoload/airline/extensions/tabline/builder.vim
244.400  025.347: first screen update
244.402  000.002: --- VIM STARTED ---
  • 某千行python文件
1
2
3
375.848  000.497  000.497: sourcing /Users/a1/.vim/plugged/vim-gitgutter/autoload/gitgutter/hunk.vim
378.849  085.163: first screen update
378.863  000.014: --- VIM STARTED ---

此方法能粗略看出哪些操作启动耗时长，只能说够用。以下介绍两种更直观的启动耗时插件，便于优化。

startuptime.vim

1
Plug 'tweekmonster/startuptime.vim'

startuptime.vim会对当前文件多次启动，标记启动最慢的一些插件以及输出每个步骤的耗时，安装插件后，通过使用:StartupTime，输出startup-log，如图：

startuptime.vim

vim-startuptime

1
Plug 'dstein64/vim-startuptime'

vim-startuptime会返回启动时各个操作之间耗时以及百分比，同样使用:StartupTime，输出如图：

vim-startuptime

发现问题

不难看出，拖慢startuptime的几处地方

  1. 一些插件，例如nerdtree，vim-airline

  2. filetype不对的插件没必要加载，例如打开python文件，显然没必要加载vim-go

  3. 一些多余的autocommand

优化方案

懒加载

本人配置在vim启动后，nerdtree是处于未展开状态，显然启动时没必要加载，在需要使用加载即可，类似的，当filetype不同时，有些插件也没必要加载。

使用vim-plug的同学，一定熟悉一些plug option，像branch、do，其中有两种参数可实现lazy load。

1
2
onOn-demand loading: Commands or <Plug>-mappings
forOn-demand loading: File types

另一种插件管理 dein.vim 也可以实现lazy load

下面改写vimrc，对于命令触发的插件添加on参数，而对于fileType触发的则添加for参数。

1
2
Plug 'scrooloose/nerdtree', { 'on': 'NERDTreeToggle' }
Plug 'fatih/vim-go', { 'do': ':GoUpdateBinaries', 'for': 'go' }

改动后，startuptime.vim显示如下:

1
2
3
4
5
6
7
8
Total Time:   62.441 -- Flawless Victory

Slowest 10 plugins (out of 25)~
  vim-airline12.314
    [runtime]12.211
    [unknown]10.636
     coc.nvim6.997
     ...

执行vim --startuptime time.log a.py

1
2
323.386  051.707: first screen update
323.399  000.013: --- VIM STARTED ---

nerdtree通过系统调用获取文件树，类似的还有statusline中获取分支名，这类系统调用的方式都是拖慢启动速度

替换插件

众所周知，vim-airline是statusline界的集大成者，兼容了许多常用插件，但同时也导致加载vim-airline时，加载不必要的内容，虽然vim-airline performance 讲解了如何优化，不过我选择用更轻量的lightline.vim替换vim-airline。

1
2
3
4
" Plug 'vim-airline/vim-airline'
" Plug 'vim-airline/vim-airline-themes'
Plug 'itchyny/lightline.vim'
Plug 'mengelbrecht/lightline-bufferline'

如图为使用lightline.vim的statusline，以及配置对比

lightline.vim

再次使用startuptime.vim 以及vim --startuptime time.log a.py，输出如下

1
2
3
4
5
6
7
8
9
10
11
Total Time:   55.207 -- Flawless Victory

Slowest 10 plugins (out of 26)~
    [runtime]12.493
    [unknown]11.405
     coc.nvim7.082
      darcula4.432
          ale3.546
vim-gitgutter3.060
lightline.vim2.748
     ...
1
2
204.982  025.837: first screen update
204.984  000.002: --- VIM STARTED ---

启动新文件

1
2
121.816  015.576: first screen update
121.818  000.002: --- VIM STARTED ---

Over

至此，经过几个步骤之后，启动时间减少了越一半，200ms也还过得去，毕竟不是每次都打开千行的文件。另外对于现如今还不支持异步或者更新不积极的插件，如果有合适的替代品也可以替换，例如fzf.vim或Leaderf替换CtrlP，vista替换tagbar。定期更新vimrc，删除不需要的配置以及插件，有可能会有意外的惊喜哦。

]]> <p>最近宅家捣鼓了一段时间Vim，原打算试试Vim作为开发IDE，随着Vim Plugin增多，基本有个IDE的雏形，开发体验上有所改善，但也导致一个问题，启动Vim时变慢了，所以又花了点时间捣鼓优化。（PS：用什么Vim当IDE，Pycharm不香吗?）</p> <h2 id Vim中的Buffers, Windows, Tabs https://www.wzmmmmj.com/2020/01/31/windows-buffers-tabs-in-vim/ 2020-01-31T19:50:06.000Z 2022-04-05T08:05:52.189Z Vim中的buffer，tab和window是容易混淆的概念，vim中输入:help window，会对三个概念进行简短解释:

Summary:
A buffer is the in-memory text of a file.
A window is a viewport on a buffer.
A tab page is a collection of windows.

对于常用IDE的同学，如果把这几个概念带入IDE中，常会摸不着头脑 比如我。对照下图，应该更容易理解
Tabs Windows Buffers

Buffers

A buffer is the in-memory text of a file.

Buffer即加载在内存中内容，常为一个文件，并且一个文件只会存在一个buffer。通过vim a.txt b.txt会打开两个文件buffer，同时会在编辑a.txt，接着执行:edit c.txt，窗口会显示c.txt文件，通过 :ls 可以显示所有buffer，这里会显示三行记录。

1
2
3
4
:ls
  1 #h   "a.txt"                        line 1
  2      "b.txt"                        line 0
  3 %a   "c.txt"                        line 1

可以看到a.txt，c.txt前面会有标识，相关标识含义如下：

1
2
3
4
5
6
7
– （非活动的缓冲区）
a （当前被激活缓冲区）
h （隐藏的缓冲区）
% （当前的缓冲区）
# （交换缓冲区）
= （只读缓冲区）
+ （已经更改的缓冲区）

所以%a表示当前激活的buffer，而#h则表示上一个展示的buffer且是隐藏的。
通过:b <编号>或:b <文件全称>可切换到相应的buffer，当然也可以通过:bprev或:bnext前后切换buffer，:bdelete <编号或文件全称>删除某个buffer。如果vimrc中声明set hidden，则在文件修改后未保存可以切换至其他buffer，而如果显式声明set nohidden则需要先保存。

Tips

如果使用NERDTree时出现:bd退出vim session的时候，可以看看此issue，通过:bp<CR>bd #<CR>可以达到删除当前buffer，并回到上一个buffer的效果。

Windows

A window is a viewport on a buffer.

Window即用于展示buffer的窗口，通过该窗口才能看到buffer中的内容。 使用:split或:vsplit，可实现分屏效果，在新窗口中展示当前buffer，也可在操作后加文件，新窗口中展示新打开的buffer。也就是说，多个window可以展示相同的buffer。

Tabs

A tab page is a collection of windows.

Tab即多个window的组合，一个tab中可以展示多个window，通过:tabp/:tabn 或 gT/gt前后切换tab，以及:tabc关闭当前tab，更多操作可见:help tab-page。

使用tab的推荐做法是进行分组管理，例如无关项目或不同类型的代码(server端与client端)都可以在多个tab中管理。在buffer中提到一个文件只会存在一个buffer，所以在多个tab的相同buffer，其实他们是同一个buffer，在某一处被关闭时，其他tab中也相应的不可见。

当然，不同人对三者的看法与使用习惯是不同的，例如有些人喜欢一个tab对应一个buffer，类似IDE中的布局，也有人不使用tab，对于什么场景下使用buffer还是tab，因人而异，一句话就是怎么舒服怎么来。

参考：
buffers or tabs
using vim tabs like buffers
buffers windows tabs
vim tab madness buffers vs tabs

]]> <p>Vim中的buffer，tab和window是容易混淆的概念，vim中输入<code>:help window</code>，会对三个概念进行简短解释:</p> <blockquote> <p>Summary:<br>A buffer is the in-memory text of a file.<br>A window is a viewport on a buffer.<br>A tab page is a collection of windows.</p> </blockquote> <p>对于常用IDE的同学，如果把这几个概念带入IDE中，常会摸不着头脑 <del>比如我</del>。对照下图，应该更容易理解<br><img src="/images/vim-tabs-windows-buffers.jpg" alt="Tabs Windows Buffers"></p> Django Model中的ManyToManyField https://www.wzmmmmj.com/2019/12/14/Django-Model-ManyToManyField/ 2019-12-14T21:35:11.000Z 2022-04-05T08:05:52.179Z 日常开发中，设计表结构经常会遇到多对多关系，都会立刻想到ManyToManyField，例如用户收藏门店，用户可以收藏多个门店，门店也可以被多个用户收藏，这个场景就很适合使用ManyToManyField。Model如下：

1
2
3
4
5
6
7
8
from django.db import models

class Account(models.Model):
    name = models.CharField(max_length=20, help_text="用户名")
   
class Shop(models.Model):
    name = models.CharField(max_length=20, help_text="门店名")
    collectors = models.ManyToManyField(Account, help_text="收藏用户")

依次完成makemigration跟migrate后，创建几条记录

1
2
3
4
kfc = Shop.objects.create(name="kfc")
alice = Account.objects.create(name="alice")
kfc.collectors.add(alice)
kfc.collectors.create(name="bob")

通过bob.shops.all()或kfc.accounts.all()即可获取bob收藏的门店和收藏kfc的所有用户。但如果添加数据时，使用以下步骤，则会抛错ValueError

1
2
3
4
5
6
7
carol = Account(name="carol")
kfc.collectors.add(carol)
# ValueError: Cannot add "<Account: Account object (None)>"
# : instance is on database "default", value is on database "None"

burger_king = Shops(name="burger king")
burger_king.collectos.add(alice)  # ValueError

此时查看数据库tables，不难发现，Django通过ManyToManyField生成了一张中间表名为*_shop_collectors的中间表。上面操作报错也就不难理解，因为当前carol和burger_king还未存在db中。

“through” model

如果需求变更，还需要记录用户收藏门店的时间，只使用默认的ManyToManyField显然是不够的。ManyToManyField提供了“through”字段，支持自定义中间表

  1. 将默认中间表写成Django Model
1
2
3
4
5
6
7
8
9
class Shop(models.Model):
    name = models.CharField(max_length=20, help_text="门店名")
    collectors = models.ManyToManyField(Account, through="ShopCollector")
    
class ShopCollector(models.Model):
    class Meta:
        db_table = "<table_name>"
    account = models.ForeignKey(Account, on_delete=models.CASCADE)
    shop = models.ForeignKey(Shop, on_delete=models.CASCADE)

中间表未生成，可以跳过第二步，如果需要在原有中间表上修改，db_table需要是原表名

  1. 执行makemigration，修改生成的mi文件
1
2
3
4
state_operations = [...]  # 原operations改为state_operations
operations = [
    migrations.SeparateDatabaseAndState(state_operations=state_operations)
]
  1. 加上collect_at字段，依次执行makemigrations，migrate
1
2
3
4
5
6
class ShopCollector(models.Model):
    class Meta:
        db_table = "<table_name>"
    account = models.ForeignKey(Account, on_delete=models.CASCADE)
    shop = models.ForeignKey(Shop, on_delete=models.CASCADE)
    collect_at = models.DateTimeField(auto_now_add=True)
  1. 依次执行makemigrations，migrate

几步操作完后，新建collector时，都会附带收藏时间

through_field

ManyToManyField生成的中间表只会有两个外键，从而Django可知哪两个model存在多对多关系，但使用自定义中间表时，新增了外键，如下存在两个除Shop表的两个外键：

1
2
3
4
5
6
7
8
9
class ShopCollector(models.Model):
    shop = models.ForeignKey(Shop, on_delete=models.CASADE)
    account = models.ForeignKey(Account, on_delete=models.CASCADE)
    inviter = models.ForeignKey(
        Account, 
        related_name="invite_collectors",
        on_delete=models.CASADE,
    )
    collect_at = models.DateTimeField(auto_now_add=True)

这种情况需要通过设置through_field为两个参数组成的元祖(field1, field2)，并且第一个元素需要是定义ManyToManyField表的外键字段名，声明多对多关系的两个外键，这个例子需要将collectors改为

1
2
3
4
5
collectors = models.ManyToManyField(
    Account, 
    through="ShopCollector", 
    through_fields=("shop", "account"),
)

对于自关联的自定义中间表，最好也通过through_fields显示声明

symmetrical

当使用自关联的多对多关系时，如下

1
2
3
class Account(models.Model):
    name = models.CharField(max_length=20, help_text="用户名")
    followers = ManyToManyField("self", related_name="followees")

此时所有Account的followers都是对称效果，也就是bob是alice的朋友，那alice也是bob的朋友，而且此时reverse relationship无效，不过可以通过设置symmetrical=False取消，使用reverse relatationship，例如这里的followers和followees。

]]> <p>日常开发中，设计表结构经常会遇到多对多关系，都会立刻想到<code>ManyToManyField</code>，例如用户收藏门店，用户可以收藏多个门店，门店也可以被多个用户收藏，这个场景就很适合使用<code>ManyToManyField</code>。Model如下：</p> <figure class="highlight python"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br></pre></td><td class="code"><pre><span class="line"><span class="keyword">from</span> django.db <span class="keyword">import</span> models</span><br><span class="line"></span><br><span class="line"><span class="class"><span class="keyword">class</span> <span class="title">Account</span><span class="params">(models.Model)</span>:</span></span><br><span class="line"> name = models.CharField(max_length=<span class="number">20</span>, help_text=<span class="string">"用户名"</span>)</span><br><span class="line"> </span><br><span class="line"><span class="class"><span class="keyword">class</span> <span class="title">Shop</span><span class="params">(models.Model)</span>:</span></span><br><span class="line"> name = models.CharField(max_length=<span class="number">20</span>, help_text=<span class="string">"门店名"</span>)</span><br><span class="line"> collectors = models.ManyToManyField(Account, help_text=<span class="string">"收藏用户"</span>)</span><br></pre></td></tr></table></figure> 为什么Django prefetch_related不起作用 https://www.wzmmmmj.com/2019/11/24/why-prefetch-related-dont-worked/ 2019-11-24T16:53:25.000Z 2022-04-05T08:05:52.189Z 最近划水刷V站的时候，刷到一个关于prefetch_related的问题，简答了一下，虽然过程有点戏剧，不过让我重新看了一遍官方文档，对prefetch_related也有了新的认识。对于刚接触prefetch_related，如果不了解其工作原理，相信都会遇到标题所示的问题。
为什么我用了prefetch_related查询次数没减少，反而还多了？

其实答案就在官方文档中

Remember that, as always with QuerySets, any subsequent chained methods which imply a different database query will ignore previously cached results, and retrieve data using a fresh database query

举个官方例子

1
2
3
4
5
6
7
8
9
10
from django.db import models


class Topping(models.Model):
    name = models.CharField(max_length=30)

    
class Pizza(models.Model):
    name = models.CharField(max_length=50)
    toppings = models.ManyToManyField(Topping)

如果需要查询每个Pizza下的所有Toppings，如下

1
pizzas = Pizza.objects.prefetch_related("toppings").all()

实际上这条语句除了执行 SELECT "pizza"."id", "pizza"."name" FROM "pizza"
因为加了prefetch_relate语句还会另外执行一条sql，通过in语句，将符合条件的pizza中所有toppings加载至内存中

1
2
3
4
5
6
7
SELECT
  ("pizza_toppings"."pizza_id") AS "_prefetch_related_val_pizza_id", 
  "topping"."id", "topping"."name" 
FROM "topping" 
INNER JOIN "pizza_toppings" 
ON ("topping"."id" = "pizza_toppings"."topping_id") 
WHERE "pizza_toppings"."pizza_id" IN (1, 2, 3)

所以通过执行类似pizza.toppings.all()的语句，实际上就会从缓存中读取，而不会产生sql，从而达到查询优化。但有时候总会有一些奇奇怪怪的需求。如果只想把topping.name=’top’的读取出来，如果我们使用了这样的语句pizza.toppings.filter(name='top')，就会与上诉缓存不一致，从而再次执行一条sql，不但没有产生任何优化，反而因为用了prefetch_related，还多了一次查询。

除了filter()，order_by()，first() 也会因为查询不一致，用不上缓存，而count()则不会。如果不确定是否一致，可以输出语句执行sql瞅一瞅。如果使用类似pizza.toppings.add()等alter语句会使prefetch_related缓存被清除，从而导致查询优化失效，这种情况可以通过改变代码逻辑。

遇到这种情况，可以选择在内存中进行后续操作

1
2
3
4
5
6
7
8
9
10
11
12
# filter
toppings = [
    topping
    for topping in pizza.toppings.all()
    if topping.name == 'top'
]

# first
topping = pizza.topping[0]

# order_by
toppings = sorted(pizza.toppings.all(), key=lambda _: _.id, reversed=True)

当然还可以通过自定义prefetch_related生成的sql，缓存需要的queryset

1
2
3
4
from django.db.models import Prefetch

filters = Topping.objects.filter(name='top')
pizzas = Pizza.objects.prefetch_related(Prefetch("toppings", queryset=filters))

如果想对同一个外键进行不用的filter，还可以使用参数to_attr命名

1
2
3
4
5
6
filters = Topping.objects.filter(name='top')
order = Topping.objects.order_by('-id')
pizzas = Pizza.objects.prefetch_related(
    Prefetch("toppings", queryset=filters, to_attr='filter_toppings'),
    Prefetch("toppings", queryset=order, to_attr='order_toppings'),
)

这样通过pizzas.order_toppings.all()或pizzas.filter_toppings.all()使用即可

]]> <p>最近划水刷V站的时候，刷到<a href="https://www.v2ex.com/t/618531" target="_blank" rel="noopener">一个关于prefetch_related的问题</a>，简答了一下，虽然过程有点戏剧，不过让我重新看了一遍<a href="https://docs.djangoproject.com/en/2.2/ref/models/querysets/#prefetch-related" target="_blank" rel="noopener">官方文档</a>，对prefetch_related也有了新的认识。对于刚接触prefetch_related，如果不了解其工作原理，相信都会遇到标题所示的问题。<br><strong>为什么我用了prefetch_related查询次数没减少，反而还多了？</strong></p> <p>其实答案就在官方文档中</p> <blockquote> <p>Remember that, as always with QuerySets, any subsequent chained methods which imply a different database query will ignore previously cached results, and retrieve data using a fresh database query</p> </blockquote> 不同目录配置不同git config https://www.wzmmmmj.com/2019/09/22/git-config-include/ 2019-09-22T16:44:52.000Z 2022-04-05T08:05:52.183Z 日常使用git时，一般会有全局配置文件的.gitconfig，所有repo会默认使用这个配置。如果需要特殊配置某个repo，只需要修改repo里的.git/config文件即可。但如果需要修改repo数量变多就容易忘，导致提交错误author的commit。

Demo

例如，公司repo与个人repo，想使用不同的user.name与user.email，简单操作就是，修改个人repo中.git/config中的配置

1
2
3
[user]
    name = name1
    email = name1@example.com

或执行以下语句，修改配置（两种方法本质上是一样的）

1
2
git config user.name name1
git config user.email name1@example.com

这样就会覆盖全局配置，但repo一多，这种方法就显得效率很低。

Solution

个人会用不同的文件夹区分公司与个人的repo，这样就可以通过git conditional include，给不同目录下的repo，设置不同的git config。假设公司repo，会放在work目录下。

新建一个.gitconfig-work，内容如下

1
2
3
[user]
    name = name2
    email = name2@example.com

打开全局配置.gitconfig文件，添加目录配置

1
2
[includeIf "gitdir:~/work/"]
    path = .gitconfig-work

这样work下的新repo，都会使用.gitconfig-work中的配置覆盖全局配置，从而达到不同目录使用不同的git config

Tip

对于work目录下已存在的repo，可执行以下命令查看.gitconfig-work中配置是否生效

1
2
git config --show-origin --get user.name
git config --show-origin --get xxxx

参考

https://git-scm.com/docs/git-config#_conditional_includes

https://stackoverflow.com/questions/43919191/git-2-13-conditional-config-on-windows

]]> <p>日常使用git时，一般会有全局配置文件的<code>.gitconfig</code>，所有repo会默认使用这个配置。如果需要特殊配置某个repo，只需要修改repo里的<code>.git/config</code>文件即可。但如果需要修改repo数量变多就容易忘，导致提交错误author的commit。</p> <h3 id="Demo"><a href="#Demo" class="headerlink" title="Demo"></a>Demo</h3><p>例如，公司repo与个人repo，想使用不同的<code>user.name</code>与<code>user.email</code>，简单操作就是，修改个人repo中<code>.git/config</code>中的配置</p> <figure class="highlight shell"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br></pre></td><td class="code"><pre><span class="line">[user]</span><br><span class="line"> name = name1</span><br><span class="line"> email = name1@example.com</span><br></pre></td></tr></table></figure> <p>或执行以下语句，修改配置（两种方法本质上是一样的）</p> <figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br></pre></td><td class="code"><pre><span class="line">git config user.name name1</span><br><span class="line">git config user.email name1@example.com</span><br></pre></td></tr></table></figure> <p>这样就会覆盖全局配置，但repo一多，这种方法就显得效率很低。</p>