通常情况下，一个应用可以直接使用数据库的自增主键 ID 作为生成方案，这种做法既方便又通过数据库唯一约束避免了 ID 冲突的问题。但这种具有连续性的ID会暴露平台的数据量，并且在数据量过大进行分库分表后，就无法依赖数据库的自增 ID 作为生成方案了。如何在这种情况下生成一个全局唯一的ID呢？
Java基础——JVM
Java 是高级语言的其中一种，要把高级语言转换为计算机可以识别的机器码需要经过解释或者编译处理。编译的过程就是通过编译器把高级语言代码翻译成可以被机器执行的机器码（如C语言），解释的过程就是通过解释器直接解释执行（如PHP、Javascript），不需要编译成机器语言。但是现代高级语言很难简单的用“编译型”、“解释型”来区分，代码执行过程中并不是只有其中一种行为。
在 Java 中，为了实现跨平台以及提升运行速度，需要先将源代码使用 javac 编译成 Java 字节码，这个字节码并不能被计算机直接识别，需要使用 Java 虚拟机 JVM 来解释执行。JVM 在解释执行代码的过程中，如果发现某个方法或代码块运行频繁，会认为这是热点代码（Hot Spot Code），被标记为热点代码的部分在运行时被动态地编译程序（JIT）转换为本地机器码，以便直接在CPU上执行，而无需再次解释执行。除了 JIT 之外， JDK17 支持的 AOT 编译也可以直接将 Java 代码编译为计算机可以直接识别执行的机器码。
ElasticSearch文档
不同版本的 ElasticSearch API 可能有所区别，本文基于 7.17 版本。
文档在 ElasticSearch 中是一个可被索引的基础信息单元，与关系型数据库中的一行记录类似，也就是一条数据。
ElasticSearch分页查询
Elasticsearch 是一个分布式的搜索与分析引擎，它的部分使用经典场景与关系型数据库（在本篇文章中以 MySQL 举例）非常相似，比如分页、遍历等。
在分页场景下，数据库需要遍历全表读取，然后根据参数跳过舍弃指定条数的记录，最终返回数据，在页码较大的深度分页场景时，数据库的响应时间较长，且会占用较多的服务器资源。Elasticsearch 中也同样如此，Elasticsearch 会聚合、遍历整个索引读取文档，然后舍弃指定条数的文档，最终返回数据，此过程也将占用较多的服务器资源。因此不管是在关系型数据库中还是 ElasticSearch ，在分页场景下应该尽量避免使用普通的分页查询进行深度分页读取较后的数据。
ElasticSearch数据类型与映射
不同版本的 ElasticSearch API 可能有所区别，本文基于 7.17 版本。ElasticSearch 有三个重要的概念，索引、映射、文档，本文介绍 ElasticSearch 的映射。映射是用来用来定义文档及其字段的存储方式、索引方式的手段，与关系型数据库中的表结构类似，可以从映射信息中得知索引下有哪些字段，字段的数据类型以及有哪些约束信息。
ElasticSearch索引
ElasticSearch 有三个重要的概念，索引、映射、文档，本文介绍 ElasticSearch 的索引。不同版本的 ElasticSearch API 可能有所区别，本文基于 7.17 版本。
ElasticSearch集群搭建
在生产环境中使用 ElasticSearch 时，一般会使用集群模式（分片+副本）提高服务的可用性，另外，集群部署相对于单机部署有更多的存储空间，可存储的数据量更大。
那些有趣的数据结构——BitMap
在开发的时候，时常会遇到去重或者校验是否存在的需求，在 Java 中当数据量小的时候可以直接使用 Set 集合进行去重或者校验存在，但数据量逐渐变大的时候使用这种去重策略可能会导致内存溢出的问题，可以根据数据的特性决定是否使用 Bitmap 解决相关需求。
Zookeeper Cluster
Zookeeper 提供单机和集群两种搭建方式，在生产环境中通常使用集群部署的方式来提高可用性。其作为分布式协调服务，应保持数据的一致性。
Zookeeper 集群是一个 CP（一致性+分区容错性）的分布式系统，任何时刻对正常工作的 Zookeeper 集群的任意节点发起的请求都尽量得到一致的数据结果，对于Zookeeper的操作是原子性的，只有成功和失败，不存在只产生部分结果的情况。