数据源为mysql，目标介质为elasticsearch。
1、 我们能利用的资源
1.1 源数据模型
源库是别人(库存)的数据，分为A,B,C三种类型的库存模型，需要将三种类型的模型整合成一中通用库存模型方便我方(商家)做业务。
典型的互联网企业是协作方式，通过数据副本实现业务之间的解耦。
1.2 特殊表（非重点）
D为库存占用订单详情，也要异构一份。
1.3 分库分表
ABCD均做了分库分表，A(16个库，4096张表),B(1,512),C(1,256),D(8,1024)
1.4 数据量
数据总量在数十亿级别
1.5 线上影响
不影响对方业务，数据源只有对方mysql分组中对应的抽数从库。
mysql分组解释
1.6 性能要求
未来要支持复杂的条件查询，对查性能有很高要求，目标介质是ES。
2、 难点
2.1 导数
交易库存复杂的分片规则，数据量大，导数是个大工程。
2.2 更新频繁
写操作频繁，ES 创建索引的tps能否满足要求。
2.3 一致性如何保证
通过mq 实现 base最终一致性。
3、 最终方案
3.1 系统整体架构
首先增量数据采用canal做收集(图中binLake同集群化canal)，ABC库全部存入es，D库存入mysql。
3.2 如何做全量倒库
sop对应的类型A，使用多个topic分散消息中间件压力，同时解决中间件同一topic的连接数限制。
3.3 如何提高es写性能(bulk)
通过jmq异步创建es索引，通过redis队列实现bulk模式提交对应用的透明化
如何提高Elasticsearch性能
如何提高Elasticsearch性能
- solr查询快，但更新索引时慢（即插入删除慢），用于电商等查询多的应用；
2.ES建立索引快（即查询慢），即实时性查询快，用于facebook新浪等搜索。
- 如何提高ES性能：
- 1.ES更新操作尽量提供批处理，减少写入次数；(bulk)
- 2.按商家维度分多套集群， 在集群里再按照商家维度分片；
- 3.热点集中问题解决方案：路由规则可定制化由ES团队负责；
- 4.提供数据重建reindex功能，要求mapping配置source为true；(方便重建数据)
- 5.ES团队要求，业务方需要提供至少10台物理机用以部署；
- 6.深分页条数建议控制在1万条以内，做分页用scroll方式实现，禁止跳转到大页
Elasticsearch同Solr对比
Elasticsearch同Solr对比
二者安装都很简单；
Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能;
Solr 支持更多格式的数据，而 Elasticsearch 仅支持json文件格式；
Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高级功能多有第三方插件提供；
Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch。Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用。
- solr查询快，但更新索引时慢（即插入删除慢），用于电商等查询多的应用；
2.ES建立索引快（即查询慢），即实时性查询快，用于facebook新浪等搜索。
并发数-吞吐量-响应时间
并发数-吞吐量-响应时间
用于指网站性能/服务器性能时候：并发数：系统同时处理的请求数（分为查询类请求数、事务类请求数）。
吞吐量：系统在单位时间内处理请求的数量。只不过是一个很宽泛的术语，
大家经常指的吞吐量的单位可能是：TPS/QPS、页面数/秒、人数/天、处理业务数/小时等等。
几个相关的概念：TPS、QPS、RPSTPS：Transactions Per Second（每秒事务处理数），
指服务器每秒处理的事务次数。一般用于评估数据库、交易系统的基准性能。QPS：Queries Per Second（查询量/秒），
是服务器每秒能够处理的查询次数，例如域名服务器、Mysql查询性能。RPS：Request Per Second（请求数/秒）
RPS（Request Per Second）和QPS可以认为是一回事。RT：Response Time（响应时间）：客户端发一个请求开始计时，到客户端接收到从服务器端返回的响应结果结束所经历的时间，
响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组成。也叫Think Time。并发数与TPS/QPS的关系：QPS（TPS）= 并发数/平均响应时间这里的并发数如果为事务处理请求数，则为TPS，如果为查询请求数，则为QPS。
原文地址：https://www.cnblogs.com/java920043111/p/9286291.html