上班第一天,老板就甩来30G文件,这个人不怕我离职的吗?

Java实现excel大数据量导入 主要为大家详细介绍了Java实现excel大数据量导入,文中示例代码介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们可以参考一下 立即下载

 如果给你一个包含一亿行数据的超大文件,让你将数据转化导入生产数据库,你会如何操作?

上面的问题是接到的一个真实的业务需求,将一个老系统历史数据通过线下文件的方式迁移到新的生产系统。

由于时间紧,而数据量又超大,所以设计的过程想到一下解决办法:

  • 拆分文件
  • 多线程导入

拆分文件

首先我们可以写个小程序,或者使用拆分命令 split 将这个超大文件拆分一个个小文件。

-- 将一个大文件拆分成若干个小文件,每个文件 100000 行
split -l 100000 largeFile.txt -d -a 4 smallFile_
复制代码

这里之所以选择先将大文件拆分,主要考虑到两个原因:

第一如果程序直接读取这个大文件,假设读取一半的时候,程序突然宕机,这样就会直接丢失文件读取的进度,又需要重新开头读取。

而文件拆分之后,一旦小文件读取结束,我们可以将小文件移动一个指定文件夹。

这样即使应用程序宕机重启,我们重新读取时,只需要读取剩余的文件。

第二,一个文件,只能被一个应用程序读取,这样就限制了导入的速度。

而文件拆分之后,我们可以采用多节点部署的方式,水平扩展。每个节点读取一部分文件,这样就可以成倍的加快导入速度。

多线程导入

当我们拆分完文件,接着我们就需要读取文件内容,进行导入。

之前拆分的时候,设置每个小文件包含 10w 行的数据。由于担心一下子将 10w 数据读取应用中,导致堆内存占用过高,引起频繁的 「Full GC」,所以下面采用流式读取的方式,一行一行的读取数据。

当然了,如果拆分之后文件很小,或者说应用的堆内存设置很大,我们可以直接将文件加载到应用内存中处理。这样相对来说简单一点。

逐行读取的代码如下:

File file = ...
try (LineIterator iterator = IOUtils.lineIterator(new FileInputStream(file), "UTF-8")) {
    while (iterator.hasNext()) {
        String line=iterator.nextLine();
        convertToDB(line);
    }

}
复制代码

上面代码使用 commons-io 中的 LineIterator类,这个类底层使用了 BufferedReader 读取文件内容。它将其封装成迭代器模式,这样我们可以很方便的迭代读取。

如果当前使用 JDK1.8 ,那么上述操作更加简单,我们可以直接使用 JDK 原生的类 Files将文件转成 Stream 方式读取,代码如下:

Files.lines(Paths.get("文件路径"), Charset.defaultCharset()).forEach(line -> {
    convertToDB(line);
});
复制代码

其实仔细看下 Files#lines底层源码,其实原理跟上面的 LineIterator类似,同样也是封装成迭代器模式。

多线程的引入存在的问题

上述读取的代码写起来不难,但是存在效率问题,主要是因为只有单线程在导入,上一行数据导入完成之后,才能继续操作下一行。

为了加快导入速度,那我们就多来几个线程,并发导入。

多线程我们自然将会使用线程池的方式,相关代码改造如下:

File file = ...;
ExecutorService executorService = new ThreadPoolExecutor(
        5,
        10,
        60,
        TimeUnit.MINUTES,
     // 文件数量,假设文件包含 10W 行
        new ArrayBlockingQueue<>(10*10000),
      // guava 提供
        new ThreadFactoryBuilder().setNameFormat("test-%d").build());
try (LineIterator iterator = IOUtils.lineIterator(new FileInputStream(file), "UTF-8")) {
    while (iterator.hasNext()) {
        String line = iterator.nextLine();
        executorService.submit(() -> {
            convertToDB(line);
        });
    }

}
复制代码

上述代码中,每读取到一行内容,就会直接交给线程池来执行。

我们知道线程池原理如下:

  1. 如果核心线程数未满,将会直接创建线程执行任务。
  2. 如果核心线程数已满,将会把任务放入到队列中。
  3. 如果队列已满,将会再创建线程执行任务。
  4. 如果最大线程数已满,队列也已满,那么将会执行拒绝策略。

线程池执行流程图

由于我们上述线程池设置的核心线程数为 5,很快就到达了最大核心线程数,后续任务只能被加入队列。

