x86 calling convention，简单概括一下，其实就是语言对于函数之间传参的一种约定。调用方要知道我要把参数按照什么形式，什么顺序传给被调用函数，被调用函数也遵守该规范去相应的位置找到传入的参数内容。

从 Go 1.14 开始，通过使用信号，Go 语言实现了调度和 GC 过程中的真“抢占“。抢占流程由抢占的发起方向被抢占线程发送 SIGURG 信号。当被抢占线程收到信号后，进入 SIGURG 的处理流程，将 asyncPreempt 的调用强制插入到用户当前执行的代码位置。本节会对该过程进行...

这次去 Gopher China 和不少老朋友见了个面，还有不少在微信上认识已久，一直没见过面的网友。同时也和各个公司的一线开发们聊了聊，互相交流了彼此使用 Go 时的一些心得和痛点。

有一个观点已经被说烂了：使用 MQ 可以帮助业务系统解耦。想法很简单，在业务状态流转时，如果没有 MQ，那么其它系统想要知道状态变了，那就需要核心流程系统去主动做通知。比如电商系统里订单从创建到处理中状态切换了，客服系统需要知道，风控系统需要知道，用户系...

要知道怎么解决长尾问题，先要理解长尾延迟是个什么问题，在开发在线服务的时候，我们都知道要关注服务的 p99/p999 延迟，要让大部分用户都能够在预期的时间范围内获得响应。

在架构师们很喜欢的 Domain Driven Design，即 DDD 中，第一课就是教导团队形成自己独有的通用语言(Ubiquitous Language)，作为业务概念沉淀下来。

众所周知，Go 使用了 Unix 老古董(误 们发明的 plan9 汇编。就算你对 x86 汇编有所了解，在 plan9 里还是有些许区别。说不定你在看代码的时候，偶然发现代码里的 SP 看起来是 SP，但它实际上不是 SP 的时候就抓狂了哈哈哈。

别觉得 CRUD 只是业务工程师的问题，无论你在写什么程序，基本上都是在和数据打交道，除了读就是写。只不过读写的时候还会附带一些领域相关的行为。比如：

根据请求来返回对应的access-control-allow-origin就好了请求的应该从referer里拿得到

竟然和es.cn上是一样的内容。。。。那我也粘过来好了 有几种方法，看着选吧：1.在业务系统里做双写 2.用elasticsearch-jdbc之类的工具来做全量和增量同步 3.用阿里的canal来做数据库binlog->kafka->es的同步，需要开发，而且依赖比较多，小公司选择还是慎重些吧

2.在调用bulk前，修改index.refresh_interval为-1，刷新是成本比较高的操作，如果不改的话，可能在你插入的时候索引刷新会降低插入效率，调用完了记得再改回去

hq [链接]

golang用的是多线程编程里的csp模型并且在程序的runtime级别实现了coroutine的调度，让一个水平不高的程序员也能在短时间内写出相对高性能的程序虽然褒贬不一，但贵在取得了开发难度和性能上的平衡，屏蔽了底层的系统相关的实现细节，让程序员“尽量”只关注于业务

origin [链接] 改成https或者ssh地址

楼上说是比较笨的方法。。实际上这也就是用redis做类似工作需要用的方法。。。 建议LZ去看一下redis in action 里面会有一些这种常见的开发实例在用redis时如何设计