149_大厂面试第三季预告片之雪花算法(上)

来，同学们请坚持一下哈，我们再讲一个题目，大场面试题也是高频必考必问的。第三。集群高并发情况下，如何保证分布式唯一注意全局ID的生成？好，那么大家思考一下这个问题是什么意思？好，那同学们安静，刚才讨论了一下呢。各位同学说的都很对啊，那重要的是因为大家都历经过这个前面电商的折磨哈，各种项目金融项目的考验都会明白来。ID注意唯一全局ID的生成，咱们呢，先来看看这个问题，人家考什么？首先。我们这个问题是什么？为什么需要分布式全局位ID以及分布式ID这种生成规则的业务诉求？大家都明白，我们先说个简单的，因为到杨哥这儿呢，大家被我带了练了这么多天都明白。

以前大家嗨的这个东东叫单机版。不废话，你现在说什么？要生成一个唯一的不重复的全局IDUUID对吧？数据库out。指针等等等等，OK，你单机版怎么？嗨，没有任何问题，可现在的问题是你呢？是一个集群。是多机的系统，那出现的一个问题就是它有个东西叫时钟同步的问题，和全局不重复啊。言下之意，兄弟们，以前的单机版里面就是一对一，外面看是，里面看也是，但现在是分布式。多微服务的环境下面，外面看是一个整体，但里面是不是N多啊，那么现在假设。你现在访问那个服务，根据前面我们NS和spring cloud的zoo进行各种的负载均衡，被打到各台机器上面。

好，那么干嘛可能在这儿，可能在这儿，可能在这儿，那么每一台机器，我怎么要保证大家最终要有个全局唯一ID呢？比如说我们进行一次军事行动，大家在行动之前规定好了以后，是不是会产生一个东东叫来。各位战友，我们统一对一下手表上的时间，以我的为准。那么说白了，时钟回拨，时钟调度以后是不是要一样，然后咱们再开始啊，那么在各种分布式系统当中，由于服务器是多台，是集群上百甚至成千的。这样的集群连排部署，每一个机器上面都可能有一个时钟，那么在某种情况下，你这个时间戳可能一样，可能不一样。那么在我们的业务诉求当中，老。我们往往需要对大量的数据和信息进行唯一标识啊，比如说我们讲过的美团，美团点评，它的金融支付，餐饮酒店是不是需要这个生成一个唯一编码号，唯一订单号。甚至我们。

大数据里面介绍过的系统，猫眼电影，那么哪一种产品数据日益增长，我们都需要有一些分库分表以后唯一的ID来标识一条数据和信息，注意唯一性。那么。特别一点的，订单骑手优惠券也需要唯一ID，所以说我们在这个大椭圆里面，这么多服务器部署下来，我们需要能够生成一个全区唯一ID的系统，非常必要。说白了，识别唯一性的标识好。那么接下来这个问题就从软件到硬件，首先从先说软件，就是你需要有一种算法保证，我这第一个你这儿我画的是七台机器有没有可能扩容。啊，那么大家告诉我，扩容了以后，你这个算法生成的规则会不会因为扩容了以后导致大家生成的ID重复了，因为假设你每台机器上都装一个MYSQL，这也是out从一开始啊，一开始撞车了怎么办？

那么好，所以说我们现在呢，先说对我们的诉求。ID生成规则部分的什么东东硬性要求来先说软件算法部分要求他达到东东呢，有这五个维度。第一个，全局唯一。上硅谷有多个Java老师，多个大数据讲师，但是上硅谷的校长CEO是不是只有同钢老师有铁金有一位全局唯一都好理解过一遍，也即不能出现重复的ID号。既然是唯一的，最基本好吧，一个车只能有一个方向盘。当然趋势递增。为什么呢？因为啊，我们一般生成这样的唯一识别号以后，比方说它作为一种唯一标识啊，需要跟人家去对战，那么口说无凭，我们生成这个编号，一般希望将它存进我们的数据库里面，那么以现在主流互联网公司用的大部分都是MYSQL数据库啊，那么MYSQL数据库啊，大部分使用的都是no DB作为默认引擎，那么随着我们的引擎单招，我们前面讲过MYSQL高级据促索引。

