这类在运行期 0 变更的通常直接扔内存，方案楼上都说的差不多了就不补充了

杭州的有无？

这么卷吗？是都降薪了么

4G 内存够够的，java1g ，mysql1g ，nginx0.5g ，完美

linux cron 每天晚上 3 点定期拉取 docker hub latest 镜像并重启，java 服务打包成 docker 镜像，内置一下 flyway ，最好买个 flyway 的授权

用阿里的 dms 啊，生产环境禁止外网这个没啥疑问吧？

1.为啥会有这种需求？
2. 能不能在数据生成的时候基于需求扔到对应 list 里去，比如 123* 的 string 放到 123 的 list 里面
3. 换其他服务处理，比如 es ，数据量不大直接 mysql

定时任务和延时任务都是绝对时间，kafka 实现了时间轮，但延时队列这玩意还是比较复杂的，因为延时任务存在不可预期性，比如一个 task 是十分钟后执行，还有一个 task 是半年或者一年后执行，这种情况下直接使用单个时间轮会导致圈数过大，而且一个槽中的所有任务分发也是比较复杂的逻辑，而且 kafka 的定位是实时流处理平台，这种业务支持也没啥太大好处。

真实

@JDog 学习了

@zoharSoul 明天加个 skywalking 监控一下看看，现在用 jprofiler ，对性能影响比较大，有没有其他的推荐的？

@zoharSoul 哈哈，这个可以试一下，不过看 mysql 监控 cpu 一直没打满，尝试增加数据库连接池线程数反而性能更低，所以一直想先压榨出应用极限性能

@pkwenda 补充一下，期望 RT99 80ms 内，tps1800 左右?

然后 1c1g 是 mysql 的配置，买的单独的服务，应用机是 2c4g ，只跑了这一个服务，配置了 2g 内存
按照您提供的意见，明天我调整到 4c4g 试试。看阿里云控制台 ecs cpu 峰值大概也才 70 左右，线程数估计是控制在 120-150 左右比较合适

jdbc 连接池用的 HikariCP ，配置是 4 个连接，orm 用的 mybatis plus ，初期调优的时候把接口 A 的批量插入优化了一下，有小部分的提升。

日志默认用的 springboot 的 logback ，打算把整体压到 80 再试试 log4j ，然后再试一下 log4j 全异步日志的性能差异，现在就是卡在 tomcat 线程池调优这块了。

TPS/QPS 基本是 1:1 ，接口 A,B 都主要是插入或者更新操作。

压测用的阿里的 PTS ，直接用他们的机器，单机封顶在 2000QPS ，这个可以调多点，不过试了下结果还是一样的，甚至延迟还高了一点。

10 个线程每个线程查 100 条，然后更新原子变量，完事。一次性加载一百万条，只能加钱。

+1

这种十之八九是洗稿的，拿里面代码片段随便一搜就能找到原文

楼主写的没问题，这个 list 一看就知道是从数据库拿的，也判空 list 了，如果 list 里面还有元素能为空的话，先把数据提供方拉出去打一顿吧。

补充一下回复，关于 code review ，比较好的做法是完成一个业务功能提交一次，单次 review 尽量保持在 300 行以内，以 Java 为例，使用 mybatis 或者 jpa 对数据表进行建模生成 model 后并添加对应枚举后，提交一次 review ，这次 review 速度一般比较快，基本上都是按团队规范和机器自动生成的，没啥太多 review 的地方，最多检查下是不是建模有问题，一般一两分钟搞定。接着就是常规的功能 review 了，通常建议拆分为业务功能多次提交，以最常见的订单系统为例，会拆分出例如订单分页接口，订单详情接口，订单提交接口，这三个接口分别提交三次 pr+review ，主要目的是保持 review 的单个逻辑连续性，如果单次提交在 1000 行以上，作为 review 评审者，其实相对难度较大，通常还需要 clone 到本地详细查看，成本太高，可能就直接点通过省事了，关于 review 其实从出发角度来看，其实是为了提升整体代码质量，避免代码崩坏，减少后续维护成本。比如团队如果有实际的代码规范的话，reviwe 主要就是关注代码规范，加上潜在 bug 发现，以及一些常规的代码质量改进，例如可以用新特性或者其他更好的方式去实现。关于你提的这个问题其实我觉得也挺有意思的，其实还是那个问题，你们老大呢，工程实践这玩意说实话就是有和没有在短期没什么太大差距，都是长期来看才有价值，否则也没有那么多的人会写垃圾代码了

先问个问题，你们老大呢？