OKAY教育搜索推荐
涉及技术栈：springboot、springcloud、canal、Kafka、rabbitmq、redis、elasticsearch、nacos、
Zookeeper、redission
项目背景：围绕小初中学习、练习等研发的各端：学生机、教师空间、AI创课、APP商城、学校工作台、OMS、CMS
等。1、OKAY学习培训专用型移动智能终端，是OKAY智慧教育独立产品研发的学员专用型移动智能终端，运用于全日
制教育院校、课外辅导机构的智慧课堂情景，及学员课后练习赔偿的学生自主学习情景。2、OKAY学习培训专用型移动
智能终端，是OKAY智慧教育致力于课堂教学情景产品研发的老师专用型移动智能终端，为老师在平时课堂教学中出示*
率的信息技术应用专用工具，考虑老师常态运用的要求。3、OKAY智慧型服务平台是为地区文化教育主管机构管理人员
量身定做打造出的学生管理专用工具。
项目职责：负责elasticsearch同步mysql数据整体架构稳定、高可用、数据一致性、数据丢失补偿、节假日接口运行正
常以及各端搜索推荐功能开发等
古素福
18301545491 丨18301545491@163.com 丨北京昌平
0mG3pcQS202210101022
工作业绩：1、服务发现、注册、配置从zk迁移到nacos以及nacos配置打印到日志功能；2、canal高可用实现；3、节
假日期间学生访问量增加导致一些接口超过3秒优化，优化后接口在持续两分钟300并发的情况下都在800ms左右；4、
elasticsearch数据打平，如nested数据结构导致查询缓慢；5、ES线上6个数据节点在跑数据时数据都提交在同一个节
点上导致该节点CPU、负载都接近100%优化。
项目问题：
canal服务器内存占比超过80%
技术挑战：canal服务在订阅binlog日志线上一个集群一个server对应20多个实例，每个实例都订阅一个
binlog日志在canal server中计算增删改数据并放入环形队列，在这个过程中canal server内存占比超过
80%，导致服务一直告警
解决方案：
提高canal server的内存大小、从32G换到64G的机子上，但是这样的弊端就是随着业务的增多，实例数的增
多，内存消耗也会慢慢上来，只能解决短期的问题
因为开源canal没有负载均衡，所以即使给这个集群配置多个服务，大部分实例可能还会注册到同一个服务上。
所以我采用建多个集群，每个集群对应一个服务，手动分配实例在哪个集群上，这样就可以把实例分散开来，服
务内存消耗也会降低，而且后续有新的实例可以再建集群让实例注册到新的服务。
实现效果：用第一个方案短期内也能解决问题，但是上线跑数据、节假日业务增大还是会有内存超过80%的情
况，用第二个方案让每个服务负责5个实例的订阅计算能力完全可以分散内存的消耗
es接口超时问题
技术挑战：nested做查询导致sql太长接口超时
解决方案：
可以把nested的数据打平到索引中，这样可以用terms的方式查询性能大大的提升
采用join的方式，把nested的数据放到新的子索引中，这样不仅提升性能，还能解决nested放超过3万条数据
报错，并且一次插入如果nested数据太多也会导致这条数据插入失败，造成数据不同步问题
实现效果：可以在持续两分钟300并发的情况下接口平均也能稳定在几百MS
es DSL过长导致接口报错
技术挑战：线上AI创课推荐素材由于每个目录下的K都是平摊的，所以最高情况下也是中间层传500多个K请求推
荐数据，但是新业务增加游客、个人用户，这些用户都放在虚拟校不同的班级里，大数据把个人、游客可以查看
的K都放在同一个目录下导致一个目录就有2000多个K，导致一次查询一个bool条件中就有2000多个子条件，一
个bool默认只能放1024个子条件。
解决方案：基于此有两种解决办法：
修改ES配置：indices.query.bool.max_clause_count: 1024，但是如果改全局配置就要重启ES，这样风险
很大，再一个问题就是如果把这个数调大十倍，如果K的数量也增大了十倍，同样会报错
可以把一个bool拆分成多个子bool，放在同一个must中以should形式关联，这样即使有5000个子条件也不
会报错。
实现效果：保证了平台推荐运行接口不会随着条件的增多而报错
线上配置维护问题
技术挑战：每次上线的时候都是运维在配置线上配置，如果配错了线上出问题也不好排查
解决方案：基于此我把ZK的配置迁移到Nacos中，以日志的形式打印到其他的日志文件中，这样只要运维上线或
修改配置都可以在日志中看到配置的新增或变更。
实现效果：保证上线稳定性
修改索引的字段如何更好的保证机器性能
技术挑战：CMS题目管理需要增加根据创建人搜索题目，但是cms单题索引中存的搜索人名称是keyword的形
式，所以需要给该字段加上ngram、ik分词属性
解决方案：由于只更新一个字段所以不用全量跑索引，只需要根据ID变更这个一个字段即可，但是线上题目索引
5000多万条数据，
如果用update_by_query的方式服务负载和cpu会非常高
用分页的方式循环跑但是如果用from、size的方式越往后每次查的数据量会非常大，ES服务会直接挂掉
用scroll的方式滚动循环分页，ES CPU、负载基本无变化，而且5000多万条数据半个小时即可跑完
实现效果：ES服务器运行良好