ZooKeeper

什么是MQ？ 消息总线(Message Queue)，是一种跨进程、异步的通信机制，用于上下游传递消息。 由消息系统来确保消息的可靠传递。 MQ是干什么用的？ 应用解耦、异步、流量削锋、数据分发、错峰流控、日志收集等等... MQ衡量标准 服务性能、数据存储、集群架构 ActiveMQ ActiveMQ是apache出品，最流行的，能力强劲的开源消息总线，并且它一个完全支持JMS规范的消息中间件。其丰富的API、多种集群构建模式使得它成为业界老牌消息中间件，在中小型企业中应用广泛。 是其性能稍差，在面对高并发的情况下，会出现消息阻塞、堆积、延迟等问题。 默认采用了基于内存的kahaDB进行存储，如果需要保证消息的可靠性，也可以选择关系行数据库进行存储。 集群架构模式如下： Master-Slave模式：通过zookeeper对主从进行管理，正常情况下，从节点不会提供服务。当主节点出现问题后，zookeeper会高效的将主节点下掉，从节点来提供服务。 NetWork模式：两套主从Master-Slave节点。由网络联通，将其变为分布式的集群架构。 Kafka Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache顶级项目。Kafka主要特点就是 基于Pull的模式来处理消息消费 ， 追求高吞吐量 ，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制

ZooKeeper is a high-performance coordination service for distributed applications . It exposes common services - such as naming, configuration management, synchronization, and group services - in a simple interface so you don’t have to write them from scratch. You can use it off-the-shelf to implement consensus, group management, leader election, and presence protocols. And you can build on it for your own, specific needs. 参考资料： Apache > ZooKeeper ZooKeeper+Dubbo分布式架构基础教程 来源： oschina 链接： https://my.oschina.net/u/4406698/blog/4458814

微服务、云原生、Kubernetes、Service Mesh 是分布式领域的热点技术，它们并不是凭空出现的，一定继承了某些“前辈”的优点。我们不仅要了解这些技术，还要深入理解其发展脉络、原理等，才能游刃有余地将其用于现有的项目开发或老系统改造中。 以下是这位资深架构师的笔记内容： 由于内容过多，为了避免影响到大家的阅读体验，在此只以截图展示部分内容。有需要获取完整版的朋友点赞后，私信【笔记】即可（一定要记得关注我，不然没办法回复陌生人私信） 第1章：深入理解网络 讲解分布式的基础一-网络， 对国际互联网、NIO、AIO、网络传输中的对象序列化问题、HTTP的前世今生、TCP/IP、从CDN到SD-WAN等知识进行深入讲解。 详细章节介绍： 从国际互联网开始 NIO, 一本难念的经 AIO,大道至简的设计与苦涩的现实 网络传输中的对象序列化问题 HTTP的前世今生 分布式系统的基石: TCP/IP 从CDN到SD-WAN 第2章：分布式系统的经典理论 讲解分布式系统的经典理论，涉及分布式系统的设计理念、-致性原理; ZooKeeper 的使用场景; CAP理论的前世今生; BASE准则;分布式事务的原理。 详细章节介绍： 从分布式系统的设计理念说起 分布式系统的一致性原理 分布式系统的基石之ZooKeeper 经典的CAP理论 BASE准则，一个影响深远的指导思想

基于SpringCloud分布式架构 为什么要使用分布式架构 Spring Cloud 专注于提供良好的开箱即用经验的典型用例和可扩展性机制覆盖 分布式/版本化配置 服务注册和发现 路由 Service-to-Service 调用 负载均衡 断路器 分布式消息传递 这是分布式的优点，这样看起来可能比较抽象，举个例子来说，对于单体服务来说，如果我想更新订单中的某个功能，我是不是需要重启整个服务。 这个时候就会导致整个项目都处于不可用状态，或者在处理订单的时候由于程序代码写的有问题，导致死锁了，这个时候也会导致整个服务处于宕机专改，容错率很差。 但是分布式不同，如上图所示，订单服务、售后服务、用户服务都是独立的服务，如果需要更新订单服务或者订单服务发生死锁，受影响的只会是订单服务，售后服务与用户服务还是可以正常工作的，这就是分布式相对单体来说最大的优势之一。 分布式基础组件 Spring Cloud Config：配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git 以及 Subversion。 Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与 Spring Cloud Config 联合实现热部署。 Eureka：云端服务发现，一个基于 REST 的服务，用于定位服务