句促和非句簇，主键和外键还有索引都讲过了啊，那么多数的都是要用B数的结构来存储数据，那么它趋势递增引后，它生成索引上面也会相当的方便，那么在主键选择上面，我们尽量保证使用有序的主键写入的性能可靠。第三一个单调递增，那么什么意思呢？尽量保证下一个的ID一定大于上一个，我们有时看出它第一个不重复啊，第二个总是比上一个版本要高，这样的话呢，我们去排查的时候好说，比如说事物版本号。消息的对话的增量，消息排序的一些特殊要求等等，那么第四一个信息安全，为啥那你说你每次增个，那假设人家知道了你这个编码号会拆除你以后你也不规则，所以说有点什么呢？恶意繁殖，如果ID是连续，那么用户恶意的爬取工作就特别容易做了。

直接按照顺序下载指定URL，如果是订单号就更危险，竞对就是指竞争对手。几乎就可以知道你一天的业务量是多少来阻击你。所以说在一些场景下，我们需要ID无规则，甚至是不规则，让竞争对手猜不到，不好猜。那么这个时候同学们来看一下，是不是有点发现三四这两个诉求或多或少有点矛盾。你不但要递增，还得让人家猜不到，不好猜好，最后最好含个时间戳，利于问题的排法排查。那么看看这个ID什么时候生成的？OK，那么兄弟们，这就是我们要有一种分布式全局唯一ID的算法部分的硬性要求。

全局唯一递增，单调递增，安全含时间拖好，这是什么？软件算法部分就是你程序要怎么写，就要符合这些维度，那么硬件部分呢？假设你现在是不是应该有一种服务，或者有一台服务器专门是生成这样唯一编号的，它硬件上过不过关，带宽、防火墙、网络，还有它的高并发的处理能力，比如说你现在软件算法程序过关了，但是你硬件上这台机器干嘛？直接各种高并发下来就把你冲垮了，那还了得，蛇无头不行，你现在就假设你这个算法干嘛呢？它的可用性要求就极高，假设你是把它部署在一台买SQL服务器上面，那么这个时候如果它宕机了，你想想现在所有业务就没有唯一编十号了，好比一个人没有头了，走出来吓不吓人？那么所以说软件上面需要有这样的要求，那么硬件上呢？

三个二。搞口药。低延迟和高QPS，那么来，同学们过来，我们要发一个获取分布式的请求，比如说你现在那么多系统，你要发一个分布式请求，好哥们儿，我这儿有这么一个系统。过来。我在外面，我我就是分布式全球国家ID的服务器，硬件算法，就是刚才我们讲的业务规则我都满足啊，每一个请求过来不调我一下，我先生成一个编号，每一个请求过来不调我一下，我生成一个号给你们用，我不能垮它，就像一个水坝一样，三峡大坝要是垮了，下面是不是被淹了，那么这个时候就祸国殃民了，所以说我们要发布一个获取分布式的请求，图中红色部分。干嘛要服务器自身硬件算法软件要符合业务规则，硬件要靠谱，要符合不注意不是四个九，是五个九的情况下，给我创建一个唯一分布式ID，高性能。那么至于什么是四个九，五个九，我们讲过了，不断展开，节约时间。

第二个低延迟干嘛点一下给我生成一个要求是什么毫秒级，你不能是什么三秒钟，给我生成一个扛不住的三秒钟，双11马上要大促开始了。你耽误得起多少。所以说。发一个请求过来，服务器就要快，注意急速啊，最后告Q撇S什么意思啊。你够硬，不容易，倒也很快点一下，一毫秒就给我来一个，或者一毫秒给我来10万个，可问题是干嘛呢？高QPS呀，这个不是一个一个的访问，这个红箭头有一堆啊，一堆人找上你麻烦，那么这个时候干嘛，你这个ID服务器撑不撑得住，所以说干嘛呢，要并发一口气10万个创建分布式的ID请求，同时刷过来，下面兄弟直接给我10万个批出一样的，我点一下给我生成10万个号。

