落盘的b+树(二)

事务 之前的b+树,并没有满足一致性的需求(或者说原子性), 因为涉及到写操作的时候,牵扯多了多个节点变更,如果出现其中一个节点写出现问题,整体上就没有办法恢复了. 所以加了一个分支,实现了出现部分写入问题,可以进行回滚. 解决 需要解决这种问题,目前必须采用double write,就是提前讲数据落在别的地方,等出现问题的时候能够从别处恢复 整体上记住一件事,出现double write的场景都是因为写是inplace update而不是append only redo/undo 例如mysql中innodb的undo和redo »

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. »