ZooKeeper

注：以下分析基于开源 v19.15.2.2-stable 版本进行，社区最新版本代码改动较大，但是总体思路是不变的。 用户提交一条查询SQL背后发生了什么？ 在传统关系型数据库中，SQL处理器的组件主要包括以下几种： • Query Parsing 负责进行词法和语法分析,把程序从人类高可读的格式(即SQL)转化成机器高可读的格式(AST,抽象语法树)。 词法分析指的是把SQL中的字符序列分解成一个个独立的词法单元——Token(<类型，值>)。 语法分析指的是从词法分析器输出的token中识别各类短语，并构造出一颗抽象语法树。而按照构造抽象语法树的方向，又可以把语法分析分成自顶向下和自底向上分析两种。而ClickHouse采用的则是手写一个递归下降的语法分析器。 • Query Rewrite 即通常我们说的"Logical Optimizer"或基于规则的优化器(Rule-Based Optimizer,即RBO)。 其负责应用一些启发式规则，负责简化和标准化查询，无需改变查询的语义。 常见操作有:谓词和算子下推，视图展开，简化常量运算表达式，谓词逻辑的重写，语义的优化等。 • Query Optimizer 即通常我们所说的"Physical Optimizer"，负责把内部查询表达转化成一个高效的查询计划，指导DBMS如何去取表，如何进行排序，如何Join。如下图所示

一、分布式锁简介 锁 是一种用来解决多个执行线程 访问共享资源 错误或数据不一致问题的工具。 如果 把一台服务器比作一个房子 ，那么 线程就好比里面的住户 ，当他们想要共同访问一个共享资源，例如厕所的时候，如果厕所门上没有锁...更甚者厕所没装门...这是会出原则性的问题的.. 装上了锁，大家用起来就安心多了，本质也就是 同一时间只允许一个住户使用 。 而随着互联网世界的发展，单体应用已经越来越无法满足复杂互联网的高并发需求，转而慢慢朝着分布式方向发展，慢慢进化成了 更大一些的住户 。所以同样，我们需要引入分布式锁来解决分布式应用之间访问共享资源的并发问题。 为何需要分布式锁 一般情况下，我们使用分布式锁主要有两个场景： 避免不同节点重复相同的工作 ：比如用户执行了某个操作有可能不同节点会发送多封邮件； 避免破坏数据的正确性 ：如果两个节点在同一条数据上同时进行操作，可能会造成数据错误或不一致的情况出现； Java 中实现的常见方式 上面我们用简单的比喻说明了锁的本质： 同一时间只允许一个用户操作 。所以理论上，能够满足这个需求的工具我们都能够使用 (就是其他应用能帮我们加锁的) ： 基于 MySQL 中的锁 ：MySQL 本身有自带的悲观锁 for update 关键字，也可以自己实现悲观/乐观锁来达到目的； 基于 Zookeeper 有序节点 ：Zookeeper

注：以下分析基于开源 v19.15.2.2-stable 版本进行，社区最新版本代码改动较大，但是总体思路是不变的。 用户提交一条查询SQL背后发生了什么？ 在传统关系型数据库中，SQL处理器的组件主要包括以下几种： • Query Parsing 负责进行词法和语法分析,把程序从人类高可读的格式(即SQL)转化成机器高可读的格式(AST,抽象语法树)。 词法分析指的是把SQL中的字符序列分解成一个个独立的词法单元——Token(<类型，值>)。 语法分析指的是从词法分析器输出的token中识别各类短语，并构造出一颗抽象语法树。而按照构造抽象语法树的方向，又可以把语法分析分成自顶向下和自底向上分析两种。而ClickHouse采用的则是手写一个递归下降的语法分析器。 • Query Rewrite 即通常我们说的"Logical Optimizer"或基于规则的优化器(Rule-Based Optimizer,即RBO)。 其负责应用一些启发式规则，负责简化和标准化查询，无需改变查询的语义。 常见操作有:谓词和算子下推，视图展开，简化常量运算表达式，谓词逻辑的重写，语义的优化等。 • Query Optimizer 即通常我们所说的"Physical Optimizer"，负责把内部查询表达转化成一个高效的查询计划，指导DBMS如何去取表，如何进行排序，如何Join。如下图所示

