ZooKeeper

SpringCloud 什么是微服务？ 要想学习微服务，首先需要知道什么是微服务？为什么会有微服务？相信看完架构的发展史读者就会明白 架构发展史 单体应用架构 如图所示：将所有的模块，所有内容(页面、Dao、Service、Controller)全部写入一个项目中，放在一个Tomcat容器中启动 适用于小型项目 优点：开发速度快，可以利用代码生成工具快速的开发一个项目 缺点：不易扩展，代码耦合度高，且不容错(当某部分出错后整个服务就会停止运行) 垂直架构 既然原来单体架构中代码耦合度高，不利于维护和运行，人们自然就想到将不同的内容分开。最简单合理的方式就是将系统按照功能划分成不同的模块，然后将各模块独立放入不同的Web容器中，这就形成了垂直架构 优点：代码耦合度降低，且不同模块之间可以独立运行。一旦某个模块压力过大，可以针对性的搭集群 缺点：模块之间有可能不是那么完全独立，导致实体类或者其他层代码不能复用，需要多出粘贴，不方便日后维护。如果直接通过HTTP调用又不是很合理。 分布式架构/分布式SOA架构 分布式架构顾名思义就是分散部署在不同的机器上的服务，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的架构。从开发的角度看就是Controller层(服务消费者)和Service层(服务提供者)分成不同的项目

原文：https://www.cnblogs.com/ityouknow/p/9340591.html 在上个月我们知道 Eureka 2.X 遇到困难停止开发了，但其实对国内的用户影响甚小，一方面国内大都使用的是 Eureka 1.X 系列，另一方面 Spring Cloud 支持很多服务发现的软件，Eureka 只是其中之一，下面是 Spring Cloud 支持的服务发现软件以及特性对比： Feature euerka Consul zookeeper etcd 服务健康检查 可配支持 服务状态，内存，硬盘等 (弱)长连接，keepalive 连接心跳 多数据中心 — 支持 — — kv 存储服务 — 支持 支持 支持 一致性 — raft paxos raft cap ap ca cp cp 使用接口(多语言能力) http（sidecar） 支持 http 和 dns 客户端 http/grpc watch 支持 支持 long polling/大部分增量 全量/支持long polling 支持 支持 long polling 自身监控 metrics metrics — metrics 安全 — acl /https acl https 支持（弱） spring cloud 集成 已支持 已支持 已支持 已支持 在以上服务发现的软件中，Euerka 和 Consul

分布式锁简述 在单机时代，虽然不存在分布式锁，但也会面临资源互斥的情况，只不过在单机的情况下，如果有多个线程要同时访问某个共享资源的时候，我们可以采用线程间加锁的机制，即当某个线程获取到这个资源后，就需要对这个资源进行加锁，当使用完资源之后，再解锁，其它线程就可以接着使用了。例如，在JAVA中，甚至专门提供了一些处理锁机制的一些API（synchronize/Lock等）。 但是到了分布式系统的时代，这种线程之间的锁机制，就没作用了，系统可能会有多份并且部署在不同的机器上，这些资源已经不是在线程之间共享了，而是属于进程之间共享的资源。因此，为了解决这个问题，「分布式锁」就强势登场了。 分布式锁是控制分布式系统之间同步访问共享资源的一种方式。在分布式系统中，常常需要协调他们的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，在这种情况下，便需要使用到分布式锁。 在分布式系统中，常常需要协调他们的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，这个时候，便需要使用到分布式锁。 分布式锁要满足哪些要求呢？ 排他性：在同一时间只会有一个客户端能获取到锁，其它客户端无法同时获取 避免死锁：这把锁在一段有限的时间之后

