序列号要素
唯一性
生成的序列号需要全局唯一。这个唯一也不是绝对的，因为首先要理解全局的概念，全局可以理解为一种业务范围，比如说订单生成，也可以到数据库表一级（因为业务建模最终会在表结构进行体现）。也要考虑到分表情况，一张订单表可能分为多张订单表并存在不同的分布式数据库中，那序列号也必须保证唯一。
支持高可用，高并发
出现不可用的情况后，必然影响业务进件，并发量支持不高的话，也无法适应高频场景。
有序
由于序列号大多为数据库表主键，也是查询的关键字段，保证有序，可方便查询。
业务意义
序列号生成后不能是一堆有序的乱糟糟的数字字母组合，它必须要体现出一定的业务或者时间意义。这样可以一目了然找到这笔业务的实际业务场景或者发生时间，并且方便范围查询。但是要保证每段序列号分配，比如说前几位代表什么，后几位是什么意义。
举例说明：[业务相关字典项A]+[业务相关字典项B]+[业务相关字典项C]+...+[时间]+[分段递增]，这样可以根据不同业务选项进行like查询（这种%在右边的like查询是会走索引的）。
生成方法
网上有很多的生成方法，我这只是展示我们公司使用的方式，并指出优缺点。其实流水号前几位已经是固定的了，因为业务相关分段号和发生时间分段号在业务进件的时候便已知，那么我们需要生成的便是最后后几位。
UUID
最差的id生成方法，它只能满足唯一性，对业务不友好，对数据库不友好，我觉得它只能作为接口间传递的接口流水号，可以定位接口日志。我们也是这么用的。
数据库
独立数据库，就是说我们有一台数据库，专门用于生成自增id，由于是单库，所以可用性不能保证，性能也有瓶颈。但是优势是结构简单，维护容易，对于并发量不高的业务场景是可以使用的。
oracle可以使用sequence，mysql需要独立建一张表，并写一个函数用于获取id，伸手拉一个实现方案如下：
建表语句
CREATE TABLE SEQUENCE_ID (
id bigint(20) unsigned NOT NULL auto_increment,
stub char(10) NOT NULL default '',
PRIMARY KEY (id),
UNIQUE KEY stub (stub)
);
存储过程
begin;
replace into SEQUENCE_ID (stub) VALUES ('anyword');
select last_insert_id();
commit;
其实，滴滴有一个开源的基于数据库和segment（分段）模式的id生成器tinyid。可以白嫖，可用性要比上面的方式高（因为应用会将一部分序列号预存到内存中，即使数据库宕机也可使用），具体使用方式可以去github上观摩一下https://github.com/didi/tinyid。
Redis
跟数据库差不多的特点，只不过比数据库要快，核心是incr和incrby两个命令。但要开启持久化AOF，宕机后可以恢复。
