分布式事务

ZooKeeper面试题

|▌冷眼眸甩不掉的悲伤 提交于 2020-02-06 21:35:05
前言 ZooKeeper 是一个分布式的,开放源码的分布式应用程序协调服务。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。 ZooKeeper 的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。 面试题 ZooKeeper 是什么? ZooKeeper 提供了什么? Zookeeper 文件系统 ZAB 协议? 四种类型的数据节点 Znode Zookeeper Watcher 机制 -- 数据变更通知 客户端注册 Watcher 实现 服务端处理 Watcher 实现 客户端回调 Watcher ACL 权限控制机制 Chroot 特性 会话管理 服务器角色 Zookeeper 下 Server 工作状态 数据同步 zookeeper 是如何保证事务的顺序一致性的? 分布式集群中为什么会有 Master? zk 节点宕机如何处理? zookeeper 负载均衡和 nginx 负载均衡区别 Zookeeper 有哪几种几种部署模式? 集群最少要几台机器,集群规则是怎样的? 集群支持动态添加机器吗? Zookeeper 对节点的 watch 监听通知是永久的吗?为什么不是永久的? Zookeeper 的 java 客户端都有哪些? chubby 是什么,和 zookeeper 比你怎么看?

分布式初探——分布式事务与两阶段提交协议

删除回忆录丶 提交于 2020-02-01 14:19:24
今天的文章咱们聊的是分布式原理当中的 原子性 ,也称为 分布式事务 。不知道会不会有人觉得奇怪,分布式系统CAP原则当中并没有原子性,这个原子性是从哪里冒出来的? 其实并不奇怪,之前我们在介绍各种一致性原则的时候,虽然没有明确提出来,但是原子性的相关内容已经隐藏在其中了。让我们回顾一下,分布式系统当中的一致性简单可以分为 强一致性和弱一致性 。强一致性很好理解,简单可以理解成 主节点每次更新都通过同步的方式,同步更新所有副本 。而弱一致性则是统称所有不满足强一致性的模型,可以简单理解成 通过异步更新的方式实现的一致性模型 。 想象一下更新的时候,有节点出错的情况。如果是强一致性,很好办,因为我们采用同步更新,所以更新失败的话,主节点立刻就能感知。要么 重试这次的更新 ,要么 回滚放弃 ,或者是 判断该从库是否已经宕机 ,将它 移除资源池 。 如果是异步的更新机制就麻烦了,因为没有一个统筹大局的主库了。 没有节点知道其他节点更新成功了没有 ,如果部分成功了,部分失败了,那么数据的一致性就完全没办法保障了,脏数据到处都是,这个系统也就没法用了。所以必须要保证即使是异步更新,也要做到原子性,要么所有节点一起更新成功,要么一起失败回滚,不允许出现一部分成功了,另一部分没有的情况。 那么怎么解决这个问题呢?这就需要用到 两阶段提交协议 了。 两阶段提交 两阶段提交协议的算法思路其实不难

分布式初探——分布式事务与两阶段提交协议

穿精又带淫゛_ 提交于 2020-02-01 09:22:04
本文始发于个人公众号: TechFlow 今天的文章咱们聊的是分布式原理当中的 原子性 ,也称为 分布式事务 。不知道会不会有人觉得奇怪,分布式系统CAP原则当中并没有原子性,这个原子性是从哪里冒出来的? 其实并不奇怪,之前我们在介绍各种一致性原则的时候,虽然没有明确提出来,但是原子性的相关内容已经隐藏在其中了。让我们回顾一下,分布式系统当中的一致性简单可以分为强一致性和弱一致性。 强一致性 很好理解,简单可以理解成 主节点每次更新都通过同步的方式,同步更新所有副本 。而 弱一致性 则是统称所有不满足强一致性的模型,可以简单理解成 通过异步更新的方式实现的一致性模型 。 想象一下更新的时候,有节点出错的情况。如果是强一致性,很好办,因为我们采用同步更新,所以更新失败的话,主节点立刻就能感知。要么 重试这次的更新 ,要么 回滚放弃 ,或者是 判断该从库是否已经宕机 ,将它 移除资源池 。 如果是异步的更新机制就麻烦了,因为没有一个统筹大局的主库了。 没有节点知道其他节点更新成功了没 有,如果部分成功了,部分失败了,那么数据的一致性就完全没办法保障了,脏数据到处都是,这个系统也就没法用了。所以必须要保证即使是异步更新,也要做到原子性,要么所有节点一起更新成功,要么一起失败回滚,不允许出现一部分成功了,另一部分没有的情况。 那么怎么解决这个问题呢?这就需要用到 两阶段提交协议 了。

