canal

125验证回文串

て烟熏妆下的殇ゞ 提交于 2020-08-13 07:03:26
# 利用双指针,一次遍历,求出结果 class Solution: def isPalindrome(self, s: str) -> bool: # 定义变量,接收字符串的长度 length = len(s) # 长度小于等于1直接返回真 if length <= 1:return True # 定义两个指针, 分别指向字符串头和尾 index1,index2 = 0,length - 1 while index1 <= index2: # 判断字符是否为字母或者数字 if not s[index1].isalnum(): index1 += 1 continue if not s[index2].isalnum(): index2 -= 1 continue # 判断两个字符是否相同 if s[index1].lower() != s[index2].lower(): return False index1 += 1 index2 -= 1 return True A = Solution() print(A.isPalindrome("A man, a plan, a canal: Panama")) print(A.isPalindrome("")) print(A.isPalindrome("qq")) print(A.isPalindrome("race a car")

canal 实现Mysql到Elasticsearch实时增量同步

偶尔善良 提交于 2020-08-12 11:06:50
简介: MySQL是一个关系型数据库管理系统,由瑞典MySQL AB 公司开发,目前属于 Oracle 旗下产品。MySQL是一种关系数据库管理系统,关系数据库将数据保存在不同的表中,而不是将所有数据放在一个大仓库内,这样就增加了速度并提高了灵活性。 1、Mysql如何同步到Elasticsearch? 2、Logstash、kafka_connector、canal选型有什么不同,如何取舍? 3、能实现同步增删改查吗? 1、Canal同步 1.1 canal官方已支持Mysql同步ES6.X 同步原理,参见之前: 干货 | Debezium实现Mysql到Elasticsearch高效实时同步。 canal 1.1.1版本之后, 增加客户端数据落地的适配及启动功能。canal adapter 的 Elastic Search 版本支持6.x.x以上。 需要借助adapter实现。 1.2 同步效果 1)已验证:仅支持增量同步,不支持全量已有数据同步。这点,canal的初衷订位就是“阿里巴巴mysql数据库binlog的增量订阅&消费组件”。 2)已验证:由于采用了binlog机制,Mysql中的新增、更新、删除操作,对应的Elasticsearch都能实时新增、更新、删除。 3)推荐使用场景 canal适用于对于Mysql和Elasticsearch数据实时增、删

围观:基于事件机制的内部解耦之心路历程

倖福魔咒の 提交于 2020-08-11 03:11:12
每篇文章都有属于它自己的故事,没有故事的文章是没有灵魂的文章。而我就是这个灵魂摆渡人。 主人公张某某,这边不方便透露姓名,就叫小张吧。小张在一家小型的互联网创业团队中就职。 职位是 Java 后端开发,所以整体和业务代码打交道在所难免。 之前有个搜索相关的需求,而且数量量也算比较大,就采用了 ElasticSearch 来做搜索。第一版由于时间比较赶,做的比较粗糙。越到后面发现代码越难写下去了,主要是在更新索引数据的场景没处理好,才有了今天的故事。 基础入门 Spring Event Spring 的事件就是观察者设计模式,一个任务结束后需要通知任务进行下一步的操作,就可以使用事件来驱动。 在 Spring 中使用事件机制的步骤如下: 自定义事件对象,继承 ApplicationEvent 自定义事件监听器,实现 ApplicationListener 或者通过 @EventListener 注解到方法上实现监听 自定义发布者,通过 applicationContext.publishEvent()发布事件 Spring Event 在很多开源框架中都有使用案例,比如 Spring Cloud 中的 Eureka 里面就有使用 event 包 定义 Event 发布 Event Guava EventBus EventBus 是 Guava 的事件处理机制,在使用层面和

「从零单排canal 04」 启动模块deployer源码解析

岁酱吖の 提交于 2020-08-09 05:14:53
基于1.1.5-alpha版本,具体源码笔记可以参考我的github: https://github.com/saigu/JavaKnowledgeGraph/tree/master/code_reading/canal 本文将对canal的启动模块deployer进行分析。 Deployer模块(绿色部分)在整个系统中的角色如下图所示,用来启动canal-server. 模块内的类如下: 为了能带着目的看源码,以几个问题开头,带着问题来一起探索deployer模块的源码。 CanalServer启动过程中配置如何加载? CanalServer启动过程中涉及哪些组件? 集群模式的canalServer,是如何实现instance的HA呢? 每个canalServer又是怎么获取admin上的配置变更呢? 1.入口类CanalLauncher 这个类是整个canal-server的入口类。负责配置加载和启动canal-server。 主流程如下: 加载canal.properties的配置内容 根据canal.admin.manager是否为空判断是否是admin控制,如果不是admin控制,就直接根据canal.properties的配置来了 如果是admin控制,使用PlainCanalConfigClient获取远程配置

