leehom

失效转移getLocalTakeOffItems逻辑问题

2

分片完后，getLocalTakeOffItems，获取分配了的失效转移分片，然后从运行实例分片中移除 > public ShardingContexts getShardingContexts() { 。。。 > // 分片 > shardingService.shardingIfNecessary(); > List shardingItems = shardingService.getLocalShardingItems(); > // 重新上线？ > if (isFailover) { > shardingItems.removeAll(failoverService.getLocalTakeOffItems()); > } > shardingItems.removeAll(executionService.getDisabledItems(shardingItems));...

using codegen to improving performance of rule execution

1

dynamic compile and codegen other than interpreting execution can improve the performance of rule execution

分布式darax(平民版)详细(落地)设计

2

https://xie.infoq.cn/article/12ffb9991783e866394ea502f 目前处于测试阶段，有了解官方版的设计的，可以讨论一下

增加关系/图同步插件

7

增加关系/图同步插件，关系数据库支持mysql/oracle，图库目前支持neo4j；同步分两步进行， 1. 同步节点，2. 同步关系，插件也有schema同步，版本4.3+； 设计 https://xie.infoq.cn/article/4977b6aa9aa588ee59e3ba8ac 同时，另一插件测试中，基于规则的转换同步， https://xie.infoq.cn/article/77c1a56d807abadefb83a944e

xxl-job弹性资源

1

 增加弹性，1到100万作业分片


首先分析一下pendingMap的状态  pengding请求过时，writeIndex调回到水位线+1作为写入点， - 上图的上部分是初始状态 writeIndex1 第一个批次请求；writeIndex2第二个批次请求，并已发送，pendingMap有两个数据 - 上图的下部分，writeIndex1超时，调和writeIndex，请求重新发送，但批次数量会有所不同，形成新的writeIndex1(覆盖原有)，writeIndex2-x，而且writeIndex1的批量比原writeIndex1大，writeIndex2-x比原writeIndex2大，pendingMap有3个数据 此时有两条发送线，不能说writeIndex2已废弃，可能跟随者已处理了原writeIndex1，只是回复失败，处理写入分析跟随者怎样处理 再看跟随者的处理  3.1.1 处理有点不解，按pendingMap分析，writeIndex2那批可能被返回不一致，处理没错，但本人认为更好的处理应该是保证写入点连续性即好，过期的请求删去就可以，一直走第二部分请求，若返回不一致，领导者进入比对，降低效率

最近分析dledger发现一个疑似的bug，上图4，比对点 < beforeBeginIndex 转到 INSTALL_SNAPSHOT状态，但如下图，snapshot mode是可选，又转到COMPARE状态，死循环？

 最近分析dledger，上图2处 计算committedIndex，请求携带的共识点，即集群的共识点，自身写入最后index，取较少的, 但memberState.followerUpdateCommittedIndex，计算committedIndex小于现有的committedIndex是不会更新，保留现有的。 下图比对2.4处， “term不一样，返回本节点term的第一个写入的index”, 回退到上一个term，可能大量的消息截取，出现共识点回退 **! 是否存在本节点的committedIndex大于写入存储的index?**