monsterxx03

如果你的 BCD 确定都是 ssh 的话, 其实可以, 在 ProxyCommand 里用 openssl wrap 一下, 在 tengine 那边根据 sni 做分发. 如果是任意 tcp 协议不行，除非也能用 openssl 包一下. 参考: https://iyzico.engineering/proxy-ssh-using-tls-sni-and-nginx-8a18f93f709

LD_PRELOAD, eg: https://github.com/a2o/snoopy

@hxndg 他大概是想依靠一个内核机制来解决一个业务层的问题. tcp_syn_retries 是可以设置的, 不同发行版默认值不一样, 一般默认是 6 次

没有 tcp syn retry 不行, connect timeout 就是在规定时间内重复发 syn 包罢了, 没 syn 包不可能握手成功.

你想要的效果理论上通过同时增大 curl --connect-timeout 和 net.ipv4.tcp_syn_retries 实现, 但这么干很傻
1. 对面防火墙可能给你回 RST
2. tcp_syn_retries 最大 255, 理论最长超时时间大概几个小时吧.
3. tcp syn retry 的间隔时间类似 exponential backoff 的方式计算的, 上限好像是 2min? 不确定. 所以你可能对面 server 起来后过了 2 min 钟你才连上.

只能在业务层面轮询.

@avastms 块设备很成熟了啊, aws ebs, gce pv, aws 自己的 rds 和 aurora 也是基于 ebs 的, 动态扩容一直可以, 缩不行, 但就我经验, 大多数业务缩容并不是一个刚需. 多挂载算是个痛点, NFS 这种太弱了, 但大多数应用也不是刚需. 现有的 sds 块设备方案基本能解决我碰到的 90%问题, iops 性价比也算是个问题.

没业务进阶不了, 而且光看 aws 能进阶啥呢, 比如看 DynamoDB, 难道学它那鬼画符一样的 expression 吗, 看它那 sharding key + sort_key 的方案其实就是分布式系统里的常规做法, 最终一致性也不是 DynamoDB 独有的概念. 学 Redshift,又是 OLAP 那套 columnar storage 的东西, spectrum 就是 presto 套皮. S3 能学啥呢, 学 api 吗, 学系统设计还不如看 OpenStack swift, 看看它怎么实现扩容的, 多副本怎么写入的.

aws 上几乎所有东西都有开源替代品, 除非是专门想做 aws 上的解决方案架构(那直接去考那个证), 不然没啥好学的.

@lrvinye 为什么要挂在同一个 pv 下？即使不考虑 k8s,在裸机上部署，三个副本跑在三个机器上肯定也是三块硬盘啊，所以你需要三个 pv，statefulset 就是用 volumeClaimTemplate 动态生成对应的 pv

如果你说的是 bitnami 的 mongodb chart 的话, 理解有点问题.

mountPath 都是每个容器单独的, 每个副本用自己的 mountPath, 为啥要挂载在不同子目录?

这个 chart 有 standalone 和 replicaset 两种部署模式, existingClaim 只在 standalone 模式下有效, 此时只有一个 mongo 实例.

replicaset 模式下,多个 statefulset 的实例是用 volumeClaimTemplate 动态 provision pv 的.

现在 v 站上的讨论真是鸡同鸭讲, 连个前提都没有, RDBMS 和 NoSQL 是一回事, OLTP 和 OLAP 是另一回事, 互联网业务里的 SQL 和 ERP 系统里的 SQL 又是另另一回事.