在单机数据库领域，我们为每个事务都分配一个序列号，比如Oracle的SCN(SystemChangeNumber),MySQL的LSN(LogSequenceNumber)，这个序列号可以是逻辑的，也可以是物理的。我们依赖这个序列号对系统中发生的事务进行排序，确保所有事务都有严格的先后关系。数据库中所有的事务都按分配的序列号排序，对于任何时间点发生的读，保证能读到这个时间点之前的提交的事务，并且读不到之后发生的事务。所以，一般来说，无论系统中序列号是逻辑还是物理的，都与真实的物理时间有一个对应的单独递增关系。在单机数据库时代，这个相对容易做到，系统中有一个唯一的序列号分配器，保证有序。
来到分布式数据时代，一个数据库系统不再只有一个节点可以处理事务，多个节点上发生的事务如何保证有序是本文想要讨论的问题。最简单的想法是，我们在数据库系统中专门添加一个组件，这个组件作用就是分配时间戳，付出的代价是，任何一个事务提交，都需要有一个网络RTT的消耗，并且分配时间戳的组件是整个系统的单点，可能成为系统的瓶颈。实际上，目前主流分布式数据库系统还提供了两个可选方案，一种是Spanner数据库的TrueTime机制，另外一种CockroachDB数据库的HLC(HybridLogicClock)机制。
HLC机制先说说HLC的由来，我们前面提到分布式数据库中，要为每个事务都分配一个合理的序列号比较麻烦，实际上这不单单是数据库的问题，还是所有分布式系统中的共性问题，如何为系统中发生的事件排序。既然各个节点的物理时钟不一致，不如都采用逻辑时钟(LogicClock)，逻辑时钟只保证因果一致性，即不保证全局有序，只保证有先后顺序的事件有序。哪些事件有先后关系，主要包括两类，1.单节点内部先后发生的事件；2.节点间有通信的事件，发送消息的节点一定早于接收消息的节点。由于分配的序列号与物理时钟完全无关，真实时间无法与序列号对应，导致无法用于实际的生产环境。HLC源于LC，是对LC的改进，同样是保证因果序，但引入了物理时间戳作为序列号的一部分，这样能与物理时钟对应起来，采用物理时钟+逻辑时钟混合的方式作为序列号，提供一种事务序列号的分配方法。
接下里我们看看HLC是怎么实现的？HLC分配算法很简单，源于[论文](https://cse.buffalo.edu/tech-reports/2014-04.pdf)。
