看了楼主的博客，感觉很适合就职“基础平台部门”的岗位😼

去年在阿里买的 3 年 229，因为活动限制，用了个新号。我看现在虽然没那么便宜，但也只要 100 块 /1 年，还是很划算的。
https://www.aliyun.com/minisite/goods

@Nadao 发布主题，回复都需要消耗铜币。
点击本条回复的爱心按钮的话，我会偷走你的铜币。不信你点一个试试👀

#16 扫雷？

参考这个
https://v2ex.com/t/651367

@yangyuhan12138
#58 消费者单机的话加个文件🔒。https://github.com/foamzou/lockf
#60 一个队列拆到多台机应该不行的，很多东西要考虑

业务层区分日志重要程度，不希望丢的实时发，可以丢的累积发。

1. @niubee1 #46 @yangyuhan12138 #48，楼主，你在 48L 提的“我们需要有个异步去还原未支付的库存” 与 46L 说的加一个过期字段并不冲突。举个例子，每分钟跑一次，将过期的订单 select 出来，逐个处理。

2. 说下我的想法
- 2.1 轮询(定时)：最简单做就是加一个字段，每隔一段时间轮询一次数据库，逐个处理（弊端：符合条件的订单数太多，处理比较慢）
- 2.2 用延时队列：直接放到队列里，多个消费者并行处理（弊端：订单数太多，mq 积压）
- 2.3 轮询 + 延时队列：就是 39L 提到的。不多余好吗，楼主你不是担心消息数太多，MQ 内存顶不住吗。这个方案就是把即将过期的提前一点入队列，解决了 2.2 和 2.3 的弊端
以上三种方法都没毛病，按实际需求选择。个人建议不要过度设计，怎么简单怎么来，提前优化就提前提高了系统复杂度。如果是我选择，就用 2.2 。

针对楼主的主题内容再聊聊我的一些看法：
3. rmq 的水平扩容？多加机器节点不就是水平扩容吗。楼主提到现在 3 个节点，且队列都设置为镜像模式。看样子架构师很没有安全感呢。一般来说一主一从就可以了，即镜像数量设置为 1 个节点，我认为是 ok 的。这样，随着节点的数的增加，就分摊到不同节点了。因此，楼主提到的“上限还是为单台机器的容量”这个麻烦，实则是自己给自己找的。

4. redis zset 方案。这个方案实则是自己实现了一套不怎么靠谱的延时队列，有现成的 delayQueue 不用，折腾这个是干啥？是有别的考虑吗。

5. RMQ 的延时队列，可以用插件实现，不需要自己用死信队列实现了。

爪机发帖排版乱了，见谅见谅

你这是长连接还是短连接。
短的话，做个透明代理，负责转发就好了。
长的话，写个接口下发 ip 端口，服务端负责维护配置即可

借楼吐槽下 mac qq 的 cpu 占用率和能耗问题。都 2020 年了，什么时候解决这个问题。。有认识 tx mac qq 的同学的帮忙艾特下，谢谢

@SilencerL 看了你的博客，是个有意思的人

1，楼主对实习生的回复风格我也不喜欢，可以友好一些。不过楼主能够倾听 v 友意见做出正向行动和反馈，是值得肯定的
2，楼上各种说 6 点准点下班怎么了的同学，估计是刺激到 996icu 情绪的了。但有一说一，在没解决完今日问题就下班的同学，除非有特殊情况，否则可以看出责任心欠佳
3，楼上还有说“实习生你还能怎样，工资低，没补贴”这种言论就更离谱了，从楼主描述的实习生来看是超出同龄人能力的大神吗？明显不是。既然能力跟别人不在同一起跑线上，又不肯花点时间赶上来，那么，我认为是不适合做 IT 的

我比较在意语言表达细节，2 处: 标题 99 年，45k 。虽然大部分同学通过上下文能 get 到，但还是过于随意了。在我项目组，这样的表达，是要打屁股的哈~

另，希望内推的话，建议贴个简历出来。或者多少提供些有竞争力的技术栈，以及核心优势。否则以你的学历(以及文中浮现的“浮躁”形象)，是拿不到内推的哦

canal 。上面拼错了

楼上同学说的观察者，类似 canel 的工具就是很好的提现

我目前用作:小程序后端，tasker(安卓那个)服务上报，日记提醒，个人博客。现在也没特别玩耍的，需要的时候用用。