didi / tinyid Goto Github PK

https://github.com/didi/tinyid/blob/49976d37222ab1089a8c413b4520cc55d105d428/tinyid-server/db.sql#L9C20-L9C20

单例的DbSegmentIdServiceImpl的retry全局变量，最好搞成常量，大写。

IdController 中 idGeneratorFactoryServer.getIdGenerator(bizType) 每次返回的都是新的CachedIdGenerator的实例，而你在这个实例里搞了（实例）锁，起不到对数据库（version冲突）减压的效果。应该锁 “bizType”

能否增加动态step调整，因为如果一开始对业务调用量无法评估的话，对step设置的过小会导致每次分配的segement使用过快，更新时冲突的概率变大，设置得过大又容易造成segement浪费。如果在增加maxId时记录增加时间lastTimeStamp，在下次增加maxId时，判断当前时间减去lastTimeStamp之间的时间差，如果小于我们设定的时间间隔(例如15分钟)，那么我们就增大内存中step变量的值，如果大于就适当减少step变量的值，这样可以让segment分配的频率在我们可控的氛围内，如果可以增加的话，我可以实现这部分代码提PR

如果有一台tinyserver挂掉， tinyclient的router不是会出问题吗？

我看router的逻辑很简单， 从配置文件拉取tinyserver的地址集合放入容器， 然后根据随机去取一台服务。

rt

private static IdGeneratorFactoryClient client = IdGeneratorFactoryClient.getInstance(null); 这个里面为什么用锁机制，静态初始化不是线程安全吗？

IdGeneratorFactoryClient = new IdGeneratorFactoryClient();
应该在init方法成功之后再new

1. 假设当前使用的号段为①
2. 调用nextId多次后，会走进loadNext, 假设next = querySegmentId()里的querySegmentId已经执行完了，等待赋值给next
   • 假设这时候查到的号段为②
3. 继续调用nextId直到用完，会走进loadCurrent。然后因为上面的next还没赋值，所以会走进querySegmentId
   • 假设这时候查到的号段为③

造成的结果: ①号段使用完了，③号段接着用，然后才可能用到②号段

CVE-2018-3258 CVE-2019-2692 CVE-2020-2934 CVE-2020-2875

Recommended upgrade version：8.0.20

有UI管理页面吗？

已经通过max_id判断是否发生过改变，就没必要再增加一个version作为乐观锁了吧？

现在IdGenerator是在每次请求来时去初始化的，这样可能导致初次访问性能较差，可以启动时完成对IdGenerator的初始化，然后开启定时任务去扫表增量初始化新加入的

能否把mysql换成postgresql

如何解决同一类型流水同时更新version超过最大次数问题，可能有100个服务同时使用一个类型流水，同时获取 超过最大次数 抛出异常，怎么解决

class IdGeneratorFactoryClient extends AbstractIdGeneratorFactory{
....省略
@OverRide
protected IdGenerator createIdGenerator(String bizType) {
return new CachedIdGenerator(bizType, new HttpSegmentIdServiceImpl());
}
....省略
}
是不是有点问题，需要手动改一下，将HttpSegmentIdServiceImpl改为DbSegmentIdServiceImpl，但改为DbSegmentIdServiceImpl不就引用了tinyId-server工程了吗

这个ID生成器，已经长期没人维护了，只能说能用，要用最好fork改一份，否则挺多陈旧的代码。

如果要用的，几个要点需要改下：

1. Server 端 数据库不支持mysql8.x 及以上的
2. 最好升级下springboot 版本，1.x 过于陈旧，升级时，需要改动一下代码
3. 使用 hikari. 连接池替换 tomcat 自带连接池，提高性能
4. 升级为 springboot 2.x 及以上，server.context-path 需要 更改为 server.servlet.context-path
5. Client 端，默认硬编码读取resource 下的 tinyid_client.properties 配置文件，不太友好，最好改成可配置

其他的BUG，PR 有修复，有人维护的话最好是合并下吧。

执行sh build.sh offline报错：
Failed to collect dependencies at com.xiaoju.uemc.tinyid:tinyid-base:jar:0.1.0-SNAPSHOT
是否要新增先构建tinyid-base的脚本？

curl http://127.0.0.1:9999/tinyid/id/nextIdSimple -d 'token=0f673adf80504e2eaa552f5d791b644c&bizType=test&batchSize=0'

java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:824) ~[?:1.8.0_241]
at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) ~[?:1.8.0_241]
at com.xiaoju.uemc.tinyid.server.controller.IdContronller.nextIdSimple(IdContronller.java:85) [classes/:?]

python 库有么

DbSegmentIdServiceImpl类查询db最新号段
@Transactional(isolation = Isolation.READ_COMMITTED) public SegmentId getNextSegmentId(String bizType) { // 获取nextTinyId的时候，有可能存在version冲突，需要重试 for (int i = 0; i < Constants.RETRY; i++) { TinyIdInfo tinyIdInfo = tinyIdInfoDAO.queryByBizType(bizType); ...... int row = tinyIdInfoDAO.updateMaxId(tinyIdInfo.getId(), newMaxId, oldMaxId, tinyIdInfo.getVersion(), tinyIdInfo.getBizType()); ..... } throw new TinyIdSysException("get next segmentId conflict"); }
1、查询db获取最新号段的确需要做容错重试，重试的逻辑应该是在更上层service业务做的，这里service只做单一的更新号段逻辑。
2、如果在上层service做重试，这里查询和更新操作可以不放在同一个事务中，如果考虑到同一个事务使用同一个mysql连接成本更低，这里就不用使用读已提交的隔离级别了。

tinyid_client.properties 里面不便于切换环境 ，应该放在application.properties里

tinyid是否支持部署到K8S容器内呢?

现在tinyid ip列表, 如果换成 k8s, 就只能写一个 k8s 的 service 名了 .

同主题

id bigint(20) unsigned id字段为无符号时，在Javabean对应的应该是 BigInteger.
对应是Long时，会有越界问题。9223372036854775808在bigint(20) unsigned可以保存，但赋值给Long会越界。
建议使用ORM框架Bee的GenBean自动生成Javabean.
鉴于tiny_id_info表不会有太多的记录，用 bigint(20)就可以了。

假如有3个库，DB1，DB2，DB3
DB1挂了会自动尝试DB2依次尝试DB3

tiny client 模式（有本地缓存），怎么解决个应用实例同时生产id，不重复问题？

CVE-2019-10086

Recommended upgrade version：1.9.4

在动态数据源DynamicDataSource类中determineCurrentLookupKey，每次都是随机选择真实的DataSource，但是在DbSegmentIdServiceImpl.getNextSegmentId方法中使用了乐观锁，每获取一个SegmentInfo都存在query 以及 update 数据的动作，所以query和update可能操作的不是同一张表

在 maven 的**仓库中还搜不到 jar 包坐标，什么时候发布到**仓库中？