id
1. etcd 为什么要使用etcd，主要是要考虑到workid需要抢占锁 https://yuerblog.cc/2017/12/12/etcd-v3-sdk-usage/ 分布式锁 https://blog.csdn.net/cadem/article/details/56495834 https://www.jianshu.com/p/d3068d0ac7c1 https://github.com/etcd-io/etcd/blob/master/clientv3/concurrency/mutex.go#L26 github.com\coreos\etcd\clientv3\lease.go recvKeepAliveLoop
背景 团队所做的微服务，统一签名校验是在openrestry(nginx)的lua脚本计算的 突然有人报告了一个bug，当post请求body大于10k的时候，签名就会失效 原因 在读取body参数时候，使用ngx.req.get_body_data This function returns nil if 1. the request body has not been read, 2. the request body has been read into disk temporary files, 3. or the request body has zero size. 很明显是命中了第二条，body太大，会被存储到临时文件，
go
分布式Id snowflake 是一种分布式id唯一算法，相比较uuid算法生成方式，snowflake生成的是一个int64大整型，并且是大致递增 我发现网上对于该算法的描述，在位数偏移上是由差异的，但是整体思路是一致的 这里的10-bit workerId在有的源码里面是分成两个 workerId 、data的5-bit大小 可以大致算一下，1毫秒1单点能生成2 ^ 12 = 4096个id，总共能部署 2 ^ 10 = 1024 个节点，也就是1毫秒最大能生成400多万个id 我按照算法思路写了如下代码 package main import ( "errors" "fmt" "sync" "time" ) var ( // 1288834974657 是 (Thu, 04 Nov 2010 01:42:
go
dlv 针对go语言的调试器，内部架构介绍 --headless package main import ( "fmt" ) func main() { m := 120 fmt.Printf("Hello world\n") fmt.Printf("m = %d\n", m) } 终端1 dlv debug --headless --api-version=2 --log --listen=127.0.0.1:8181 tmp.go client 1 直接使用官方提供的dlv作为客户端连接 dlv connect
nil
空指针和空接口不等价 package main import ( "fmt" ) type MyError struct{} func (p *MyError) Error() string { return "test error" } func returnsError() error { var p *MyError = nil return p } func main() { e := returnsError() if e != nil { fmt.Printf("%s\n", e.Error()) } else { fmt.Printf("no nil
mysql
现象 某服务A从晚上6点开始，监控一直出现mysql调用延迟超高，http接口500飙升 原因 经查发现是一条全局update整张表的sql引起的，全局lock表 最小化 使用下面操作进行最小化 建库 create databses test; 建表 CREATE TABLE `Record` ( `id` BIGINT NOT NULL, `count` BIGINT NOT NULL, PRIMARY KEY(`id`) ) ENGINE = InnoDB； 插入一条数据 CREATE TABLE `Record` ( `id` BIGINT NOT NULL, `count` BIGINT NOT NULL, PRIMARY KEY(`id`) ) ENGINE = InnoDB； 代码如下： package main
锁
难点 个人感觉信号量主要难在应用场景上； 同等对比，互斥量主要用来上锁，条件变量来优化多任务等待 其中互斥量正常场景下，都应该（最好都是遵从这样方式）保持上锁、解锁是同一个task； 在《评论迁移》里面，分布式锁redis的set NX 过程中，参数是key、requireId、expiration，其中requireId（多task环境下唯一ID）就是为了保证上锁、解锁是同一个task 综合来看，好像不需要信号量这类东西的存在 《UNIX 网络编程 卷2:进程间通信》 一书上讲了互斥量、信号量、条件变量的区别 （1）互斥锁必须总是由给它上锁的的线程（任务）解锁，信号量的挂出却不必由执行过它的等待操作的同一线程执行。（这是个特性，实际测试中go语言中的互斥量其实是可以的）。 （2）互斥锁要么被锁住，要么被解开（二值状态，类似于二值信号量）。 （3）既然信号量有一个与之关联的状态（它的计数值），那么信号量挂出操作总是被记住。然后 PV操作
faas
函数即服务（faas），现在挺火的一个概念，不同于Iaas、Paas、Saas，颗粒度更细致； 看一下github.com一个开源的openfaas； minikube 按照官方推荐的教程流程，首先使用minikube启动单点的k8s **1.**注意minikube启动的时候，会有一下几种情况： $ minikube start --vm-driver=virtualbox Starting local Kubernetes v1.10.0 cluster... Starting VM... E0808 02:43:48.772569 32480 start.go:174] Error starting host: Error creating host: Error executing step: Running precreate checks.
vim
2018.09.04 set nocompatible filetype off set rtp+=~/.vim/bundle/Vundle.vim call vundle#begin() Plugin 'VundleVim/Vundle.vim' Plugin 'vim-airline/vim-airline' Plugin 'vim-airline/vim-airline-themes' Plugin 'Shougo/echodoc.vim' Plugin 'fatih/vim-go', {'
锁
条件变量 互斥器用于互斥，条件变量用于等待 如果上例子中消费者和生产者同时并发，那么需要消费者需要轮询（polling）或者轮转（spinning） 查询buf状态，看是否满足消费条件 void comsume_wait(int i) { for( ; ; ) { pthread_mutex_lock(&shared.mutex); if (i < shared.sum) { pthread_mutex_unlock(&shared.mutex); return; } pthread_mutex_unlock(&shared.mutex); } } void *comsume(void *arg) { (void) arg; for (int i = 0;
互斥量
锁 我们语境下的锁是一种同步机制，用于计算机在多任务环境下访问公共资源达到互斥作用。 临界资源 临界资源（Critical Resource）是一次仅允许一个进程（任务）使用的共享资源 临界区 每个进程（任务）中访问临界资源的代码块。每次只允许一个进程进入临界区（Critical Section） 互斥量 互斥量（mutex），用于保护临界区的。下面举个例子，三个task，其中两个生产者，一个消费者 以下代码有如下假定： 1. 生产者在shared.buf[i]生成出数据 i 2. 生产者竞争（race）生产，直到所有buf区域都有数据，并此时停止生成 3. 消费者在整个buf全有数据后才开始消费 #include <stdio.h> #include <pthread.h>
js
1. 问题 前几日，我在测试express框架的时候，构造了一个测试样例死活过不来，即便调试到测试框架superagent ，依然不对。最终发现是nodejs的bug，而且最新版本的nodejs已经"修复"了，导致我中间饶了几圈都没发现是nodejs的事，下面来重现问题流程。 2. 环境预备 1. 安装一下gnvm 地址，后面需要控制一下版本（windows10 需要用管理员权限的cmd或者powershell） 2. 安装git环境（主要要使用curl命令） 3. 摘抄如下代码 // main.js var http = require('http') var tmpObject = Object tmpObject.prototype['love'] = 'express' var server = http.