那么这个时候服务器就要顶得住，且一下子成功创建10万个分布式ID。所以说我们的这个问题，全局分布式ID的唯一诉诉求的还是非常复杂的，那么现在到外面去问，他就会问你，那你们是分布式微服务架构的。集群化部署的电商或者金融系统，你们的这个唯一识别号是怎么获得的？因为现在问的问题不再是靠你背。就能答出来。他问的是。要么是比较难的算法与数据结构。要么就是工程落地的实施主流成熟经验，就说我现在给你一个设计体验，我给你个我们工作中遇到的场景怎么解决，偏向于应用题了，说难听点，再去死背死记那些什么a list link list con current map、底层源码。

当然这是基本功，人家也考，但这个说实话只能保证你找到一份工作了，能想拿到一万五到2万之间的高薪。那么杨哥讲的大场面试题第三期现在这些内容，那么希望同学们跟着走好，我们呢继续往下，大家请看，那么在业内我们为了在多个系统之间统一的能够有一个红色的系统啊，这个生成一个唯一的编号，我们一般而言，大家想想我们该怎么做呢？那么来首先先说结论，我们这次啊，主要讲的，因为一般在外面哈。主要用的一个东东呢，叫S雪花算法。答案，面试官一听这个就应该知道你们公司还是靠点谱，用的东西还是主流成熟稳定的，这个决定了他想不想继续跟你聊下去，那么接下来他就会问你，你们公司为什么要选这种算法，谈谈你这种算法的理解怎么演变过来的，你了解过吗？好，那么。

首先先了解一个名词like雪花算法，那么接下来我们来看看。从单机版到集群的话，一般这种全局式分布式ID，它的通用解决方案来。在雪花算法之前，我们呢，一般可以用UUID。那同学们这个UUID我觉得不用我多说了吧。想一下。好，那么同学们呢，说的都很对，那部分同学呢，我最后来一遍，那么大家都明白哈，我们这是不是有有个叫u idea，没问题吧，Run to string，弟兄们，这个时候你懂的。我直接一运行了以后，它是不是生成一个多少啊，32位的一个字符串啊，那么好给它运行一下。来同学们请看一下这个UID，那么大家请看，就是中间带这些短线的是吧，多少多少多少位，那么这个呢过来。

那么首先这个UUID什么鬼？大家看32位的16进制数字，以零字号分五段，分别是八、四、四、四、幺、二、36个字符，那么同学们，这个我们用过多次了。复习一下也不展开了，好吧，一般呢，直接弄这个。他肯定是you idea。干嘛？不重复好处，本地生成的没有网络消耗，而且根本就是JDK自带的。那么，如果你只是为了唯一性，这哥们儿绝对足够够用了。不用去再去研究后面的了，可问题坏就坏在什么，懂不懂呢？我们考虑唯一性的话，它OK了，坏就坏掉，我们产生如果用UUID产生了这么一个东东，兄弟们，你很多编码，很多数据，假设这个就是个订单编号，你是要存进数据库的。不是不是什么，它带不带个减号，这个减号我们可以用replace把它去掉嘛，对不对，关键是它无序，听懂了吗？那么这个时候导致什么呢？它入数据库的性能比较差，我们讲过了，最好ID自增了以后，我们买SQL数据库的B数索引，是不是它那个数生成的它会更好，那么你的入库性能差是什么意思呢？

来，同学们。一点点过来。首先无序，无法预测UUID的生成顺序，不能生成递增的有序数字啊，你可别忘了前面上一讲，我是不是讲了我们要生成全局危机ID的业务诉求是不是要有五个，至少是不是有个什么趋势递增吧，但是它是无序的。那么这个时候首先。我们一般会用分布式的ID作为一种主件，比方说订单编号等等。但是。买这个官方推荐这个主件，越短越好，U用ID是唯一性了，不重复啊，但是每个都很长，是32位啊，不是很推荐第二个拿UID去杠主键的话，它在特定的环境中会存在一些问题，什么意思呢？我们如果你非要拿它做主件，我们请看一下MYSQL官网上它的原话。

