并发是一个让人很头疼的问题，通常会在服务端或数据库端做处理，保证在并发下数据的准确性。
为此，简要讨论一下，如何通过解决全局生成唯一编号的并发问题。
1 MySQL数据库的锁
1-0 锁的分类
- 按锁定的数据粒度
- 表级锁
- 页级锁
- 行级锁
- 按锁定的方式
- 共享锁
- 排他锁
读锁 := 共享锁(shared Lock) / 写锁:= 排他锁(exclusive Lock)
1-1 读锁/共享锁
1-1-1 定义
事务A 使用共享锁 获取了某条（或者某些）记录时:
事务B 可以读取这些记录; 可以继续添加共享锁，但是不能修改或删除这些记录；
否则，当事务B 对这些数据修改或删除时，会进入阻塞状态，直至：锁等待超时或者事务A提交
1-1-2 用法
[表级读锁]
SET AUTOCOMMIT=0;
LOCK TABLES tb_student READ, tb_student READ, ...; -- 加锁
[do something with tables tb_student and tb_student , ... here];
COMMIT;
UNLOCK TABLES; -- 解锁
[行级读锁]
SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE;
1-1-3 注意事项
当使用读锁时，避免产生如下操作
[事务1]
BEGIN;
select * from sys_user where id = 1 LOCK IN SHARE MODE; (步骤1)
update sys_user set username = "taven" where id = 1; (步骤3，发生阻塞)
COMMIT;
[事务2]
BEGIN;
select * from sys_user where id = 1 LOCK IN SHARE MODE; (步骤2)
update sys_user set username = "taven" where id = 1; (步骤4，死锁)
COMMIT;
根据我们之前对读锁定义可知:
当有事务拿到一个结果集的读锁时: 其他事务想要更新该结果集，需要拿到读锁的事务提交（释放锁）。
而上述情况2个事务分别拿到了读锁，且都有update 操作，2个事务互相等待造成死锁（2个事务都在等待对方释放读锁）
1-1-4 使用场景
1) 读取结果集的最新版本，同时防止其他事务产生更新该结果集。
主要用在需要数据依存关系时，确认某行记录是否存在，并确保没有其它人对这个记录进行UPDATE或者DELETE操作
1-2 写锁/排他锁
1-2-1 定义
1个写锁会阻塞其他的读锁和写锁。
事务A 对某些记录添加写锁时:
- 事务B 无法向这些记录添加写锁或读锁;（注：未添加锁的数据，是可以读取的）
- 事务B 也无法执行对 锁住的数据进行update / delete操作
1-2-2 使用场景
读取结果集的最新版本，同时防止其他事务产生读取或者更新该结果集。
例如：并发下对商品库存的操作
1-2-3 注意事项
在使用读锁、写锁时，都需要注意，读锁、写锁属于行级锁。
即 事务1 对商品A 获取写锁，和事务2 对商品B 获取写锁互相不会阻塞的。
需要我们注意的是:我们的SQL要合理使用索引，当我们的SQL全表扫描的时候，行级锁会变成表锁。
使用EXPLAIN查看 SQL是否使用了索引，扫描了多少行。
1-2-4 用法
SELECT * FROM table_name WHERE ... FOR UPDATE
1-3 乐观锁(非数据库锁的逻辑锁) [推荐]
上述介绍的是行级锁，可以最大程度地支持并发处理（同时也带来了最大的锁开销）
乐观锁是一种逻辑锁，通过数据的版本号（vesion）的机制来实现，极大降低了数据库的性能开销。
(此处的版本号仅仅是对逻辑标记字段一种代称)
我们为表添加1个字段 version；
读取数据行时，将此版本号一同读出；
更新数据行时：
- 修改此数据行所在的version: version = version + 1
- 同时，将提交数据的 version 与数据库中对应记录的当前 version 进行比对：
- 如果提交的数据版本号>数据库表当前版本号，则：予以更新；否则，认为是过期数据
update t_goods
set status=2,version=version+1
where id=#{id} and version < #{version}; // 更新前将 代码的#{version} 自增
-- SQL: 先查询(where)， 后修改(update)
或者
update t_goods
set status=2,version=version+1
where id=#{id} and version = #{version}; // 更新前 代码的#{version} 不自增
-- SQL: 先查询(where)， 后修改(update)
2 解决方案
2-1 方案1： [服务器端] synchronize(锁 方法或锁对象) + Java事务(锁定业务流程原子性) [推荐]
@Transnational
public synchronize generateOrderCode(){
...
}
2-2 方案2： 数据库【写锁/排他锁】(锁定多线程/进程的共享数据) + Java事务(锁定业务流程原子性)
维护数据库内1张存储最大值的表，多行；
每一行为过去所使用的历史最大值的记录，最后插入的一行为当前最新最大值所在行。
Thread1 (Lock) 读取表内目标字段最大值Max前，加写锁；（此后，在Thread1未释放写锁前，其它Thread将读取目标字段最大值失败）
Thread1 (Query) 读取表内目标字段最大值Max；
Thread1 (Insert) 插入新增的值————Max=Max+1；
Thread1 (UnLock) 释放写锁；
2-3 方案3：数据库【乐观锁】(锁定多线程/进程的共享数据) + Java事务(锁定业务流程原子性)
类似 方案1，需要区别2点： 1）数据库的锁的变化；2) 维护数据库的行的意义/行数的变化
维护数据库内1张存储最大值的表，1行；
字段等于目标编号业务属性的字段所在的行 即为当前最大值的所在行记录；其它行 为其它编号业务属性的字段所在的行。
2-4 方案4：Redis [推荐]
基于redis单线程的特点，生成全局唯一id，redis性能高，支持集群分片。
亦可实现分布式锁
[核心代码]
思路：日期（yyyyMMddHHmmss）+redis原子生成的数字（不足6位前面补0） / 类似：20191206221953000001
理论上6位后缀支持每秒最多生成999999个订单号，具体可以根据业务调整日期格式或日期后面的位数。
核心在于对象RedisAtomicLong (可以想下juc包下的AtomicLong)，它对于同一个key会一直自增生成数字，这里我设置的key过期时间为20s，减轻redis的压力。
@Resource
private RedisTemplate<String,Serializable> redisTemplate;
/**
* 获取有过期时间的自增长ID
* @param key
* @param expireTime
* @return
*/
public long generate(String key,Date expireTime) {
RedisAtomicLong counter = new RedisAtomicLong(key, redisTemplate.getConnectionFactory());
Long expire = counter.getExpire();
if(expire==-1){
counter.expireAt(expireTime);
}
return counter.incrementAndGet();
}
public String generateOrderId() {//生成id为当前日期（yyMMddHHmmss）+6位（从000000开始不足位数补0）
LocalDateTime now = LocalDateTime.now();
String orderIdPrefix = getOrderIdPrefix(now);//生成yyyyMMddHHmmss
String orderId = orderIdPrefix+String.format("%1$06d", generate(orderIdPrefix,getExpireAtTime(now)));
return orderId;
}
public static String getOrderIdPrefix(LocalDateTime now){
return now.format(DateTimeFormatter.ofPattern("yyyyMMddHHmmss"));
}
public Date getExpireAtTime(LocalDateTime now){
ZoneId zoneId = ZoneId.systemDefault();
LocalDateTime localDateTime = now.plusSeconds(20);
ZonedDateTime zdt = localDateTime.atZone(zoneId);
Date date = Date.from(zdt.toInstant());
return date;
}
Redis在集群环境中生成唯一ID：
https://blog.csdn.net/csujiangyu/article/details/52348003
高并发下使用Redis生成唯一id：
https://blog.csdn.net/heroguo007/article/details/78490278
Redis生成分布式自增ID：
https://blog.csdn.net/chengbinbbs/article/details/80437334
可读性好，不能太长。一般订单都是全数字的。可使用redis的incr命令生成订单号。
优点：可读性好，不会重复
缺点：需要搭建redis服务器
2-5 方案5：UUID 或 雪花算法
uuid生成全球唯一id,生成方式简单粗暴；常用于生成token令牌。
基于雪花算法snowflake 生成全局id，本地生成，没有网络开销，效率高，但是依赖机器时钟。
个人建议： 存储最新值到数据库前，检查此值是否已存储，防止极小概率事件发生
优点：简单，很难很难很难重复(概率极小)，本地生成，没有网络开销，效率高；
缺点：长度较长；没有递增趋势性；可读性差；不易维护；
2-6 方案6：MySQL的ID自动增长
mysql自带自增生成id，oracle可以用序列生成id,但在数据库集群环境下，扩展性不好。
优点：不需要我们自己生成订单号，mysql会自动生成。
缺点：如果订单表数量太大时需要分库分表，此时订单号会重复。如果数据备份后再恢复，订单号会变。
2-7 方案7: 日期+随机数
采用毫秒+随机数。
缺点：仍然有重复的可能。不建议采用此方案。在没有更好的解决方案之前可以使用。