KV 存储作为美团一项重要的在线存储服务，承载了在线服务每天万亿级的请求量。在 2019 年 QCon 全球软件开发大会（上海站）上，美团高级技术专家齐泽斌分享了《美团点评万亿级 KV 存储架构与实践》，本文系演讲内容的整理，主要分为四个部分：第一部分讲述了美团 KV 存储的发展历程；第二部分阐述了内存 KV Squirrel 架构和实践；第三部分介绍了持久化 KV Cellar 架构和实践；最后分享了未来的发展规划和业界新趋势。 美团点评 KV 存储发展历程 美团第一代的分布式 KV 存储如下图左侧的架构所示，相信很多公司都经历过这个阶段。在客户端内做一致性哈希，在后端部署很多的 Memcached 实例，这样就实现了最基本的 KV 存储分布式设计。但这样的设计存在很明显的问题：比如在宕机摘除节点时，会丢数据，缓存空间不够需要扩容，一致性哈希也会丢失一些数据等等，这样会给业务开发带来的很多困扰。 随着 Redis 项目的成熟，美团也引入了 Redis 来解决我们上面提到的问题，进而演进出来如上图右侧这样一个架构。大家可以看到，客户端还是一样，采用了一致性哈希算法，服务器端变成了 Redis 组成的主从结构。当任何一个节点宕机，我们可以通过 Redis 哨兵完成 Failover，实现高可用。但有一个问题还是没有解决，如果扩缩容的话，一致性哈希仍然会丢数据，那么这个问题该如何解决呢

本文源码： GitHub·点这里 || GitEE·点这里 一、高并发简介 在互联网的业务架构中，高并发是最难处理的业务之一，常见的使用场景：秒杀，抢购，订票系统；高并发的流程中需要处理的复杂问题非常多，主要涉及下面几个方面： 流量管理，逐级承接削峰； 网关控制，路由请求，接口熔断； 并发控制机制，资源加锁； 分布式架构，隔离服务和数据库； 高并发业务核心还是流量控制，控制流量下沉速度，或者控制承接流量的容器大小，多余的直接溢出，这是相对复杂的流程。其次就是多线程并发下访问共享资源，该流程需要加锁机制，避免数据写出现错乱情况。 二、秒杀场景 1、预抢购业务 活动未正式开始，先进行活动预约，先把一部分流量收集和控制起来，在真正秒杀的时间点，很多数据可能都已经预处理好了，可以很大程度上削减系统的压力。有了一定预约流量还可以提前对库存系统做好准备，一举两得。 场景：活动预约，定金预约，高铁抢票预购。 2、分批抢购 分批抢购和抢购的场景实现的机制是一致的，只是在流量上缓解了很多压力，秒杀10W件库存和秒杀100件库存系统的抗压不是一个级别。如果秒杀10W件库存，系统至少承担多于10W几倍的流量冲击，秒杀100件库存，体系可能承担几百或者上千的流量就结束了。下面流量削峰会详解这里的策略机制。 场景：分时段多场次抢购，高铁票分批放出。 3、实时秒杀 最有难度的场景就是准点实时的秒杀活动

　　 20 大进阶架构专题每日送达 　　链接：yq.aliyun.com/articles/601745 　　 2020年Java面试题库连载中 　　！ 　　 正文 　　站在未来的路口，回望历史的迷途，常常会很有意思，因为我们会不经意地兴起疯狂的念头，例如如果当年某事提前发生了，而另外一件事又没有发生会怎样？一如当年的奥匈帝国皇位继承人斐迪南大公夫妇如果没有被塞尔维亚族热血青年普林西普枪杀会怎样，又如若当年的丘老道没有经过牛家村会怎样？ 　　2007年底，淘宝开启一个叫做“五彩石”的内部重构项目，这个项目后来成为了淘宝服务化、面向分布式走自研之路，走出了互联网中间件体系之始，而淘宝服务注册中心ConfigServer于同年诞生。 　　2008年前后，Yahoo 这个曾经的互联网巨头开始逐渐在公开场合宣讲自己的大数据分布式协调产品 ZooKeeper，这个产品参考了Google 发表的关于Chubby以及 Paxos 的论文。 　　2010年11月，ZooKeeper从 Apache Hadoop的子项目发展为 Apache的顶级项目，正式宣告 ZooKeeper成为一个工业级的成熟稳定的产品。 　　2011年，阿里巴巴开源Dubbo，为了更好开源，需要剥离与阿里内部系统的关系，Dubbo 支持了开源的 ZooKeeper 作为其注册中心，后来在国内，在业界诸君的努力实践下