巴拉巴拉这么多，以前我讲买斯克高级的时候详细讲过，这些不展开了，我们这儿由于是讲落地的面试题和工程解决方案植入主题，请看最后一句，如果这个主键是长的，那么这个secondary index将会用更多的空间，所以我们干嘛？强烈推荐用优势化的，这种使用的话，用短的东东来做数据库的主件，但它是多少，基本上是30多位，那么所以说不合适啊。最后坑爹的，由于你要是拿这个UID，因为你存到库里面嘛，你要去做主件，那么大家请看接近36位连上这个短线，但是一般我们会把这四个用replace方法给它去掉，这么说OK，所以说一般我们存到数据库是32位，那么。

干嘛呢？既然分布式ID是主键的话，然后主键是包含所引。我们前面讲过，MYCQ是通过B加数来实现的，每一个新的idea为了查询优化都会对索引进行修改，那么图书馆里面每引进了一批书，新添了1万本书，那图书馆的那个索引系统是不是要更新？但是由于你这个UIID是无序的呀，所以每次呢？都会对这个B数进行很大的修改，这一点很不友好，所以说导致插入完全无限就会导致。MYSQ的原有的B数产生节点分裂情况，这个索引不好见，那么创造了很多不饱和的节点，我们讲过这个动画片了啊，不展开了，因为现在呢时间很紧张，B加数杨哥上一讲全面详细讲过，不再用动画片展示了，所以说这样呢，由于你是。

第一个长。不合适做主件，第二个我们要流通库里面都希望拿这个唯一编号做主件的话，将会导致索引分裂，那么大大降低了数据库的插入性能。所以说UUID。可以参考，但不合适啊，你做个单机版的话，就是说你自己还自娱自乐用可以，生产上不推荐不许用，甚至。那么第二种，那么干嘛呢？那么再看看我们的业务诉求，一定重要的是按照业务来决定技术，首先软件要求的硬，它的软件要求趋势递增，单调递增，全局危机等等，那么好吗？而且还要保证数据库，那么我用数据库的自身组件，这总行了吧，那么来，兄弟们。先从单击再到集群分布式，先说结论，单击可以，但是集群分布式呢，又出现看跌情况，那么下面我先暂停一下录屏，我把数据库打开给大家演示啊。

好，我数据库呢。打开。兄弟们，我们现在。随便找个库哈，就消息中间这个库吧，SMQ，我们这儿干嘛呢。那么。以前我们单击是不是自增的时候，同学们都会，呃，有明白我们这儿写的是不是out to increase。接下来这个问题哈。看着UUID已经被我们否了，我们写一下。那么UUID，它可以解，但是只有唯一性。那么其他的那些什么趋势。递增，还有干嘛呢。包括。我们的前面这些含时间戳等等的话。说难听点就是这五个运行要求，我是给他拷过来吧，同学们。

那么。它除了只满足第一个以外，其他都不具备，那么到我们这个MYSQL，我们看看它。又来解决什么问题呢？我们进一步，那么好吗？MYCQ的递增没问题吧，一点一下，从MYCQ里面拿个数字加个一，相当于每次做一个。哎，佳佳。那么来看一下单机版的MYSQL，如果你在分布式环境里面，你这个红色的菱形哈，就是这个分布式ids从数据库拿过来的，我们看看首先可不可行。第一个他的原则呢。是通过数据库自增的ID和MYSQL数据库的replace into来实现的。刚才停了一下，给班上同学们讨论一下，好多同学都是用auto的自增，那是肯定不不OK的，再次强调，那叫helloard教学DEMO，但是到生产上，一定你要从数据库里面拿自增ID，尤其分布式里面，假设你现在假设你也是个分布式系统，但是你并发量真的很小。

哎，那么你用一个数据库来做，可解就是小厂你用这种方法基本上也够了。但是呢，我们逐步从小产到中产到大产，给大家演示啊四个阶段啊。你自己自娱自乐，Hello word版本用个UUID可以，如果你是个什么50个人以内的小公司啊，你的并发量也并不高，那么我们到了第二步，用MY。自增ID和MYSQ的replace into来实现么？过了它干嘛的呢？这个replace into给大家说一下，它跟insert差不多，那么它不同点在于就是这个时候配into的话呢，你看说配什么叫替代，首先先往数据库里面插，如果已经有什么。重复了就是说，比方说数据库里面已经有一个。数字了，就跟我现在要插入去的这个一模一样，那么就先删除怎么着再插入，否则直接查询数据没有，我查个新的，有了，要replace取而代之，所以说叫replace to，那么它干什么呢？

