国内环境运行openapi库

代码如下，直接运行会报错， from openai import OpenAI client = OpenAI(api_key = "") // 这里填入自己的API_KEY，在openapi官网帐号上有 # Prompt for the conversation response = client.chat.completions.create( model="gpt-3.5-turbo", messages=[ {"role": "system", "content": "You are a helpful assistant."}, {"role&

xv6系列 util实验

Sleep 没啥难度，主要调用系统调用 sleep #include "kernel/types.h" #include "kernel/stat.h" #include "user/user.h" int main(int argc, char *argv[]) { char *err1 = "not right\0"; char *err2 = "sleep wrong\0"; if (argc != 2) { write(2, err1, strlen(err1)

xv6 系列一（搭建环境）

准备 需要三个部分 1. RISC-V 工具链 2. 虚拟机 3. xv6源码 1. 工具链 RISC-V工具链 RISC-V 建议采用手动编译的方式，brew install riscv-tools相对于来说比较卡 git clone --recursive https://github.com/riscv/riscv-gnu-toolchain 代码下载时间比较久 问题： a. 如果下载sub module下载失败了，需要进入 riscv-gnu-toolchain目录下，重新执行 git submodule update --init --recursive 下载 b. 遇到错误/bin/

关于沟通

近一年，严格来说可能是11个月，我时常反思关于沟通的问题。一直到近几个月的沉默。我理解都是沟通是原罪。以下言论都是我抹去了大多性格上的短板因素，刚好也是去年这个时候开始想这个因素变量（令自己恐怖的是这个件事我竟然想了一年，老是觉得是上周的事情），这么做是为了减少计算量，我需要计算自己这点上的影响数值。 1. 首先要把自己的位置放正，其次要把态度放正。位置是要明白自己需要产生多大的影响，而且能产生多大的影响，这是一种base，目的与能力的一种权衡；其次态度可以使自己更加客观看自己，不容易受情绪影响，下的结论会更贴近真实客观。 2. 需要明白沟通是需要载体，我们将 model 简化，单对单场景，载体是人。沟通方式，无非是语言、文字、可视化资料。但是往往令人忽略的是沟通载体的差异性，也就是所谓的共识。排除掉所有性格（情绪）的外界因素，剩下影响共识的是经历和学识。或者说“共识”是 “经历和学识”的一种高度抽象，然而“经历和学识”还是太过于抽象，于是在我的认知范畴内将其转化为可计算的。难点在于如何作为简化计算公式和输

golang 神坑range

