清晨的炸鸡啤酒花生米的博客

设计思路有意义的位数的订单号日期+订单来源+支付类型+业务标记+用户ID+自递增数这样就比较一目了然，也是很常见的 设计方案可以反解的订单号，本身一眼是看不出你订单的意义可以通过反解订单知道此订单的情况，这不是和方案1一样吗？方案一会暴露系统的订单设计意义，方案可能会涉及到加密等问题，为了数据安全考虑无意义的订单号为了处理并发，有些情况下，为了巨大的并发量会设计一个算法来生产订单号的接口，直接使用使用redis，mysql锁机制做自增数，一个内部调用的一个服务这样然后可以配合任意的前缀...