攜程Redis治理演進之路

{"type":"doc","content":[{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"一、背景"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"攜程Redis集羣規模和數據規模在過去幾年裏快速增長，我們通過容器化解決了Redis集羣快速部署的問題，並根據實際業務進行的一系列嘗試，比如二次調度，自動化漂移等，在內存超分的情況下保證了宿主機的可靠性。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"擴縮容方面，我們主要通過垂直擴縮容的方式解決Redis集羣容量的問題，但隨着集羣規模擴大，這種方式逐漸遇到了瓶頸。一方面，單個Redis實例過大，會帶來較大的運維風險和困難；另一方面，宿主機容量有上限，不能無止境的擴容。考慮到運維便利性和資源利用率的平衡，我們希望單個Redis實例的上限爲15GB。但實際操作中卻很難做到：a. 某些業務發展很快，經常性需要給Redis進行擴容，導致單個實例大小遠超15GB；b. 一些業務萎縮，實際使用量遠低於初始申請的量，造成資源的浪費。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"如何有效控制Redis實例大小呢？接下來本文將帶着這個問題，逐步講解攜程Redis治理和擴縮容方面的演進歷程。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"二、Redis水平擴分拆"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在攜程開始使用Redis很長一段時間裏，一直只有垂直擴縮容，原因有兩點："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"第一，一開始業務規模比較小，垂直擴縮容可以滿足需求。垂直擴縮容對於Redis來說只是Maxmemory的配置更改，對業務透明；"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}}]}