在之前的文章中，我们提到了Shard支持Key映射的特性，通过这个特性能够支持对序有需求的应用场景。今天我们给大家介绍一个在削峰填谷或流量突增情况下的功能：弹性伸缩。在生产中我们往往会面临峰值和低值的情况，也会遇到因业务层映射不均衡，导致某一个分区（shard）有非常大流量的场景，弹性伸缩（Merge/Split）就是为此设计的利器。

使用弹性伸缩的应用场景

场景1（视频类）：根据峰值、底值弹性扩容，控制成本

用户A是一个视频类网站，晚8点-22点是一天的高峰，会产生大量的点击和访问日志。小A使用日志服务一个logstore进行点击日志收集与消费。

• 在白天时使用一个Shard（Shard0）分区（写5MB/S、读10MB/S）
• 当晚间高峰时对该分区进行分裂（Split），分区变为2个分区Shard1，Shard2服务能力（写10MB/S，读20MB/S）
• 当高峰期过后，通过合并（Merge）将两个分区调整一个分区的服务能力(Shard3)，以控制成本

场景2（日志保序处理）：将不同实例映射到不同分区，调整分区处理能力

用户B是一位程序员，通过日志服务logstore采集数据库节点日志。小B管理的数据库有大有小，大的每分钟产生1MB/S 数据，小的也就0.5 KB。由于数据库日志是需要保序处理的，因此小B通过Hash方式将各数据库映射到唯一的Shard上，在消费时保证保序列。

• 根据映射规则，DB1-DB3被 hash到 shard1上，DB4-5被映射到Shard2，相安无事
• 有一天数据库实例DB2, DB3流量突然产生的变化，突破了Shard1处理能力(写5MB/S，读10MB/S)
• 小B通过分析，决定把DB2，DB3进行拆分，于是根据映射Hash方式调整了Shard1，变成2个新的Shard(Shard3, Shard4)，Shard3 服务DB1,DB3, Shard4 服务DB2，流量终于均衡了

值得一提的是，伸缩操作都是ms级完成，并且过程是对用户服务是没有任何影响。

关于弹性伸缩(Merge/Split)详细说明

分区是什么

logstore下分为若干个分区，每个分区由两个md5组成的左闭右开的区间组成，每个区间的范围不会相互覆盖，并且所有的区间的范围合并起来就是md5的整个取值范围。logstore的日志必定保存在某一个分区上。

以图为例，为了简化说明，这里假设md5的取值范围是00 到ff。这个logstore共有4个分区，范围分别是[00,40),[40,80),[80,C0),[C0,ff)。当写入日志时，用户指定一个md5的key是5f，那么这个请求会落在第1号分区上；如果用户指定md5是8c，那么该请求的数据会落到第2号shard上。

分区的状态有两种，一种是readwrite，可以读写；另一种是readonly，只能读数据，不能写数据。 分区的范围如何划分。创建logstore时，指定分区个数，会自动平均划分整个md5的范围。之后可以通过分裂和合并操作来扩容和缩容分区个数。

logstore需要多少个分区

根据logstore实际的流量，每个分区能够处理5M/s的写数据，和10M/s的读数据。根据流量计算出来需要多少个分区。

当写入的API持续报错403或者500错误时，通过logstore云监控查看流量，判断是否需要增加分区。

当流量变小时，为了节约企业成本，可以通过合并操作减少分区。

分裂和合并操作

分裂操作是把一个readwrite的分区分裂成两个readwrite的分区，同时自己变成readonly的分区。分裂操作是扩容logstore流量的手段。

以图为例，1号分区原来的范围是[40,80)，指定以60为分界点，把整个范围分成了两份[40,60),[60,80)，形成两个新的分区4号分区和5号分区。1号分区变成红色的readonly状态。 在分裂之前写到1号分区上的数据仍然留在1号分区上可供读取，分裂完成后，1号分区不再接收数据，落到40到80之间的数据会选择性的落到4号分区或者5号分区，比如5f这个md5，会写入到4号分区上。

合并操作和分裂操作相反，是把两个相邻的readwrite的分区合并成一个readwrite分区，同时原来的两个分区变成readonly状态。

如何进行分裂与合并

• 通过API或SDK：,
• 通过管理控制台

弹性伸缩对上下游是否有影响

• 对上游没有任何影响，透明
• 对下游消费者而言需要感知Shard数目变化，我们推荐使用我们提供Storm Spout，Spark Stream Library或Client Library（Java、Python等用户），Client Library会根据消费实例数目与Shard数目做负载均衡，过程不丢不重数据