它的含义最终一句话就是，如果表中唯一索引的值遭到冲突了，直接替换老数据。好，那么理论是这个意思啊，说白了就是。没有直接先插入，有了替换好，那么兄弟们直接给大家先演示啊，那么你在分布式环境当中，数据库啊，不再是用那个auto equipment，那是单机版分布式的BYCL，首先我们在这先建这么一张干嘛表，那么来同学们。直接过来节约时间，这些都不废话了，直接拷过来。那么干什么呢？大家请看。现在idea。

Stop，存根现在表已经建好了，那么请看它就只有一个自增的ID和一个数值啊，然后大家请看我，Place into value是B，随便啊，这你写什么都可以，那么请看啊，同学们。我直接在这儿，我一。执行，根据刚才我们的说法，现在上一次我们查了以后它是空，这是首次执行，肯定会有一条记录被插入，那么请看E。B，那么大家请看我这儿规定的是什么意思啊？唯一索引是不是这个在上面建了个唯一索引，那么如果我第二次再去插这个B的时候，说明系统里面已经有了，那么它将会把这个系统里面干什么给干掉，再重新插入一条，这样是不是导致这个ID值就往上增了一步，那么大家请看我们现在执行了一次啊，再来选这个，请看上一次插入的ID。多少是不是一，为什么？因为我们现在执行了这么一次以后，这是不是有个一，也就是我上一次插入的这个ID就是一，那好同学们，假设我这个现在我两条一块执行，请看啊。

如果我第二次啊，执行这个。干嘛查询这个两行受到影响，为什么我要去查这条已经有一个B了，我要先删掉。然后再插入，那么这个时候请看同学们，我们第二次的时候，它的值是多少。是二，所以说我现在只要建了这么一张表，每次执行这样我从数据库里面拿过来的肯定是递增大且唯一的，那么这个时候是不是比UUID。要好有有ID。只能解决唯一性，但是现在我们的MYCQL兄弟们来了，我们干什么呢？它是不是唯一性？肯定的，那都不用讲，弟兄们，我这是不是unit t干嘛？唯一索引给你建好了，并且还可以递增，那么大家请看。

这个时候是不是要比UUID更加的合适和优化，那么来同学们，我们多执行几次给大家看一下啊，大家请看是不是三四五六七八九十不会重复，所以说在分布式环境。你可以用这样的方法，小厂里面叫并发量不高的情况下，你用这个用MYQ过来干，获得一个唯一全局ID，可以因为这些这些方法哈，都没有绝对的错和对，看你的业务场景脱离。业务去谈技术都是耍流氓，小厂用这个足够了，假设你并发量不高的话。那么接下来我们看这些都给大家，到时候呢。整理好了直接去执行，工作中都能用，那么接下来我们要一个问题是。单机倒是可以的，但分布式的这样一个勉强够了，那么如果说我们就拿这个方案去搞定。

我们的。电商金融系统行不行呢？答案是不可以，为啥你现在首先在这台买CQ上面你只有一台，这哥们挂了怎么办？那么这个时候说明什么？对于这样的ID服务器是一定要用集群的，否则你只要死了一个，你所有ID都获不到。比如说我们现在要去查一下我的身份证，是中华人民共和国公安部的系统，现在公安部的系统宕机了，不能查身份证了，那么你想想这个恐不恐怖，坐飞机坐火车都很可怕，那么接下来我们来搂他一眼，为什么？BYCQL还是不行呢，别忘了，你就算软件满足了硬件呢？我要求你这个买SQL服务器，高可用低延迟啊，最恐怖的是有个什么东东叫高QPS啊，兄弟们，你现在一台机器，我现在一秒钟，我要求你买这个，给我生成10万个ID。他这个时候他就扛不住了，因为大家都明白。

