ZooKeeper

实战：10 分钟掌握分布式 ID 之雪花算法 一个在生产每天经过1亿+数据量验证的id生成器 背景 1.为什么要使用雪花算法生成 ID -- 保证 id 全局唯一 -- 保证 id 自增长 -- uuid 无序且过长 雪花算法 ID 组成 1: 1位标识部分： --- 在 java 中由于 long 的最高位是符号位，正数是 0，负数是 1，一般生成的 ID 为正数，所以为 0； 2: 41 位时间戳部分： --- 这个是毫秒级的时间，一般实现上不会存储当前的时间戳，而是时间戳的差值（当前时间-固定的开始时间），这样可以使产生的 ID 从更小值开始；41 位的时间戳可以使用 69 年，(1L<< 41) / (1000L _ 60 _ 60 _ 24 _ 365) = 69 年； 3: 10 位workid： Twitter 实现中使用前 5 位作为数据中心标识，后 5 位作为机器标识，可以部署 1024 个节点。我这里的实现根据服务名生产的，意思就是说每个服务只要不超过 1024 个节点就不会有问题，实际生产中我也没有见过某个服务有 1024 个节点的。 4: 12 位序列号部分： --- 支持同一毫秒内同一个节点可以生成 4096 个 ID。意思就是说某个服务 1ms 能生成 4096 个 id，如果你单表的 TPS 超过 4096\*60s，那可能就会出问题了

目录 一、原理简述 二、Producer 原理 三、Producer 端参数详解 四、Kafka Server 基本原理 五、KafkaServer 主分区与副本数据同步原理 六、KafkaServer 零拷贝原理 七、KafkaServer Leader 选举 八、KafkaConsumer 原理 九、KafkaConsumer 参数详解 十、性能优化方案 一、原理简述 【1】 Producer 将消息进行分组分别发送到对应 leader 节点； 【2】 Leader 将消息写入本地 log ； 【3】 Followers 从 Leader pull 最新消息，写入 log 后向 Leader 发送 ack 确认； 【4】 Leader 收到所有 ISR 中的 Follower 节点的 ACK 后，增加 HW ，标记消息已确认全部备份完成，最后返回给 Producer 消息已提交成功； 【5】消费端从对应 Leader 节点 poll 最新消息并消费，消费完成后将最新的 offset 位置提交至 Topic 为 _consumer_offsets 的主节点中保存。 二、Producer 原理 初始化 KafkaProducer，会创建一个后台线程 KafkaThread ，会循环的判断缓存中的数据是否需要提交。同时会发送消息，主要指定 Topic和 Value，不建议指定

一、RPC框架 比起普通的集群模式，采用微服务分布式系统，使系统之间的耦合度大大降低，并且可以独立开发、部署、测试。由于分布式系统可能有很多独立的子系统组成，业务量增强以后，子系统通信关系复杂，这时就需要引入RPC框架 简单介绍RPC（Remote Procedure Call），大部分RPC框架都使用TCP协议。比如微服务A需要调用微服务B的一个类的一个方法。A服务与B服务需要先建立一个Socket传输。原理基于 序列化和反序列化 。B服务将Java对象序列化为二进制格式，传给A服务端，A服务端接收到之后，再反序列化为Java对象,服务A就可以调用这个Java对象了。比起Restful的http模式，RPC是面向过程的，直接用二进制格式进行传输。 二、Dubbo 设计架构 官方文档：http://dubbo.apache.org/zh-cn/ Apache Dubbo |ˈdʌbəʊ| 是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。 Dubbo 特性 三、Dubbo控制管理台 github: https://github.com/apache/dubbo-admin.git Dubbo控制管理台是springboot + VUE.JS 前后端分别启动就可以了

