分库分表之后,id 主键如何处理？
因为要是分成多个表之后，每个表都是从 1 开始累加，这样是不对的，我们需要一个全局唯一的 id 来支持。
生成全局 id 有下面这几种方式：
- UUID：不适合作为主键，因为太长了，并且无序不可读，查询效率低。比较适合用于生成唯一的名字的标示比如文件的名字。
- 数据库自增 id : 两台数据库分别设置不同步长，生成不重复ID的策略来实现高可用。这种方式生成的 id 有序，但是需要独立部署数据库实例，成本高，还会有性能瓶颈。
- 利用 redis 生成 id : 性能比较好，灵活方便，不依赖于数据库。但是，引入了新的组件造成系统更加复杂，可用性降低，编码更加复杂，增加了系统成本。
- Twitter的snowflake算法 ：Github 地址：https://github.com/twitter-archive/snowflake。
- 美团的Leaf分布式ID生成系统 ：Leaf 是美团开源的分布式ID生成器，能保证全局唯一性、趋势递增、单调递增、信息安全，里面也提到了几种分布式方案的对比，但也需要依赖关系数据库、Zookeeper等中间件。感觉还不错。美团技术团队的一篇文章：https://tech.meituan.com/2017/04/21/mt-leaf.html 。
- ......
-
面试题 分库分表之后，id 主键如何处理？ 面试官心理分析 其实这是分库分表之后你必然要面对的一个问题，就是 id 咋生成？因为要是分成多个表之后，每个表都是从 1 开始累加，那肯定不对啊，需要一个全局唯一的 id 来支持。所以这都是你实际生产环境中必须考虑的问题。 面试题剖析 基于数据库的实现方案 数据库自增 id 这个就是说你的系统里每次得到一个 id，都是往一个库的一个表里插入一条没什么业务
-
问题内容： 我有一张桌子，它是： 当我提出错误的要求时，例如要为唯一列输入相同的值。“ id”正在增加…这是错误的id请求； 这是我的表结果; 请帮助我如何解决此问题，我想订购。顺序的.. 问题答案： 这就是序列的工作方式。 重要提示：为避免阻塞从同一序列中获取数字的并发事务，绝不会回退nextval操作。也就是说，一旦获取了值，就将其视为已使用且不会再次返回。即使周围的事务稍后中止，或者调用查询
-
我有两个分支:和。我刚刚将合并回中，并且完成了该分支。我应该删除它还是让它坐着？删除它是否会导致数据丢失？
-
实现动机 传统数据库软件开发中，主键自动生成技术是基本需求。而各个数据库对于该需求也提供了相应的支持，比如 MySQL 的自增键，Oracle 的自增序列等。 数据分片后，不同数据节点生成全局唯一主键是非常棘手的问题。同一个逻辑表内的不同实际表之间的自增键由于无法互相感知而产生重复主键。 虽然可通过约束自增主键初始值和步长的方式避免碰撞，但需引入额外的运维规则，使解决方案缺乏完整性和可扩展性。 目
-
主要内容：1.ShardingSphere概念,2.功能列表,3.项目状态,4.分库分表_结果归并1.ShardingSphere概念 ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由、和 这3款相互独立的产品组成。 他们均提供标准化的数据分片、分布式事务 和 数据库治理功能，可适用于如Java同构、异构语言、云原生等各种多样化的应用场景。 Apache ShardingSphere 旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力，而并非实现
-
Kafka只提供一个分区内消息的总顺序，而不提供主题中不同分区之间的消息的总顺序。每分区排序与按键对数据进行分区的能力相结合，对于大多数应用程序来说已经足够了。但是，如果您需要消息的总顺序，这可以通过只有一个分区的主题来实现，尽管这意味着每个使用者组只有一个使用者进程。 下面是我的问题： > 这是否意味着如果我希望有多个消费者（来自同一组）阅读一个主题，我需要有多个分区？ 分区是如何编号的？从0开