分布式全局唯一ID

全局唯一ID可以是整型或者字符串。如果是字符串，可以用UUID。缺点是字符串作为ID占用空间大，索引效率比整型低。如果是整型，可以用数据库自增ID，整型ID首先排除掉32位int类型，因为范围太小，必须使用64位long型。

UUID

比如version1。生成一个包含32个16进制字符串（结合机器识别码（全局唯一的IEEE机器识别号，如果有网卡，从网卡MAC地址获得，没有网卡以其他方式获得），当前时间，一个随机数）。不仅能保证分布式集群的全局唯一性，还能保证全球唯一性（mac地址48bit，全球每个设备mac地址唯一）。
优点是简单粗暴，直接本地生成，不需要协调各节点。
缺点是长度大，存储开销大，而且无序（非单调递增）
Go生成uuid方法：https://github.com/satori/go.uuid

数据库自增ID

数据库自增ID从1开始，连续递增，能够保证数据表唯一。
优点：简单。
缺点：数据插入数据表之后才生成自增ID（如果需要用到这个ID，需要再查表返回这个自增ID）。且数据库自增ID不适用于ID有可能需要改变的场景。（数据表主键最好不要修改，特别是数据量大的时候，否则会导致大规模的数据记录物理位置调整）此外，数据库自增ID只能保证数据表唯一，不能保证多个数据表之间唯一，有一定的限制。

集中式ID生成器

比如借助redis和zookeeper生成全局唯一ID，缺点是严重依赖外部应用，增加复杂程度（最好不要引入系统中原本不需要的组件）。

Redis

Redis的所有命令是单线程的，可以利用Redis的原子操作INCR（让key中存储的value值+1），来生成全局唯一的ID。比如利用Redis来生成每天从0开始的流水号，如订单号=日期+当日自增长号。可以每天在Redis中生成一个Key，适用INCR进行累加。
优点是性能高，缺点是redis宕机后数据丢失。

zookeeper

通过创建zookeeper的顺序模式的znode节点，可以生成全局唯一的ID。节点创建完成后，会返回节点的完整的层次路径和生成的序号，可以通过截取路径末尾的数字，作为新生成的ID。由于zookeeper保证了同一时刻只有一个节点能够在zookeeper上创建znode节点，所以能够保证此序号是全局唯一的。
缺点是高并发场景下速度慢。