携程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}}]}