可能微信回调坑！楼主可以检查一下，微信走的 http 回调，竟然不支持返回 content-encoding: gzip/br，曾经为了这个问题折腾了好几天，最后单独让 nginx 为这个接口原文返回。

大写的服。

只能说贵微信，真是神一样的团队。

LZ 先找到愿意给你提供这种发包的机器再说吧。

I/O 高不一定是读文件的问题

也有可能是文件数量多导致

光从性能角度来说

一级热数据进 redis （取最近登录多少天）

二级进 pika 或 ssdb 这类 kvdb （取最常登录多少次）

三级命中走 mysql 分表查询

无论存还是查 100 亿都问题不大

@cabing 自己做 proxy 其实也尝试过 单机问题不大。但是涉及到「分布式」这块一致性和稳定性比较难彻底解决。遂放弃。

@laminux29 大佬说的是，问题描述确实有些矛盾，其实也是想请教一下在这个场景下，大家会用的一些低成本高收益的方案。

@xautll 似乎 clickhouse 适合于离线分析 ，不适合高并发下 kv 查询。

@btnokami 目前是集群 回头试试 key 分片。

@ppyybb 感谢，目前用的就是 ssdb 集群。

@vus520
感谢，pika 其实挺好的，但是到 v3 后已经去掉 double master 支持了，
要自行引入 codis，不然还得带 docker，运维成本并不低
之前用 pika 当文件存储服务，存了 1.5T 文件后，
访问量不高，但 I/O 直接吃满，性能上不去，就不敢用了...

@fuis
感谢，TIDB 门槛有点高，个人开发者吃不消.

无脑推 上古卷轴

@muxiaoke 甭试了 这家国人开的 网络去年硬盘挂了给补偿 2 月，以为会好点…结果依旧常年炸的不要不要的 这个故事告诉我们不要贪小便宜 早点申请退款洗洗睡吧 #来自年付当扔了的用户

@uer 老哥这个细腻到点了，小弟真心受用！之前确实钢铁直男去考虑问题…我好好再去屡屡。再次感谢老哥点拨 🙏

最后回复一下：

1. 南方（至少我们这）提车都会挑日子（习俗），虽然我也不太信这个，但是只有长辈懂，所以征求长辈的意见。这和妈宝扯不上半毛钱关系哈。

2. 征求亲妈意见是老婆先提出来的，我觉得这也是老婆对婆婆的尊重，并没有什么不妥。

各位意见我都虚心学习和借鉴，帖子到此打住，感谢各位的关心。

感谢楼上楼下的 v 友的建议。

统一回复一下：

1. 亲妈的说闲话的顾忌还是怕被亲戚借钱、借车之类的关系不好处理，这点在人情事故确实上很难处理，我也明白。因为工作原因，确实和家人沟通得比较少，下单前没和家人讨论也确实不应该。回头好好沟通一下。

2. 个人的经历不具参考性，比较难复制就不在这里给大家乱带路了，一个人从产品+设计+运营坚持一个项目十几年，之前一直负支出，这几年开始尝试变现。要总结就是：坚持自己的兴趣和信仰，现实一定不会亏待你的。

3. 关于 50w 的代步车在这边确实有些过。但是我和老婆都很喜欢那款车，其他各种其实都有试过很多，一是自己已经有七座 suv 了主要考虑轿车，二是想后续 8-10 年不用换车了，干脆一步到位。

综合以上，目前还是非常确定要坚持买。

真没人在 ns 上玩「上古卷轴·天际」？我龙裔不佛！

有个东西叫索引表

json 别编码试试：json_encode($data,320)