3. ES集群深度优化提升
讲 完 了 E S 的 双 中 心 主 备 集 群 高 可 用 架 构 , 接 下 来 我 们 深 入 讲 解
一 下 E S 主 集 群 的 优 化 工 作 。 有 一 段 时 间 , 我 们 特 别 痛 苦 , 就 是
每 到 饭 点 , E S 集 群 就 开 始 报 警 , 搞 得 每 次 吃 饭 都 心 慌 慌 的 , 生
怕 E S 集 群 一 个 扛 不 住 , 就 全 公 司 炸 锅 了 。 那 为 什 么 一 到 饭 点 就
报 警 呢 ? 因 为 流 量 比 较 大 ,
导 致 E S 线 程 数 飙 高 , c p u 直 往 上 窜 , 查 询 耗 时 增 加 , 并 传 导 给
所 有 调 用 方 , 导 致 更 大 范 围 的 延 时 。 那 么 如 何 解 决 这 个 问 题 呢
? 通 过 深 入 E S 集 群 , 我 们 发 现 了 以 下 几 个 问 题 :
ES负载不合理,热点问题严重。ES主集群一共有几十个节点,有的节点上
部署的shard数偏多,有的节点部署的shard数很少,导致某些服务器的负
载很高,每到流量高峰期,就经常预警。
ES线程池的大小设置得太高,导致cpu飙高。我们知道,设置ES的threadpo
ol,一般将线程数设置为服务器的cpu核数,即使ES的查询压力很大,需要
增加线程数,那最好也不要超过“cpu core * 3 / 2 +
1”。如果设置的线程数过多,会导致cpu在多个线程上下文之间频繁来回切
换,浪费大量cpu资源。
shard分配的内存太大,100g,导致查询变慢。我们知道,ES的索引要合理
分配shard数,要控制一个shard的内存大小在50g以内。如果一个shard分
配的内存过大,会导致查询变慢,耗时增加,严重拖累性能。
string类型的字段设置了双字段,既是text,又是keyword,导致存储容量
增大了一倍。会员信息的查询不需要关联度打分,直接根据keyword查询
就行,所以完全可以将text字段去掉,这样就能节省很大一部分存储空间
,提升性能。
ES查询,使用filter,不使用query。因为query会对搜索结果进行相关度算
分,比较耗cpu,而会员信息的查询是不需要算分的,这部分的性能损耗
完全可以避免。
节约ES算力,将ES的搜索结果排序放在会员系统的jvm内存中进行。
增加routing
key。我们知道,一次ES查询,会将请求分发给所有shard,等所有shard返