目前国内关于Debezium的资料不多，大多都比较粗糙，本人实操的时候也确实走了很多弯路，现在在这里详细记录下来供大家参考； 项目需求是实现postgresql至es的数据同步；对此做了一些调研： https://my.oschina.net/u/3734816/blog/3210243 ；最终选定了debezium；这里记录一下psotgresql同步至kafka，kafka至es放在下一篇； docker安装zk，kafka，posgresql，connect zookeeper安装 docker run -it --rm --name zookeeper -p 2181:2181 -p 2888:2888 -p 3888:3888 debezium/zookeeper:latest kafka安装 docker run -it --rm --name kafka -p 9092:9092 --link zookeeper:zookeeper debezium/kafka:latest postgresql安装 docker run -it --rm --name database -p 5432:5432 -e POSTGRES_PASSWORD=xxx -d debezium/example-postgres:latest connect安装 docker volume

关于分布式锁原理的一些学习与思考-redis分布式锁，zookeeper分布式锁 https://www.cnblogs.com/JJJ1990/p/10496850.html 来源： oschina 链接： https://my.oschina.net/u/3391025/blog/4428381

etcd简介 etcd 是开源的、高可用的分布式key-value存储系统，可用于配置共享和服务的注册和发现，它专注于： 简单：定义清晰、面向用户的API（gRPC） 安全：可选的客户端TLS证书自动认证 快速：支持每秒10,000次写入 可靠：基于Raft算法确保强一致性 etcd与redis差异 etcd和redis都支持键值存储，也支持分布式特性，redis支持的数据格式更加丰富，但是他们两个定位和应用场景不一样，关键差异如下： redis在分布式环境下不是强一致性的，可能会丢失数据，或者读取不到最新数据 redis的数据变化监听机制没有etcd完善 etcd强一致性保证数据可靠性，导致性能上要低于redis etcd和ZooKeeper是定位类似的项目，跟redis定位不一样 为什么用 etcd 而不用ZooKeeper？ 相较之下，ZooKeeper有如下缺点： 复杂 ：ZooKeeper的部署维护复杂，管理员需要掌握一系列的知识和技能；而 Paxos 强一致性算法也是素来以复杂难懂而闻名于世；另外，ZooKeeper的使用也比较复杂，需要安装客户端，官方只提供了 Java 和 C 两种语言的接口。 难以维护 ：Java 编写。这里不是对 Java 有偏见，而是 Java 本身就偏向于重型应用，它会引入大量的依赖。而运维人员则普遍希望保持强一致、高可用的机器集群尽可能简单

最近做了一个面试题解答的开源项目，大家可以看一看，如果对大家有帮助，希望大家帮忙给一个star，谢谢大家了！ 《面试指北》项目地址： https://github.com/NotFound9/interviewGuide 本文主要是对美团的分布式ID框架Leaf的原理进行介绍，针对Leaf原项目中的一些issue，对Leaf项目进行功能增强，问题修复及优化改进，改进后的项目地址在这里： Leaf项目改进计划 https://github.com/NotFound9/Leaf Leaf原理分析 Snowflake生成ID的模式 7849276-4d1955394baa3c6d.png snowflake算法对于ID的位数是上图这样分配的： 1位的符号位+41位时间戳+10位workID+12位序列号 加起来一共是64个二进制位，正好与Java中的long类型的位数一样。 美团的Leaf框架对于snowflake算法进行了一些位数调整，位数分配是这样： 最大41位时间差+10位的workID+12位序列化 虽然看美团对Leaf的介绍文章里面说 Leaf-snowflake方案完全沿用snowflake方案的bit位设计，即是“1+41+10+12”的方式组装ID号。 其实看代码里面是没有专门设置符号位的，如果timestamp过大，导致时间差占用42个二进制位，时间差的第一位为1时

