感谢对 TiDB Serverless 的关注。TiDB Serverless 的版本升级由平台统一控制，会在 LTS 版本发布后稍稍等待一段时间发布几个 bugfix 的版本之后再启动。目前正在灰度验证中的版本是 7.1 LTS 系列，会在近期逐步放量直到全局发布。7.5 LTS 的发布应该会在 7.1 LTS 正式全量发布后接近半年的周期再升级。 TiDB Cloud 上服务化版本同完全可自定义调整的 TiDB 版本不同的限制可以在这个文档处查看：https://docs.pingcap.com/tidbcloud/limited-sql-features TiDB Serverles…

是 hackathon 的项目，后续没有继续做。欢迎社区有意愿投入的同学提技术方案并参与开发。

报错说明在试图连接本地的数据库，而不是 TiDB Cloud 上的服务。需要检查下应用配置如何指定服务器地址。 另外千万不要把你的密码放在公网上，赶紧去 reset 密码吧。

Serverless 不用 RocksDB 是一套独立的面向云上设计的存储引擎。另外主干版本的 TiKV 也同样在 RocksDB 上实现了多 region 不共享 LSM Tree 的能力。每个 region 都有自己独立的 RocksDB 的 LSM Tree 实例。

yes, 但是关心性能可以选择 100% 缓存的策略

有本地盘上的缓存用于读取

感谢大家对 serverless 产品的关注。考虑到目前可以投入的资源，研发和产品交付还仅限于海外的 AWS region，当然未来也会向 GCP 和 Azure 扩展。中国区的服务会在后续有精力的时候根据 AWS 中国区产品相关能力匹配程度和市场成熟程度来安排部署计划。

@Christophe 这个不是主动屏蔽，但是能不能访问得看本地的接入网络访问海外的情况了。

Serverless 是一个通用概念，可参考 FAQ 或者其他 Serverless 相关的介绍文档。https://docs.pingcap.com/tidbcloud/serverless-tier-faqs#serverless-tier-faqs 看样子网络不通，可以先 traceroute 查下网络通路是否有问题，或者先简单的翻墙连接一下。服务在海外本身没有限制国内访问，但整个链路较长是否需要翻墙要看你的网络情况。

机械盘跑 TiKV 不在官方支持范围内，自己这么跑的话也需要了解到机械盘不可能支撑大流量，跑 benchmark 这种事情一定会把机器压死。

HashMap 并发做这个写入是不行的，报告的那个异常是这个问题引起的。Concurrency 问题是随机的，没重现不代表它不存在，这里改成 ConcurrentHashMap 应该是合理的。 另外 TiKV 直写过去还有一些问题尚未完全解决，建议现在线用 JDBC 方式写入。

Flink 读的数据不只会在自己的机器上，也可能会跨机器读取。如果网络带宽不够成为瓶颈，就会影响到系统的吞吐。

TCP 连接本身是双向的，一个连接可以在两个方向上发送数据。在目前的通讯模型下，数据读取是由客户端发起由服务端返回的。 另外问下最后定位到是什么问题呢？

监控进程的流量用分配给具体容器的那个应该就行

代码里没搜到那个 Multiple entries 的内容不好定位是哪里的检查，收到错误的时候完整的 stack 有打印出来么

看上去这个表使用了 TiSpark 不支持的特性 Supports and Limitations TiSpark (>= 2.4.2) supports writing data to clustered index tables, which is a new feature in TiDB-5.0.0. TiSpark does not support writing to the following tables: tables with auto random column partition table tables with generated column https…

这个有点奇怪，正常来说双向是一样的带宽。问一下你们团队的基础设施团队看看这个网络有没有什么问题？

看上面的线程图如果持续是这样没有某个线程接近 100% 的话那应该不是分发线程瓶颈。 网络角度看的话 TiKV 用的是 TCP 连接，可以拿 iperf 看下 TM 这个机器的入流量是什么情况

用这个 top -H 的命令来看，主要是想知道有没有某个类似于 dispatcher 的线程成为瓶颈了 另外你提到的网络的确也有可能是一个瓶颈点，可以观察下客户端机器上的出口带宽和机器的网卡能力的比值