认真说人家说次品率 30%，每箱又是 100 个，又是随机整批装箱，那么大概率是符合统计学结果，每箱不好的估计大概率就是在 30 个上下，所以不用纠结这个，这种情况研究概率大概率不会帮助你挑到好的，还是约定次品比 30 高多少就退货更靠谱

挑选的 3 个都是正品的概率似乎是 1-0.3*0.3*0.3 ，但是按这个流程似乎各箱之间是独立事件，所以通过拿出来的 3 个决定买哪箱，3 个是好的坏的情况对你买整箱情况似乎影响不大啊

@BenchWidth #10 没懂 nacos 还能影响这？也不是每个请求都需要请求 nacos 吧，那 nacos 应该和并发无关才对

如果有经常会出现短时间内并发数剧增的情况，建议限流，服务有最佳处理延时和 qps ，限流排队要比直接打到服务上效率要高得多，可以测测看，一般一个节点给 64-256 并发应该就最佳了，而且入股是短时限流排队更有利于削峰吧

3000 并发已经很高了，200-400ms 延时，每秒 qps 过万了吧，502 估计就是 #5 楼说的问题，网关无响应被标记为不可用节点了，3000 并发已经是很高的值了，每个请求都要查询数据库的话，想不超时估计需要各种优化了

@morty0 redis 只能单主的，不存在网络分区问题吧，网络分区后 redis 在哪个区只有哪个区能用，都不在就都不能用

@Nnq #11 dev 和 test 分支其实还有个用途是，dev 是开发分支所以应该自动更新部署到开发患教，test 则应该自动部署到测试环境，master 是最终版肯定是只包含可发布的代码才对，所以一般都是测试完成从 test 分支合并过去的

微服务 devops 还有个麻烦的事情就是，假如同时有个功能版本同时开发，那就需要部署多个不同版本，服务非常多那这个工作量就非常大了而且非常耗资源，所以我们的做法是标准的 dev 和 test 分支其实是基础版本，一般不能直接用于开发测试，而是每个版本再次创建 dev-v1 和 test-v1 这样的版本分支，然后在通过 CI CD 自动部署到 k8s 集群里，这个过程只有你当前版本需要改动的项目才建版本分支部署项目，然后通过流量染色和服务网格来组一个完整服务切面，这样就能用很小的资源和工作量给每个版本一个相对独立和完整的环境了

通过流量染色和服务网格来组一个完整服务切面这个过程也不复杂，就是前端请求里应该都带标准的版本、设备、用户标识信息，这些信息到后端后会在整个请求链路中传递，然后通过服务网格的流程来做流量匹配，如果某个服务有对应版本就请求对应版本的服务，没有则由基础版本来处理，这样你只要部署你需要修改的项目，然后用当前版本的 app 访问就能访问到你修改的服务上去，无论你的服务位于请求链路的前面和后面，而创建 dev-v1 和 test-v1 分支部署到 k8s 并注册服务网格信息这个过程完全由 CI CD 自动完成

比如整个微服务由 200 个服务组成，现在有一个版本 v1 的迭代只需要修改项目 A 和 B ，那么你只需要在项目 A 和 B 创建 dev-v1 分支，这样你就有了一个独立的 v1 版本的开发环境，其余的项目无需任何处理，测试环境也是一样的

这样一个 v1 版本的整个开发测试发布过程就变成了 dev-v1 分支完成开发，然后基于 dev-v1 创建 test-v1 提测，测试完成等到发布周期是合并进 master 统一发布，发布后 master 再合并到 dev 和 test 分支完成基础版本更新，最好删除 dev-v1 和 test-v1 分支清理环境和资源

也许只是你没装宽带所以你爸妈才不会上网，而他们说不会上网也许只是想省点钱和没用过，如果费用无所谓又有条件，先装上再说呗，也许后面就发现他们其实会的，你不给创造条件那肯定不会了啊

没必要吧，反正各 app 也只是代销，就算人家倒闭了你的基金理财也不会有啥事，找个大一点的平台或者招行这样的 app ，就算有啥事偶尔出点毛病基金理财啥的难道你还能立刻去买了止损？股票这种虽然你能立刻卖，但是吧一般小散来说除了自己闹心，早卖一点晚卖一点最后一看估计也差不多，人家挂也不可能挂几天的，搞这么多说不定自己哪天记错了或者收益损失算不清买错卖错损失更大来着

如果是 CI CD 后端微服务的话其实感觉都不好，在这个流程中，GIT 的分支管理应该满足三个不同需求

开发-》不同人不同功能分别在不同分支开发 codereview 后合并进总 dev 分支
测试-》按不同测试提测进度合并到 test 分支然后构建测试服务自动完成部署更新
发布-》测试完成合并进 master 构建发布版最少上线同时创建 tag ，这个过程可能又有多个不同功能分别开发测试最后一起发布

微服务 devops 流程中 GIT 分支不应该只管理开发过程，测试发布依然用镜像版本号来管理提测和发布进度，感觉过于坑了，因为镜像不能直接 diff 出改了啥，配合 CI CD 后应该随时提测更新发布，一天一个项目更新个十几或者几十次很容易就乱七八糟了完全分不清哪个改动是哪个版本的，所以镜像版本实操性太弱，应该还是以代码来做版本管理，然后在 build 的镜像信息里打入 git 的 commit 信息，然后同时记录到链路追踪日志里，整个就比较清楚了，CI CD 的执行也会比较顺畅

当然以上流程需求其实实际操作上是大多简化运行的，毕竟迭代虽然很多但是微服务体系下单个项目同时被修改的概率还是低很多的，所以大多数情况下只一个人改一个功能应该就 dev test 和 master 三个分支就行吧

既然如此，为啥第一步编译打包 jar 要放在 docker build 里呢，用 docker run 来运行 mvn package 就是了呗，把项目目录和 maven 缓存都-v 映射进去就是了呗，编译完了 jar 文件就在宿主机目录里了，然后再 docker build 就是了

既然如此，直接实现成分布式锁的逻辑就是了呗，谁获取锁成功谁就能操作或者是 leader

且不说各种饲料主要成分就是转基因豆粕，做菜和各种零食的油一大半估计都是转基因压榨的，都吃了喝了十几年几十年了，不止我们吃喝，国外那不照样是，这 up 主根本就是狗屁不通，瞎 BB 哗众取宠，还什么讳莫如深“不能细说”，这种基础品可不是食品添加剂，根本不可能防得住，要是不足够安全，搞这个自己也得掂量掂量

没官方授权很容易认定为非法入侵计算机，违法犯罪啊，你这没钱，重要的啥也没说，这风险是不是有点高？

@CSGO #20 看来你确实和一般人不一样，正常人都是下单后看多久能吃上，啥会管商家花了多久，骑手花了多久，再说如果上班的话点完餐都要继续干工作了，谁有时间盯着看商家完成了没，骑手到哪了，还有美团饿了么给的预估时间也是总时间，他们也不分商家和骑手消耗的时间，美团人家肯定是分析过绝大部分用户的习惯才这么设计的

@stroh #11 只能说你们老板胆子大，万一谁体制特殊或者身体底子不行，或者这样强行感染然后传给家属出毛病的，他也不怕担责

这有啥难理解的，感觉你不像是活在现实中似的，难道你点单后算啥时候送到能吃是从商家做完骑手取走后算起的么？是个正常人都是按下单后开始计算的，如果大多数人期望送达时间是固定的，那么商家做的慢必然占用骑手配送时间，而骑手路上会有各种不确定，那么正常骑手都会期望商家做快点，这不十分合情合理的么