再谈电商 618 大促备战:分布式 Redis、压测、限流、降级、review

标签: dev | 发表时间:2018-06-11 00:00 | 作者:
出处:http://itindex.net/relian


在促销开始后,比如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 线上日志不能多,重要事项写满磁盘,异常检查,空值检查,异常处理,数据重复,降级预案,单机压测,联合压测,通用数据不能通用读问题。


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

        

相关 [电商 分布 redis] 推荐:

再谈电商 618 大促备战:分布式 Redis、压测、限流、降级、review

- - IT瘾-dev
在促销开始后,比如618一般是从6月1日就开始进行促销了,开始促销后最好的方式是线上服务尽量不要上线了. 但还是有些情况比如618当天活动信息,必须要大促时进行上线的,主要需要确保两方面一是功能一是性能. 保证功能正确,完全保证功能正确还是很难的,但还是有很多经验可循,首先新的服务尽量去新建而不要和原有其他服务勾连一起避免其他服务不可用,再有就是其他服务使用的与接口相关的尽量不要去修改,无论是修改名称还是对类增减字段都是会影响原有服务调用的,在dubbo微服务架构下,这是需要注意的点.

BDRP分布式redis集群

- - 百度运维团队技术博客
BDRP(baidu distributed redis platform)是包含 twemproxy, redis,redis-sentinel等多个模块开发的分布式redis平台. bdrp已经在github上进行了开源, bdrp的github项目点这里. 目前redis集群架构主要有以下几个组件: twemproxy:redis的代理系统,可以选择多种数据分片算法 redis:集群的redis存储节点 sentinel:redis官方的集群高可用组件,可以监控redis主节点故障,并进行主备切换.

如何用redis实现分布式锁

- - CSDN博客数据库推荐文章
redis作为一个强大的key/value数据库,其实还可以用来实现轻量级的分布式锁. 最早官方在 SETNX命令页给了一个实现:. 不过这个方案有漏洞,就是release lock用的DEL命令不支持cas删除(delete if current value equals old value),这样忽略race condition将会出现问题:.

Redis分布式中间件TwemProxy

- - 企业架构 - ITeye博客
twemproxy,也叫nutcraker. 是一个twtter开源的一个redis和memcache代理服务器. redis作为一个高效的缓存服务器,非常具有应用价值. 但是当使用比较多的时候,就希望可以通过某种方式 统一进行管理. 避免每个应用每个客户端管理连接的松散性. 搜索了不少的开源代理项目,知乎实现的python分片客户端.

基于twemproxy的redis分布式应用

- - 数据库 - ITeye博客
根据以往的测试结论,单个redis的实例的内存总量最好控制在8G以内(最大不能超过20G),而实际上应用对redis的内存的需求可能会远远大于8G,因此需要一个保持redis server性能不下降,但可以有效扩充redis server的容量的方案. twemproxy是一个恰当的选择. twemproxy,也叫nutcraker.

使用Scrapy-redis实现分布式爬取

- - 标点符
Scrapy是一个比较好用的Python爬虫框架,你只需要编写几个组件就可以实现网页数据的爬取. 但是当我们要爬取的页面非常多的时候,单个主机的处理能力就不能满足我们的需求了(无论是处理速度还是网络请求的并发数),这时候分布式爬虫的优势就显现出来. 而Scrapy-Redis则是一个基于Redis的Scrapy分布式组件.

基于 Redis 实现分布式应用限流

- - 文章 – 伯乐在线
限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统,一旦达到限制速率则可以拒绝服务. 前几天在DD的公众号,看了一篇关于使用 瓜娃 实现单应用限流的方案,参考《redis in action》 实现了一个jedis版本的,都属于业务层次限制. 按照一定的规则如帐号、IP、系统调用逻辑等在Nginx层面做限流.

基于redis分布式锁实现“秒杀”

- - 企业架构 - ITeye博客
来自于  http://blog.5ibc.net/p/28883.html. 所谓秒杀,从业务角度看,是短时间内多个用户“争抢”资源,这里的资源在大部分秒杀场景里是商品;将业务抽象,技术角度看,秒杀就是多个线程对资源进行操作,所以实现秒杀,就必须控制线程对资源的争抢,既要保证高效并发,也要保证操作的正确.

Redis分布式锁解决抢购问题

- - 企业架构 - ITeye博客
废话不多说,首先分享一个业务场景-抢购. 一个典型的高并发问题,所需的最关键字段就是库存,在高并发的情况下每次都去数据库查询显然是不合适的,因此把库存信息存入Redis中,利用redis的锁机制来控制并发访问,是一个不错的解决方案.         //这里抛出的异常要是运行时异常,否则无法进行数据回滚,这也是spring中比较基础的  .

Redis 分布式锁原理及 Redisson 实现

- - 叉叉哥的BLOG
Redis 分布式锁原理. Redis 分布式锁原理,可以直接看官方文档:. SET resource-name anystring NX EX max-lock-time 命令可以基于 Redis 实现分布式锁. NX 仅当 key 不存在时设置成功. EX seconds 失效时间(秒). Nil 时,客户端未获得锁,需要过一段时间再重试命令尝试获取锁.