主要是分析一些比较熟悉的开源项目的github action。 etcdcodeql-analysis.yml12345678910111213141516171819202122232425262728293031323334353637383940414243name: "CodeQL"on: push: branches: [main, release-3.4,

本次打算对go的io进行一个分析。 go io首先我们来查看一下go io包下的文件树。 12345678910├── example_test.go├── export_test.go├── fs├── io.go├── io_test.go├── ioutil├── multi.go├── multi_test.go├── pipe.go└── pipe_test.go ioutil是一些工具

参考链接1对grpc有非常详细的教程，这里主要讲一些文章中没讲过的。我们主要基于文章最后提供的链接分析一下其中的代码。 我们来看看.pb.go和_grpc.pb.go文件。目前这是我们的pb文件。 12345678910111213141516171819202122232425262728syntax = "proto3"; // 版本声明，使用Protocol Buffer

1brc挑战1brc 是Gunnar Morling老哥发起的挑战，这位老哥看起来挺牛逼的。挑战的主要内容页很简单，就是对一个10亿行的文件，进行解析，求出每个城市温度的最大值，最小值和平均值。这幅图里面讲的非常清楚。接下来我将讲一讲我自己的解决思路和方案。 一些前置处理 在src/python下提供了数据产生脚本create_measurements.py <number>。 官方测

ziplist的缺点我们都知道ziplist的插入效率其实是$o(n)$的，redis的解决方案是ziplist不可太长。使用到ziplist的两个上层数据结构分别是dict和zset，其二者有配置hash-max-ziplist-entries和zset-max-ziplist-entries来限制其在底层存储是ziplist状态下的长度。同时我们在这里解释了ziplist递归更新的风险，这将短

ziplist.c的开头注释这一段注释大概解析了一下ziplist基本构成。 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778ZIPLIST OVERAL

接下来一系列的文章可能会看一看redis的源码，主要是为了学习下优秀软件的设计思路。 为什么需要SDS？C语言没有像其他语言一样的string类，有原生的字符串。C语言可以用char*存储字符串，并以"\0"结尾。但是 char*原生的增 也就是strcat在char数组长度不够的时候会溢出，即不存在拓容机制。 以 "\0"结尾所带来的后果就是字符串中间无法

本文主要分析redis存储的底层哈希表。即src/dict.c , src/dict.h 哈希的存储结构这是最底层的存储kv的结构体dictEntry，中间的union可以共享内存，也就是如果是uint64_t, int64_t, double 则是直接与key存在一起，用val存储地址。 12345678910typedef struct dictEntry { void

cs61b的一个实验是mini-git，借此看看git内部是如何存储数据的。 Git对象blob objectGit内部对象的存储是一个kv库。key为SHA-1的哈希值，value为具体文件。接下来我们通过一个小小的实验来看看。首先需要初始化一个git仓库。 1234567$ go init testInitialized empty Git repository in /demo/test/