为了后续任务不被线程池拒绝,我们可以采用如下方案:

  • 将队列容量设置成很大,包含整个文件所有行数
  • 将最大线程数设置成很大,数量大于整个文件所有行数

以上两种方案都存在同样的问题,第一种是相当于将文件所有内容加载到内存,将会占用过多内存。

而第二种创建过多的线程,同样也会占用过多内存。

一旦内存占用过多,GC 无法清理,就可能会引起频繁的 「Full GC」,甚至导致 「OOM」,导致程序导入速度过慢。

当然了,我们还可以第三种方案,综合前两种,设置合适队列长度,以及合适最大线程数。不过呢,**「合适」**这个度真不好把握,另外也还是有 「OOM」 问题。

所以为了解决这个问题,研究出两个解决方案:

  • CountDownLatch 批量执行
  • 扩展线程池

CountDownLatch 批量执行

JDK 提供的 CountDownLatch,可以让主线程等待子线程都执行完成之后,再继续往下执行。

利用这个特性,我们可以改造多线程导入的代码,主体逻辑如下:

try (LineIterator iterator = IOUtils.lineIterator(new FileInputStream(file), "UTF-8")) {
    // 存储每个任务执行的行数
    List<String> lines = Lists.newArrayList();
    // 存储异步任务
    List<ConvertTask> tasks = Lists.newArrayList();
    while (iterator.hasNext()) {
        String line = iterator.nextLine();
        lines.add(line);
        // 设置每个线程执行的行数
        if (lines.size() == 1000) {
            // 新建异步任务,注意这里需要创建一个 List
            tasks.add(new ConvertTask(Lists.newArrayList(lines)));
            lines.clear();
        }
        if (tasks.size() == 10) {
            asyncBatchExecuteTask(tasks);
        }

    }
    // 文件读取结束,但是可能还存在未被内容
    tasks.add(new ConvertTask(Lists.newArrayList(lines)));
    // 最后再执行一次
    asyncBatchExecuteTask(tasks);
}
复制代码

这段代码中,每个异步任务将会导入 1000 行数据,等积累了 10 个异步任务,然后将会调用 asyncBatchExecuteTask 使用线程池异步执行。

/**
 * 批量执行任务
 *
 * @param tasks
 */
private static void asyncBatchExecuteTask(List<ConvertTask> tasks) throws InterruptedException {
    CountDownLatch countDownLatch = new CountDownLatch(tasks.size());
    for (ConvertTask task : tasks) {
        task.setCountDownLatch(countDownLatch);
        executorService.submit(task);
    }
    // 主线程等待异步线程 countDownLatch 执行结束
    countDownLatch.await();
    // 清空,重新添加任务
    tasks.clear();
}
复制代码

asyncBatchExecuteTask 方法内将会创建 CountDownLatch,然后主线程内调用 await方法等待所有异步线程执行结束。

ConvertTask 异步任务逻辑如下:

/**
 * 异步任务
 * 等数据导入完成之后,一定要调用 countDownLatch.countDown()
 * 不然,这个主线程将会被阻塞,
 */
private static class ConvertTask implements Runnable {

    private CountDownLatch countDownLatch;

    private List<String> lines;

    public ConvertTask(List<String> lines) {
        this.lines = lines;
    }

    public void setCountDownLatch(CountDownLatch countDownLatch) {
        this.countDownLatch = countDownLatch;
    }

    @Override
    public void run() {
        try {
            for (String line : lines) {
                convertToDB(line);
            }
        } finally {
            countDownLatch.countDown();
        }
    }
}
复制代码

ConvertTask任务类逻辑就非常简单,遍历所有行,将其导入到数据库中。所有数据导入结束,调用 countDownLatch#countDown。

一旦所有异步线程执行结束,调用 countDownLatch#countDown,主线程将会被唤醒,继续执行文件读取。

虽然这种方式解决上述问题,但是这种方式,每次都需要积累一定任务数才能开始异步执行所有任务。

另外每次都需要等待所有任务执行结束之后,才能开始下一批任务,批量执行消耗的时间等于最慢的异步任务消耗的时间。

这种方式线程池中线程存在一定的闲置时间,那有没有办法一直压榨线程池,让它一直在干活呢?

扩展线程池

回到最开始的问题,文件读取导入,其实就是一个**「生产者-消费者」**消费模型。