一、分布式session 　　session 是啥？浏览器有个 cookie，在一段时间内这个 cookie 都存在，然后每次发请求过来都带上一个特殊的 jsessionid cookie ，就根据这个东西，在服务端可以维护一个对应的 session 域，里面可以放点数据。 　　一般的话只要你没关掉浏览器，cookie 还在，那么对应的那个 session 就在，但是如果 cookie 没了，session 也就没了。常见于什么购物车之类的东西，还有登录状态保存之类的。 　　这个不多说了，懂 Java 的都该知道这个。 　　单块系统的时候这么玩儿 session 没问题，但是你要是分布式系统呢，那么多的服务，session 状态在哪儿维护啊？ 　　（1）完全不用 session 　　使用 JWT Token 储存用户身份，然后再从数据库或者 cache 中获取其他的信息。这样无论请求分配到哪个服务器都无所谓 　　（2）tomcat + redis 　　这个其实还挺方便的，就是使用 session 的代码，跟以前一样，还是基于 tomcat 原生的 session 支持即可，然后就是用一个叫做 Tomcat RedisSessionManager 的东西，让所有我们部署的 tomcat 都将 session 数据存储到 redis 即可。 　　在 tomcat 的配置文件中配置：

锁的机制一般都是用于多线程安全中，多线程竞争统一资源 一、 java的 synchronized： lock： java.util.concurrent.locks lock.lock(); try{ // 处理 }catch(Exception ex){ // 捕获异常 }finally{ // 释放锁 lock.unlock(); } 二、JMM的volatile锁关键字。 保证可见性,保证线程不从自己的副本中读值，都强制从主工作区读取值！ 三、数据库的锁 select * from table where ? lock in share mode;//共享锁 select * from table where ? for update;//排他锁 悲观锁：觉得我在操作的时候一定有人试图来篡改干扰我，很悲观，所以会给加上一个排他锁。 乐观锁：觉得别人对我当前操作的影响无所谓，非常乐观，即便出现了冲突，让用户决定和承担，所以只会加共享锁！ 四、分布式锁 本地锁在分布式架构中就实效了，所以分布式需要自己特定的分布式锁的概念： 基于数据库实现分布式锁：当我们要锁住某个方法或资源的时候，我们就在该表中增加一条记录，想要释放锁的时候就删除这条记录。（同Redis一样，不过数据库的操作会比Redis慢，因为Redis是基于内存缓存数据库） 基于缓存（Redis等）实现分布式锁；

zookeeper是一个高性能,可扩展的服务.zookeeper的读操作 和写操作的设计目标就是速度快,不过zookeeper的读比写快,在读的场景下,zookeeper可以将读的压力分散到不同的follow服务节点上,而且需要读取的数据大部分是已经被更新好了的'旧'的数据,而写操作需要在各个节点间保证一致性同步.保证数据的一致性同步是zookeeper的核心功能,他提供如下保证: 顺序一致性: 从客户端发送过来的命令是按照时间先后顺序有序执行的(注:更新操作是leader节点执行的,读取请求leader/follow都可以执行) 原子性: 更新操作的结果要么成功要么失败,没有部分成功或者部分失败的情况,不会产生部分结果 单一的一致系统映像:客户端读取到数据都是一致的,也就是讲对于一个zookeeper集群来讲,同一时间节点上客户端在任何一个节点读取的数据都是一致的,即使有些特殊情况下zookeeper发生了故障转移,客户端也不会读取到脏的数据 可靠性: 一旦更新被应用了,那么数据就会被持久化了不会被丢失或者篡改除非客户端后面主动的修改这个值,这个保证有2个推论: 如果客户端得到了一个操作的success code,那么这个更新操作就被应用了.一个服务端错误产生了()那么客户端是不知道的操作是成功还是失败了,我们采取的步骤是尽量减少失败,但只有返回成功代码的操作才有保证

一 分布式中的CAP怎么理解 1 CAP C（Consistency）一致性 每一次读取都会让你得到最新的写入结果 A （Availability）可用性 每个节点(如果没有失败)，总能执行查询(读取和写入)操作 P （Partition Tolerance）分区容忍性 即使节点之间的连接关闭，其他两个属性也会得到保证 CAP理论认为，任何联网的共享数据系统智能实现三个属性中的两个，但是可以通过明确处理分区，优化一致性和可用性，从而实现三者之间的某种权衡 2 zookeeper提供的一致性服务 很多文章和博客里提到，zookeeper是一种提供强一致性的服务，在分区容错性和可用性上做了一定折中，这和CAP理论是吻合的。但实际上zookeeper提供的只是单调一致性。 原因： 　　1. 假设有2n+1个server，在同步流程中，leader向follower同步数据，当同步完成的follower数量大于 n+1时同步流程结束，系统可接受client的连接请求。如果client连接的并非同步完成的follower，那么得到的并非最新数据，但可以保证单调性。 　　2. follower接收写请求后，转发给leader处理；leader完成两阶段提交的机制。向所有server发起提案，当提案获得超过半数（n+1）的server认同后，将对整个集群进行同步，超过半数（n+1

后端架构师图鉴 作者：星晴（当地小有名气，小到只有自己知道的杰伦粉） 忽略：我准备从博客园（ https://www.cnblogs.com/pingping-joe/ ）转移到公众号了！！！ 从2017年开始写博客到现在，经历了几家公司，碰到不少有趣的人，人也成长不少，褪去幼稚的面孔，只剩下越发后移的发际线；一路坎坷，唯一还在坚持的就只剩下写博客了，虽然不知道为什么坚持，但是感觉还不错。 今天第一天发公众号推文，作为搞java的，还是给大家准备了架构师的学习路线。当然如果大家都知道，可以忽略。 架构师学习路线大致分为五个部分： 互联网运维 Git，Maven，Gradle，jenkins，linux 框架源码分析 Spring , Mybatis 并发编程 并发包 性能调优 JVM调优，Mysql调优，Nginx调优，Tomcat调优 分布式框架 分布式服务治理：Dubbo, Zookeeper, SpringCloud-Alibaba,SpringCloud-NetFliex 分布式消息：RocketMq, RabbitMq, Kafka 分布式数据缓存：Redis 分布式数据存储：Sharding-sphere 分布式通信：Netty 分布式搜索引擎：ELK 如果想要完整的学习路线，请关注公众号，并且回复【1】，谢谢支持 本文分享自微信公众号 - 喜欢奶茶的星晴（code

0. Env list: Oracle Linux:6.10 Oracle DB 11.2.0.4 OGG4Ora:19.1 OGG4BD:19.1 1.Install package for OCI instance: yum groupinstall "X Window System" yum install oracle-rdbms-server-11gR2-preinstall Yum install java yum -y groupinstall kde-desktop yum install -y java-1.8.0-openjdk.x86_64 yum install tiger-vncserver https://scriptingmysql.wordpress.com/2019/11/22/how-to-setup-a-gui-via-vnc-for-your-oracle-linux-compute-instance-in-oracle-cloud-infrastructure-oci/ 2.OS Configuration a.service iptables stop b.profile: #!/bin/bash ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1; export ORACLE_HOME

HDFS HA Namenode HA 详解　　 　　hadoop2.x 之后，Clouera 提出了 QJM / Qurom Journal Manager ，这是一个基于 Paxos 算法（分布式一致性算法）实现的 HDFS HA 方案，它给出了一种较好的解决思路和方案,QJM 主要优势如下： 　　不需要配置额外的高共享存储，降低了复杂度和维护成本。 　　消除 spof(单点故障)。 　　系统鲁棒性(Robust)的程度可配置、可扩展。 　　 基本原理就是用 2N+1 台 JournalNode 存储 EditLog，每次写数据操作有>=N+1 返回成功时即认为该次写成功，数据不会丢失了 。当然这个算法所能容忍的是最多有 N台机器挂掉，如果多于 N 台挂掉，这个算法就失效了。这个原理是基于 Paxos 算法。 　　在 HA 架构里面 SecondaryNameNode 已经不存在了，为了保持 standby NN 时时的与 Active NN 的元数据保持一致，他们之间交互通过 JournalNode 进行操作同步。 　　任何修改操作在 Active NN 上执行时，JournalNode 进程同时也会记录修改 log到至少半数以上的 JN 中，这时 Standby NN 监测到 JN 里面的同步 log 发生变化了会读取 JN 里面的修改 log