字节三面：100万的并发，如何设计一个商品搜索系统？

主要观点总结

本文阐述了一道关于设计百万并发下商品搜索系统的面试题，包括系统设计的总体架构和核心关键设计，以及应对大数据量、高并发、缓存穿透、GC调优和灾备高可用设计等方面的解决方案。

关键观点总结

关键观点1: 系统总体架构设计

包括用户层、接入层、服务层、检索层、数据层等，每层都有相应的设计和优化策略。

关键观点2: 核心关键设计

包括分片与容量设计、深度分页性能优化、避免缓存穿透设计、GC调优和灾备高可用设计等，这些都是解决系统瓶颈和提高性能的关键点。

关键观点3: 数据库与搜索引擎的选择和优化

文中提到了MySQL的局限性，推荐使用Elasticsearch作为搜索引擎，并给出了相应的配置和优化建议。

关键观点4: 缓存策略

通过多级缓存、布隆过滤器等手段避免缓存穿透问题，提高系统性能和响应时间。

关键观点5: 高可用性和灾备设计

通过多AZ部署、服务注册中心、主从切换等策略提高系统的可用性和容错能力。

文章预览

今天我们来看一道比较有深度的面试题：百万并发下，商品搜索系统，你如何设计呢？ 假设场景：某电商平台大促期间，需支撑每秒100万次的商品搜索请求，要求响应时间≤200ms，同时应对商品数据量超10亿条。假设给你来做系统设计，怎么做呢？ 如果是我来回答面试官这道题的话，我会按照这些思路来跟面试官阐述： 为什么不能用MySQL的llike？ 总体架构设计 核心关键设计 1.为什么不能用mysql的like？ 我们每次提到关键词搜索，大家很容易就想到 数据库的like ，比如： SELECT  *  FROM  products  WHERE  title  LIKE   '%智能手机%'   LIMIT   10 ;    但是，显然商品数据量超10亿条，搜索不能用like。 LIKE '%keyword%'  无法利用索引，触发全表扫描。10亿数据时单次查询可能耗时数秒。 不支持分词搜索（如"手机壳"无法拆分为"手机"和"壳"单独匹配） 分库分表后跨库 ………………………………