如果马赛克的并发性真那么厉害的话，为什么我们在前面要挡着一层叫啊？所以说我们这儿得到一个结论。那么如果说我们数据库的自增ID机制啊，是和replace是否做ID。分布式ID，答案呢是没有说对错，我们说的是合适的问题。那么也不太合适啊，第一个你不可能只用一个单机买车票，你就必须要用集群，可问题是今天随着你的业务扩张，你是一台买色票，明天是两天，后天是四个，大后天是六个，那么导致一个什么问题？来系统的水平扩展比较困难。I要定义好步长和机器台算，你要去算那么第一台机，假设现在你只有这台机的发号是12345，不长时间，这个话倒是好说，你单机就是12345，可问题如果说是你为了避免单机。号码系统故障，你必须是MYSQL集群啊，会不会那么第二台机器也是从一开始增长吗？不合适啊，那么这两个你一定要设置一个步长和号码间断，否则这台机器的增长要是追上下一台了怎么办？是不是导致IID号冲突，那么你要设置这个什么号速和步长就不是OK，这个时候你扩一台机器倒是好说。

只需要把第二台的机器设置只比这台超很多就行了，比方说第一台我就干到多少9999999。第二台盖过它，但是问题如果我们现在不是两台，是100台机器这种横向扩容呢，那么。非常恐怖，买这个的分表分库扩容是不好做的，你就为了生成个ID。要赔进去至少半个DBA，那人家干吗？再来。数据库压力大呀，别忘了我们这儿有一个硬件要求是什么鬼？高QPA低延迟，你买这个并发性上来了。它沉不住，否则我们不会要学一个技术叫red，所以说呢，导致一个问题，我们过来看，在这儿出事了。

每次获得ID第二读写次数，数据库兄弟们。Replace select是不是一写一读，那么相当于说请看啊，别忘了我们刚才我这执行这一段话时几行两行，所以说这个时候兄弟们非常影响性能，不符合我们的高QPS啊。所以说高并发下面如果都要去数据库里面拿ID，还是影响性能的，那么再次强调不太合适。大中型项目，但小厂你可以用数据库。Replace特和自增ID来解决，那接下来。并发性。牛逼的谁呀？是不是还可以过来用呀？没问题，那么接下来兄弟们想想，给大家思考一下。我们的数据库啊，MY用的是insert和replace和replace into，那么我们的想一想它的特点是什么？怎么用它来做全局ID的生存策略呢？思考一下。

来，那么同学们，我们一边讨论一边复习，首先哈，还是要结合我们的业务要求和系统要求来。通过业务来决定我们的技术选型。再次强调，现在大场面试题到高级部分，它不再是考这个方案。正不正确？一还是零，他看的是你的技术选型思路和你工程落地的方案选择背景，你为什么要选这个？那么接下来。知其然，知其所以然，首先哈。在red5.0之前哈，因为我看过文档，好像red6.0出来以后，Red开始已经支持。多线程的，注意我们目前讲的red都是单线程的，明白吧，这是red的根本为为什么快，其中有个它单线程的，那么这个时候我们这儿有个问题。

因为是单线的，天生保证什么线原子性，所以说我们可以使用原子操作increase和increase by，那么这个默认是这个时候来决定不查。杨歌的大家都听过了，一九版的。不多废话，更多高级命令和底层的解析大家都知道了，那么你用red来做回答我上面这些什么？危险，第三，安全高可用，哎呀，Red天生更加适合，这个比MYSQ更适合。所以说我们的技术选型，你要告诉人家你一步步怎么来的，大厂的经理他想听的是从零。到十这个过程错而不说问你说这个问题见没见过，见过我们那个订单号都是用雪花算法，好，最终答案是雪花算法那。

别人一背他也懂啊，那下面的问题是你们怎么考虑用这个的？有这么多ID都可以生成，你为什么要用循环算法？说说其他方案，那么这个时候你答的比别人更广更深，更细，更加。经验上的陈述更加有血有肉，那么兄弟，这个我法才能到你手头上。而且现在。Java程序呢，越来越呢是。拒绝初级选手，就是你只会做增删改，查API调用工程师啊，没什么机会啦。差不多这辈子可能也就是1万到12000，但是如果你是能够做分布式微服，高频发，高可用，高性能这样的。系统，那么弟兄们，差不多我们也看了前面学长的工资条了。一万五到2万也不是什么新闻了，那么关键还是技术说话，那么接下来我们not year，由于red啊，要去启动Linux啊，那么比较麻烦，我就不像MYSQL这样给大家演示啊，那么首先如果老规矩单机版你就用这个increase和increase来实现，那么如果说我们是分布式环境下面的这种集群版呢？

