// HandleTSORequest forwards TSO allocation requests to correct TSO Allocators of the given keyspace group.
func (kgm *KeyspaceGroupManager) HandleTSORequest(
ctx context.Context,
keyspaceID, keyspaceGroupID uint32,
count uint32,
) (ts pdpb.Timestamp, curKeyspaceGroupID uint32, err error) {
if err := checkKeySpaceGroupID(keyspaceGroupID); err != nil {
return pdpb.Timestamp{}, keyspaceGroupID, err
}
allocator, _, curKeyspaceGroupID, err := kgm.getKeyspaceGroupMetaWithCheck(keyspaceID, keyspaceGroupID)
if err != nil {
return pdpb.Timestamp{}, curKeyspaceGroupID, err
}
err = kgm.checkTSOSplit(curKeyspaceGroupID)
if err != nil {
return pdpb.Timestamp{}, curKeyspaceGroupID, err
}
err = kgm.checkGroupMerge(curKeyspaceGroupID)
if err != nil {
return pdpb.Timestamp{}, curKeyspaceGroupID, err
}
// If this is the first time to request the keyspace group, we need to sync the
// timestamp one more time before serving the TSO request to make sure that the
// TSO is the latest one from the storage, which could prevent the potential
// fallback caused by the rolling update of the mixed old PD and TSO service deployment.
err = kgm.markGroupRequested(curKeyspaceGroupID, func() error {
return allocator.Initialize()
})
if err != nil {
return pdpb.Timestamp{}, curKeyspaceGroupID, err
}
ts, err = allocator.GenerateTSO(ctx, count)
return ts, curKeyspaceGroupID, err
}
我是这么理解的。像上面的例子，周期改成25秒之后，50秒内能获得tos就翻了一倍，不是一次请求的翻了一倍。
，原文是默认的一个时钟周期内最多可以提供262144个，如果需要获取更多，也就是超过262144个…你的解释没问题，应该是文档描述不太严谨，代码中也没找到限制的代码，这个也算是一个缺陷 
？
你这么说也有道理，可以在 