ZooKeeper

微服务架构要求： 根据业务模块划分服务种类 每个服务可独立部署且互相隔离 通过轻量级API调用服务 服务需保证良好的高可用 微服务技术选型： 使用 Spring Boot 开发服务 使用 Node.js 作为服务网关反向代理调用服务 使用 Zookeeper 注册发现服务 使用 Docker 封装/部署/隔离服务 使用 Jenkins 构建发布服务 Spring Boot Spring4.0推荐使用Java代码和注解方式作为配置（去xml）， Spring Boot 遵循相关理念且采用4.0相关特性和技术，集成了主流组件，可创建一个内嵌Servlet容器的jar独立运行，且提供生产级特性（服务治理）。 Node.js Node.js 是基于ChromeV8引擎的Javascript 运行环境 ，它使用“ 事件驱动 ”且“ 异步非I/O ”的模型使其轻量且高效，Node.js的包管理器NPM是全球最大的开源库生态系统。 Node.js 是运行环境，而非Javascript类库和框架， NPM 与Java的Maven异曲同工，事件驱动把事件加入队列中轮训。Node.js采用 单线程模型 ，适用于 I/O密集型应用 （高并发网站）。 Node.js内置HTTP服务器（模块），性能和稳定性与Nginx不分伯仲。且模块体系强大，比如Web框架 Express ，Web Socket服务

摘要： 高可用性对于我们来说应该属于经常提到的名词，本文我们将介绍在分布式系统中保证高可用性的一些常用经验。 系统可用性指标 系统可用性指标简单来将就是系统可用时间与总运行时间之比 Availability=MTTF/(MTTF+MTTRMTTF) ​MTTF 是 Mean Time To Failure，指平均故障前的时间，即系统平均能够正常运行多长时间才发生一次故障。系统的可靠性越高，MTTF 越长(简单理解MTTF 就是指系统正常运行的时间)。MTTR 是 Mean Time To Recovery， 平均修复时间，即从故障出现到故障修复的这段时间，也就是系统不可用的时间，这段时间越短越好。系统可用性指标可以用通过下表的999标准衡量，现在普遍要求至少2个9，最好4个9以上： 故障不可避免 高可用性是指系统提供的服务要始终可用，然而故障不可避免，特别是在分布式系统，面对不可控的用户流量和机房环境，系统故障将会显得更加复杂和不可预测。在大规模的分布式系统中，各个模块之间存在错综复杂的依赖，任一一个环节出现问题，都有可能导致雪崩式、多米诺骨牌式的故障，甚者可以断言出现故障成了常态。 如上图的分布式系统中，用户请求系统中的某个服务接口，请求需要经过长长的调用链才能处理返回。我们起码要保证网络连接正常，服务网关正常、前端服务正常、后台服务正常、数据库正常，请求才能被正常处理

hbase列式分布式数据库： 结构化数据和非结构化数据 支持实时数据处理 列存储 水平扩展优秀 HBASE接口：java api ，shell，hive HBASE数据模型： 列式存储在数据分析中效率很高，同一列数据类型相同可以达到更高的压缩率； 事务性操作比较多使用传统 行式存储； 分析型应用为主 列式储存； master服务器： 分区信息维护和管理、维护region服务器列表、监控region、负责对region进行分配、负载均衡 region服务器： 客户端存取数据、维护redion hbase三级寻址： zookeeper -> -ROOT表-> .META->用户数据表 hbase安装： 伪分布式： hbase-site.xml文件 <property> <name>hbase.cluster.distributed</name> #是否为分布式 <value>true</value> </property> <property> <name>hbase.rootdir</name> <value>hdfs://weide:8020/hbase</value> #hbase共享目录，持久化hbase数据 </property> <property> <name>hbase.master.port</name> #hbasemaster的主机和端口 <value>weide

迄今，相信大家肯定听说过 HBase，但是对于 HBase 的了解可能仅仅是它是 Hadoop 生态圈重要的一员，是一个大数据相关的数据库技术。 今天我带你们一起领略一下 HBase 体系架构，看看它是如何大规模处理海量数据。 一、什么是 HBase？ 关于 HBase 的实现，是基本遵循 Bigtable 的论文。HBase 是一个面向列的分布式数据库，也是个非关系型数据库系统（NoSQL），它建立在 Hadoop 文件系统之上。面向列的数据库是将数据表存储为数据列的一部分而不是数据行的数据库。 HBase 是一个分布式，持久，严格一致的存储系统，具有接近最佳的写入 I / O 通道饱和度和出色的读取性能。而且 HBase 只考虑单个索引，类似于 RDBMS 中的主键，提供服务器端实现灵活的二级索引解决方案。 二、为什么使用 HBase？ HBase 是 Hadoop 生态圈中重要的一环，用于存储，管理和处理数据。我们知道 Hadoop HDFS 是无法处理高速随机写入和读取，也无法在不重写文件的情况下对文件进行修改。HBase 正好解决了 HDFS 的缺点，因为它使用优化的方式快速随机写入和读取。此外，随着数据呈指数增长，关系数据库无法提供更好性能去处理海量的数据。HBase提供可扩展性和分区，以实现高效的存储和检索。 三、HBase 体系架构 我们先来看看 HBase

