1.5 啊, 这个最稳定, 公司用当然一切求稳了.
上什么 1.6, 1.7, 1.8, 11, 15, 16, 不出问题还好, 一出问题怎么办, 你们公司有能力修改 jdk 源码么

可以做固定时间点的延时重发.
比如说, 1 秒, 10 秒, 30 秒, 1 分钟, 5 分钟, 1 小时, 8 小时, 24 小时延时等.
针对每个延时时间创建一个队列, 生产者按延时需求将数据(数据里包一层最终要去的队列名)发送到对应队列.
然后每个队列起一个消费者, 轮询数据, 到点发送到目标队列即可.
```
headers.put('finalTopic', topic);
producer.send(new ProducerRecord(delayedTopic, key, value, headers));
```

```
// 60 秒延时队列
int delay = 60_000;
while (true) {
ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
for (ConsumerRecord<String, String> record : records) {
long timeLeft = record.timestamp() + delay - System.currentTimeMillis();
if (timeLeft > 0) {
Thread.sleep(timeLeft);
}
var topic = record.headers.lastHeader('finalTopic')
record.headers.remove('finalTopic');
producer.send(new ProducerRecord(topic, key, value, headers));
}
}
```

局域网要什么安全认证

用 M1 安装虚拟机干什么, 找台服务器安装虚拟机, M1 远程上去不香么

我司都是密钥库里随机抽一个再加点随机数当密钥, 谁也不知道密钥到底是哪个.
上线的时候, 先启动在线密钥爆破线程, 在一个更大点的密钥库里用随机数进行爆破, 大概半个到一个小时后, 就会爆破到正确密钥, 服务就启动起来了.

最烦这种在编译过程中干黑活的, 能不用还是不要用了

ZGC 虚拟内存占用翻三倍, 一堆相关监控软件及 linux 内核不针对性升级处理, 谁敢用

键值对直接写到 release 包文件属性里, 搜索的时候, 直接用 windows 资源管理器里对文件属性进行检索

6k 可以了, 别自己组装, 累不死你, 直接上 dell 办公用电脑就行了, cpu i7, 16g 内存, 256G 以上 ssd 硬盘就可以了.
京东我随便找了下, 比如这个:
https://item.jd.com/100012920592.html#crumb-wrap

java 确实一坨屎, 自身 sdk 里连个生产可用的 httpserver 都没有, 还要依靠 tomcat 那一坨. servlet 规范到现在还有什么鸟用, 还有谁会写 jsp 的. 你要是不强依赖 Java, 建议.net core, 简单好用性能也强, 就是太简单了工资不高

@xx6412223 这样不行的, 调用成功并不是代表真的成功了. 死信队列局限性很大的, 大多数网络异常, 死信队列都无能为力. 最简单的, 你先死循环发数据, 然后本地网络适配器里禁用网络再启用网络, 你会发现禁用瞬间, rabbitmq 并不能立即发现网络失效, 数据能照常发送. 要过一段时间, 通常是十几秒到几十秒, rabbitmq 才发现网络失效抛出异常. 那么这个十几秒到几十秒之间发出去的数据, rabbitmq 客户端认为发出去了, 而服务器并不会收到, 如何进死信队列?
对 rabbitmq 来说, 只有服务端 ack 了的才算成功了, 服务 nack 的算发送失败,
还有一种情况是, 长时间既未收到服务端 ack 信号又未收到服务端 nack 信号, 这种数据有可能发送成功了, 也有可能发送失败了.
如果要求一条不丢, 那么在收到服务器 ack 信号时标记这条数据发出去了. 再新起一个守护线程, 定期将已发送但尚未未标记发送成功的数据重发一次.

这要是那 100 个用户都关机了咋办

触发器啊

找到了他的姓名手机号又能怎么办, 去他家堵门吗? 还是说你觉得警察会帮你去把这个人抓起来把手机拿回来给你, 警察要是愿意做这个事了, 中间还需要你去跟苹果费那么大力气吗

网易云笔记啊

m1 就是生产力, 即便你就是拿来看爱奇艺

乘早换工作, extjs 对你后来成长没有任何帮助, 纯浪费时间