【 Java架构师面试网 】收集整理了几乎整个架构师学习途中会遇到的面试题，希望大家都能早日圆自己的架构师梦~ 网站近期在备案和迁移服务器，暂时无法打开，先关注一波公众号吧 公众号： Java架构师面试网 ，关注回复“ 资料 ”即可领取精美整理的面试资料一份哦~ 1. Dubbo 支持哪些协议，每种协议的应用场景，优缺点？ dubbo ： 单一长连接和 NIO 异步通讯，适合大并发小数据量的服务调用，以及消费者远大于提供者。传输协议 TCP，异步， Hessian 序列化； rmi ： 采用 JDK 标准的 rmi 协议实现，传输参数和返回参数对象需要实现Serializable 接口，使用 java 标准序列化机制，使用阻塞式短连接，传输数据包大小混合，消费者和提供者个数差不多，可传文件，传输协议 TCP。多个短连接， TCP 协议传输，同步传输，适用常规的远程服务调用和 rmi 互操作。在依赖低版本的 Common-Collections 包， java 序列化存在安全漏洞； http ： 基于 Http 表单提交的远程调用协议，使用 Spring 的 HttpInvoke 实现。多个短连接，传输协议 HTTP，传入参数大小混合，提供者个数多于消费者，需要给应用程序和浏览器 JS 调用； webservice ： 基于 WebService 的远程调用协议，集成 CXF 实现

一， 为什么写 JMicro 印象中初次接触微服务大概是2011年，那会做Eclpise插件开发，网上查看好多关于OSGI的技术文章，发现Spring新出了一个叫Spring-boot的框架，那会没太上心，只是了解了点皮毛，工作又太忙，之后就没下文了。 直到大概2015年的某天，碰到一个小项目，没什么难度，都用老套路去玩，没什么意思，得玩点新东西才行，也不枉一翻付出，于是选择用GO语言实现，选择GO主要是想体验一下GO，看是不是真如传说中的那样无敌。经过一翻折腾，最终确定GOGIN+GOMICRO实现。是的，从那会开始，通过学心和使用GOMICRO，从此迷上微服务。后来因为工作需要，再没什么机会在项目中接触GO。 后面也曾试图去用Dubbo和Spring-Cloud做项目，但也止于浅尝则止，没能深入。一方面项目时间太紧，折腾不起。另一方面，也是最重要的，项目组成员根本不愿意去学新东西，在很多成员心中，微服务，Spring-Cloud太深奥，玩不起，没时间，至于Dubbo，写个服务，做个RPC也是从百度复制下来的，跑起来就完事了，没人关心个中的原理，经常碰到问题就抓狂！ 从那时候起，就一直琢磨着能不能用Java写一个像GoMicro一样简单的微服务框架，这个框架要确保足够简单，入门和使用成本要底，就像写HelloWord一样，但微服务的基本功能要全。因此项目依赖不能多

最强面试题推荐： 2020Java面试题及答案，命中率高达90% 1.bio与nio的区别 2.select与poll的区别 3.zookeeper的⼯作原理 4.cap理论 5.⼆段式满⾜cap理论的哪两个理论 6.线程池的参数配置，为什么java官⽅提供⼯⼚⽅法给线程池 7.分布式框架dubbo的好处，不⽤dubbo可不可以。为什么要使⽤分布式 8.七个垃圾回收器之间如何搭配使⽤ 9.接⼝限流⽅案 10.ConcurrentHashMap使⽤原理 11.解决map的并发问题⽅案 12.什么是协程，以及实现要点 13.lru cache 使⽤hash map 的实现（算法） 14.图的深度遍历和⼴度遍历（算法） 15.基本排序（算法） 16.设计模式的使⽤ 17.java 8 流式使⽤ 18.说说b+树？ 19.内存屏障与volatile 20.java 域的概念 21.分布式设计领域的概念 22.如何实现双11的购物限流（redis实现⽅案） 23.mysql调优 24.cdn（异地多活） 25.进程之间的通信⽅式 26.tcp/ip协议、http协议 27.写⼀个redis分布式锁 28.spring 7种事务的传播⾏为 29.分布式下down机的处理⽅案（⼼跳检测） 30、分析下分布式强⼀致性、弱⼀致性、最终⼀致性？ 31、dubbo与zookeeper 两者作为注册中