NoSQL简介

偶尔善良 提交于 2020-01-31 06:08:34
1.什么是NoSql:   NoSql(Not Only SQL),意即“不仅仅是SQL”,指的是非关系型数据库。随着互联网Web2.0网站的兴起,传统的关系型数据库在应付Web2.0网站,特别是超大规模和高并发的SNS类型的Web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,而非关系型数据库则由于其本身的特点得到了非常迅速的发展。非关系型数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战,尤其是大数据应用难题,包括超大规模数据的存储。例如谷歌或Facebook每天为他们的用户收集万亿比特的数据。 这些类型的数据存储不需要固定的模式 ,无需多余操作就可以横向扩展。 NoSql的好处:  易扩展:   NoSql数据库种类繁多,但是有一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系,这样就非常容易扩 展。也无形之间,在架构的层面上带来了可扩展的能力。  高性能:   NoSQL数据库都具有非常高的读写性能,尤其在大数据量下,同样表现优秀。这得益于它的无关系性,数据库的结构简单。 一般MySQL使用Query Cache, 每次表的更新Cache就失效,是一种大粒度的Cache ,在针对Web2.0的交互频繁的应用,Cache性能 不高。 而NoSQL的Cache是记录级的,是一种细粒度的Cache ,所以NoSql在这个层面上来说就要性能高很多了。

Java内置方式处理高并发

点点圈 提交于 2020-01-30 04:11:42
对于我们开发的网站,如果网站的访问量非常大的话,那么我们就需要考虑相关的并发访问问题了。而并发问题是绝大部分的程序员头疼的问题, 但话又说回来了,既然逃避不掉,那我们就坦然面对吧~今天就让我们一起来研究一下常见的并发和同步吧。 为了更好的理解并发和同步,我们需要先明白两个重要的概念: 同步和异步 1、同步和异步的区别和联系   所谓同步,可以理解为在执行完一个函数或方法之后,一直等待系统返回值或消息,这时程序是出于阻塞的,只有接收到 返回的值或消息后才往下执行其它的命令。 异步,执行完函数或方法后,不必阻塞性地等待返回值或消息,只需要向系统委托一个异步过程,那么当系统接收到返回 值或消息时,系统会自动触发委托的异步过程,从而完成一个完整的流程。 同步在一定程度上可以看做是单线程,这个线程请求一个方法后就待这个方法给他回复,否则他不往下执行(死心眼)。 异步在一定程度上可以看做是多线程的(废话,一个线程怎么叫异步),请求一个方法后,就不管了,继续执行其他的方法。    同步就是一件事,一件事情一件事的做。 异步就是,做一件事情,不引响做其他事情。 例如:吃饭和说话,只能一件事一件事的来,因为只有一张嘴。 但吃饭和听音乐是异步的,因为,听音乐并不引响我们吃饭。 对于Java程序员而言,我们会经常听到同步关键字synchronized,假如这个同步的监视对象是类的话,那么如果当一个对象

Redis事务与可分布式锁

♀尐吖头ヾ 提交于 2020-01-28 23:39:13
1 Redis 事务 1.1 Redis 事务介绍 l Redis 的事务是通过 MULTI , EXEC , DISCARD 和 WATCH 这四个命令来完成的。 l Redis 的单个命令都是 原子性 的,所以这里确保事务性的对象是 命令集合 。 l Redis 将命令集合序列化并确保处于同一事务的 命令集合连续且不被打断 的执行 l Redis 不支持回滚操作 1.2 相关命令 l MULTI 用于标记事务块的开始 。 Redis 会将后续的命令逐个放入队列中,然后使用 EXEC 命令 原子化地执行这个命令序列。 语法: multi l EXEC 在一个事务中执行所有先前放入队列的命令 ,然后恢复正常的连接状态 语法: exec l DISCARD 清除所有先前在一个事务中放入队列的命令 ,然后恢复正常的连接状态。 语法: discard l WATCH 当某个 事务需要按条件执行 时,就要使用这个命令将给定的 键设置为受监控 的状态。 语法: watch key [key…] 注意事项: 使用该命令可以实现 redis 的 乐观锁 。 l UNWATCH 清除所有先前为一个事务监控的键。 语法: unwatch 1.3 事务失败处理 l Redis 语法错误(可以理解为 编译期错误 ) l Redis 类型错误(可以理解为 运行期错误 ) l Redis 不支持事务回滚

hibernate整理

