```如果直接用销量排序，对于一些没有销量的品不够公平。```
如果这个是老店铺的新商品。排序的时候可以参考店铺的属性作为一个参数
这块对于新商品且新店铺的情况下。可以随机分一些流量给新商品。看点击率/互动率之类的指标。如果这些指标不错就分给他更多的流量（更好的排序位置。）可以去参考下冷启动～

```测试也测试了，现网上线了。但是 dev_1.0 的分支没有合并到 develop ```
不允许非生产分支的代码部署到 prod 。
cicd 的流程不明确。

1. 一般会有 local.yaml 文件来保存本地的允许配置。这部分是不推到 git 上面的。
2. 测试环境只有一个的话。不建议反复该来改去发布当本地环境来用哦。

看你加 v2 的目的。
如果是只更新 user 相关的接口。/users/v2/userInfo
如果是全部接口都要更新。/v2/users/userInfo
如果是你只要更新一个接口。 /users/userInfoV2

如果熟悉 gurobi 的话可以用这个来做计算。高性能来解决优化问题的。
比如这个例子:
https://github.com/carloalbe/A-nurse-scheduling-problem-solved-with-Gurobi

不会用模式二的。针对于第一个模式一的问题。可以开发两套系统。ka 和 smb 。两者的需求本来就不一样。

```可以看到，Multi-threaded 多进程任务的情况下我们可以看到相当大的性能差异。``
thread 是线程的意思

以及你的对比结果：
Multi-threaded time taken : 8.21 seconds
Multi-threaded time taken : 4.86 seconds

Multi-process time taken : 5.64 seconds
Multi-process time taken : 6.14 seconds


你说的和你跑的结果大相径庭。。

其实现在 hr 筛简历不怎么看技术内容。就这么几个点：1. 工作公司 2. 职级 3.毕业院校。这三个点至少得有突出点。否则不大容易过简历筛选，至于做了啥。不是很重要。区分 sde/de/mle/ds 啥的就够了。这个人聪明学得快至于有些没做过不大所谓。对于初级/中级工程师来说。（ p7/p7 以下）

btw: 小公司招聘不清楚。

如果有说错的地方见谅。

down time 要最少的的话。建议是先扩容。再接个外部的数据库当 slave （会利用 binlog 的）。直到数据一致之后切换主从。然后把 master 给删了。。
如果 downtime 可以接受的话。先把网站关了。然后数据库直接迁移到新的库。然后再更改链接。。

付费的话。云上有一些现成的工具。。

不如买个水獭掌柜的。还便宜。

explain 看一下呢？ 都一样嘛。