背景 最近有很多事情变化太快，对于局势的不解，反而让我有更多的时间反思了. 前提 首先个人不是神，不可能想全所有的细节进行推演. 局势上宏观任何的变动对于微观上都可能是致命的，甚至无法预料. 而恰恰宏观势的观察异常困难，尤其是面临各种信息差的时候. 核心竞争力 个人反思一下，对于任何一家企业招人，它愿意招你的根本条件是什么？（这里排除极个别异常的情况） 是你能给这家公司带来利益，那么利益是经由你怎么产生的，这个就是你在这家公司的价值 对于个人（普通员工）直接带来利益的手段，就是解决问题 如何花费最小的代价解决不同层面的问题决定了你在这家公司的职级 这里扔去网上那些对于核心竞争力这个词的定义，思考一下同样情况下竞争力 »
调试器 如果把调试器看成一个产品的时候，首先他应该具体的功能有哪些？ 1. 断点 2. 代码与当前断点映射（例如查看源码） 3. 断点过后继续运行（继续执行，单步，单出） 4. 打印变量 附属的功能： 1. 打印调用栈 2. 打印堆栈 3. 函数调用 4. 条件断点 5. 反汇编 »
粗读一遍，细读一遍总结 文章最后几节看了，但是我并没有画到导图中，我觉得可能目前对我用处不大 相对而言，本篇看起来更像是自我总结。 我更喜欢《幕后产品 打造突破式产品思维》这种由己及外的方式。 xmind下载 »
背景 以前很少按年跨度来做总结（除了工作上），对于我而言总觉得年的跨度太长了 下面三张脑图的一些点是这两年陆陆续续补上去的 （svg矢量图可以右键在另一个tab里面打开，看起来比较清晰） 架构 这张图的第一版本是2年前我维护nodejs api 网关写的（表达的认知可能还是比较肤浅）以及后续在后端团队里面的补充 最核心的还是对于网关的认知，项目本身它承载着比较重要而且前沿的思想理论 （但是目前感觉这个项目没有充分完成它的使命，辜负了它的创始人） 分布式事务 18~19年在维护旧系统里面，遇到最恶心的问题之一：微服务之间数据不一致 尝试了一些解决方案，最后还是比较倾向柔性事务这个概念 （还有一些图，因为涉及了比较敏感数据， »
意义 搜了一下好像并没有文章讲这件事，网上的tcp迁移貌似讲的都是网关，跟upstream直连偷偷换连接（偷改四元组，类似负载均衡）;；不过我说的可能跟其他人看到标题时候想的也不一样，实际主要说的是热更新tcp长链不断。 mosn 主要也是看了mosn（蚂蚁版本envoy）源码，这块挺有意思的。 实际上我也没有完全看明白它的实现，里面代码封装太多层（抽象，也不好调试）。比方说，conntion迁移的时候是和reader buffer的数据一起过去了，如何避免中间时间差的read buffer；我只是翻懂了大致的思路，然后自己写出来一个（写法上有一些差异）。 热更新 »
事务 之前的b+树，并没有满足一致性的需求（或者说原子性）, 因为涉及到写操作的时候，牵扯多了多个节点变更，如果出现其中一个节点写出现问题，整体上就没有办法恢复了. 所以加了一个分支，实现了出现部分写入问题，可以进行回滚. 解决 需要解决这种问题，目前必须采用double write，就是提前讲数据落在别的地方，等出现问题的时候能够从别处恢复 整体上记住一件事，出现double write的场景都是因为写是inplace update而不是append only redo/undo 例如mysql中innodb的undo和redo »
被虐了，原来go里面的nil可以调用方法，但是成员变量会panic https://github.com/go-delve/delve/pull/1722#discussion_r336509209 package main import ( "fmt" ) type Blah struct { } func (b *Blah) Foo() { fmt.Printf("hello! »
参考内容 项目地址: bptree 代码参考：主要参考了两个版本bplustree和go的内存版本bptree 定义参考：对于b+树的定义有太多了，主要参考了b+树总结 实现细节 可以提前申请一些节点(leaf和node)结构的内存池，避免大量内存申请和释放 每个磁盘块（系统和磁盘交互的最小逻辑单位）都是一个节点所占空间大小（会有浪费），需要序列化写入文件 因为是递归操作，所以每一个函数当出现将某块磁盘节点映射成内存节点，都应该在函数结束前某个时机（可能其他调用了其他递归函数也进行了映射，造成数据覆盖）刷盘 »