@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 不就可以防护这个吗？

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

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

golang 中的 ast 还算可用，自行定制开发其实并不会有太大的障碍。我开发 golang 规则引擎 N 年了，内部使用非常完美，但无法开源。目前没看到市面上有用着非常友好的规则引擎库，如果非得推荐一款，那就 https://github.com/bytedance/arishem 。优势在于内置的函数够多不用对底层二开。

gengine 的并发模型，arishem 的内置函数定义，再加上自研的规则权重可能会让规则引擎更加强大。

@xiaocaiji111 #9 java 不也得单独处理不加的日志的情况吗