主线程作为生产者不断读取文件,然后将其放置到队列中。

异步线程作为消费者不断从队列中读取内容,导入到数据库中。

「一旦队列满载,生产者应该阻塞,直到消费者消费任务。」

其实我们使用线程池的也是一个**「生产者-消费者」**消费模型,其也使用阻塞队列。

那为什么线程池在队列满载的时候,不发生阻塞?

这是因为线程池内部使用 offer 方法,这个方法在队列满载的时候**「不会发生阻塞」**,而是直接返回 。

那我们有没有办法在线程池队列满载的时候,阻塞主线程添加任务?

其实是可以的,我们自定义线程池拒绝策略,当队列满时改为调用 BlockingQueue.put 来实现生产者的阻塞。

RejectedExecutionHandler rejectedExecutionHandler = new RejectedExecutionHandler() {
    @Override
    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
        if (!executor.isShutdown()) {
            try {
                executor.getQueue().put(r);
            } catch (InterruptedException e) {
                // should not be interrupted
            }
        }

    }
};
复制代码

这样一旦线程池满载,主线程将会被阻塞。

使用这种方式之后,我们可以直接使用上面提到的多线程导入的代码。

ExecutorService executorService = new ThreadPoolExecutor(
        5,
        10,
        60,
        TimeUnit.MINUTES,
        new ArrayBlockingQueue<>(100),
        new ThreadFactoryBuilder().setNameFormat("test-%d").build(),
        (r, executor) -> {
            if (!executor.isShutdown()) {
                try {
                   // 主线程将会被阻塞
                    executor.getQueue().put(r);
                } catch (InterruptedException e) {
                    // should not be interrupted
                }
            }

        });
File file = new File("文件路径");

try (LineIterator iterator = IOUtils.lineIterator(new FileInputStream(file), "UTF-8")) {
    while (iterator.hasNext()) {
        String line = iterator.nextLine();
        executorService.submit(() -> convertToDB(line));
    }
}    
复制代码

小 结

一个超大的文件,我们可以采用拆分文件的方式,将其拆分成多份文件,然后部署多个应用程序提高读取速度。

另外读取过程我们还可以使用多线程的方式并发导入,不过我们需要注意线程池满载之后,将会拒绝后续任务。

我们可以通过扩展线程池,自定义拒绝策略,使读取主线程阻塞。

好了,今天文章内容就到这里,不知道各位有没有其他更好的解决办法,欢迎留言讨论。


原文链接:https://juejin.cn/post/7042173639604568072

【异常】API 速率限制报错问题全流程排查与解决指南 API rate limit reached. Please try again later. 摘要: 本文针对大模型API开发中常见的速率限制报错("API rate limit reached")提供全流程解决方案。首先解析该报错的本质是服务端对高频调用的保护机制,通过三步排查法确认根因:客户端请求频率超出账户阈值。提出三级解决方案:1)临时等待限流周期重置;2)升级付费账户提高调用配额;3)构建多模型容灾架构实现自动切换。建议生产环境优先采用容灾方案,通过备用API节点保障业务连续性,同时平衡不同模型服务的成本与性能。 阅读详情

相关推荐

1、Ovirt 开源虚拟化平台安装

Ovirt虚拟化Node和Engine安装

大鱼 6266

Files.lines()使用问题

Java8的标准库中增加了一个新的方法: 1 2 3 4 public final class Files { public static Stream<String> lines(Path path) throws IOException } 方法描述文档。 这个方...

以爱护甲,爱满枫林。 9158

微信小程序真机HTTPS证书链失效排查与修复指南

HTTPS证书信任链是保障Web通信安全的基础机制,其核心在于客户端能否通过服务器提供的证书及其上级签发者,逐级回溯至自身预置的可信根证书。在微信小程序场景中,由于客户端不复用系统根证书库,而是采用固化、精简且更新滞后的自研CA白名单,导致大量符合浏览器标准的证书(如Let’s Encrypt新版ISRG Root X1、TrustAsia等)在真机环境下触发net::ERR_CERT_AUTHORITY_INVALID错误。该问题本质是证书链断裂或签名算法/密钥长度不合规,而非域名配置或CORS策略异常。

weixin_33935636的博客 677

如何读取大文件?(java) 流式读取Files.lines()

