M3 ，16G ，512 ，三个层面升级，8599 拿下。有 plus 可以 8539 拿下

@hangzhou #6 真货是为了穿起来舒适，而不是为了让你一双鞋穿多久。不能穿的时间长短作为真假的评判标准

@DualVectorFoil 下不了单

@jdkxnktkdkxod #35 pdd 真的争商家服务费。不管有没有最终成交，只要产生订单就会收取商家的交易服务费。（技术服务费）

难以评价 pdd 是推动进步还是退步，pdd 让我看到人群多样性以及认知差异化巨大。
1. 有人花 5 块钱买了个一次性的东西要求它像 500 块钱一样优质，顺手点个举报薅走一个赔偿，再申请仅退款完成羊腿的收割！
2. 偏远地区的兄弟买东西前不考虑快递成本以及失效，下单后三天点一个仅退款/退货退款，留下店主在风中凌乱。
3. 有的人心很恶，摸透规则，只要多问几个问题，就能触发 pdd 的体验检测机制，拿到体验差的赔偿，完成进一步降本的目的。

OP ，你的网站是用什么建的，是什么相机

我来讲一个方案给楼主点思路。

我在广告方面做过一些项目，热点数据量在几亿条，存储占用四五 T ，需要秒级别延迟下的数据检索。
开始我们用了 starrocks ，但 starrocks 在广告场景下密集写入数据后搜索性能极差（这里不是点 starrocks ，只是我们在用这个。实际上各种号称大数据搜索的都有这种问题）。线上事故不断，资损动不动就是几十万，巅峰时期 3 天 4 个线上事故。
后来我们想了一个办法，搜索的字段和内容是固定的。我们动用了两套数据库，一个是常规的大容量存储，保证原始数据不丢失（这块我们不用于线上查询，偶尔 T+1 检索，目的是保证数据可以用来恢复业务需要的数据以及数分团队抽数分析），另一个是 Redis ，通过 ETL 方式将数据通过规则（规则是可配置的，比如“今天是星期天”，分词后就是“今天”，“星期天”）写入 Redis 作为索引。

* 检索：检索的时候仅查询 Redis ，从 Redis 中查到原始数据的索引，再去获取需要的数据

* 数据重刷：规则是固定的，随着业务的发展，规则需要变更。分词变更成“今天是星期天”要分词成“今天”，“2024/07/30”，“星期天”，“2024/08/04”，这个时候只能重刷数据。刷数就会导致未知风险，为了保证线上可以无感切换，我们还准备了两条数据链路，刷数链路清完数据开始从大容量存储里捞数据，重建影响范围内的数据。刷完后切换查询数据源。再把原来的数据链路重复上面的步骤。

以上一把操作后，我们的热点数据存储从之前的几 T 变成了百 G 。热点数据的数据量上的降低让我们系统 SLA 从 95%提升到 99.9%以上，接口耗时从 200 ～ 300ms 变成了 5ms 。

-----
ES 对于千万级别的数据用起来还算顺手，但数据量上去后 C 端接口抖动真的难以优化。如果有预期数据量在短期有数十倍增长就不必折腾了。B 端业务可以上，B 端接口 10ms 与 200ms 的感知不明显。

redis + mysql 稳了

必须妥妥的

看到这样的，我只劝你买点保险。用保险的额度覆盖你目前的债务以及家人未来 20 年的基本生活支出。

@singer 我对于好的发型师都是 5k 起冲，不好的发型师只会换来我的一顿喷，因为发型至少能影响我半个月的心情。

我看到用这种剪刀给我剪的理发师，我就喷他。上次在杭州苑苑黄龙中心店有个傻 d 这么剪，被我喷到退款。
100+剪头发就是为了剪出满意的头发，tony 用碎剪来抢钱？

CF 不就可以防护这个吗？

阿里是一个很高的成就吗？

你的桌板是全实木一体的吗？我前几个星期也在找但价格太贵了，整块胡桃木要五六千。
椅子是哪个卖家那里收的？