暂无个人介绍
暂时未有相关通用技术能力~
阿里云技能认证
详细说明本文介绍了Phoenix映射HBase时间戳的一种实现,希望抛砖引玉,读者根据自己的实际情况设计其他的实现方式。
本文介绍Phoenix在2345公司的实践,主要是实时查询平台的背景、难点、Phoenix解决的问题、Phoenix-Sql的优化以及Phoenix与实时数仓的融合思路
上一篇博客我们介绍了ActorSystem的创建过程,下面我们就研究一下actor的创建过程。 val system = ActorSystem("firstActorSystem",ConfigFactory.load()) val helloActor= system.actorOf(Props(new HelloActor),"HelloActor") helloActor ! "Hello" 普通情况下,我们一般使用ActorSystem的actorOf来创建actor,当然通过上一篇博客的介绍,我们已经知道actorOf是继承自ActorRefFactory的函数。
由于本人对Akka比较感兴趣,也用Akka开发了一些系统,但对Akka的源码还没有具体分析过,希望研究源码的同时写一点博客跟大家分享。有不当之处还请指正。我准备采取Debug的方式来研究Akka的运行过程,从入口开始,直至分析Akka是如何运转的。
慎用ask应该是Akka设计的一个准则,很多时候我们应该禁用ask。之所以单独把ask拎出来作为一篇博文,主要是akka的初学者往往对ask的使用比较疑惑。 "Using ask will send a message to the receiving Actor as with tell,...
SpringCloud生态强调微服务,微服务也就意味着将各个功能独立的业务抽象出来,做成一个单独的服务供外部调用。但每个人对服务究竟要有多“微”的理解差异很大,导致微服务的粒度很难掌控,划分规则也不统一。
While模式严格来说是while循环在Akka中的合理实现。while是开发过程中经常用到的语句之一,也是绝大部分编程语言都支持的语法。但while语句是一个循环,如果循环条件没有达到会一直执行while语句体的代码,且会阻塞while语句外的代码。
链式调用在很多框架和系统中经常存在,算不得上是我自己总结的设计模式,此处只是简单介绍在Akka中的两种实现方式。我在这边博客中简化了链式调用的场景,简化后也更符合Akka的设计哲学。 trait Chained{ def receive:Receive = Actor.
所谓的Aggregate模式,其实就是聚合模式,跟masterWorker模式有点类似,但其出发点不同。masterWorker模式是指master向worker发送命令,worker完成某种业务逻辑。
通过前面的文章我们总结了几个常见的actor设计模式,但此处不得不提前介绍一下在Akka中消息的设计模式。随着对Akka的使用,我们会发现,使用Akka设计系统其实就是面向消息编程。actor之间消息设计的是否合理,往往意味着Akka应用设计的是否合理。
上一节我们介绍了Akka使用的基本模式,简单点来说就是,发消息给actor,处理结束后返回消息。但这种模式有个缺陷,就是一旦某个消息处理的比较慢,就会阻塞后面所有消息的处理。那么有没有方法规避这种阻塞呢,这就是本章要讲的Backend模式。
本文介绍akka的基本使用方法,由于属于基础功能,想不出一个很高大上的名称,此处就以基础模式命名。下文会介绍actor的使用方法,及其优劣点。 class SimpleActor(name:String) extends Actor { private def doWork(message...
谈到Akka就必须介绍Actor并发模型,而谈到Actor就必须看一篇叫做《A Universal Modular Actor Formalism for Artificial Intelligence 》的论文,它最早发表于1973年,提出了一种并发计算的理论模型,Actor就源于该模型。
性能 这也是一个比较大的问题,因为性能不一定是Akka本身的问题,还可能是你代码写的有问题。 优化的第一步就是找出性能的瓶颈,隔离出应用程序里面比较耗时的部分,然后尝试对其优化,减少需要耗费的时间成本。
可用性 简单点来说就是系统能否正常使用。如果系统能够及时响应一个请求,则认为是可用的;如果响应时间过长或者根本不响应,则是不可用的。系统在停机或超载时是不可用的。一般用系统正常运行时长的百分比来计量系统的可用性,例如常常用N个9表示系统的可用性。
容错 容错绝对是分布式系统最难搞定的事儿,至少我这样认为,因为意外总是会发生。 处理故障在许多方面意味着要放弃全局一致性。Akka是基于不粗要调用方负责处理故障的想法而建立的。它主张由发生故障的actor负责处理问题,在actor不能处理的情况下,会向其“监督者”寻求帮助。
一致性和可扩展性 一致性是系统内比较复杂的属性,它会随着系统的变化而变化。简单来说,一致性就是数据保持一致,在分布式系统中,可以理解为多个节点中数据的值是一致的。一旦系统具有并行性(分布式只是并行的一种表现),保持一致性就变得困难了,毕竟需要协调全局状态。
优秀的Actor设计 我看到这一章节真是如获至宝,毕竟它阐释了如何使用Akka,以及优秀的设计模式。 大系统小做 其实作者想告诉我们的是要尽量提前关注actor级别的设计,而不是仅仅考虑大的架构。
在对JavaBean做序列化时,我们可能在某些场景希望前后兼容性好一些。比如所有的javaBean都序列化后保存在数据库,用的时候需要反序列化创建。随着业务的发展,数据模型可能会进行变更,那么原来的数据进行反序列化时可能会遇到版本不一致的问题。
分布式领域驱动设计 DDD领域驱动设计,应该就是一种系统设计的方法论,可以知道人们设计软件。其实老外就喜欢总结一些方法论用于指导实践,这一点还是很重要的。 DDD概述 DDD是一套关于软件架构的指导原则。
Akka简介 Akka是什么:“Akka是在JVM上构建高并发、分布式、弹性消息驱动应用的开源工具包”。弹性意味着要积极响应失败情况,从失败中恢复的能力。 其实Akka的定义很符合响应式领域模型,这个模型有几个基本特征: 1、弹性。
问题背景 与数据库或者存储系统交互是所有应用软件都必不可少的功能之一,akka开发的系统也不例外。但akka特殊的地方在于,会尽可能的将所有的功能都设计成异步的,以避免Actor阻塞,然而无法避免IO这类的阻塞操作。
作者属于Scala、Akka技术爱好者,但苦于Akka没有关于设计模式的文章,偶尔搜到《Akka应用模式》一书,如获至宝。现整理一些读书笔记和自己的感悟,以供参考。 Actor模型 Actor模型感觉还是很给力的,要是按我以前学习actor模型,绝对会对他嗤之以鼻,这玩儿意能干啥。
RT quill目前的驱动(2.4.2版本)不支持json,等待作者更新版本吧
不得不说这是一本好书。本书涉及的主要内容从书名就可以看出来:函数式、响应式、领域驱动建模。 该书并不是一个入门级教材,读者需要对函数式、响应式、领域驱动建模有一定的基础,缺一不可。比如我对领域驱动建模这块不是太熟悉,研读的时候会不太理解作者为什么会举那些例子;对函数式不够深入,看后面几章就会有云里雾里的感觉;对响应式不清楚,就不会明白作者费那么大的劲举的例子解决了一个什么问题。
tomcat作为web容器被广泛应用,但作者所在的公司restful接口特别多,每个接口都需要一个tomcat来启动,为了配置隔离,一般都会把tomcat安装文件复制多遍,分别把war包部署在对应的webapp目录下,但这样造成的问题就是tomcat安装文件占用了大量的磁盘空间,且不便于统一管理。
Actor使用模式 现在我们已经了解了可以创建的actor系统的不同类型,那么我们在编写基于actor的应用程序时,可以采用什么样的使用模式,以便避免出现常见错误呢? 下面就让我们看看其中使用模式。
第一章 Actor应用程序类型 在会议上发言时,我遇到的最多问题之一是“基于Actor的应用程序的用例是什么?”这取决于您要完成的任务,但是如果您想构建具有可管理的并发性、跨节点向外扩展性、并具有容错能力的应用程序,actor就非常适合了。
以下是对StreamingListene的研究,由于比较简单,故只贴代码,不做解释 /** * Created by gabry.wu on 2016/5/27. * 实现StreamingListener,以监控spark作业状态 * 传入StreamingContext可以在...
本文提供一种用SCALA把JSON串转换为HIVE表的方法,由于比较简单,只贴代码,不做解释。有问题可以留言探讨 package com.gabry.hiveimport org.json4s.
上一篇博客中,已经对股票预测的例子做了简单的讲解,下面对其中的几个关键的技术点再作一些总结。 1、updateStateByKey 由于在1.6版本中有一个替代函数,据说效率比较高,所以作者就顺便研究了一下该函数的用法。
最近学习Spark Streaming,不知道是不是我搜索的姿势不对,总找不到具体的、完整的例子,一怒之下就决定自己写一个出来。下面以预测股票走势为例,总结了用Spark Streaming开发的具体步骤以及方法。