整个搜索的架构设计
先是从大的方面进行讲述,然后可以从各个模块深入细节
数据存储层
db :mysql mongo hdfs
es:
redis: 用户画像
数据从db转移部分到es,es不用做持久层,只是做搜索使用
在数据接入的过程中
mysql,mongo通过mongo-shake,canal接入,代码解析数据丢到kafka当中,相当于一个数据中转
pre-clean — 对搜索来书是脏数据的清理
flink-counter — 统计型数据
indexer项目的接入
面临的问题:数据库的表比较多,索引也比较多
-
批量较慢(导致数据的实时性受到影响),跳跃id问题(导致了空查询)
改成使用线程池的工作方式,按照id并发,但是存在大量空id情况
单线程查询,然后多线程处理的方式,拒绝策略需要注意 -
单线程消费每个kafka的表路由到不同的索引当中,每个表的逻辑更加复杂化,数据发生堆积问题,
由表的维度修改到索引的维度,不同的索引消费kafka使用不同个group
每一个索引有一个线程池进行业务处理,可以进行资源共享
增加批量处理的模式 -
任务复杂,需要消费的数据类型有mongo,kafka,flink,采用抽象设计模式,同时想要减少数据更新的频次(根据日志的特点可以决定是否进行更新),热点数据延时更新
设计模式优化,组合和继承共用
尽可能配置化,每个index