泪湿孤枕 提交于 2020-01-28 17:19:24
国外框架项目地址:http://websystique.com/springmvc/spring-mvc-4-angularjs-example/Angularjs文本输入框用ng-moduel,其他的用{{ }}放行用.*?Angularjs插件地址http://www.cnblogs.com/pilixiami/p/5634405.htmlUI班的教程:http://pan.baidu.com/share/link?shareid=4146906997&uk=866705889非严格读写是并发的概念Spring不支持多线程Flush()强制要求缓存与数据库一致Eache表连接,lazy子查询ORM: 编写程序时,以面向对象的方式处理数据 保存数据时是以关系型数据库的方式存储的Hibernate的数据持久化: New实例化对象时默认是瞬时的 Jdbc连接数据库时,持久化数据 将数据存入硬盘单向关联关系: 一个类单方向包含另一个类为属性,模拟数据库外键mysql数据库附加:String driver=com.mysql.jdbc.DriverString url=jdbc:mysql://localhost:3306/demohibernate注入: 实体类(1)这个表示一个实体类,Table表示对应数据库中的表名。@Entity@Table(name="t_emp")(2

理解HTTP幂等性,分布式事物

浪尽此生 提交于 2020-01-27 05:44:14
理解HTTP幂等性 基于HTTP协议的Web API是时下最为流行的一种分布式服务提供方式。无论是在大型互联网应用还是企业级架构中,我们都见到了越来越多的SOA或RESTful的Web API。为什么Web API如此流行呢?我认为很大程度上应归功于简单有效的HTTP协议。HTTP协议是一种分布式的面向资源的网络应用层协议,无论是服务器端提供Web服务,还是客户端消费Web服务都非常简单。再加上浏览器、Javascript、AJAX、JSON以及HTML5等技术和工具的发展,互联网应用架构设计表现出了从传统的PHP、JSP、ASP.NET等服务器端动态网页向Web API + RIA(富互联网应用)过渡的趋势。Web API专注于提供业务服务,RIA专注于用户界面和交互设计,从此两个领域的分工更加明晰。在这种趋势下,Web API设计将成为服务器端程序员的必修课。然而,正如简单的Java语言并不意味着高质量的Java程序,简单的HTTP协议也不意味着高质量的Web API。要想设计出高质量的Web API,还需要深入理解分布式系统及HTTP协议的特性。 幂等性定义 本文所要探讨的正是HTTP协议涉及到的一种重要性质:幂等性(Idempotence)。在HTTP/1.1规范中幂等性的定义是: Methods can also have the property of

#HTTP协议学习# (十一)理解HTTP幂等性

与世无争的帅哥 提交于 2020-01-26 11:18:53
在httpcomponent 文档中看到如下段落: 1.4.1. HTTP transport safety It is important to understand that the HTTP protocol is not well suited to all types of applications. HTTP is a simple request/response oriented protocol which was initially designed to support static or dynamically generated content retrieval. It has never been intended to support transactional operations. For instance, the HTTP server will consider its part of the contract fulfilled if it succeeds in receiving and processing the request, generating a response and sending a status code back to the client. The server will make no attempt

Fescar原理

纵然是瞬间 提交于 2020-01-23 15:53:27
Fescar原理 1、概述 fescar刚推出不久,没几天。看了github的Issues,有人问:可以直接商用吗? 作者的回复: image 我们也看一下fescard的历史: 阿里是国内最早一批进行应用分布式(微服务化)改造的企业,所以很早就遇到微服务架构下的分布式事务问题。 2014 年,阿里中间件团队发布 TXC(Taobao Transaction Constructor),为集团内应用提供分布式事务服务。 2016 年,TXC 经过产品化改造,以 GTS(Global Transaction Service) 的身份登陆阿里云,成为当时业界唯一一款云上分布式事务产品,在阿云里的公有云、专有云解决方案中,开始服务于众多外部客户。 2019 年起,基于 TXC 和 GTS 的技术积累,阿里中间件团队发起了开源项目 Fescar(Fast & EaSy Commit And Rollback, FESCAR),和社区一起建设这个分布式事务解决方案。 TXC/GTS/Fescar 一脉相承,为解决微服务架构下的分布式事务问题交出了一份与众不同的答卷。 阿里出品的中间件有一种精神是值得赞扬的,就是出品的任何中间件都是业务中已经使用多年的产品。都是经过锤炼的产品,开源的话,去除和内部业务耦合的代码,开源出来。至少有一点,底层的代码是经历过双11这种高并发请求量打磨过的代码