转载自 ： 杉枫

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

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

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

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

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

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

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

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

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

需要对分片、集群架构、集群扩容、所容、删除机制、以及连接管理，负载以及数据存储大小，合理使用数据结构等各个方面深入理解，不然使用很容易突然发生问题，从而影响业务稳定性，作为一个程序架构设计人员，我们应该加强了解，本身对于分布式redis集群这种架构有深入了解后，对于其他比如bigtable、hbase理解也会更加深入。