ZooKeeper

　　Kafka集群搭建分为单节点的伪分布式集群和多节点的分布式集群两种，首先来看一下单节点伪分布式集群安装。单节点伪分布式集群是指集群由一台ZooKeeper服务器和一台Kafka broker服务器组成，如下图所示： 　　 　　为了搭建单节点Kafka集群，需要依次安装如下软件：安装Java-->安装ZooKeeper-->安装Kafka。 一、安装Java 　　可以参考 linux安装jdk ,来进行安装 二、安装ZooKeeper 　　 下载地址： https://www-us.apache.org/dist/zookeeper/stable/ 　　下载二进制压缩包 zookeeper- 3.4 . 14 .tar.gz ，然后上传到linux服务器指定目录下，本次上传目录为 /software ，然后执行如下命令安装： tar -zxvf zookeeper- 3.4 . 14 .tar.gz mv zookeeper-3.4.14 /usr/local/zookeeper cd /usr/local/zookeeper/conf mv zoo_sample.cfg zoo.cfg mkdir /usr/local/zookeeper/data 　　然后修改 zoo.cfg 文件，设置参数： tickTime= 2000 dataDir=/usr/local

1、结构不一样 　　kafka broker：topic+partition rocketmq broker：topic+queue 　　kafka 注册中心：zookeeper rocketmq 注册中心：nameserver 2、消费 　　kafka中同一个consumergroup下消费实例无法广播消费，rocketmq可以实现广播消费 　　kafka如果实现广播，只要每个consumer有一个独立的group即可 3、吞吐量 　　kafka>rocketmq 　　kafka在消息存储时根据topic+partition数量创建物理文件，也就是说我们创建一个topic并指定了3个partition，那么就会有3个物理文件目录，也就说说partition的数量和对应的物理文件是一一对应的。 　　rocketmq消息实际上是存储在commitlog中的，consumequeue存储消息索引。 　　kafka多文件并发写入，而rocketmq是单文件写入，显然kafka吞吐量更大 4、nameserver VS zookeeper 　　kafka具备选举功能，当master挂掉会选举slave为master 　　rocketmq如果master挂掉，slave不会变为master；原本发送到该broker改为发送到另外broker上 来源： oschina 链接： https:/

本文节选自我开源的 JavaGuide ： https://github.com/Snailclimb/JavaGuide （Github标星92k+!一份涵盖大部分 Java 程序员所需要掌握的核心知识。准备 Java 面试，首选 JavaGuide！） 经历过技术面试的小伙伴想必对这个两个概念已经再熟悉不过了！ Guide哥当年参加面试的时候，不夸张地说，只要问到分布式相关的内容，面试官几乎是必定会问这两个分布式相关的理论。 并且，这两个理论也可以说是小伙伴们学习分布式相关内容的基础了！ 因此，小伙伴们非常非常有必要将这理论搞懂，并且能够用自己的理解给别人讲出来。 这篇文章我会站在自己的角度对这两个概念进行解读！ 个人能力有限。如果文章有任何需要改善和完善的地方，欢迎在评论区指出，共同进步！——爱你们的Guide哥 CAP理论 CAP 理论/定理 起源于 2000年，由加州大学伯克利分校的Eric Brewer教授在分布式计算原理研讨会（PODC）上提出，因此 CAP定理又被称作 布鲁尔定理（Brewer’s theorem） 2年后，麻省理工学院的Seth Gilbert和Nancy Lynch 发表了布鲁尔猜想的证明，CAP理论正式成为分布式领域的定理。 简介 CAP 也就是 Consistency（一致性） 、 Availability（可用性） 、 Partition

经历过技术面试的小伙伴想必对这个两个概念已经再熟悉不过了！ CAP 理论 CAP 理论/定理起源于 2000 年，由加州大学伯克利分校的 Eric Brewer 教授在分布式计算原理研讨会（PODC）上提出，因此 CAP 定理又被称作 布鲁尔定理（Brewer’s theorem） 2 年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 发表了布鲁尔猜想的证明，CAP 理论正式成为分布式领域的定理。 简介 CAP 也就是 Consistency（一致性） 、 Availability（可用性） 、 Partition Tolerance（分区容错性） 这三个单词首字母组合。 CAP 理论的提出者布鲁尔在提出 CAP 猜想的时候，并没有详细定义 Consistency 、 Availability 、 Partition Tolerance 三个单词的明确定义。 因此，对于 CAP 的民间解读有很多，一般比较被大家推荐的是下面 这种版本的解。 在理论计算机科学中，CAP 定理（CAP theorem）指出对于一个分布式系统来说，当设计读写操作时，只能能同时满足以下三点中的两个： 一致性（Consistence） : 所有节点访问同一份最新的数据副本 可用性（Availability） : 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。

