0608516518

如果特指 VIP ，它底层协议就是 VRRP ，无论是 F5 ，还是硬件路由器、防火墙，都用 VRRP ，所以本质功能没有区别。
linux 下实现 VRRP 的软件就是 keepalived 了。

但对于 Mysql 和 redis ，它双机热备恐怕并不*只*用 VIP 实现的吧？因为这两个服务都是有状态的。
比如两个 mysql 实例，你还得考虑数据同步和一致性的问题。如果想实现高可用，推荐你使用 mysql 的另外的发行版 Percona XtraDB Cluster. 而 Redis 也要部署为 replica 模式。

@cheneydog 哦严格来说确实是 TPS 。只不过站在后端视角，一个 API call 一般也就是一个 transaction 。所以 QPS 与 TPS 基本一致。

当然你可以说强调数据库写入性能时用 TPS ，强调应用服务器处理请求时，使用 QPS

老哥写一下本科的学校吧~（否则默认双非了。。）

如果是绝区零这样的成熟游戏与应用，基本可以确认用的是传统 RDMS （如 MySQL ）来保存账号。

不能只想着分配 id ，别忘了还用户资料、昵称、人物数据等等。这些都得有地方存啊。说来说去，还是数据库赛高。

我不那么相信 “几分钟就生成了上百万 id”，可能是之前预约用户已经分配、初始化好账号了。如果我是该产品的开发，一定会想出削峰填谷的策略。

退一万步“几分钟的百万次请求”其实也并不算大，3K QPS 情况下，5 分钟就可以生成 100w 个数据了，3K QPS 插入，在 SSD + 较多核服务器 + user 表 sharding 情况下，还是可以扛住的。但这样搞，技术风险大，压力测试也难做。想必还是用预约玩家的数据已经生成好了

SealOS 出名，还是因为它是一个 k8s 的 dashboard / UI 。事实上无法达到“用户不懂 k8s ，还用 SealOS ” 的，否则低级问题就很让人头疼。

SealOS 应该把应用生态做好，开箱即用，就像 @DaiShu888 说的，做几款卖爆的应用，会好得多。否则有多少需求会用到容器化部署呢（个人网站？）。企业级应用又选择大云厂了

公有云形式租赁模式下，包月几乎没有啥优势。价格敏感的，选择 autodl 的时租模式。
租 3 个月以上的，人家也不傻，自己买硬件了。

当然，你要是流量够多，总能筛选到购买的客户，核心痛点其实在这里。。

思核云的 S3 （ OSS 服务），0.06 元/GB/月。
3TB 的年成本是 2160 元。算是很便宜了。
兼容 S3 协议，所以有很多 S3 备份客户端或者 S3 挂载客户端可以使用

历史上用某一个库，如果觉得“它要是 XX 功能就好了”，那么就做开发这个功能，然后提 PR

有些编码规范是为了降低风险，或者由于某些公司内部原因（历史原因，或者只有阿里才会遇到的性能问题）而提出来的。我印象深刻的是 boolean 变量不要叫 isGood ，而要叫 good ，否则某些框架序列化成 json ，会变成 is_is_good 。但请问现代 jackson 会吗？不会。

看规范，更重要的是看它为什么要这样写。