你用也可以来做，但还不是最好、最优秀、最合适的，理由如下。第一大问题。同样和买一样，设置需要不同的增长步长，并且RA还牵扯到一个key的过期时间，默认是不是永不过期啊？好，那么过来可以使用集群来获取更高的吞吐量，因为我们说要高并发，高可靠和高QPS啊，那么单机版的red的性能绝对不如集群，所以说这次的部署也肯定是red集群，那么集群多少台，每一台它的增长部长你怎么设又来了？第二个问题，那么过来吧，我们来给大家做一个简单的演示啊，如果说我现在为了这个红色菱形这哈，那么干脆这块我把它划掉吧，可能画的有点太哎。

画的有点儿太乱了哈。那么兄弟们，我们在这的话呢，直接把这块划掉吧。假设哈，弟兄们现在都应该明白我这个意思，反正哈，那么我们这要有一个分布式ID的系统，那么反正弟兄们你要给我用分布式ID，你就要通过它获得。那么现在我们。怎么落地呢？用的东东叫red集群来干，那么集群你部署几台？假设我们有五台，因为单机肯定不如集群嘛，我们要高吞吐量，高QPS干这个集群每台red值分别是12345，然后步长都是五，什么意思啊？那假设兄弟们第一台red从一开始走。它的increase by是五，第二次是不是就到六，第三次是不到11，那么所以说我们的第一台机器就是幺六十一，16 21，每次增补。

那么第二台机器的增长呢，以此类推，干嘛就从二开始，二加五是不是七，七加五是不是12，那么大家请看我这台机器这边是生成的是11，你这边机器到我这儿是生成12。我们把。345打开，大家请看，竖着看五台机器的集群是不是一二三四五六七八九十十一十二十三十四十五回答我这样ID是不是在red舞台集群里面设置不长是我是最经典的一个成熟解决方案，换句话说，你从red集群当中拿到的ID单调递增，趋势递增，全局唯一高并发什么什么什么的是不都满足了，所以说一般的。中小产用red集群也可以获得分布式全局唯一ID，这个是可行的，可落地。

且有公司实践过。但问题是。坏处是什么呢？越是高精尖，越是安全的落地技术方案。那么我们的维护保养是不是就比较麻烦？它唯一的缺点是什么？配置麻烦，维护啰嗦一句话，现在哥们儿我就想。要一个全局唯一ID。但是你却要给我干出来的幺蛾子呢，是维护一个red集群啊，兄弟们，五台机器，那么中间red集群要设置它避免单点故障，那么又要设置它哨兵值无人值守，某一台弹了又怎么样好等等等等，那么这个时候说明什么，我为了一个一，我要去付出十啊，而且还要引，如果我的系统里面我并不需要用red，我为了生成订单号，唯一标识全球ID，我要引入一套red体系，那这个是不是也比较麻烦，那么所以说这三者。

是目前主流的生成方案，有有idea MySQL。Replace英特尔和ID自增和基于red的集群生成，ID都可以落地，但是各有优缺点，尤其red呢，是属于什么呢？费事，我依赖于第三方red系统集群环境的搭建和搭配，而且设置不长的话也挺。繁的中间一台机器断了以后，负载均衡永远只达到ABC这几台机器导致一个什么问题，这可能有些号就不连续了。好，那么接下来我们来看看。你跟。面试官说到这儿了以后，说明你对这个问题有过深入的思考，那么接下来你要推出来。那么因为。各种找嘛，现在大家都喜欢听是吧，技术的演进，你们要找了各种方案，他也想听听，因为他通过面试也看看你有哪碰到哪些坑，那么哪种方案好，哪种方案不好，你给我说出个道道来，说出123，证明你有工程落地经验。

而不是只会增强改差，那么接下来red完了以后，终于，那么我们呢？来到了我们今天的重点，下半场来说一下雪花算法。