MySQL到Elasticsearch数据同步

依然范特西╮ 提交于 2020-08-09 02:25:31
MySQL与Elasticsearch同步 当业务需要对海量数据进行多维度、实时的搜索时,关系型数据库显然力不从心。一个非常典型的例子就是对产品或者商品进行多维度搜索。此时,业务经常需要借助搜索引擎Elasticsearch满足多样化的实时搜索诉求。搜索开始前,首先需要解决的问题是如何将待搜索数据从关系型数据库实时同步到Elaticsearch 方案1:阿里云数据传输DTS DTS支持本地IDC自建MySQL/其他云厂商MySQL/阿里云ECS自建MySQL/RDS MySQL->Elasticsearch之间的数据实时同步。通过DTS提供的数据实时同步功能,用户只要3步就可搭建起MySQL同Elasticsearch的实时同步实例,实现基于MySQL Binlog的毫秒级同步延迟。 方案2:Logstash将MySQL数据同步到ElasticSearch 开源工具成本高:待同步表必须更新时间字段、业务写入数据必须更新时间 性能影响大:通过SQL读取数据、对线上业务影响大 同步延迟高:定期数据同步、同步时延高达数小时 稳定性差:无法解决RDS实例迁移及、日志回收情况下的同步稳定性 除mysql外,还支持oracle、SQL server、PostgreSQL等数据库类型 使用logstash-input-jdbc插件读取mysql的数据,这个插件的工作原理比较简单

大数据采集和抽取怎么做?这篇文章终于说明白了!

江枫思渺然 提交于 2020-08-06 10:52:14
本文来源于公众号【胖滚猪学编程】,转载请注明出处! 关于数据中台的概念和架构,我们在 大白话 六问数据中台 和 数据中台全景架构及模块解析!一文入门中台架构师! 两篇文章中都说明白了。从这一篇文章开始分享中台落地实战。 其实无论是数据中台还是数据平台,数据无疑都是核心中的核心,所以闭着眼睛想都知道数据汇聚是数据中台/平台的入口。纵观众多中台架构图,数据采集与汇聚都是打头阵的: 本文将从以下几个方面分享数据采集的方方面面: 一、企业数据来源 二、数据采集概念和价值 三、数据采集常用工具 四、数据采集系统设计原则 五、数据采集模块生产落地分享 有来源才能谈采集,因此我们先来归纳下企业中数据来源。 数据来源 企业中的数据来源极其多,但大都都离不开这几个方面: 数据库,日志,前端埋点,爬虫系统等。 数据库我们不用多说,例如通常用mysql作为业务库,存储业务一些关键指标,比如用户信息、订单信息。也会用到一些Nosql数据库,一般用于存储一些不那么重要的数据。 日志也是重要数据来源,因为日志记录了程序各种执行情况,其中也包括用户的业务处理轨迹,根据日志我们可以分析出程序的异常情况,也可以统计关键业务指标比如PV,UV。 前端埋点同样是非常重要的来源,用户很多前端请求并不会产生后端请求,比如点击,但这些对分析用户行为具有重要的价值,例如分析用户流失率,是在哪个界面,哪个环节用户流失了

分布式之数据库和缓存双写一致性方案解析

无人久伴 提交于 2020-08-04 11:29:49
原文出处: https://www.cnblogs.com/rjzheng/p/9041659.html 引言 为什么写这篇文章? 首先,缓存由于其高并发和高性能的特性,已经在项目中被广泛使用。在读取缓存方面,大家没啥疑问,都是按照下图的流程来进行业务操作。 但是在更新缓存方面,对于更新完数据库,是更新缓存呢,还是删除缓存。又或者是先删除缓存,再更新数据库,其实大家存在很大的争议。目前没有一篇全面的博客,对这几种方案进行解析。于是博主战战兢兢,顶着被大家喷的风险,写了这篇文章。 文章结构 本文由以下三个部分组成 1、讲解缓存更新策略 2、对每种策略进行缺点分析 3、针对缺点给出改进方案 正文 先做一个说明,从理论上来说,给缓存设置过期时间,是保证最终一致性的解决方案。这种方案下,我们可以对存入缓存的数据设置过期时间,所有的写操作以数据库为准,对缓存操作只是尽最大努力即可。也就是说如果数据库写成功,缓存更新失败,那么只要到达过期时间,则后面的读请求自然会从数据库中读取新值然后回填缓存。因此,接下来讨论的思路不依赖于给缓存设置过期时间这个方案。 在这里,我们讨论 三种 更新策略: 先更新数据库,再更新缓存 先删除缓存,再更新数据库 先更新数据库,再删除缓存 应该没人问我,为什么没有先更新缓存,再更新数据库这种策略。 (1)先更新数据库,再更新缓存 这套方案,大家是普遍反对的。为什么呢

