在之前的文章《日志服務（原sls）新功能釋出(1)--支援保序寫入和消費》中，我們提到了shard支援key映射的特性，通過這個特性能夠支援對序有需求的應用場景。今天我們給大家介紹一個在削峰填谷或流量突增情況下的功能：彈性伸縮。在生産中我們往往會面臨峰值和低值的情況，也會遇到因業務層映射不均衡，導緻某一個分區（shard）有非常大流量的場景，彈性伸縮（merge/split）就是為此設計的利器。
使用者a是一個視訊類網站，晚8點-22點是一天的高峰，會産生大量的點選和通路日志。小a使用日志服務一個logstore進行點選日志收集與消費。
在白天時使用一個shard（shard0）分區（寫5mb/s、讀10mb/s）
當晚間高峰時對該分區進行分裂（split），分區變為2個分區shard1，shard2服務能力（寫10mb/s，讀20mb/s）
當高峰期過後，通過合并（merge）将兩個分區調整一個分區的服務能力(shard3)，以控制成本
使用者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級完成，并且過程是對使用者服務是沒有任何影響。
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實際的流量，每個分區能夠處理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：split, merge
通過管理控制台
對上遊沒有任何影響，透明
對下遊消費者而言需要感覺shard數目變化，我們推薦使用我們提供storm spout，spark stream library或client library（java、python等使用者），client library會根據消費執行個體數目與shard數目做負載均衡，過程不丢不重資料