无题

整个搜索的架构设计

先是从大的方面进行讲述，然后可以从各个模块深入细节

数据存储层
db ：mysql mongo hdfs
es：
redis: 用户画像
数据从db转移部分到es，es不用做持久层，只是做搜索使用
在数据接入的过程中
mysql,mongo通过mongo-shake,canal接入，代码解析数据丢到kafka当中，相当于一个数据中转
pre-clean — 对搜索来书是脏数据的清理
flink-counter — 统计型数据

indexer项目的接入

面临的问题：数据库的表比较多，索引也比较多

1. 批量较慢（导致数据的实时性受到影响），跳跃id问题（导致了空查询）
   改成使用线程池的工作方式，按照id并发，但是存在大量空id情况
   单线程查询，然后多线程处理的方式，拒绝策略需要注意

2. 单线程消费每个kafka的表路由到不同的索引当中，每个表的逻辑更加复杂化，数据发生堆积问题，
   由表的维度修改到索引的维度，不同的索引消费kafka使用不同个group
   每一个索引有一个线程池进行业务处理，可以进行资源共享
   增加批量处理的模式

3. 任务复杂，需要消费的数据类型有mongo,kafka,flink,采用抽象设计模式，同时想要减少数据更新的频次(根据日志的特点可以决定是否进行更新)，热点数据延时更新
   设计模式优化，组合和继承共用
   尽可能配置化，每个index