MAXWELL系列(一)-利用maxwell 解析binlog 到 redis

巧了我就是萌 提交于 2020-05-01 01:06:22
今天猪脚是maxwell, zendesk 公司开源 https://github.com/zendesk/maxwell 先看架构,和他竞争的有 Debezium Connector for MySQL 废话不多说,搭建目标任务 mysql的binlog 到redis (192.168.0.1 ~~~~~~~192.168.0.3) 1:下载 https://github.com/zendesk/maxwell/releases/download/v1.22.0/maxwell-1.22.0.tar.gz 2: 安装java ,配置好java环境变量 ,解压maxwell-1.22.0.tar.gz(因为是java 写的) 3:mv maxwell-1.22.0 /usr/local && ln -s maxwell maxwell-1.22.0 4: 配置原库(192.168.0.1)添加账号,(后面要用). mysql > select user ,host from mysql. user where user = ' canal ' ; + -- -----+------+ | user | host | + -- -----+------+ | canal | % | + -- -----+------+ 1 row in set ( 0.01 sec) mysql>

Redis面试笔记(二)雪崩、穿透、击穿三连问

走远了吗. 提交于 2020-04-29 16:37:56
Redis雪崩? 雪崩是指缓存中大批热点数据过期后系统涌入大量查询请求,因为大部分数据在Redis层已经失效,请求渗透到数据库层,大批量的请求犹如洪水一般涌入,引起数据库压力造成查询阻塞甚至宕机。 解决方案: 将缓存失效时间分散开,比如每个key的过期时间都是随机的,防止同时大量数据过期现象发生,如果缓存是分布式部署,将热点数据分布在不同的Redis和数据库中,有效分担压力。 简单粗暴法,将Redis数据设置永不过期(如果业务准许,比如不需要更新的名单类) Redis穿透? 穿透是指绕过Redis,调用者发起的请求参数(Key)在缓存和数据库中都不存在,通过不存在的key,成功穿透到系统底层,大规模不断发起不存在的Key的检索请求,导致系统压力过大最后故障。 解决方案: 分布式布隆过滤器 返回空值,遇到数据库和Redis都查不到的值,在Redis里Set一个null value过期时间很短,目的在于同一个Key再次请求时直接返回Null,避免穿透。 Redis击穿? 击穿:击穿和穿透概念类似,一般是指一个Key被穿透,这个Key是热点Key,同一个Key会被成千上万次请求,比如微博搜索热点排行榜、如果这个Key失效了,就像保险丝熔断了,百万QPS直接压垮数据库。 解决方案: - 利用互斥锁,简单来说就是在缓存失效的时候,不是直接去Load DB

Redis 如何保持和MySQL数据一致【二】

不想你离开。 提交于 2020-04-29 14:44:06
需求起因 在高并发的业务场景下,数据库大多数情况都是用户并发访问最薄弱的环节。所以,就需要使用redis做一个缓冲操作,让请求先访问到redis,而不是直接访问MySQL等数据库。 这个业务场景,主要是解决读数据从Redis缓存,一般都是按照下图的流程来进行业务 读取缓存步骤一般没有什么问题,但是一旦涉及到数据更新:数据库和缓存更新,就容易出现 缓存(Redis)和数据库(MySQL)间的数据一致性问题 。 不管是先写MySQL数据库,再删除Redis缓存;还是先删除缓存,再写库,都有可能出现数据不一致的情况。举一个例子: 1.如果删除了缓存Redis,还没有来得及写库MySQL,另一个线程就来读取,发现缓存为空,则去数据库中读取数据写入缓存,此时缓存中为脏数据。 2.如果先写了库,在删除缓存前,写库的线程宕机了,没有删除掉缓存,则也会出现数据不一致情况。 因为写和读是并发的,没法保证顺序,就会出现缓存和数据库的数据不一致的问题。 如来解决?这里给出两个解决方案,先易后难,结合业务和技术代价选择使用。 缓存和数据库一致性解决方案 1.第一种方案:采用延时双删策略 在写库前后都进行redis.del(key)操作,并且设定合理的超时时间。 伪代码如下 public void write( String key, Object data ) { redis.delKey( key );