作为互联网领域的程序员，有相当一部分人都曾经接触过电商领域这一块，即使没接触过，想必对“订单号”的概念还是有一定的了解，其中“订单号”最重要的一个核心思想就是保证绝对唯一，对于一些访问量比较大，高频生成订单的网站，通过技术手段生成唯一号码，想必很多人都能轻易的回答上来，这些答案中可能并不相同，每个人都有自己的思路，最常见的就是靠数据库自增，如果想要一些其他特殊规则，也可谓仁者见仁智者见智了。
近期，一名码农网友给我们分享了一段生成订单号的代码，据他说，他最近要开发一个下单功能的程序，以前没写过类似的逻辑，关于订单号的生成他想借鉴一下其他人的逻辑，看看他们都是怎么生成订单号的，他在网上问了好多码农朋友或者网友，结果真有一位好心人无私的奉献他的一段代码逻辑，这名网友看了这段逻辑后感觉很意外，没想到生成单号的逻辑如此简单，很容易理解，脑袋就不需要拐任何弯就可以看懂代码，并且这名网友说看了这段代码真是亮瞎了他的双眼，接下来我就贴出这段代码，大家可以一起品品这段代码如何，并且针对这样的代码让我们一起看看其他网友们都是怎么认为的吧！
网友一：写了一堆没用的转string,查不到还把单号写死了，名其妙莫得在给单号加一
上世是朵花：逻辑到没什么拐弯的，不过似乎考虑的有点简单，除去高频生成单号的情况和一些特殊因素，这样的代码也能工作，但是这样的代码真是有点经不起推敲啊，遇见一些特殊情况可能就完了。
网友二：这逻辑能力让人流泪！
上世是朵花：之前经常见网友吐糟某代码思路奇葩清奇之类的，看了这段代码我个人的评价是这段代码逻辑比较单纯，纯洁！
网友三：并发大数据库自增也会出问题
上世是朵花：嗯，不过靠数据库自增已经能解决90%的生成订单号的场景了，如果并发大到一定程度另有设计方案，其中设计思想就是生成单号的环节肯定有 串行队列这个概念。
网友四：订单号能变来变去还有default的，有点屌
上世是朵花：的确算是一个槽点，如果因为什么意外情况都进入default这个分支后，岂不是生成一堆重复的订单号。
网友五：如果是null取出来不就永远是那个单号+1了吗
上世是朵花：没错，只要是代码写出来的情况，都有可能会执行到那个分支，如果不想有这个情况就不要开这样的分支。
网友六：单号查询为空直接赋个定值是啥意思；自增1没考虑并发吧，为啥不用数据库自增的
上世是朵花：是的，从这段代码看的确没考虑到并发的情况。
网友七：写这个代码的人应该不知道数据库自增的功能……
上世是朵花：我想可能也知道，可能想定制自己的逻辑，比如单号前缀，一般情况下都是用自己的代码对数据库自增封装一下，注入一点自己的逻辑来生成订单号。
网友八：我怀疑，mapper是查Max，数据库存的varchar，所以需要转一下加一。这代码可以看出一天没几个订单
上世是朵花：在访问量小的情况下，这样的代码漏洞也的确暴露不出什么问题，如果一直是这样的状态，运行几年估计也是会一直保持正常工作的。
生成订单号的逻辑不是很难，也没有什么复杂的，但有一个大家都知道的要求，那就是单号保证绝对唯一，这个要求不高，随着并发量越高，这个难度将会越来越大，网站的所有访问情况都是并发的，可以高度并行访问，但是到生成单号这一步一定是串行的，不论是用锁，队列等什么的机制，总之都是要保证这一步是串行操作，一般情况下靠数据库主键自增已经够原子操作了，能解决绝大多数生成单号的问题，如果并发大到一定程度，就需要结合现有的业务场景实现自己的取号机制，能够在保证效率的情况下实现绝对唯一的设计才是我们想要的，当然，这个设计的复杂程度也是要与业务场景相结合的，有的设计在这个业务场景是没问题的，但是到另一种访问规模可能就会需要出问题了。
以上所有图片均来之互联网
大家好，我是“上世是朵花”。如果你有什么好的看法或者观点可以在评论区展现你的才华，互动交流，如果想进一步了解我，那就关注我吧！
451
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
