分布式微服务下，可能会将系统按功能拆分（比如拆为订单中心和库存中心…），那tidb中数据库是建一个还是也拆开为多个，拆分为多个那跨库查询会不会有效能问题，还有跨库的分布式事务tidb是否原生支持
tidb中数据库创建一个也好多个也好问题都不大，只要创建一套tidb集群就好。
在一个tidb集群中跨库查询不会有效率问题，tidb是支持跨库的分布式事务的。
另外比较建议的是批量类和略微复杂一些的查询语句单独部署tidb-server计算节点，尽量与TP系统分开。
1 个赞
您好，感谢您的回复，针对跨库的事务支持感觉是业界比较难的题目，当然也有借助第三方中间件（比如阿里seata，但效能比较差），那tidb是如何做的呢，请问哪里有相关资料
你指的跨库是跨集群吧。上面说的跨库是在同一套集群中跨schema，跨schema的事务支持并不难，也不需要中间件，如果有这种需求，把数据放到一套集群里就好了。
他应该是没用过分布式数据库，不知道tidb就是为了解决此类问题的，对他来说想要的应该就是一个集群多个schema(库)
确实没用过分布式数据库，我指的是其实是不同的schema（比如订单中心一个数据库，库存中心另外一个数据库）。那基于微服务的分布式事务tidb能处理吗？比如订单中心调用库存中心的服务，库存中心成功了，订单中心出错了，那库存中心怎么回滚（tidb原生支持？）
多个微服务，每个微服务对应一个数据库（schema），实际上我想问的是跨服务的分布式事务tidb是怎么解决的，还是不支持
你把tidb当成一个性能很强大的mysql单机库就可以
我理解在同一个集群内每个微服务对应一个数据库（schema），本质上和访问同一个database并无区别，schema只是逻辑上的。
1 个赞
很多关键问题混在一块了。mysql场景下，多个schema可能会在多个mysql实例上，因为本身mysql的性能受到单机性能限制，庞大的系统，如果做数据库的纵向切分，通过seata做分布式事务，是一种比较好的解决方案。如果底层数据库采用TiDB，需要换个角度思考，TiDB就是一个性能、存储“不受限制”的数据库，业务方只需要不断的创建schema，不断的建表的就可以了，不需要考虑太多。在没有seata这种中间件之前，你所说库存中心成功了，订单中心出错了，那库存中心怎么回滚，只是需要放在一个事务里面就可以了，在TiDB仍然如此。
1 个赞
参考这个 一个集群6000+数据库
所以说TIDB本身解决的是关系数据库的弹性扩展的问题，并且支持基于多节点的分布式事务。但这里的分布式事务应该是基于同一个数据库连接的（当然也可以跨schema），但如果将系统微服务化了，系统之间的调用是通过API进行的，已经不属于一个连接，我理解tidb也解决不了这种微服务之前互调带来的分布式事务问题（即使底层是一个tidb集群）。这个时候就需要上层的seata中间件来处理了
是的，但tidb在针对微服务架构时的建议措施是什么？是基于不同的微服务建不同的scheme，还是所有的微服务公用一个schema。如果真的tidb底层针对这2种方式没有任何差别，那应该按功能纵向拆分比较好，各个微服务无论是应用层还是存储层都各司其职，互不干扰。否则就变成了一个非常庞大的云端saas单体应用。
一个集群6000+库，感觉太多了，应用层也是采用微服务架构吗，那你们是如何解决跨服务的分布式事务问题的呢
其实还有个核心问题，就是微服务切分之后，我们原则上是不能直接访问其他应用的db的，只能通过api来访问，否则微服务之间的耦合就打了，违背了微服务的设计原则。这就是为啥不在同一个事务里面，没法直接采用tidb分布式事务的原因。
那这样和用什么数据库就没关系了，是开发需要考虑微服务的分布式事务解决方案，这种一般都是做一些补偿或通知机制来保证事务的最终一致性，参考一下这篇文章：
一个系统，一套TiDB集群，不同应用（功能模块）可以建不同的database，使用不同的用户。因为在一个集群里，分布式事务TiDB自身就支持的。无需应用考虑。
从开发的角度你可以将TiDB当做一个可以无限大的MySQL单实例来用。
你要的是属于业务层面的分布式事务，肯定是由应用层去做，TCC、 Seata、2PC、3PC都是常用的方案
明白你说的意思了。我个人不太赞成应用seata或者说哪怕是消息中间件来做两阶段提交来保持跨应用的事务，我们一般是应用消息中间件来保持最终一致性，这对系统来说可以调优的空间比较大。我们的认知中，但凡需要强事务保证的两个接口就应该在一个应用上，是不应该拆开的。
分布式服务并不影响用一整套tidb集群服务，业务服务需要数据隔离的话可以在tidb用户层面进行数据隔离