最近面试了阿里、京东、美团、滴滴等大型互联网公司，最终收到了美团offer，这次面试过后，我把面试过的公司的面试题做了一个整理。这篇文章是我凭回忆记录的，面试题没有顺序，不分先后，接下来公布我去阿里、京东、美团等一线互联网公司的面试题： 一、阿里巴巴面试 　　1、开发中Java用得比较多的数据结构有哪些？ 　　2、谈谈你对HashMap的理解，底层原理的基本实现，HashMap怎么解决碰撞问题的？ 　　这些数据结构中是线程安全的吗？假如你回答HashMap是线程安全的，接着问有没有线程安全的map，接下来问conurren包。 　　3、对JVM熟不熟悉？简单说说类加载过程，里面执行的哪些操作？问了GC和内存管理，平时在tomect里面有没有进行过相关的配置。 　　4、说一下http协议、get和post的基本区别，接着问tcp/ip协议，三次握手，窗口滑动机制。 　　5、开发中用了哪些数据库？回答mysql；储存引擎有哪些？然后问了我悲观锁和乐观锁问题使用场景、分布式集群实现的原理。 　　6、springmvc和mybatis的工作原理，有没有看过底层源码？ 二、京东金融面试 　　1、Dubbo超时重试；Dubbo超时时间设置 　　2、如何保障请求执行顺序 　　3、分布式事物与分布式锁（扣款不要出现负数） 　　4、分布式session设置 　　5、执行某操作，前50次成功

几点说明 1、本系列Spring Cloud的博客参考了方志朋所著《深入理解Spring Cloud与微服务构建》； 2、大家如果想更加深入的理解Spring Cloud 建议多实战、多看书； Dubbo简介 介绍 Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。 Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力： 面向接口的远程方法调用:封装了长连接的NIO框架，例如:Netty、Mina等等； 智能容错和负载均衡； 服务自动注册和发现； 集成Apache的Zookeeper组件，用于用户的注册与发现； Dubbo框架的运行流程如下： 服务提供者注册进入服务注册中心； 服务消费者订阅服务； 服务消费者发现服务； 服务消费者通过远程调度来找到服务提供者进行服务的消费； 服务消费者和服务提供者定时发送心跳数据到服务监控中心用于记录调用次数和时间； Dubbo的优点： 连通性： 服务注册中心、服务提供者、服务消费者、服务监控中心都是长连接； 健壮性： 监控中心宕机不会影响其他的服务的正常进行，服务器集群配置的话，任意一个服务的宕机都不会影响整体的服务的运行状况； 伸缩性： 可以动态增减注册中心与服务的实例数量； 升级性： 服务器集群升级，不会对现有架构造成压力

----------------------------------------------------------------------------- spring boot 1.我理解就是把 spring spring mvc spring data jpa 等等的一些常用的常用的基础框架组合起来， 提供默认的配置，然后提供可插拔的设计，就是各种 starter ，来方便开发者使用这一系列的技术。 2.以前需要关注版本兼容和一堆配置整合文件， 现在可以先不关心如何配置，可以快速的启动开发，进行业务逻辑编写， 各种需要的技术，加入 starter 就配置好了，直接使用，可以说追求开箱即用的效果吧。 3.对使用者来说，换用Spring Boot以后，项目初始化方法变了，配置文件变了， 另外就是不需要单独安装Tomcat这类容器服务器了，maven打出jar包直接跑起来就是个网站，但你最核心的业务逻辑实现与业务流程实现没有任何变化。 4.4.0版本是Spring框架最新发布的主版本，并且首次完全支持Java8的功能。你依然可以使用较早的Java版本，但是现在所需的最小的版本已经被提升的Java SE6。 同时还利用主版本发布的机会删除了很多废弃的类和方法。 5.Spring 是一个“引擎”； Spring MVC 是基于Spring的一个 MVC 框架； Spring Boot

