雪花算法生成id是几位 MySQL分库分表之后，id主键如何处理？

MySQL分库分表之后，id主键如何处理？

我从分库分表存在的问题和怎么做来回答一下这个问题。。

一，分库分表的ID主键不能依赖于数据库的自增，因为多库中会重复！

通常使用外接的数据组件获取全局唯一的ID：比如加强型UUID（根据Ip，时间戳等得到）和使用Redis(RedisAtomicLong)和zookeeper的API获取，Twitter的雪花算法等等！

二，分库分表之后的连接查询比较困难！

问题没法避免，通常拆分SQL，使用多次查询，用查到的结果再分别查别的结果！

三，分布式事务的数据一致性很难保证！

可以使用TCC编程模型保证两处的事务都能正确提交，但是这种方式对代码的侵入比较重！也可以使用基于消息的数据一致性保证！

四，多数据的排序，分组，统计会比较困难！

1，用多线程，对多个节点分别查询，然后汇总！

2，也可以提前冗余查询表，将所有的经常查询的重点数据提前统一到个库表里！

分库分表涉及到的知识点比较多，建议使用专门的分库分表组件！本人有mycat使用经验，如果您有相关问题，欢迎前来探讨！

请问对于数据库的主键究竟要不要用自增id呢？

谢谢邀请！这个问题跟具体业务场景和技术实现有关：

1、业务场景：例如订单、支付单号等比较敏感的肯定不能自增了，都是安全级别很高的字段，需要唯一id作为主键。

2、技术实现：在实际开发过程中批量导入或处理数据的时候要考虑到技术实现的性能那么要多方面验证用自增主键还是非自增主键了。

在分布式系统中，如何生成分布式ID？

分布式ID常见的两种方法就是UUID和snowflake算法（雪花算法）。

UUID是一种本地生成ID的方法，不需要远程调用，高性能、低延时、扩展性好，但是UUID不支持递增。

snowflake算法是twitter开源的分布式ID生成算法，其核心思想是一个long型的ID：1位标识符（始终是0）、41位时间戳毫秒数、10位机器标识码、12位毫秒内序列号，该算法单机每秒内理论上最多可以生成1000*(2^12)的ID，性能高、趋势递增、灵活度高，但snowflake依赖机器的时钟，如果服务器时钟回拨会导致生成重复的ID。

雪花算法生成id是几位 雪花算法生成id java生成唯一字符串算法

版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。