如何读取大文件?(java) 流式读取 当文件过大,并且你设置的 内存过下或者无法满足文件内存,一次性读取就会出现OOM内存溢出。 当这时可以使用 Files.lines() 方法解决 与 readAllLines 方法返回 List 不同,lines 方法返回的是 Stream。 这,使得我们在需要时可以不断读取、使用文件中的内容,而不是一次性地把所有内容都读 取到内存中,因此避免了 OOM。 LongAdder longAdder = new LongAdder();

jj89929665的博客 3621

防止通达信公式被盗?手把手教你用DLL加密+互联网验证(含易语言后台管理)

本文详细介绍了如何通过DLL加密与互联网验证技术保护通达信公式安全。从DLL加密实现、设备绑定到易语言后台管理,提供了一套完整的防护方案,有效防止公式被盗用。重点讲解了互联网验证登录和绑定设备等核心技术,帮助量化交易者守护核心资产。

weixin_29323551的博客 500

不刷机!Jetson AGX Orin无损更新内核与设备树的两种安全方法(附备份恢复脚本)

本文详细介绍了Jetson AGX Orin在不刷机的情况下安全更新内核与设备树的两种方法,包括extlinux.conf动态加载和分区精准刷新方案。通过备份恢复脚本和工业级灾备方案,确保零数据丢失,适用于边缘AI和机器人等关键场景。

weixin_40192258的博客 306

JDK8:用java.nio.file.Files.lines方法读取大型文件

使用jdk8中java.nio.file.Files.lines方法读取大型文件内容

github_38727595的博客 1700

Rokid眼镜高精度图像识别的五大工程破局点

图像识别是AR交互的基础能力,其核心在于将现实图像映射为可计算的数字特征,并通过几何建模解算空间姿态。在专用AR眼镜场景中,该过程面临光学畸变、传感器时序错位、低延迟跟踪与人因适配等复合挑战。尤其在工业现场,Rokid Max系列的鱼眼镜头畸变、IMU-视觉异步采样、窄FOV下快速眼动等物理约束,使传统基于AR Foundation或OpenCV的识别方案失效。本文聚焦真实部署中的关键瓶颈,涵盖实时反畸变纹理渲染、原生SDK直调优化、端侧轻量CNN模型(TinyImageNet-Rokid)、IMU-视觉紧

weixin_33681778的博客 697

Files.lines()方法使用相关问题

