微服务架构中真的有必要使用分布式ID吗？

Question

探讨话题：
分布式系统中真的有必要使用分布式ID吗？

在网上大多数写分布式ID文章的观点是，微服务中由于数据量大会对数据进行分库分表处理，所以需要用到分布式ID，避免使用msyql自增ID造成ID冲突。

但是我想说的是就算分库分表，它也是根据某个字段进行hash或者rang分片规则来决定数据存储在哪个数据库节点上的。所以我们写sql查询语句的时候，where条件语句中肯定是需要带上分片规则指定的字段来查询，这样可以洛到具体的节点查询数据，不可能遍历所有数据节点查数据，我想这在高并发的场景里是绝对不被允许的。

那既然是这样的话，我想分布式ID在这里根本就没有必要使用。直接使用mysql的自增ID即可，只不过这里的ID其实没有实际的业务意义。

至于标识数据的唯一性，我想使用UUID生成即可满足业务需求。

Answer 1

针对这种架构层面上的东西，我向来主张一句话：软件工程没有银弹。

这句不是我编的，而是 IBM 大型机之父 —— 布鲁克斯的原话。他有本书你应该听过，就是著名的《人月神话》。

具体问题需要具体分析，并不存在一个放之四海而皆准的架构设计原则。你给的场景信息太少，单单一个“微服务”恐怕很难给出具体的结论，这本来就是公说公有理、婆说婆有理的事情 —— 毕竟谁也不知道你要面对的业务是什么。

我只能抛出一个可能存在的问题：用 DB 自增键做分布式 ID，那么对于大量插入操作而言，是不是瓶颈落在了 DB 上？如何高可用？如果用分库分表+设置步长的方式，如何扩容？

如果你的答案是通通不需要，那确实引入一个额外的分布式 ID 方案，除了增加系统复杂度之外，别无他用。

Answer 2

如果我想要根据名称去查询所有的数据，这不就翻车了，甚至不需要条件，我就去查询所有的数据，找到了两个id一样的玩意，这没问题吗？
分表在逻辑上你可以认为数据还在一个表中，id相等就相当于一个表中出现了主键数据相同的情况

Answer 3

分布式 ID 最大的优势不是分库分表，它最大的优势是 :

数据库中的每一条数据 ID 都不同

这个好处就是，你可以任意复制一整条数据到任意其他库中，而不必担心是否出现主键重复的问题，另外在关联查询的时候可能存在 c 表中的 belong_id 所属关系属于 a表 或 b表 ，而由于 a b表的主键没有相同的因此可以从 a 或 b 直接关联 c 中的 belong_id 而无需区分这行数据是否是关联本表的；

另外在数据迁移的时候很可能碰到原库中已经有数据，现在需要把其他库中的数据部分导入过来，如果要导入过来的数据有好几张表，且互相均存在关联关系，那么分布式 ID 的优势就非常明显，不需要担心像自增ID存在的主键冲突，因为一旦冲突，关联关系就会被破坏。

分布式ID目前最佳实践为 雪花ID 实现，它最大的好处是递增整形数，因此比起 uuid 最大的好处就是他的排序和 自增ID 的排序一致，不会乱。

Answer 4

uuid太长且无序不利于索引，而且主键是有意义的。不是阿猫阿狗字段都能做主键的

Answer 5

分布式id说的就是数据的唯一标识，你最后提的的uuid其实可以看做一种分布式id的实现方案，而你前面说的每个库没有任何意义也不在乎是否重复的“id”，其实跟分布式id要讨论的完全是两回事，并且你自己也是意识到了的，必须有一个像uuid这样能唯一标识数据的东西，所以你的问题是对“id”的理解过于狭隘了

Answer 6

这种理想化带上分片信息的数据查询在用户报表或则业务报表，以及一些大数据量BI分析统计下就没法了，所以现在很多的架构都是在分库分表的基础上，还有一些全量数据存储方案，比如Tidb，，hive，spark，等这些存储方案下。