RedisMasterNode

G304 实测可以，基本天天打游戏，5 号电池一节用了 5 个多月，还正常的，但是身边有全新的正好替换掉了。

在 gHub 里面简单设置一下降低一些不必要的性能参数应该可以用很久很久很久吧

当年一加 1 从 14 年用到了 18 年还在服役，真的是神机。。。

@sss15 时间如果+8 的话哪天去美国了是不是又会骂他没有-8 hhhhhhhh

@wsszh 有趣的 repo ，关注一下，感谢

@yongzhenchen682 数据可以是提交数据，也可以是查询数据，你怎么去定义呢？

服务 A 向服务 B 查询了一堆数据，数据是从 B 流向 A ，所以你觉得 B 是上游，A 是下游；

服务 A 向服务 B 写入了一堆数据，数据从 A 流向 B ，所以说 A 是上游，B 是下游。

根本就没办法解释和通用地定义“流向”和“依赖”，文字游戏是没啥意思的

@v2nika 听起来没什么问题？一直都是这么用的。不需要强加自己的理解于别人之上，面试只需要表达清楚意思就可以了。

上下游的定义一直都有（至少）两类，

第一类: 按 action 的方向定义
上游: 指收到了哪里的请求 / 要响应给谁。
- 上游服务调用了我，我要响应给上游服务。
下游: 发请求给谁 / 从谁那接收它的响应。
- 我正在调用我的下游。

第二类：依赖关系
上游: 发请求给谁 / 从谁那接收它的响应。
- 我正在调用服务的上游
下游: 指收到了哪里的请求 / 要响应给谁。
- 下游服务调用了我。

面试里面结合语义这些东西并不值得纠结，而且既然不是个所有人都同意的东西，hh ，我也觉得会有人发帖：

```
为什么这么多后端开发上下游不分?
面试了不少于 100 个后端工程师, 初级到高级都有. 有相当一部分 (>70%) 的人, 都会说我做的服务调用上游服务如何如何.
为什么会这样? 只要认真思考一下, downstream 和 upstream 的概念不至于记不住吧?
```

@ye4tar 比较接近，但是想要个解决方案，至少能把数据报给 prometheus （或者别的也行），它应该是个 Linux 系统能跑的进程才对，类似 Node Exporter ，但是 export 出去的内容是“外部请求的黄金指标”