Files.lines方法使用的相关问题Files.lines()问题一原因解决总结 Files.lines() 以Stream流的形式读取文件的所有行 /** * 以流的形式读取文件的所有行 * 读取的的字节是以UTF-8解码的字符集 * * @param path 文件的路径 * @return Stream<String> 文件中的行组成的流 * @throws IOException 出现IO错误时抛出该异常 * @throws SecurityException 如

攻城狮Chova的博客 5025

Microsemi Libero系列教程(全网首发)

关于Libero IDE和Libero SoC Libero分为Libero IDE和Libero SoC,Libero IDE最新版本是v9.2 SP3(2016年4月4日)已经不再更新维护了,而Libero SoC是Libero IDE的升级版,官方推荐的开发工具,文中的Libero指的是Libero SoC。 Libero SoC Libero® SoC是Microsemi(美高森美)官方...

whik1194的博客 2万+

从0到1:OpenClaw 助力单元测试代码自动化与覆盖率飞升

OpenClaw 的横空出世,宛如一道曙光,照亮了这片黑暗的领域。它作为一款强大的本地 AI 助手,拥有着令人惊叹的能力。OpenClaw 能够深入理解代码的逻辑结构,自动分析代码中的各种功能和潜在的风险点,从而精准地生成高质量的单元测试代码。它就像是一位不知疲倦的测试专家,能够快速、准确地完成那些繁琐的测试编写工作,将开发者从重复劳动中解放出来,让他们能够将更多的精力投入到更具创造性和价值的工作中。

远程部署调试 运行安装 项目调试 二次开发 项目技术新 持续迭代 部分源码免费分享 476

30G 上亿数据的超大文件,如何快速导入生产环境?

Hello,大家好,我是楼下小黑哥~ 如果给你一个包含一亿行数据的超大文件,让你在一周之内将数据转化导入生产数据库,你会如何操作? 上面的问题其实是小黑哥前段时间接到一个真实的业务需求,将一个老系统历史数据通过线下文件的方式迁移到新的生产系统。 由于老板们已经敲定了新系统上线时间,所以只留给小黑哥一周的时间将历史数据导入生产系统。 由于时间紧,而数据量又超大,所以小黑哥设计的过程想到一下解决办法: 拆分文件 多线程导入 欢迎关注我的公众号:小黑十一点半,获得日常干货推送。如果您对我的专题内容感兴趣,也

楼下小黑哥 663

UG NX二次开发(C++)-UIStyler-指定平面的对象和参数获取

在采用NXOpen C++进行二次开发时,采用Menu/UIStyler是一种很常见的方式,这样可以制作精美的界面,而且常用的块对象也集成了快速编程的代码,我们可以快速的利用这些块来定制我们需要的界面。但是,对于很多初学者可能对选择对象的获取不是很熟悉,我们本文以选择“指定平面”来讲一下如何获取选择的对象和对象的参数。另外,由于我们的UG NX二次开发学习讨论群QQ一群已满,有希望参与学习的有志之士加入我们的QQ二群:683566590。

GimiGimmy 1091

上班第一天,老板就甩来30G文件是种什么体验

当然了,我们还可以第三种方案,综合前两种,设置合适队列长度,以及合适最大线程数。上述读取的代码写起来不难,但是存在效率问题,主要是因为只有单线程在导入,上一行数据导入完成之后,才能继续操作下一行。另外每次都需要等待所有任务执行结束之后,才能开始下一批任务,批量执行消耗的时间等于最慢的异步任务消耗的时间。回到最开始的问题,文件读取导入,其实就是一个**「生产者-消费者」**消费模型。任务类逻辑就非常简单,遍历所有行,将其导入到数据库中。方法,这个方法在队列满载的时候**「不会发生阻塞」**,而是直接返回。

2501_90404749的博客 1758

大中型超市收银系统(可直接运行)

光步前台收银系统系统功能:商品销售、商品退货、挂单、收银员权限、会员销售、单品取消、整单取消、商品查询、脱机销售、脱机数据上传,基本资料下载,开钱箱、小票打印、收款结算,支持多币种付款方式(现金、储值卡、礼券、微信等),支持多种促销。运行环境:.net 4.0登陆信息用户名:1001 密码:123456内置商品信息,商品编码可输入00001000 - 00010000,测试效果相关功能键F5 结算 F9挂单 F11商品查询 F8退货 Insert单品取消 Del整单取消 F12开钱箱F2 会员 Ctrl+Z退出系统 Home 锁屏 相关源码待公开

假人有限元模型

假人模型,车辆碰撞假人有限元模型,适合做乘员安全的研究者利用

上班第一天,老板就甩来30G文件是种什么体验...

如果给你一个包含一亿行数据的超大文件,让你将数据转化导入生产数据库,你会如何操作? 上面的问题是接到的一个真实的业务需求,将一个老系统历史数据通过线下文件的方式迁移到新的生产系统。 由于时间紧,而数据量又超大,所以设计的过程想到一下解决办法: 拆分文件 多线程导入 拆分文件 首先我们可以写个小程序,或者使用拆分命令 split 将这个超大文件拆分一个个小文件。 -- 将一个大文件拆分成若干个小文件,每个文件 100000 行 split -l 100000 largeFile.txt -d -a 4 s

fly1north的博客 1267

Camera2Demo

在Camera2 的基础上进行封装,使得Camera2一堆初始化逻辑与Activity分离,降低耦合度,完成预览拍照并保存的操作

上班第一天,老板就甩来30G文件这班不上也罢

如果给你一个包含一亿行数据的超大文件,让你将数据转化导入生产数据库,你会如何操作? 上面的问题是接到的一个真实的业务需求,将一个老系统历史数据通过线下文件的方式迁移到新的生产系统。 由于时间紧,而数据量又超大,所以设计的过程想到一下解决办法: 拆分文件 多线程导入 拆分文件 首先我们可以写个小程序,或者使用拆分命令 split 将这个超大文件拆分一个个小文件。 -- 将一个大文件拆分成若干个小文件,每个文件 100000 行 split -l 100000 largeFile.txt -d -

wdjnb的博客 107

复分析 阿尔福斯(Ahlfors) 第三版答案 英文

答案分为十章,有部分习题没有答案,全英文复分析阿尔福斯(Ahlfors) 第三版答案

提出离职后,老板说年底给你涨3000,你还会选择走吗?

回顾行业发展,网络安全的红利期集中在那几年,2022 年下半年起行业开始出现裁员潮,而我恰好赶在 2022 年上半年完成跳槽 —— 当时刚参与完成北京冬奥安全保障项目,新工作带来了 1 万元的月薪涨幅。但无论属于哪种情况,只要你提出离职后选择留下,领导大概率会开始制定 “Plan B”,培养后备人员准备替代你 —— 因为在领导眼中,你的 “忠诚度” 已受质疑。

2301_79455190的博客 892

mysql导入30gsql文件_老大甩给我 30G 文件,让小黑哥几天内所有导入到数据库

老大甩给我 30G 文件,让小黑哥几天内所有导入到数据库楼下小黑哥 小黑十一点半 数据库Hello,你们好,我是楼下小黑哥~小程序若是给你一个包含一亿行数据的超大文件,让你在一周以内将数据转化导入生产数据库,你会如何操做?多线程上面的问题实际上是小黑哥前段时间接到一个真实的业务需求,将一个老系统历史数据经过线下文件的方式迁移到新的生产系统。并发因为老板们已经敲定了新系统上线时间,因此只留给小黑哥一...

weixin_28930803的博客 628

一个IBM人的离职泪:伟大公司,SB老板,苦逼员工

在此轮IT企业格局大调整中,IBM似乎是最安全的一个,国内新闻也波澜不惊。但在波澜不惊之下是怎样的暗流涌动,一位在IBM工作14年的经理级别高级员工离职感言可窥一二。付出14年青春,原本要一辈子在IBM的人,为何在14天内速速收拾行囊?文中所描述的IBM各种内因,发人深省。 相濡以沫,不如相忘于江湖。18摸(钛媒体注:IBM内部人喜欢对IBM的一个戏称)是我的第一份工作,目前也是我的最后一份。是

hualusiyu的专栏 2189

一个IBM人的离职泪:伟大公司,SB老板,苦逼员工 (zz.IS2120.BG57IV3)

一个IBM人的离职泪:伟大公司,SB老板,苦逼员工 按:外企相比以前更懂中国;各种cost down呀 //z 2013-03-05 22:09:18.T128139434@is2120.csdn.bg57iv3 [T13,L225,R2,V298] 钛媒体注:在此轮IT企业格局大调整中,IBM似乎是最安全的一个,国内新闻也波澜不惊。但在波澜不惊...

440

老大甩给我 30G 文件,让我几天内全部导入到数据库

如果给你一个包含一亿行数据的超大文件,让你在一周之内将数据转化导入生产数据库,你会如何操作?上面的问题其实是前段时间接到一个真实的业务需求,将一个老系统历史数据通过线下文件的方式迁移到新的...

艾小仙的专栏 348

mysql导入30gsql文件_老大甩给我 30G 文件,让小黑哥几天内全部导入到数据库

老大甩给我 30G 文件,让小黑哥几天内全部导入到数据库楼下小黑哥 小黑十一点半Hello,大家好,我是楼下小黑哥~如果给你一个包含一亿行数据的超大文件,让你在一周之内将数据转化导入生产数据库,你会如何操作?上面的问题其实是小黑哥前段时间接到一个真实的业务需求,将一个老系统历史数据通过线下文件的方式迁移到新的生产系统。由于老板们已经敲定了新系统上线时间,所以只留给小黑哥一周的时间将历史数据导入生...

weixin_39631689的博客 420

一个IBM人的离职泪:伟大公司 SB老板 苦逼员工

钛媒体注:在此轮 IT 企业格局大调整中,IBM 似乎是最安全的一个,国内新闻也波澜不惊。但在波澜不惊之下是怎样的暗流涌动,一位在 IBM 工作 14 年的经理级别高级员工离职感言可窥一二。付出 14 年青春,原本要一辈子在 IBM 的人,为何在 14 天内速速收拾行囊?文中所描述的 IBM 各种内因,发人深省。 此文为该离职人员授权钛媒体匿名发表,经过钛媒体编辑,转载请注明出处,并附上本文链接:

663
上一篇: 字节二面:面试官问我MySQL怎么调优,我只说了一句话就被看穿了
下一篇: 为什么大家都用Spring Cloud ,作为一套微服务治理的框架它凭什么这么牛?
Java架构师小森
博客等级 码龄5年 23粉丝 32原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值