家里有奥迪油车，奔驰油车（带动能回收），特斯拉 Y （动能回收模式），我的脚都在油/电门上，刹车是辅助。要持续给动力才行。

普通道路
奥迪，不给油门也能滑行，但没给油车速保持不住，肯定要持续给油。
奔驰，不给油门速度降太快，持续给油保持匀速。
特斯拉 Y ，不给电门，动能回收能把人搞吐了。持续油门就完事了


高速
奥迪油门持续给油，路况不复杂开定速巡航。
奔驰油门持续给油，路宽不复杂开定速巡航。
特斯拉 Y 电门给到 120km/h ，开辅助驾驶。会根据路况自动调整速度。


10 年驾龄，一次被女司机撞右后门的经历，无一次主动事故和违章。

@zimuyun 浙江补贴

@hopea 肯定 M3 牛

@singer #20 乱码了。离谱。

17:/Apple/苹果 AI 笔记本/2024MacBookAir13.6 英寸 M3(8+10 核)16G 512G 午夜色电脑 MXCV3CH/A ！ Y5I4DEEiFjCeQd9o ！╰+Jīιng▲鯟

@zimuyun @Psychopassor @intoext

MTclM0ElMkZBcHBsZSUyRiVFOCU4QiVCOSVFNiU5RSU5Q0FJJUU3JUFDJTk0JUU4JUFFJUIwJUU2JTlDJUFDJTJGMjAyNE1hY0Jvb2tBaXIxMy42JUU4JThCJUIxJUU1JUFGJUI4TTMoOCUyQjEwJUU2JUEwJUI4KTE2RyUyMDUxMkclMjAlRTUlOEQlODglRTUlQTQlOUMlRTglODklQjIlRTclOTQlQjUlRTglODQlOTFNWENWM0NIJTJGQSVFRiVCQyU4MVk1STRERUVpRmpDZVFkOW8lRUYlQkMlODElRTIlOTUlQjAlMkJKJUM0JUFCJUNFJUI5bmclRTIlOTYlQjIlRTklQUYlOUY=

base64 解一下，链接带我的返现，介意的话不要用。浙江、北京政府补贴 2000 。提示下单火爆就换个号下单。

https://imgur.com/a/5cbX4mr.jpg

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 稳了

必须妥妥的