京东面试题–有一个生成唯一串的需求，并发请求量非常大，该如何实现?

个人记录：2018年，工作的第6到7个年头。
重点研究自己不太擅长的技术：分布式、高并发、大数据量、数据库优化、高性能、负载均衡等。


京东面试题 – 有一个生成唯一串的需求，并发请求量非常大，该如何实现？


多个机器，多个JVM，要生成唯一串，并发量非常大，该如何实现？
面试官说，他们是借鉴表锁和行锁实现的。


问题源头：http://ifeve.com/question/%e4%ba%ac%e4%b8%9c%e9%9d%a2%e8%af%95%e9%a2%98-%e6%9c%89%e4%b8%80%e4%b8%aa%e7%94%9f%e6%88%90%e5%94%af%e4%b8%80%e4%b8%b2%e7%9a%84%e9%9c%80%e6%b1%82%ef%bc%8c%e5%b9%b6%e5%8f%91%e8%af%b7%e6%b1%82/


个人看法
在电商系统中，尤其是双11当天，秒杀高并发。
需要一个单独的订单号生成服务，据说是因为数据库的自增性能比较差。
其中，在 高并发订单系统架构设计（二） http://blog.csdn.net/FansUnion/article/details/79621049
这篇文章中，网友提到了1个算法：
这里采用Twitter snowflake方案，全剧唯一ID生成由：时间戳+机器ID+自增序列（+userid后两位）； 
订单的生成过程直接在应用实例中生成，直接在内存中计算，且计算过程分散到每台应用实例中，解决性能问题，userid后两位在后面解释。




唯一串格式：时间戳+机器ID+自增序列


时间戳：System.currentTimeMillis();
机器ID：每台机器有自己的ID，集群ID+机器ID。（可能存在集群）
自增ID：数据库/Redis维护1个ID，每次系统启动获得最新的ID+1，缓存到Redis中。Redis中的增长序列，不断增加。
数据库中是否需要维护最新序列，是个问题？
只要不是极端情况下，当前机器的时间是不断变化的，系统每次启动，都使用最新的自增序列，比如1开始.
万一当前机器时间还可能一致，需要把Redis中的增长序列持久化到数据库中，比如10秒中，保存一次。
如果在间隔的情况下，机器重启。重启前Redis数是12，数据库可能是10。自增序列从11开始，存在重复。
这种情况下，时间还会重复吗？


提供一个分布式唯一服务
public class GlobalUniqueStringNoService{


    public String makeGlobalUniqueStringNo();

}  


多机器多JVM，如果需要使用，直接调用RPC分布式服务。
如果请求量过大，要么加机器，要么使用缓存。
缓存分2个地方：
方法1：缓存在消费者调用方，提前缓存1000个。每次消费，从池子里取。定时任务，定时调用RPC接口，向池子的末尾放。
方法2：缓存在服务者提供方，提前缓存1000个。缓存池，和方法1类似。


关于“面试官”的观点
“借鉴表锁和行锁”，应该是没有使用数据库的表锁和行锁，而是借鉴了他们的原理。
具体是怎样的呢？
真不太清楚。


网友观点


一、ip+进程号+当前时间(精确到纳秒)+计数器（每次批量生成串的时候重置计数器为0），由定时检查队列的线程批量生成后放到队列（可以采用LinkedBlockingQueue ）中，一秒种检查一次队列中的串数量，队列大小可以设置为指定的数量，当队列中的串数量低于多少时，往队列中追加新生成的串。获取串的线程访问由队列控制即可。
思路：
1、生成串由单线程批量生成。
2、并发获取的线程由队列（队列采用链表的阻塞队列实现）进行控制。
 
串的生成格式：ip+进程号+当前时间(精确到纳秒)+计数器（每次批量生成串的时候重置计数器为0）
可以解决，多机多JVM实例的问题，计数器可以解决时间相同的问题


二、唯一串的格式：集群编号+机器ip+jvm进程号+线程编号+时间+计数器
如果上述还达不到性能需求的话，那就将上述生成的串池化（形式多样），各集群全部运行起来不停的生成串，供消费者调用。
实现上，可以单独部署这样的集群，提供服务；也可以就部署在应用服务器上，本地获取唯一的串。
如果上面还满足不了，那就加机器。