一、前言 　　前面有说到Dubbo的服务发现机制，也就是SPI，那既然Dubbo内部实现了更加强大的服务发现机制，现在我们就来一起看看Dubbo在发现服务后需要做什么才能将服务注册到注册中心中。 二、Dubbo服务注册简介 　　首先需要明白的是Dubbo是依赖于Spring容器的（至于为什么在上篇博客中有介绍），Dubbo服务注册过程也是始于Spring容器发布刷新事件。而后Dubbo在接收到事件后，就会进行服务注册，整个逻辑大致分为三个部分： 　　 1、检查参数，组装URL： 服务消费方是通过URL拿到服务提供者的，所以我们需要为服务提供者配置好对应的URL。 　　 2、导出服务到本地和远程： 这里的本地指的是JVM，远程指的是实现invoke，使得服务消费方能够通过invoke调用到服务。 　　 3、向注册中心注册服务： 能够让服务消费方知道服务提供方提供了那个服务。 三、接收Spring容器刷新事件 　　在简介中我们提到Dubbo服务注册是始于Spring容器发布刷新事件，那么Dubbo是如何接收该事件的呢？ 　　在我们平常编写provider的接口实现类时，都会打上 @Service注解 ，从而这个标注这个类属于ServiceBean。在ServiceBean中有这样一个方法onApplicationEvent。该方法会在收到 Spring 上下文刷新事件后执行服务注册操作

Redis集群设计包括 2部分：哈希 Slot和节点主从 节点主从： 主从设计不算什么新鲜玩意，在数据库中我们也经常用主从来做读写分离，直接上图： 图上能看得到的信息： 1， 只有1个Master，可以有N个slaver，而且Slaver也可以有自己的Slaver，由于这种主从的关系决定他们是在配置阶段就要指定他们的上下级关系，而不是Zookeeper那种平行关系是自主推优出来的。 2， 读写分离，Master只负责写和同步数据给Slaver，Slaver承担了被读的任务，所以Slaver的扩容只能提高读效率不能提高写效率。 3， Slaver先将Master那边获取到的信息压入磁盘，再load进内存，client端是从内存中读取信息的，所以Redis是内存数据库。 当一个新的Slaver加入到这个集群时，会主动找Master来拜码头，Master发现新的小弟后将全量数据发送给新的Slaver，数据量越大性能消耗也就越大，所以尽量避免在运行时做Slaver的扩容。 简单总结下主从模式的设计： 优点：读写分离，通过增加Slaver可以提高并发读的能力。 缺点：Master写能力是瓶颈。 虽然理论上对Slaver没有限制但是维护Slaver开销总将会变成瓶颈。 Master的Disk大小也将会成为整个Redis集群存储容量的瓶颈。 哈希Slot： 这个艺名看起来很文艺

【原创】我还是很建议你用DelayQueue搞定超时订单的(1) 我就是那个人见人爱的 锦成同学，我是java进阶架构师社区的特邀作者, 今天为大家带来新的一篇小知识,祝各位宝宝能学到新知识...更上一层楼..... 一、用三根鸡毛做引言 真的! 不骗你们的喔~ 相信大家都遇到类似于:订单30min后未支付自动取消的开发任务 那么今日份就来了解一下怎么用延时队列 DelayQueue搞定单机版的超时订单 二、延时队列使用场景 那么什么时候需要用延时队列呢？常见的延时任务场景 举栗子： 订单在30分钟之内未支付则自动取消。 重试机制实现,把调用失败的接口放入一个固定延时的队列,到期后再重试。 新创建的店铺，如果在十天内都没有上传过商品，则自动发送消息提醒。 用户发起退款，如果三天内没有得到处理则通知相关运营人员。 预定会议后，需要在预定的时间点前十分钟通知各个与会人员参加会议。 关闭空闲连接，服务器中，有很多客户端的连接，空闲一段时间之后需要关闭之。 清理过期数据业务。比如缓存中的对象，超过了空闲时间，需要从缓存中移出。 多考生考试,到期全部考生必须交卷,要求时间非常准确的场景。 三、解决办法多如鸡毛 定期轮询（数据库等） JDK DelayQueue JDK Timer ScheduledExecutorService 周期性线程池 时间轮(kafka) 时间轮