问：你们现在系统里有用消息队列么？ 答：有 这是一个面试官给你埋坑的开始！！大量的系统都有引入使用消息队列，也是目前业内比较流行的。还有比如 ZooKeeper、Redis、Dubbo 等等，都是目前比较热门的技术。在这里要小心了！面试官此时想慢慢过渡到你具体的业务场景中去了，关心你3个点：解耦、异步和削峰。 问：为什么要在系统中使用消息队列呀？ 答：emmm... 老板做好架构设计、技术选型之后，然后就让我们落地实现 兄弟！千万别脱离了需求分析、架构设计、技术选型和资源评估，只是关心技术的落地实现，往往是没经过深度思考的朋友才干的事儿。只是为了用而用，不知道在此架构设计下为啥会用某些技术。 问：系统中引入了消息队列，会不会有啥隐患？ 答：还没遇到过... 这里就惨了！！如果没做过深度技术调研，盲目地直接在系统中引入不熟悉的技术，这就坑爹了，也是挖坑小能手经常干的事儿。比如，可能会遇到这两个问题：第一，链路变长，造成请求响应时间变长，影响用户体验。第二，MQ本身高可用很重要，不然造成整个系统的瘫痪。 问：消息队列的产品有 RabbitMQ、RocketMQ、Kafka 等，你们选用哪个？技术调研后的依据是啥？ 答：&%#@*…！/(ㄒoㄒ)/~~ 那，我们还能不能好好搞懂 MQ？ 答案是可以的，小编整理了一套技术资料不仅能精准消除技术盲点、累计面试经验，更可以攻克MQ、JVM

1）背景 软件版本2.0.0 Released July 30, 2018 Release Notes Source download: kafka-2.0.0-src.tgz (asc, sha512) Binary downloads:We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended). Scala 2.11 - kafka_2.11-2.0.0.tgz (asc, sha512) Scala 2.12 - kafka_2.12-2.0.0.tgz (asc, sha512) 软件下载地址 http://kafka.apache.org/downloads.html 下载安装包 kafka_2.11-2.0.0.tgz 2）部署 cd kafka_2.11-2.0.0 chmod a+x bin/* //赋予服务器脚本运行需要的执行权限 vi config/server.properties //配置服务器的IP地址

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 什么是 ZooKeeper ZooKeeper 是 Apache 的一个顶级项目，为分布式应用提供高效、高可用的分布式协调服务，提供了诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知和分布式锁等分布式基础服务。由于 ZooKeeper 便捷的使用方式、卓越的性能和良好的稳定性，被广泛地应用于诸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分布式系统中。 ZooKeeper 有三种运行模式：单机模式、伪集群模式和集群模式。 单机模式：这种模式一般适用于开发测试环境，一方面我们没有那么多机器资源，另外就是平时的开发调试并不需要极好的稳定性。 集群模式：一个 ZooKeeper 集群通常由一组机器组成，一般 3 台以上就可以组成一个可用的 ZooKeeper 集群了。组成 ZooKeeper 集群的每台机器都会在内存中维护当前的服务器状态，并且每台机器之间都会互相保持通信。 伪集群模式：这是一种特殊的集群模式，即集群的所有服务器都部署在一台机器上。当你手头上有一台比较好的机器，如果作为单机模式进行部署，就会浪费资源，这种情况下，ZooKeeper允许你在一台机器上通过启动不同的端口来启动多个 ZooKeeper 服务实例，以此来以集群的特性来对外服务。