go源码阅读 map
序 关于map的实现，我按照我的思路来看源码，中间尝试了挺多的case，最终选了一些来作为实例 可能跟网上其他人不太一样 准备工作 首先做一些准备工作，跳过一下与编译无关的过程，例如搜索依赖关系 样例代码 新建临时目录test_map，在该目录下写入样例代码 // main.go package main import ( "fmt" ) func test_map() { s := make(map[ »
从compare_4.go初识go的typecheck
主要是上一次的题目的第四道 上次compare梳理了 go build在compile之前的准备工作，比如收集import依赖关系 针对compare_4.go进行编译，看一下一点compile的过程，参数build -x -o ./compare_4 compare_4.go package main import "fmt" func main() { a := []byte("helloworld" »
nsq 支持分布式事务（三）
主备同步 代码提交记录 完成度 只完成了主从复制；但是主备切换、依据处理能力动态调整消费能力、一些write失败逻辑处理 没有完成 基本逻辑 数据 主要分成了三部分数据的复制 发送SLAVE_SYNC_INFO命令，返回所有的topic和其对应的channel 发送SLAVE topic_name命令，携带当前topic的关键4个参数fileindex filenum totalMsgCnt viroffset和一个maxnum希望本次同步返回的消息数量，返回 master的关键参数和消息本身 发送SLAVE topic_ »
nsq 支持分布式事务（二）
核心代码逻辑 commit 修改dtpre队列 在考虑落盘之前，先思考另一个问题，由于dtpre本身跟消费者无关，只跟生产者有关，其实并不需要等到消息从topic分发到各个channel里之后再进行commit(cacel)，浪费存储空间（如果落盘就浪费了磁盘空间） 所以我们将dtpre的部分移至topic中存储 落盘逻辑 对于落盘逻辑来说，不只是dtpre的逻辑需要修改，如此对于一般的消息来说，都应该进行落盘 而channel来说只需要落盘数据索引即可 修改细节 实际这次提交修改了比较多的内容，最核心的还是移除了memoryMsgChan（无论是 topic 还是 channel），添加了backendMsgChan. »
虚拟内存地址计算物理内存地址
产生的困惑 mq落盘的时候，rocketmq采用mmap，但是多处mmap同一个文件，会不会导致映射多次到物理内存上？ 页是内存管理的最小单位（通常是4k） 查看程序虚拟地址 利用 man proc 可以看到命令介绍，/proc/[pid]/maps里面关于一些参数解释 /proc/[pid]/maps A file containing the currently mapped memory regions »
限制并发量
源码 今天调试了一下golang编译工具，发现了一个很有"奇怪"的地方 简化问题 假设有1000个任务，1000个并发协程，设置n（cpu核数）个物理处理器（task）并发完成，每个协程只要完成了当前任务采取完成下一个 代码 原始代码，go作者无所畏惧的使用协程 func parseFiles(filenames []string) uint { var noders []*noder // Limit »
原子性
单例 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 »
nsq 支持分布式事务
原意 对于微服务架构来说，当数据垂直拆分到各个服务之后，通常通过调用接口的方式（或者异步消息）来保证数据一致性，但是如果出现被调用服务暂时性宕机（或者非平滑发布），那么两边数据就不一致了。 ps : 我认为还有一种情况，由于互联网人员流动性比较高，许多非核心业务中转好几个产品经理手，最后在新业务与旧业务联动的时候，会有遗漏一些业务异常情况，我暂时称之为"数据联动性"，目前我除了规范业务流程，没有更好的方案；而本文所要解决的场景，称之为"分布式事务一致性" dt协议 对于A、B两个服务之间某个请求有分布式事务关联，使用如下方式， »