这是一个创建于 466 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前用 es 做了一个全文检索服务，索引 3T 大小左右。
9 点上班有个访问高峰，其他时间访问量不高，9 点的时候，Es 服务需要支撑至少 1w 人同时访问，其他时间不超过 1000 。
在这种场景下，部署一个能同时支撑 1w 人的 Es 服务开销太大。
有没有一种解决方案，动态调整 Es 资源（类似于阿里云的 Elasticsearch serverless ，按量付费），1w 个人来就给你能支撑 1w 人访问的计算资源，1000 人来就给 1000 人的资源，这样能节省很大一笔开支。
第 1 条附言 2024-07-02 15:51:55 +08:00
我没有表述清楚，假设用户量 60w ，这 60w 个人在一分钟内发请求过来，平均每秒 1w 个请求，并发至少 1w 是这么来的。
用户搜索词有 90% 的可能不一样，缓存可能有点用，但是光靠缓存不太行。
有信心的可直接加 V: d3VrYWlnZWUK
能帮忙部署一个 demo 更好，钱好说（反正不是我出），只要能解决这个场景。
用户搜索词有 90% 的可能不一样，缓存可能有点用，但是光靠缓存不太行。
有信心的可直接加 V: d3VrYWlnZWUK
能帮忙部署一个 demo 更好，钱好说（反正不是我出），只要能解决这个场景。
36 条回复 2024-07-03 14:25:04 +08:00
 | 1 Aliencn 2024-07-02 12:19:57 +08:00 那就直接用阿里云 ES 的弹性伸缩不就行了嘛。 自己实现的话也是够买弹性服务器加入集群。 |
 | 3 bronyakaka 2024-07-02 12:30:48 +08:00 简单说就是 资源可以减少，但是要上缓存，缓存层支撑高并发 |
 | 4 angeni 2024-07-02 12:50:18 +08:00 搜索应该也讲二八原则，那给 80%的套上缓存可能行 |
 | 5 oudemen 2024-07-02 12:53:53 +08:00 es 部署到 k8s 中，定时弹性扩缩容？ |
 | 6 my3157 2024-07-02 13:06:34 +08:00 就用 ES 原生的 ILM 最方便, 部署用 k8s, 配置好 k8s 的 nodegroup, 每天九点之前, 扩容一批 es hot/warm 节点, 并且将 index 从 cold 节点提升上来, 完事了再降回 cold 节点, 缩掉扩容的 k8s 节点, 实现起来也不复杂 |
 | 7 justest123 2024-07-02 13:35:14 +08:00  1 感觉像是个 AB 问题。。 先确认下，这 1W 人是真的都需要访问到 ES 吗，用缓存转移走部分重复请求或者没必要的请求吧 |
 | 8 sdoq19 2024-07-02 13:44:58 +08:00 阿里云 elasticsearch serverless |
 | 9 fengjianche 2024-07-02 15:15:30 +08:00 这种分布式存储问题都一个样，先上多级缓存，再扛不住就加机器。1w 人同时访问，也不是很多啊。 |
 | 10 JunMemon 2024-07-02 15:24:29 +08:00 ES 拆分节点类型，可以横向扩展非 data 节点，data 节点采用冷热数据部署 |
 | 11 bootvue 2024-07-02 1:27:15 +08:00 k8s hpa |
 | 12 hallDrawnel 2024-07-02 15:45:45 +08:00 感觉像是个 XY 问题，你最终要做的可能不是扩容你的 ES 。试着从搜索分布分析一下？ |
 | 13 zhenjiachen 2024-07-02 15:46:41 +08:00 k8s hpa 或者 node hpa 应该不行把。以为他们只扩充节点，但是数据不会同步到新节点并且节点关闭了数据也丢了 |
 | 14 Xu3Xan89YsA7oP64 2024-07-02 15:47:21 +08:00 有悬赏平台吗，没有的话谁去开发一个，我要抢单 |
 | 15 winglight2016 2024-07-02 15:50:51 +08:00 ES 的缓存就是靠内存，你要是裸机安装就内存弹性增加，如果是 k8s 安装，那就用 HPA 弹性加内存 |
 | 16 ss098 2024-07-02 15:54:23 +08:00 部署 ElasticSearch Helm 到 Kubernetes ，声明 ElasticSearch 不同 node role 的 resources 以及 autoscaling 的配置。 https://github.com/bitnami/charts/tree/main/bitnami/elasticsearch |
 | 17 ChoateYao 2024-07-02 16:01:23 +08:00 阿里云有这种业务啊，包括 RDS 之类的数据库都有动态扩容方案 https://help.aliyun.com/zh/es/user-guide/perform-auto-scaling-for-a-cluster?spm=a2c4g.11186623.0.0.6f397de1Etkjdj |
 | 18 wukaige OP |
 | 19 lasuar 2024-07-02 16:51:53 +08:00 你需要一个 es 专家 |
 | 20 mightybruce 2024-07-02 16:57:28 +08:00 "假设用户量 60w ，这 60w 个人在一分钟内发请求过来，平均每秒 1w 个请求，并发至少 1w 是这么来的。" 首先这个公式就是有问题， 怎么可能 60w 人都是活跃用户，并且用户量根本不能直接这样换算， 你这什么应用 就是一个 XY 问题。 |
 | 21 Jinnrry 2024-07-02 17:21:59 +08:00 via Android 不改业务代码，纯改 es 架构不太现实，你有没有想过 3T 数据扩容的时候主节点复制到从节点要多久？如果高峰瞬间过来，这时你又加节点，从节点复制数据把主节点机器大部分 io 都占了，服务瞬间 GG ，还不如不扩容 除非你能分钟级准确预估峰值时间，否则怎么定扩容策略 另外，1 万人同时访问，这也不多啊，就算缩容，每个月省几千块钱？ |
 | 22 brom111 2024-07-02 17:31:11 +08:00 说起来既然都用阿里云了 有没有考虑过 Lindorm 这套东西 |
 | 23 Coolwinds 2024-07-02 17:33:34 +08:00 从 IT 的角度上来说，你假如自己做伸缩，你多出来的计算资源譬如服务器在闲时怎么办，企业一般不会允许你在一台机器上部署多个服务，除非只是测试环境节省资源 |
 | 24 skymei 2024-07-02 18:06:26 +08:00 感觉业务描述不够清晰，数据是否有冷热区分，是只有基本的全文检索服务，还是会有 agg 聚合统计，数据有没有业务状态，目前分片和副本怎么配置的，分词粒度咋样，这些都可能影响性能。 |
 | 25 keakon 2024-07-02 19:10:24 +08:00 计算挺奇怪的，60 万用户全在一分钟内访问，这是主动发起的，还是定时任务啊？ 平时还能有 1000 qps ，他们是有多闲，每 10 分钟都会查询一次… 说实话你这问题靠扩容没法解决，比如 8:59 时还是 1000 qps ，假设 1 台机器刚好。9:00 突然到 1 万 qps ，立刻再起 9 台机器，启动要半分钟，同步数据几分钟，然后发现 qps 回到 1000 了，它们又可以下线了。 |
 | 26 rrfeng 2024-07-02 19:22:02 +08:00 可以搞。 8 点执行扩容计划，增加节点，增加副本，9 点前 copy 完毕上线。高峰期过了就把临时节点下线。 第二天重复即可。 核心问题是 copy 数据可能会很慢，需要考虑用某种快照方式快速复制数据。 但是我觉得还是可以从业务逻辑上解决更好。 |
 | 27 raycj912 2024-07-02 19:42:19 +08:00 可以多给点信息，不然只能给很粗方案。比如加支持 QPS 更高的组件（缓存）、要么就是弹性扩容，估计都不是你想要的 |
 | 28 cloudzhou 2024-07-02 19:52:24 +08:00 |
 | 29 dode 2024-07-02 20:43:18 +08:00 还是采用超大内存机器吧，3-6 台物理服务器，一天电费是没多少钱。 不是很了解 es 在足够内存和 CPU 情况下，是否有锁限制性能？ k8s 自建 es 服务，定期，启动拉起&关闭服务。 这个 3T 数据能否拆分,提供负载均衡服务 |
