高并发业务线上性能、存储二三事

最近两天促销开始，零点流量大幅增加，通过还是比较平稳的，到是到了白天一个节点流量有大幅增加，但是量远没有达到系统极限，但是系统多个业务性能有一段时间下降。

首先分析问题原因，流量本身不正常因为白天突然增加七倍访问量，这个基本是不可能的，再有就是就算流量真的涨七倍，如果是正常流量本身系统也是没有问题的，那么可以说流量本身异常的，不然系统本身没有问题。

经下游同学定位，流量本身是刷子流量，并且来自于M站点，移动网页站点应该是各大网站刷流量抓取重地。刷子一般没有带用户信息这种情况是没有登陆，再有就是登陆了但是访问页面异常的快以及异常的多。导致系统流量突然加大，其实突然增大流量也不会导致请求异常，是什么导致服务性能异常呢？

服务性能异常就要从服务本身特点出发，我们业务本身应用 redis 存储，redis存储能处理高并发请求，但对于频繁单个key请求很容易造成性能热点从而导致服务性能异常。对于避免这种问题可以从三个方面处理这个问题。

一是从外部避免这个问题，就是从M站本身加强对于刷子流量过滤，增加防刷策略从而避免此类问题，保护内部系统，也是对刷子的一种一种防止，一种对抗。这样是比较根本方式，来避免业务异常。

二是我们个性化服务增加过滤机制，对于空用户直接返回通过数据，不要去读取redis数据从而避免单key过热导致性能下降。再有就是对于单个用户增加限制机制一是过于频繁访问通过策略限制访问次数，从而避免单key过热导致性能下降。

三是，我们的下游服务直接将访问我们的刷子流量降调，从而避免个性化服务本身受影响。二和三应该是不得已而为之方式，因为从架构合理性角度，一个防刷不可能每一层都去做，而是应该最外层去做，但是从宽进严出角度我们也应该做相应检查，避免因为一些场景导致性能受影响。

最近线上还有一个事就是存储量一直增长，导致存储有一个快被写满的情况，其实这个事本来很简单，分布式存储直接扩容就可以了，但是有个问题就是存储本身很大，以及存储客户端非常多导致连接非常多，扩容后连接会更大幅增加从而导致连接有可能取不到，这是存储本身面临问题。

解决方案一是减少客户端，从而减少连接，这就要对存储进行拆分，召回存储以及特征要拆成小集群，并且集群从一主一丛方式拆解到一主多从方式，从而进一步减少集群连接压力并且可以将读取压力拆解到多个从上，达到集群扩展性增强。能够支持更多访问量，并且集群小扩容和管理本身也能降低难度，拆解之后一定都是好处很明显不是，因为能够处理qps会降低的很明显。

你在存储和线上业务遇到过什么问题呢，可以在评论中分享下。