nsq 支持分布式事务（四）
也许我就是个跑偏的人，这个系列越写越偏 基准测试 本来是跟原版里面./bench.sh做一些基准测试，在我这台垃圾电脑上面 写性能 最后发现如果没有SyncTimout（就是超时落盘）这个，dtnsq写竟然40w/s，而nsq才18w/s~20w/s 没办法加上了默认了SyncTimout(2s)，但是dtnsq也是30w/s 大家在落盘之前都是内存操作，如果有性能差异，我猜测是 channel导致的 读性能 »
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. »
分布式锁
起因 之前遇到一些场景，使用了分布式锁，目前来做一个总结 redis 1. 单点redis 单点redis场景，主要容易存在单点故障。（分布式高可用的手段：1.单点故障转移 2.数据冗余） // 获取锁 SET key value NX PX xmilliseconds // 删除锁 if redis.call("get" »
分布式id生成器
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: »
snowflake
分布式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 »