"不同机房的应用实例使用同一个 DB" 这不就是天然实现分布式锁的基础设施么，没必要纠结非要使用 redis ，把 redis 分布式锁 setnx 和 expire ，用数据库的方式实现一遍就可以了呀，
举个例子，来个 lock 表，lock_name 作为唯一索引，加一个 lock_status 状态,expire_time 过期时间，
获取锁的时候 update lock set lock_status = 1 where lock_name = xxx and (lock_status = 0 or expire_time<now())
释放锁的时候 update lock set lock_status = 0 where lock_name = xxx and lock_status = 1

@antinomii #12 还加了 90 上了个 850w 的电源，萌新入坑果然就是先交学费的

https://i.imgur.com/3Ak84oJ.jpeg 前两天整了一套，发出来参考下，本人萌新基本只懂一些概念，在 x 宝上找到了一个配置，店主好像是个 B 站 up 主来着

@wxf666 #23 大佬动手能力真强呀，这个和之前 1brc( https://zhuanlan.zhihu.com/p/683955185)有异曲同工之处了，反正按照 po 主的意思，顺序扫一遍全表，然后内存计算推送时间过滤出超过 24 小时的，时间应该是快的，不过 sqllite 纯 SQL 还能这么快，还是挺让人震撼的(之前没怎么接触过 sqllite ，都是 pg 和 mysql 多一点)

如果是数据已经写好，不想改动业务表的情况下，要计算相邻推送的时间间隔这个就是纯读取相邻两条数据，然后计算推送时间间隔，这种必然要扫描全表的，那感觉可以按照时间顺序使用流式的方式读一遍全表，然后用程序计算好了，回写一张独立的推送间隔表，如果有增量数据那就记录一下末次处理的业务表 id ，然后基于记录的业务 id 定时扫表，或者监听 binlog 转 kafka 这种消息方式
如果业务表支持改造增加一个字段写入的时候就直接记录推送间隔就好了
有了推送间隔，后续基于此做分析可以使用纯 SQL 就能搞定

有点东西 https://i.imgur.com/io2SM1h.png

@chen90902 #85 已收藏 感谢分享

OP 你还是好好想想吧。至少父亲还健在，要知道不少人想和自己父亲说上一句话都已经办不到了
"子欲养而亲不待" 这才是遗憾

首先，允许我表达一下感慨 “虽然我不懂，但我大为震撼“.JPG
我记得之前看到过一段很经典的话 原话大概是这么说的 : ”当思想出于虚无主义时，行为开始偏向享乐主义，性格开始偏向利己主义。随后一个人的天性就会变成一个安静的绝望者，极端的虚无主义者，当你的欲望不能满足，那你就会痛苦。满足了你又会开始无聊，人生就在痛苦和无聊之间摇摆。“
感觉楼主的情况很像这种虚无主义了，怎么对抗虚无主义，这是 ChatGPT 的答案，可以作为参考 https://chat.openai.com/share/8a5c05bc-8714-4dc0-9289-f3e78175621b

为啥没有“卧槽原” 哈哈

谢谢楼主提醒，已经卸载

你是真该死呀(手动狗头)

@lp7631010 大兄弟 要注意保护用眼，不然就得看眼科了

@bluekz 如果我是卖家，有加价肯定也优先满足加价的

@dbow 是呀，希望大家都能早点好起来，进入正常生活节奏

@cheng6563 狗东还有这一茬，之前使用体验一直不错来着

@binaryify 诶，啥都要抢，日子越过越回去了

@genesislive 我的还没说退款，等等再说，实在不行也只能退款了

@EminemW 没那么快吧，现在顶多园区内跑一跑