总结一下碰到的一些range问题，尤其是边loop边delete的骚操作，我一直以为是人家开源库的bug，直到我看到golang官方也这么用。 首先是比较经典的问题，我们团队之前确实有人写这样代码出事了。 v是数据复制 1. 代码本意是为了获取每个slice每个元素的指针，构造成新的slice type P struct { Name string Age int } func main() { o := []P{ P{"chain1", 20}, P{"chain2", 21}, P{"chain3", 22}, } oPointer := make([]*P, 0, 3) for _, v := range o { oPointer = append(oPointer, &v)

golang 非协作式抢占

最近因为dlv里面有个bug，关于go1.14版本之后非协作式抢占扩大了调试状态下的一些协程问题。 于是就找了原始的提议看了看，恩，果然大部分都看不懂！！！ 利用google/baidu式的翻译，手敲了一遍，并且存疑的地方都加了一点东西，算是给自己一点做个笔录吧，后面有理解更深的地方会更新一下自己的理解。 翻译笔录英文版本如链接 摘要 go 当前在编译器插入的函数序章中插入协作抢占点。在大多数情况下，这足以让golang开发人员忽略抢占细节，专注于编码清晰的并行代码，但是这种方式有着非常尖锐的问题，以至于我们一次又一次的看到它降低了开发人员的体验。当它出现错误时候，就会呈现出惊人的错误现象，导致未知的系统层面的延迟问题，甚至有时候会完全冻结（就是卡住不动的意思）。因为这个是存在于golang语言语义之外的语言实现问题，这些错误是非常令人吃惊的，并且非常难以调试。 @dr2chase已经投入了大量的精力在循环中建立协作抢占点的原型，这是解决这个问题的一种方法。然而，即使是复杂的方法也会导致在紧密循环（我理解就是死循环或者短时间无法跳出的循环）中无法接受的减速（这种

tcp 拥塞控制

2020年

背景 以前很少按年跨度来做总结（除了工作上），对于我而言总觉得年的跨度太长了 下面三张脑图的一些点是这两年陆陆续续补上去的 （svg矢量图可以右键在另一个tab里面打开，看起来比较清晰） 架构 这张图的第一版本是2年前我维护nodejs api 网关写的（表达的认知可能还是比较肤浅）以及后续在后端团队里面的补充 最核心的还是对于网关的认知，项目本身它承载着比较重要而且前沿的思想理论 （但是目前感觉这个项目没有充分完成它的使命，辜负了它的创始人） 分布式事务 18~19年在维护旧系统里面，遇到最恶心的问题之一：微服务之间数据不一致 尝试了一些解决方案，最后还是比较倾向柔性事务这个概念 （还有一些图，因为涉及了比较敏感数据，我感觉不应该放在blog上面） 技能 这个图主要是目前工作中遇到的问题，打算串起来

tcp连接迁移

意义 搜了一下好像并没有文章讲这件事，网上的tcp迁移貌似讲的都是网关，跟upstream直连偷偷换连接（偷改四元组，类似负载均衡）;；不过我说的可能跟其他人看到标题时候想的也不一样，实际主要说的是热更新tcp长链不断。 mosn 主要也是看了mosn（蚂蚁版本envoy）源码，这块挺有意思的。 实际上我也没有完全看明白它的实现，里面代码封装太多层（抽象，也不好调试）。比方说，conntion迁移的时候是和reader buffer的数据一起过去了，如何避免中间时间差的read buffer；我只是翻懂了大致的思路，然后自己写出来一个（写法上有一些差异）。 热更新 关于热更新：类似nginx或者go http服务的热更新，一般都比较熟知大致流程； 新进程继承listen port（子进程继承），并且接受新的http请求； 旧进程上面已存在的http请求正常运行至结束，旧进程在所有http请求关闭后自动退出； 所以新旧进程短时间可能会同时存在运行。 可以拿nginx和python来做个试验。 第一步：可以看到Nginx监听了80端口，没有任何连接

落盘的b+树

参考内容 项目地址: bptree 代码参考：主要参考了两个版本bplustree和go的内存版本bptree　　 定义参考：对于b+树的定义有太多了，主要参考了b+树总结 实现细节 1. 可以提前申请一些节点(leaf和node)结构的内存池，避免大量内存申请和释放 2. 每个磁盘块（系统和磁盘交互的最小逻辑单位）都是一个节点所占空间大小（会有浪费），需要序列化写入文件 3. 因为是递归操作，所以每一个函数当出现将某块磁盘节点映射成内存节点，都应该在函数结束前某个时机（可能其他调用了其他递归函数也进行了映射，造成数据覆盖）刷盘 4. 文件开始位置并不一定是根节点，因为节点会不断增加和删减，所以在读取文件时候需要check root　　 5. 还有一些事务性问题，比方当前节点已经刷盘，但是延伸更新父亲节点刷盘失败，这种情况暂时没有考虑　　 b+树优

条件断点

背景 查看到delve这条issues，对于条件断点会导致程序变慢很多 package main import ( "fmt" "time" ) func main() { sum := int64(0) start := time.Now() for value := int64(0); value < 10000; value++ { sum += value // break, cond 1 value==-1 } elapsed := time.Since(start) fmt.Printf("Sum: %d\nTook %s\n", sum, elapsed)