在《分布式服务化系统一致性的“最佳实干”》一文中提出了保证系统最终一致性的定期校对模式，在定期校对模式中最常使用的方法是在每个系统间传递和保存一个统一的唯一流水号（或称为traceid），通过系统间两两核对或者第三方统一核对唯一流水号来保证各个系统之间步伐一致、没有掉队的行为，也就是系统间状态一致，在互联网的世界里，产生唯一流水号的服务系统俗称发号器。Twitter的Snowflake是一个流行的开源的发号器的实现。Slowfake是由Scala语言实现的，并且文档简单、发布模式单一、缺少支持和维护，很难在现实的项目中直接使用。为了能让Java领域的小伙伴们在不同的环境下快速使用发号器服务，本文向大家推荐一款自主研发的多场景分布式发号器Vesta，这是由Java语言编写的，可以通过Jar包的形式嵌入到任何Java开发的项目中，也可以通过服务化或者REST服务发布，发布样式灵活多样，使用简单、方便、高效。Vesta是一款通用的唯一流水号产生器，它具有全局唯一、粗略有序、可反解和可制造等特性，它支持三种发布模式：嵌入发布模式、中心服务器发布模式、REST发布模式，根据业务的性能需求，它可以产生最大峰值型和最小粒度型两种类型的ID，它的实现架构使其具有高性能，高可用和可伸缩等互联网产品需要的质量属性，是一款通用的高性能的发号器产品。本文聚焦在笔者原创的多场景分布式发号器Vesta的设计、实现、性能评估等方面，同时介绍Vesta的发布模式以及使用方式，并在最后给读者介绍如何在你的项目中使用Vesta。为什么不用UUIDUUID虽然能够保证ID的唯一性，但是，它无法满足业务系统需要的很多其他特性，例如：时间粗略有序性，可反解和可制造型。另外，UUID产生的时候使用完全的时间数据，性能比较差，并且UUID比较长，占用空间大，间接导致数据库性能下降，更重要的是，UUID并不具有有序性，这导致B+树索引在写的时候会有过多的随机写操作（连续的ID会产生部分顺序写），另外写的时候由于不能产生顺序的append操作，需要进行insert操作，这会读取整个B+树节点到内存，然后插入这条记录后写整个节点回磁盘，这种操作在记录占用空间比较大的情况下，性能下降比较大，具体压测报告请参考：Mysql性能压测实践报告既然数据库自增ID和UUID有诸多的限制，我们需要整理一下发号器的需求。需求分析和整理既然数据库自增ID和UUID有诸多的限制，我们需要整理一下发号器的需求。需求是所有设计的起始点，一切偏离需求的设计，都是“耍流氓”，下面是...
