在谈电商618大促备战分布式redis、压测、限流、降级、review

在促销开始后，比如618一般是从6月1日就开始进行促销了，开始促销后最好的方式是线上服务尽量不要上线了。但还是有些情况比如618当天活动信息，必须要大促时进行上线的，主要需要确保两方面一是功能一是性能。

保证功能正确，完全保证功能正确还是很难的，但还是有很多经验可循，首先新的服务尽量去新建而不要和原有其他服务勾连一起避免其他服务不可用，再有就是其他服务使用的与接口相关的尽量不要去修改，无论是修改名称还是对类增减字段都是会影响原有服务调用的，在dubbo微服务架构下，这是需要注意的点。

保证功能正确需要进行详尽单元测试，覆盖尽可能多的路径，而不是测一下验证程序正确性，测试思路应该是尽量找出程序问题。就是要尽可能测试更多情况覆盖尽可能多的路径，来避免出现null 重复数据等各种异常。明显错误，空指针、数据重复、抛异常这些一定要避免。

单元测试保证程序没有基本逻辑错误后，还不够，还需要程序进行性能测试，性能压测确保程序在高并发，程序cpu、内存、网络、磁盘各种资源压力在可承受范围内，而不是内存崩溃或者cpu使用90%以上，导致程序不能正常提供服务。或者突然的超大流量直接导致程序全面雪崩，从而导致服务不可用，还有更坏情况就是程序负载过高影响统一硬件上其他容器内服务，造成更大破坏。

有了完善功能测试与性能压力测试就够了吗，答案是还不够，有了上面软件功能流程能保证程序基本没有问题，但是不能保证意外，比如流量突然就超过与测试值，大家买买买太厉害了。这时就需要降级预案，并且预案不单单是我们自己的，还包含调用我们的下游兄弟，如果我们自身出现问题，不但我们可以切换程序逻辑，下游也可以对程序逻辑进行切换。从而确保流量或功能出现问题时，迅速切到降级预案避免用户受影响。

存储作为应用程序核心依赖中间件也是备战重点对象，存储本身也是存在及其复杂环境，存储受限于网络吞吐、连接、每条数据大小、批量读数据大小，集群压力越大时，大小会影响集群吞吐，以及tp999、tp max从而影响线上服务。要想存储快，就要单条数据尽可能小，并且批量拉取数据尽可能小。

今年遇到比较麻烦问题时是扩容后线上服务节点增加导致redis访问客户端增加，并且由于推荐系统特征工程导致大量storm任务，多个原因导致客户端增加，客户端多导致连接增多，过多连接达到集群上限导致集群存在后续如果存在高流量情况会出现取不到链接从而导致取不到数据，及其严重情况。

早些时候通过通用数据隔一层服务情况来解决，方式是没问题的，但应该先找到导致连接增加最重要原因、因素是哪个？是线上服务还是storm、还是离线mapreduce任务倒入redis导致的，解决问题首先是定位问题，这一点是极其关键因素。才能尽量少走弯路的解决问题。

经定位一是线上服务多个集群混用，以前业务少业务逻辑简单还是挺好的方式，资源利用率高，但现在线上服务越来越复杂，拉取数据越来越多，那就需要更多redis连接、内存、cpu来提供服务。这时混用可能就不再是一个好的选择，每个服务一个集群是必须要走的一条路，业务拆分。

再有连接问题可以采用写主读从，并且把两个机房都利用起来，将连接进行分摊从而解决连接问题。去年通过主从解决了问题，今年通过主从也是不能解决问题了。就需要上边这种通过拆分业务，单个业务单个集群来严格控制连接数。连接数问题，容器连接，物理机连接，过多连接会导致物理机连接耗尽，从而导致取不到链接，取不到数据，引发严重事故。

redis团队解决连接数过多，采用升级客户端方式来解决，redis存储客户端单长连接来解决连接池导致连接过多问题。storm程序通过使用新版客户端，将连接数降了下来，暂时解决了问题，从侧面也能说明storm本身对redis产生了很多客户端，生出了很多连接。长远还是要对redis进行拆分。

storm在一种业务架构下为了消息不挤压采用很多storm进程方式，而每个进程都会产生一个redis客户端，每个客户端包含大量连接。导致连接过多。

redis一种架构增加中间代理，代理会成为瓶颈。可以作为跨语言调用redis的一种架构方案。

无论是单连接还是中间代理架构，都会导致性能损耗，单连接本身如果有数据特别大势必会严重影响整个吞吐，在原来连接池方式下会比单连接更好。代理架构代理部分多了一层转发造成性能消耗，再有就是过大请求压力对导致代理需要很多资源，这是代理架构缺陷。

应用本地缓存guava cache，减少写redis，这种要根据实际场景来应用，通过别的团队了解到线上是有在用的，可以证明这种方式是走的通的。

review 线上日志不能多，重要事项写满磁盘，异常检查，空值检查，异常处理，数据重复，降级预案，单机压测，联合压测，通用数据不能通用读问题。

要想不半夜被电话叫醒，半夜改程序，以及我们作为一个有一点追求的研发人员，就需要我们通过各种思考、方法、架构、必要流程来解决问题，以及一个完善灵活、完备、可扩展系统与架构，需要我们不断探索以及不断总结，才能取得一些微小成绩。