Hbase集群搭建 1. 解压： hbase压缩包位置 链接：https://pan.baidu.com/s/1HYQGn9-DqWxlCmV6QAOKqA 提取码：vtu5 [root@master /]# cd /soft #进入Hbase压缩包位置 [root@master soft]# tar -xzvf hbase-1.2.0-bin.tar.gz #解压 2. 创建软链接 [root@master soft]# ln -s hbase-1.2.0 /soft/hbase 3. 添加环境变量 [root@master soft]# vi /etc/profile #添加如下内容 export HBASE_HOME=/soft/hbase export PATH=$HBASE_HOME/bin:$PATH [root@master soft]# source /etc/profile #生效 4. 编辑hbase-env.sh文件 （在$HBASE_HOME/conf下） [root@master hbase]# cd $HBASE_HOME/conf [root@master conf]# vi hbase-env.sh 添加如下配置 export JAVA_HOME=/soft/jdk #添加Java环境变量export HBASE_MANAGES_ZK=false

本篇文章为系列文章，未读第一集的同学请猛戳这里： RPC 框架 Dubbo 从理解到使用（一） 本篇文章讲解 Dubbo 支持的注册中心、Dubbo 负载均衡策略和 Dubbo 控制台的安装。 　　 注册中心支持 　　 　　注册中心可以更高效的管理系统的服务：比如服务接口的发布、自动剔除无效的服务、自动恢复服务等。 　　Dubbo 支持五种注册中心：Multicast、Nacos(推荐)、ZooKeeper(推荐) 、Redis、Simple。本文重点介绍前三个，更多注册中心的信息请参考： http://dubbo.apache.org/zh-cn/docs/user/references/registry/introduction.html 　　 Multicast 注册中心 　　 　　Multicast 注册中心不需要启动任何中心节点，只要广播地址一样，就可以互相发现。 提供方启动时广播自己的地址 消费方启动时广播订阅请求 提供方收到订阅请求时，单播自己的地址给订阅者，如果设置了 unicast=false ，则广播给订阅者 消费方收到提供方地址时，连接该地址进行 RPC 调用。 　　组播受网络结构限制，只适合小规模应用或开发阶段使用。组播地址段: 224.0.0.0 - 239.255.255.255 　　 配置 　　 <dubbo:registry address=

前言 哨兵sentinel是redis自带的高可用程序,可以发现并自动切换主从状态的redis服务配置,而且哨兵sentinel还可以支持管理多套redis主从. 而应用可以通过类似jedis的驱动直接连接哨兵,来实现高可用.jedis会在哨兵sentinel里发现真实的主库地址,然后让程序连上真实主库地址操作. 不过这个架构有三个问题,第一,应用程序的配置要实现这个功能的话就要从连接真实IP的redis改成连接哨兵.第二,如果哨兵挂了,应用会报错而无法切换(3.2还会出现).第三,如果一套哨兵管理多套redis主从,并不是很好管理. 解决的方法有两个,一个是在哨兵前面加类似nginx的负载均衡来控制jedis访问哨兵地址,另一个就是在redis主从上加入高可用vip的操作来代替jedis直连哨兵,因为哨兵sentinel支持切换发生时接入脚本操作. 这篇文章说的就是加入高可用vip方式. 哨兵sentinel通信原理 在讲主题之前,我想想讲一下哨兵sentinel的原理. 通讯原理: 当一个完全没接入哨兵sentinel的redis主从里,第一个哨兵sentinel主动和redis主库通信,询问有没有其他的redis从库和哨兵sentinel连接信息.如果没有,这个哨兵sentinel就创建配置,等待同步其他哨兵信息. 然后,第二个哨兵连进redis主库

前言 关于Spring Cloud的知识总结了一个思维导图分享给大家 1、什么是 Spring Cloud ？ Spring cloud 流应用程序启动器是 于 Spring Boot 的 Spring 集成应用程序，提供与外部系统的集成。Spring cloud Task，一个生命周期短暂的微服务框架，用于快速构建执行有限数据处理的应用程序。 2、使用 Spring Cloud 有什么优势？ 使用 Spring Boot 开发分布式微服务时，我们面临以下问题 （1）与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题。 （2）服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，在该目录中注册服务，然后能够查找并连接到该目录中的服务。 （3）冗余-分布式系统中的冗余问题。 （4）负载平衡 --负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路，中央处理单元，或磁盘驱动器的分布。 （5）性能-问题 于各种运营开销导致的性能问题。 （6）部署复杂性 evops 技能的要求。 3、服务注册和发现是什么意思？Spring Cloud 如何实现？ 当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化

