关于性能优化的一些实践

背景

在海量并发业务的场景下,比如电商抢购、微信红包这样的场景下,我们经常会遇到各种各样的性能问题,在应对这些问题的时候,应该有怎样的方法论去指导我们解决问题,基于这几年的开发经验,做一个简单的分享。性能优化包含两个方面的理解:

  • 业务层面的性能优化
  • 框架层面的性能优化

在比较大的互联网公司中,一般不会直接使用开源的框架做业务开发,这里就涉及到框架的性能问题,一般的框架都需要解决几个问题

  1. 锁的粒度,在高并发的请求处理中,都需要解决输入输出队列的锁的问题,这是一个演化的过程,从古老的文件锁,到现在的无锁循环队列,对框架的处理性能是有质的飞跃
  2. 调度的粒度,在TX,比较老的框架,其实一开始都是多进程的框架,后面才慢慢有了多线程,以及后面的微线程的框架,越来越小的调度代价,减少内核态和用户态的切换,能够有效的带来性能的收益。
  3. 拷贝的次数,一个请求,从请求进入之后,经历过几个流程的处理,经历了几次的内存拷贝,对整个框架的性能也有比较大的影响

技术手段

不过,本文不讨论框架层面的性能优化,更多的是介绍业务层面的相关技术手段

  • 前端保护后端
  • 业务流程解耦(异步化)
  • 数据库分库分表
  • 柔性可用,可降级
  • Set化部署

     以上技术手段在MY微信红包中的具体实现

     1.前端保护后端

     在高并发的场景中,瞬间的并发量是非常大的,因此请求应该呈现一个漏斗型往下递减

    所以,我们在前端CGI层利用缓存(如redis、memcache等)做了一些优化,比如在抢红包的场景中,用redis存储红包剩下的个数,每个人是否抢过这个红包这些标识, 尽量只让真正可以抢红包的请求通过CGI层落入逻辑层,快速的过滤掉不合理的请求。

在前端,我们一般用CDN(或者类似的数据靠近服务)做前端页面的加速;

接入层作为后端的第一个模块,接收最多的请求,一般的优化方式有合并请求,数据预加载等,在云监控的场景中,前端接入层需要接收大量的数据点,需要屏蔽无效的数据点,这里就会有数据预加载的请求,将接入的信息(变更频率很低)预加载到内存中,请求进来之后根据内存中的预存储数据做数据的过滤。

     2.业务流程解耦

     在业务开发过程中,我们经常会遇到耗时的场景,比如在抢红包入账的场景中,入账的操作是一个事务,耗时比较长,放在核心流程中,会影响整体的吞吐量,或者是在监控数据上报的场景中,后续的数据梳理和告警判断都是很重的业务逻辑,这就需要我们去解耦这个流程,利用消息队列对这个入账的流程或者其他的处理流程进行解耦,保证并发量 ,如下图,是笔者最近开发的事件中心架构,就用到CKafka做业务的解耦

事件中心架构

     3. 数据库分库分表

      分库分表作为一个比较老的手段,依然是很有效的增加并发能力的方法(因为我们很多不经意的查询或者更新都会导致锁表)。例如在红包的根据红包ID,将红包落入不同的表中,这样在抢红包的场景中,DB的锁的压力就分散到各个表中,这里如何做分表是调优的关键,核心思想就是均匀的分配数据。

本身如何均匀的做数据分配也是一个比较难的问题,我们在监控数据的存储中,也会遇到这样的问题,监控的数据一般会用KV存储,基于LSM的HBASE和在这个基础上做了优化opentsdb是比较主流的选择,opentsdb不仅针对时序数据的特点做了优化,同时,针对rowKey的生成方式也做了比较多的改进,避免数据分布不均导致数据热点的产生,这里不展开讨论。

     4. 柔性可用,过载保护可降级

     在数据层发生灾难、系统负载高的情况下,保证业务的最核心流程可用,牺牲一些用户体验来达到系统的稳定。例如对抢红包的返回结果进行降级,不返回红包列表等,只让用户看到自己抢的红包的结果。

基于业务优先级的过载保护

     5. Set化部署

以最近参与的云监控项目为例,腾讯云现在的地域非常广,最新的地域现在在俄罗斯(欢迎试用),海外地域到国内的数据延迟一般在300ms以上,这就要求我们在所有地域都有Set去做就近接入,减少因为网络延迟带来的影响,云监控现在在每个地域都是单独部署,只有告警发送模块等少量服务是集中部署的

set化部署

结论

工作接近五年,前面的三年多的时间一直从事的是2C产品的开发,经历过苦哈哈的计算内存空间的时候,因为2C的数据体量远比2B的产品要大,TX以前的A/B/C的服务器性能也一般(从现在看来),在这种场景下成长起来的程序员都会比较抠门,更多的去想如何节省机器,当然现在我觉得也是有一定参考价值的,希望对你有用

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

开发者

1 篇文章1 人订阅

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏编程一生

接口服务规划的个人想法

1214
来自专栏PingCAP的专栏

TiDB at 丰巢:尝鲜分布式数据库

随着丰巢业务系统快速增长,其核心系统的数据量,早就跨越了亿级别,而且每年增量仍然在飞速发展。整个核心系统随着数据量的压力增长,不但系统架构复杂度急剧增长,数据架...

900
来自专栏EAWorld

Service Mesh解读:新一代微服务技术新秀

作者:William Morgan 译者:月满西楼 原题:What’s a service mesh? And why do I need one? Ser...

3416
来自专栏IT大咖说

每秒处理1000万用户请求…云上架构如何实现高性能和高可用

1551
来自专栏帅小子的日常

Dubbo介绍和服务架构分析

3828
来自专栏Java架构师进阶

怎么从初、中级Java程序员过渡到高级Java程序员?

原文地址:https://www.toutiao.com/i6599524702937416195/

421
来自专栏Java架构沉思录

亿级用户下的新浪微博平台架构

  新浪微博在2014年3月公布的月活跃用户(MAU)已经达到1.43亿,2014年新年第一分钟发送的微博达808298条,如此巨大的用户规模和业务量,需要高可...

1322
来自专栏EAWorld

独家系列:让我们遇见未来——为什么选择SEDA作为云平台的基础消息处理架构(PPT)

? 我们身处在一个数字化商业的时代,作为一名IT工作者,如何保证我们所设计的系统、开发的服务在面对复杂不确定的网络环境中,还要去交付准确可靠稳定的服务? 我...

3424
来自专栏IT技术精选文摘

PB级海量数据服务平台架构设计实践

基于PB级海量数据实现数据服务平台,需要从各个不同的角度去权衡,主要包括实践背景、技术选型、架构设计,我们基于这三个方面进行了架构实践,下面分别从这三个方面进行...

2486
来自专栏北京马哥教育

十分钟看懂时序数据库(I)-存储

2017年时序数据库忽然火了起来。开年2月Facebook开源了beringei时序数据库;到了4月基于PostgreSQL打造的时序数据库TimeScaleD...

35111

扫码关注云+社区