ZK

ZooKeeper是一个分布式的、开源的分布式应用程序协调服务，可以在分布 式环境中实现应用配置管理、统一命名服务、状态同步服务等功能。 ZooKeeper是一种为分布式应用所设计的高可用、高性能的开源协调服务，它提供了一项基本服务：分布式锁 服务。由于ZooKeeper开源的特性，在其分布式锁实现的基础上，又被摸索出了其它的功用，譬如：配置维 护、组服务、分布式消息队列等等。 ZooKeeper维护了一个类似文件系统的数据结构，其内部每个子目录都被 称作znode（目录节点），与文件系统一样，我们可以自由的增删改查znode。ZooKeeper集群适合搭建在奇数 台机器上。只要集群中半数以上主机处于存活，那么服务就是可用的。 ZooKeeper在配置文件中并没有指定 master和slave，但是，ZooKeeper在工作时，只有一个节点为leader，其余节点为follower，leader是通过内部 的选举机制临时产生的。 ZooKeeper特点 1、顺序一致性：以zxid来保证事务的顺序性。 2、原子性：以zab保证原子操作，要么成功，要么失败。 3、单一视图：客户获取到的数据始终是一致的。 4、可靠：以版本实现"写入校验"，保证了数据写入的正确性。 ZooKeeper有三种安装方式：单机模式 & 伪集群模式 & 集群模式 单机模式：ZooKeeper以单实例的形式运

之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务。 首先说一下，这里可能会牵扯到一些 Spring Cloud 的原理，如果有不太清楚的同学，可以参考之前的文章： 《拜托，面试请不要再问我Spring Cloud底层原理！》 。 业务场景介绍 咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。 那对一个订单支付之后，我们需要做下面的步骤： 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。 进一步思考 好，业务场景有了，现在我们要更进一步，实现一个 TCC 分布式事务的效果。 什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。 上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。 举个例子，现在订单的状态都修改为“已支付”了，结果库存服务扣减库存失败。那个商品的库存原来是 100 件，现在卖掉了 2 件，本来应该是 98 件了。

写在前面 作为一名Java开发者，进大厂是不是所有人的期待，就是最终想获得大厂的offer，可能在面试的时候会经历层层筛选。想要进入大厂首先要有过硬的技术，以及面试的时候要有一个良好的心态，只有这样在面试的时候才不会与心仪大厂失之交臂。 今天分享给大家的都是目前大厂使用最高频的面试题：redis，SpringBoot，SpringCloud，SpringMVC，zookeeper，并发编程，多线程面试，开源框架，乐观锁与悲观锁，设计模式等等，希望都能进到大厂，工资加加加。 redis 什么是 Redis？简述它的优缺点？ Redis 与 memcached 相比有哪些优势？ Redis 支持哪几种数据类型？ Redis 主要消耗什么物理资源？ 使用 Redis 有哪些好处？ Redis 是单进程单线程的？ Redis 的持久化机制是什么？各自的优缺点？ Redis 常见异常问题和解决方案（雪崩，穿透...） redis 过期键的删除策略？ 为什么 redis 需要把所有数据放到内存中？ Redis 集群的主从复制模型是怎样的？ Redis key 的过期时间和永久有效分别怎么设置？ Redis 集群方案什么情况下会导致整个集群不可用？ MySQL 里有 2000w 数据，redis 中只存 20w 的数据，如何保证 redis 中的数据都是热点数据？ SpringBoot 什么是

导读 真是有人( 锁 )的地方就有江湖( 事务 )，今天不谈江湖，来撩撩人。 分布式锁的概念、为什么使用分布式锁，想必大家已经很清楚了。前段时间作者写过Redis是如何实现分布式锁，今天这篇文章来谈谈Zookeeper是如何实现分布式锁的。 陈某今天分别从如下几个方面来详细讲讲ZK如何实现分布式锁： ZK的四种节点 排它锁的实现 读写锁的实现 Curator实现分步式锁 ZK的四种节点 持久性节点：节点创建后将会一直存在 临时节点：临时节点的生命周期和当前会话绑定，一旦当前会话断开临时节点也会删除，当然可以主动删除。 持久有序节点：节点创建一直存在，并且zk会自动为节点加上一个自增的后缀作为新的节点名称。 临时有序节点：保留临时节点的特性，并且zk会自动为节点加上一个自增的后缀作为新的节点名称。 排它锁的实现 排他锁的实现相对简单一点，利用了 zk的创建节点不能重名的特性 。如下图： 根据上图分析大致分为如下步骤： 尝试获取锁：创建 临时节点 ，zk会保证只有一个客户端创建成功。 创建临时节点成功，获取锁成功，执行业务逻辑，业务执行完成后删除锁。 创建临时节点失败，阻塞等待。 监听删除事件，一旦临时节点删除了，表示互斥操作完成了，可以再次尝试获取锁。 递归：获取锁的过程是一个递归的操作， 获取锁->监听->获取锁 。 如何避免死锁 ：创建的是临时节点

