业务系统需要怎样的全局唯一ID.docxVIP

业务系统需要怎样的全局独一ID 2021-03-23 ID 生成器在微博我们一直叫发号器，微博就是用这样的号来存储，而我微博里争辩的时候也都是以发号器为标签。它的次要目的确如平常大家理解的“为一个分布式系统的数据object产生一个独一的标识”，但其实在一个真实的系统里可能也可以担当更多的作用。概括起来次要有以下几点： 1.?独一性 2. 时间相关 3. 粗略有序 4. 可反解 5. 可制造 下面我会分别讲每个作用后面的考虑和权衡，也会对比引见一下业界已知的几种 ID 设计。 1. 要独一性，能否需要全局独一？ 说起全局独一，通常大家都会在想到发号器服务，分布式的通常需要更大空间，中心式的则需要在一个合适的地方在会聚。这就可能涉及到锁，而锁意味着成本和功能的下降。所以当前的系统能否需要全局的独一性，就是一个需要考虑的问题。 比如在通讯系统里，谈天消息可能就未必需要全局，由于一条消息只是某一个人发出，系统只需保证一个人维度的独一性即可。本质上而言，这里利用了用户 ID 的独一性，由于独一性是可以依靠的，通常我们设计系统也都是基于类似的性质，比如后面降到的使用时间独一性的方式。 2. 用时间来做什么？千万年太久，只争朝夕？ 前面说到独一性可以依靠，我们需要选择的是依靠什么。通常的做法可以选择数据库自增，这在很多数据库里都是可以满足ACID 的操作。但是用数据库有个缺点，就是数据库有功能问题，在多机房情况下也很难处理。当然，你可以通过调整自增的步长来设计，但对于一个发号器而言，操作和维护都略重了。 而时间是自然?独一的，因而也是很多设计的选择。但对于一个8Byte的 ID?而言，时间并没有那么多。你假如精确到秒级别，三十年都要使用30bit，到毫秒级则要再添加10bit，你也只剩下20bit 可以做其他事情了。之所以在8Byte 上捣鼓，由于8Byte 是一个Long，不管在处理器和编译器还是言语层面，都是可以更好地被处理。 然而三十年够么？对于一个人来说，可能不够，但对一个系统而言，可能足够。我们经常开玩笑，互联网里能活三十年的系统有多少呢？三十年过去，你的系统可能都被重写 N 遍了。这样的决心同样来自于摩尔定律，三十年后，计算功能早就提高了上千倍，到时候更多Byte 都不会是问题了。 3. 粗略有多粗略，秒还是毫秒？ 每秒一个或者每毫秒一个ID明显是不够的，刚才说到还有20bit 可以做其他事情，就包括一个SequenceID。假如要达到精确的有序，就要对 Sequence 进行并发把握，功能上确定会打折。所以经常会有的一个选择就是，在这个秒的级别上不再保证挨次，而整个 ID 则只保证时间上的有序。后一秒的 ID确定比前一秒的大，但同一秒内可能后取的ID比前面的号小。这在使用时格外关键，你要理解，系统也要接受才可以。 那时间用秒还是毫秒呢？其实不用毫秒的时候就可以把空出来的10bit 送给 Sequence，但整个ID 的精度就下降了。峰值速度是更现实的考虑。Sequence 的空间打算了峰值的速度，而峰值也就意味着持续的时间不会太久。这方面，每秒100万比每毫秒1000限制更小。 4. 可反解，解开的是什么？ 一个 ID 生成之后，就会伴随着信息终身，排错分析的时候，我们需要查验。这时候一个可反解的 ID 可以帮上很多忙，从哪里来的，什么时候诞生的。 跟身份证倒有点儿相通了，其实身份证就是一个典型的分布式 ID 生成器。 假如ID 里已经有了时间而且能解开，在存储层面可能不再需要timestamp 一类的字段了。微博的 ID 还有很多业务信息，这个后面会细讲。 5. 可制造，为什么不用UUID？ 互联网系统上可用性永久是优先目标。但由于分布式系统的脆弱，网络不稳定或者底层存储系统的不行用，业务系统随时面临着失败。为了给前端更友好的响应，我们需要能尽量容忍失败。比如在存储失败时，可能需要临时导出恳求供后续处理，而后续处理时已经离开了当时的时间点，挨次跟其他系统错开了。我们需要制造出这样的ID 以便系统好像一直正常运转一样，可制造的 ID 让你可以把握生产日期（汗，有点儿假冒伪劣的意思了），然后连续下面的处理。 另一个重要场景就是数据清洗。这个属于较少遇到，但并不稀有的情况，可能是原来 ID 设计的不合理，也可能由于底层存储的转变，都可能消灭。这样一个可制造的 ID 就会带来很多操作层面的便利。 这也是我们不用 UUID 的一个缘由。UUID 标准可以保证在某时某地生成，但假如要把握生成一个特定时间的 UUID，可能需要底层库的改动。阅历告知我们，能在上层处理的问题不要透到下层，这种库的维护成本是格外高的。 #设计细节 UUID 就不说了， 其他公开出来的这里说下SnowFlake、Weibo以及 Ticktick