| 30 dode 2024-07-02 20:44:55 +08:00 用户搜索词都不一样，但是每个用户每天都是一样的搜索词吗，能否预先批计算？ |
| 31 dode 2024-07-02 20:51:06 +08:00 非高峰期使用一个普通 ES 服务器，配置 SSD 应该就 OK 了，部署两套。 |
 | 32 yuedingwangji 2024-07-03 02:32:23 +08:00 每秒并发 1w ， 真的可怕，这得是什么大项目 |
 | 33 dzdh 2024-07-03 09:24:27 +08:00 搜的几个 index mapping 是怎么设计的 最多请求是什么类型的 |
 | 34 yoooooooo 2024-07-03 10:47:59 +08:00 1w 的峰值，想自己搞这个弹性伸缩不太现实，想想看这个量级每天都要折腾多少节点，光是数据的迁移和从节点的拷贝要花多长时间，而且你们除了峰值其他时间的访问量比较小，那么每次需要操作的节点应该是非常多的，这个方案不现实。 |
| 35 yoooooooo 2024-07-03 10:50:04 +08:00 可以优先从业务角度考虑优化，看有没有优化空间，既然是搜索，为什么搜索词 90%都不会重叠，这个感觉好奇怪 |
 | 36 1018ji 2024-07-03 14:25:04 +08:00 感觉不是加机器的问题，先梳理逻辑啊，看看到底啥事瓶颈 加机器解决一切问题，一个集群不够俩集群 |
Select Language