转载自 : 杉枫

量变引起质变,这个情况在分布式redis集群下发生的极其明显,当用redis集群规模很小、存取数据很小时,基本上不会遇到任何问题,但是当我们集群规模为数T,并且存在很多业务读写集群各种各样问题都会发生。

线上遇到过一个业务突然tp99飙升,并且性能持续变差,性能看着一点一点变差,而我们只能去分析定位查找,最终定位到是集群在拉取数据,mGet高达30万数据,不是一次mGet30万组数据而是分多次批量读取,每次取1000直到30万数据读完,这么大的批量读取由于redis本身是单线程架构会导致其他请求堵塞导致性能上升,通过优化架构减少读取数据从而提升性能。

线上遇到过集群分片一直在写,从而导致集群一直很忙,影响线上性能,经过不断分析定位,发现问题是什么呢?是有一个key一直在写,实际业务上是一个过滤数据,存储在redis,每个用户去过滤他自己数据,实际中因为有些用户不会登陆,这是就不能进行过滤,否则因为没有登陆用户很多,会导致过滤数据不停写,并且不断增大从而导致分片性能受影响,从而导致性能出问题。

前一次大促时候线上大促时遇到redis连接数过多,过多会导致什么问题呢?连接过多会导致后续连接可能取不到数据,从而导致线上业务遭受严重影响,怎么减少连接呢?就要从连接来源分析,将连接数降低,从而避免连接风暴导致集群不可用。

首先分析连接数来自于三个方面,一个是离线任务倒入redis,这种方式通过代理方式连接redis集群,好处是可以控制代理集群到redis集群连接数,从而控制连接数量,问题是代理集群数量过少会影响使用这种方式连接redis集群业务。每一种方式优点往往就是这种方式缺点,这时就需要我们根据实际情况进行取舍。

另一种连接集群方式采用公司自己研发客户端,采用连接池方式与redis集群连接,直接连接redis集群,好处是批量读取、单个读取性能都高,缺点是连接数高,导致集群连接数过多,原来storm storm主要用于准时事计算这种可以进行优化,线上业务也采用这种连接方式,不好进行方式修改,因为修改会对于线上业务有很大影响。关于连接池相关可以见这篇 谈谈连接池、线程池技术原理

对于上边连接问题还有一种客户端采用单连接架构,单连接能显著降低连接,但是会对批量操作有一定影响对于mGet,这时就权衡将storm升级为这种方式,显著减少连接数,解决了连接数过多问题。

对于连接数因为以前业务逻辑简单,推荐引擎召回数据很少,那时将多个业务存在一个集群是合理的,但当下单个业务逻辑极其复杂,召回数据极其多,这时就需要拆分集群,从而降低集群负载以及连接数。同时这种架构也可避免线上业务相互影响。

从上边可以看出来,当你的业务达到数万/分钟,并且一个用户请求需要多次召回数据、复杂计算才能返回,这时就不能拿redis当作透明中间件来用,而应该对其架构不断深入理解,根据实际场景来运用。

需要对分片、集群架构、集群扩容、所容、删除机制、以及连接管理,负载以及数据存储大小,合理使用数据结构等各个方面深入理解,不然使用很容易突然