@ryd994 我觉得 lz 的意思不是无脑 redis 锁，是中文环境下的文档搞得好像只有这个方案，etcd/zk 的分布式锁成了原罪一样。实现需求不是非黑即白。还是要考量业务因素。但我比较反对的是说大额交易才要考虑 cp 。这点我观点跟 lz 相同，和钱打交道只能是 cp 不能考虑 ap 。哪怕只有 1 毛钱的东西。

明显是设计问题…
90%/数据库都没有的数据，你却要求缓存有…你品…你细品

还有都贴官方推荐，所以用。那么问题来了，数据不一致的时候，哪怕一辈子就一次，偏偏几千万订单。你猜是你负责还是所谓的 redis 官方负责？

我一直对这种以内存为主的单机行为分布式锁抱有怀疑。内存天然不靠谱。连个分布式协议都没有…我没想明白为什么这么多人觉得这个玩意是绝对可靠的

其实我也一直纳闷为什么动不动就是拿 redis 做队列，动不动就是 redis 做分布式锁。还满是优越脸…那您 redis 崩了别来找我啊，云端 redis 运维够简单了吧，中断 30s 够快了吧。抱歉，就是有人要把 redis 当核心外部依赖…我昨天一看，所有服务都是这样，在 k8s 的环境下，如果 redis 挂了，全部雪崩…………

cpu，内存，磁盘 io 。都看一下。网络基本很难你能把 aws 的弄满了。

aws 没这么脆弱。带宽是 5G…你能跑满？
大概率是 cpu 跑满了。所以 ssh 都回不去了

对小规模公司推 k8s ？我缓缓打出个…？
lz 看样子需求很小。业务规模不大，非常简单。阿里云负载均衡按道理肯定用了。本质上不停机都是围绕这个来的。要复杂可以复杂。要简单可以简单。

不是负载均衡本身能这样。要做一些工作的。我的 v0.1 版自动部署就非常简单。我的例子适用 lz 。我到这家公司的时候启动模式也是 nohup 。更新模式跟你一摸一样。
我做的第一件事是不要手动去 nohup 启动。先不考虑滚动更新。这是一件很简单的事，1-2 个工作日就改造玩完了。jenkins 一个 job 的事。
第二件事，开始考虑挂了拉起来。既然这样。我换个思路，系统启动要做到自动拉当前的 jar 包。启动。这也很简单，程序启动本来就有逻辑了。只要解决在系统启动得时候如何拉包的问题就解决了。
第三件事，滚动更新。我是 aws，研究一下负载均衡和弹性伸缩。
首先负载均衡会自动检查节点是否健康，如果不健康，摘除并且关闭节点，其次，弹性伸缩会保护一定要到一个数额。那这个问题就简单了。因为第一件和第二件事我已经做了，只要配置好了弹性伸缩和负载均衡。效果就出来了。那如何滚动更新讷？一台一台关掉就是了，关一台检查是否启动成功，再关下一台。其他都不用考虑。到此，负载均衡和弹性伸缩就都 work 了…接下来就是要解决日志的问题…

顺便说一下…我们有 80+微服务。这套逻辑跑了小半年，最后当然我可以踏踏实实的切刀 k8s 里。废话…200 多实例多浪费钱啊…

jwt 和 refres token 是两回事…用 jwt 可以不用 refresh token 啊。用 refresh token 也可以不用 jwt…

其实不处理是不是也可以…………
因为又不是你的车违章…按道理对你没任何实际影响

我家两只猫主子…dyson 用着还不错。
为啥说专利壁垒，因为销量第一得一直是 dyson 啊…用脚投票总不会错。看评测会发现这也不能买那也不能买，非常恼火。大部分评测都有倾向性，所以我是看销量来买。

公司攒一个黑苹果，就不背了

奇怪？转给我解忧愁

毫无疑问，戴森。专利壁垒

另外 ps…要测试速度很简单…做一百万次除法就是每次查重需要的时间和 cpu 消耗

@kwklover 又不是没次都是建 100 万次…每次入的时候计算一次这个新文档而已，就是第一次慢

vim 模式

每个文档提交的时候酸一个向量值。查重就是比一下得事。应该飞快。比你查前 300 字，拆句，搜索快 n 倍。算法不超过 100 行代码

简单的向量相似性即可…