奇怪的需求
业务开发过程中总能遇到各式各样的需求，比如这个：业务编号生成。
生成业务编号是如下格式：BZ000001、BZ000002，其中BZ是业务前缀；要求递增且连续。
解决方案
看了前人的代码，采用了一个比较骚的方案: mysql的自增主键来实现，可能是考虑到实现时间&业务场景，业务上qps极小。
实现过程如下：
先把记录insert进表，获取记录的自增主键，再拼接上业务前缀，进行update。
本质上，一步操作拆两步。
怎么抗？-第一个坑来了
大家也很容易想到，上面那个方案，在批量新增情况下，效率奇差。
比如产品增加了excel导入的需求。怎么办？
那只能接下这个锅，对方案进行改造。
最直接的方案是使用redis，利用incryBy命令实现线程安全递增。
领导说不行，redis是咱们自己搭建的sentinel集群，宕机数据恢复问题不好解决。
那就先用mysql做一个方案：单独用一张表存放id使用情况，记录已使用的最新的编号。调用者获取该业务的记录，在内存里计算要使用的最后一个id，然后回写最后1个id至该表。
流程如下：
考虑到，峰值qps也就10左右，单个请求响应约70ms，1s的延迟可以接受。
扩展
由于是低流量业务，方案已经满足要求。
但如果流量稍微增长点，比如峰值qps到1k，系统应该如何设计？
要想数据不丢失&性能较高，那就只有使用redis，通过数据一致性弥补redis的可靠性