Bistoury介绍 Bistoury 是去哪儿网开源的一个对应用透明，无侵入的java应用诊断工具，用于提升开发人员的诊断效率和能力，可以让开发人员无需登录机器或修改系统，就可以从日志、内存、线程、类信息、调试、机器和系统属性等各个方面对应用进行诊断，提升开发人员诊断问题的效率和能力。 Bistoury 集成了Alibaba开源的 arthas 和唯品会开源的 vjtools ，因此arthas和vjtools相关功能都可以在 Bistoury 中使用。 Arthas和vjtools通过命令行或类似的方式使用，Bistoury在保留命令行界面的基础上，还对很多命令提供了图形化界面，方面用户使用。 Bistoury 英文解释是外科手术刀，含义也就不言而喻了。 Screenshots 通过命令行界面查看日志，使用arthas和vjtools的各项功能 在线debug，在线应用调试神器 线程级cpu监控，帮助你掌握线程级cpu使用率 在web界面查看JVM运行信息，以及各种其它信息 动态给方法添加监控 线程dump Bistoury架构分析 Bistoury核心组件包含agent，proxy，ui： agent ： 与需要诊断的应用部署到一起，负责具体的诊断命令执行，通过域名连接proxy proxy：agent的代理，agent启动时会通过ws和proxy连接注册

3篇文章总结： 文章1： https://www.cnblogs.com/cc11001100/p/10269494.html 问题：如果一个客户端线程成功获取zk的分布式锁，但因为各种原因执行时间较长，长到zk的临时节点超时，删除临时子节点，另外一个线程此时获得锁，但前面获得锁的客户端也在执行，此时分布式锁就有问题了。 文章2： https://my.oschina.net/eohad/blog/983738 一句话总结：如果因为zk服务端-客户端网络中断导致锁提前释放，但业务逻辑可能会依然并发执行。 解决方案：使用永久节点。但会出现因为会话异常关闭导致死锁问题。 文章3： https://m.imooc.com/article/302954 最终决定还是用Redis的分布式锁吧。我TM emmmmmmmmmmmmmmmmmmmmmmm。 来源： oschina 链接： https://my.oschina.net/u/3730149/blog/3226403

1 概述 1.1 zookeeper 简介 中间件,提供协调服务 作用于分布式系统,发挥其优势,可以为大数据服务 支持 Java, 提供 Java 和 C语言的客户端 API 1.2 什么是分布式系统 很多台计算机组成一个整体,一个整体一致对外并且处理同一请求 内部的每台计算机都可以相互通信(REST/RPC) 客户端到服务端的一次请求到响应结束会经历多台计算机 1.3 分布式系统的瓶颈 1.3.1 zookeeper 的特性 一致性 数据一致性,数据按照顺序分批入库 原子性 事务要么成功要么失败,不会局部化 单一视图 客户端连接集群中的任一 zk 节点,数据都是一致的 可靠性 每次对 zk的操作状态都会保存在服务端 实时性 客户端可以读取到 zk 服务端的最新数据 2 下载、安装以及配置 安装 JDK 2.1 单机模式 2.1.1 Linux环境操作 2.1.2 Mac OS操作 $brew install zookeeper ==> Downloading https://homebrew.bintray.com/bottles/zookeeper-3.4.6_1.mavericks.bottle.2.tar.gz ######################################################################## 100.0% ==

zookeeper是构建分布式系统的重要组件,今天尝试了使用homebrew在mac上安装zookeeper,本文是安装过程的完整记录. 安装zookeeper 查看可用版本 使用命令 $ brew info zookeeper 查看可用版本信息: zookeeper: stable 3.4.8, HEAD Centralized server for distributed coordination of services https://zookeeper.apache.org/ Not installed From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/zookeeper.rb ==> Options --with-perl Build Perl bindings --with-python Build with python support --HEAD Install HEAD version ==> Caveats To have launchd start zookeeper now and restart at login: brew services start zookeeper Or, if you don't want/need a background service

一、发展历程 早期淘宝内部有两套消息中间件系统：Notify和Napoli。 先有的Notify(至今12历史)，后来因有序场景需求，且恰好当时Kafka开源(2011年)，所以参照Kafka的设计理念自研了RocketMQ。 目前Notify和RocketMQ二者的定位如下: RocketQ 主要面向消息有序的场景，能够提供更大的消息堆积能力，拉模式，消息持久化在磁盘 Notify主要面向更加安全可靠地交易类场景，无序、推模式、消息持久化在mysql RocketMQ发展历程如下 ： Metaq 1.x 开源社区维护killme2008维护，因为依赖zk挂了，导致上下游服务全网宕机，到了12年基于开源Kafka，直接用java语言翻译重写 Metaq 2.x 2012年11月上线，淘宝内部使用 RocketMQ 3.x 后来一统江湖成为整个阿里系主流MQ。基于公司内部开源共建原则， RocketMQ项目只维护核心功能，且去除了所有其他运行时依赖，核心功能最简化。每个BU的个性化需求都在RocketMQ项目之上进行深度定制。RocketMQ向其他BU提供的仅仅是Jar包，例如要定制一个Broker，那么只需要依赖rocketmq-broker这个jar包即可，可通过API进行交互，如果定制client，则依赖rocketmq-client这个jar包，对其提供的api进行再封装。

一、概述 1.1、简介 Zookeeper是一个开源的，分布式的，为分布式应用提供协调服务的Apache项目 1.2、工作机制 Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化Zookeeper就将负责通知已经在Zookeeper.上注册的那些观察者做出相应的反应。 1.3、特点 1） Zookeeper： 一个领导者（Leader） ，多个跟随者（Follower） 组成的集群。 2）集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。 3）全局数据一致：每个Server保存一份相同的数据副本，Client无论 连接到哪个Server，数据都是一致的。 4）更新请求顺序进行，来自同一个Client的更新请求按其发送顺序依次执行。 5）数据更新原子性，一次数据更新要么成功，要么失败。 6）实时性，在一定时间范围内，Client能读到最新数据。 1.4、数据结构 ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。 znode一共有4种类型：持久的（persistent）、临时的 （ephemeral）、持久有序的