HBase的 卡桑德拉 HBase is based on Bigtable (Google) Cassandra基于DynamoDB（Amazon）。它最初是由前亚马逊工程师在Facebook上开发的。这就是Cassandra支持多数据中心的原因之一。 HBase使用Hadoop基础架构（Zookeeper, NameNode, HDFS）。部署Hadoop的组织必须具有Hadoop和HBase的知识 Cassandra与Hadoop分开启动和发展, 其基础架构和操作知识要求与Hadoop不同。但是, 对于分析, 许多Cassandra部署使用Cassandra + Storm（使用zookeeper）和/或Cassandra + Hadoop。 HBase-Hadoop基础结构具有几个“活动部分”, 包括Zookeeper, 名称节点, HBase主服务器和数据节点, Zookeeper是集群的并且自然地具有容错能力。需要对名称节点进行群集以容错。 Cassandra使用单个节点类型。所有节点均相等, 并执行所有功能。任何节点都可以充当协调器, 从而确保没有Spof。当然, 添加风暴或Hadoop会增加基础架构的复杂性。 HBase非常适合进行基于范围的扫描。 Cassandra不支持基于范围的行扫描, 这在某些用例中可能会受到限制。

以下部分内容来源于网络摘抄~ 1、简介 Broker : Kafka 服务器 ，一个服务器被称为一个Broker Topic : 每一类消息可以定义一个Topic Partition : 每个Topic都有1个或者多个partition，属于物理上的分隔 offset : 偏移量每个partition中的消息唯一标识 Producer : 消息发布者 Consumer ： 消息订阅者 Consumer Group : 属于订阅者独有的概念，默认为统一的group 它提供了类似于JMS的特性，但是在 设计 实现上完全不同，此外它并不是JMS规范的实现。 ①kafka对消息保存时根据Topic进行归类，发送消息者成为Producer,消息接受者成为Consumer, ②此外kafka集群有多个kafka实例组成，每个实例( server )成为 broker 。 ③无论是kafka集群，还是producer和consumer都依赖于 zookeeper 来保证系统可用性集群保存一些meta信息。 2.Topics/logs ① 一个Topic可以认为是一类消息，每个topic将被分成多个partition(区),每个partition在存储层面是append log文件。 ②任何发布到此partition的消息都会被直接追加到log文件的尾部，每条 消息 在文件中的 位置 称为

前言： 随着笔者的颜值不断提高，用户量的日益增长，传统的单机方案已经不能满足产品的需求。笔者在网上寻遍方案，发现均为人云亦云，一份以毫秒为精度的轮询分布式锁被转发转载上万次。然，该方案没法满足笔者性能要求。故此，笔者研发ELock插件，并发布本文章。 其实集群也好，分布式服务也好。当我们不能保证团队成员的整体素质，那么在某些业务上，分布式锁自然没法避免。 公认开发原则：能不使用分布式锁的，尽可能不使用 举个例子，一个商品交易，需要检查库存、检查余额、扣库存、扣款、变更订单状态。可能很多人觉得，在分布式环境下一定要分布式锁才能安全。 致此，笔者提供一种简单的方案： 订单处理{ if(订单状态!=待支付){ return 该订单已处理; } if(库存不足){ return 库存不足; } if(余额不足){ return 余额不足; } 事务管理(rollbackFor = Exception.class){ //修改订单状态 int changeLine = 执行语句( update 订单表 set status=已支付 where status=待支付 and orderId=订单号); if(changeLine < 1){ return 该订单已处理; } //扣库存 changeLine = 执行语句(update 商品表 set 库存=库存-订单信息.购买数量 where

第1章 Kafka 概述 1.1 消息队列 （ 1 ）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除） 点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。 （ 2 ）发布 / 订阅模式（一对多，数据生产后，推送给所有订阅者） 发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，处于离线状态。 1.2 为什么需要 消息队列 1） 解耦： 　　允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 2） 冗余： 消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的 " 插入 - 获取 - 删除 " 范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。 3） 扩展性： 因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。 4） 灵活性 & 峰值处理能力： 在访问量剧增的情况下，应用仍然需要继续发挥作用

第一部分 Kafka架构与实战 1.1 概念和基本架构 1.1.1 Kafka介绍 Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多生产者、多订阅者，基 于zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日 志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。 主要应用场景是：日志收集系统和消息系统。 Kafka主要设计目标如下： 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。 * 同时支持离线数据处理和实时数据处理。 支持在线水平扩展 有两种主要的消息传递模式：点对点传递模式、发布-订阅模式。大部分的消息系统选用发布-订阅模式。Kafka就是一种发布-订阅模式。 对于消息中间件，消息分推拉两种模式。Kafka只有消息的拉取，没有推送，可以通过轮询实现消息的推送 Kafka在一个或多个可以跨越多个数据中心的服务器上作为集群运行。 Kafka集群中按照主题分类管理，一个主题可以有多个分区，一个分区可以有多个副本分区。

开源Linux 一个执着于技术的公众号 版本 • JDK 14 • Zookeeper • Kafka 安装 Zookeeper 和 Kafka Kafka 依赖 Zookeeper，所以我们需要在安装 Kafka 之前先拥有 Zookeeper。准备如下的 docker-compose.yaml 文件，将文件中的主机地址 192.168.1.100 替换成你自己的环境中的主机地址即可。 version : "3" services : zookeeper : image : zookeeper build : context : ./ container_name : zookeeper ports : - 2181 : 2181 volumes : - ./ data / zookeeper / data :/ data - ./ data / zookeeper / datalog :/ datalog - ./ data / zookeeper / logs :/ logs restart : always kafka_node_0 : depends_on : - zookeeper build : context : ./ container_name : kafka - node - 0 image : wurstmeister / kafka environment