基于指标阈值的弹性机制：对于超出预期的业务流量突增，可以设置基于指标阈值的弹性策略，根据 CPU 、内存等资源指标，以有 QPS 等业务指标让应用实现自动的弹性缩。
通过多种弹性机制，能够对系统容量进行精细粒度的管理，使资源的使用量能随着业务流量的变化而调整，从而极大程度的增加资源利用率，大幅降低资源成本。
面对这种全球性跨地域的分布式系统，我们不得不谈到CAP理论，为了能够多中心全量数据提供服务，Partition tolerance（分区容错性）是必须要解决的，但是根据CAP的理论，Consistency（一致性）和Availability（可用性）就只能满足一个。对于线上应用，可用性自不用说了，那面对这样一个问题，最终一致性是最好的选择。
最高位是符号位，始终为0，不可用。
41位的时间序列，精确到毫秒级，41位的长度可以使用69年。时间位还有一个很重要的作用是可以根据时间进行排序。
10位的机器标识，10位的长度最多支持部署1024个节点。
12位的计数序列号，序列号即一系列的自增ID，可以支持同一节点同一毫秒生成多个ID序号，12位的计数序列号支持每个节点每毫秒产生4096个ID序号。
适用场景
适用于int32类型的Id分配，单个区域内容量上限可评估的业务使用。
集中式分配算法
1）算法说明
集中式可以是Redis，也可以是ZooKeeper，也可以利用数据库的自增Id集中分配。
通过DRC的拆解，数据库操作有三种：insert、update、delete，这三种操作不管哪两种操作都是不能满足交换律的，会产生冲突，所以我们在并发级别（主键）加上额外信息，这里我们采用序号，也就是2中提到的染色的过程，这个过程是保留的。
而主键之间是并发的，没有顺序而言。当接收消息的时候我们并不保证强顺序，采用LWW（Last Write Wins）的方式，也就是说我们执行当前的SQL而放弃前面的SQL，这样我们就不用考虑交换的问题。同时我们会根据消息的唯一性（实例+单元+数据库+MD5(SQL)）对每个消息做幂等，保证每个SQL都不会重复执行。而对于结合律，我们需要对每个操作单独分析。
update操作天然满足结合律。但是这里又要考虑一种特殊情况，那就是执行结果为0。这说明此语句之前一定存在一个insert语句，但这个语句我们还没有收到。这时我们需要利用这条语句中的数据将update语句转成insert再重新执行一次。
delete也是天然满足结合律的，而无论之前都有什么操作，只要执行就好了。
在insert和update操作里面，都有一个转换的过程，而这里有个前提，那就是从DRC拿到的变更数据每一条都是全字段的。可能有人会说这里的转换可以用replace into替换，为什么没有使用replace into呢，首先由于顺序错乱的情况毕竟是少数
