数据库方式实现方案?有什么缺陷?

MySQL为例我们将分布式系统中数据库的同一个业务表的自增ID设计成不-样的起始值，然后设置固定的步长，步长的值即为分库的数量或分表的数量。

以MySQL举例，利用给字段设置auto_ _increment _increment和auto_ _increment _ffset来保证ID自增。

auto_ increment_ offset: 表示自增长字段从那个数开始，他的取值范围是1 .. 65535。
auto_ increment_ increment: 表示自增长字段每次递增的量，其默认值是1,取值范围是1 .. 65535。

缺点也很明显，首先它强依赖DB，当DB异常时整个系统不用。虽然配置主从复制可以尽可能的增加可用性，但是数据一致性在特殊情况下难以保证。主从切换时的不一致可能会导致重复发号。还有就是ID发号性能瓶颈限制在单台MySQL的读写性能。

使用redis实现

Redis实现分布式唯一ID主要是通过提供像INCR和INCRBY这样的自增原子命令，由于Redis自 身的单线程的特点所以能保证生成的ID肯定是唯一有序的。

但是单机存在性能瓶颈,无法满足高并发的业务需求,所以可以采用集群的方式来实现。集群的方式又会涉及到和数据库集群同样的问题，所以也需要设置分段和步长来实现。

为了避免长期自增后数字过大可以通过与当前时间戳组合起来使用，另外为了保证并发和业务多线程的问题可以采用Redis + Lua的方式进行编码，保证安全。

Redis实现分布式全局唯- -ID, 它的性能比较高,生成的数据是有序的，对排序业务有利,但是同样它依赖于redis,需要系统引|进redis组件，增加了系统的配置复杂性。

当然现在Redis的使用性很普遍，所以如果其他业务已经引|进了Redis集群，则可以资源利用考虑使用Redis来实现。