缓存后直接等 success, success 后直接用缓存里的数据更新, 不重新请求.

服务端有其它客户端提交的更新, 用服务端推送, 客户端判断 id 是否重复再刷新.

配合虚拟机用 vscode remote 感觉可以, 全放虚拟硬盘.

有的人选择"有则改之无则加勉".
见得多了, 我选择成为一个无素质的人.
上次一堆老爷爷老奶奶站非机动车道上聊天, 我骑车路过说了句麻烦让一下, 还被碎碎念了.
我当场就说了句 wcnm.

方法 2 依赖两个脚本, 一个 docker 启动脚本一个 redis.conf, 两个脚本还互相依赖, 比如 redis 开放的端口和 docker forward 的端口是互相依赖的, 分开在两个文件中配置就会带来各种问题. 用的久了必然选 1.

另外有些人可能以为 2 可以在不重启 container 的情况下重载配置. 实际上操作起来比较麻烦, 因为修改 host 上的 redis.conf 的时候, 很多情况下会改变 redis.conf 的 inode, 而 container 内部的配置文件不会跟着一起改变, 这时还是要重启 container.

@xgfan 50 个参数也能用 1, 因为你启动 docker 用的是另一个脚本.

dns 代理目前还是免费的.

思路还可以,吸粉的同时还筛了粉

我拿个人微信帐号前后收过几十万款, 没出过任何问题. 我感觉你们就是被客户举报了.

@Illusionary 那是你不知道凌晨三点服务器网络波动谁要起床.

而且如果运维不一起加班, 你让谁来部署. 该加的班一分钟都不会少.

@nnd 责任大, 薪水少, 懂得都懂.

意思是你四个字的 ECMA 都能拼成 EMCA, 还要吐槽别人手写了几百个字符有笔误的.

wiki.js 有人用过不, 貌似功能上差点意思.

三百万文件扫两天? 一秒扫 17 个文件? 你这索引是不是把文件内容也索引了?
我觉得肯定没到机器性能问题这一步.

tail -c 1234567 "/path/to/script.sh" > /tmp/your/temp.tar.gz 2> /dev/null
gnuzip -xzf /tmp/your/temp.tar.gz

打包的时候把 tar.gz 输出到 script.sh 后面.

需求很常见, atlassian 的安装包都是这样的.

@Aynamic archlinuxcn-keyring, typo?

最近经常说的一句话, "有点道理."

有啥好争的呢, 如果能理解他

亲测被污染得很严重, 科学浓度不够.

@594duck 不是, 你让大家评评理, 我哪里说过十个服务 25M 啊.... 你这人性格真的..

@janxin 不至于真的只有两台吧.. 这群人说话不是一千台以上就是两台以上的, 太夸张了.

和你需求基本相同, 用 lrange + ltrim, 每次取固定数量, 代码大概五十行吧, 跑了几年至今没遇到过超时和内存溢出.

仿佛来到了卡巴, 20 块钱配置出的问题, 一堆人让买八路泰坦.

@janxin k8s 又不是只解决 ha 的方案, 不用 ha 部署上也比 systemd+docker-compose 方便点.
@594duck 你是何来的概念觉得 512M 跑不了十个 docker, 我开发环境的 overhead 一共 25M, 还是虚拟机+docker, 开一个 chrome 页面的内存远大于一个 docker..

U1S1, 我严肃怀疑是网警在钓鱼.