业务需求
公司的一个非高并发项目中提出了关于订单号生成的规则：
业务类型（1位） + 城市编码（6位） + 渠道（4位） + 年份（4位） + 8位递增序列号
一共23位
并且需要满足后8位序列号随着年份而从1开始循环切换，即xxxx201900000001...xxxx201900000008 到
xxxx202000000001...xxxx202000000008类似的年切的规则
技术分析
基于订单号生成本身的要求即需要在分布式环境下保证唯一性，本来想利用redis单线程原子操作来实现，但是不太好实现年切的需求，因此采用了MySQL乐观锁来实现
乐观锁与悲观锁
介绍Mysql乐观锁之前先简单说一下乐观锁和悲观锁的区别
- 悲观锁
可以理解为悲观的看待世事，先假定一定会发生冲突，每个线程修改数据前都会先获取锁，从而保证同一时刻只有一个线程能操作数据，从而保证数据的完整性，像Java的Synchronized就可以理解为一种悲观锁
- 乐观锁
乐观的看待世事，每次操作数据前都会假定不会有其他人在操作修改数据，等到自己操作完准备提交更新的时候判断一下在此期间是否有其他人已经更新了这个数据，如果没有人更新过，就直接更新成功，如果有人更新过，就尝试重新获取数据，再操作，再提交更新，如此循环
像Java中的atomic类就是一种乐观锁的实现，通过CAS实现（比较并交换）
| 锁分类 | 举例 | 应用场景 |
|---|---|---|
| 悲观锁 | Synchronized | 并发写操作多的场景 |
| 乐观锁 | atomic | 读多写少的场景 |
Mysql 乐观锁实现
采用增加字段的形式，如version, timestamp字段
更新时将version值 + 1， 将timestamp值更新，并比较该数据在数据库中的值是否与自己取出时的一致，一致则更新成功，否则就表示已经有别人更新了
sql
update table_name set num = #{num}, version = version + 1 where id = 1 and version = #{version}
Mysql 显示和隐士锁
我们知道mysql的InnoDB采用的是类似两阶段锁定协议，即存在显示锁定和隐士锁定两种
- 隐士锁
当我们开启一个事务，并执行update语句时，会锁定当前update条件下的数据，直到commit事务，才会释放掉这个隐士锁
- 显示指定锁
直接利用sql添加锁
select ... where id = 1 for update
会直接锁定该条件下的数据，其他事务再执行该条件下数据的update操作，只能等以上事务提交后，释放锁以后才行
订单号生成具体实现
表结构
其中sequence_key column 字段为年切循环条件，如'2019'，'2020'
sequence_id column 字段表示当前年切循环条件下的自增id值
主要sql语句
// 初始化当前年切条件自增id数据
insert ignore into order_sequence (sequence_id, sequence_key) values(1, #{key});
// 获取当前年切循环条件下的自增id值
select sequence_id from order_sequence where sequence_key = #{key};
// 乐观锁更新当前年切循环条件下的id + 1
update order_sequence set sequence_id = sequence_id + 1 where sequence_key = #{key} and sequence_id = #{sequenceId};
Java代码实现
具体编码细节不作展示，这里给出实现思路
总结
乐观锁的存在并不适合有大量并发写的场景，如果有很多人同时下单，并发更新自增id，就会存在性能问题
其次递归方法如果很深，在性能方面也会存在一定问题
因此，以上实现只适合用于并发量不大的情况，但目前根据我们的业务场景来说时足够了，且代码实现起来较为简单，投入成本较低
