Browsed by
标签:Zookeeper

最常用的Java框架或者开源项目有哪些?

最常用的Java框架或者开源项目有哪些?

閱讀本文約花費: 19 (分鐘)系统设计 微服务/分布式 基础框架 Spring Boot [1] :Spring Boot 可以轻松创建独立的生产级基于 Spring 的应用程序,内置 web 服务器让你可以像运行普通 Java 程序一样运行项目。另外,大部分 Spring Boot 项目只需要少量的配置即可,这有别于 Spring 的重配置。 spring-cloud-alibaba[2] : Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件,方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。 Spring Cloud Alibaba Sentinel[3] :A lightweight powerful flow control component enabling reliability and monitoring for microservices. (轻量级的流量控制、熔断降级 Java 库)。 Dubbo[4] :Apache Dubbo 是一个基于 Java 的高性能开源 RPC 框架。 Nacos[5] :Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮…

Read More Read More

分布式定时任务调度框架实践

分布式定时任务调度框架实践

閱讀本文約花費: 14 (分鐘)分布式任务调度框架几乎是每个大型应用必备的工具,本文介绍了任务调度框架使用的需求背景和痛点,对业界普遍使用的开源分布式任务调度框架的使用进行了探究实践,并分析了这几种框架的优劣势和对自身业务的思考。 一、业务背景 1.1 为什么需要使用定时任务调度 (1)时间驱动处理场景:整点发送优惠券,每天更新收益,每天刷新标签数据和人群数据。 (2)批量处理数据:按月批量统计报表数据,批量更新短信状态,实时性要求不高。 (3)异步执行解耦:活动状态刷新,异步执行离线查询,与内部逻辑解耦。 1.2 使用需求和痛点 (1)任务执行监控告警能力。 (2)任务可灵活动态配置,无需重启。 (3)业务透明,低耦合,配置精简,开发方便。 (4)易测试。 (5)高可用,无单点故障。 (6)任务不可重复执行,防止逻辑异常。 (7)大任务的分发并行处理能力。 二、开源框架实践与探索  2.1 Java 原生 Timer 和ScheduledExecutorService 2.1.1 Timer使用 Timer缺陷: Timer底层是使用单线程来处理多个Timer任务,这意味着所有任务实际上都是串行执行,前一个任务的延迟会影响到之后的任务的执行。 由于单线程的缘故,一旦某个定时任务在运行时,产生未处理的异常,那么不仅当前这个线程会停止,所有的定时任务都会停止。 Timer任…

Read More Read More

当我们谈注册中心时谈什么?

当我们谈注册中心时谈什么?

閱讀本文約花費: 11 (分鐘)最近工作重心转向了注册中心,于是想来写一篇关于注册中心的文章 概念 什么是注册中心,以大多数人熟悉的RPC框架来说,通常RPC中有三种角色: provider 服务提供者 consumer 服务消费者,即调用方 registry 注册中心,让consumer能发现provider的关键 注册中心对于服务提供者需要具备服务注册、注销的能力,对于服务消费者需要提供查询服务、感知服务变化的功能。当然还需要解决一些其他问题才能成为一个优秀的注册中心,如高可用、高性能、水平扩展能力、服务探活能力、路由功能、多机房(多活)能力等。 特性详解 存储 可以将注册中心理解为一个存储系统,存储着服务名与服务提供方的映射表。由此可见DNS是目前使用最广泛的注册中心。一般注册中心对存储没有什么要求,甚至你可以基于数据库来实现一个注册中心。 高可用 在聊高可用前,假定你了解分布式CAP理论,如果不知道可以稍微网上查一下,这里就不赘述。 其中对注册中心的高可用要求尤其高,它有如下几层含义,首先肯定是集群部署,无单点问题,其次就算整个集群挂掉了,也不能影响现有服务的调用,只不过现有的调用关系无法及时改变而已。 在分布式理论CAP中,注册中心更理想的应该是AP模式。(此结论更多讨论参考文末的《阿里巴巴为什么不用ZooKeeper做服务发现》),可以简单的从以下两个场景来理解:​ 注…

Read More Read More

再有人问你分布式事务,把这篇扔给他

再有人问你分布式事务,把这篇扔给他

