高并发系统功能设计注意事项

本文详细阐述了IT系统设计的关键环节,包括产品需求澄清、开发设计评审中的功能和数据库设计、缓存策略、接口设计、job设计的幂等性和性能优化,以及监控和预案设计,强调了高并发场景下的处理策略和系统稳定性的重要性。
摘要由CSDN通过智能技术生成

一、产品需求澄清、PM排期及任务分解

这个没太多好说的。

二、开发设计评审(研发、测试参与)

2.1 功能设计流程图

与外部系统交互、本系统模块之间流程,比较好用的画图软件draw.io或在线的process on

2.2 数据库设计

评审

  • 表结构设计是否合理;
  • 表的关联关系是否合理;
  • 是否创建索引;
  • 是否需要放到分片库以及分片字段设计;

2.3 缓存设计

  • 缓存结构是否合理 (string、hash、list、set),

优秀实践:
1)对于C端高并发接口,hash结构要慎重用,key不能用固定的key,防止key倾斜,可以采用string结构,value尽可能压缩下,比如
("groupId:":"536363737""groupId":"989898989"}改为"536363737#989898989",大大节省redis空间。

2)对于数据量很大,单条value报文很大的业务,如果经常判断某个值是否存在,可以考虑采用set结构,利用sismember方法,时间复杂度0(1)

  • 缓存过期时间是否合理(不能怕脑袋胡乱,给一个时间,如果存放的数量,过期时间一定要给短一些,比如20分钟或半小时,否则增长很长,打爆redis);、

  • 缓存是否设计考虑预热和重建机制

  • 缓存中尽可能不能使用delete、特别是存放数量很大的hash、set、List、容易阳塞redis,引发事故、替换方案:expire-1

  • 是否是否设计二级缓存(本地缓存+分布存、实现方式Caffinecuaatredis),对于数据量不大热点数据般1w条以下,单条报文10Kb以下,比如网点教据、航线数挥可以放本地缓存,这些热点数据查询非常频繁,容易造成redis倾斜,本地缓存可以抗这种高并发流量

  • 防穿透处理
    1)提供c端的接口,查询不到数据,尽可能不要穿透到数据库,防止打爆数据库,查不到一定记得打印告警日志,及时人工干预

    2)提前将数据预热到缓存中(系统启动预热或者运营后台有手动刷新缓存按钮或者有个job刷缓存)

4、job设计

  • job逻辑要考虑幂等
  • job逻辑尽可能轻量级,不要太重,导致执行逻辑很久(如果确实逻辑比较复杂,可以分拆J0b或者从代码层面优化,例如:分批并行处理、减少单次处理数据)
  • 构建数据到缓存类似的job,尽可能选择时间在晚上12点以后,尽量不要白天进行,因为白天流量很大,重建缓存容易引起接口抖动
  • 对于定时执行的job,设计执行时间的时候,要慎重考虑线上整个job执行的时间,根据这个时间配置cron表达式,不要拍脑袋随意设置不然本次job没执行完,下一次job执行的时候容易错过。
  • 对于大表数据(百万、千万甚至亿级),可以利用xxljob、saturn等分布式调度框架的分片处理能力,并行刷数据,提供处理速度。

5、接口设计

  • 高并发接口必须在测试环境压测,清楚的知道接口支持的QPS,另外根据压测报告给出的优化建议,及时调整线上的配置、代码优化。
  • 提供给C端的接口,要清楚曝光位置、然后根据接口可能预计调用的流量、压测的接口最大支持的QPS,决定是否扩容、是否需要限流及兜底逻辑、是否熔断。
  • 程序中涉及的异常信息,及时配置错误监控告警,遇事做到心中有数。
  • 对于业务关键位置,及时打印info级别的业务追踪日志,如果是高并发接口,要做好开关,能秒级关闭,因为打印日志也特别耗性能。
  • 程序设计方面,高并发接口,尽可能使用缓存、能异步就异先一般用不要用多线程异》,尽可能买用无锁设计防止线程10CK CPU冲高,批量写库
  • 接口前置逻辑提前,尽早过滤掉不合规逻辑,缩短接口整个调用链路时长,提升接口整体吞吐量。
  • 接口要考虑无状态设计、幂等设计(考虑分布式锁唯一key)、安全设计(接口方法签名、是否接第三方防刷服务判断是否黑产用户)
  • 对第三方服务做到0信任,考虑降级、熔断,与业务方确认好兜底逻辑处理。
  • 工具类尽可能使用apache、google等出的、一些github小众的开源框架很多在高并发场景有bug和性能瓶颈。
  • 接口的时间复杂度,部分逻辑在设计的时候尽可能保证是0(1),例如调用第三方接口,f循环调用的,是否可以提到循环外,传多个d批量调用一次,时间复杂度从0(n)降为0(1)。

6、监控设计

  • 核心接口做好监控,例如:调用量上涨/下跌80%、接口健康度监控(5分钟error超过100次、5分钟接口超过11000次、5分钟不可用次数超过1000次)
  • 应用监控,例如:应用cpu、内存层、gc、繁忙线程数、数据库连接池连接数监控告警
  • 中间件监控,例如:redis可用性、cpu-内存-流量-大key-热key-慢查询监控、kafka可用性-消息积压情况-丢失率监控告警数据库监控,例如:mysql cpu、慢sql监控告警
  • 业务监控,例如:发券量暴涨或暴跌、活动注册人数同比或环比异常

7、预案设计

1)设计全局开关(系统接近不可用,通过配置中心全局开关快速切断接口流量,保证系统可用)
2)遇到系统故障,非核心功能通过配置中心开关下线,保证整体服务可用
3)应用能自动扩容这里就要求应用做到无状态设计,比如:我们之间有一些应用有调用加密机,但是新应用节点需要申请白名单,这种设计方式就没法自动扩容)

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值