一次线上优化引发生产问题的思考

前言

在程序员的系统开发中,有些开发是从0到1的系统开发,有些开发是从1到100的系统开发,有些开发是为了保证系统更好、更稳定运行的优化。
从0到1的开发和从1到100的开发,是为了系统更好的实现功能,需要快速迭代,可以不断的优化、上线、再优化、再上线。
优化需求,是为了更好的使用系统,让系统更好、更稳定的运行,但是优化不能够影响到原有线上的功能,但是我们需要优化。为了防止优化过程中影响到其他代码,这里有几个总结的方案可供参考。

使用开关配置

目前我们项目中配置中心使用的是Apollo,其他配置中心或者配置文件也是同样的道理。

  • 优点:①可配置化,②可以直接防止优化代码报异常影响到原来的逻辑
  • 缺点:开关是一刀切,要么走优化逻辑,要么不走优化逻辑
public static void main(String[] args) {
        // 这里可以使用开关配置,如果有问题可以使用开关及时关掉
        String switchKey = ApolloUtil.getProperty("business_key", "false");
        if (Boolean.TRUE.toString().equalsIgnoreCase(switchKey)){
           // 优化逻辑
        }
        // 原来业务逻辑
    }

使用 try-catch

  • 优点:即使优化代码出现异常也会直接出现的异常吞掉
public static void main(String[] args) {
        try {
            // 优化逻辑
        }catch (Throwable e){
        	// 这里可以把优化逻辑代码出现的异常吞下,防止系统异常之类的
            log.error("the exception is {}", e.getMessage(), e);
        }
        // 原来业务逻辑
    }

随机调整

  • 优点:①类似于灰度发布,②可配置化,可以灵活调整比例
  • 缺点:影响部分用户的使用
public static void main(String[] args) {
        int limitNum = Integer.parseInt(ApolloUtil.getProperty("limitNum", "10"));
        // 10%, 90% 类似于灰度发布,可以逐步放开
        if (limitNum > Math.random() * 100){
            // 优化逻辑
        }
        // 原来业务逻辑
    }

联合使用

  • 核心:结合 try-catch 和可配置化
public static void main(String[] args) {
        String str = "";
        boolean flag = optimizationLogic(str);
        if (flag){
            // 根据 flag 为 true 情况下的逻辑
        }else {
            // 根据 flag 为 false 情况下的逻辑
        }
        // 原来的逻辑
    }

    /**
     * 优化逻辑,false 表示不走,true 表示走
     * @param code
     * @return
     */
    private static boolean optimizationLogic(String code){
        try {
            if (null == code || code.isEmpty()){
                return false;
            }

            String switchKey = ApolloUtil.getProperty("business_key", "false");
            if (Boolean.FALSE.toString().equalsIgnoreCase(switchKey)){
                return false;
            }

            // 优化逻辑
            return true;
        }catch (Throwable e){
            // 这里可以把优化逻辑代码出现的异常吞下,防止系统异常之类的
            log.error("the exception is {}", e.getMessage(), e);
        }
        
        return false;
    }
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
线上线程池优化是一个比较常见的问题,下面提供一个简单的优化案例。 假设我们有一个线程池,用来处理用户上传的文件。该线程池的配置如下: ``` corePoolSize=10 maxPoolSize=50 queueCapacity=100 keepAliveSeconds=60 ``` 在线上环境中,我们发现该线程池经常会出现以下两种情况: 1. 线程池中的线程数量一直处于较高的水平,但是 CPU 使用率并不高。 2. 线程池中的线程数量在短时间内迅速增加,但是处理速度并没有提升。 为了解决这两个问题,我们可以采取以下优化措施: 1. 调整线程数 首先,我们需要观察线程池的运行状态,根据实际的负载情况来调整线程池中的线程数量。可以通过监控线程池中线程的数量、CPU 使用率、系统负载等指标,来判断线程池的负载情况。如果线程数量一直处于较高的水平,但是 CPU 使用率并不高,那么就可以适当减少线程池中的线程数量,以节省系统资源。如果线程池中的线程数量在短时间内迅速增加,但是处理速度并没有提升,那么就可以适当增加线程池中的线程数量,以加快任务处理速度。 2. 使用合适的队列 其次,我们需要选择合适的队列来存储等待处理的任务。在上述的线程池配置中,使用的是基于数组的有界队列,当队列已满时就会触发线程池的拒绝策略。但是,如果上传文件的请求比较频繁,那么队列很容易就会满,从而触发拒绝策略。为了避免这种情况,我们可以考虑使用无界队列(如 LinkedBlockingQueue),或者使用基于优先级的队列(如 PriorityBlockingQueue),以及使用自定义的拒绝策略来处理请求。 3. 优化任务处理逻辑 最后,我们需要优化任务的处理逻辑,以提高任务的处理效率。可以通过优化文件上传、下载、存储等操作,减少任务处理的时间。同时,也可以考虑使用异步处理、批量处理等技术,以提高任务处理的效率。 以上就是一个简单的线上线程池优化案例。当然,具体的优化方案需要根据具体的情况来制定,并且需要进行充分的测试和评估,以确保优化效果。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Simba1949

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值