閱讀本文約花費: 24 (分鐘)前言 不知道你是否遇到过这样的情况,去小卖铺买东西,付了钱,但是店主因为处理了一些其他事,居然忘记你付了钱,又叫你重新付。又或者在网上购物明明已经扣款,但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的一些重要性。有了事务,你去小卖铺买东西,那就是一手交钱一手交货。有了事务,你去网上购物,扣款即产生订单交易。 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元,组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交,只要其中任一操作执行失败,都将导致整个事务的回滚。简单地说,事务提供一种“要么什么都不做,要么做全套(All or Nothing)”机制。 数据库本地事务 ACID 说到数据库事务就不得不说,数据库事务中的四大特性,ACID: A:原子性(Atomicity) 一个事务(transaction)中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。 就像你买东西要么交钱收货一起都执行,要么要是发不出货,就退钱。 C:一致性(Consistency) 事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成,那么…

Read More Read More

阿里巴巴为什么不用 ZooKeeper 做服务发现?

阿里巴巴为什么不用 ZooKeeper 做服务发现?

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

Read More Read More

连接zookeeper时报”Path cannot be null”错误的解决方法

连接zookeeper时报”Path cannot be null”错误的解决方法

閱讀本文約花費: 3 (分鐘)   上周将公司生产环境中zookeeper集群中的一台zookeeper重启后,所有的连接此zookeeper的客户端都报如下错误: [ctvpay] 2018-03-23 10:57:08.569 — ERROR [main-EventThread] CuratorFrameworkImpl.java:529 – Watcherexceptionjava.lang.IllegalArgumentException: Path cannot be null        at org.apache.zookeeper.common.PathUtils.validatePath(PathUtils.java:45) ~[zookeeper-3.4.6.jar!/:3.4.6-1569965]        at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1572) ~[zookeeper-3.4.6.jar!/:3.4.6-1569965]        at com.netflix.curator.framework…

Read More Read More

分布式服务框架 Zookeeper

分布式服务框架 Zookeeper

閱讀本文約花費: 1 (分鐘) ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。 1- 分布式服务框架 Zookeeper入门学习 https://coolshell.me/articles/zookeeper-intro-01.html 2- 分布式服务框架Zookeeper介绍、原理及应用 https://coolshell.me/articles/zookeeper-intro-02.html 3- ZooKeeper实际应用案例-开发实战 https://coolshell.me/articles/zookeeper-intro-03.html 4- Zookeeper典型应用场景介绍 https://coolshell.me/articles/zookeeper-intro-04.html 5- 分布式服务协调框架ZooKeeper https://coolshell.me/articles/zookeeper-intro-05.html 6- Zookeeper到底是干嘛的 https://coolshell.me/articles/zookeeper-intr…

Read More Read More

Zookeeper到底是干嘛的

Zookeeper到底是干嘛的

閱讀本文約花費: 17 (分鐘) Zookeeper主要哪些服务:配置管理,名字服务,提供分布式同步以及集群管理,更多介绍请看下文. 在Zookeeper的官网上有这么一句话:ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. 这大概描述了Zookeeper主要可以干哪些事情:配置管理,名字服务,提供分布式同步以及集群管理。那这些服务又到底是什么呢?我们为什么需要这样的服务?我们又为什么要使用Zookeeper来实现呢,使用Zookeeper有什么优势?接下来我会挨个介绍这些到底是什么,以及有哪些开源系统中使用了。 配置管理 在我们的应用中除了代码外,还有一些就是各种配置。比如数据库连接等。一般我们都是使用配置文件的方式,在代码中引入这些配置文件。但是当我们只有一种配置,只有一台服务器,并且不经常修改的时候,使用配置文件是一个很好的做法,但是如果我们配置非常多,有很多服务器都需要这个配置,而且还可能是动态的话使用配置文件就不是个好主意了。这个时候往往需要寻找一种集中管理配置的方法,我们在这个集中的地方修改了配置,所有对这个配置感…

Read More Read More

分布式服务协调框架ZooKeeper

分布式服务协调框架ZooKeeper

