阅读本文大概需要 14 分钟。
来自:同程艺龙技术中心
目录
背景
ES 高可用方案
会员 Redis 缓存方案
高可用会员主库方案
异常会员关系治理
展望:更精细化的流控和降级策略
背景
ES 高可用方案
| ES 双中心主备集群架构
| ES 流量隔离三集群架构
第一类是跟用户的下单主流程密切相关的请求,这类请求非常重要,应该高优先级保障。
第二类是营销活动相关的,这类请求有个特点,他们的请求量很大,tps 很高,但不影响下单主流程。
| ES 集群深度优化提升
ES 负载不合理,热点问题严重。ES 主集群一共有几十个节点,有的节点上部署的 shard 数偏多,有的节点部署的 shard 数很少,导致某些服务器的负载很高,每到流量高峰期,就经常预警。
ES 线程池的大小设置得太高,导致 cpu 飙高。我们知道,设置 ES 的 threadpool,一般将线程数设置为服务器的 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返回结果后再聚合数据,最后将结果返回给调用方。如果我们事先已经知道数据分布在哪些 shard 上,那么就可以减少大量不必要的请求,提升查询性能。
会员 Redis 缓存方案
第一个,前面讲的 ES 集群性能很好,秒并发 3 万多,99 线耗时 5 毫秒左右,已经足够应付各种棘手的场景。
第二个,有的业务对会员的绑定关系要求实时一致,而会员是一个发展了 10 多年的老系统,是一个由好多接口、好多系统组成的分布式系统。
| ES 近一秒延时导致的 Redis 缓存数据不一致问题的解决方案
| Redis 双中心多集群架构
高可用会员主库方案
| MySQL 双中心 Partition 集群方案
| 会员主库平滑迁移方案
会员系统是一刻都不能停机的,要在不停机的情况下完成 SqlServer 到 MySQL 的切换,就像是在给高速行驶的汽车换轮子。
会员系统是由很多个系统和接口组成的,毕竟发展了 10 多年,由于历史原因,遗留了大量老接口,逻辑错综复杂。这么多系统,必须一个不落的全部梳理清楚,DAL 层代码必须重写,而且不能出任何问题,否则将是灾难性的。
数据的迁移要做到无缝迁移,不仅是存量 10 多亿数据的迁移,实时产生的数据也要无缝同步到 MySQL。另外,除了要保障数据同步的实时性,还要保证数据的正确性,以及 SqlServer 和 MySQL 数据的一致性。
| MySQL 和 ES 主备集群方案
异常会员关系治理
展望:更精细化的流控和降级策略
| 更精细化的流控策略
| 更精细化的降级策略
推荐阅读:
内容包含Java基础、JavaWeb、MySQL性能优化、JVM、锁、百万并发、消息队列、高性能缓存、反射、Spring全家桶原理、微服务、Zookeeper、数据结构、限流熔断降级......等技术栈!
⬇戳阅读原文领取! 朕已阅