TIkv 的 JavaClient 没有 batchGet，只有 batchPut，这个什么时候能支持呢？
这个需要跟研发同学确认下，请稍等。
现在的Java Client 是一个比较粗糙的版本，是从很古老的 TiSpark 版本中切割出来的，而且也暂时无人维护。我们这个月正在整理 TiKV API 的接口设计，希望和 go 等其他版本一起统一设计和更新，所以大致上会在年底或者明年初完成新的版本的设计和重构，那个版本将会作为长期维护版本，且包含必要的接口。
好的 谢谢
还有个问题想问下，Java 版的 BatchGet 有什么坑么？ 我看Java Client，对其他基本方法都实现了，唯独这个没去实现。所以想知道有没有什么坑或者难点，我自己开发 BatchGet接口的时候，能避免掉。如果到时候测试没问题，我也很希望能提PR。
还有个问题想问下，Java 版的 BatchGet 有什么坑么？ 我看Java Client，对其他基本方法都实现了，唯独这个没去实现。所以想知道有没有什么坑或者难点，我自己开发 BatchGet接口的时候，能避免掉。如果到时候测试没问题，我也很希望能提PR。
对于一个需要横跨多个 Region 的 BatchGet 请求，会需要涉及应对 Region 分裂任务重切的 backoff 策略，除此之外应该没太多坑。在 RawClient 接口层需要封装 RegionStoreClient 的 BatchGet，backoff策略需要在顶层实现。
辛苦提供下日志的详细信息吧。tidb.log ？
我没用 tidb，只用了tikv。 日志目录 是deploy 目录下的 log目录么？ 我在log目录下，没找到抛错的日志。。。
EpochNotMatch：该错误是说 Region 的版本过期。
检查机制实现是，每个 Region 信息都有 Epoch 信息，包括两个字段:
- conf_ver 代表配置项版本，新增或删除 peer 时，该属性会自增
- version 代表 region 的版本，当 region 被合并或拆分时，该值会自增
TiDB 的在请求 TiKV 时会在请求中附上 Epoch，KV 会校验 Epoch 如果不匹配则返回 EpochNotMatch 错误, 并在错误中附带自己知道的最新 Region 信息。
如果使用了 TiDB 那么 TiDB 在收到报错后会进行 backoff 重试，但是您那里没有使用 TiDB ,那么建议在业务端设计重试机制，进行重试。
d好的，那我明白了。是我改代码 打的日志有问题，我应该忽略 这种错误。谢谢
我写完了代码，并测试完成。准备明天提个 Tikv Java Client 的 PR，到时候麻烦看下 是否有问题，谢谢！
期待
收到，已经通知了研发小伙伴了~
多谢 我们尽快完成review
最近在密集更新，大家可以关注下
1 个赞