这是一个创建于 724 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前有商品表和订单表。
订单记录了购买的商品 id 和价格。
为了优化商品流的呈现，要为商品做热度排序：
根据商品的浏览量、收藏量、销售额进行评分排序。
同时为了防止热门的商品一直排在前面，对以上信息添加基于时间的权重。
（比如 7 天内销量权重高，15 天权重减半，30 天权重再减半，超过 30 天就不记录在内）
目前数据在 SQL 数据库中，同时有 Redis 作为缓存使用。
在商品数量不断上升的前提下，有没有比较成熟高效的热度排序方案呢 (暂时不考虑 AI 排序)
 |
1
leogm9408leo 2022-11-25 10:42:35 +08:00
这个排序其实是很常见的业务场景，数据同步到 es ，浏览量、收藏量这些作为排序因子，时间作权重因子，在 es 里用排序脚本排序
|
 |
2
lawsiki 2022-11-25 10:43:52 +08:00
redis zset 排序？每次读取缓存的时候根据权重更新 score
|
 |
3
jaggle 2022-11-25 10:50:32 +08:00 via iPhone
@leogm9408leo 排序脚本性能如何，会不会很慢呢，因为我想到这样就没法用索引了
|
|
4
leogm9408leo 2022-11-25 11:04:08 +08:00
@jaggle #3 es 做这种简单脚本排序性能还是很 OK 的，算是业界最常用的开源组件了。当然也看你们的数据规模，如果总共也就几千条数据要排序，那全量 load 到内存里直接计算成本更低，如果有百万的在售商品，那用 es 更省心
|
 |
5
liuhuansir 2022-11-25 11:12:15 +08:00
看你举例的权重方案，估计对实时性要求也不高，直接搞成定时任务，跑完入库就行了吧
|
 |
6
Hanggi OP @leogm9408leo 不用 ES 呢？
|
|
7
leogm9408leo 2022-11-25 11:54:41 +08:00
@Hanggi #6 看业务的数据量和实时性要求，如果数据量少，可以全部 load 到内存做计算，如果实时性要求不高，可以用定时任务异步算分
|
 |
8
wudaye 2022-11-25 12:00:57 +08:00
加个热度字段或者热度索引表，然后定时任务更新热度就行了
|
|
9
Hanggi OP |
 |
10
ghostwind 2022-11-25 16:44:43 +08:00
热度排序是 topN 的还是 全排序的
|
Select Language