@daimubai 与你完全一致

@luistrong 你的第一个问题 “好像感受不到“，这种其实是一种预期规划，你的预期是钱越来越不值钱，你的收益越来越高，收入的浮盈赶上利息带来的成本。但是这只是一种预期。 实际上你减少这 5 年的利息是 实打实的 钱！而且如果你后面预期规划真是这样，那你照样可以第二年又多还一点，这样每年都叠加还，这样你的总 利息就可以降到更低。10 年换房这种更不影响你提前还贷，你归还了本金，你卖房子后还银行的本金也会变少。始终记住一点， 减少占用银行的资金时间，付出的利息成本就是会变低的。

第二个问题：借贷！不建议这样做，往往这种东西看似只有 4.3 的利率，但是其中有很多隐形成本，比如其中的手续费，过桥费，中介费，都可能是成本，可能最终算下来并不划算，而且这种借贷 如果是正规渠道，那么钱一般不可以直接用于房产，其他渠道可能有更多的风险。 而且借贷一般年限比较低，是否考虑有抽贷可能性？

@luistrong 要分情况，如果你现在手上钱比较富裕，然后能够预见未来 3 年内工作能够比较稳定，就建议缩短期限。这样你还款的速度就会变快，贷款使用成本最低。 如果未来 3 年内可能不太稳定，只是现在手上这笔钱找不到好的投资渠道，就选择减少月还款，这样可以把这笔钱收益最大化，同时能够减轻未来还款的压力

建议提前还，但是是分批次提前还， 别去看现在银行什么利率理财产品吹嘘的年化%5 ，但是记住那是投资不是银行的存单。现在 4 大行的银行大额存单 3 年 20W 起一般在 3.5 +-0.2 这个样子。从经济发展模型上来说，存单利率会波动向下走。但是你的贷款利率可不会这样。如果你房贷每个月按 5000 算，一年还 6W ，如果有闲钱，你可以选择再多还 6W 。
最终的目的就是，减少 **占用银行资金的时间**， 你的成本才会变低。 别去想什么通胀问题，那都是支出通胀，收入极低缓慢上涨。公积金不在考虑范围内
如果你有能力让你的钱超过当前房贷，大概率你也不会问这个问题了。

不严谨回答：如果是 mongodb 全量数据，可以考虑采用 mongodb 的内存引擎 你可以了解一下

先去医院检查一下，再决定做不做， 因为不是你想做就能做！ 还要看眼睛的情况，有因为晶状体薄的做不干净，有因为间歇不够植入晶体也不得行的。检查建议到正规三甲医院去检查。
如果本身条件不够，那不就不用烦恼了。哈哈

八方中置电机 你搜索一下就明白了

@hopingtop ..... 按了几次 CTRL 回车，导致就没有回答完。。。狗头。。。

Docker 使用了 Linux 的 Namespaces 技术来进行资源隔离，如 PID Namespace 隔离进程，Mount Namespace 隔离文件系统，Network Namespace 隔离网络等。一个 Network Namespace 提供了一份独立的网络环境，包括网卡、路由、Iptable 规则等都与其他的 Network Namespace 隔离。

host 模式类似于 Vmware 的桥接模式，与宿主机在同一个网络中，但没有独立 IP 地址。一个 Docker 容器一般会分配一个独立的 Network Namespace 。但如果启动容器的时候使用 host 模式，那么这个容器将不会获得一个独立的 Network Namespace ，而是和宿主机共用一个 Network Namespace 。容器将不会虚拟出自己的网卡，配置自己的 IP 等，而是使用宿主机的 IP 和端口。

@hopingtop 但是 HOST 网络模式应该和宿主机共享 Namespace ，如果中间没有其他代理，按理能取到 IP

remoteAddr 是真正连接你服务端的 IP ，但是往往一次网络请求可能会经过几层网络代理，那么你渠道的 IP 就是最后一层代理，并不是真的 ClientIP 。
因为 Docker 他有网络模式，默认情况下（ bridge ）所以他其实就是相当于一层代理了。

今年的 实体 物品怕不便宜，毕竟有通胀等问题

frp 是你上面描述的用过的方案吗？
其实你大可不必担心域名和端口泄露问题。
生成一个随机的 X 位字符串,当二级域名不就行了吗？是不是可以当密码的思路用？
如果你这样还担心泄露，域名和端口，还担心你的 NAS 破解验证。 你就当我什么都没说吧

@hopingtop 这里只单纯讨论为什么可能出现超时，不讨论为什么要这么用 ETCD

一百万数据并不多的。如果在读场景少的情况下。 从节点不多的情况，一般不会出现这样的情况。
出现问题，主要是看 client 的使用方式是否有问题，还有就是 ETCD 的配置。如果是云服务，一般是大多数场景的最佳配置。特别注意一下 关于 ETCD 存储大小和压缩相关的设置
看看 client 端吧。 如果是基于 v2 版本的 HTTP ， 也要注意一下 Request 包是否有什么问题。
还有就是每一个 KV ，V 是否过大？
如果会其他语言，可以试着换一种语言的 Client 试试

@liuhan907 嗯，很多问题都是选择合适的。没有最强只有最合适！适合自己的使用场景就好。
感谢一起沟通这么多！

后台 Demo 已经放到 README.md 上面了

@liuhan907
1.配置简单对比 Qelog 我不赞同，你可能是对比其他的日志服务。当前背景是中小团队和个人项目，不一定拥有 Prometheus，况且 Label 的方式和普通日志的方式还是有一定的区别。这里应该是选择？需要一个 Prometheus 还是需要一个快速解决问题的 日志系统？
2.我这里 mongodb 并没有采用他自有的 分片集群配置，自有的 sharding 配置和维护确实有点繁琐。我是根据程序自动路由到不同的 mongo 库实例中
3.关于远端存储如果选择 S3 我认为在存储这里不知道会不会有问题，特别是索引，还有是否会有碎片化的问题，特别是容量清楚的时候，KV 的存储方式，不清楚是否会 扫描 K，然后在删？
5.对于不知道 Prometheus 报警规则的，没接触过，又是一个学习成本。
6.因为没有使用 sharding 集群，所以每一次，每一个租户都相当于独立拥有 单集合的批量写入，达到最高性能。mongodb 的 sharding 反而会更慢，因为他会把一批数据打散，不能充分利用批量写入特性。也不利于数据维护，
关于量大删除，这里为什么会分集合，对于 mongodb 如果要删除一个集合当中的某些数据，其实开销是很大的。而且删除的数据空间也不会马上被系统回收，还是会被当前集合占有， 但是对于 drop collection 的开销就很小很小了。因为在删除这个集合的时候，同时集合是不会承担写入请求的。而且占有磁盘会马上释放。所以采用这样的删除逻辑可能更优。

以上几点是对应几点的，解释。你看看是否还有疑问

@HertzHz 后期我更新上去

@liuhan907 我上午看了一下 Loki 的文档，并总结了一下。
可能有理解不对的地方，还请指出，一起探讨