package main import ( "fmt" "log" "net/http" "time" ) func handler(w http.ResponseWriter, r *http.Request) { time.Sleep(time.Millisecond * time.Duration(500)) fmt.Fprintf(w, "ok") } func main() { http.HandleFunc("/A", handler) log.Fatal(http.ListenAndServe("
消息队列
起因 公司同事发现，其topic数据均摊在k8s里面 5个 nsqd 但是其中两个nsqd对应的消费channel已经出现积压，甚至落盘过万条数据 触发条件 注意每个 consumer 与 每个 NSQD 都有连接（图中没有画出） 每个consumer的maxinflight设置都是1 使用最新的官方sdk版本go-nsq v1.0.7 参数解释 这里面有两个参数需要解释一下，但是是从consumer的角度解释的，同样的参数在nsqd中可能含义不一样 RDY是代表当前消费者还可以接受多少条消息，进行处理（在上面场景，大部分情况都是0、1） maxinflight代表是当前还未完全处理完的消息最大条数（默认是1条） 负载均衡 例如从consumer A角度来看，有这样的场景，len(A.conns) > maxinflight 也就是说，consumer A在同一时间内，不能够RDY多个nsqd，所以只能暂时选取其中一个，然后过一段时间再来处理其他的nsqd上面的消息，实际在consumer里面确实有一个定时器去做这件事 fun
lock
起因 之前遇到一些场景，使用了分布式锁，目前来做一个总结 redis 1. 单点redis 单点redis场景，主要容易存在单点故障。（分布式高可用的手段：1.单点故障转移 2.数据冗余） // 获取锁 SET key value NX PX xmilliseconds // 删除锁 if redis.call("get", KEYS[1]) == ARGS[1] then return redis.call("del", KEYS[1]) else return 0 end 设置key值，需要设置一下随机value，避免锁被其他竞争者删除 设置过期时间，避免客户端崩溃之后，
起因 今年之前我写过一次总结，关于流程规范的，而且里面提到执行最佳手段，然而短短不到半年我又需要去推翻先前的理论。（或者严格地说并不是推翻，而是做一次递进。）总体上来说，触发我这次思维跃迁的主要是某位产品运营刘的离职，让我再一次确认一个道理 —— 职场如战场。 孙子曰：兵者，国之大事也，死生之地，存亡之道，不可不察也 手段 关于我当时认为的深不可测（我认为越聪明的打工者越能感觉到恐惧感），然而这种恐惧感也是一种有效的方式。也就是说 越聪明的打工者你以为你凭借自己聪明察觉到的细致形势，也不过是管理者故意透露给你的。如果你从聪明的打工者角度出发，你会感受到安全感，这种安全感是你自己带来的。另一方面，卖破绽并不是一直有效的，如果你需要走得越高，你需要更多人的支持，所谓以人为本。情绪化表达带来的后遗症也比较多，控制性的主动权在你这，但是容易失误。也就是需要更高明的手段，但是首先第一点，得学会忍。更高明的手段，需要把情绪表达地更细微，甚至是仅仅是一个眼神。 谋势 当一些事情你推不动的时候，或者别人并不听从你的一些任务的时候，你需要谋势。 （当然，所有事情都是要建
内存
产生的困惑 mq落盘的时候，rocketmq采用mmap，但是多处mmap同一个文件，会不会导致映射多次到物理内存上？ 页是内存管理的最小单位（通常是4k） 查看程序虚拟地址 利用 man proc 可以看到命令介绍，/proc/[pid]/maps里面关于一些参数解释 /proc/[pid]/maps A file containing the currently mapped memory regions and their access permissions. See mmap(2) for some further information about memory mappings. Permission to access this file is governed by a ptrace
发现了一个种全排列的新写法，类似于洗牌 原始写法 按照我以前的写法，如下： package main import "fmt" func getPerm(ori []int, cur []int, pos int, vis []bool, resP *[][]int) { if pos == len(ori) { *resP = append(*resP, append([]int{}, cur...)) return } for i := 0; i < len(ori); i++ { if !vis[i] { vis[i] = true cur[pos]
平滑重启
源码 今天调试了一下golang编译工具，发现了一个很有"奇怪"的地方 简化问题 假设有1000个任务，1000个并发协程，设置n（cpu核数）个物理处理器（task）并发完成，每个协程只要完成了当前任务采取完成下一个 代码 原始代码，go作者无所畏惧的使用协程 func parseFiles(filenames []string) uint { var noders []*noder // Limit the number of simultaneously open files. sem := make(chan struct{}, runtime.GOMAXPROCS(0)+10) for _, filename := range filenames { go func(filename string)
go
单例 package main import ( "fmt" "math/rand" "sync" "time" ) type A struct { Item int } var a *A var l sync.RWMutex func GetGlobalA() *A { if a != nil { return a } l.Lock() if a == nil { rand.Seed(0) a = &A{Item: rand.
饮食 当地的大部分油炸（包括炒饭、炒菜）都有一种当地特色的油味道，我一般是吃不惯 当地特色餐，脏鸭餐、猪排饭 都是可以尝尝的 小费 通常房间打扫 需要放 10000 卢比（约5元人民币） 大部分本土人都比较nice（宗教信仰比较多），隔壁岛的一些人不是很友好（可能会发生排华） 出行 最好是包车，当地出租车比较贵，公交车很难排到，本土人大部分都是各家都有自己的摩托车 所以当地都是盛行摩的，没有红绿灯，没有交警，过马路需要很小心 最好不要租摩的，警察会抓罚款 不建议一人独自来度假，最好成群结伴 语言沟通 大部分本地人都会一些英文、中文，实在不行可以用google翻译 货币 稍微正规、规模稍大的超市、餐厅都是支持支付宝、微信 3%的华人占据40%的经济 可以玩的点 太多了，自己去查，大多都是景点拍照，懒得讲细节；
go
原意 对于微服务架构来说，当数据垂直拆分到各个服务之后，通常通过调用接口的方式（或者异步消息）来保证数据一致性，但是如果出现被调用服务暂时性宕机（或者非平滑发布），那么两边数据就不一致了。 ps : 我认为还有一种情况，由于互联网人员流动性比较高，许多非核心业务中转好几个产品经理手，最后在新业务与旧业务联动的时候，会有遗漏一些业务异常情况，我暂时称之为"数据联动性"，目前我除了规范业务流程，没有更好的方案；而本文所要解决的场景，称之为"分布式事务一致性" dt协议 对于A、B两个服务之间某个请求有分布式事务关联，使用如下方式，将分布式事务转化成单表事务 其中 send preapred 和 A服务的单表sql 顺序是可以随意的 实现这里需要修改一下nsq的代码，每一个client连接到nsqd都需要做一个协商（IDENTIFY）协议的版本号，通过magic字段来协商，目前nsq支持的是 V1和V2两个版本 所以我们需要添加一个文件protocol_dt.go，里面的内容主要是照搬protocol_v2.go，
流程规范 我认为流程规范是为了将不同程度技能点的人员拉到统一水平线上，以此来控制项目进度中人力工作量的风险。好处是将次等人（不针对人，只针对某方面业务能力）提升到普通水平线，坏处是限制了优等人（不针对人，只针对某方面业务能力）发挥空间。所以在一些特殊需求场景（非规范流程）下，会延申出双标。而对于双标来说，好处是极大提升了团队的工作效率，坏处是容易造成不务实之风、资源分配不均匀、关系处理不当容易造成崩盘等现象。 双标人群 如何区别心中的双标人群。我认为最直接有效的手段是，工作中初次合作，利用压迫式方式令对方产生负面情绪，直接刺探心理，重点反映出来的是心理承受能力、高压处理能力、逻辑思维能力。依据这三部分区分双标人群。 手段 那么什么是最佳手段，目前我也不清楚最佳方式是什么。很多管理者采取手段是掩藏，几乎隐藏了一切情绪。对于这些管理者，给我直观感受的是一种深不可测（我认为越聪明的打工者越能感觉到恐惧感），工作用战战兢兢、如履薄冰等词形容也不为过。你可能永远也不知道什么时候踩到TL的心理底线，所谓伴君入伴虎大概如此吧。 我认为双标方式的最高明方式并不是掩藏，而是故意卖
tracing
tracing方案 我们基本方案，是基于service mesh (envoy打脸最终并没有) 和 jaeger 来实现的 环境安装 关于jaeger的搭建，主要参考官方文档 jaeger-k8s 来的 ，其中注意关于 五个组件的区分 端口号协议组件功能 5775UDPagent通过thrift的compact协议接收zipkin.thrift数据6831UDPagent通过thrift的compact协议接收jaeger.thrift数据6832UDPagent通过thrift的二进制协议接收jaeger.thrift数据5778HTTPagent用于配置接口16686HTTPquery用于UI界面14268HTTPcollector直接接受客户端直连的jaeger.thrift14250HTTPcollector接受model.proto9411HTTPcollector兼容zipkin的http端点 其中 agent 和 collector 是放在 公用服务的k8s环境里面的（a01），而 jaeger web ui 是可以放在管理环境（a