閱讀本文約花費: 13 (分鐘) 文章重点介绍了ZooKeeper数据模型,ZooKeeper典型的应用场景以及Zookeeper service网络结构,希望对大家有帮助。 。 ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务框架,它可以实现同步服务,配置维护、命名服务、分布式锁等分布式基础服务。 ZooKeeper数据模型 Zookeeper提供基于类似于文件系统的目录节点树方式的数据存储,但是Zookeeper并不是用来专门存储数据的,它的作用主要是用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化,从而可以达到基于数据的集群管理。 数据模型 Zookeeper会维护一个具有层次关系的数据结构,它非常类似于一个标准的文件系统,如图: 与Linux文件系统不同的是,Zookeeper的数据节点称为znode,znode是Zookeeper中数据的最小单元,每个znode都可以保存数据,同时还可以挂载子节点,因此构成了一个层次化的命名空间,称为树。 znode结构 每个znode节点既像文件一样维护着数据、元信息、ACL、时间戳等数据结构,又像目录一样可以作为路径标识的一部分。每个znode由3部分组成: stat:状态信息, 描述该Znode的版本, 权限等信息 data:与该znode关联的数据 children:该znode下的子…

Read More Read More

Zookeeper典型应用场景介绍

Zookeeper典型应用场景介绍

閱讀本文約花費: 13 (分鐘) 本文主要通过几个例子来具体的说明Zookeeper在特定场景下的使用方式 ,希望对您的学习有所帮助。 1.前言 之前自己写了一些关于Zookeeper的基础知识,Zookeeper作为一种协调分布式应用高性能的调度服务,实际的应用场景也非常的广泛,这里主要通过几个例子来具体的说明Zookeeper在特定场景下的使用方式(下面的这些功能估计consul和etcd也能实现,以后学到了再说吧)。 2.具体应用 2.1.一致性配置管理 我们在开发的时候,有时候需要获取一些公共的配置,比如数据库连接信息等,并且偶然可能需要更新配置。如果我们的服务器有N多台的话,那修改起来会特别的麻烦,并且还需要重新启动。这里Zookeeper就可以很方便的实现类似的功能。 2.1.1.思路 将公共的配置存放在Zookeeper的节点中 应用程序可以连接到Zookeeper中并对Zookeeper中配置节点进行读取或者修改(对于写操作可以进行权限验证设置),下面是具体的流程图: 2.1.2.事例 数据库配置信息一致性的维护 配置类: public class CommonConfig implements Serializable{// 数据库连接配置private String dbUrl;private String username;private String pas…

Read More Read More

ZooKeeper实际应用案例-开发实战

ZooKeeper实际应用案例-开发实战

閱讀本文約花費: 12 (分鐘) 本文主要介绍通过实际工作中的一个例子,讲解zookeeper是如何帮我解决分布式问题,以此引导大家发现自己系统中可以应用zookeeper的场景。 项目背景介绍 首先给大家介绍一下本文描述项目的情况。这是一个检索网站,它让你能在几千万份复杂文档数据中检索出你所需要的文档数据。为了加快检索速度,项目的数据分布在100台机器的内存里,我们称之为数据服务器。除了数据,这100台机器上均部署着检索程序。这些server之外,还有数台给前端提供接口的搜索server,这些机器属一个集群,我们称之为检索服务器。当搜索请求过来时,他们负责把搜索请求转发到那100台机器,待所有机器返回结果后进行合并,最终返回给前端页面。结构如下图: 面临问题 网站上线之初,由于数据只有几百万,所以数据服务器只有10多台。是一个规模比较小的分布式系统,当时没有做分布式系统的协调,也能正常工作,偶尔出问题,马上解决。但是到了近期,机器增长到100台,网站几乎每天都会出现问题,导致整个分布式系统挂掉。问题原因如下: 数据服务器之前没有做分布式协调。对于检索服务器来说,并不知道哪些数据服务器还存活,所以检索服务器每次检索,都会等待100台机器返回结果。但假如100台数据服务中某一台死掉了,检索服务器也会长时间等待他的返回。这导致了检索服务器积累了大量的请求,最终被压垮。当所有的检索服务器…

Read More Read More

分布式服务框架Zookeeper介绍、原理及应用

分布式服务框架Zookeeper介绍、原理及应用

閱讀本文約花費: 18 (分鐘) 文章主要介绍了Zookeeper基础 、Zookeeper设计目的、Zookeeper工作原理以及相关的应用。 Zookeeper简介 Zookeeper 分布式服务框架是 Apache Hadoop 的一个子项目,它主要是用来解决分布式应用中经常遇到的一些数据管理问题,如:统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等等。 Zookeeper基本概念 zk角色 Zookeeper中的角色主要有以下三类,如下表所示:zookeeper角色 zk service网络结构 Zookeeper的工作集群可以简单分成两类,一个是Leader,唯一一个,其余的都是follower,如何确定Leader是通过内部选举确定的。 Leader和各个follower是互相通信的,对于zk系统的数据都是保存在内存里面的,同样也会备份一份在磁盘上。 对于每个zk节点而言,可以看做每个zk节点的命名空间是一样的,也就是有同样的数据。(可查看下面的树结构) 如果Leader挂了,zk集群会重新选举,在毫秒级别就会重新选举出一个Leaer。 集群中除非有一半以上的zk节点挂了,zk service才不可用。 zk命名空间结构 Zookeeper的命名空间就是zk应用的文件系统,它和linux的文件系统很像,也是树状,这样就可以确定每个路径都是唯一的,对于命名空…

Read More Read More

分布式服务框架 Zookeeper入门学习

分布式服务框架 Zookeeper入门学习

閱讀本文約花費: 17 (分鐘) 本文主要讲解了ZooKeeper是什么,它的角色及架构,ZooKeeper数据模型Znode,ZooKeeper服务中操作,Zookeeper下载安装与配置和命令相关。 ZooKeeper介绍 ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务,是Google的Chubby一个开源的实现。 提供功能: 命名服务 配置管理 集群管理 分布式锁 队列管理 特性: 顺序一致性:从同一个客户端发起的事务请求,最终将会严格按照其发起顺序被应用到ZooKeeper中。 原子性:所有事务请求的结果在集群中所有机器上的应用情况是一致的,也就是说要么整个集群所有集群都成功应用了某一个事务,要么都没有应用,一定不会出现集群中部分机器应用了该事务,而另外一部分没有应用的情况。 单一视图:无论客户端连接的是哪个ZooKeeper服务器,其看到的服务端数据模型都是一致的。 可靠性:一旦服务端成功地应用了一个事务,并完成对客户端的响应,那么该事务所引起的服务端状态变更将会被一直保留下来,除非有另一个事务又对其进行了变更。 实时性:通常人们看到实时性的第一反应是,一旦一个事务被成功应用,那么客户端能够立即从服务端上读取到这个事务变更后的最新数据状态。这里需要注意的是,ZooKeeper仅仅保证在一定的时间段内,客户端最终一定能够从服务端上读取到最新的…

Read More Read More

面试官邪魅一笑:MySQL千万级别大表,你要如何优化?

面试官邪魅一笑:MySQL千万级别大表,你要如何优化?

閱讀本文約花費: 23 (分鐘)当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑、部署、运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是没有太大问题的。而事实上很多时候MySQL单表的性能依然有不少优化空间,甚至能正常支撑千万级以上的数据量: 字段 尽量使用TINYINT、SMALLINT、MEDIUM_INT作为整数类型而非INT,如果非负则加上UNSIGNED VARCHAR的长度只分配真正需要的空间 使用枚举或整数代替字符串类型 尽量使用TIMESTAMP而非DATETIME, 单表不要有太多字段,建议在20以内 避免使用NULL字段,很难查询优化且占用额外索引空间 用整型来存IP 索引 索引并不是越多越好,要根据查询有针对性的创建,考虑在WHERE和ORDER BY命令上涉及的列建立索引,可根据EXPLAIN来查看是否用了索引还是全表扫描 应尽量避免在WHERE子句中对字段进行NULL值判断,否则将导致引擎放弃使用索引而进行全表扫描 值分布很稀少的字段不适合建索引,例如”性别”这种只有两三个值的字段 字符字段只建前缀索引 字符字段最好不要做主键 不用外键,由程序保证约束 尽量不用UNIQUE,由程序保证约…

Read More Read More

Scroll Up