缓存 缓存的作用： 高并发、高性能 高性能：查询速度快 高并发：缓存是走内存的，内存天然就支撑高并发 常见缓存问题： 缓存与数据库双写不一致 缓存雪崩、缓存穿透、缓存击穿 缓存并发竞争 如何保证缓存和数据库一致性： 使用串行化，即：将读请求和写请求放到一个内存队列中。 串行化可以保证缓存与数据库一直，但是会导致系统吞吐量大幅度降低。非严格要求，不要串行化。 经典缓存+DB读写模式 》读：先读缓存，没有读取DB,读出来放入缓存。 》更新：先更新DB,再 删除 缓存。 缓存雪崩 请求量大时，缓存此时也跌机了，导致大量请求直接请求DB,带着DB也跌机了。 缓存雪崩的事前事中事后的解决方案： 事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。 事后：Redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。 缓存穿透 缓存中查询不到，大量的请求直接查询DB. 解决方案： 每次系统 A 从数据库中只要没查到，就写一个空值到缓存里去，比如 set -999 UNKNOWN 。然后设置一个过期时间，这样的话，下次有相同的 key 来访问的时候，在缓存失效之前，都可以直接从缓存中取数据。 缓存击穿 某个 key 非常热点，访问非常频繁，处于集中式高并发访问的情况

首先要知道的是Spring Cloud是微服务架构。 微服务架构是一种架构模式，它将单一的应用程序划分成一组很小的服务，服务之间相互协调、互相配合。每个服务都运行在独立的进程中，服务与服务间采用轻量级通信机制（通常是HTTP协议的RESTful API）。每个服务都有着自己的业务，并且能够被独立的部署到生产环境、类生产环境等，对于具体的一个服务而言，应该根据上下文，选择合适的语言、工具对其进行构建。 Spring Cloud中是一种微服务架构，项目案例：www.1b23.com，其中包含如下功能： 服务注册与发现、服务调用、服务熔断、负载均衡、服务降级、服务消息队列、配置中心管理、服务网关、服务监控、全链路追踪、自动化构建部署、服务定时任务。 但是在项目中一般只会用到如下几种： 服务注册与发现：EUREKA 服务负载与调用：NETFLIX OSS RIBBON、NETFLIX FEIGN 服务熔断降级：HYSTRIX 服务网关：NETFLIX Zuul 服务器分布式配置：Spring Coloud Config 服务开发：Spring Boot 下面来看下官方解析 Cloud 分布式系统的开发与一般的系统来说是具有挑战性的。服务之间的交流更为密切，Cloud把项目的工作重点由应用层移到了网络层。代码想要连接到Cloud服务需要12个因素，如配置文件，状态，日志，连接到后端的服务

大数据技术栈——Hadoop概述 1 引例 2 MapReduce 3 HDFS 4 Hadoop 5 HBase 5.1 逻辑模型 5.2 物理模型 5.3 Region服务器 6 Hive 7 Pig 8 ZooKeeper 8.1 ZooKeeper的特性 8.2 ZooKeeper的设计目标 1 引例 Hadoop是专为离线和大规模数据分析而设计的，上图Hadoop整体技术框架描述。（为了方便学习，会先介绍Map Reduce与HDFS） 2 MapReduce MapReduce是Google提出的大规模并行计算解决方案，应用于大规模廉价集群上的大数据并行处理（Map Reduce1.0运行模型如下）。 MapReduce以key/value的分布式存储系统为基础，采用“分而治之”的思想，是一种并行编程模型，将计算阶段分为两个阶段：Map阶段（分）和Reduce阶段（治）。 原理：利用一个输入（key，value）对的集合产生一个输出的（key，value）对的集合。 map阶段 ：被分配了map任务的worker程序读入数据片段，解析出（key，value）对，传给用户定义的Map函数，Map函数生出中间对，缓存在内存中。 Reduce阶段 ：该阶段由Reduce函数把Map阶段具有相同key值的中间结果收集到相同Reduce结点进行合并处理，并将结果写入本地磁盘