之前有人在某群里询问 Go 的编译器是怎么识别下面的代码始终为 false，并进行优化的： package main func main() { var a = 1 if a != 1 { println("oh no") } } 先说是不是，再说为什么。先看看他的结论对不对： TEXT main.main(SB) /Users/xargin/test/com.go com.go:3

1.13 正式发布了，Release notes 上说 defer 现在大多数情况下可以提升 30% 的性能。这 30% 的性能怎么来的呢？ 我们知道，以前的 defer func 会被翻译成 deferproc 和 deferreturn 两个过程，这里 [https://github.com/cch123/golang-notes/blob/master/defer.md] 现在

虽然公司内的存储和数据系统名目繁多，但一般难以满足领域(就是 DDD 里说的那个 domain)内或子域(subdomain)内的所有需求，在业务部门内部还有着花样繁多的各种数据系统。这样的现状会导致业务接入数据服务的开发成本非常高。 这么说可能比较抽象，举个例子，如果你们公司有 LBS 相关的业务，一般一定会有一个坐标相关的服务，可以使用用户 id 获取瞬时坐标信息。也可能用一个订单或者配送 id 获得某件事情的发生轨迹。坐标轨迹相关的服务和地图类的数据强相关，所以这种服务一般是由单独的部门提供。 再比如说，公司内有公共的订单服务，但主服务不可能为各种相对独立的支撑域(supporting domain)的业务需求，无穷无尽地加字段，这种时候一般支持域会在其内部构建自己业务强相关的业务数据服务。

Week 2 的问题是 map reduce 优化，说实话，这周的示例代码写的不怎么样，不知道为什么都是同一个人的代码，同一个参数的名字还换来换去，读起来会浪费一些时间。一些缩写也让人比较困惑，比如 fs，bs，别人要稍微思考一下才能看懂这是什么东西，用 fileList 或者 bufferList 显然更好啊，可能样例代码的人是写 acm 出身，比较喜欢赶时间。虽然 Go 的 runtime 代码里也经常这么干，汗。 吐槽就到这里。题目是想让你先把

第一周是给定了函数签名实现多路归并排序。这里 [https://github.com/pingcap/talent-plan/tree/master/tidb/mergesort]。 为啥要考这个问题呢？个人认为多路归并在分布式数据库、分布式搜索引擎领域是挺常见的算法。用我相对熟悉的 es 来举例，在搜索数据时，我们会指定 bool 表达式来对数据进行筛选，同时需要指定每个查询 sort by 字段以及 size，但分布式环境下，我们没有办法确定这 size 个元素要在每个 shard 里取几个元素。所以最基本的思路：