- 浏览: 476231 次
- 性别:
- 来自: 广州
文章分类
- 全部博客 (502)
- Java (70)
- Linux (10)
- 数据库 (38)
- 网络 (10)
- WEB (13)
- JSP (4)
- 互联网 (71)
- JavaScript (30)
- Spring MVC (19)
- HTML (13)
- CSS (3)
- AngularJS (18)
- Redis (5)
- Bootstrap CSS (1)
- ZooKeeper (4)
- kafka (6)
- 服务器缓存 (4)
- Storm (1)
- MongoDB (9)
- Spring boot (16)
- log4j (2)
- maven (3)
- nginx (5)
- Tomcat (2)
- Eclipse (4)
- Swagger (2)
- Netty (5)
- Dubbo (1)
- Docker (7)
- Hadoop (12)
- OAuth (1)
- webSocket (4)
- 服务器性能 (7)
- Session共享 (1)
- tieye修改 (1)
- 工作 (1)
- 有用的语录 (0)
- https (2)
- common (5)
- 产品开发管理 (1)
- CDN 工作原理 (1)
- APNS、GCM (1)
- 架构图 (3)
- 功能实现分析 (1)
- JMX (1)
- 服务器相关操作命令 (1)
- img02 (0)
- 服务器环境搭建 (9)
- goodMenuBook (1)
- CEInstantPot (0)
- 有用数据 (1)
- 百度地图WEB API (2)
- 正则表达式 (1)
- 样式例子 (2)
- staticRecipePressureCooker.zip (1)
- jCanvas (1)
- 网站攻击方法原理 (1)
- 架构设计 (3)
- 物联网相关 (3)
- 研发管理 (7)
- 技术需求点 (1)
- 计划 (1)
- spring cloud (11)
- 服务器开发的一些实用工具和方法 (1)
- 每天学到的技术点 (4)
- Guava (1)
- ERP 技术注意要点 (2)
- 微信小程序 (1)
- FineRepor (1)
- 收藏夹 (1)
- temp (5)
- 服务架构 (4)
- 任职资格方案 (0)
- osno_test (1)
- jquery相关 (3)
- mybatis (4)
- ueditor (1)
- VueJS (7)
- python (10)
- Spring EL (1)
- shiro (1)
- 前端开发原理与使用 (7)
- YARN (1)
- Spark (1)
- Hbase (2)
- Pig (2)
- 机器学习 (30)
- matplotlib (1)
- OpenCV (17)
- Hystrix (1)
- 公司 (1)
- miniui (4)
- 前端功能实现 (3)
- 前端插件 (1)
- 钉钉开发 (2)
- Jenkins (1)
- elasticSearch使用 (2)
- 技术规范 (4)
- 技术实现原理 (0)
最新评论
ES数据同步方案
- 博客分类:
- 数据库
- elasticSearch使用
//===============================================================
ES数据同步方案
1.同步双写
数据写到mysql时,同时将数据写到ES,实现数据的双写。
优点:业务逻辑简单。
缺点:硬编码,业务强耦合,性能较差,代码的侵入性太强
2.异步双写(MQ方式)(程序到MQ,MQ再到MYSQL和ES)
改为写MQ,不直接写ES
优点:性能高(由于MQ的性能基本比mysql高出一个数量级);不存在丢数据问题
缺点:硬编码,业务强耦合,代码的侵入性太强,延时
3.异步双写(Worker方式)(定时任务)
让该程序按一定的时间周期扫描指定的表,把该时间段内发生变化的数据提取出来;逐条写入到ES中。
优点:不改变原来代码,没有侵入性、没有硬编码;没有业务强耦合;
缺点:时效性较差
4.Binlog 同步方式
利用mysql的binlog来进行同步
优点:没有代码侵入、没有硬编码;原有系统不需要任何变化,没有感知;性能高;业务解耦,不需要关注原来系统的业务逻辑。
缺点:构建Binlog系统复杂;也像方案二,存在MQ延时的风险
//===============================================================
MYSQL同步方式,主从复制、半同步复制和主主复制
MySQL数据库的复制需要启动三个线程来实现:
其中1个在主服务器上,另两个在从服务器上。当发出START SLAVE时,从服务器创建一个I/O线程,以连接主服务器并让它发送记录在其二进制日志中的语句。主服务器创建一个线程将二进制日志中的内容发送到从服务器。该线程可以识别为主服务器上SHOW PROCESSLIST的输出中的Binlog Dump线程。从服务器I/O线程读取主服务器Binlog Dump线程发送的内容并将该数据拷贝到从服务器数据目录中的本地文件中,即中继日志。第3个线程是SQL线程,是从服务器创建用于读取中继日志并执行日志中包含的更新。
————————————————
https://blog.csdn.net/weixin_35794185/article/details/113158779
异步复制
通常没说明指的都是异步,即主库执行完Commit后,在主库写入Binlog日志后即可成功返回客户端,无需等等Binlog日志传送给从库,一旦主库宕机,有可能会丢失日志。
半同步复制
半同步启动需要主从两端都需要加载安装各自对应的semi模块
而半同步复制,是等待其中一个从库也接收到Binlog事务并成功写入Relay Log之后,才返回Commit操作成功给客户端;如此半同步就保证了事务成功提交后至少有两份日志记录,一份在主库Binlog上,另一份在从库的Relay Log上,从而进一步保证数据完整性;半同步复制很大程度取决于主从网络RTT(往返时延),以插件 semisync_master/semisync_slave 形式存在。
半同步复制是介于全同步复制和全异步复制之间的一种,主库只需要等待至少一个从库节点收到并Flush Binlog到Relay log文件即可,主库不需要等待所有从库给主库反馈。
全同步
全同步是指当主库接收到客户端的一个事务请求,所有的从库都执行了该事务才返回给客户端。
因为要等待所有从库执行完事务,主库才将结果返回给客户端,所以全同步复制的性能必然受到严重影响,即完成一个事务的时间被拉长,性能降低。
//===============================================================
redis主从复制原理
主从复制,直观的做法是主节点产生一份数据的快照发送给从节点,以快照数据为基准,将之后增量的数据变更同步给从节点,如此就能保证主从数据的一致。总体来看,主从复制一般包含全量数据同步、增量同步两个阶段。
全量数据同步:主节点产生一份全量数据的快照,即RDB文件,并将此快照发送给从节点。且从产生快照时刻起,记录新接收到的写命令。当快照发送完成后,将累积的写命令发送绐从节点,从节点执行这些写命令。此时基准已经建立完成。
命令传播:全量数据同步完成后,主节点将执行过的写命令源源不断地发送给从节点,从节点执行这些命令,保证主从节点中数据有相同的变更,如此保证主从节点数据的一致。
1、主从关系建立后,从节点向主节点发送一个 SYNC 命令请求进行主从同步。
2、主节点收到 SYNC 命令后,执行 fork 创建一个子进程,子进程将所有的数据编码存储到 RDB(Redis Database) 文件中,这就产生了数据库的快照。
3、主节点将此快照发送给从节点,从节点接收快照并载入。
4、主节点接着将生成快照、发送快照期间积压的命令发送给从节点。
5、此后,主节点源源不断地新执行的写命令同步到从节点,从节点执行传播来的命令,命令执行后,从库中的数据也就得到了更新。如此,主从数据保持一致。需要说明的是,命令传播存在时延的,所以任意时刻,不能保证主从节点间数据完全一致。
以上就是 Redis 主从复制的基本原理,很简单很容易理解,但存在一些不美好的地方:
fork 耗时过长,阻塞主进程
执行fork 时候,需要拷贝大量的内存页表,这是一个耗时较多的操作,尤其当内存使用量较大的时候。组内同学曾做过测试,内存占用 10GB 时,fork 需要消耗 100 多毫秒。fork 的时候主进程阻塞 100 多毫秒,这对 Redis 而言,实在太长了。另外,fork 之后,如果主库中有不少的写入,那么由于写时复制机制,会额外消耗不少的内存,还会增大响应时间。
如果主从间网络闪断怎么办
如果网络故障,连接断开,主节点无法继续传播信息至该从节点。之后网络恢复,从节点重新连接上主节点后,主节点不能再继续传播新接收到的信息了,因为从节点已经漏掉了一些命令。此时,从节点需要从来,再次执行全部的同步过程,
网络闪断是常发生的事情,闪断期间主节点中可能只写入了比较少的数据,但就因为这很少的一部分数据,需要让从节点进行一全量同步。这种做法是非常低效的,该如何解决这问题
Redis部分重同步
Redis 2.8 版本后,引入了部分同步。它在主节点中维护了一个复制积压缓冲区,命令一方面会传播到从节点,另外还会记录在这个缓冲区中。保持所有的命令是不必要的,Redis 中使用了一个环形的缓冲区,这样就可以只保留最近的一些命令了。
有了部分同步,网络闪断后就可以避免全量同步了。但是因为主节点只能保留最近的部分命令,保存多少取决于复制积压缓冲区的大小。如果从节点断开时间过长,或者断开期间主节点新执行的写命令足够多,漏掉的命令就无法全部保存到复制积压缓冲区中了。加大复制积压缓冲区可以尽可能多地避免全量同步,但这同时会造成额外的内存消耗。
部分同步消耗了部分内存来保存最近执行的写命令,避免闪断后的全同步,这是很直观、很容易想象的解决方案。这种方案很好,它是否还存在其他问题呢?考虑以下问题:
ES数据同步方案
1.同步双写
数据写到mysql时,同时将数据写到ES,实现数据的双写。
优点:业务逻辑简单。
缺点:硬编码,业务强耦合,性能较差,代码的侵入性太强
2.异步双写(MQ方式)(程序到MQ,MQ再到MYSQL和ES)
改为写MQ,不直接写ES
优点:性能高(由于MQ的性能基本比mysql高出一个数量级);不存在丢数据问题
缺点:硬编码,业务强耦合,代码的侵入性太强,延时
3.异步双写(Worker方式)(定时任务)
让该程序按一定的时间周期扫描指定的表,把该时间段内发生变化的数据提取出来;逐条写入到ES中。
优点:不改变原来代码,没有侵入性、没有硬编码;没有业务强耦合;
缺点:时效性较差
4.Binlog 同步方式
利用mysql的binlog来进行同步
优点:没有代码侵入、没有硬编码;原有系统不需要任何变化,没有感知;性能高;业务解耦,不需要关注原来系统的业务逻辑。
缺点:构建Binlog系统复杂;也像方案二,存在MQ延时的风险
//===============================================================
MYSQL同步方式,主从复制、半同步复制和主主复制
MySQL数据库的复制需要启动三个线程来实现:
其中1个在主服务器上,另两个在从服务器上。当发出START SLAVE时,从服务器创建一个I/O线程,以连接主服务器并让它发送记录在其二进制日志中的语句。主服务器创建一个线程将二进制日志中的内容发送到从服务器。该线程可以识别为主服务器上SHOW PROCESSLIST的输出中的Binlog Dump线程。从服务器I/O线程读取主服务器Binlog Dump线程发送的内容并将该数据拷贝到从服务器数据目录中的本地文件中,即中继日志。第3个线程是SQL线程,是从服务器创建用于读取中继日志并执行日志中包含的更新。
————————————————
https://blog.csdn.net/weixin_35794185/article/details/113158779
异步复制
通常没说明指的都是异步,即主库执行完Commit后,在主库写入Binlog日志后即可成功返回客户端,无需等等Binlog日志传送给从库,一旦主库宕机,有可能会丢失日志。
半同步复制
半同步启动需要主从两端都需要加载安装各自对应的semi模块
而半同步复制,是等待其中一个从库也接收到Binlog事务并成功写入Relay Log之后,才返回Commit操作成功给客户端;如此半同步就保证了事务成功提交后至少有两份日志记录,一份在主库Binlog上,另一份在从库的Relay Log上,从而进一步保证数据完整性;半同步复制很大程度取决于主从网络RTT(往返时延),以插件 semisync_master/semisync_slave 形式存在。
半同步复制是介于全同步复制和全异步复制之间的一种,主库只需要等待至少一个从库节点收到并Flush Binlog到Relay log文件即可,主库不需要等待所有从库给主库反馈。
全同步
全同步是指当主库接收到客户端的一个事务请求,所有的从库都执行了该事务才返回给客户端。
因为要等待所有从库执行完事务,主库才将结果返回给客户端,所以全同步复制的性能必然受到严重影响,即完成一个事务的时间被拉长,性能降低。
//===============================================================
redis主从复制原理
主从复制,直观的做法是主节点产生一份数据的快照发送给从节点,以快照数据为基准,将之后增量的数据变更同步给从节点,如此就能保证主从数据的一致。总体来看,主从复制一般包含全量数据同步、增量同步两个阶段。
全量数据同步:主节点产生一份全量数据的快照,即RDB文件,并将此快照发送给从节点。且从产生快照时刻起,记录新接收到的写命令。当快照发送完成后,将累积的写命令发送绐从节点,从节点执行这些写命令。此时基准已经建立完成。
命令传播:全量数据同步完成后,主节点将执行过的写命令源源不断地发送给从节点,从节点执行这些命令,保证主从节点中数据有相同的变更,如此保证主从节点数据的一致。
1、主从关系建立后,从节点向主节点发送一个 SYNC 命令请求进行主从同步。
2、主节点收到 SYNC 命令后,执行 fork 创建一个子进程,子进程将所有的数据编码存储到 RDB(Redis Database) 文件中,这就产生了数据库的快照。
3、主节点将此快照发送给从节点,从节点接收快照并载入。
4、主节点接着将生成快照、发送快照期间积压的命令发送给从节点。
5、此后,主节点源源不断地新执行的写命令同步到从节点,从节点执行传播来的命令,命令执行后,从库中的数据也就得到了更新。如此,主从数据保持一致。需要说明的是,命令传播存在时延的,所以任意时刻,不能保证主从节点间数据完全一致。
以上就是 Redis 主从复制的基本原理,很简单很容易理解,但存在一些不美好的地方:
fork 耗时过长,阻塞主进程
执行fork 时候,需要拷贝大量的内存页表,这是一个耗时较多的操作,尤其当内存使用量较大的时候。组内同学曾做过测试,内存占用 10GB 时,fork 需要消耗 100 多毫秒。fork 的时候主进程阻塞 100 多毫秒,这对 Redis 而言,实在太长了。另外,fork 之后,如果主库中有不少的写入,那么由于写时复制机制,会额外消耗不少的内存,还会增大响应时间。
如果主从间网络闪断怎么办
如果网络故障,连接断开,主节点无法继续传播信息至该从节点。之后网络恢复,从节点重新连接上主节点后,主节点不能再继续传播新接收到的信息了,因为从节点已经漏掉了一些命令。此时,从节点需要从来,再次执行全部的同步过程,
网络闪断是常发生的事情,闪断期间主节点中可能只写入了比较少的数据,但就因为这很少的一部分数据,需要让从节点进行一全量同步。这种做法是非常低效的,该如何解决这问题
Redis部分重同步
Redis 2.8 版本后,引入了部分同步。它在主节点中维护了一个复制积压缓冲区,命令一方面会传播到从节点,另外还会记录在这个缓冲区中。保持所有的命令是不必要的,Redis 中使用了一个环形的缓冲区,这样就可以只保留最近的一些命令了。
有了部分同步,网络闪断后就可以避免全量同步了。但是因为主节点只能保留最近的部分命令,保存多少取决于复制积压缓冲区的大小。如果从节点断开时间过长,或者断开期间主节点新执行的写命令足够多,漏掉的命令就无法全部保存到复制积压缓冲区中了。加大复制积压缓冲区可以尽可能多地避免全量同步,但这同时会造成额外的内存消耗。
部分同步消耗了部分内存来保存最近执行的写命令,避免闪断后的全同步,这是很直观、很容易想象的解决方案。这种方案很好,它是否还存在其他问题呢?考虑以下问题:
发表评论
-
SQL常用语句
2022-07-21 19:09 178delete from cacherefresh where ... -
elasticSearch使用
2022-04-27 08:42 330ElasticSearch 基于Apache Lucene构建 ... -
SQL存储过程例子和有用的SQL
2022-02-19 09:20 167delete from cacherefresh where ... -
SQL优化对比与总结
2021-01-09 14:44 34519000000 b表 SELECT * from b w ... -
执行存储过程测试
2020-12-30 16:47 349--执行存储过程创建 if (exists (select * ... -
mysql提高insert into 插入速度的方法
2018-12-14 17:26 6059mysql提高insert into 插入 ... -
Mysql并发时经典常见的死锁原因及解决方法
2018-12-08 09:30 3017Mysql并发时经典常见的死锁原因及解决方法 MySQL有 ... -
数据库沉余实现方式
2018-12-04 17:30 976数据库沉余实现方式 canal 原理相对比较简单: (1)c ... -
最终一致性的常用做法
2018-12-01 22:28 594最终一致性的常用做法 ... -
库存扣减和锁
2018-11-29 16:19 2库存扣减和锁 在对数据库的值进行修改时,如果在多线程情况下 ... -
Spring Boot中整合Sharding-JDBC
2018-11-26 18:03 3407Spring Boot中整合Sharding-JDBC ... -
MYSQL 主从、读写分离、分库分表、高可用、数据安全
2018-11-19 18:03 1698MYSQL 主从、读写分离、分库分表、高可用、数据安全 ... -
mybatis-generator 使用
2018-05-19 11:29 511http://www.cnblogs.com/Jason-Xi ... -
eclipse JPA Tools 使用
2018-05-14 17:11 730https://blog.csdn.net/guoxin91/ ... -
mybatis 通用查询实现
2018-03-26 10:04 1362package com.oceano.modity.entit ... -
存储过程 函数
2017-10-27 17:59 441存储过程 函数 存储过 ... -
分页查询例子
2017-10-19 10:22 743分页查询例子 Mybatis分页插件PageHelper的 ... -
数据库同步工具
2017-10-14 14:27 1293数据库同步工具 goden gate Oracle Go ... -
ETL工具
2017-09-01 15:14 668ETL工具 ETL,是英文 Extract-Transfor ... -
PowerDesigner 对比pdm文件内容变化工具
2017-08-06 14:24 670PowerDesigner 对比pdm文件内容变化工具
相关推荐
某天BI团队期望对数据库做全文索引,于是我们同时要写多一份数据到ES中,改造后一段时间,又有需求需要写入到Redis缓存中。很明显这种模式是不可持续发展的,这种双写到各个数据存储系统中可能导致不可维护和扩展,...
MySQL与Elasticsearch实时同步方案 - ...该项目为用户提供了一个基于Canal的MySQL与Elasticsearch实时同步方案,支持增量同步和全量同步,通过界面交互和功能模块,为用户提供了一个高效、易用的实时数据同步解决方案。
特别有用的MySQL数据实时同步到ES轻松配置手册 特别有用的MySQL数据实时同步到ES轻松配置手册
基于canal的mysql和elasticsearch实时同步方案,支持增量同步和全量同步.zip
对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张MySQL 表中,这张中间表对应了业务需要的Elasticsearch 索引,每一列对应索引中的一个Mapping 字段。通过脚本以 Crontab 的...
mongoDB是一个基于分布式文件存储的数据库,由 C++ 语言编写,旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。它介于关系数据库和非关系数据库之间,被认为是非关系数据库当中功能最丰富,最像关系数据库的...
暴露的Http接口(接口定义见 ),待调用后开启后台线程,通过主键分批同步指定数据库中数据到Elasticsearch 读取数据库会加读锁主键必须为数字类型 过程 首先会根据所给的数据库主键分段,拿到最大的主键数字max_id...
对于Elasticsearch,如果要在项目中使用,第一个要解决的问题就是,如何将数据库中的数据同步到Elasticsearch,下面常见的几种中方案 修改代码,修改插入数据库的代码,同时插入Elasticsearch 修改代码,修改插入...
分布式搜索elasticsearch java API 之(一)--- 与...分布式搜索elasticsearch java API 之(七)--- 与MongoDB同步数据 10 分布式搜索elasticsearch java API 之(八)--- 使用More like this实现基于内容的推荐 12
数据中心级持久内存在Elasticsearch云的应用与实践 腾讯万亿级Elasticsearch技术解密 网易基于 Elasticsearch 构建通用搜索系统的实践 易趣上的Pronto Elasticsearch扩展实践 字节跳动的ES智能运维和数据管理理中台...
任何需要快速、准确接收MySQL数据变化增量的场景均适用,例如广告传输流:输出到本地增量文件数据同步:可数据库同构复制,也可以跨异构数据源sync,比如MySQL到一些NoSQL,例如redis、mongodb,或者es、solr等提供...
在trapi v3.x上测试最新测试:v3.4.0该插件尚未在mongodb上进行测试开发此插件的目的是使用Strapi中的弹性搜索引擎来帮助应用程序开发过程 :memo: 目录 方案4 职能阿皮例子记录中作者 先决条件安装Elasticsearch- ...
Elasticsearch数据迁移与容灾实践 云计算业务迁移实验指导 kubernetes容器云平台迁移实践 Oracle数据迁移技巧和优化思路 PostgreSQL去O迁移的一些思考 Service+Mesh渐进式迁移方案 从+IDC+到云端服务迁移历程 大规模...
同步数据、使用 spring-data-elasticsearch 进行高级检索。 系统分析大作业,详细写个 readme 记录下我肝了整整五天踩坑跳坑的结果。 1. elasticSearch 去官网下载安装,这里我用的6.4.1(好像说springboot默认6.4.3...
美国广播公司ABC是与appbase.io进行交互的命令行工具。 它也可以用作瑞士军刀,将数据从任何流行的数据源(Postgres,SQL,Mongo)导入到Elastic... 它可以使Elasticsearch索引与数据源实时同步。 (注意:目前仅支持
为了更好的 完善,提升,B/S架构系统的性能和实用性,系统...MQ数据适配,解析,校验,托管,异常捕获,为使用者提供两种方案,监听器模式和责任链模式并提供出 crud接口 使用者只需要按自己的需求同步到其它容器中即可
本文从实际应用的角度出发,为数据库系统设计并实现了一种基于虚拟...它能够提供稳定的数据复制,可用性高、准时复制、响应时间短,在及时同步业务数据、灾难备份恢复、改善决策支持系统等许多关键服务中有很高的应用
与Elasticsearch的非常相似完全用C ++编写:启动速度快,不需要太多RAM,低级优化可提供良好的性能实时插入:插入后,可以立即读取文档让学习更轻松内置复制和负载平衡可以直接从MySQL / PostgreSQL / ODBC / xml /...
开放数据平台将各种组件集成到用于开放数据的完整门户解决方案中。 特别是,它将元数据目录软件集成到JavaEE服务器环境中。 组件 门户软件Liferay在Java应用程序容器(例如Apache Tomcat)中运行。 它实现了portlet...