应用场景
应用场景：对于大多数电商系统或财务系统来说，系统中的单号一般都不是从1开始的自增数字，而是一串有一定意义的字符串序列。 而往往这样的单号是要全局唯一的，不可重复。 那么，每次新增订单记录时，这个单号就要按照指定的规则来生成。
常见的订单号规则是字母前缀+日期+时间+定长的数字，如DD201610201559060001(format:XXYYYYMMDDHHmmssNNNN)，PZ16102015000012(format:XXYYMMDDHHNNNNNN)
常见方案...
实现这样的场景，有如下几种方案：
1. 常规实现方案：代码逻辑为从数据表里取出现有最大订单号，转换后得到新的订单号，将新的订单insert到表里；
2. 考虑并发，在1的基础上，加lock，以避免多个线程同时执行这段逻辑，导致订单号重复引起主键冲突；
3. 对于2来说，这种方案仅适用于单应用部署的情况。 像电商的订单表，往往是好多系统都要生成订单， 那么，最终到数据库层级时， 也仍然会导致订单号重复引起主键冲突。 所以，要做数据库级别的锁表和事务控制；
4. 方案3的另一个版本：将生单逻辑从各业务系统解耦，封装起来单独部署。 然后提供rpc，供各业务系统调用。 这种方案的缺点是，单点部署会有风险。
比较以上方案，1显然是最基本的业务逻辑实现方案；当有并发时，2和4解决了单节点部署的并发问题，不过由于仅适用于单点部署，所以会有单点故障；3解决了多多节点部署下的并发问题，也消除了单点故障，互联网应用通常是要用nginx等技术做负载均衡的。
我的上一篇博客里有详细的方案说明。
完美方案
这里要介绍的是另一个方案——**从更细粒度的角度，将单号的生成抽象出来**。
具体怎么实现？ 见下面的方案：
**分离单号的生成和使用**
以日期为粒度，日终批量生成下一天的所有单号，暂存到一个单号表T_Sequence(seq varchar(64),primary key(seq))里。
次日系统有订单时，直接从这个单号表里取出一个订单号，作为新订单记录的订单号。注意，这里要说的是，取出这个订单号之后，就把这个单号从T_Sequence表里删掉， 这样可以保证每次订单号不重复。
对于这个方案，只要保证每天的订单号事先生成完成就行了，这一点很容易做到。 另外，所谓每天有多少订单号，这个需要程序员自己评估，然后得出一个保守的量。 当然，不考虑系统每日订单量，就直接确定一个保守值也没问题，比如1百万。 每天的日初删掉前日的单号即可。
这样一来，解决了单号重复问题，也极大提高了系统的性能。
**方案再次优化，利用Sequence**
oracle是支持Sequence的。 我的系统用的db是SqlServer。 今天通过和一个dba沟通，才得知SqlServer从2012以后，已经支持Sequence了， 这样的话，就可以直接读取Sequence的递增值，然后按照规则得到新增记录的订单号。 这个方案就无需对单号的生成和使用做分离了，也无需那些批处理服务了——这应该是最优方案了。
CREATE SEQUENCE [dbo].[Sequence-20161020-180217] AS [BIGINT] START WITH 1 INCREMENT BY 1 CACHE GO SELECT NEXT VALUE FOR [Sequence-20161020-180217]
不用Sequence也行，看这位仁兄的博客-[一种在SQLServer中实现Sequence的高效方法](http://www.cnblogs.com/heekui/archive/2008/07/24/1250842.html)， 或者这位仁兄的博客-[自已写的存储过程用来解决自动生成编号问题](http://blog.sina.com.cn/s/blog_638d83240100xvz1.html)
我是有底线的
作者：buguge
出处：http://www.cnblogs.com/buguge/p/5982180.html
如果，您认为阅读这篇博客让您有些收获，不妨点击一下右下角的【推荐】
如果，您希望更容易地发现我的新博客，不妨点击一下左下角的【关注我】
如果，您对我的博客内容感兴趣，请继续关注我的后续博客，我是【buguge】
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段
声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。